# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## BPROXY — Reverse-proxy connection reliability A fictional reporting API sits behind a reverse proxy. Clients see intermittent disconnects and incorrect origins after changes to keep-alive and forwarding headers. **Field:** Networking. **Suggested stack:** TypeScript, HTTP, Local reverse proxy. **Engineer value:** Practice HTTP intermediaries, connection lifetimes, and network failure isolation. **Company value:** Provide a proxy contract that preserves request identity and releases resources predictably. **Delivery agreement:** Deliver a local proxy configuration or adapter plus reproducible failure checks. ### Setup prerequisites - Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. ### Define proxy trust Constrain forwarding and request interpretation. #### BPROXY-101 — Document the trusted proxy chain and public origin **Task · Medium priority · Foundational** noCV practice brief v5 · BPROXY-101 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define proxy trust. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Networking 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The application trusts forwarding headers from any caller. Acceptance criteria - List trusted proxy hops and expected public origin. - Define which hop sets each forwarding field. - Reject ambiguous trust configuration. Implementation constraints - All modeled hops are local fixtures. Verification - Resolve origin through the trusted chain. - Reject direct-client spoofed forwarding metadata. Deliverables - Proxy trust contract. Rollout and recovery: Review the trust chain before changing application origin handling. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-102 — Normalize forwarded headers without accepting client spoofing **Bug · High priority · Advanced** noCV practice brief v5 · BPROXY-102 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define proxy trust. Depends on: BPROXY-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Networking 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A client-provided forwarded host changes generated callback URLs. Acceptance criteria - Discard untrusted incoming forwarding fields. - Set canonical forwarding metadata at the trusted boundary. - Reject malformed or conflicting host values. Implementation constraints - Use an explicit allowed-origin list. Verification - Generate a callback for the allowed origin. - Inject a spoofed forwarded host and verify rejection. Deliverables - Forwarding-header guard. Rollout and recovery: Enable alongside the reviewed proxy chain; retain safe fixed-origin fallback. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-103 — Strip hop-by-hop headers before forwarding requests **Task · High priority · Intermediate** noCV practice brief v5 · BPROXY-103 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define proxy trust. Depends on: BPROXY-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 80% · API design 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Connection-specific headers are forwarded as if they were end-to-end metadata. Acceptance criteria - Remove declared hop-by-hop fields. - Honor fields named by the Connection header. - Preserve required end-to-end headers. Implementation constraints - Parse header names case-insensitively and bound header size. Verification - Forward a valid request unchanged semantically. - Verify Connection-nominated fields do not reach upstream. Deliverables - Header forwarding tests. Rollout and recovery: Deploy to the local proxy fixture first and inspect resulting headers. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Manage connections Handle reuse, timeouts, and cancellation. #### BPROXY-104 — Align keep-alive lifetimes between proxy and upstream **Bug · High priority · Advanced** noCV practice brief v5 · BPROXY-104 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage connections. Depends on: BPROXY-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Performance engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The proxy reuses sockets just after the upstream has closed them. Acceptance criteria - Document idle-timeout relationships. - Retire idle connections before unsafe reuse under the chosen policy. - Classify stale-connection failures separately. Implementation constraints - Use controlled local timeout fixtures. Verification - Reuse a valid connection. - Expire upstream idle state and verify bounded recovery. Deliverables - Connection lifetime configuration. Rollout and recovery: Change one timeout at a time; retain previous values for comparison. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-105 — Limit upstream connections per service without unbounded waiting **Task · High priority · Intermediate** noCV practice brief v5 · BPROXY-105 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage connections. Depends on: BPROXY-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Performance engineering 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A slow upstream creates an unlimited queue behind a finite connection pool. Acceptance criteria - Set finite active and waiting limits. - Return explicit overload responses when waiting is full. - Remove cancelled waiters. Implementation constraints - Keep limits service-scoped and observable. Verification - Serve within the configured pool. - Overflow the wait queue and verify no resource leak. Deliverables - Bounded upstream pool. Rollout and recovery: Start conservatively; tune only from recorded workload behavior. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-106 — Propagate downstream disconnects through streamed responses **Bug · High priority · Advanced** noCV practice brief v5 · BPROXY-106 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage connections. Depends on: BPROXY-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Backend 30% · Performance engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A cancelled report download continues consuming upstream bandwidth. Acceptance criteria - Abort the owned upstream request on disconnect. - Stop buffering and release stream resources. - Preserve completion metrics distinct from cancellation. Implementation constraints - Use bounded synthetic report streams. Verification - Finish a small streamed response. - Disconnect mid-stream and verify upstream cancellation. Deliverables - Streaming cancellation fix. Rollout and recovery: Adopt on one streaming route; retain traces of safe lifecycle events. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-107 — Avoid unsafe automatic replay after partial request transmission **Task · High priority · Advanced** noCV practice brief v5 · BPROXY-107 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage connections. Depends on: BPROXY-104, BPROXY-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 40% · API design 30% · Distributed systems 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The proxy retries a POST after its connection breaks, potentially duplicating a write. Acceptance criteria - Distinguish retryable methods and declared idempotent operations. - Track whether request transmission may have occurred. - Return unknown outcome when safe replay cannot be established. Implementation constraints - Do not infer idempotency from an empty response. Verification - Retry a safe read after a stale connection. - Break a write after transmission and prevent blind replay. Deliverables - Proxy retry policy. Rollout and recovery: Disable automatic write retries until application identity semantics are explicit. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Verify proxy changes Measure behavior and rehearse configuration recovery. #### BPROXY-108 — Compare buffering and streaming under bounded memory **Task · High priority · Expert** noCV practice brief v5 · BPROXY-108 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify proxy changes. Depends on: BPROXY-105, BPROXY-106, BPROXY-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Networking 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Buffering simplifies upstream retries but large reports exhaust proxy memory. Acceptance criteria - Compare identical synthetic response sizes and client rates. - Measure memory, time-to-first-byte, completion, and cancellation. - Explain retry and partial-response tradeoffs. Implementation constraints - Record machine limits and do not generalize local throughput. Verification - Run fast and slow clients under both policies. - Expose the memory or partial-response failure boundary. Deliverables - Proxy buffering decision record. Rollout and recovery: Select route-specific policy with explicit byte limits and rollback configuration. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-109 — Reload proxy configuration without dropping healthy in-flight requests **Task · High priority · Advanced** noCV practice brief v5 · BPROXY-109 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify proxy changes. Depends on: BPROXY-108. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Configuration reloads close active report streams immediately. Acceptance criteria - Validate new configuration before activation. - Drain existing connections within a bounded deadline. - Reject invalid reloads while retaining the prior configuration. Implementation constraints - Use only locally owned processes. Verification - Reload during an active stream. - Submit invalid configuration and verify the old proxy remains usable. Deliverables - Graceful reload behavior. Rollout and recovery: Keep a tested prior configuration and an explicit drain timeout. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BPROXY-110 — Write a proxy incident checklist by connection stage **Chore · Low priority · Foundational** noCV practice brief v5 · BPROXY-110 · Reverse-proxy connection reliability Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify proxy changes. Depends on: BPROXY-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Networking 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Operators need to distinguish header rejection, pool waiting, and upstream disconnects. Acceptance criteria - Map safe failure categories to checks. - Include current timeout and pool settings. - Document bounded rollback and drain commands. Implementation constraints - Do not capture request bodies or credentials. Verification - Diagnose a synthetic stale connection. - Distinguish pool overload from upstream application failure. Deliverables - Proxy support runbook. Rollout and recovery: Ship with configuration changes and verify it during local rehearsal. Project prerequisites: Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic. Engineer value: Practice HTTP intermediaries, connection lifetimes, and network failure isolation. Company value: Provide a proxy contract that preserves request identity and releases resources predictably. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.