# 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. ## BNETDIAG — Dual-stack network troubleshooting kit A fictional desktop sync client works on one office network but intermittently fails on another. Application retries hide whether DNS, IPv6, or transport limits are responsible. **Field:** Networking. **Suggested stack:** TypeScript, Packet trace fixtures, HTTP. **Engineer value:** Practice layered network diagnosis and reproducible troubleshooting. **Company value:** Produce precise support diagnostics that distinguish application defects from connectivity conditions. **Delivery agreement:** Deliver an offline trace analyzer and local diagnostic workflow with explicit platform limits. ### Setup prerequisites - Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. ### Observe network stages Normalize safe diagnostics and establish controlled cases. #### BNETDIAG-101 — Define a sanitized connection-attempt diagnostic record **Task · Medium priority · Foundational** noCV practice brief v5 · BNETDIAG-101 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe network stages. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Privacy engineering 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. Support receives raw traces containing request payloads and personal hostnames. Acceptance criteria - Record stage, address family, duration, and safe error category. - Exclude payloads, credentials, and user identifiers. - Mark unavailable measurements explicitly. Implementation constraints - Use synthetic traces only. Verification - Represent a successful local connection. - Scan a seeded sensitive trace and verify excluded fields. Deliverables - Diagnostic schema. Rollout and recovery: Adopt minimal records before collecting more detail. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-102 — Correlate DNS answers with selected connection addresses **Task · Medium priority · Intermediate** noCV practice brief v5 · BNETDIAG-102 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe network stages. Depends on: BNETDIAG-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Site reliability 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 client log shows resolved addresses but not which one it attempted. Acceptance criteria - Bind attempts to their resolution result identity. - Record selected family and address classification. - Detect attempts outside the recorded answer set. Implementation constraints - Store only approved synthetic addresses. Verification - Trace selection from a dual-stack answer. - Flag a connection address absent from the result. Deliverables - Resolution-to-connection correlation. Rollout and recovery: Enable in local diagnostic mode first. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. ### Diagnose failure families Separate resolution, address selection, and transport behavior. #### BNETDIAG-103 — Implement bounded address-family fallback in the client fixture **Task · High priority · Advanced** noCV practice brief v5 · BNETDIAG-103 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Diagnose failure families. Depends on: BNETDIAG-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Performance engineering 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 unreachable IPv6 address delays a working IPv4 connection until a long timeout. Acceptance criteria - Race or sequence families under a declared bounded policy. - Cancel losing attempts and release sockets. - Preserve meaningful final errors when both fail. Implementation constraints - Use deterministic timers and loopback doubles. Verification - Reach IPv4 when the IPv6 fixture stalls. - Fail both families without leaked attempts. Deliverables - Address-family fallback policy. Rollout and recovery: Compare with the previous policy under identical traces before adoption. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-104 — Detect a packet-size black-hole pattern in synthetic traces **Task · High priority · Advanced** noCV practice brief v5 · BNETDIAG-104 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Diagnose failure families. Depends on: BNETDIAG-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Small requests succeed while larger uploads stall without an application response. Acceptance criteria - Identify the declared retransmission and size pattern. - Distinguish a hypothesis from confirmed cause. - Suggest one bounded local verification step. Implementation constraints - Do not infer path MTU from an arbitrary single failed request. Verification - Analyze a synthetic size-dependent failure. - Keep a generic timeout trace inconclusive. Deliverables - Packet-size diagnostic rule. Rollout and recovery: Use advisory findings only; require the verification step before configuration changes. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-105 — Separate proxy interception from origin TLS failure **Task · High priority · Advanced** noCV practice brief v5 · BNETDIAG-105 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Diagnose failure families. Depends on: BNETDIAG-101, BNETDIAG-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Security 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. Certificate failures on one network are blamed on the origin service. Acceptance criteria - Compare expected peer identity with observed chain metadata. - Record proxy configuration source safely. - Keep unknown interception explicitly unresolved. Implementation constraints - Never recommend disabling TLS verification. Verification - Identify the modeled local proxy certificate. - Distinguish a wrong-origin certificate from an unreachable origin. Deliverables - TLS path diagnostic. Rollout and recovery: Keep failed connections closed while investigating trust configuration. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-106 — Detect split-horizon DNS differences without leaking private zones **Task · Medium priority · Intermediate** noCV practice brief v5 · BNETDIAG-106 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Diagnose failure families. Depends on: BNETDIAG-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 60% · Privacy 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 same service name maps differently in two authorized network contexts. Acceptance criteria - Compare labeled resolver-context results. - Report family, record class, and policy differences. - Redact private names from shareable output. Implementation constraints - Use synthetic zone data and no external DNS queries. Verification - Compare two intentional split-horizon fixtures. - Detect an unexpected public-context answer. Deliverables - Resolver comparison report. Rollout and recovery: Review private results locally; share only the sanitized projection. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-107 — Bound diagnostic retries independently of application retries **Bug · High priority · Intermediate** noCV practice brief v5 · BNETDIAG-107 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Diagnose failure families. Depends on: BNETDIAG-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Developer tooling 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. Running the diagnostic tool triggers the client's normal retry loop and floods the local test endpoint. Acceptance criteria - Use a separate fixed diagnostic attempt budget. - Disable application retry chaining. - Stop immediately on explicit cancellation. Implementation constraints - Targets must match the authorized local allowlist. Verification - Run the declared number of attempts. - Cancel or supply an unapproved target and verify no further connections. Deliverables - Diagnostic execution guard. Rollout and recovery: Default to offline analysis; require explicit local target configuration. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. ### Make diagnosis repeatable Evaluate fallback and produce safe support artifacts. #### BNETDIAG-108 — Compare fallback latency without hiding failed attempts **Task · High priority · Expert** noCV practice brief v5 · BNETDIAG-108 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make diagnosis repeatable. Depends on: BNETDIAG-103, BNETDIAG-104, BNETDIAG-105, BNETDIAG-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. A new connection policy appears faster because the report excludes failed IPv6 attempts. Acceptance criteria - Use identical network-condition traces for both policies. - Report end-to-end success, failure, latency, and extra connection work. - Document simulated conditions and unverified real-network behavior. Implementation constraints - Do not rank policies solely by successful median latency. Verification - Compare healthy and one-family-failing cases. - Expose additional connection cost and dual-family failure behavior. Deliverables - Fallback policy assessment. Rollout and recovery: Adopt only for the modeled conditions and retain a configuration rollback. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-109 — Generate a shareable network diagnosis bundle **Story · Medium priority · Intermediate** noCV practice brief v5 · BNETDIAG-109 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make diagnosis repeatable. Depends on: BNETDIAG-106, BNETDIAG-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Networking 30% · Developer tooling 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. Support needs a useful report without raw packet payloads. Acceptance criteria - Include tool version, scenario, and safe stage observations. - Link findings to sanitized trace identities. - Bound bundle size and reject forbidden fields. Implementation constraints - Keep original synthetic trace data separate. Verification - Build a bundle for a known local failure. - Seed credentials and verify they cannot enter the bundle. Deliverables - Sanitized diagnosis bundle. Rollout and recovery: Review the bundle schema before any real support collection. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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. #### BNETDIAG-110 — Write a troubleshooting decision tree with inconclusive exits **Chore · Low priority · Foundational** noCV practice brief v5 · BNETDIAG-110 · Dual-stack network troubleshooting kit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make diagnosis repeatable. Depends on: BNETDIAG-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 70% · Site reliability 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. Support scripts force every connection failure into a known cause. Acceptance criteria - Separate DNS, connect, TLS, and HTTP branches. - Include evidence needed for each next step. - Provide an inconclusive result when observations are insufficient. Implementation constraints - Every active check stays inside the authorized local lab. Verification - Follow the tree for a modeled family failure. - Stop inconclusively for missing telemetry. Deliverables - Network troubleshooting guide. Rollout and recovery: Keep the guide tied to implemented diagnostics and declared limits. Project prerequisites: Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic. Engineer value: Practice layered network diagnosis and reproducible troubleshooting. Company value: Produce precise support diagnostics that distinguish application defects from connectivity conditions. 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.