# 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. ## BSDKGEN — Deterministic SDK publishing pipeline A fictional partner platform publishes TypeScript clients. Generator upgrades create noisy diffs, occasional runtime mismatches, and uncertainty about which schema was packaged. **Field:** Developer tooling. **Suggested stack:** TypeScript, OpenAPI, Node.js. **Engineer value:** Practice reproducible generation, compatibility reviews, and package provenance. **Company value:** Reduce partner integration surprises with reviewable clients and recoverable releases. **Delivery agreement:** Deliver the local generation and packaging workflow with a compatibility report; publish nothing externally. ### Setup prerequisites - Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. ### Pin inputs Specify schema and generator provenance. #### BSDKGEN-101 — Record the exact inputs behind a generated client **Task · Medium priority · Foundational** noCV practice brief v5 · BSDKGEN-101 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Pin inputs. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. A checked-in client cannot be traced to its schema revision. Acceptance criteria - Record schema digest, generator version, and options. - Keep the manifest stable across machines. - Fail when a required input is missing. Implementation constraints - Avoid absolute paths and timestamps in generated content. Verification - Compare manifests from two directories. - Remove the schema and verify a clear failure. Deliverables - Generation manifest. Rollout and recovery: Introduce manifests before enforcing them; keep the previous complete client. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-102 — Normalize schema ordering without changing semantics **Task · Medium priority · Intermediate** noCV practice brief v5 · BSDKGEN-102 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Pin inputs. Depends on: BSDKGEN-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · API design 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. Reordered schema properties create hundreds of irrelevant review lines. Acceptance criteria - Sort unordered maps deterministically. - Preserve ordered examples and tuple definitions. - Keep references resolvable after normalization. Implementation constraints - Do not remove descriptions or validation constraints. Verification - Compare equivalent reordered schemas. - Detect a changed enum or required field. Deliverables - Schema normalizer. Rollout and recovery: Review semantic diffs before replacing the stored schema. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. ### Generate predictably Produce usable stable clients and visible changes. #### BSDKGEN-103 — Separate transport code from generated resource methods **Task · High priority · Advanced** noCV practice brief v5 · BSDKGEN-103 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Generate predictably. Depends on: BSDKGEN-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · API design 30% · 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. Regeneration overwrites the timeout behavior partners configured manually. Acceptance criteria - Inject a stable transport interface. - Regenerate resource methods without overwriting custom transport. - Pass abort signals and request identifiers consistently. Implementation constraints - Keep credentials out of generated examples. Verification - Regenerate twice and compare output. - Cancel a delayed mock request and verify transport cancellation. Deliverables - Transport boundary and generated client. Rollout and recovery: Retain the existing adapter until contract tests pass. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-104 — Represent nullable and optional fields distinctly in clients **Bug · High priority · Intermediate** noCV practice brief v5 · BSDKGEN-104 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Generate predictably. Depends on: BSDKGEN-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · API design 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 omitted patch field is serialized as null and clears a partner record. Acceptance criteria - Model omitted and explicit null independently. - Omit undefined values during serialization. - Preserve null only where the schema allows it. Implementation constraints - Avoid broad type assertions that erase schema distinctions. Verification - Patch one field without clearing another. - Reject null for a non-nullable field. Deliverables - Serialization correction. Rollout and recovery: Release as a reviewed compatibility fix; restore the prior artifact if unrelated payloads change. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-105 — Generate errors that preserve safe machine-readable details **Story · Medium priority · Intermediate** noCV practice brief v5 · BSDKGEN-105 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Generate predictably. Depends on: BSDKGEN-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Developer tooling 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. Client users currently parse human error messages to detect conflicts. Acceptance criteria - Expose status, problem type, and safe request ID. - Handle non-JSON failures without crashing the parser. - Exclude authorization headers from error objects. Implementation constraints - Bound retained response-body bytes. Verification - Parse a conflict and a text gateway error. - Verify oversized and secret-bearing responses stay bounded and sanitized. Deliverables - Typed error mapping. Rollout and recovery: Keep message text compatible where practical; document structured fields. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-106 — Detect breaking schema changes before rebuilding packages **Task · High priority · Advanced** noCV practice brief v5 · BSDKGEN-106 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Generate predictably. Depends on: BSDKGEN-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Developer tooling 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 required request property was added without a major-version discussion. Acceptance criteria - Classify request and response changes separately. - Flag removed operations and narrowed accepted values. - Require an explicit reviewed explanation for allowed exceptions. Implementation constraints - Do not treat every additive response field as breaking. Verification - Detect a required-input addition. - Accept a documented additive field and reject an expired exception. Deliverables - Compatibility diff command. Rollout and recovery: Run advisory first; enforce after reviewing known baseline exceptions. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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 packages Exercise installation, compatibility, and recovery locally. #### BSDKGEN-107 — Test a packaged client from a clean consumer directory **Task · High priority · Intermediate** noCV practice brief v5 · BSDKGEN-107 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify packages. Depends on: BSDKGEN-104, BSDKGEN-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Quality 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. The client works in the monorepo but its published archive omits runtime files. Acceptance criteria - Install the local archive outside the workspace. - Exercise ESM imports and declared type exports. - Verify the archive excludes fixtures and credentials. Implementation constraints - Use local archives; no public publication or real account required. Verification - Run a request against the mock server. - Remove an exported file and detect the package failure. Deliverables - Clean-consumer smoke check. Rollout and recovery: Gate local release candidates on archive validation. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-108 — Make generated examples compile against their advertised version **Chore · Medium priority · Foundational** noCV practice brief v5 · BSDKGEN-108 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify packages. Depends on: BSDKGEN-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Quality 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. Documentation snippets refer to methods removed two releases ago. Acceptance criteria - Compile examples using the packaged client. - Pin examples to a release identifier. - Show credential placeholders without usable secrets. Implementation constraints - Examples must call the local mock service only. Verification - Run the basic read and paginated examples. - Detect a snippet using a removed method. Deliverables - Executable example suite. Rollout and recovery: Update examples together with packages; retain versioned previous examples. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-109 — Design a release matrix for old servers and new clients **Task · High priority · Expert** noCV practice brief v5 · BSDKGEN-109 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify packages. Depends on: BSDKGEN-106, BSDKGEN-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 40% · API design 30% · Quality 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. Partners upgrade clients and servers at different times, so latest-against-latest testing leaves a compatibility gap. Acceptance criteria - Declare supported client/server pairs and exclusions. - Run representative operations against each local server version. - Document unknown behavior rather than marking untested pairs supported. Implementation constraints - Bound the matrix to two client and two server versions. Verification - Exercise a supported mixed-version pair. - Expose an incompatible removed operation as an expected documented failure. Deliverables - Compatibility matrix and release recommendation. Rollout and recovery: Promote only tested pairs; preserve previous client artifacts and migration instructions. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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. #### BSDKGEN-110 — Rehearse replacing a defective SDK archive locally **Task · Medium priority · Advanced** noCV practice brief v5 · BSDKGEN-110 · Deterministic SDK publishing pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify packages. Depends on: BSDKGEN-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Platform 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. A release candidate accidentally retries non-idempotent requests, and maintainers need a recovery procedure. Acceptance criteria - Mark the defective local version as withdrawn in the index. - Publish a distinct corrected local version without rewriting archives. - Verify consumers can pin the last known usable version. Implementation constraints - Never overwrite a versioned artifact. Verification - Install the corrected package and previous usable package. - Ensure the withdrawn version remains identifiable for diagnosis. Deliverables - Local recovery rehearsal. Rollout and recovery: Document withdrawal and pinning before external publication is ever considered. Project prerequisites: Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files. Engineer value: Practice reproducible generation, compatibility reviews, and package provenance. Company value: Reduce partner integration surprises with reviewable clients and recoverable releases. 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.