# 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. ## BEGRESS — Restricted outbound fetch gateway A fictional content-import service accepts document URLs. The team needs explicit destination approval, redirect handling, and response limits before enabling imports. **Field:** Networking. **Suggested stack:** TypeScript, HTTP, DNS fixtures. **Engineer value:** Practice URL interpretation, network policy enforcement, and resource controls. **Company value:** Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. **Delivery agreement:** Deliver a local gateway contract and authorized lab tests; no unrestricted internet proxy. ### Setup prerequisites - Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. ### Define destination policy Normalize URLs and bind approved destinations. #### BEGRESS-101 — Define the approved destination contract for imports **Task · Medium priority · Foundational** noCV practice brief v5 · BEGRESS-101 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define destination policy. 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 importer accepts any URL beginning with a trusted-looking string. Acceptance criteria - Specify allowed scheme, hostname, port, and path scope. - Represent exact hosts separately from subdomain rules. - Reject unknown policy entries. Implementation constraints - Use fictional destinations mapped only inside the local simulator. Verification - Accept an exact approved destination. - Reject a lookalike hostname and unapproved port. Deliverables - Destination policy schema. Rollout and recovery: Default to deny until a reviewed policy exists. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-102 — Normalize import URLs without changing their authority **Task · High priority · Advanced** noCV practice brief v5 · BEGRESS-102 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define destination policy. Depends on: BEGRESS-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Networking 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. User-info syntax and encoded separators confuse destination checks. Acceptance criteria - Parse URLs with a single canonical parser. - Reject credentials, ambiguous encodings, and unsupported schemes. - Compare normalized authority against policy. Implementation constraints - Do not perform a request during validation. Verification - Normalize an approved URL deterministically. - Reject user-info and authority-confusion fixtures. Deliverables - URL validation boundary. Rollout and recovery: Run validation before queueing any fetch. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. ### Enforce bounded fetching Check resolution, redirects, and response limits. #### BEGRESS-103 — Bind resolved addresses to the approved hostname policy **Task · High priority · Advanced** noCV practice brief v5 · BEGRESS-103 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce bounded fetching. Depends on: BEGRESS-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Security 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. An approved hostname resolves to an address outside the permitted destination range. Acceptance criteria - Validate every candidate address against policy. - Reject private or special ranges unless explicitly authorized in the lab policy. - Pin the validated resolution for the connection. Implementation constraints - The local test harness explicitly maps approved loopback fixtures; production defaults remain deny. Verification - Connect using an approved simulated resolution. - Change resolution to an unapproved range and deny the request. Deliverables - Resolution-aware fetch policy. Rollout and recovery: Fail closed on resolution ambiguity or unavailable policy. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-104 — Revalidate every redirect before following it **Bug · High priority · Intermediate** noCV practice brief v5 · BEGRESS-104 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce bounded fetching. Depends on: BEGRESS-103. Difficulty: Intermediate. Estimated focused work: 150 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. An approved endpoint redirects the importer to an unapproved destination. Acceptance criteria - Validate each redirect target independently. - Bound redirect count. - Prevent credentials or sensitive headers crossing origins. Implementation constraints - Do not inherit destination approval from the first URL. Verification - Follow an approved same-policy redirect. - Reject an unapproved target and a redirect loop. Deliverables - Redirect policy checks. Rollout and recovery: Disable redirects by default until the policy is configured. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-105 — Enforce response byte limits during streaming **Task · High priority · Intermediate** noCV practice brief v5 · BEGRESS-105 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce bounded fetching. Depends on: BEGRESS-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Security 30% · 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 response exceeds memory limits before its declared size can be checked. Acceptance criteria - Enforce streamed compressed and expanded byte limits. - Abort when the configured bound is exceeded. - Reject inconsistent length metadata safely. Implementation constraints - Never buffer an unbounded response. Verification - Fetch a small valid synthetic document. - Abort an oversized or expanding response and release resources. Deliverables - Bounded response reader. Rollout and recovery: Start with conservative document limits and explicit too-large errors. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-106 — Constrain total fetch time across DNS and redirects **Task · High priority · Advanced** noCV practice brief v5 · BEGRESS-106 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce bounded fetching. Depends on: BEGRESS-103, BEGRESS-104, BEGRESS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Site reliability 30% · Backend 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. Each redirect gets a fresh timeout, extending one import indefinitely. Acceptance criteria - Use one total deadline for all stages. - Propagate cancellation to owned operations. - Settle even when a destination double ignores cancellation. Implementation constraints - No automatic retry after the total budget expires. Verification - Complete a multi-stage fetch within budget. - Exhaust the deadline during redirects and verify cleanup. Deliverables - End-to-end fetch deadline. Rollout and recovery: Return a retryable unavailable result only under the documented import policy. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-107 — Separate content-type validation from document parser selection **Task · High priority · Intermediate** noCV practice brief v5 · BEGRESS-107 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce bounded fetching. Depends on: BEGRESS-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Backend 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 importer trusts a response header and sends arbitrary bytes to the wrong parser. Acceptance criteria - Allowlist supported content types. - Check bounded content signatures where applicable. - Reject disagreement instead of guessing a parser. Implementation constraints - Parsing runs only through the authorized document-processing boundary. Verification - Accept a matching synthetic text document. - Reject mislabeled binary content and unsupported types. Deliverables - Content validation contract. Rollout and recovery: Keep unsupported imports rejected with clear user guidance. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. ### Review policy lifecycle Handle policy changes, exceptions, and operational diagnostics. #### BEGRESS-108 — Revoke destination approval for queued and cached imports **Bug · High priority · Advanced** noCV practice brief v5 · BEGRESS-108 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review policy lifecycle. Depends on: BEGRESS-106, BEGRESS-107. 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. An endpoint is removed from policy but previously queued work still fetches it. Acceptance criteria - Recheck current policy before dispatch. - Bind cached fetch authority to policy revision. - Invalidate revoked destinations without serving stale private content. Implementation constraints - Cached bytes cannot authorize a new network operation. Verification - Dispatch an unchanged approved import. - Revoke the host and deny queued work before connection. Deliverables - Policy revocation handling. Rollout and recovery: Pause affected work and preserve safe operation metadata. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-109 — Assess proxy deployment versus embedded fetch enforcement **Task · High priority · Expert** noCV practice brief v5 · BEGRESS-109 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review policy lifecycle. Depends on: BEGRESS-103, BEGRESS-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Networking 30% · Security 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. The team must decide whether every service implements egress checks or shares a constrained gateway. Acceptance criteria - Compare enforcement consistency, latency, failure domain, and operations burden. - Model bypass risks and explicit provider boundaries. - Choose the smallest design satisfying the scenario. Implementation constraints - Do not add microservices without a demonstrated need; a local module may be sufficient. Verification - Trace an authorized import through the chosen boundary. - Show how direct unapproved network access is prevented in the model. Deliverables - Egress architecture decision record. Rollout and recovery: Keep the gateway unavailable until enforcement and bypass assumptions are verified. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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. #### BEGRESS-110 — Write a destination-exception review with expiry **Chore · Low priority · Foundational** noCV practice brief v5 · BEGRESS-110 · Restricted outbound fetch gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review policy lifecycle. Depends on: BEGRESS-109. Difficulty: Foundational. Estimated focused work: 60 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 temporary import source should not become a permanent wildcard allowlist entry. Acceptance criteria - Require exact destination, owner, reason, and expiry. - Document required negative checks. - Preserve exception history after removal. Implementation constraints - Exceptions cannot disable response or time bounds. Verification - Approve a narrow synthetic exception. - Reject expired and wildcard-wide exceptions. Deliverables - Egress exception guide. Rollout and recovery: Review exceptions before policy publication and remove expired authority. Project prerequisites: Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts. Engineer value: Practice URL interpretation, network policy enforcement, and resource controls. Company value: Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable. 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.