# 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. ## BCONTRACT — Consumer contract compatibility lab A fictional fulfillment API serves a web checkout and warehouse adapter. Provider tests pass while consumers fail on subtle response and error changes. **Field:** Quality engineering. **Suggested stack:** TypeScript, HTTP, JSON Schema. **Engineer value:** Practice executable contracts, meaningful negative tests, and compatibility triage. **Company value:** Expose integration regressions before deployment without requiring every system to run together. **Delivery agreement:** Deliver versioned public contract checks and a local compatibility report. ### Setup prerequisites - Author two small local consumers and one mock provider with versioned synthetic responses. ### Capture expectations Identify consumer behavior that forms a real contract. #### BCONTRACT-101 — Inventory the fields each fulfillment consumer actually reads **Task · Medium priority · Foundational** noCV practice brief v5 · BCONTRACT-101 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture expectations. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. The existing contract copies entire sample responses, making harmless changes fail. Acceptance criteria - List fields and semantics used by each consumer. - Distinguish optional fields from required decisions. - Identify one response field neither consumer needs. Implementation constraints - Use synthetic consumers rather than production traffic. Verification - Trace checkout and warehouse reads. - Remove an unused field without changing the consumer outcome. Deliverables - Consumer expectation inventory. Rollout and recovery: Review scope before creating strict assertions. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-102 — Create isolated provider states for contract examples **Task · High priority · Intermediate** noCV practice brief v5 · BCONTRACT-102 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture expectations. Depends on: BCONTRACT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. Contracts depend on whichever orders happen to exist in a shared test database. Acceptance criteria - Create named states with deterministic synthetic identities. - Reset each state independently. - Reject unrecognized state names instead of selecting a default. Implementation constraints - State setup is accessible only inside the local harness. Verification - Run states in either order. - Request an unknown state and verify no default data leaks. Deliverables - Provider-state fixture harness. Rollout and recovery: Use the isolated harness for new contracts; retire shared mutable fixtures. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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 boundaries Exercise provider changes and error semantics. #### BCONTRACT-103 — Protect decimal quantities from implicit numeric coercion **Bug · High priority · Intermediate** noCV practice brief v5 · BCONTRACT-103 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify boundaries. Depends on: BCONTRACT-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. The warehouse adapter rounds fractional unit quantities after a provider changes strings to numbers. Acceptance criteria - Specify quantity representation and allowed scale. - Reject excess precision and non-finite values. - Verify consumer arithmetic preserves the declared quantity. Implementation constraints - Use exact decimal arithmetic or integer units. Verification - Process a supported fractional quantity. - Reject scientific-notation and overprecision examples where unsupported. Deliverables - Quantity contract regression. Rollout and recovery: Treat representation changes as reviewed compatibility changes. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-104 — Verify unknown enum values do not crash old clients **Task · Medium priority · Advanced** noCV practice brief v5 · BCONTRACT-104 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify boundaries. Depends on: BCONTRACT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. A new fulfillment status reaches a client compiled against the previous enum. Acceptance criteria - Define unknown-status behavior for each consumer. - Preserve the raw value for safe diagnostics. - Avoid treating unknown as delivered or cancelled. Implementation constraints - Unknown states must not trigger irreversible actions. Verification - Handle every documented status. - Feed a future status and verify conservative behavior. Deliverables - Forward-compatible enum checks. Rollout and recovery: Deploy tolerant readers before adding new provider values. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-105 — Test authorization before provider-state response lookup **Bug · High priority · Advanced** noCV practice brief v5 · BCONTRACT-105 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify boundaries. Depends on: BCONTRACT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. A contract fixture returns an order by ID even when the caller belongs to another merchant. Acceptance criteria - Scope reads by authenticated merchant at the repository boundary. - Use non-enumerating denial semantics. - Keep privileged fixture setup unavailable to consumers. Implementation constraints - Contract success must not bypass authorization. Verification - Read an owned order. - Request another merchant's order and compare safe denial behavior. Deliverables - Cross-merchant contract cases. Rollout and recovery: Block compatibility approval when tenant denial regresses. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-106 — Cover retry semantics for conflicts and transient failures **Task · High priority · Advanced** noCV practice brief v5 · BCONTRACT-106 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify boundaries. Depends on: BCONTRACT-103, BCONTRACT-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · API design 30% · Distributed systems 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. Both clients currently retry every failed write, including conflicting requests. Acceptance criteria - Distinguish conflict, validation, and transient errors. - Specify which writes are safely retryable. - Preserve request identity across allowed retries. Implementation constraints - Use a deterministic mock clock and bounded retry count. Verification - Recover from one transient error. - Verify validation and conflicting idempotency reuse are not retried. Deliverables - Error and retry contract suite. Rollout and recovery: Adopt new error handling with the provider behavior unchanged. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-107 — Detect undocumented response changes with focused mutation checks **Task · High priority · Advanced** noCV practice brief v5 · BCONTRACT-107 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify boundaries. Depends on: BCONTRACT-103, BCONTRACT-104, BCONTRACT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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 passing contract may only prove the mock matched itself. Acceptance criteria - Mutate one required field, status, or header per case. - Show each relevant mutation makes a consumer expectation fail. - Record intentionally tolerated mutations separately. Implementation constraints - Mutations target public contract behavior only. Verification - Catch a missing quantity and wrong conflict status. - Tolerate an unrelated additive response property. Deliverables - Contract sensitivity report. Rollout and recovery: Review surviving mutations before trusting the contract gate. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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 evolution Make compatibility decisions and exceptions reviewable. #### BCONTRACT-108 — Design a compatibility gate that handles missing consumers **Task · High priority · Expert** noCV practice brief v5 · BCONTRACT-108 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage evolution. Depends on: BCONTRACT-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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 new provider build is marked compatible because one consumer stopped submitting its contract. Acceptance criteria - Require an explicit supported-consumer inventory. - Distinguish failed, missing, stale, and passed verification. - Define a reviewed exception with owner and expiry. Implementation constraints - Absence of results cannot mean compatibility. Verification - Pass with all supported consumers checked. - Remove or stale one contract and block the gate. Deliverables - Compatibility gate decision record. Rollout and recovery: Start as advisory; enforce once inventory ownership is established. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-109 — Generate a human-readable contract failure explanation **Story · Medium priority · Intermediate** noCV practice brief v5 · BCONTRACT-109 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage evolution. Depends on: BCONTRACT-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. Engineers see a JSON diff but cannot tell which consumer behavior changed. Acceptance criteria - Name the consumer and contract revision. - Show the relevant expected and observed public fields. - Exclude credentials and unrelated payload content. Implementation constraints - Bound output and redact synthetic secret markers. Verification - Explain a changed error status. - Verify oversized payloads and authorization headers are omitted. Deliverables - Failure explanation formatter. Rollout and recovery: Attach explanations to existing failed checks without altering outcomes. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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. #### BCONTRACT-110 — Rehearse retiring an unused consumer contract **Chore · Low priority · Foundational** noCV practice brief v5 · BCONTRACT-110 · Consumer contract compatibility lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage evolution. Depends on: BCONTRACT-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 70% · API design 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 abandoned warehouse client keeps blocking harmless provider changes. Acceptance criteria - Record owner confirmation and supported-version cutoff. - Preserve the retired contract for history. - Remove it from required checks only after the cutoff. Implementation constraints - Do not delete active consumer coverage based solely on low test activity. Verification - Retire a synthetic obsolete consumer. - Verify an active consumer remains required. Deliverables - Contract retirement procedure. Rollout and recovery: Keep the last compatibility report available for rollback investigation. Project prerequisites: Author two small local consumers and one mock provider with versioned synthetic responses. Engineer value: Practice executable contracts, meaningful negative tests, and compatibility triage. Company value: Expose integration regressions before deployment without requiring every system to run together. 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.