# 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. ## BILL — Close the billing reconciliation gap A fictional subscription service invoices in USD and EUR. Finance currently compares a payment-provider CSV with database exports; late refunds and retried imports make the monthly close unreliable. Work on synthetic ledger entries only. **Field:** Backend. **Suggested stack:** TypeScript, NestJS, PostgreSQL, BullMQ. **Engineer value:** Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. **Company value:** Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. **Delivery agreement:** Ten bounded tickets over three phases; choose an individual issue or deliver the complete synthetic reconciliation service with a finance handoff. ### Setup prerequisites - REST APIs - SQL transactions - Integer money representation ### Reliable intake Make settlement imports inspectable and repeatable. #### BILL-101 — Reject ambiguous settlement amounts before import **Task · High priority · Foundational** noCV practice brief v5 · BILL-101 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Finance received a row containing 12,34 EUR beside rows using 12.34. The importer currently guesses the separator and silently books the wrong amount. Acceptance criteria - Accept documented decimal-dot amounts and convert them to integer minor units. - Reject mixed separators, excess precision, and unsupported currency codes with row numbers. - A rejected file creates no settlement rows. Implementation constraints - The exercise supports USD and EUR, both with two minor digits; do not use floating-point arithmetic. Verification - Import 0.01, 12.34, and a negative refund amount exactly. - Reject 12,34 and 1.005 without partial writes. Deliverables - Settlement input contract and parser regression fixtures Rollout and recovery: Run validation against saved synthetic files before enabling persistence; revert the parser behind the importer flag. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-102 — Make repeated settlement uploads converge on one batch **Bug · High priority · Intermediate** noCV practice brief v5 · BILL-102 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: BILL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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. An upload times out after committing. Finance retries the same file and sees every payout twice. Two browser tabs can also submit it together. Acceptance criteria - Identical bytes within one merchant resolve to the same batch identity. - Concurrent submissions create one committed batch and one set of rows. - A different file with a reused client request key returns a conflict. Implementation constraints - Scope deduplication to the merchant and retain the original content hash. Verification - Submit the same file concurrently and compare persisted counts. - Reuse a request key with a changed amount and assert conflict. Deliverables - Idempotent import command and concurrency reproduction Rollout and recovery: Enable for one synthetic merchant; rollback routing while preserving committed batch identities. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-103 — Add a finance-readable import rejection report **Story · Medium priority · Foundational** noCV practice brief v5 · BILL-103 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: BILL-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Backend 30% · Security 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 currently pastes a stack trace into the finance channel when a file fails. Finance needs row-level corrections without exposure to provider tokens or infrastructure details. Acceptance criteria - Report row number, field, stable reason code, and a plain-English correction hint. - Cap the report at 100 errors and state the total omitted count. - Require merchant authorization before downloading a report. Implementation constraints - Do not echo complete source rows or payment instrument data. Verification - Show distinct corrections for missing reference and invalid currency. - Deny another merchant and confirm a token-like cell is absent. Deliverables - Bounded rejection report endpoint and example response Rollout and recovery: Expose reports for new imports first; disable downloads without deleting import audit records. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. ### Explain the balance Match settlements and preserve unresolved differences. #### BILL-104 — Match settlement lines without combining currencies **Story · High priority · Intermediate** noCV practice brief v5 · BILL-104 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-102. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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. Provider reference pay_204 exists on a EUR invoice, but a malformed USD settlement row shares the reference. The current join marks the invoice paid. Acceptance criteria - Match only within merchant, reference, and currency boundaries. - Represent matched, unmatched, and conflicting lines separately. - Calculate batch totals independently for each currency. Implementation constraints - A reference match with a currency mismatch is a conflict, never an exchange-rate conversion. Verification - Match a complete EUR batch to its invoices. - Keep same-reference USD and cross-merchant rows unresolved. Deliverables - Reconciliation query and currency-conflict fixture Rollout and recovery: Compare dry-run classifications with the synthetic finance baseline before switching reports. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-105 — Carry partial refunds across settlement days **Bug · High priority · Advanced** noCV practice brief v5 · BILL-105 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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 100.00 charge receives refunds of 20.00 on Monday and 15.00 on Thursday. The report subtracts only the latest refund, overstating net revenue by 20.00. Acceptance criteria - Net the charge against all distinct posted refunds in the selected cutoff. - Keep pending refunds visible but outside settled totals. - Flag cumulative refunds above the captured amount without silently clipping them. Implementation constraints - Preserve each provider refund identity and posting timestamp; never overwrite the original charge. Verification - Assert net 65.00 after both refunds and 80.00 at Monday cutoff. - Replay a refund and inject an excess refund; check deduplication and conflict. Deliverables - Append-only refund matching change and cutoff examples Rollout and recovery: Recompute a shadow report for one month; retain the previous report revision for comparison. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-106 — Record discrepancy decisions without editing source entries **Story · Medium priority · Intermediate** noCV practice brief v5 · BILL-106 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Security 20% · Database 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. Finance has confirmed that a 0.03 difference is a provider fee adjustment. They need to explain it without changing the settlement CSV or marking every mismatch resolved automatically. Acceptance criteria - An authorized reviewer can append a reason and decision to one discrepancy. - Concurrent decisions against the same revision produce one success and one conflict. - Reports show the original difference and complete decision history. Implementation constraints - A decision changes review state, not the immutable amounts or provider provenance. Verification - Resolve and reopen a discrepancy while preserving both decisions. - Reject stale revisions and an actor lacking finance-review permission. Deliverables - Discrepancy decision API and history contract Rollout and recovery: Gate the command to a test finance role; disable writes while keeping history readable on rollback. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. ### Close and recover Make runs reproducible and safe to operate. #### BILL-107 — Freeze a close report against a reproducible cutoff **Task · High priority · Expert** noCV practice brief v5 · BILL-107 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-105, BILL-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Backend 40% · Data 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. The April report changed after a late settlement arrived in May. Finance needs to explain what was known at close while still showing corrections in a new revision. Acceptance criteria - Freeze source identities, cutoff, calculation version, and report hash for a close revision. - Later imports cannot mutate the frozen report. - A correction creates a new linked revision with explicit differences. Implementation constraints - Distinguish provider effective time from system receipt time; document which governs inclusion. Verification - Regenerate a frozen revision and compare canonical hashes. - Import a backdated settlement after close and prove the old revision is unchanged. Deliverables - Versioned close report design, implementation, and correction walkthrough Rollout and recovery: Introduce revisioned closes in parallel with the current export; retain old readers until reconciliation agrees. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-108 — Recover an import after the queue acknowledgement is lost **Bug · High priority · Advanced** noCV practice brief v5 · BILL-108 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-102, BILL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Backend 30% · Database 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. The database commits an accepted batch and the API process exits before enqueueing reconciliation. The UI remains on Processing until someone runs SQL manually. Acceptance criteria - Accepted batch and dispatch intent commit atomically. - Restarted dispatch delivers pending work with a deterministic job identity. - Repeated delivery produces the same reconciliation result without duplicate entries. Implementation constraints - Keep provider payloads out of queue metadata; use a durable batch identifier. Verification - Interrupt after database commit and recover through the dispatcher. - Deliver the same job twice and compare the ledger and audit counts. Deliverables - Transactional dispatch path and crash-recovery reproduction Rollout and recovery: Start dispatch in observe mode, then enable pending batches; pause dispatch to rollback without losing intent. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-109 — Alert when a merchant close is blocked by stale imports **Chore · Medium priority · Intermediate** noCV practice brief v5 · BILL-109 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Operations sees a healthy API while three accepted imports have made no progress for 45 minutes. Finance discovers the blockage at the end of the day. Acceptance criteria - Expose accepted-to-completed age and counts by bounded processing state. - Alert after the oldest accepted batch exceeds 15 minutes for two observations. - The runbook identifies the batch safely and distinguishes retryable from invalid input failures. Implementation constraints - Avoid merchant IDs, file names, and references as metric labels. Verification - Advance a controlled clock to trigger a stale-batch alert. - Confirm a rejected file does not trigger queue-lag paging. Deliverables - Metrics, alert rule, and import recovery runbook Rollout and recovery: Observe alerts for one synthetic close cycle before enabling paging; disable the rule if it pages on rejected files. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-110 — Paginate the discrepancy export during a large close **Task · Medium priority · Advanced** noCV practice brief v5 · BILL-110 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Backend 40% · 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. A synthetic close with 250,000 discrepancies exhausts API memory because the export loads every row. Finance also receives spreadsheet formulas when a reference begins with an equals sign. Acceptance criteria - Stream a stable report revision in bounded pages without omissions or duplicate rows. - Neutralize spreadsheet formula prefixes in text cells. - Abort export promptly on client disconnect and preserve authorization on resume. Implementation constraints - Use a repeatable 250,000-row synthetic benchmark and report peak memory rather than assuming scalability. Verification - Compare streamed row identities with the frozen report count. - Export malicious-looking references and cancel halfway through; check escaping and cleanup. Deliverables - Bounded CSV export and benchmark report Rollout and recovery: Offer the streamed export alongside the old limit; rollback the route while retaining report revisions. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. ## STOCK — Stop overselling the last warehouse unit A fictional retailer sells bicycle parts from East and West warehouses. Cart reservations last ten minutes, payment callbacks arrive late, and warehouse counts occasionally need correction. The exercise has no real orders or payment integration. **Field:** Backend. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Redis. **Engineer value:** Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. **Company value:** Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. **Delivery agreement:** Three phases of ten reviewable issues, from a stock lookup to a concurrency and recovery handoff using synthetic orders. ### Setup prerequisites - Relational modeling - Concurrent API requests - State transitions ### Stock contract Define quantities and safe reservation boundaries. #### STOCK-101 — Return available stock for a specific warehouse **Story · Medium priority · Foundational** noCV practice brief v5 · STOCK-101 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stock contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database engineering 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. Product pages display total stock across both warehouses, although East cannot ship West inventory. A customer sees four brake kits available when their shipping warehouse has none. Acceptance criteria - Return on-hand, reserved, and available quantities for the selected warehouse and SKU. - Unknown SKUs return a documented not-found response. - Reject warehouse IDs outside the caller's retailer scope. Implementation constraints - Available means on-hand minus active reservations; do not silently substitute another warehouse. Verification - Read the same SKU from East and West with different balances. - Deny a foreign warehouse and reject an empty SKU. Deliverables - Warehouse stock endpoint and response examples Rollout and recovery: Switch the synthetic product page lookup by warehouse behind a flag; restore the earlier lookup if contract errors rise. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-102 — Define legal reservation transitions **Task · High priority · Foundational** noCV practice brief v5 · STOCK-102 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stock contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Pattern topics: State (compare). State — Compare: Compare a transition table with State objects for the reservation lifecycle. Legal transitions and terminal-state protection matter more than the number of classes. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A support script changed a paid reservation from COMMITTED back to ACTIVE. Inventory is now counted twice because each endpoint writes status directly. Acceptance criteria - Allow ACTIVE to become COMMITTED, RELEASED, or EXPIRED through named operations. - Terminal reservations cannot return to ACTIVE. - Each successful transition records actor, reason, and timestamp. Implementation constraints - Keep transition validation in the domain/service boundary, including maintenance callers. Verification - Exercise all three allowed exits from ACTIVE. - Attempt every terminal-to-active transition and assert no quantity or audit mutation. Deliverables - Reservation transition table and domain operations Rollout and recovery: Route existing writes through the new operations first; rollback callers without reopening terminal records. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. ### Checkout under contention Handle retries, timeouts, and allocations consistently. #### STOCK-103 — Reserve the last unit atomically **Bug · Urgent priority · Advanced** noCV practice brief v5 · STOCK-103 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-101, STOCK-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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. Two checkouts both read one remaining wheelset before either writes a reservation. Both succeed, leaving the warehouse with available stock of minus one. Acceptance criteria - At most one of two concurrent requests for the last unit succeeds. - Availability never drops below zero for committed reservation transactions. - An insufficient-stock failure creates neither a reservation nor an audit success. Implementation constraints - The database must enforce correctness when requests arrive at different API processes. Verification - Run overlapping reservations against one unit and inspect final state. - Inject a failure before commit and prove the available quantity is restored. Deliverables - Atomic reservation path and deterministic race reproduction Rollout and recovery: Canary with one synthetic SKU under contention; disable reservation writes if the invariant monitor fails. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-104 — Replay checkout retries without extending a hold **Bug · High priority · Intermediate** noCV practice brief v5 · STOCK-104 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. A flaky mobile connection retries the reserve call every minute. Each retry adds another ten minutes to the hold and can change the requested quantity. Acceptance criteria - The same order request replays the original reservation and expiry. - Changing quantity or warehouse under the same request key returns conflict. - An expired reservation remains expired when the request is replayed. Implementation constraints - Bind the request identity to retailer and order; a replay is not a renewal. Verification - Retry after nine minutes and assert the original expiry remains. - Replay with changed quantity and replay after expiry; inspect both responses. Deliverables - Reservation idempotency contract and time-controlled examples Rollout and recovery: Enable replay behavior for new keys; retain legacy key interpretation until outstanding holds expire. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-105 — Decide the winner when payment and expiry arrive together **Task · High priority · Expert** noCV practice brief v5 · STOCK-105 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Distributed systems 30% · Database 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. Payment confirmation and the expiry sweeper reach reservation R-42 at the same instant. Today both handlers succeed and a paid order loses its stock. Acceptance criteria - Document one deadline rule using server time and apply it in both handlers. - Exactly one terminal transition wins under concurrency. - A payment arriving after a lost hold enters an explicit exception path without reserving unavailable stock. Implementation constraints - Payment success alone does not authorize negative stock; retain callback identity for replay. Verification - Exercise callback just before, at, and just after the deadline. - Run callback and sweeper concurrently, then replay both and inspect one terminal audit. Deliverables - Deadline decision record, race tests, and late-payment exception contract Rollout and recovery: Shadow-classify deadline decisions first; rollback new routing while preserving terminal decisions already recorded. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-106 — Reserve a multi-line order without partial holds **Story · High priority · Advanced** noCV practice brief v5 · STOCK-106 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Checkout under contention. Depends on: STOCK-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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 order for a cassette and chain reserves the cassette, then fails on the chain. The abandoned partial hold blocks another buyer for ten minutes. Acceptance criteria - Reserve all requested lines or none within one warehouse. - Combine repeated SKU lines before checking stock. - Concurrent orders listing SKUs in opposite orders finish or return bounded retryable failures. Implementation constraints - Set a maximum of 50 distinct SKUs per request and define deterministic acquisition order. Verification - Reserve two available lines and verify both holds. - Fail the second line and run opposite-order concurrent carts; check no partial state. Deliverables - Atomic basket reservation operation and deadlock exercise Rollout and recovery: Opt in synthetic multi-line carts; fall back to rejecting whole baskets if contention exceeds the agreed budget. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. ### Warehouse operations Introduce corrections and operational visibility without corrupting reservations. #### STOCK-107 — Apply a stock count correction with an explicit shortage **Story · High priority · Intermediate** noCV practice brief v5 · STOCK-107 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-102, STOCK-103. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 80% · 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. A warehouse count finds two damaged lights while three lights are reserved. Operations needs to record the loss without silently cancelling customer holds. Acceptance criteria - Append an authorized adjustment with reason and counted quantity. - Represent a shortage when active reservations exceed the corrected on-hand quantity. - Block new holds during a shortage while preserving existing reservation history. Implementation constraints - An inventory correction is not permission to cancel a paid allocation. Verification - Correct an unreserved SKU and inspect the new available balance. - Create a shortage and assert existing holds survive while new requests fail. Deliverables - Stock adjustment command and shortage response contract Rollout and recovery: Limit adjustments to a test warehouse role; reverse mistakes through a compensating adjustment. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-108 — Split existing stock rows by warehouse without a write outage **Chore · High priority · Expert** noCV practice brief v5 · STOCK-108 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-101, STOCK-103. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · Platform 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 old table has one quantity per SKU. The East/West launch needs a warehouse key, but a one-shot table rewrite blocks checkout on the large synthetic inventory fixture. Acceptance criteria - Provide expand, backfill, validation, and contract steps with explicit compatibility windows. - Backfill is resumable and preserves total on-hand quantities. - Demonstrate old and new application versions coexist during the supported migration window. Implementation constraints - Define the mapping of legacy stock to East before backfill; never infer a warehouse from a SKU. Verification - Interrupt the backfill and resume without duplicate inventory. - Run reservation traffic during migration and test rollback before the contract step. Deliverables - Versioned migration set and measured lock-duration report Rollout and recovery: Use the documented expand/backfill/switch sequence; prohibit old-version rollback after incompatible cleanup. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-109 — Invalidate availability cache after committed stock changes **Bug · Medium priority · Intermediate** noCV practice brief v5 · STOCK-109 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Distributed systems 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. The product page shows an old available count for five minutes after a warehouse adjustment. A failed adjustment also evicts unrelated retailers' cached stock. Acceptance criteria - Invalidate only the retailer, warehouse, and SKU affected by a committed change. - A rolled-back transaction emits no successful invalidation event. - Reservation correctness remains database-backed when the cache is stale or unavailable. Implementation constraints - The cache is a display optimization and cannot authorize a hold. Verification - Apply an adjustment and observe the next lookup refresh. - Rollback an adjustment and disable Redis; check scope and successful authoritative reads. Deliverables - Scoped cache invalidation and stale-read behavior notes Rollout and recovery: Reduce cache lifetime before enabling invalidation; bypass the cache if refresh failures rise. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. #### STOCK-110 — Give support a safe reservation incident view **Task · Medium priority · Foundational** noCV practice brief v5 · STOCK-110 · Stop overselling the last warehouse unit Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Warehouse operations. Depends on: STOCK-105, STOCK-107. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Security 30% · Privacy 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. Support needs to explain why an order lost its hold. The current workaround is database access that exposes customer addresses and permits accidental stock edits. Acceptance criteria - Show reservation transitions, expiry, warehouse, and exception reason for one authorized order. - Exclude addresses, payment payloads, and write controls. - Distinguish a late payment exception from a normal expiry in readable text. Implementation constraints - The view is diagnostic only; corrective actions remain separate audited commands. Verification - Inspect committed, expired, and shortage examples. - Deny another retailer and assert sensitive fields are absent. Deliverables - Support projection and a three-case incident walkthrough Rollout and recovery: Grant read access to the synthetic support role; revoke the route permission to rollback. Project prerequisites: Relational modeling Concurrent API requests State transitions Engineer value: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair. Company value: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes. 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. ## PIPE — Make parcel tracking survive messy carrier events A fictional delivery marketplace receives JSON batches from three carriers. One uses local timestamps, another retries whole batches, and a third corrects delivery scans. Customer support needs a stable timeline rather than the last payload received. **Field:** Data engineering. **Suggested stack:** TypeScript, PostgreSQL, BullMQ, S3-compatible storage. **Engineer value:** Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. **Company value:** Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. **Delivery agreement:** Ten tickets in three phases; hand off synthetic carrier fixtures, a replay procedure, and a support-readable tracking projection. ### Setup prerequisites - JSON schema validation - SQL queries - Event-time concepts ### Receive and quarantine Keep valid events and explain rejected input. #### PIPE-101 — Validate carrier events without discarding a whole batch **Task · High priority · Foundational** noCV practice brief v5 · PIPE-101 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. A 200-event batch contains one scan with an empty parcel reference. The importer rejects all 200, leaving valid deliveries invisible until the next carrier export. Acceptance criteria - Classify each row as accepted or rejected with a source position. - Require carrier event ID, parcel reference, event code, and timestamp. - Accepted and rejected counts sum to the received count. Implementation constraints - Publish the partial-acceptance contract; never silently drop malformed rows. Verification - Process 199 valid rows and one malformed row with exact counts. - Reject oversized batches and invalid JSON without accepted events. Deliverables - Batch validation contract and mixed-validity fixtures Rollout and recovery: Enable partial acceptance for one synthetic carrier; retain rejection reports if the route is disabled. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-102 — Attach source lineage to every accepted scan **Chore · Medium priority · Foundational** noCV practice brief v5 · PIPE-102 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: PIPE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · Storage 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. Support found a delivery scan that neither carrier recognizes. The normalized table contains no batch hash, row position, or parser version to trace its origin. Acceptance criteria - Store batch hash, row position, carrier identity, receipt time, and parser version. - Link normalized records to a bounded source artifact reference. - Restrict artifact retrieval to ingest support permission. Implementation constraints - Use synthetic data; do not copy full payloads into logs. Verification - Trace two accepted rows to their exact source positions. - Deny a tracking viewer direct source-artifact access. Deliverables - Lineage migration and trace example Rollout and recovery: Populate new imports first and mark untraceable legacy rows explicitly. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-103 — Deduplicate carrier retries and surface changed duplicates **Bug · High priority · Intermediate** noCV practice brief v5 · PIPE-103 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: PIPE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Database 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. Carrier Cedar retries yesterday's batch. Most event IDs are identical, but one delivery timestamp changed from 14:03 to 14:30 and is overwritten silently. Acceptance criteria - Identical carrier-scoped event IDs and content replay without duplicate scans. - Changed content under an existing ID enters a conflict record. - Concurrent duplicate imports converge to one accepted event. Implementation constraints - An event ID from another carrier is a separate identity. Verification - Replay the batch twice and compare accepted counts. - Submit changed content and concurrent duplicates; inspect originals and conflicts. Deliverables - Deduplication constraint and conflict handling contract Rollout and recovery: Observe duplicate classifications before enforcement; preserve originals if conflict routing is rolled back. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. ### Build the tracking timeline Resolve time, order, and corrections explicitly. #### PIPE-104 — Stop interpreting offset-free scans as server-local time **Bug · High priority · Advanced** noCV practice brief v5 · PIPE-104 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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 carrier sends 2025-11-02 01:30 in its configured New York time zone. The importer guesses one occurrence during the clock change and displays delivery before pickup. Acceptance criteria - Normalize explicit-offset timestamps to UTC. - Quarantine ambiguous or nonexistent local times instead of guessing. - Preserve original timestamp text and normalization policy version. Implementation constraints - Use explicit carrier time-zone configuration; process time zone cannot define event meaning. Verification - Normalize equivalent UTC and offset timestamps to one instant. - Quarantine repeated-hour and skipped-hour local timestamps. Deliverables - Timestamp normalization policy and clock-change fixtures Rollout and recovery: Shadow-normalize historical fixtures and review differences before switching timeline timestamps. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-105 — Keep a late pickup scan from undoing delivered status **Bug · High priority · Intermediate** noCV practice brief v5 · PIPE-105 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-103, PIPE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · 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. A DELIVERED scan arrives at 16:00, followed by a delayed PICKED_UP scan from 08:00. The tracking card switches back to In transit because it uses receipt order. Acceptance criteria - Build the timeline from event time with a documented deterministic tie-breaker. - Retain late scans without regressing current delivery state. - Represent inconsistent event sequences with a visible anomaly reason. Implementation constraints - Receipt time remains diagnostic information, not a substitute for event time. Verification - Import pickup and delivery in both arrival orders and compare projections. - Add a pickup dated after delivery and inspect the anomaly. Deliverables - Tracking projection and out-of-order fixtures Rollout and recovery: Compare projections in a shadow table; switch reads after reviewing differences. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-106 — Apply an explicit carrier correction without erasing the scan **Story · High priority · Advanced** noCV practice brief v5 · PIPE-106 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. A driver scanned the wrong parcel as delivered. The carrier now sends corrections referencing the original scan; support must see why Delivered became In transit. Acceptance criteria - Require a same-carrier, same-parcel target event. - Keep the original scan and append the correction relationship. - Recompute the projection and expose the withdrawn delivery scan. Implementation constraints - Missing targets become pending references with bounded retry, never permission to delete arbitrary events. Verification - Apply a valid delivery withdrawal and inspect history and state. - Reject a cross-parcel target and resolve a target that arrives later. Deliverables - Correction contract and deferred-reference recovery Rollout and recovery: Enable the configured correction-capable carrier; retain history if projection readers are rolled back. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. ### Replay and monitor Repair data safely and detect silent ingestion gaps. #### PIPE-107 — Replay a parser fix into a new projection generation **Task · High priority · Expert** noCV practice brief v5 · PIPE-107 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Distributed systems 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. Parser v3 mislabeled ARRIVED_AT_DEPOT as DELIVERED. Operations needs to rebuild 100,000 synthetic scans while fresh batches continue arriving. Acceptance criteria - Replay immutable sources into an isolated projection generation. - Capture a high-water mark and include arrivals through the documented cutover boundary. - Switch readers atomically only after counts and anomaly checks pass. Implementation constraints - Record parser and projection versions; rebuilding cannot mutate sources. Verification - Replay twice and compare deterministic output hashes. - Interrupt replay and add events during catch-up; prove no cutover gaps. Deliverables - Replay command, generation cutover, and recovery runbook Rollout and recovery: Keep the previous generation readable and revert its pointer if comparison fails. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-108 — Throttle ingestion without losing accepted batches **Task · High priority · Advanced** noCV practice brief v5 · PIPE-108 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Performance engineering 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. After an outage, one carrier sends a day's events in 30 seconds. Memory pressure restarts workers and the API cannot tell which batches were accepted. Acceptance criteria - Bound request size and active ingest concurrency. - Acknowledge only after durable source and dispatch intent exist. - Return retryable overload before accepting work above the backlog limit. Implementation constraints - Distinguish rejected-before-acceptance from delayed-after-acceptance responses. Verification - Burst synthetic batches and account for every acknowledged batch. - Fail storage and saturate the queue; assert no false acceptance. Deliverables - Backpressure limits and accepted-batch accounting test Rollout and recovery: Start with conservative limits; reduce intake while draining accepted work if lag grows. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-109 — Detect a quiet carrier feed independently of queue health **Chore · Medium priority · Intermediate** noCV practice brief v5 · PIPE-109 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Site reliability 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. Every worker is healthy, but Carrier Elm has not sent a batch since morning. No alert fires because all dashboards measure processing failures. Acceptance criteria - Track last accepted receipt separately from event-time freshness. - Apply each carrier's configured operating schedule and lateness budget. - Feed-gap alerts name the integration and diagnostic step without parcel data. Implementation constraints - Empty valid batches count as receipts but do not imply fresh parcel scans. Verification - Advance the clock during operating hours to trigger a feed-gap alert. - Suppress quiet-window paging and distinguish stale event times. Deliverables - Freshness metrics, alert rule, and escalation notes Rollout and recovery: Review a simulated week in report-only mode before enabling paging. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-110 — Expire raw tracking payloads while retaining minimal lineage **Task · Medium priority · Advanced** noCV practice brief v5 · PIPE-110 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Data engineering 30% · Storage 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. Carrier payloads contain recipient notes unnecessary after the exercise's 30-day debugging window. A cleanup script removes artifacts still used by an active replay. Acceptance criteria - Delete eligible raw artifacts after configured retention. - Protect artifacts referenced by an active authorized replay lease. - Retain minimal hashes, deletion receipts, and normalized non-sensitive facts. Implementation constraints - Thirty days is a fictional exercise policy; expired leases cannot pin data forever. Verification - Expire an eligible artifact and verify its deletion record. - Protect an active replay artifact, then expire the lease and delete it. Deliverables - Retention job and replay-lease cleanup cases Rollout and recovery: Review a dry-run deletion manifest before enabling deletion on synthetic artifacts. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. ## LAKE — Rebuild a trustworthy merchant analytics mart A fictional marketplace reports daily sales to merchants. Refund joins inflate revenue, merchants close books in different time zones, and backfills compete with nightly loads. All source orders and merchants are synthetic. **Field:** Data engineering. **Suggested stack:** SQL, PostgreSQL, TypeScript, Object storage. **Engineer value:** Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. **Company value:** Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. **Delivery agreement:** Ten issues across definition, modeling, and release; deliver SQL, synthetic reconciliation fixtures, and an analyst handoff. ### Setup prerequisites - SQL joins and aggregates - Batch pipelines - Metric definitions ### Agree on the numbers Make metric grain and source assumptions explicit. #### LAKE-101 — Write the daily net-sales contract with worked rows **Task · High priority · Foundational** noCV practice brief v5 · LAKE-101 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Agree on the numbers. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. Finance subtracts posted refunds from captured charges; product subtracts pending refunds too. Both dashboards use Net sales and disagree for merchant M-17. Acceptance criteria - Define grain, inclusion states, currencies, and reporting date. - Provide six worked rows covering captures, refunds, pending entries, and voids. - Explicitly exclude tax and shipping from this exercise's net-sales metric. Implementation constraints - Do not resolve ambiguity by silently adopting whichever query exists. Verification - Recalculate worked totals independently from the contract. - Demonstrate why pending refunds and voids do not change posted totals. Deliverables - Versioned metric contract with executable example assertions Rollout and recovery: Review worked examples with the synthetic analyst role before downstream adoption. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-102 — Profile source keys before trusting the order feed **Chore · Medium priority · Foundational** noCV practice brief v5 · LAKE-102 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Agree on the numbers. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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 warehouse assumes order_id is globally unique, but two merchants both supplied order 7001. Daily deduplication keeps only one. Acceptance criteria - Report duplicates at global and merchant-scoped order grain. - Count missing merchant IDs, order IDs, currencies, and update timestamps. - Produce bounded sample references without customer details. Implementation constraints - Profiling reports anomalies and never deletes source rows. Verification - Detect intentionally duplicated merchant/order pairs. - Keep same-ID orders from different merchants distinct and report missing keys. Deliverables - Read-only profiling SQL and annotated output Rollout and recovery: Profile before changing ingestion; retain only minimized aggregate reports. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. ### Build reliable models Handle refunds, dimensions, dates, and incremental updates. #### LAKE-103 — Remove the order-line and refund join fan-out **Bug · High priority · Intermediate** noCV practice brief v5 · LAKE-103 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build reliable models. Depends on: LAKE-101, LAKE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · Database 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. An order with three lines and two refunds becomes six joined rows. The daily mart counts each captured amount several times although the ledger is correct. Acceptance criteria - Aggregate sources at declared grains before joining. - Count each capture and posted refund exactly once. - Keep orders without refunds and flag orphan refunds. Implementation constraints - DISTINCT on monetary values is not a fix; equal legitimate amounts remain distinct. Verification - Reconcile a three-line, two-refund order to its source total. - Include equal-value captures and an orphan refund to expose accidental deduplication. Deliverables - Corrected SQL and join-fan-out fixture Rollout and recovery: Compare a synthetic month and publish a new metric version with its correction delta. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-104 — Assign sales to the merchant's reporting day **Story · High priority · Intermediate** noCV practice brief v5 · LAKE-104 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build reliable models. Depends on: LAKE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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 23:30 Los Angeles sale appears on tomorrow's report because the mart groups UTC dates. Merchants cannot reconcile their register totals. Acceptance criteria - Derive reporting dates from the merchant's configured time zone. - Retain the original UTC instant. - Handle 23-hour and 25-hour days without lost or duplicate source rows. Implementation constraints - An unknown time zone blocks the affected partition instead of defaulting silently. Verification - Assign sales on both sides of local midnight correctly. - Exercise clock-change boundaries and an invalid time zone. Deliverables - Reporting-date model and boundary fixtures Rollout and recovery: Compare date-shifted totals before switching the synthetic merchant dashboard. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-105 — Preserve historical merchant plans in revenue breakdowns **Task · Medium priority · Advanced** noCV practice brief v5 · LAKE-105 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build reliable models. Depends on: LAKE-102, LAKE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. M-17 upgrades from Starter to Growth in June. Joining today's merchant record moves all earlier revenue into Growth and rewrites quarterly comparisons. Acceptance criteria - Join sales to the plan effective at the sale instant. - Reject overlapping effective intervals per merchant. - Represent missing history explicitly instead of using today's plan. Implementation constraints - Use inclusive-start, exclusive-end intervals and document their boundary. Verification - Assign sales before and at the upgrade instant correctly. - Detect interval overlaps and gaps without double-counting. Deliverables - Historical dimension model and interval checks Rollout and recovery: Backfill synthetic history and retain the prior dimension version until totals reconcile. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-106 — Pick up late refunds in an incremental load **Bug · High priority · Advanced** noCV practice brief v5 · LAKE-106 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build reliable models. Depends on: LAKE-103, LAKE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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 nightly job filters on order creation date. A refund posted today against a six-week-old order never reaches the mart. Acceptance criteria - Select changed keys using source change positions or update times. - Recompute affected reporting partitions beyond today's orders. - Advance checkpoints only after selected changes commit. Implementation constraints - Document watermark precision and ties; overlapping reads must be idempotent. Verification - Apply a late refund and reconcile its affected date. - Fail mid-load and replay equal-timestamp updates without loss or duplication. Deliverables - Incremental model and checkpoint recovery tests Rollout and recovery: Compare incremental and full builds on identical synthetic changes before switching schedules. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. ### Release the mart safely Reconcile, backfill, and govern a versioned dataset. #### LAKE-107 — Prevent a backfill from replacing a newer nightly partition **Bug · High priority · Expert** noCV practice brief v5 · LAKE-107 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release the mart safely. Depends on: LAKE-105, LAKE-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Distributed systems 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 noon backfill finishes after the nightly job. Its older snapshot overwrites May's newer partition and removes refunds received at 18:00. Acceptance criteria - Associate each generation with a source snapshot boundary. - Reject cutover when another generation superseded the intended partition revision. - Resume backfills without publishing incomplete partition sets. Implementation constraints - Document locking or compare-and-swap policy; finish time is not freshness. Verification - Overlap backfill and nightly load; prove the fresher state wins. - Interrupt before publication and verify readers see a complete prior generation. Deliverables - Partition publication protocol and overlap reproduction Rollout and recovery: Publish shadow generations first; retain the previous complete manifest for rollback. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-108 — Block publication when revenue fails source reconciliation **Task · High priority · Intermediate** noCV practice brief v5 · LAKE-108 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release the mart safely. Depends on: LAKE-103, LAKE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Quality 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 transformation passes SQL syntax checks while dropping one currency partition. The dashboard refresh succeeds and hides the revenue gap. Acceptance criteria - Compare counts and exact minor-unit totals by merchant, date, and currency. - Block unexplained differences while preserving the previous generation. - Report bounded discrepancy references and transformation version. Implementation constraints - Percentage tolerance cannot excuse exact integer ledger mismatches. Verification - Publish a fully reconciled fixture. - Drop one EUR partition and assert publication blocks with an actionable report. Deliverables - Reconciliation gate and discrepancy report Rollout and recovery: Observe known fixtures first, then enforce the gate before manifest publication. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-109 — Separate merchant exports from the analyst-wide mart **Task · High priority · Advanced** noCV practice brief v5 · LAKE-109 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release the mart safely. Depends on: LAKE-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Data engineering 30% · Privacy 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. Removing merchant_id from an export request returns every merchant's sales because the support route passes filters directly to an analyst-wide query. Acceptance criteria - Derive merchant scope from authorized context at the export boundary. - Expose only approved aggregate columns. - Reject unbounded date ranges and cross-merchant access. Implementation constraints - An analyst credential cannot substitute for merchant authorization. Verification - Export permitted dates for one merchant with correct totals. - Omit or replace merchant scope and request raw customer columns; assert denial. Deliverables - Scoped export boundary and authorization regression cases Rollout and recovery: Route one synthetic merchant through reduced credentials first; revoke export permission on scope failures. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. #### LAKE-110 — Explain a metric release to the analyst on call **Chore · Low priority · Foundational** noCV practice brief v5 · LAKE-110 · Rebuild a trustworthy merchant analytics mart Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release the mart safely. Depends on: LAKE-107, LAKE-108. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · 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. After a mart correction, May net sales changes and analysts need to know which rows moved. Build a synthetic before/after comparison and quantify the delta instead of assuming a target percentage. Acceptance criteria - Document metric versions, source cutoff, and affected partitions. - Break the delta into fan-out, late-refund, and reporting-day effects. - Provide reproducible comparison queries and previous-manifest restoration steps. Implementation constraints - Label measured deltas as results from the synthetic fixture, not expected company impact. Verification - Reproduce the note's totals from the synthetic fixture created for this project. - Exercise rollback and confirm the prior version is visible. Deliverables - Analyst release note and verified handoff checklist Rollout and recovery: Ship the note with the generation switch and record any rollback in the incident log. Project prerequisites: SQL joins and aggregates Batch pipelines Metric definitions Engineer value: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases. Company value: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product. 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. ## ROLL — Make a small service release recoverable A fictional scheduling service has an API, a worker, and PostgreSQL. Releases use immutable images on two application instances. The team needs compatibility checks, staged traffic, and a rehearsed rollback without introducing a new orchestration platform. **Field:** Platform engineering. **Suggested stack:** TypeScript, OCI image metadata, PostgreSQL, CI workflows. **Engineer value:** Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. **Company value:** Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. **Delivery agreement:** Ten phased issues using a synthetic service and simulated release provider; submit manifests, failure drills, and an operator handoff. ### Setup prerequisites - HTTP health checks - CI pipelines - Database migrations ### Know what is running Establish artifact identity and useful health signals. #### ROLL-101 — Display the exact release identity in diagnostics **Task · Medium priority · Foundational** noCV practice brief v5 · ROLL-101 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. Two API instances report version latest even though only one received yesterday's build. On call cannot connect a failing request to its deployed artifact. Acceptance criteria - Expose build revision, immutable artifact digest, and deployment ID through an authorized diagnostic endpoint. - Fail validation when a release manifest lacks immutable identity. - Keep build secrets and environment values outside the response. Implementation constraints - The build injects identity; request parameters cannot override it. Verification - Read distinct diagnostics from two synthetic release versions. - Reject a manifest containing only a mutable tag and inspect response redaction. Deliverables - Release manifest schema and diagnostic projection Rollout and recovery: Add diagnostics before changing deployment routing; remove endpoint exposure without changing artifact identities. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-102 — Separate liveness from database readiness **Bug · High priority · Foundational** noCV practice brief v5 · ROLL-102 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 brief database outage makes the process liveness endpoint fail. The restart policy kills every API instance and turns a recoverable connection issue into a restart loop. Acceptance criteria - Liveness reports whether the process can serve its own health handler. - Readiness fails when required database operations cannot complete within a bounded timeout. - Dependency errors return a stable diagnostic code without connection strings. Implementation constraints - A readiness probe must not create user records or run migrations. Verification - Assert both probes succeed with healthy synthetic dependencies. - Disable the database and verify readiness fails while liveness remains successful. Deliverables - Separate health routes and dependency-outage reproduction Rollout and recovery: Switch traffic readiness first, then restart-policy probes; restore prior routing if probe semantics are misconfigured. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-103 — Refuse deploys with incomplete runtime configuration **Task · High priority · Intermediate** noCV practice brief v5 · ROLL-103 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what is running. Depends on: ROLL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 80% · 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 new worker image needs STORAGE_REGION, but its environment is missing the setting. The rollout reports success while every document job fails on first use. Acceptance criteria - Validate required settings and allowed combinations before readiness succeeds. - Produce setting names and reason codes without printing values. - Validate API and worker manifests against their own declared configuration versions. Implementation constraints - Use dummy values in fixtures; configuration validation cannot contact production services. Verification - Validate complete API and worker manifests. - Reject missing storage region and incompatible settings while checking log redaction. Deliverables - Configuration preflight and role-specific fixtures Rollout and recovery: Run preflight as an advisory CI step, then block invalid synthetic release manifests. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. ### Control release risk Enforce compatibility, serialization, and staged rollout decisions. #### ROLL-104 — Keep old API instances working during a column rename **Task · High priority · Advanced** noCV practice brief v5 · ROLL-104 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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 migration renames booking.start to booking.starts_at before old API instances finish draining. Half the requests fail until every instance updates. Acceptance criteria - Define expand, compatible application rollout, backfill, and contract stages. - Prove old and new application versions work during the supported overlap. - Block destructive cleanup while the old reader version remains active. Implementation constraints - Include rollback compatibility explicitly; a reverse rename alone is not a release strategy. Verification - Run mixed-version synthetic requests through the expanded schema. - Attempt cleanup with an old instance present and assert the gate blocks. Deliverables - Versioned migration plan and mixed-version compatibility checks Rollout and recovery: Apply only expansion first; rollback application traffic before the contract stage if errors appear. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-105 — Prevent two release jobs from overwriting the same environment **Bug · High priority · Advanced** noCV practice brief v5 · ROLL-105 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-101, ROLL-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Distributed systems 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. Two commits deploy simultaneously. The older job finishes last and marks its artifact current after the newer release already passed validation. Acceptance criteria - Serialize mutations per environment with a bounded renewable lease. - Reject state updates from expired or superseded lease holders. - Record the winning release identity and every rejected stale update. Implementation constraints - A process-local mutex cannot coordinate independent CI jobs. Verification - Race two simulated releases and inspect one current manifest. - Expire a lease, acquire a successor, and prove the old holder cannot publish. Deliverables - Release lease protocol and stale-writer regression Rollout and recovery: Enable serialization on the test environment; disable dispatch while investigating lease failures. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-106 — Base canary decisions on enough comparable requests **Story · High priority · Expert** noCV practice brief v5 · ROLL-106 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control release risk. Depends on: ROLL-102, ROLL-104, ROLL-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Platform engineering 40% · 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 release automatically promotes after five error-free canary requests while the stable version serves thousands. Low traffic makes an untested version look healthy. Acceptance criteria - Require a configured minimum request count and observation window before promotion. - Compare matching route classes with error-rate and latency budgets declared in the fixture. - Return HOLD for insufficient traffic and ABORT for breached safety thresholds. Implementation constraints - Use bounded route labels; a percentage alone cannot justify a decision without sample counts. Verification - Promote a synthetic canary with adequate comparable traffic. - Exercise sparse traffic, a route-mix shift, and rising errors; inspect HOLD or ABORT reasons. Deliverables - Canary decision function, fixture traces, and decision report Rollout and recovery: Run decisions in observe mode against simulated traffic before allowing the simulated provider to advance stages. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. ### Recover with evidence Drain work, diagnose failures, and rehearse rollback. #### ROLL-107 — Drain long requests before retiring an API instance **Bug · High priority · Intermediate** noCV practice brief v5 · ROLL-107 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Networking 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. During release, an instance exits halfway through a report download. The load balancer keeps sending new requests during its shutdown grace period. Acceptance criteria - Mark the instance unready before starting its bounded drain period. - Allow existing requests to complete until the documented deadline. - Close remaining connections and report forced terminations at deadline without hanging shutdown. Implementation constraints - Do not count idle keep-alive connections as unfinished business requests indefinitely. Verification - Start a long synthetic request, initiate shutdown, and observe completion. - Keep a request stuck beyond the deadline and confirm bounded exit and termination count. Deliverables - Graceful shutdown behavior and request-drain reproduction Rollout and recovery: Exercise draining on one test instance; restore the previous grace settings if traffic does not stop arriving. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-108 — Do not roll back a worker into an unreadable job format **Task · High priority · Expert** noCV practice brief v5 · ROLL-108 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-104, ROLL-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Distributed systems 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. Worker v8 enqueues a new payload shape. Rolling back to v7 starts a retry storm because v7 cannot parse jobs already accepted by v8. Acceptance criteria - Version job envelopes and declare the worker versions able to consume each version. - Gate rollback when queued work would become unreadable. - Provide a safe drain or compatibility path that preserves accepted job identities. Implementation constraints - Do not rewrite historical payloads in place or discard incompatible jobs to make rollback green. Verification - Process old and new fixture envelopes with the declared compatible worker. - Attempt an incompatible rollback with queued v8 work and assert a useful blocking reason. Deliverables - Job compatibility matrix and rollback preflight Rollout and recovery: Deploy backward readers before new writers; remove old readers only after the compatibility window closes. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-109 — Attach a release marker to bounded operational telemetry **Chore · Medium priority · Intermediate** noCV practice brief v5 · ROLL-109 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-101, ROLL-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. An error spike starts near a deploy, but the dashboard has no release event or stable artifact link. Engineers compare screenshots and guess which change was live. Acceptance criteria - Emit a release event with environment, deployment ID, artifact digest, and stage outcome. - Link stage failures to sanitized diagnostic references. - Keep request bodies, secret values, and arbitrary commit messages out of metric labels. Implementation constraints - Store high-cardinality release details in events; use bounded dimensions for metrics. Verification - Trace a simulated canary abort from its marker to its release manifest. - Inject secret-like fixture metadata and verify the telemetry projection excludes it. Deliverables - Release event schema and incident dashboard query Rollout and recovery: Add markers without changing alert thresholds; disable the new event sink if it delays release decisions. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. #### ROLL-110 — Rehearse an aborted release and write the operator handoff **Task · Medium priority · Intermediate** noCV practice brief v5 · ROLL-110 · Make a small service release recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover with evidence. Depends on: ROLL-106, ROLL-107, ROLL-108, ROLL-109. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Site reliability 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. The release checklist says rollback tested, but nobody has timed recovery or tried it with an expanded database schema and pending worker jobs. Acceptance criteria - Run one simulated failed canary with pending jobs and expanded schema. - Record detection, abort, drain, and recovery timestamps with observed limitations. - Provide exact preconditions and stop conditions for the documented rollback path. Implementation constraints - A simulated drill establishes fixture behavior only; label its measured timings accordingly. Verification - Recover the previous compatible release and reconcile accepted jobs. - Include an incompatible rollback example and prove the checklist tells the operator to stop. Deliverables - Recorded release drill and operator runbook Rollout and recovery: Version the runbook with the tested manifests; repeat the bounded drill when compatibility assumptions change. Project prerequisites: HTTP health checks CI pipelines Database migrations Engineer value: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology. Company value: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe. 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. ## QUEUE — Bring document processing back under control A fictional internal document portal creates previews through a trusted mock renderer. Large batches crowd out small teams, failed documents retry forever, and operators lack a safe replay command. This exercise never executes uploaded code or real document macros. **Field:** Platform engineering. **Suggested stack:** TypeScript, BullMQ, Redis, PostgreSQL, Object storage. **Engineer value:** Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. **Company value:** See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. **Delivery agreement:** Ten tickets in intake, resilience, and operations phases; use only synthetic document metadata and a trusted deterministic renderer. ### Setup prerequisites - Queue semantics - Database transactions - Operational metrics ### Account for accepted work Create traceable jobs with bounded inputs. #### QUEUE-101 — Expose a document job's current phase and terminal reason **Story · Medium priority · Foundational** noCV practice brief v5 · QUEUE-101 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Platform engineering 30% · 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 portal shows Processing for both queued and permanently rejected documents. Support cannot tell whether a file is waiting, rendering, or never going to finish. Acceptance criteria - Expose QUEUED, RUNNING, SUCCEEDED, FAILED, and CANCELLED through an allowlisted projection. - Include a stable terminal reason code and last transition time. - Deny jobs owned by another tenant. Implementation constraints - Only service transition methods may update lifecycle state; logs are not the source of truth. Verification - Read queued and failed fixture jobs with distinct explanations. - Reject foreign-tenant lookup and ensure renderer payloads are absent. Deliverables - Job status contract and authorized read endpoint Rollout and recovery: Switch status reads for synthetic jobs first; retain historical transition records if the view is reverted. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-102 — Reject oversized document batches before accepting work **Task · High priority · Foundational** noCV practice brief v5 · QUEUE-102 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Performance engineering 30% · 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. A client submits 50,000 document references in one call. Validation exhausts API memory before the queue sees a single job. Acceptance criteria - Enforce a documented request byte limit and a maximum of 100 document references. - Reject duplicate references within the batch with a clear validation reason. - Create no jobs when batch validation fails. Implementation constraints - Validate metadata only; the API must not download or render document contents. Verification - Accept a valid 100-reference synthetic batch. - Reject 101 references, excessive bytes, and duplicate references without partial jobs. Deliverables - Bounded batch contract and boundary cases Rollout and recovery: Publish limits before enforcing them on the test client; rollback client batching rather than raising limits without measurement. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-103 — Commit job acceptance and dispatch intent together **Bug · High priority · Advanced** noCV practice brief v5 · QUEUE-103 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Account for accepted work. Depends on: QUEUE-101, QUEUE-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Database engineering 30% · Platform 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. Pattern topics: Transactional Outbox (apply). Transactional Outbox — Apply: Commit acceptance and dispatch intent in one transaction, then demonstrate recovery after the queue is unavailable or the process stops before dispatch. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The portal returns 202 after storing a job, then loses Redis connectivity before enqueueing it. The job stays QUEUED forever with no delivery attempt. Acceptance criteria - Commit accepted job records and durable dispatch intents atomically. - Dispatch retries use deterministic job identities. - A failed database transaction cannot return accepted status. Implementation constraints - Queue messages contain identifiers and bounded metadata, not document bytes. Verification - Lose Redis after acceptance and recover every job when dispatch resumes. - Fail the database commit and assert neither job nor dispatch intent exists. Deliverables - Outbox-backed acceptance and recovery reproduction Rollout and recovery: Drain synthetic pending intents through the new dispatcher; pause dispatch without deleting accepted work to rollback. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. ### Handle failures deliberately Control retries, concurrency, cancellation, and worker loss. #### QUEUE-104 — Stop retrying unsupported document formats **Bug · High priority · Intermediate** noCV practice brief v5 · QUEUE-104 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. The trusted mock renderer returns UNSUPPORTED_FORMAT for a fixture file. The worker retries it every minute, consuming the same capacity as a temporary storage timeout. Acceptance criteria - Classify unsupported format as terminal and storage timeout as retryable. - Apply a bounded attempt count and backoff policy to retryable failures. - Record each attempt and the final exhaustion reason without replacing earlier failures. Implementation constraints - Unknown provider errors need an explicit conservative policy; do not retry forever. Verification - Retry a transient failure that succeeds on its third attempt. - Verify unsupported format runs once and persistent timeout reaches a bounded terminal state. Deliverables - Failure classification table and retry policy Rollout and recovery: Apply new classification to future attempts; stop scheduling exhausted jobs without erasing their attempt history. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-105 — Keep one team's bulk import from occupying every worker **Story · High priority · Advanced** noCV practice brief v5 · QUEUE-105 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-103, QUEUE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Performance engineering 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. A synthetic tenant uploads 10,000 documents. A second tenant's single preview waits behind the entire batch although the renderer has spare concurrency slots between completions. Acceptance criteria - Enforce configured global and per-tenant active-job limits. - Allow eligible tenants to make progress while a bulk tenant has backlog. - Release capacity after success, terminal failure, cancellation, or expired execution lease. Implementation constraints - Do not create an unbounded queue or metric family per tenant; explain the fairness policy. Verification - Run one bulk tenant and two small tenants and measure their wait times. - Crash a worker while holding capacity and prove another eligible tenant eventually progresses. Deliverables - Fair dispatch policy and controlled-load report Rollout and recovery: Start with conservative synthetic limits; disable new intake and drain leases if accounting diverges. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-106 — Fence a late worker after its rendering lease expires **Bug · High priority · Expert** noCV practice brief v5 · QUEUE-106 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-104, QUEUE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Worker A pauses long enough to lose its lease. Worker B completes the same preview, then A resumes and overwrites B's artifact pointer with stale output. Acceptance criteria - Associate each execution attempt with a monotonic fencing identity. - Accept completion only from the current authorized lease holder. - Keep rejected late completions observable and prevent them from changing terminal job state. Implementation constraints - Lease expiration alone does not stop a process; the persistence boundary must reject stale writes. Verification - Expire A, complete through B, then submit A's completion and inspect unchanged output. - Replay B's completion and assert one terminal transition and artifact reference. Deliverables - Fenced completion operation and paused-worker reproduction Rollout and recovery: Introduce fencing before extending concurrency; rollback dispatch while retaining fencing checks on completions. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-107 — Cancel queued work without racing a completed preview **Story · Medium priority · Advanced** noCV practice brief v5 · QUEUE-107 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle failures deliberately. Depends on: QUEUE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Platform engineering 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. A user cancels a batch just as one preview finishes. The portal reports Cancelled while retaining an accessible success artifact, and a retry renders it again. Acceptance criteria - Make cancellation an authorized state transition with documented running-job semantics. - Resolve cancellation and completion races to one terminal result. - Prevent cancelled jobs from being newly dispatched or retried. Implementation constraints - For the mock renderer, cancellation can be cooperative; disclose work that cannot stop immediately. Verification - Cancel queued work and prove the renderer is never called. - Race running completion and cancellation, then replay both commands and inspect stable state. Deliverables - Cancellation contract and race regression Rollout and recovery: Enable queued cancellation first, then running cancellation after the race cases pass; retain terminal records on rollback. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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 recovery routine Expose useful lag signals and safe repair operations. #### QUEUE-108 — Measure oldest runnable work instead of queue size alone **Chore · Medium priority · Intermediate** noCV practice brief v5 · QUEUE-108 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-104, QUEUE-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · Platform 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 queue contains only ten jobs, but the oldest eligible preview has waited 40 minutes. A queue-depth alert never fires, while scheduled retries inflate another dashboard. Acceptance criteria - Measure oldest eligible-job age separately from delayed retries and running age. - Expose attempt exhaustion and stale-lease counts with bounded labels. - Alert when eligible wait exceeds the fixture's ten-minute budget for two observations. Implementation constraints - Exclude document IDs and tenant IDs from metric label sets. Verification - Advance a controlled clock and trigger runnable-age paging. - Keep a future retry delayed and verify it does not inflate eligible wait. Deliverables - Queue age metrics and diagnosis-oriented alert Rollout and recovery: Compare alerts with the synthetic workload trace in report-only mode before paging. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-109 — Replay a failed preview through an audited repair command **Task · High priority · Intermediate** noCV practice brief v5 · QUEUE-109 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-104, QUEUE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · Backend 30% · Security 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. Operators repair failed jobs by deleting Redis keys. That loses failure history and can replay work for the wrong tenant when a copied ID is mistaken. Acceptance criteria - Allow an authorized operator to create a linked repair attempt for a terminal failure. - Require tenant scope, expected job revision, and a reason. - Preserve original failure history and make duplicate repair requests idempotent. Implementation constraints - Do not reopen the failed record in place or expose a general queue-management console. Verification - Repair one terminal fixture failure and follow the linked attempts. - Reject a foreign tenant, stale revision, and repair of a successful job. Deliverables - Scoped repair command and audit projection Rollout and recovery: Grant repair permission to a synthetic operator role; revoke command access while retaining read-only audit history. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. #### QUEUE-110 — Collect orphaned preview artifacts without deleting live output **Task · Medium priority · Advanced** noCV practice brief v5 · QUEUE-110 · Bring document processing back under control Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make recovery routine. Depends on: QUEUE-106, QUEUE-107, QUEUE-109. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Platform engineering 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. A worker writes an artifact then loses its lease before committing the pointer. Storage grows with orphaned previews, but a naive age-based cleanup can delete an output still being committed. Acceptance criteria - Separate temporary attempt artifacts from committed output references. - Delete only unreferenced artifacts beyond a documented grace period with no active lease. - Make cleanup resumable and record bounded deletion outcomes. Implementation constraints - Use synthetic objects; an artifact listing alone cannot prove an object is unreferenced. Verification - Collect an abandoned attempt artifact after its grace period. - Race cleanup with a valid completion and prove committed output survives. Deliverables - Orphan collector, race fixture, and dry-run manifest Rollout and recovery: Review deletion manifests in dry-run mode, then enable cleanup for the synthetic storage prefix only. Project prerequisites: Queue semantics Database transactions Operational metrics Engineer value: Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider. Company value: See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access. 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. ## ACCESS — Tighten a partner portal's access boundaries A fictional manufacturing company shares purchase-order documents with partner organizations. Buyers, partner administrators, and read-only agents use the same API. Recent support reports suggest list filters and background downloads disagree about who may see an order. **Field:** Security. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Redis. **Engineer value:** Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. **Company value:** Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. **Delivery agreement:** Ten defensive engineering issues over mapping, enforcement, and assurance phases; use synthetic accounts and documents in an owned test environment. ### Setup prerequisites - HTTP APIs - Session authentication - Tenant-scoped data access ### Map permissions Identify resources and define authorized actions. #### ACCESS-101 — Write the partner permission matrix from existing routes **Task · High priority · Foundational** noCV practice brief v5 · ACCESS-101 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map permissions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · System 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. The portal has three roles, but engineers infer permissions from page names. A read-only agent can discover an Edit route that was added for partner administrators. Acceptance criteria - Inventory order, document, invitation, and export actions at route and service boundaries. - Define allowed actions for buyer, partner administrator, and read-only agent. - Mark unspecified combinations as denied and identify ownership or tenant conditions. Implementation constraints - A hidden button is not an authorization rule; include non-UI callers. Verification - Map each fixture route to exactly one documented action. - Show explicit denials for agent edits and cross-partner document reads. Deliverables - Permission matrix and route-to-action inventory Rollout and recovery: Review the matrix before enforcing new checks; record intentional compatibility changes for test clients. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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 at every boundary Apply tenant and permission rules across synchronous and asynchronous access. #### ACCESS-102 — Remove partner scope from client-controlled list filters **Bug · High priority · Intermediate** noCV practice brief v5 · ACCESS-102 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Backend 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. Changing partnerId in the purchase-order query reveals another partner's orders. The controller authenticates the session but trusts the query filter to choose the tenant. Acceptance criteria - Derive authorized partner scope from the server-side actor context. - Apply that scope within the order repository query. - Return scoped counts and pagination cursors that cannot widen access. Implementation constraints - Test the repository directly as well as the route; controller-only filtering is insufficient. Verification - List two pages of the authorized partner's orders with correct counts. - Replace partnerId and replay a foreign cursor; assert no foreign records or totals. Deliverables - Tenant-scoped list boundary and denial regressions Rollout and recovery: Switch the synthetic partner list first; disable the route if scoped count comparisons fail. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-103 — Make bulk order updates all-or-nothing across authorization checks **Bug · High priority · Advanced** noCV practice brief v5 · ACCESS-103 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101, ACCESS-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 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. A batch update contains nine permitted order IDs and one foreign ID. The service updates the first nine before discovering the forbidden order and returning 403. Acceptance criteria - Authorize the complete bounded target set before committing changes. - A missing, duplicate, or foreign order prevents the entire batch update. - Record no success audit when the transaction is rejected. Implementation constraints - Do not reveal which foreign order exists through different error shapes. Verification - Update a fully authorized synthetic batch atomically. - Mix permitted and forbidden IDs and inject a final-write failure; verify unchanged records. Deliverables - Atomic bulk command and mixed-scope reproduction Rollout and recovery: Enable a bounded batch size on the synthetic client; revert batch routing without relaxing individual authorization. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-104 — Stop a document lookup from revealing foreign filenames **Bug · High priority · Foundational** noCV practice brief v5 · ACCESS-104 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A foreign document request returns Forbidden: invoice-acme-september.pdf. Download is blocked, but the error itself leaks the other partner's filename. Acceptance criteria - Use the same public not-found response for missing and out-of-scope documents. - Do not include filename, owner, storage key, or existence hints in denied responses. - Keep an internal denial reason behind authorized audit access. Implementation constraints - Apply the projection to metadata and download-link routes, not just the file response. Verification - Retrieve an authorized filename normally. - Compare missing and foreign-document response bodies and inspect sanitized logs. Deliverables - Document denial projection and metadata-leak regression Rollout and recovery: Replace external error text immediately in the fixture routes; keep internal reason codes for diagnosis. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-105 — Consume partner invitations once under concurrent acceptance **Task · High priority · Advanced** noCV practice brief v5 · ACCESS-105 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 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. Two acceptance requests use the same invitation token at nearly the same time. The portal creates duplicate memberships and occasionally accepts a token after its role was revoked. Acceptance criteria - Bind an invitation to partner, intended recipient, role, expiry, and current invitation state. - Consume it and create membership in one transaction. - Concurrent acceptance yields one membership with a documented replay or conflict response. Implementation constraints - Persist token hashes only; synthetic invitation secrets must not enter logs. Verification - Accept a valid invitation once and inspect its membership. - Race acceptance and try expired, revoked, and wrong-recipient tokens; assert denial or one winner. Deliverables - Invitation consumption command and concurrency cases Rollout and recovery: Issue the new token format for future synthetic invitations; retain a documented expiry window for legacy links. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-106 — Narrow integration keys to the permissions they were issued **Story · High priority · Intermediate** noCV practice brief v5 · ACCESS-106 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101, ACCESS-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. A partner creates a read-only reporting key while an administrator is logged in. Requests using that key inherit the administrator's full session permissions. Acceptance criteria - Evaluate key scopes separately from browser-session roles. - Restrict effective permissions to both key scope and current partner authority. - Support key revocation without disabling unrelated partner sessions. Implementation constraints - A key cannot grant a permission its issuer was not authorized to delegate. Verification - Read permitted reports through a scoped synthetic key. - Attempt order edits, cross-partner reads, and use after revocation; assert denial. Deliverables - Integration-key authorization policy and scope tests Rollout and recovery: Create scoped test keys alongside existing clients; remove broad key support after explicit client migration. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. ### Prove revocation and explain denials Handle changes in authority and provide useful audit records. #### ACCESS-107 — Recheck export authority when a background job completes **Bug · High priority · Expert** noCV practice brief v5 · ACCESS-107 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-103, ACCESS-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Distributed systems 20% · Storage 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. An administrator starts a large partner export and loses membership while it runs. The worker later emails a long-lived storage URL using authorization captured only at request time. Acceptance criteria - Record immutable request scope without treating it as permanent authorization. - Reauthorize delivery and each download against current membership and export scope. - Revoked users cannot receive or use new access grants; completed artifacts remain tenant-restricted. Implementation constraints - Use an authenticated download boundary or similarly revocable design; do not send real email in this exercise. Verification - Complete and download a permitted synthetic export. - Revoke access between request, completion, and download; verify denial at each relevant boundary. Deliverables - Export authorization lifecycle and revocation timing tests Rollout and recovery: Route synthetic exports through the new download boundary; expire legacy links before removing their compatibility path. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-108 — Invalidate cached permissions after a role downgrade **Bug · High priority · Advanced** noCV practice brief v5 · ACCESS-108 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-102, ACCESS-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Distributed systems 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 partner administrator is downgraded to read-only but retains edit access on one API instance for an hour because permission caches are local and keyed only by user ID. Acceptance criteria - Scope cached decisions by actor, partner, and authority revision. - Enforce a documented maximum revocation delay with an authoritative fallback. - Fail closed for privileged writes when current authority cannot be established. Implementation constraints - User ID alone is insufficient when the same user belongs to multiple partners. Verification - Downgrade a role across two synthetic API instances and measure the revocation delay. - Simulate cache invalidation loss and authority-store failure; assert privileged writes cannot persist indefinitely. Deliverables - Permission cache policy and revocation-latency reproduction Rollout and recovery: Shorten cache lifetime before enabling revisioned entries; bypass the cache if revision propagation fails. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-109 — Record useful access-denial audits without copying documents **Chore · Medium priority · Foundational** noCV practice brief v5 · ACCESS-109 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-104, ACCESS-106. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Security receives Denied entries with no action name, while application debug logs include complete document metadata. Neither source is suitable for reviewing a partner complaint. Acceptance criteria - Record actor reference, scoped action, tenant reference, reason code, and correlation ID. - Exclude document text, credential values, request bodies, and raw download URLs. - Protect audit queries with a dedicated read permission and bounded date range. Implementation constraints - Security audit records are append-only; generic analytics must not receive sensitive audit detail. Verification - Follow an authorized denial investigation through its correlation ID. - Attempt audit access as a partner agent and scan secret-like fixture values for absence. Deliverables - Minimized audit schema and investigation example Rollout and recovery: Mirror fixture denials into the new sink and inspect redaction before enabling operator queries. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-110 — Serialize membership removal with privileged order approval **Task · High priority · Expert** noCV practice brief v5 · ACCESS-110 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-103, ACCESS-108, ACCESS-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database 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. A buyer is removed from a partner while their order-approval request is between authorization and commit. The current implementation commits the approval after removal without a defined policy. Acceptance criteria - Declare the transactional ordering rule for removal and approval. - Reconcile authority revision within the privileged write transaction so one ordering is enforced. - Keep successful approvals and rejected stale authority attempts separately auditable. Implementation constraints - A second controller check does not close the race; prove the service/database boundary controls it. Verification - Commit approval before removal under the declared ordering and inspect attribution. - Commit removal first while approval is paused and assert no unauthorized order mutation. Deliverables - Authority/write serialization design and deterministic interleaving tests Rollout and recovery: Apply the rule to order approvals before broader privileged writes; retain audit records through application rollback. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. ## VAULT — Rotate an integration credential without losing work A fictional supplier integration signs incoming webhooks and uses an outbound API credential. Operators currently replace environment values by hand. Build with a deterministic secret-store adapter and fabricated keys only; no live provider account or production credential is part of the exercise. **Field:** Security. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Secret-provider interface. **Engineer value:** Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. **Company value:** Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. **Delivery agreement:** Ten issues across inventory, rotation, and recovery phases; deliver a deterministic provider, synthetic contract checks, and a credential incident drill. ### Setup prerequisites - Cryptographic hash APIs - HTTP webhook handling - Access control ### Make credential use explicit Establish provider boundaries and prevent secret exposure. #### VAULT-101 — Inventory credential consumers without exporting their values **Task · Medium priority · Foundational** noCV practice brief v5 · VAULT-101 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Platform 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. Operations knows the supplier key is used by the API but discovers a nightly worker still reads an old environment variable. Rotation planning has no reliable consumer list. Acceptance criteria - List logical credential names, consuming processes, purposes, and required permissions. - Distinguish inbound signing verification from outbound API authentication. - Exclude credential values and private material from the inventory artifact. Implementation constraints - Prepare a synthetic API/worker consumer configuration; inspect its names only and do not enumerate the user's environment or local secrets. Verification - Account for API and worker consumers in the synthetic configuration prepared for this project. - Insert a dummy secret value and confirm the inventory output never contains it. Deliverables - Credential consumer map and rotation dependency list Rollout and recovery: Review the map before changing lookup paths; version it with each new consumer. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-102 — Move secret lookup behind a version-aware provider **Task · High priority · Intermediate** noCV practice brief v5 · VAULT-102 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: VAULT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Backend 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. Pattern topics: Ports and Adapters (apply). Ports and Adapters — Apply: Separate version-aware secret lookup from provider details so the deterministic adapter and an unavailable provider obey the same fail-closed contract. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. API and worker read process environment independently and cannot report which credential version they are using. The test suite also embeds key values in request snapshots. Acceptance criteria - Define lookup by logical credential name and permitted version reference. - Return a non-secret version identity separately from sensitive material. - Use a deterministic fixture adapter and fail closed when no provider is configured. Implementation constraints - Keep secret material out of serialized DTOs and snapshot assertions. Verification - Resolve a known synthetic version for an authorized consumer. - Reject an unknown version, unauthorized consumer, and absent provider without fallback secrets. Deliverables - Secret provider contract and deterministic adapter Rollout and recovery: Migrate one synthetic consumer at a time; keep configuration rollback limited to the fixture provider. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-103 — Redact credentials from failed supplier requests **Bug · High priority · Foundational** noCV practice brief v5 · VAULT-103 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: VAULT-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. The HTTP client's error serializer includes Authorization headers and query parameters. A supplier timeout writes the outbound credential into a generic error log. Acceptance criteria - Log an allowlisted error projection with operation, status class, timeout, and correlation ID. - Exclude headers, raw URLs, request bodies, and provider response bodies. - Expose credential version identity only when it is a non-secret reference. Implementation constraints - Do not rely on replacing one known key value; future values and nested errors must remain safe. Verification - Diagnose a synthetic timeout through permitted metadata. - Inject secret-like values into nested headers, URLs, and response bodies and assert absence. Deliverables - Safe supplier error serializer and redaction fixtures Rollout and recovery: Replace error serialization before rotation drills; disable verbose client logging in the fixture configuration. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. ### Rotate with controlled overlap Handle version changes, webhook verification, and in-flight work. #### VAULT-104 — Model credential activation and retirement as explicit transitions **Story · High priority · Intermediate** noCV practice brief v5 · VAULT-104 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-102, VAULT-103. 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. An operator changes a credential row from RETIRED to ACTIVE to recover an outage. The service resumes using a version that was deliberately revoked after a drill. Acceptance criteria - Define staged, active, retiring, retired, and revoked states with named commands. - Prevent revoked and retired versions from becoming active again. - Audit actor, reason, version references, and transition time without secret material. Implementation constraints - A replacement requires a new credential version; state changes cannot rewrite historical identity. Verification - Walk a staged fixture version through activation and retirement. - Attempt forbidden reactivation and stale revision updates; assert unchanged history. Deliverables - Credential lifecycle operations and transition matrix Rollout and recovery: Route fixture operator changes through the commands before removing direct state writes. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-105 — Verify signed webhooks against raw bytes before parsing **Bug · High priority · Advanced** noCV practice brief v5 · VAULT-105 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Integrations 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 receiver parses JSON and reserializes it before checking the supplier signature. Harmless whitespace changes break valid signatures, while trusted routing fields are read before authenticity is established. Acceptance criteria - Verify the exact bounded raw body using the fixture protocol's HMAC signature format. - Use constant-time comparison for equal-length signature bytes and reject malformed encodings. - Parse trusted fields only after successful verification and enforce the protocol's timestamp tolerance. Implementation constraints - The fixture protocol signs timestamp plus raw body with HMAC-SHA-256; define the byte separator explicitly. Verification - Accept a correctly signed body including deliberate whitespace. - Reject one-byte changes, invalid signature length, and timestamps outside the declared tolerance. Deliverables - Raw-body webhook verification and protocol fixtures Rollout and recovery: Run signature checks on a fixture receiver first; fail closed when verification material is unavailable. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-106 — Accept old and new webhook signatures only during a bounded overlap **Task · High priority · Advanced** noCV practice brief v5 · VAULT-106 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-104, VAULT-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Integrations 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 supplier rotates signing keys gradually across senders. Switching instantly drops valid traffic; retaining every old key forever defeats retirement. Acceptance criteria - Accept only the configured active and retiring versions during their explicit validity windows. - Reject retired or revoked versions regardless of timestamp tolerance. - Record the non-secret verifying version identity for accepted webhook receipts. Implementation constraints - Bound the candidate key set; an untrusted key ID cannot trigger arbitrary provider lookups. Verification - Accept both fixture versions inside overlap and only the new version after retirement. - Try a revoked version and an unknown attacker-controlled key ID; assert rejection without broad lookup. Deliverables - Signing overlap policy and boundary-time tests Rollout and recovery: Stage the new version, begin bounded overlap, then retire the old version after fixture sender convergence. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-107 — Keep duplicate signed callbacks from creating duplicate supplier events **Bug · High priority · Intermediate** noCV practice brief v5 · VAULT-107 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-105, VAULT-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Integrations 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 supplier retries a valid signed callback through both old and new signing keys during overlap. Signature checks pass twice and both requests create a purchase-order update. Acceptance criteria - Deduplicate by authenticated supplier event identity and tenant, independent of signing version. - Bind the identity to a canonical payload fingerprint and conflict on changed content. - Commit the receipt and business dispatch intent atomically. Implementation constraints - A valid signature proves message authenticity under the fixture protocol, not permission for duplicate side effects. Verification - Deliver the same event under both allowed keys and assert one business dispatch. - Race duplicate callbacks and reuse the event ID with changed content; inspect stable state and conflict. Deliverables - Authenticated receipt deduplication and overlap replay cases Rollout and recovery: Enable receipt uniqueness before starting overlap; retain receipts through any receiver rollback. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. ### Recover and audit Revoke compromised versions, bound caching, and rehearse provider failure. #### VAULT-108 — Rotate outbound credentials without retrying an ambiguous write twice **Task · High priority · Expert** noCV practice brief v5 · VAULT-108 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-104, VAULT-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 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. An outbound supplier update times out during credential rotation. The worker retries with the new key and a fresh request ID, creating the same supplier instruction twice. Acceptance criteria - Keep one operation identity across credential version changes and retries. - Distinguish authentication rejection from an unknown remote commit outcome. - Use the fixture supplier's idempotency/status contract before resending an ambiguous write. Implementation constraints - Do not assume changing credentials resets business idempotency or proves a timed-out request failed. Verification - Rotate after a confirmed authentication failure and complete one logical operation. - Simulate remote commit followed by timeout; reconcile through status lookup and assert no duplicate instruction. Deliverables - Outbound rotation retry protocol and ambiguous-outcome reproduction Rollout and recovery: Verify against the deterministic supplier adapter before switching fixture consumers; pause ambiguous writes if status lookup fails. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-109 — Make emergency revocation reach cached consumers **Bug · High priority · Expert** noCV practice brief v5 · VAULT-109 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-104, VAULT-106, VAULT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Distributed systems 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 operator revokes a synthetic compromised key, but a worker's indefinite cache continues signing requests with it. Another worker refreshes and succeeds, hiding the inconsistent state. Acceptance criteria - Bound cache lifetime and propagate credential authority revisions to all consumers. - Prevent use after the declared revocation deadline, including during provider outage. - Audit revocation convergence using version references and consumer acknowledgements only. Implementation constraints - Cached availability cannot override explicit revocation; define the exercise's maximum revocation delay. Verification - Revoke a cached fixture key across two consumers and measure convergence. - Drop one invalidation notification and disable lookup; verify use stops at the deadline. Deliverables - Revocation propagation design and failure-interleaving tests Rollout and recovery: Enforce bounded caching before testing emergency revoke; pause outbound work when authority cannot be refreshed safely. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-110 — Rehearse a secret-provider outage and document recovery limits **Chore · Medium priority · Advanced** noCV practice brief v5 · VAULT-110 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-103, VAULT-108, VAULT-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 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. The provider is unavailable during a planned rotation. On call needs to know which reads can continue, which writes must wait, and how to recover without pasting keys into environment files. Acceptance criteria - Exercise provider outage before activation, during overlap, and after old-version revocation. - Document allowed cached behavior and fail-closed conditions for each stage. - Restore processing through the provider while preserving operation IDs and audit history. Implementation constraints - Use fabricated credentials and deterministic failures; no manual secret-value fallback is allowed. Verification - Recover a staged fixture rotation after provider availability returns. - Keep the revoked version unusable throughout outage and recovery, and inspect logs for secret absence. Deliverables - Credential incident drill report and stage-specific recovery runbook Rollout and recovery: Version the runbook with provider and policy versions; repeat the drill when cache or overlap behavior changes. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. ## DESK — A support console that survives a busy shift The fictional Alder support team handles billing and delivery conversations in a browser console. Agents keep several tickets open, share filtered queues, and work through unreliable office Wi-Fi. The API contract returns ticket revisions and cursor-based pages; work stays within the console and its test adapter. **Field:** Frontend. **Suggested stack:** React, TypeScript, CSS Modules, Testing Library, Playwright. **Engineer value:** Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. **Company value:** Inspect how an engineer protects agent work and handles failures that interrupt support operations. **Delivery agreement:** Choose one ticket or deliver the phases as separate pull requests. Use synthetic customer content; live email delivery is outside scope. ### Setup prerequisites - A ticket-list and reply API contract to implement or stub - Synthetic conversations across two organizations with revision conflicts ### Make the queue dependable Keep navigation and list state understandable. #### DESK-101 — Keep shared queue links useful after refresh **Story · Medium priority · Foundational** noCV practice brief v5 · DESK-101 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 shift lead shares the unassigned billing queue, but recipients land on All tickets. Put filters in the URL so opening the link, refreshing, and using Back retain the intended view. Acceptance criteria - Status, team, and reference filters round-trip through the URL. - Unknown filter values use documented defaults without crashing. - Back restores the preceding filters and clears any cursor invalidated by them. Implementation constraints - Reference search targets synthetic ticket IDs; customer message text must not enter query parameters. Verification - Open team=billing and status=unassigned in a fresh tab and inspect the request. - Use an unknown status, then navigate Back after two filter changes; verify fallback and history order. Deliverables - Queue URL parser and browser navigation regression case Rollout and recovery: Enable URL filters for the internal queue; a flag restores the default queue without invalidating ticket links. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-102 — Separate an empty queue from a failed request **Bug · High priority · Foundational** noCV practice brief v5 · DESK-102 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Accessibility 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. During an API outage the console said No tickets, and an agent assumed the queue was clear. Give loading, empty, stale, and failed responses distinct presentations. Acceptance criteria - An empty successful response shows active filters and a clear-filters action. - A failed refresh retains previously loaded rows and labels them stale. - Retry fetches the active query once and exposes an accessible error if it fails again. Implementation constraints - Keep the last successful response while refreshing. Verification - Return an empty successful page and verify no outage message appears. - Load three rows, reject refresh, then recover on retry; rows persist until replacement. Deliverables - Explicit queue request states and failure screenshots Rollout and recovery: Release state rendering independently; revert the presentation component if the queue becomes unusable. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-103 — Stop a late search response replacing the current queue **Bug · High priority · Intermediate** noCV practice brief v5 · DESK-103 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the queue dependable. Depends on: DESK-101, DESK-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. On a slow connection, searching DL-42 and immediately clearing the field sometimes repopulates the screen with DL-42 results. Make response ownership follow the active query. Acceptance criteria - Only a response for the active query updates rows, counts, or errors. - Changing filters abandons the previous page cursor. - Unmounting the queue prevents late responses from changing visible state. Implementation constraints - Guard against adapters that resolve after cancellation. Verification - Resolve two requests in reverse order and confirm the last selection wins. - Reject a superseded request after the current one succeeds; no stale error appears. Deliverables - Query ownership fix and deterministic out-of-order response test Rollout and recovery: Canary with the support pilot; revert the coordinator if current-query results stop loading. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. ### Protect the conversation Keep drafts, revisions, and focus tied to the right ticket. #### DESK-104 — Restore the right reply draft when switching tickets **Story · High priority · Intermediate** noCV practice brief v5 · DESK-104 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Agents alternate between conversations while checking orders. The editor resets on every switch, and one experimental fix restored a draft into the wrong customer thread. Acceptance criteria - Draft keys include organization, signed-in agent, and ticket. - Returning to a ticket restores its text without copying it to another conversation. - Sign-out clears local drafts; storage refusal leaves editing usable with a persistence notice. Implementation constraints - Use synthetic text and never record draft content in analytics. Verification - Write different drafts on two tickets, switch repeatedly, and reload in the same account. - Switch organizations and simulate quota failure; no prior-account draft appears and typing still works. Deliverables - Scoped draft store and account-switch regression coverage Rollout and recovery: Start with session-scoped storage; disable persistence and retain the in-memory editor if corruption is reported. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-105 — Make ticket switching predictable from the keyboard **Task · Medium priority · Intermediate** noCV practice brief v5 · DESK-105 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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 agent navigating by keyboard loses their place after closing ticket details. Define focus behavior for opening, closing, and removing the selected row. Acceptance criteria - Opening details moves focus to the detail heading or first intentional control. - Closing returns focus to the originating row or a documented adjacent fallback. - Shortcuts do not fire in text inputs or during input method composition. Implementation constraints - Shortcuts supplement semantic controls and the ordinary tab sequence. Verification - Open and close details using only the keyboard and inspect focus. - Remove the originating row while details are open, then close; focus remains visible and useful. Deliverables - Focus restoration and keyboard walkthrough notes Rollout and recovery: Ship focus restoration before shortcuts; disable shortcuts separately if they conflict with editing. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-106 — Show assignment conflicts without pretending a save worked **Bug · High priority · Advanced** noCV practice brief v5 · DESK-106 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the conversation. Depends on: DESK-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Two leads assign the same ticket within a second. One console displays its optimistic assignment forever even though the API rejected the stale revision. Acceptance criteria - Writes include the last observed ticket revision. - A conflict restores authoritative assignment and explains the competing update. - An older rollback cannot overwrite a newer confirmed assignment. Implementation constraints - The API remains authoritative; never automatically retry a stale assignment. Verification - Accept an assignment and verify the returned revision replaces the local one. - Interleave two changes with a conflict arriving last; the newest authoritative owner remains visible. Deliverables - Revision-aware assignment flow and interleaving tests Rollout and recovery: Enable for one team and inspect conflicts; fall back to confirmed saves if optimistic rollback proves unreliable. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. ### Handle interruptions Recover from partial failures and concurrent work. #### DESK-107 — Report partial bulk-close results per ticket **Story · Medium priority · Advanced** noCV practice brief v5 · DESK-107 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-106. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Closing 25 conversations returns 22 successes, two permission denials, and one revision conflict. Today a green toast appears and every selected row disappears. Acceptance criteria - Successful IDs leave the queue only if its filter excludes closed work. - Denied and conflicting tickets remain selected with individual reasons. - Retry targets retryable failures without replaying confirmed closes. Implementation constraints - Interpret the result per ID; a successful HTTP status does not mean every item succeeded. Verification - Run mixed outcomes and compare row visibility and selection with each result. - Inspect retry IDs; denied and already closed items are excluded. Deliverables - Bulk result summary and mixed-outcome integration test Rollout and recovery: Limit the first release to 25 tickets; disable bulk close while retaining individual close on regression. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-108 — Reconcile an uncertain reply send after a connection drop **Bug · Urgent priority · Expert** noCV practice brief v5 · DESK-108 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-104, DESK-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Distributed systems 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 server accepts a reply, but Wi-Fi drops before acknowledgement. Clicking Send again duplicates the email. Model an uncertain result and recover through operation lookup. Acceptance criteria - One operation key survives timeout and explicit retry. - Uncertain sending preserves the draft and checks status before clearing it. - Changed text receives a new operation only after reconciliation; account changes stop status polling. Implementation constraints - Use a stubbed idempotent send/status contract; actual email delivery is excluded. Verification - Accept sending but drop the response, then report accepted from lookup; display one reply. - Return unknown and then unavailable from lookup; preserve the draft and prevent an unkeyed duplicate. Deliverables - Reply send state machine and lost-acknowledgement test Rollout and recovery: Pilot with synthetic mailboxes; disable the new sending flow if operation reconciliation cannot be trusted. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. #### DESK-109 — Keep a long conversation responsive without hiding context **Task · Medium priority · Advanced** noCV practice brief v5 · DESK-109 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruptions. Depends on: DESK-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Frontend 30% · Accessibility 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. An 800-message synthetic conversation makes expanding attachments slow. Reduce initial rendering while preserving chronological reading and position when older messages load. Acceptance criteria - Initial rendering uses a bounded window and explicit load-older control. - Prepending older messages preserves the visible anchor and keyboard focus. - A before/after profile on the same fixture records the performance budget and measurement environment. Implementation constraints - Prefer explicit pagination if virtualization would break assistive-technology reading order. Verification - Profile the 800-message fixture and load two older pages without a scroll jump. - Fail and retry an older-page request; no messages duplicate and the current position remains. Deliverables - Bounded message rendering and reproducible profile note Rollout and recovery: Enable above an agreed conversation size; restore full rendering if reading order regresses. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. ### Prepare the next shift Make the release diagnosable and supportable. #### DESK-110 — Give support a useful report when the console fails **Chore · Medium priority · Intermediate** noCV practice brief v5 · DESK-110 · A support console that survives a busy shift Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare the next shift. Depends on: DESK-107, DESK-108, DESK-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Privacy engineering 30% · 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. On-call receives screenshots saying It stopped working with no clue whether loading, assignment, or sending failed. Add redacted diagnostics and a release handoff. Acceptance criteria - Diagnostics include build version, operation category, timestamp, and safe correlation ID. - Customer text, drafts, tokens, and raw responses are excluded. - Copying diagnostics after failure preserves current draft and navigation. Implementation constraints - Use a field allowlist and document the owner of each operation category. Verification - Trigger sending failure and match its correlation ID to the synthetic trace. - Put secret-like strings in messages and errors; copied diagnostics contain none. Deliverables - Redacted diagnostics panel and one-page console runbook Rollout and recovery: Enable diagnostic copying for the pilot; hide it immediately if excluded content appears. Project prerequisites: A ticket-list and reply API contract to implement or stub Synthetic conversations across two organizations with revision conflicts Engineer value: Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes. Company value: Inspect how an engineer protects agent work and handles failures that interrupt support operations. 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. ## FORM — Purchase requests without spreadsheet follow-ups The fictional Beacon operations team buys equipment through a browser form. Finance checks totals, departments, and quotes. Scope is one currency per request and an approval API contract; payments and accounting integration are excluded. **Field:** Frontend. **Suggested stack:** Vue, TypeScript, CSS Modules, Vitest, Playwright. **Engineer value:** Practice form modeling, exact totals, revision handling, and collaboration under failure. **Company value:** Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. **Delivery agreement:** Each issue is a bounded pull request against one shared form. The complete project is optional; document mocked APIs. ### Setup prerequisites - Synthetic department and cost-center directory - Draft, submission, and approval API fixtures ### Capture the request Make entry accurate and accessible. #### FORM-101 — Point requesters to the field that needs fixing **Story · Medium priority · Foundational** noCV practice brief v5 · FORM-101 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the request. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Accessibility 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 incomplete request produces only Invalid request. Add field feedback and an error summary for vendor, business reason, and delivery date. Acceptance criteria - Invalid submission focuses a summary with links to fields. - Each error is associated with its field and stays visible until resolved. - Entered values survive client and server validation failures. Implementation constraints - Map known server field errors and use a safe general fallback for unknown errors. Verification - Submit an empty form by keyboard and follow each summary link. - Return an unknown server validation code; preserve values and display an actionable general error. Deliverables - Accessible validation summary and server-error mapping cases Rollout and recovery: Ship behind the form flag; restore the earlier route if requesters cannot correct errors. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-102 — Make the total match the submitted line items **Bug · High priority · Intermediate** noCV practice brief v5 · FORM-102 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the request. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Three items at 19.99 sometimes display extra decimal digits. Finance also found a preview total that differed from the payload after a quantity edit. Acceptance criteria - One calculation path derives display and payload totals from integer minor units. - Fractional quantities, negative prices, overflow, and mixed currencies are rejected. - Editing or removing a line immediately updates the same total. Implementation constraints - Document the fixed two-decimal practice currency and rounding rule; conversion is excluded. Verification - Enter three units at 19.99 and compare preview and payload at 59.97. - Try overflow and negative amounts; submission is blocked with field errors. Deliverables - Pure total calculator and boundary fixtures Rollout and recovery: Compare old and new totals on synthetic requests; block submission rather than use inaccurate arithmetic on mismatch. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-103 — Clear an orphaned cost center when department changes **Bug · Medium priority · Foundational** noCV practice brief v5 · FORM-103 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the request. Depends on: FORM-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Selecting Marketing / Events and then changing to Engineering leaves Events hidden in the payload. The reviewer has to send the request back. Acceptance criteria - Department changes clear any incompatible cost center. - Loading and unavailable directory states differ from an empty directory. - A previous department response cannot replace active options. Implementation constraints - Store stable directory IDs and explain why a selection was cleared. Verification - Switch Marketing / Events to Engineering; the field and payload both lose Events. - Reverse response order and reject the active request; stale options remain unavailable. Deliverables - Dependent-select fix and delayed-directory tests Rollout and recovery: Release after synthetic department-switch checks; prevent submission if required directory data is unavailable. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. ### Keep work recoverable Preserve drafts and supporting documents. #### FORM-104 — Save drafts without overwriting a second browser tab **Story · High priority · Advanced** noCV practice brief v5 · FORM-104 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep work recoverable. Depends on: FORM-102, FORM-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. A requester edits quantities in one tab and the explanation in another. Background autosave overwrites whichever tab saved first. Acceptance criteria - Autosave includes the loaded revision and serializes local writes. - Conflicts pause autosave and offer reload or a reviewable copy of local edits. - Navigating away with unsaved changes triggers a meaningful warning where supported. Implementation constraints - Never merge money fields automatically; preserve local edits for explicit conflict resolution. Verification - Save normally and verify the saved indicator follows the acknowledged revision. - Race two tabs, then fail recovery fetch; local edits remain and autosave stays paused. Deliverables - Revision-aware draft coordinator and two-tab conflict reproduction Rollout and recovery: Pilot manual saves before autosave; disable autosave without changing stored drafts if conflicts rise. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-105 — Show attachment quarantine and upload recovery clearly **Story · Medium priority · Intermediate** noCV practice brief v5 · FORM-105 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep work recoverable. Depends on: FORM-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · 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. Quotes look attached immediately even though the upload service can reject or quarantine them. Requesters submit before learning the reviewer cannot open the PDF. Acceptance criteria - Uploading, scanning, accepted, rejected, and failed have distinct labels. - Submission stays unavailable while a required quote is pending or rejected. - Retry uses the upload operation contract; removal cancels pending UI work. Implementation constraints - Treat names and service messages as untrusted text; scanning uses API fixtures here. Verification - Advance an upload from scanning to accepted and verify submission becomes available. - Reject a file and resolve a removed upload late; neither appears accepted. Deliverables - Attachment state component and upload fixture scenarios Rollout and recovery: Pilot quote-required requests; disable new attachment submissions if accepted state cannot be reconciled. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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 approval trustworthy Expose changes and protect submission boundaries. #### FORM-106 — Show finance what changed since their last review **Story · High priority · Advanced** noCV practice brief v5 · FORM-106 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make approval trustworthy. Depends on: FORM-104, FORM-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. After clarification, a requester changes both the explanation and amount. The review page says Updated without identifying which lines changed. Acceptance criteria - The view compares two explicit immutable revisions. - Stable line IDs identify additions, removals, and old/new values. - Collapsing unchanged fields keeps total difference and revision identifiers visible. Implementation constraints - Use the shared money calculator; array position is not a line identity. Verification - Reorder unchanged lines and confirm no false replacements appear. - Remove one line and increase another; verify both changes, total difference, and a missing-baseline error. Deliverables - Revision comparison view and change-set fixtures Rollout and recovery: Add a comparison tab; hide it on regression while preserving both original revision pages. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-107 — Close the duplicate-submit gap after a slow response **Bug · High priority · Expert** noCV practice brief v5 · FORM-107 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make approval trustworthy. Depends on: FORM-104, FORM-105. Difficulty: Expert. Estimated focused work: 195 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Distributed systems 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 15-second response prompts a refresh and second submission. Finance receives two approval requests. Coordinate submission identity with saved revisions and uncertain responses. Acceptance criteria - Submission waits for acknowledgement of the exact displayed draft revision. - One revision reuses a durable operation key across refresh and retry. - Uncertain results use status lookup; edits cannot silently reuse the old key for a different revision. Implementation constraints - Use the idempotency/status contract; disabling the button alone is insufficient. Verification - Drop the accepted response, refresh, and retry; one logical submission exists under the same operation key. - Edit during failed autosave and submit; no unsaved or mismatched revision is sent. Deliverables - Submission coordinator and refresh-after-timeout test Rollout and recovery: Pilot with one queue and inspect operation conflicts; disable new submissions on reconciliation failure while preserving drafts. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-108 — Retire approval controls when authority changes **Bug · High priority · Intermediate** noCV practice brief v5 · FORM-108 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make approval trustworthy. Depends on: FORM-106. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. An approver leaves the page open past delegation expiry. Approve fails, but controls remain active and the page incorrectly labels the request handled. Acceptance criteria - Denial preserves request state and removes stale controls after authority refresh. - Organization switching clears previous request and permissions before rendering new context. - Access-loss messages omit private authorization diagnostics. Implementation constraints - UI checks improve interaction; the API must authorize every action independently. Verification - Approve with current authority and display only the confirmed result. - Expire delegation and switch organizations mid-request; no success state or old request content appears. Deliverables - Authority-refresh handling and denied-approval browser case Rollout and recovery: Release denial handling independently; disable approvals separately while preserving permitted reading. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. ### Validate the handoff Keep the workflow usable under team conditions. #### FORM-109 — Make a 40-line request usable on a narrow screen **Task · Medium priority · Intermediate** noCV practice brief v5 · FORM-109 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate the handoff. Depends on: FORM-102, FORM-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. At 200% zoom, a sticky total covers the final row and horizontal scrolling separates quantity inputs from labels. Fix the equipment-request layout. Acceptance criteria - Labels, values, errors, and remove actions remain associated at the agreed narrow viewport and zoom. - The total and footer never cover focusable content. - Long vendor names and 40 lines remain readable without losing review information. Implementation constraints - Use semantic CSS; do not replace rows with unlabelled visual cards. Verification - Review the 40-line fixture by keyboard at 200% zoom and capture its final row. - Use a long vendor and invalid quantity; the error remains visible without horizontal page overflow. Deliverables - Responsive line-item layout and zoom walkthrough Rollout and recovery: Preview on agreed finance viewports; revert the layout if associations or actions become inaccessible. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. #### FORM-110 — Check the request-return-resubmit journey before release **Chore · Medium priority · Advanced** noCV practice brief v5 · FORM-110 · Purchase requests without spreadsheet follow-ups Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate the handoff. Depends on: FORM-107, FORM-108, FORM-109. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 70% · Frontend 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. Form tests passed, but the last release lost a quote when finance returned a request. Add a deterministic journey through return, edit, and resubmission. Acceptance criteria - The journey covers submission, finance return, changed amount, and review of the new revision. - Attachment and request identities stay stable across revision creation. - Resubmission failure leaves the earlier revision readable and the new draft recoverable. Implementation constraints - Synthetic users and API fixtures establish workflow behavior, not live-service readiness. Verification - Run twice from clean fixtures and compare final revision relationships. - Fail after draft save before submission acknowledgement; attachments survive and requests do not duplicate. Deliverables - Workflow browser check and release/rollback checklist Rollout and recovery: Gate form releases on this journey; stop rollout on identity loss and restore the prior form build. Project prerequisites: Synthetic department and cost-center directory Draft, submission, and approval API fixtures Engineer value: Practice form modeling, exact totals, revision handling, and collaboration under failure. Company value: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions. 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. ## FIELD — An offline workday for field technicians The fictional Vale facilities team services equipment in basements with poor reception. Technicians receive assigned work orders, record checks, and attach synthetic equipment photos. The practice app uses an on-device database and a stub sync service; background location tracking is excluded. **Field:** Mobile. **Suggested stack:** React Native, TypeScript, SQLite, Jest, Android emulator. **Engineer value:** Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. **Company value:** Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. **Delivery agreement:** Deliver selected tickets against synthetic work orders. Full project phases are optional and do not require a live dispatch service. ### Setup prerequisites - Synthetic work orders and a revisioned sync contract - An emulator with controllable connectivity and app lifecycle ### Start the offline day Make downloaded work clear and durable. #### FIELD-101 — Tell technicians which work orders are available offline **Story · High priority · Foundational** noCV practice brief v5 · FIELD-101 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Start the offline day. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. The assignment list looks ready in the depot, but opening a work order downstairs produces an endless spinner. Distinguish listed work from fully downloaded details. Acceptance criteria - Each order states whether required details are cached, downloading, or unavailable offline. - Opening an uncached order offline shows a recoverable explanation. - The app shows the last successful download time without presenting cached data as current. Implementation constraints - Use a connectivity adapter for fixtures; an online signal does not guarantee the API is reachable. Verification - Download an order, disable connectivity, and open its cached details. - Open a listed but uncached order offline and simulate a reachable network with a failed API; neither path spins indefinitely. Deliverables - Offline-availability presentation and connectivity fixture cases Rollout and recovery: Pilot with a small depot dataset; retain read-only cached access if download status regresses. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-102 — Commit a completed checklist item before showing it saved **Bug · High priority · Intermediate** noCV practice brief v5 · FIELD-102 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Start the offline day. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Database 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 technician checks Replace intake filter and force-closes the app. On reopening, the check is gone even though the screen showed Saved. Acceptance criteria - Saved appears only after the local transaction commits. - A committed answer survives process termination and reopening. - Database write failure preserves the editable value and clearly marks it unsaved. Implementation constraints - Keep persistence behind a repository boundary; component state alone is not durable. Verification - Commit an answer, terminate the app, and verify the answer after restart. - Inject a database-full error before commit; the UI must not claim success or discard the typed value. Deliverables - Transactional checklist persistence and restart regression test Rollout and recovery: Enable on pilot devices with synthetic work; stop editing if local persistence is unavailable rather than falsely confirming saves. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-103 — Make inspection inputs usable with large text **Task · Medium priority · Foundational** noCV practice brief v5 · FIELD-103 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Start the offline day. Depends on: FIELD-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Mobile 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 technician increases system text size. Pass/Fail controls overlap equipment names, and the last input disappears beneath the keyboard. Acceptance criteria - The agreed largest supported text setting keeps labels and choices readable. - Focused fields can scroll above the keyboard without hiding their error messages. - Each checklist choice has an accessible name that includes its inspection item. Implementation constraints - Do not disable system text scaling to make the layout fit. Verification - Complete a six-item inspection at large text size with the on-screen keyboard. - Use a long equipment name and an invalid reading; controls and errors remain reachable through assistive navigation. Deliverables - Adaptive inspection layout and emulator accessibility walkthrough Rollout and recovery: Review on the smallest supported test device; revert affected layout components if input becomes unreachable. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. ### Record the visit Capture work and attachments through interruptions. #### FIELD-104 — Keep photo evidence attached after the app is suspended **Bug · High priority · Advanced** noCV practice brief v5 · FIELD-104 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Record the visit. Depends on: FIELD-102. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Storage systems 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 technician takes an equipment photo, answers a phone call, and returns to a blank attachment tile. The draft stored a temporary camera URI that no longer exists. Acceptance criteria - Attachment metadata becomes saved only after the file is copied into app-owned storage. - Restart restores pending attachments with a clear missing-file recovery action when necessary. - Cancelled capture and failed copies leave neither dangling records nor orphaned temporary files. Implementation constraints - Use synthetic equipment images; permission to capture does not authorize unrelated gallery access. Verification - Capture, suspend, terminate, and reopen; the saved attachment remains available. - Delete the source URI before copying and cancel another capture; no accepted attachment or orphaned pending row remains. Deliverables - Durable attachment staging and lifecycle failure cases Rollout and recovery: Pilot capture separately from uploads; disable new capture if staged-file recovery fails while preserving existing files. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-105 — Explain why a work order is not ready to finish **Story · Medium priority · Intermediate** noCV practice brief v5 · FIELD-105 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Record the visit. Depends on: FIELD-102, FIELD-103, FIELD-104. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. Finish visit is disabled with no explanation when a required reading or photo is missing. Technicians tap through every section to find the blocker. Acceptance criteria - A completion summary lists missing required answers and attachments with navigation actions. - Optional notes never block completion. - Finishing offline creates a pending completion operation and labels it as awaiting sync rather than server-confirmed. Implementation constraints - Derive readiness from the current local revision and the downloaded checklist version. Verification - Fill the required inputs and finish offline; a pending operation is visible after restart. - Remove a required photo and leave optional notes empty; only the photo blocks completion. Deliverables - Completion-readiness summary and offline finish cases Rollout and recovery: Enable the summary before completion changes; pause finishing if checklist versions cannot be resolved. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. ### Reconnect safely Resolve retries, reassignment, and conflicting edits. #### FIELD-106 — Drain the sync queue without duplicating completed visits **Task · High priority · Advanced** noCV practice brief v5 · FIELD-106 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconnect safely. Depends on: FIELD-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Distributed systems 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. Reception returns briefly and drops again during sync. The same completed visit is sent twice, while a later note disappears after a failed batch. Acceptance criteria - Each queued operation has a stable identity and advances only after acknowledgement. - Per-order dependencies preserve answer and completion ordering while unrelated orders can progress. - Retry uses bounded backoff and keeps unacknowledged operations durable across restart. Implementation constraints - The fixture service deduplicates operation IDs; do not assume a timeout means the server rejected a write. Verification - Acknowledge a batch and verify only confirmed queue entries leave local storage. - Drop a response after server acceptance and restart; retries keep the same IDs and produce one logical completion. Deliverables - Durable sync queue processor and interrupted-batch tests Rollout and recovery: Limit initial batch size and observe backlog age; pause queue draining on repeated protocol errors without deleting pending work. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-107 — Keep reassigned work from being silently completed offline **Bug · High priority · Expert** noCV practice brief v5 · FIELD-107 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconnect safely. Depends on: FIELD-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 40% · Security 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. Dispatch reassigns a job while the original technician is underground. That device later uploads completion against the old assignment. Preserve the technician’s work while honoring current server authority. Acceptance criteria - Sync includes the assignment revision that authorized the offline visit. - Reassignment rejection moves local work into an explicit review-required state without marking the job complete. - The technician can inspect their unsynced notes and a redacted export while server-only actions remain blocked. Implementation constraints - Do not automatically apply old work to the new assignee; supervisor resolution is a documented stub contract. Verification - Sync a completion with the current assignment revision and confirm acceptance. - Reassign before reconnecting and reject the old revision; retain local work and prevent repeated automatic completion retries. Deliverables - Reassignment conflict flow and preserved-work recovery fixture Rollout and recovery: Pilot with forced reassignment scenarios; disable offline finishing if authority conflicts cannot retain work safely. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-108 — Resume a large photo upload without restarting the whole queue **Story · Medium priority · Advanced** noCV practice brief v5 · FIELD-108 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconnect safely. Depends on: FIELD-104, FIELD-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 40% · Storage systems 40% · 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. One 12 MB equipment photo repeatedly fails halfway through and blocks all completed visits. Integrate the resumable-upload contract and isolate attachment progress from unrelated operations. Acceptance criteria - Committed upload offsets are persisted and reconciled with the service after reconnect. - An expired upload session starts a new session without losing the source file. - Failure of one attachment does not block sync for another independent work order. Implementation constraints - Use small synthetic chunks in tests; server file integrity and scanning remain separate responsibilities. Verification - Interrupt after two acknowledged chunks and resume from the server-confirmed offset. - Expire the session and simulate a missing local file; show repair guidance and allow another work order to sync. Deliverables - Resumable upload adapter and offset/session recovery cases Rollout and recovery: Enable for larger attachments first; pause uploads and keep staged files if offset reconciliation fails. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. ### Support the rollout Protect devices and give support safe diagnostics. #### FIELD-109 — Clear a shared device without dropping pending work invisibly **Story · High priority · Advanced** noCV practice brief v5 · FIELD-109 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support the rollout. Depends on: FIELD-107, FIELD-108. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Mobile 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. Two technicians share a tablet between shifts. Sign-out currently leaves cached addresses for the next user, but blindly deleting storage would also erase unsynced repairs. Acceptance criteria - Sign-out reports pending work before an explicit discard or sync choice. - Confirmed sign-out removes account-scoped database rows, staged files, and credentials from the usable app context. - Signing in as a different technician cannot render or sync the prior account’s data. Implementation constraints - Document the limits of app-level deletion; do not claim forensic erasure or export data automatically. Verification - Sync all work, sign out, and sign in as another user; no previous records appear. - Fail sync with pending attachments and choose cancel; preserve the current session and work without exposing it to another account. Deliverables - Shared-device sign-out flow and account-boundary tests Rollout and recovery: Require this check before shared-device pilots; disable account switching if cleanup cannot be confirmed. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. #### FIELD-110 — Expose sync health that depot support can act on **Chore · Medium priority · Intermediate** noCV practice brief v5 · FIELD-110 · An offline workday for field technicians Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support the rollout. Depends on: FIELD-106, FIELD-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Site reliability 30% · Privacy 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. Depot support cannot distinguish a device waiting for Wi-Fi from one stuck on an expired upload. Add an account-local sync health page and a safe support bundle. Acceptance criteria - The page separates queued, retrying, blocked, and acknowledged counts with last successful sync time. - The bundle includes app/schema versions and operation categories but excludes notes, photos, addresses, and tokens. - A retry action obeys the same queue rules and cannot bypass blocked authority conflicts. Implementation constraints - Keep diagnostic storage bounded and document one recovery action per blocker category. Verification - Create a retryable upload and a reassignment blocker; verify distinct states and actions. - Seed private fixture content and inspect the exported bundle; none of it is present and blocked work is not force-sent. Deliverables - Sync health screen and depot troubleshooting note Rollout and recovery: Enable for pilot support staff; remove bundle export if redaction fails while retaining local status labels. Project prerequisites: Synthetic work orders and a revisioned sync contract An emulator with controllable connectivity and app lifecycle Engineer value: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows. Company value: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment. 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. ## TRIP — A commuter planner that explains uncertainty The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection. **Field:** Mobile. **Suggested stack:** Kotlin, Jetpack Compose, Room, JUnit, Android emulator. **Engineer value:** Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. **Company value:** Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. **Delivery agreement:** Work from fixed fixtures and an emulator. Deliver individual issues or three-to-four focused phase increments. ### Setup prerequisites - Synthetic timetable with explicit time zones and service dates - Departure, alert, and permission adapters with failure fixtures ### Make journeys readable Present stable saved trips and correct service times. #### TRIP-101 — Give saved journeys names that survive station renames **Story · Low priority · Foundational** noCV practice brief v5 · TRIP-101 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · Database 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. Central Station becomes Central Exchange in a feed update and a saved commute disappears. Save journeys by station identity and let riders keep a personal label. Acceptance criteria - Saved journeys use stable station IDs and optional rider labels. - Renaming a station updates its display without duplicating the journey. - A removed station shows an unavailable state with an edit action instead of silently deleting the journey. Implementation constraints - Limit labels and render them as text; no account sync is required. Verification - Save Home to Office and apply a station-name update; identity and label remain. - Remove a referenced station and reload; the saved journey remains editable with an unavailable endpoint. Deliverables - Saved-journey model and station-update fixture tests Rollout and recovery: Migrate a copied local fixture database first; retain original IDs if label migration fails. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-102 — Keep the last train on the correct service day **Bug · High priority · Advanced** noCV practice brief v5 · TRIP-102 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: No preceding ticket. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · Integrations 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 Saturday service departing after midnight appears under Sunday and disappears from the late-night search. The feed expresses service-day times beyond 24:00. Acceptance criteria - Service date and elapsed service-day time map to an instant using the feed time zone. - Display uses rider-friendly local date/time while retaining the original service identity. - Unsupported or ambiguous feed times produce an explicit data error rather than a guessed departure. Implementation constraints - Write the conversion policy for daylight-saving transitions; do not parse service times as ordinary clock-only strings. Verification - Resolve a Saturday 25:10 service to the expected next-calendar-day instant and keep Saturday service identity. - Exercise the agreed clock-change fixtures and malformed time input; no negative journey duration or silent guess appears. Deliverables - Service-time conversion module and boundary fixture table Rollout and recovery: Compare converted times against curated synthetic examples; hide affected feed entries if conversion fails. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-103 — Explain transfers without relying on line colors **Task · Medium priority · Foundational** noCV practice brief v5 · TRIP-103 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: TRIP-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Mobile 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 journey card distinguishes Line 4 from Line 8 only by color. Riders using grayscale or a screen reader cannot tell where to change. Acceptance criteria - Each leg shows mode, line label, destination, and boarding/alighting stops in reading order. - Transfers state walking and waiting time in text. - Large text and grayscale preserve every required leg distinction. Implementation constraints - Keep decorative map graphics out of the essential accessible description. Verification - Read a two-transfer fixture with assistive navigation and compare spoken order to itinerary order. - Use grayscale and large text; a canceled leg must remain identifiable without its color or icon. Deliverables - Accessible journey-leg card and device walkthrough Rollout and recovery: Release text semantics with the existing card layout first; revert visual changes independently if leg details become clipped. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Handle changing feeds Keep live data, cancellations, and stale results coherent. #### TRIP-104 — Label stale departures when the live feed stops responding **Story · High priority · Intermediate** noCV practice brief v5 · TRIP-104 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing feeds. Depends on: TRIP-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Real-time systems 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 departures screen keeps displaying an old prediction after a feed outage. A rider mistakes a 12-minute-old estimate for a live arrival. Acceptance criteria - Predictions show source update time and become stale at the configured fixture threshold. - Scheduled times remain available but are visibly distinguished from current predictions. - A failed refresh preserves readable departures and provides a retry action. Implementation constraints - Calculate staleness from trusted feed timestamps with a documented clock-skew allowance. Verification - Advance a fake clock across the freshness threshold and inspect the label change. - Return a future-dated update beyond allowed skew and then fail refresh; do not display it as trustworthy live data. Deliverables - Departure freshness policy and fake-clock tests Rollout and recovery: Enable stale labels for one synthetic feed; disable live prediction display if timestamps cannot be validated. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-105 — Apply cancellation updates to the right departure instance **Bug · High priority · Advanced** noCV practice brief v5 · TRIP-105 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing feeds. Depends on: TRIP-104. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Real-time systems 30% · Data 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. Canceling the 08:10 Line 4 also marks tomorrow’s 08:10 as canceled because the cache key contains only the route. Reconcile alerts by departure identity. Acceptance criteria - Cancellation identity includes service date and trip instance rather than route label alone. - A newer correction can restore a departure while an older cancellation cannot overwrite it. - Unknown alert references remain diagnosable without canceling unrelated trips. Implementation constraints - Define ordering from feed revision metadata, not arrival order on the device. Verification - Cancel today’s instance and verify tomorrow’s matching route stays available. - Deliver correction and cancellation out of order; the newest revision wins and unknown IDs change no journey. Deliverables - Departure alert reducer and ordering regression tests Rollout and recovery: Shadow-reconcile synthetic alerts before display; fall back to a general service notice if precise mapping is unavailable. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Respect device conditions Handle lifecycle, reminders, and permissions deliberately. #### TRIP-106 — Stop refreshing a journey after the rider leaves it **Bug · Medium priority · Intermediate** noCV practice brief v5 · TRIP-106 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. Opening several saved journeys starts several permanent refresh loops. The app continues polling all of them in the background and occasionally displays the wrong result. Acceptance criteria - Only the visible journey owns an active foreground refresh loop. - Backgrounding pauses polling and foreground return performs one bounded freshness check. - Late results from a departed journey cannot update the active journey. Implementation constraints - Use lifecycle-aware cancellation plus request identity; do not request a background location service for refresh. Verification - Switch among three journeys and inspect that only one loop remains active. - Background during an in-flight request and return after expiry; exactly one fresh check occurs and stale results are ignored. Deliverables - Lifecycle-aware refresh coordinator and request-count tests Rollout and recovery: Pilot with a short foreground session trace; disable automatic refresh if loop ownership regresses and keep manual refresh. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-107 — Make departure reminders honest about permission and schedule changes **Story · Medium priority · Advanced** noCV practice brief v5 · TRIP-107 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-105, TRIP-106. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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 rider enables a reminder after denying notifications, then assumes an alert will arrive. Rescheduled departures also leave the old reminder behind. Acceptance criteria - Reminder state distinguishes requested, scheduled, denied, canceled, and expired. - Changing the departure revision cancels the old schedule before confirming its replacement. - The app offers an in-app alternative when device notification capability is unavailable. Implementation constraints - Request permission only after an explicit reminder action and disclose the limits of delivery timing. Verification - Allow notifications, schedule a reminder, then change departure time; one current schedule remains. - Deny permission and cancel the trip during rescheduling; no successful reminder claim or orphan schedule remains. Deliverables - Reminder state coordinator and permission-change cases Rollout and recovery: Pilot opt-in reminders on emulators and test devices; disable new scheduling if duplicate reminders are observed. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-108 — Recover a route search when the timetable changes mid-session **Bug · High priority · Expert** noCV practice brief v5 · TRIP-108 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-101, TRIP-105, TRIP-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Database 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 timetable refresh replaces station and trip data while a route calculation still reads the old version. The result combines a new platform with a removed connection. Acceptance criteria - A search reads one timetable snapshot/version for its entire calculation. - A result from an obsolete snapshot is explicitly revalidated or replaced before being labeled current. - Interrupted dataset replacement leaves either the old complete dataset or the new complete dataset available. Implementation constraints - Use synthetic small datasets and a local transaction; implementing a nationwide routing engine is excluded. Verification - Swap timetable versions during calculation and verify every returned leg belongs to one version. - Fail replacement halfway through and restart; searches use a complete version and unavailable connections are not invented. Deliverables - Versioned timetable handoff and interrupted-update tests Rollout and recovery: Stage updates beside the active dataset; switch the active pointer back if validation fails and retain prior-version diagnostics. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Prepare a measured release Explain limitations and verify the complete journey. #### TRIP-109 — Offer nearby stops without making location mandatory **Story · Medium priority · Intermediate** noCV practice brief v5 · TRIP-109 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a measured release. Depends on: TRIP-101, TRIP-103. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Mobile 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 first screen demands location before showing any journeys. A rider who declines cannot search by station even though the timetable supports it. Acceptance criteria - Station search and saved journeys work without location permission. - Nearby stops request location only after an explicit action and show how approximate results are used. - Denial, timeout, and unavailable location return to a usable manual search without repeated prompts. Implementation constraints - Use a one-shot coarse-location adapter and do not persist coordinates in generic analytics. Verification - Deny location on first use and complete a manual station search. - Return an approximate fix and then a timeout; nearby results disclose approximation and manual search remains accessible. Deliverables - Optional nearby-stop flow and permission-free journey check Rollout and recovery: Release manual search before nearby suggestions; disable the location adapter if denial recovery or privacy checks fail. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-110 — Rehearse a disrupted commute with fixed feed data **Chore · Medium priority · Advanced** noCV practice brief v5 · TRIP-110 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a measured release. Depends on: TRIP-107, TRIP-108, TRIP-109. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Mobile 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. Most checks cover a clean daytime trip. Before the pilot, rehearse a saved late-night commute through feed outage, cancellation correction, and app restart. Acceptance criteria - A deterministic scenario records which timetable revision, departure identity, and freshness label appear at each step. - Restart preserves the saved journey without restoring an obsolete reminder. - The handoff states fixture coverage and unresolved live-feed assumptions explicitly. Implementation constraints - Use a controllable clock and adapters; do not depend on actual transit services or notification delivery. Verification - Run the rehearsal twice and compare the ordered visible states. - Inject an invalid feed timestamp and an interrupted dataset update; no current-live label or mixed-version trip appears. Deliverables - Disruption rehearsal script and pilot support checklist Rollout and recovery: Require the fixed-data rehearsal before app updates; pause pilot expansion on misleading freshness or reminder state. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ## A11Y — A civic appointment flow people can complete The fictional Riverside desk books appointments for permit paperwork and library assistance. Its browser flow was assembled from separate forms and dialogs. Work uses synthetic availability and booking adapters; actual appointments and personal records are excluded. **Field:** Accessibility. **Suggested stack:** TypeScript, Semantic HTML, CSS Modules, Playwright, axe-core. **Engineer value:** Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. **Company value:** Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. **Delivery agreement:** Choose a bounded issue and record automated and manual checks separately. A passing scanner does not establish complete accessibility. ### Setup prerequisites - Synthetic services, slots, and booking API contract - Keyboard and screen-reader access for a documented manual check ### Enter the flow Make service selection and entry understandable. #### A11Y-101 — Replace clickable service tiles with a named selection group **Bug · High priority · Foundational** noCV practice brief v5 · A11Y-101 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enter the flow. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Service choices are clickable divs. Keyboard users cannot reach them, and a screen reader announces no selected service. Repair selection without changing the taxonomy. Acceptance criteria - Every service belongs to a semantic single-choice group with a visible label. - Selected value is announced and included in the form value. - Unavailable services explain their status and cannot be selected by keyboard or pointer. Implementation constraints - Prefer native radio inputs and associated labels over a custom interaction model. Verification - Choose Library assistance using only the keyboard and inspect the form value. - Try selecting an unavailable service through pointer and keyboard; selection remains unchanged and its reason is readable. Deliverables - Semantic service chooser and keyboard regression case Rollout and recovery: Release independently; restore native unstyled controls if decoration hides focus or selection. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-102 — Keep contact-field help and errors understandable together **Task · Medium priority · Foundational** noCV practice brief v5 · A11Y-102 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enter the flow. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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 phone-field error replaces the format hint, then disappears on the first keystroke while the value remains invalid. Give help and validation a coherent lifecycle. Acceptance criteria - Persistent help and current errors are associated with their field. - Submitted errors remain until correction or the next documented validation point. - Invalid submission provides a focusable summary linked to every invalid field. Implementation constraints - Do not announce errors on every keystroke; document validation timing. Verification - Submit an invalid phone and navigate from summary to field; hear both hint and error. - Correct one of two invalid fields and resubmit; only the remaining error appears and values persist. Deliverables - Contact validation semantics and assistive-technology notes Rollout and recovery: Apply to contact fields first; retain plain inline errors if enhanced summary behavior loses focus. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. ### Choose an appointment Handle date navigation and changing slots. #### A11Y-103 — Make month navigation work without a pointer **Story · High priority · Intermediate** noCV practice brief v5 · A11Y-103 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Choose an appointment. Depends on: A11Y-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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 calendar exposes 42 unnamed buttons and moves focus to the page top on month changes. Add a deliberate keyboard model and plain date-entry alternative. Acceptance criteria - Date controls announce full date, availability, and selection. - Changing month retains focus at a predictable date or documented month control. - Manual date entry uses the same availability validation and reports invalid dates clearly. Implementation constraints - Document the calendar keyboard model; shortcuts must not conflict with text entry. Verification - Select an available date across a month boundary by keyboard. - Enter an impossible date and navigate to an unavailable date; neither becomes selected and focus remains recoverable. Deliverables - Accessible date selection and month-boundary walkthrough Rollout and recovery: Keep manual entry during rollout; disable the custom calendar on keyboard-navigation regression. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-104 — Keep the booking action visible at high zoom **Bug · High priority · Intermediate** noCV practice brief v5 · A11Y-104 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Choose an appointment. Depends on: A11Y-102, A11Y-103. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. At 400% zoom the fixed step header and cookie banner cover the selected time and Continue button. Repair reflow across booking steps. Acceptance criteria - At the documented desktop viewport and 400% zoom, essential content reflows without horizontal page scrolling. - Fixed UI never covers focused fields, error links, or booking actions. - Long service names and expanded text spacing do not clip labels or values. Implementation constraints - Use normal flow where fixed positioning provides no user benefit. Verification - Complete service and slot selection at 400% zoom by keyboard. - Apply expanded text spacing and a long service name with an error summary; check clipping and focus obstruction. Deliverables - Reflow corrections and viewport/zoom evidence notes Rollout and recovery: Check every step before shared layout release; revert sticky behavior first if actions become obscured. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-105 — Recover when another visitor takes the chosen slot **Bug · High priority · Advanced** noCV practice brief v5 · A11Y-105 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Choose an appointment. Depends on: A11Y-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Frontend 30% · 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. The last 10:30 appointment is taken while a visitor enters contact details. Submission reports Slot unavailable and resets the entire flow. Acceptance criteria - Conflict preserves contact values and service while clearing the unavailable slot. - The conflict is announced once and focus moves to a useful recovery heading with alternatives. - A replacement needs explicit confirmation and current availability revision data. Implementation constraints - Never automatically book a different time; availability remains server-authoritative. Verification - Conflict the slot, choose 11:00, and finish without re-entering contact details. - Return no alternatives and fail refresh; explain the state without trapping focus or inventing availability. Deliverables - Slot-conflict recovery and accessible failure scenario Rollout and recovery: Exercise synthetic capacity conflicts before pilot; pause booking if contact recovery or slot identity is unreliable. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. ### Preserve progress Recover focus, drafts, and session interruptions. #### A11Y-106 — Announce availability changes without reading the whole page again **Task · Medium priority · Advanced** noCV practice brief v5 · A11Y-106 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Preserve progress. Depends on: A11Y-105. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Each refresh rewrites a large live region. A screen reader repeats all slots and interrupts contact entry even when nothing changed. Acceptance criteria - Unchanged slot lists generate no routine announcements. - Meaningful changes produce a short status without moving focus. - Loss of a selected slot takes priority over routine counts; stale request messages are ignored. Implementation constraints - Use a small status region and coalesce bursts; never mark the entire form live. Verification - Refresh identical data three times while typing; no repeated list announcement occurs. - Remove the selected slot while delayed old data arrives; announce loss once and retain current focus. Deliverables - Announcement coordinator and manual speech-output log Rollout and recovery: Pilot with routine announcements disabled; retain only actionable notices if speech becomes noisy. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-107 — Handle expiry without an inaccessible countdown trap **Story · High priority · Expert** noCV practice brief v5 · A11Y-107 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Preserve progress. Depends on: A11Y-102, A11Y-105, A11Y-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Frontend 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. A slow form session expires after details are entered. The countdown steals focus every second, and Extend reports success after the server session has ended. Acceptance criteria - Advance warning offers an accessible extension action without announcing each second. - Extension success requires server confirmation and preserves the active form location. - Expiry or uncertain extension preserves a scoped draft but requires session recovery and fresh slot validation before booking. Implementation constraints - Use a fake clock and session adapter; do not weaken expiry or record contact data in analytics. Verification - Extend before expiry by keyboard and verify confirmed continuation with focus restoration. - Race expiry and a lost extension response; expired authority cannot book, and recovery revalidates the slot. Deliverables - Session continuity state machine and expiry-race walkthrough Rollout and recovery: Pilot against short synthetic sessions; disable booking under ambiguous session authority while preserving recoverable drafts. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-108 — Return focus correctly after reviewing contact details **Bug · Medium priority · Advanced** noCV practice brief v5 · A11Y-108 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Preserve progress. Depends on: A11Y-104, A11Y-107. Difficulty: Advanced. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Edit contact opens a dialog from review. Closing returns focus to a control removed by session refresh, stranding keyboard users. Acceptance criteria - The dialog has a name, contained focus, and visible close action. - Closing restores the invoking control or a documented visible fallback if the step changed. - Recovery and dialog close cannot race focus into hidden or inert content. Implementation constraints - Use an accessible primitive with local styling and coordinate focus ownership across states. Verification - Edit and close normally; focus returns to Edit contact with revised details visible. - Expire the session while editing and close during recovery; focus lands on the current recovery heading. Deliverables - Dialog focus ownership fix and interleaved-state keyboard test Rollout and recovery: Enable only on review; switch to inline editing if dialog focus ownership regresses. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. ### Complete and verify Make confirmation and release evidence usable. #### A11Y-109 — Make confirmation usable on screen and in print **Story · Medium priority · Intermediate** noCV practice brief v5 · A11Y-109 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete and verify. Depends on: A11Y-105, A11Y-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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 screenshot-style confirmation cannot be selected, print cuts off the address, and appointment time omits the time zone. Acceptance criteria - Service, date, time zone, location, and reference are selectable semantic text. - Print includes all appointment details without navigation chrome or clipping. - Only confirmed bookings show confirmation, with an accessible copy-reference action. Implementation constraints - An HTML print view is sufficient; PDF generation is excluded. Verification - Confirm a synthetic appointment, copy its reference, and inspect print preview. - Return an uncertain result and use a long location; no false confirmation appears and reconciled print details remain complete. Deliverables - Semantic confirmation and print stylesheet Rollout and recovery: Release styling after booking-identity checks; retain plain-text details if print styling fails. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. #### A11Y-110 — Build a barrier-focused release check for booking **Chore · High priority · Advanced** noCV practice brief v5 · A11Y-110 · A civic appointment flow people can complete Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete and verify. Depends on: A11Y-106, A11Y-107, A11Y-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Quality 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. Scanners pass while keyboard testers still lose drafts after conflicts. Add a release check covering actual booking and recovery. Acceptance criteria - Checks cover keyboard completion, zoom, named controls, slot conflicts, and session recovery. - Automated assertions and manual observations are recorded separately with browser/tool versions. - Unresolved barriers name affected steps and usable fallbacks without claiming universal accessibility. Implementation constraints - Bound the manual matrix to agreed combinations and include a reproduction script per barrier. Verification - Run normal booking plus slot-conflict and session-expiry scenarios and record outcomes. - Introduce a missing dialog name or broken return focus in a local fixture; the relevant check detects it. Deliverables - Booking accessibility regression matrix and release decision note Rollout and recovery: Use before pilot expansion; block steps with unrecoverable barriers and retain the documented alternative flow. Project prerequisites: Synthetic services, slots, and booking API contract Keyboard and screen-reader access for a documented manual check Engineer value: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates. Company value: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability. 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. ## READ — A document reader that keeps people oriented The fictional Plainview handbook reader serves versioned HTML documents with headings, tables, footnotes, and annotations. Scope is accessible HTML rendering from a structured model; OCR and arbitrary PDF remediation are excluded. **Field:** Accessibility. **Suggested stack:** React, TypeScript, CSS Modules, Testing Library, Playwright. **Engineer value:** Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. **Company value:** Inspect how an engineer makes information usable while protecting document integrity and access boundaries. **Delivery agreement:** Each ticket targets one reader behavior. Use synthetic documents and record assumptions about the source model. ### Setup prerequisites - Versioned synthetic documents with stable section IDs - Annotation and document-access API contracts to stub ### Make content readable Preserve semantics and text preferences. #### READ-101 — Restore heading and table semantics in handbook chapters **Bug · High priority · Foundational** noCV practice brief v5 · READ-101 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make content readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Every source block becomes a styled div. Readers cannot navigate by heading, and table cells expose no header relationships. Acceptance criteria - Headings preserve validated source hierarchy in semantic elements. - Tables retain captions and source-model header associations. - Unsupported blocks show a clear fallback rather than silently disappearing. Implementation constraints - Validate the structured model; this ticket does not infer semantics from arbitrary visual formatting. Verification - Navigate by headings and inspect a table with row and column headers. - Supply an unsupported block and invalid hierarchy; content is not silently lost and validation identifies the issue. Deliverables - Semantic block renderer and document-model fixtures Rollout and recovery: Enable for validated documents; retain the accessible source view when model validation fails. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-102 — Let readers adjust text without losing their place **Story · Medium priority · Foundational** noCV practice brief v5 · READ-102 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make content readable. Depends on: READ-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Frontend 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. Increasing font size resets the chapter to the top, while dark theme leaves footnotes unreadable. Add preferences that preserve position and cover every content type. Acceptance criteria - Font size, spacing, and theme apply to body, footnotes, tables, and annotations. - Preference changes preserve the current section anchor. - System theme is the initial default and invalid stored preferences recover safely. Implementation constraints - Use semantic CSS variables and avoid fixed content heights. Verification - Resize text midway through a chapter; the current section stays in view. - Load corrupt preference data and test dark/system themes; content stays readable and defaults recover. Deliverables - Reader preferences and theme/content fixture page Rollout and recovery: Release session-local preferences first; disable persistence if stored values break rendering. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ### Keep the reader oriented Make search, contents, and bookmarks predictable. #### READ-103 — Navigate search matches without breaking document text **Story · Medium priority · Intermediate** noCV practice brief v5 · READ-103 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Accessibility 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. Highlighting rewrites innerHTML and removes links around matches. Keyboard users also cannot identify the current match. Acceptance criteria - Highlights preserve source text, links, and semantics. - Next/previous exposes index and total without rereading the chapter. - Clearing search restores normal reading at a sensible position. Implementation constraints - Treat queries as literal text and use structured ranges; never interpolate search text into HTML. Verification - Find a phrase spanning emphasis and follow the preserved link around a match. - Search markup-like text and a no-match query; nothing executes and match navigation is correctly disabled. Deliverables - Structured highlight layer and keyboard match-navigation tests Rollout and recovery: Enable for one renderer; disable highlighting separately while retaining plain results if semantics regress. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-104 — Keep contents links and footnote returns oriented **Bug · Medium priority · Intermediate** noCV practice brief v5 · READ-104 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-101, READ-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Contents links scroll to sections but leave focus in the sidebar. Following a footnote returns to the document top. Acceptance criteria - Contents navigation updates the URL and focuses the destination heading without obscuring it. - Footnotes offer a named return action to the originating reference. - Back restores the preceding meaningful reading anchor. Implementation constraints - Use stable source IDs and respect reduced motion for scrolling. Verification - Navigate by contents, follow a footnote, and return using only the keyboard. - Open a missing section link and use Back; show a useful fallback without trapping focus. Deliverables - Anchor/focus coordinator and footnote walkthrough Rollout and recovery: Ship stable anchors before custom scrolling; disable scroll effects if focus and visual position diverge. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-105 — Recover bookmarks after a handbook correction **Story · High priority · Advanced** noCV practice brief v5 · READ-105 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep the reader oriented. Depends on: READ-103, READ-104. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Accessibility 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 correction inserts two sections before a bookmark. Its raw character offset now opens an unrelated paragraph. Acceptance criteria - Bookmarks include version, stable section, and optional bounded text anchor. - A newer version resolves the section or explicitly reports that the passage moved or disappeared. - The permitted original version remains reachable without silently rewriting the bookmark. Implementation constraints - Approximate text matching is not exact; disclose ambiguity and retain the original anchor. Verification - Insert content before a stable section and reopen its bookmark; the intended section remains selected. - Delete it and create two similar passages; show ambiguous recovery rather than silently choosing one. Deliverables - Version-aware bookmark resolver and correction fixtures Rollout and recovery: Keep legacy bookmarks readable during migration; fall back to the permitted original version on uncertain resolution. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ### Support richer reading Add annotations and long-document loading without breaking reading flow. #### READ-106 — Render annotations safely and expose their controls **Bug · High priority · Advanced** noCV practice brief v5 · READ-106 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-103, READ-104. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Accessibility 30% · Frontend 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. Pasted annotation markup changes layout and introduces active links. Annotation actions are unnamed icons visible only on hover. Acceptance criteria - Annotations use plain text or an explicit constrained format that removes disallowed content. - Edit, delete, and return-to-passage actions have accessible names and work without hover. - Failed saves preserve a draft distinct from confirmed comments. Implementation constraints - Keep document source immutable and treat annotation content as untrusted. Verification - Create a normal annotation and navigate every action by keyboard. - Paste script-like markup and a dangerous link, then reject save; no active content runs and the unsaved draft stays explicit. Deliverables - Safe annotation renderer and keyboard/security regression cases Rollout and recovery: Enable plain text first; disable rich formatting on sanitization regression while preserving stored source text. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-107 — Load long handbooks without losing reading order **Task · Medium priority · Advanced** noCV practice brief v5 · READ-107 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-102, READ-104. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Accessibility 40% · Frontend 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 200-section handbook blocks interaction, but a virtual-list prototype removes headings while a screen reader navigates them. Acceptance criteria - Initial work is bounded through explicit section loading or an equally accessible documented strategy. - Loaded sections stay in logical order and focused content is never removed. - Section-load failure offers in-place retry without resetting the reading anchor. Implementation constraints - Profile a reproducible fixture and state the environment; do not optimize by hiding required accessible content. Verification - Profile initial load and navigate three loaded sections by keyboard and headings. - Fail the next request while focus stays in the current section; retry without duplicates, reordered headings, or focus loss. Deliverables - Incremental loading and before/after profile with reading-order checks Rollout and recovery: Enable for large documents; keep a full-document option when incremental reading is unsuitable. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-108 — Keep annotation review stable through collaborator updates **Story · Medium priority · Expert** noCV practice brief v5 · READ-108 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support richer reading. Depends on: READ-105, READ-106, READ-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Accessibility 30% · Real-time 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. A colleague resolves a comment while another reader edits a reply. The panel reorders, steals focus, and sends the reply to the newly selected thread. Acceptance criteria - Editing binds to immutable thread identity and revision, not list position. - Remote updates never silently retarget a draft or move current focus. - Resolved/deleted-thread conflicts preserve the draft, announce once, and offer explicit permitted recovery. Implementation constraints - Use fixture events; a full collaboration backend and automatic merging are excluded. Verification - Insert a remote comment above the active thread while typing; the draft keeps its original thread. - Resolve the active thread during reply acknowledgement; no reply lands elsewhere and the confirmed state stays coherent. Deliverables - Revision-aware annotation model and concurrent-update tests Rollout and recovery: Pilot manual refresh before live events; pause remote panel updates if focus or binding becomes unstable. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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 access and recovery Check interruptions and document the release boundary. #### READ-109 — Handle access loss without an empty-reader trap **Bug · High priority · Advanced** noCV practice brief v5 · READ-109 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify access and recovery. Depends on: READ-107, READ-108. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Accessibility 30% · Frontend 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. Access expires while a reader is on a late section. The next fetch clears the page and leaves focus on a removed annotation button. Acceptance criteria - Confirmed access loss stops fetches and clears protected rendered content. - Focus moves to a named access-state heading with permitted navigation. - Account changes cannot restore prior content through cached sections or Back. Implementation constraints - Omit private authorization details and document account-scoped draft handling on access loss. Verification - Remove access during a section fetch and verify a useful accessible access state. - Switch account and navigate Back; protected cached content stays absent and stale fetches stop. Deliverables - Access-loss boundary and account-switch browser tests Rollout and recovery: Verify before enabling protected handbooks; disable protected caching if invalidation cannot be guaranteed. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. #### READ-110 — Verify a complete reading-and-annotation session **Chore · Medium priority · Intermediate** noCV practice brief v5 · READ-110 · A document reader that keeps people oriented Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify access and recovery. Depends on: READ-105, READ-108, READ-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Quality 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. Component checks miss interactions among search, resizing, bookmarks, and drafts. Add a short reader acceptance script to the release checklist. Acceptance criteria - The script follows contents, changes text settings, searches, annotates, bookmarks, and reopens. - Keyboard-only and one documented screen-reader pass record observed limitations. - Version correction and denied annotation save are recovery branches. Implementation constraints - Record the environment and observations; automated checks do not establish complete accessibility. Verification - Run the ordinary synthetic session and verify final bookmark and annotation identities. - Reject saving and replace the version; the draft stays explicit and ambiguous bookmarks require resolution. Deliverables - Reader acceptance script and reproducible barrier notes Rollout and recovery: Use for navigation/annotation changes; pause the affected feature on identity loss or unrecoverable keyboard failure. Project prerequisites: Versioned synthetic documents with stable section IDs Annotation and document-access API contracts to stub Engineer value: Practice semantic structure, accessible navigation, safe annotations, and stable reading positions. Company value: Inspect how an engineer makes information usable while protecting document integrity and access boundaries. 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. ## LIVE — A collaborative incident room with a reliable timeline The fictional Harbor operations team coordinates synthetic incidents in a shared room. Engineers post status notes and claim response tasks while connections come and go. Scope is one application gateway, a durable room event store, and fixture clients; alert paging and external chat delivery are excluded. **Field:** Real-time systems. **Suggested stack:** TypeScript, Node.js, WebSocket, PostgreSQL, Redis. **Engineer value:** Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. **Company value:** Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. **Delivery agreement:** Deliver one issue or a phase at a time against synthetic rooms. Keep load fixtures bounded and avoid real incident channels. ### Setup prerequisites - Room membership and command contracts - Synthetic incident events and a controllable transport harness ### Establish the room contract Make connection state and event boundaries explicit. #### LIVE-101 — Show the difference between connected and caught up **Story · Medium priority · Foundational** noCV practice brief v5 · LIVE-101 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Frontend 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 room shows Connected immediately after a socket opens, even while the last five minutes of events are still missing. Give connection and synchronization separate states. Acceptance criteria - The UI distinguishes connecting, recovering, current, disconnected, and unavailable. - Current appears only after the server-defined replay boundary has been applied. - The latest confirmed timeline remains readable during reconnect with a visible freshness notice. Implementation constraints - Use a deterministic transport fixture; socket open alone is not proof of complete room state. Verification - Open a connection and delay replay completion; the room stays recovering until the boundary arrives. - Disconnect after a confirmed note and fail reconnect; the note remains readable but is not labeled current. Deliverables - Room connection/sync state model and delayed-replay UI test Rollout and recovery: Enable state labels in the pilot room; force read-only mode if synchronization cannot be established. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-102 — Reject malformed room events before they reach the reducer **Task · High priority · Foundational** noCV practice brief v5 · LIVE-102 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 50% · API design 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. A gateway change sends a string sequence number and crashes every open room tab. Define a versioned event envelope with deliberate unknown-version behavior. Acceptance criteria - The boundary validates version, room ID, event ID, sequence, type, and bounded payload. - Malformed or unsupported events never enter the state reducer. - Protocol errors expose a safe category and recovery action without echoing raw note content. Implementation constraints - Treat transport input as untrusted and impose a documented frame-size limit. Verification - Accept a valid status-note envelope and verify its typed reducer input. - Send an oversized frame, invalid sequence, and unknown version; reject each without crashing or leaking raw payloads. Deliverables - Versioned event parser and invalid-envelope fixture suite Rollout and recovery: Deploy readers that understand the new version before changing writers; pause the stream on unsupported contracts. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-103 — Authorize room subscription before replaying its history **Bug · High priority · Intermediate** noCV practice brief v5 · LIVE-103 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the room contract. Depends on: LIVE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Real-time systems 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 client changes the room ID in its subscribe message and receives a few private timeline entries before the gateway rejects membership. Move authority checks ahead of all history and live delivery. Acceptance criteria - Subscription derives tenant and user from the authenticated session. - Current room membership is checked before replay queries and live listener registration. - Denied subscriptions leave no active listener or partially delivered room data. Implementation constraints - Enforce room scope in repository methods as well as at the transport boundary. Verification - Subscribe as an authorized synthetic member and inspect permitted replay. - Request a room in another organization and revoke membership before listener installation; deliver zero room events in both cases. Deliverables - Authorized subscription boundary and cross-room denial tests Rollout and recovery: Require this before private-room pilots; disable subscriptions if membership authority is unavailable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Recover a coherent timeline Order, deduplicate, and replay confirmed events. #### LIVE-104 — Stop duplicate and out-of-order notes confusing the timeline **Bug · High priority · Advanced** noCV practice brief v5 · LIVE-104 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover a coherent timeline. Depends on: LIVE-101, LIVE-102, LIVE-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 reconnect overlaps live delivery with replay. The same mitigation note appears twice, and a late earlier event moves a resolved task back to active. Acceptance criteria - Event identity deduplicates replay and live delivery for the same room. - Only a contiguous server sequence advances the applied cursor. - Out-of-order gaps are buffered within a configured bound and trigger recovery rather than arbitrary state application. Implementation constraints - A wall-clock timestamp is presentation metadata, not the authoritative event order. Verification - Deliver a duplicate event through replay and live paths; the timeline shows it once. - Deliver sequences 12, 14, 13 and then an oversized gap; apply contiguous state correctly and enter recovery at the bound. Deliverables - Ordered room reducer and duplicate/gap test vectors Rollout and recovery: Shadow the reducer against fixed logs before use; reset from a validated snapshot if gap recovery fails. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-105 — Recover when a reconnect cursor is older than retained history **Story · High priority · Advanced** noCV practice brief v5 · LIVE-105 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover a coherent timeline. Depends on: LIVE-104. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 laptop wakes after the room’s replay window has expired. The gateway returns recent events after the old cursor, leaving an invisible gap in the task state. Acceptance criteria - An expired cursor receives an explicit resync-required response. - The client replaces state from a room-scoped snapshot and resumes after its exact sequence boundary. - Snapshot and post-snapshot events cannot combine data from different rooms or snapshot revisions. Implementation constraints - Keep the prior timeline visibly stale until the replacement state is validated. Verification - Resume a retained cursor and confirm ordinary incremental replay. - Use an expired cursor and deliver a live event during snapshot loading; apply it once after the snapshot boundary, or reject mismatched room data. Deliverables - Snapshot/replay recovery protocol and expired-cursor tests Rollout and recovery: Pilot with a short synthetic retention window; disable writes during unresolved resync and retain safe read-only context. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Coordinate work safely Protect commands, presence, and changing access. #### LIVE-106 — Reconcile a task claim when its acknowledgement is lost **Bug · High priority · Advanced** noCV practice brief v5 · LIVE-106 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Backend 30% · Database 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. A responder claims Investigate cache saturation, loses the acknowledgement, and retries. The room appends duplicate claims and briefly shows two owners. Acceptance criteria - A claim command has a stable operation key and expected task revision. - The durable event and operation result commit together or neither becomes authoritative. - Retry returns the existing result; a competing confirmed claim produces a conflict instead of a second owner. Implementation constraints - Use the application transaction boundary and an outbox if broadcasting crosses processes. Verification - Accept a claim, drop the acknowledgement, and retry with the same key; one logical claim exists. - Race two responders at the same revision and fail broadcast after commit; one owner remains and replay recovers the event. Deliverables - Idempotent claim command and lost-acknowledgement/concurrent-claim tests Rollout and recovery: Enable claims after replay recovery; disable new claims if transaction/result consistency fails while keeping confirmed assignments readable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-107 — Expire disconnected presence without rewriting incident history **Task · Medium priority · Intermediate** noCV practice brief v5 · LIVE-107 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-103. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 70% · 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. Closing a laptop leaves its user shown as In room for hours. Presence currently uses the same durable event path as incident notes, making heartbeat traffic dominate replay. Acceptance criteria - Presence expires from a bounded lease using server-observed heartbeats. - Multiple tabs collapse to one visible member while preserving presence if one tab remains connected. - Presence expiration never removes authored notes or changes task ownership. Implementation constraints - Presence is advisory activity state, not proof that someone read or understood an incident. Verification - Open two tabs, close one, and verify the member remains until the final lease expires. - Delay heartbeats and restart the presence store; stale members expire without changing durable timeline or ownership. Deliverables - Ephemeral presence lease model and multi-tab expiry tests Rollout and recovery: Release advisory presence independently; hide it when its store is unavailable rather than retaining indefinite online claims. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-108 — Cut off room delivery when membership is revoked mid-replay **Bug · Urgent priority · Expert** noCV practice brief v5 · LIVE-108 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate work safely. Depends on: LIVE-105, LIVE-106, LIVE-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Real-time systems 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 temporary responder is removed while a long history replay is streaming. The established socket keeps receiving new private notes until reconnect. Acceptance criteria - Membership changes invalidate active subscriptions and pending replay batches for that session and room. - Commands recheck current authority before committing, even when the socket was previously authorized. - After the defined revocation barrier, no queued private frames are delivered and listener resources are released. Implementation constraints - Specify the barrier and in-flight message limits; do not promise retroactive removal of data already delivered. Verification - Revoke a member between replay batches and assert no subsequent private frames cross the barrier. - Race revocation with task claim and a queued live note; reject unauthorized commit and remove all room listeners. Deliverables - Revocation-aware subscription lifecycle and race harness Rollout and recovery: Require the race harness before temporary-member use; close affected room sockets if revocation propagation is uncertain. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ### Handle operational pressure Bound resource use and rehearse recovery. #### LIVE-109 — Keep one slow room client from exhausting gateway memory **Task · High priority · Expert** noCV practice brief v5 · LIVE-109 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle operational pressure. Depends on: LIVE-105, LIVE-108. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Real-time systems 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 paused browser cannot consume events, but its send buffer grows throughout a synthetic incident drill. Add bounded per-connection delivery and a recoverable overload path. Acceptance criteria - Each connection has explicit queued-byte and queued-event limits. - Overloaded clients receive a safe resync/close outcome when possible; durable events are never silently skipped while claiming currency. - Healthy clients continue receiving events and per-connection resources are reclaimed after closure. Implementation constraints - Keep a bounded load fixture; distinguish disposable presence updates from durable timeline events. Verification - Pause one consumer while a second reads normally; measure bounded memory and uninterrupted healthy delivery. - Exceed limits, reconnect the slow client, and recover by cursor/snapshot with no silently missing timeline events. Deliverables - Backpressure policy and bounded slow-consumer load report Rollout and recovery: Canary conservative queue limits with disconnect metrics; reduce admission or disable live updates if memory bounds fail. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. #### LIVE-110 — Rehearse gateway restart during incident coordination **Chore · High priority · Advanced** noCV practice brief v5 · LIVE-110 · A collaborative incident room with a reliable timeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle operational pressure. Depends on: LIVE-106, LIVE-108, LIVE-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Site reliability 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. The team has not tested what room users see during a gateway restart. Create a repeatable drill with one pending claim, a disconnected reader, and a recently revoked member. Acceptance criteria - The drill records final durable event IDs, sequence, task owner, and subscription count. - Restart recovery neither duplicates the claim nor grants the revoked member replay access. - The runbook defines safe metrics and a rollback action without logging private note bodies. Implementation constraints - Restart only disposable practice processes and use synthetic room content. Verification - Run the restart drill twice from the same fixture and compare final authoritative room state. - Make the event store unavailable during reconnect; clients remain explicitly stale/read-only and no command is falsely confirmed. Deliverables - Gateway restart drill and incident-room operator runbook Rollout and recovery: Require the drill before pilot expansion; keep room writes disabled if durable replay or authorization recovery is unavailable. Project prerequisites: Room membership and command contracts Synthetic incident events and a controllable transport harness Engineer value: Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system. Company value: Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages. 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. ## FLEET — A dispatch map that does not invent certainty The fictional Cedar delivery depot dispatches vans through a browser map and accessible list. Synthetic telemetry arrives through a gateway with device sequence numbers. This is operational fleet software practice; no real driver tracking, employee scoring, or routing safety guarantee is part of the project. **Field:** Real-time systems. **Suggested stack:** TypeScript, React, MapLibre, Node.js, PostgreSQL. **Engineer value:** Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. **Company value:** Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. **Delivery agreement:** Use a fixed synthetic depot and replayable location traces. Each ticket is independently bounded by its declared prerequisites. ### Setup prerequisites - Synthetic vehicle telemetry with device sessions and sequence numbers - Dispatch assignment and authorized region API contracts ### Establish a truthful map Validate coordinates and show age and identity clearly. #### FLEET-101 — Keep invalid coordinates from appearing as real vans **Bug · High priority · Foundational** noCV practice brief v5 · FLEET-101 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a truthful map. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Real-time systems 30% · Frontend 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. Missing coordinates are coerced to zero, placing a depot van in the ocean. Validate telemetry before rendering and explain vehicles with no usable position. Acceptance criteria - Latitude and longitude must be finite numeric values within documented geographic bounds. - Missing or rejected position data produces an unknown-location state in the list. - A valid zero coordinate remains valid and is not treated as a missing value. Implementation constraints - Keep vehicle identity separate from location availability; rejecting one fix must not delete the vehicle. Verification - Render valid zero latitude and a normal depot position correctly. - Send null, a numeric string, an out-of-range value, and non-finite coordinates; none becomes a plausible marker. Deliverables - Telemetry coordinate parser and invalid-position fixtures Rollout and recovery: Validate traces before map display; hide invalid markers while retaining unknown-location list rows. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-102 — Show dispatchers how old each vehicle position is **Story · High priority · Foundational** noCV practice brief v5 · FLEET-102 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a truthful map. Depends on: FLEET-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Frontend 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 van’s last position remains bright green after its device disconnects. Dispatch assigns a nearby job using a point that is twenty minutes old. Acceptance criteria - Map and list expose last accepted fix time and age. - Positions move through configured fresh, stale, and unknown states without requiring a new event. - Device timestamps outside the allowed clock-skew range cannot make a position appear indefinitely fresh. Implementation constraints - Use a controllable clock and text labels as well as visual styling. Verification - Advance the clock past both freshness thresholds and verify map/list agreement. - Send a future-dated fix and disconnect the stream; no false current label remains. Deliverables - Position freshness policy and fake-clock UI checks Rollout and recovery: Release age labels before assignment features; disable freshness coloring if timestamp authority is uncertain. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-103 — Fit selected vehicles without zooming out across the entire planet **Bug · Medium priority · Intermediate** noCV practice brief v5 · FLEET-103 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a truthful map. Depends on: FLEET-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 synthetic depot near the date line has vans at longitudes 179.8 and -179.7. Fit selection zooms to the whole world because the bounding box takes the long route. Acceptance criteria - Viewport fitting chooses the intended minimal longitude span for the selected valid points. - One-point and empty selections use documented zoom/fallback behavior. - Unknown-location vehicles remain listed but do not distort geographic bounds. Implementation constraints - Bound this task to viewport fitting; route calculation and global projection replacement are excluded. Verification - Fit points on both sides of the date line and verify a local view contains both. - Fit an empty selection, one point, and a mix containing invalid fixes; no invalid bounds or extreme zoom occurs. Deliverables - Dateline-aware bounds helper and geographic edge-case fixtures Rollout and recovery: Enable for selection fitting only; retain a manual reset-to-depot control if bounds calculation fails. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. ### Reconcile live telemetry Handle device ordering and reconnect boundaries. #### FLEET-104 — Prevent delayed telemetry from moving a van backwards **Bug · High priority · Advanced** noCV practice brief v5 · FLEET-104 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile live telemetry. Depends on: FLEET-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 70% · Data 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. A device buffers updates through a tunnel, then sends them out of order. The marker jumps to an older point and the arrival-age label resets incorrectly. Acceptance criteria - Per-device session and sequence identify whether a fix advances accepted position. - Duplicates and earlier fixes do not replace current position or refresh its age. - A new device session follows an explicit reset/authority policy rather than comparing unrelated sequence counters. Implementation constraints - Arrival time alone cannot establish device order; keep bounded diagnostics for rejected categories. Verification - Deliver sequence 40, 42, 41, and 42 again; accepted position remains at 42. - Restart the device session with sequence 1 and replay an old-session fix; the documented session policy chooses one authority. Deliverables - Device-session telemetry reducer and reordered-trace tests Rollout and recovery: Replay fixed traces before live pilot; freeze a device at its last confirmed fix when session authority is ambiguous. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-105 — Reconnect the map without losing updates between snapshot and stream **Task · High priority · Expert** noCV practice brief v5 · FLEET-105 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile live telemetry. Depends on: FLEET-103, FLEET-104. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 dashboard downloads a vehicle snapshot and opens the live stream afterward. Updates during that gap never arrive, so a van appears stale until its next fix. Acceptance criteria - The snapshot supplies an authorized region identity and exact stream watermark. - Buffered or replayed events after that watermark apply once after snapshot installation. - Expired watermarks, buffer overflow, and mismatched region data trigger explicit resync rather than a partial-current view. Implementation constraints - Document the snapshot/replay boundary contract; use a bounded buffer and synthetic trace harness. Verification - Inject movement during snapshot loading and confirm the final position includes it exactly once. - Expire the watermark and switch region during recovery; no mixed-region positions or falsely current state appears. Deliverables - Snapshot/stream handoff protocol and gap-recovery harness Rollout and recovery: Pilot with forced reconnects; keep the map visibly stale and commands disabled until a coherent snapshot is installed. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. ### Support operational decisions Keep assignments, filters, and access consistent. #### FLEET-106 — Resolve competing dispatch assignments explicitly **Bug · High priority · Advanced** noCV practice brief v5 · FLEET-106 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support operational decisions. Depends on: FLEET-105. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Backend 30% · Frontend 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. Two dispatchers assign the same van to different pickup jobs. Both dashboards show success until a refresh reveals the losing assignment disappeared. Acceptance criteria - Assignment commands include expected van/job revision and a stable operation key. - Only the server-confirmed assignment becomes authoritative in map and list. - A competing change shows the current assignment and preserves the unsubmitted alternative for an explicit decision. Implementation constraints - Use conditional updates at the repository boundary; stale location is shown as context, not assumed current availability. Verification - Assign a free van and verify map/list share the confirmed revision. - Race two dispatchers and lose one acknowledgement; one assignment wins, retries do not duplicate it, and the conflict is visible. Deliverables - Revision-aware dispatch command and concurrent-assignment tests Rollout and recovery: Enable for one synthetic depot after replay checks; disable assignment writes if confirmed map/list state diverges. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-107 — Keep map, list, and counts on the same filtered vehicle set **Bug · Medium priority · Intermediate** noCV practice brief v5 · FLEET-107 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support operational decisions. Depends on: FLEET-102, FLEET-106. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Real-time systems 20% · Accessibility 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. Filtering to Unassigned removes map markers but leaves assigned vans in the keyboard list. The count in the toolbar then disagrees with both. Acceptance criteria - One derived selection drives map IDs, list rows, and count. - A live assignment change updates all representations without silently retargeting the selected van. - If a selected van leaves the filter, the interface explains why and offers a deliberate clear-filter action. Implementation constraints - Maintain an accessible list as an operational alternative to the map. Verification - Filter unassigned vehicles and compare IDs across map, list, and count. - Assign the selected vehicle remotely while keyboard focus is on its row; selection is explained and focus is not lost. Deliverables - Shared filtered projection and map/list consistency tests Rollout and recovery: Enable shared projection for one filter first; fall back to the authoritative list if map selection behavior regresses. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-108 — Remove out-of-region location data when dispatch scope changes **Task · High priority · Advanced** noCV practice brief v5 · FLEET-108 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support operational decisions. Depends on: FLEET-105, FLEET-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Real-time systems 30% · Privacy 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. A dispatcher moves from North depot coverage to East, but an existing stream continues delivering North vehicle coordinates. Hidden markers remain in the browser store. Acceptance criteria - Subscriptions and snapshot queries enforce current authorized region at the service boundary. - Scope changes close old delivery, clear disallowed cached positions, and reconcile a new authorized snapshot. - Diagnostics contain safe event categories and IDs, not raw coordinate trails or personal driver details. Implementation constraints - Use synthetic fleet data and do not add employee behavior scores or continuous personal-device tracking. Verification - Switch from North to East and verify only authorized East vehicles remain in storage and presentation. - Queue an old-region event during scope revocation; reject it after the documented barrier and deny a forged region query. Deliverables - Region-scoped delivery lifecycle and cross-region denial tests Rollout and recovery: Require this before multi-depot pilots; close all location streams when current scope cannot be established. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. ### Bound and rehearse the system Maintain responsiveness and verify failure recovery. #### FLEET-109 — Coalesce position rendering without dropping dispatch events **Task · High priority · Expert** noCV practice brief v5 · FLEET-109 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound and rehearse the system. Depends on: FLEET-104, FLEET-107, FLEET-108. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Real-time systems 30% · Frontend 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 replay of 500 vans updating twice a second freezes the browser. Dropping every other message improved drawing but also lost assignment changes. Acceptance criteria - Position drawing may coalesce to the newest accepted fix per vehicle within a bounded frame window. - Assignment, authorization, and removal events follow their full ordered state path and are never discarded as visual updates. - A reproducible load profile records input rate, render frequency, memory bound, and keyboard interaction latency. Implementation constraints - Separate authoritative state reduction from rendering cadence; use synthetic bounded traces. Verification - Replay the agreed 500-vehicle trace and measure the documented interaction budget. - Interleave assignment, region removal, and position bursts; all nonvisual state transitions apply and removed vehicles do not reappear. Deliverables - Render coalescing scheduler and mixed-event load report Rollout and recovery: Canary with conservative draw limits; reduce displayed live density or use the list if interaction budgets fail, preserving command state. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. #### FLEET-110 — Rehearse a depot outage before enabling live dispatch **Chore · High priority · Intermediate** noCV practice brief v5 · FLEET-110 · A dispatch map that does not invent certainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound and rehearse the system. Depends on: FLEET-105, FLEET-106, FLEET-108, FLEET-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 40% · Site reliability 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. Dispatch needs to know what remains usable when telemetry stops but assignment storage still works. Write a fixed-data outage rehearsal and an operator decision note. Acceptance criteria - The rehearsal separates telemetry outage, assignment-store outage, and authorization outage. - Every scenario records visible freshness, permitted actions, and recovery state. - The note defines safe fallback actions and states that synthetic replay is not proof of real fleet readiness. Implementation constraints - Do not send real dispatch commands or connect to personal/production location feeds. Verification - Stop telemetry, advance the clock, and recover by snapshot; stale labels and final positions match the trace. - Fail assignment storage and then authorization during a pending command; show no false success and close delivery when scope is unknown. Deliverables - Depot outage rehearsal and dispatch operator runbook Rollout and recovery: Require a reviewed rehearsal for pilot use; pause live dispatch when authority or assignment confirmation is unavailable. Project prerequisites: Synthetic vehicle telemetry with device sessions and sequence numbers Dispatch assignment and authorized region API contracts Engineer value: Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands. Company value: Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages. 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. ## CLI — Release day without the shared spreadsheet A team maintains six related packages. Release notes, version changes, and tags are copied between a spreadsheet and a terminal; a failed upload recently left two packages ahead of their dependents. The exercise uses temporary repositories and a fake registry. **Field:** Developer tooling. **Suggested stack:** TypeScript, Node.js, Git, pnpm. **Engineer value:** Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. **Company value:** Review how an engineer makes release changes inspectable and recoverable before they affect consumers. **Delivery agreement:** A release-plan CLI, local fixtures, recovery tests, and an operator guide. ### Setup prerequisites - Create a temporary Git repository with three related fixture packages. - Use a local registry double; no publishing credentials are required. ### Know what will change Produce a deterministic release plan from repository inputs. #### CLI-101 — Print package versions without depending on the current directory **Task · Medium priority · Foundational** noCV practice brief v5 · CLI-101 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. 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. The release coordinator runs the command from packages/ui and gets an empty package list. Add an inspect command that finds the workspace root and reports each releasable package. Acceptance criteria - Running from the root or a nested package produces the same sorted names and versions. - Private packages are labeled and excluded from the releasable count. - A directory outside a workspace returns a nonzero exit code and an actionable error. Implementation constraints - Read manifests as data; do not run package scripts. - Stop root discovery at the filesystem root. Verification - Run inspect from root, a nested directory, and a path containing spaces. - Pass malformed package JSON and verify that the filename appears without dumping file contents. Deliverables - Inspect subcommand and a three-package fixture Rollout and recovery: Ship as a read-only command first; revert the command registration if root detection regresses. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-102 — Give scripts a stable JSON output contract **Story · Medium priority · Foundational** noCV practice brief v5 · CLI-102 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. Depends on: CLI-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. CI currently scrapes a colored table and breaks when a package name wraps. Add --json to inspect so automation can consume a versioned response. Acceptance criteria - JSON output includes schemaVersion, workspace packages, and warnings with stable field names. - Stdout contains exactly one JSON document with no ANSI escapes. - Diagnostics go to stderr and invalid arguments keep a documented nonzero exit code. Implementation constraints - Keep human rendering separate from the result model. Verification - Parse stdout from a successful --json run with JSON.parse. - Combine --json with an unknown flag and assert no partial success document is printed. Deliverables - JSON response schema and CLI exit-code reference Rollout and recovery: Add the opt-in format without changing existing human output; version incompatible schema changes. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-103 — Include dependent packages in the proposed version bump **Story · High priority · Advanced** noCV practice brief v5 · CLI-103 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Know what will change. Depends on: CLI-101. Difficulty: Advanced. Estimated focused work: 180 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 patch to @fixture/parser requires updating the exact dependency in @fixture/runner. The plan currently includes only parser, leaving runner pinned to the old release. Acceptance criteria - The plan includes transitive dependents whose declared ranges no longer accept the proposed version. - Packages already accepting the new version are not bumped solely because they depend on it. - Cycles are reported with a readable cycle path and no files are written. Implementation constraints - Declare supported workspace range syntax and reject unsupported protocols. - Use a stable topological order with package-name tie breaking. Verification - Plan a chain with exact, compatible-range, and dev-only dependencies and compare expected inclusion. - Feed a dependency cycle and a missing workspace target; both must fail before preparation. Deliverables - Dependency-aware planner and graph fixtures Rollout and recovery: Expose the graph as plan output before enabling its use in file preparation; rollback to read-only inspection. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. ### Prepare a reviewable release Write only the planned files and make failure recovery explicit. #### CLI-104 — Make a dirty checkout a deliberate release decision **Bug · High priority · Intermediate** noCV practice brief v5 · CLI-104 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-103. Difficulty: Intermediate. Estimated focused work: 90 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 teammate prepared a release with an uncommitted dependency change and could not reproduce the resulting versions. Capture the base revision and refuse preparation when tracked files differ. Acceptance criteria - The plan records the full base commit and a digest of release inputs. - Preparation rejects staged or unstaged tracked changes with a list of affected paths. - A plan whose base commit or input digest changed is rejected even when the checkout is clean. Implementation constraints - Use Git argument arrays rather than composing shell commands. - Document whether untracked files participate in the release input set. Verification - Prepare a clean fixture checkout successfully. - Stage one manifest change and separately advance HEAD; the old plan must be rejected in each case. Deliverables - Stale-plan guard and reproducibility note Rollout and recovery: Enable guards before any write command; disable preparation if repository state cannot be determined. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-105 — Turn change fragments into package-specific release notes **Task · Medium priority · Intermediate** noCV practice brief v5 · CLI-105 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-103. Difficulty: Intermediate. Estimated focused work: 105 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. The same release note is pasted into all six packages, even when only one changed. Read small checked-in change fragments and render notes grouped by affected package. Acceptance criteria - Each fragment names existing packages and one supported change category. - Rendering is deterministic and includes each fragment once per affected package. - Unknown packages, duplicate fragment IDs, and empty descriptions block generation with file-level errors. Implementation constraints - Treat fragment text as plain Markdown content, never executable templates. - Preserve issue references exactly as supplied. Verification - Render two overlapping fragments and check package-specific sections. - Use duplicate IDs and an unknown package to verify the entire notes step fails without writing output. Deliverables - Fragment format, examples, and release-note renderer Rollout and recovery: Generate notes to a preview path initially; switching to committed notes requires the validated plan. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-106 — Prepare manifests and notes as one recoverable file operation **Story · High priority · Advanced** noCV practice brief v5 · CLI-106 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a reviewable release. Depends on: CLI-104, CLI-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Storage systems 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 interrupted process updated two manifests but left the changelog untouched. Preparation needs a journal so the next invocation can identify exactly which planned writes completed. Acceptance criteria - Validate every target and render every new file before replacing any repository file. - A journal records expected before and after hashes for each target and completed replacements. - Recovery restores only files still matching the recorded after hash and refuses to overwrite user edits. Implementation constraints - Keep staging and target files on the same filesystem. - Resolve paths inside the selected repository and reject symlink escapes. Verification - Inject failure after the first replacement and recover the original bytes. - Edit a prepared file before recovery and confirm a conflict is reported while the edit is preserved. Deliverables - Preparation journal, recovery command, and failure-injection fixtures Rollout and recovery: Enable writes only after preview and recovery pass locally; use the journal to undo an interrupted preparation. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. ### Handle an interrupted release Resume against a fake registry without duplicating or concealing work. #### CLI-107 — Prevent a second release process from using the same checkout **Bug · High priority · Advanced** noCV practice brief v5 · CLI-107 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-106. Difficulty: Advanced. Estimated focused work: 120 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. Two terminals started preparation within a second and both used the same temporary filenames. Add an exclusive lease for mutation commands with inspectable ownership. Acceptance criteria - Exactly one of two concurrent preparation commands obtains the repository lease. - The loser exits before replacing a file and reports the existing operation ID. - Stale-lease recovery is an explicit command that verifies the recorded operation is no longer active. Implementation constraints - Do not decide lease ownership from a PID alone; include an operation token. - Read-only commands remain usable while a lease exists. Verification - Start two local fixture processes behind a barrier and count successful mutations. - Simulate a stale lease and verify ordinary preparation refuses it until explicit recovery. Deliverables - Lease implementation and concurrent-process test Rollout and recovery: Require leases for all mutation commands together; rollback by disabling mutations until both versions agree on the lease format. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-108 — Resume a publish rehearsal after the registry response disappears **Story · High priority · Expert** noCV practice brief v5 · CLI-108 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-106, CLI-107. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Distributed systems 30% · Integrations 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 fake registry accepts a package and then drops the connection. A blind retry may conceal a different artifact already registered at that version. Reconcile remote state before resuming. Acceptance criteria - Each planned package records its version and artifact digest before the fake publish call. - An existing version with the same digest is treated as completed; a different digest blocks the entire resume. - Resume respects dependency order and leaves a durable record of ambiguous, reconciled, and completed steps. Implementation constraints - Use a local registry port with deterministic lost-response behavior. - A release record is append-only; do not overwrite the original failed attempt. Verification - Drop the first response after acceptance and verify resume makes no duplicate upload. - Preload the same version with different bytes and confirm dependents remain unpublished. Deliverables - Resumable rehearsal workflow and ambiguity incident walkthrough Rollout and recovery: Keep the registry adapter local for this exercise; require a reviewed digest reconciliation policy before a real adapter. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-109 — Keep release credentials and package contents out of logs **Chore · High priority · Intermediate** noCV practice brief v5 · CLI-109 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-102, CLI-108. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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 registry error included an authorization header in a debug dump. Add structured diagnostics with an allowlist of safe release fields and a useful correlation ID. Acceptance criteria - Diagnostics include operation ID, package name, step, duration, and error category. - Headers, environment variables, artifact contents, and token-like fixture values are absent from all log levels. - Human and JSON errors reference the same operation ID. Implementation constraints - Map provider failures to safe errors at the adapter boundary. - Do not rely only on replacing known secret strings. Verification - Cause a fake provider error containing a token and scan stdout, stderr, and persisted diagnostics. - Confirm a safe package conflict still carries enough information to locate the failed step. Deliverables - Safe error mapper and redaction regression cases Rollout and recovery: Make safe diagnostics the default; temporarily reduce diagnostic detail if an unknown provider error cannot be classified. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. #### CLI-110 — Package the CLI so a fresh checkout can rehearse a release offline **Task · Medium priority · Intermediate** noCV practice brief v5 · CLI-110 · Release day without the shared spreadsheet Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle an interrupted release. Depends on: CLI-108, CLI-109. Difficulty: Intermediate. Estimated focused work: 120 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. The maintainer can run the tool only through a source-tree import. Package the command and document one complete rehearsal using fixture packages and the local registry. Acceptance criteria - The built executable supports --help and --version without source imports. - An offline rehearsal covers inspect, plan, prepare, interrupted publish, and resume. - The guide explains which steps mutate files and how to restore the fixture repository. Implementation constraints - Pin fixture inputs so example output is reproducible. - Do not perform an actual registry publication. Verification - Install the packed artifact into a temporary directory and run the documented rehearsal. - Run without a registry configuration and confirm publishing fails before any network attempt. Deliverables - Packed CLI artifact instructions and end-to-end rehearsal guide Rollout and recovery: Distribute a prerelease artifact for local evaluation; retract it if packed-command behavior differs from source execution. Project prerequisites: Create a temporary Git repository with three related fixture packages. Use a local registry double; no publishing credentials are required. Engineer value: Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work. Company value: Review how an engineer makes release changes inspectable and recoverable before they affect consumers. 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. ## BUILD — Make the monorepo feedback loop trustworthy A product team waits for every package to rebuild after small changes. An experimental cache is faster but occasionally returns success after a shared type changed. Build a small, auditable task runner around fixture packages. **Field:** Developer tooling. **Suggested stack:** TypeScript, Node.js, pnpm, JSON. **Engineer value:** Practice incremental computation, dependency scheduling, cache correctness, and cancellation. **Company value:** Inspect whether faster checks preserve the guarantees reviewers depend on. **Delivery agreement:** A dependency-aware check runner with a local cache and reproducible benchmark report. ### Setup prerequisites - Prepare four fixture packages with one shared library and two applications. - Use only trusted fixture commands in local tests. ### Model checks and dependencies Make task selection and scheduling predictable. #### BUILD-101 — Reject invalid task configuration before starting a command **Task · Medium priority · Foundational** noCV practice brief v5 · BUILD-101 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · 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. A misspelled dependsOn entry silently removed a typecheck prerequisite. Introduce a validated task configuration with clear locations for configuration errors. Acceptance criteria - Every task has a unique ID, command argument list, working directory, and declared dependencies. - Unknown dependencies and paths outside the workspace fail validation. - Validation reports all independent configuration errors without starting commands. Implementation constraints - Commands are trusted fixture configuration; no shell interpolation. - Keep configuration parsing independent of execution. Verification - Validate a four-task graph successfully. - Submit a missing dependency and escaping working directory together and confirm both errors and zero process starts. Deliverables - Configuration schema and validation diagnostics Rollout and recovery: Use validation in a read-only plan command first; refuse execution for older unsupported config versions. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-102 — Show why a task is selected after a file change **Story · Medium priority · Intermediate** noCV practice brief v5 · BUILD-102 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: BUILD-101. Difficulty: Intermediate. Estimated focused work: 105 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. Changing packages/shared/types.ts reruns one app but not its sibling. Build a changed-file planner that includes affected dependents and prints the reason for each selected task. Acceptance criteria - Changes under a shared package select all configured downstream checks. - A root configuration change selects the documented full validation set. - Deleted files and renamed files are handled using both old and new affected paths. Implementation constraints - Sort explanation paths for reproducible output. Verification - Change shared types and inspect both application check reasons. - Delete a file from one leaf package and confirm unrelated leaf tasks remain unselected. Deliverables - Affected-task planner and explanation output Rollout and recovery: Compare selection with full checks in report-only mode before using it to skip work. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-103 — Schedule independent checks without exceeding the worker limit **Story · High priority · Advanced** noCV practice brief v5 · BUILD-103 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model checks and dependencies. Depends on: BUILD-101. Difficulty: Advanced. Estimated focused work: 150 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. Two independent application tests could run together, but shared compilation must finish first. Add bounded scheduling and explicit blocked states for dependent tasks. Acceptance criteria - A task starts only after every prerequisite succeeds. - Active process count never exceeds the configured positive concurrency limit. - A failed prerequisite marks descendants blocked while unrelated tasks may finish. Implementation constraints - Detect cycles before execution and return the cycle path. - Store task transitions through one scheduler boundary. Verification - Run a diamond graph with barrier-controlled fixture tasks and assert start order and concurrency. - Fail the shared task and verify descendants never start while an independent task completes. Deliverables - Bounded scheduler and graph execution trace Rollout and recovery: Default concurrency to one; increase only after the scheduling trace demonstrates the limit. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. ### Cache only valid results Prove when outputs may safely be reused. #### BUILD-104 — Include tool versions and declared environment in the cache key **Bug · High priority · Advanced** noCV practice brief v5 · BUILD-104 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Storage 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. The cache reused a successful check after the TypeScript version changed. Define a canonical cache key that captures the command, inputs, dependency results, and supported environment. Acceptance criteria - Changing input bytes, lockfile, command arguments, tool version, or a declared environment value changes the key. - File enumeration order and path separators do not change an otherwise equivalent key. - Undeclared environment dependence is documented as unsupported and such tasks can disable caching. Implementation constraints - Hash values rather than logging environment contents. - Use content hashes, not modification times, as input identity. Verification - Reorder file enumeration and assert the key is unchanged. - Change each declared input dimension independently and assert a cache miss. Deliverables - Cache-key specification and canonicalization tests Rollout and recovery: Version the cache namespace and discard entries produced by the old key algorithm. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-105 — Restore cached outputs without touching unrelated files **Story · High priority · Expert** noCV practice brief v5 · BUILD-105 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Developer tooling 30% · Storage 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. A cached archive restored ../config.json during a local corruption test. Replace blind extraction with a validated manifest and staged restoration inside declared output roots. Acceptance criteria - Every restored file has a normalized in-root path and verified content digest. - Absolute paths, traversal paths, symlink escapes, and unexpected output entries are rejected. - A rejected or interrupted restoration preserves the prior output set and reports a cache miss. Implementation constraints - Treat cache entries as untrusted even when the cache is local. - Separate verification from replacement and avoid executing archive hooks. Verification - Restore a valid two-directory output manifest and compare every digest. - Use traversal, digest mismatch, and interrupted replacement fixtures and verify unrelated files are unchanged. Deliverables - Validated cache restorer and corruption fixtures Rollout and recovery: Enable restoration behind an opt-in flag; on any integrity error rebuild from source and quarantine that cache entry. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-106 — Never cache failed or incompletely written task outputs **Bug · High priority · Intermediate** noCV practice brief v5 · BUILD-106 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cache only valid results. Depends on: BUILD-103, BUILD-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Storage systems 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 killed build left an output directory that the next run accepted as a hit. Publish a cache entry only after successful exit and complete output hashing. Acceptance criteria - Nonzero exit, cancellation, and missing declared outputs never create reusable entries. - Entries become visible through one final commit marker after all files and metadata are written. - Concurrent identical writers either publish equivalent complete entries or report an integrity conflict. Implementation constraints - Use a unique staging directory per attempt. Verification - Kill a fixture build after it creates one output and assert the next run executes it again. - Race two successful writes for one key and verify readers observe only complete entries. Deliverables - Atomic cache publisher and partial-output test Rollout and recovery: Invalidate legacy entries without a completion marker; keep cache misses safe by running the original task. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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 the runner usable in CI Control resources and report failures without hiding them. #### BUILD-107 — Cancel running checks and report what did not run **Story · Medium priority · Advanced** noCV practice brief v5 · BUILD-107 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-103. Difficulty: Advanced. Estimated focused work: 150 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. Pressing Ctrl+C stops the runner but leaves a test child consuming CPU. Add cancellation with a bounded grace period and explicit cancelled outcomes. Acceptance criteria - Cancellation stops new starts immediately and requests termination of every owned process tree. - After the configured grace period remaining owned processes are forcefully terminated using supported platform behavior. - The summary distinguishes failed, cancelled, blocked, and completed tasks and returns a nonzero exit. Implementation constraints - Exercise only controlled fixture child processes. - Do not terminate processes outside the operation ownership set. Verification - Cancel a parent fixture that owns a long-lived child and confirm both are gone. - Cancel while one independent task has completed and verify its successful result remains in the summary. Deliverables - Cancellation handler and process-cleanup test Rollout and recovery: Enable cancellation together with process ownership tracking; retain the serial execution fallback if cleanup fails on a supported OS. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-108 — Keep parallel task output readable and bounded **Task · Medium priority · Foundational** noCV practice brief v5 · BUILD-108 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-103. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Concurrent test logs interleave half-lines and a noisy task consumes hundreds of megabytes of memory. Prefix complete lines and cap retained output per task. Acceptance criteria - Every rendered line carries its task ID without splitting UTF-8 characters. - Retained output per task stays below a configured byte limit with a visible truncation notice. - The final summary includes exit code, duration, and an indication that output was truncated. Implementation constraints - Handle a final line that has no newline. - Keep stderr attribution separate from status. Verification - Emit split multibyte characters from two fixture processes and check rendered text. - Write beyond the limit and verify bounded retention and a single clear truncation notice. Deliverables - Streaming output formatter and noisy-task fixture Rollout and recovery: Use bounded capture by default and document an explicit file-output option for deeper local debugging. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-109 — Explain a cache miss without exposing input contents **Story · Low priority · Intermediate** noCV practice brief v5 · BUILD-109 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-104, BUILD-106. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Privacy 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 team cannot tell whether frequent misses come from the lockfile or an unstable generated file. Add an explain command comparing safe input metadata from two runs. Acceptance criteria - Explanation identifies added, removed, or changed input paths and changed key categories. - File contents and environment values are never printed. - A missing prior run produces a useful first-run result instead of an error. Implementation constraints - Retain hashes and category names only for environment-sensitive inputs. Verification - Change a source file and a tool version and assert both reasons appear. - Place a secret fixture value in a declared environment variable and confirm no output includes it. Deliverables - Cache-miss explanation command and safe metadata format Rollout and recovery: Make explanation read-only; deleting history must not alter cache correctness. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. #### BUILD-110 — Measure the faster loop against a full-check baseline **Task · Medium priority · Intermediate** noCV practice brief v5 · BUILD-110 · Make the monorepo feedback loop trustworthy Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the runner usable in CI. Depends on: BUILD-105, BUILD-106, BUILD-107, BUILD-108, BUILD-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Developer tooling 30% · 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. A timing screenshot says the cache is faster but omits cases where it skipped a required check. Produce a reproducible comparison covering clean, warm, leaf-change, and shared-change runs. Acceptance criteria - The report records machine context, fixture revision, task counts, cache hits, and wall-clock timings. - Each incremental result is compared with the full-check result for the same input state. - A deliberate shared-type error fails both workflows and is never reported as a valid cache hit. Implementation constraints - Present measured numbers with run count and variability. - Avoid a hard speed claim based on one run. Verification - Run the documented matrix from an empty cache and reproduce task selection. - Introduce a dependent type error and confirm the benchmark records failed correctness before reporting speed. Deliverables - Benchmark script and correctness-first comparison report Rollout and recovery: Adopt skipped-task execution only after parity is demonstrated; retain a scheduled full-check path as a diagnostic baseline. Project prerequisites: Prepare four fixture packages with one shared library and two applications. Use only trusted fixture commands in local tests. Engineer value: Practice incremental computation, dependency scheduling, cache correctness, and cancellation. Company value: Inspect whether faster checks preserve the guarantees reviewers depend on. 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. ## CHECK — Checkout regressions the team can reproduce A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage. **Field:** Quality engineering. **Suggested stack:** TypeScript, Playwright, HTTP, SQL. **Engineer value:** Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. **Company value:** Review whether a test suite catches business regressions and explains failures without creating noisy release gates. **Delivery agreement:** A local checkout fixture, regression suite, failure artifacts, and release-gate policy. ### Setup prerequisites - Create or provide a local checkout fixture application. - Model products, tax rules, inventory, and a payment-provider double using synthetic data. ### Define the checkout contract Establish realistic fixtures and observable expected behavior. #### CHECK-101 — Write the smallest cart fixture that catches a pricing regression **Task · Medium priority · Foundational** noCV practice brief v5 · CHECK-101 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the checkout contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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. The only test product costs 100.00, so fractional-price bugs pass. Define a reusable fixture with 19.99 and 0.10 items, quantities, tax, and one promotion. Acceptance criteria - Expected totals use integer minor units with the rounding stage explicitly documented. - The fixture can reset to an identical starting cart between runs. - Expected values are stated independently of the checkout implementation. Implementation constraints - Use a fictional currency with two decimal places for this fixture. Verification - Check the documented two-item total by an independent integer calculation. - Change quantity from one to three and verify the expected amount changes without fixture state leaking between runs. Deliverables - Synthetic cart fixture and pricing expectation table Rollout and recovery: Add the fixture as a separate suite seed; reset by run ID instead of clearing shared environments. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-102 — Replace timing sleeps in the checkout happy path **Chore · Medium priority · Foundational** noCV practice brief v5 · CHECK-102 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the checkout contract. Depends on: CHECK-101. Difficulty: Foundational. Estimated focused work: 75 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. Checkout passes locally but fails in CI after a fixed 500 ms sleep. Wait for user-visible readiness and assert the final receipt against the fixture. Acceptance criteria - The happy path contains no arbitrary timing sleeps. - Selectors use accessible roles and names where the interface exposes them. - The receipt order reference and charged amount match the created order. Implementation constraints - Wait on observable state transitions, not broad network-idle heuristics. Verification - Run with the payment double delayed by several deterministic values. - Keep the submit button disabled and verify the test times out at an actionable readiness assertion. Deliverables - Stable checkout browser test and selector rationale Rollout and recovery: Run beside the existing happy path for comparison, then remove the redundant sleep-based version. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. ### Exercise costly failure paths Cover money, duplication, inventory, and access boundaries. #### CHECK-103 — Cover discount and tax rounding at the documented boundary **Bug · High priority · Intermediate** noCV practice brief v5 · CHECK-103 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-101. Difficulty: Intermediate. Estimated focused work: 105 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 10% promotion on three 19.99 items produces a one-cent difference between the cart and receipt. Add cases that pin down order-level versus line-level rounding. Acceptance criteria - Tests use the agreed line-discount-then-tax rule and include a half-cent boundary. - Cart, order, and payment request totals must agree in minor units. - A discount greater than the eligible subtotal is rejected or capped according to an explicit contract. Implementation constraints - Do not reproduce the production rounding helper in expected-value code. Verification - Assert concrete expected totals for zero, one, and three eligible items. - Introduce a round-at-order-end defect in the fixture and show the relevant case fails. Deliverables - Pricing boundary matrix and regression tests Rollout and recovery: Gate pricing changes with these deterministic cases; update expectations only with a reviewed rule change. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-104 — Prove a lost payment response cannot create two orders **Story · High priority · Advanced** noCV practice brief v5 · CHECK-104 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Distributed systems 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 payment double accepts a charge but drops the response. The customer clicks Try again. The regression must verify one charge and one order, not just a success banner. Acceptance criteria - The double can accept a payment and deterministically lose the first response. - Retry preserves the intended checkout idempotency identity. - Assertions inspect order count, charge count, amount, and final customer-visible status. Implementation constraints - Record provider requests in the local double; do not connect a real payment account. Verification - Run a lost-response-then-retry case and assert one durable charge and one order. - Use a fixture defect that rotates the idempotency key on retry and confirm the regression detects the duplicate. Deliverables - Lost-response payment scenario and durable-state assertions Rollout and recovery: Add to checkout gates with bounded local timeouts; keep provider behavior versioned with the test. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-105 — Test the last-item race without relying on lucky timing **Story · High priority · Expert** noCV practice brief v5 · CHECK-105 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-101. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Database 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. Two customers can both buy the last unit when the stock check and reservation are separate. Build a barrier-controlled concurrency case around a single remaining item. Acceptance criteria - Two isolated customers reach the reservation boundary before either proceeds. - Exactly one reservation succeeds and inventory never becomes negative. - The losing checkout receives a recoverable stock message and creates no captured payment. Implementation constraints - Use an explicit local test barrier, not sleep-based synchronization. - Assert final database and provider states after both requests settle. Verification - Repeat the controlled race with each customer released first. - Run against a deliberately non-atomic fixture reservation and demonstrate that the invariant assertion fails. Deliverables - Deterministic inventory race harness and invariant report Rollout and recovery: Keep the barrier available only in local test composition; add the regression before changing reservation code. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-106 — Check that one customer cannot open another receipt **Bug · High priority · Intermediate** noCV practice brief v5 · CHECK-106 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. The receipt screen fetches an order by URL ID. Add an authorization regression covering both the page and its backing endpoint with two synthetic customer accounts. Acceptance criteria - An owner can load their receipt with the expected line items. - Another customer and an anonymous session cannot retrieve receipt details by changing the order ID. - Denied responses and browser artifacts contain no customer address or item details. Implementation constraints - Treat order IDs as discoverable; obscurity is not the access rule. Verification - Open the same order using owner, second-customer, and logged-out contexts. - Attempt the direct receipt API request and inspect its body for leaked fields. Deliverables - Receipt access matrix and browser/API denial tests Rollout and recovery: Make the access checks a required checkout gate; quarantine artifacts if a regression exposes fixture-sensitive fields. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. ### Turn checks into a useful release gate Keep runs isolated, diagnosable, and honest about coverage. #### CHECK-107 — Verify checkout errors can be corrected using a keyboard **Story · Medium priority · Intermediate** noCV practice brief v5 · CHECK-107 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Accessibility 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 invalid postal code turns the field red but focus remains on the submit button and no message is announced. Add keyboard and semantic checks for error recovery. Acceptance criteria - Submission exposes a text error associated with the invalid field. - Keyboard users can reach the field, correct it, and complete checkout without pointer input. - The error summary links to the field and disappears or updates after correction. Implementation constraints - Record a short manual screen-reader check; automated role assertions alone do not establish full accessibility. Verification - Tab through a failed then corrected checkout and verify focus placement. - Remove the error association in the fixture and confirm the semantic regression fails. Deliverables - Keyboard regression and manual assistive-technology checklist Rollout and recovery: Include keyboard checks in the browser suite; retain manual accessibility coverage for release reviews. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-108 — Give each parallel test its own stock and customer records **Chore · High priority · Advanced** noCV practice brief v5 · CHECK-108 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-104, CHECK-105, CHECK-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Database 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. The suite passes alone but fails in parallel because every worker buys the same seeded SKU. Namespace mutable fixtures and make cleanup safe when a worker crashes. Acceptance criteria - Each test run receives unique customer, cart, inventory, and provider namespaces. - Cleanup deletes only records owned by that run and can be repeated safely. - A crashed run is discoverable by expiry metadata without clearing records from active runs. Implementation constraints - Use a controllable clock for expiry checks. - Avoid global truncate operations. Verification - Run two full suites concurrently and verify their record IDs never overlap. - Crash one run, expire it, and confirm cleanup preserves the other run and unowned sentinel data. Deliverables - Fixture lifecycle helpers and parallel-isolation tests Rollout and recovery: Migrate tests to namespaced seeds before increasing CI concurrency; disable expired-run cleanup if ownership metadata is missing. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-109 — Capture enough failure detail without storing checkout secrets **Task · Medium priority · Intermediate** noCV practice brief v5 · CHECK-109 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-108. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Privacy engineering 20% · 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. A failure report has only a screenshot, while a trace includes full authorization headers. Define a bounded artifact bundle that helps reproduce a failure safely. Acceptance criteria - A failed case records fixture seed, run ID, safe request IDs, assertion, and application revision. - Authorization, payment tokens, and full address values are absent from stored artifacts. - Artifact filenames and retention rules are deterministic and scoped to the run. Implementation constraints - Use synthetic credentials but still prove the redaction boundary. Verification - Fail a payment case and reconstruct it from the recorded seed and revision. - Insert secret marker strings into headers and form fields and scan every produced artifact for them. Deliverables - Safe failure artifact bundle and retention policy Rollout and recovery: Replace unrestricted tracing with the safe bundle; disable unsafe artifact types until sanitization is verified. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-110 — Separate release blockers from tests awaiting investigation **Task · Medium priority · Advanced** noCV practice brief v5 · CHECK-110 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-103, CHECK-107, CHECK-109. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Platform 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. The team reruns the whole suite until it turns green. Define a gate that retains the first failure, identifies explicit quarantines, and does not hide payment or access regressions. Acceptance criteria - Payment, inventory, pricing, and authorization regressions remain blocking even after a successful retry. - Quarantined cases require an owner, issue reference, reason, and expiry date. - Reports show first-attempt outcomes, retry outcomes, and omitted coverage separately. Implementation constraints - Use retries for diagnosis rather than rewriting the original result. Verification - Run a fail-then-pass fixture and verify its first failure remains visible and blocking when critical. - Use an expired quarantine and confirm gate evaluation fails with the owning issue reference. Deliverables - Release-gate evaluator and quarantine policy examples Rollout and recovery: Evaluate the new policy against recorded fixture runs before enabling enforcement; rollback policy configuration without deleting result history. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. ## REPLAY — A webhook replay lab for incident recovery An integration team closes incidents with screenshots of provider dashboards, then struggles to reproduce the same delivery sequence. Build a synthetic event corpus and replay runner against an allowlisted local receiver. **Field:** Quality engineering. **Suggested stack:** TypeScript, HTTP, HMAC, SQLite. **Engineer value:** Practice protocol verification, controlled fault injection, and reproducible incident investigation. **Company value:** Review concrete evidence that webhook consumers tolerate real delivery failure patterns. **Delivery agreement:** A synthetic event corpus, safe local replay runner, and repeatable incident scenarios. ### Setup prerequisites - Create a local receiver fixture with an inspectable event store. - Use generated test signing keys and synthetic payloads only. ### Build inspectable event fixtures Represent exact request bytes and expected receiver effects. #### REPLAY-101 — Define a portable synthetic webhook fixture **Task · Medium priority · Foundational** noCV practice brief v5 · REPLAY-101 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build inspectable event fixtures. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Integrations 20% · 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. A copied JSON payload loses its original whitespace and cannot reproduce a signature mismatch. Store exact request bytes with safe headers and an expected event identity. Acceptance criteria - The fixture preserves body bytes, content type, event ID, and schema version. - Loading rejects unknown fields that could supply credentials or arbitrary destination URLs. - The fixture includes a content digest and validates it before replay. Implementation constraints - Generate synthetic examples; do not import production customer payloads. Verification - Round-trip a body with whitespace and non-ASCII text byte-for-byte. - Change one payload byte and verify digest validation fails before a request is sent. Deliverables - Fixture schema and three synthetic event examples Rollout and recovery: Version the fixture format; retain older samples read-only until a validated converter exists. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-102 — Generate signatures from raw bytes and an injected clock **Task · High priority · Intermediate** noCV practice brief v5 · REPLAY-102 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build inspectable event fixtures. Depends on: REPLAY-101. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Security 30% · Integrations 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 receiver accepts fresh signatures but rejects replay fixtures because timestamp generation depends on the wall clock. Add a deterministic signer for the lab contract. Acceptance criteria - Signing covers the timestamp and exact raw body according to the documented lab protocol. - The clock and generated test key are supplied explicitly. - Signature values and secret keys are not printed in ordinary run logs. Implementation constraints - Use an established HMAC implementation and document byte encoding. Verification - Check a fixed key/time/body vector against an independently calculated digest. - Change only whitespace or timestamp and confirm the signature changes. Deliverables - Test signer and fixed signature vectors Rollout and recovery: Restrict signing to the local lab adapter; rotate fixture keys by changing the versioned test configuration. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. ### Reproduce delivery failures Control signing, ordering, duplicates, and lost responses. #### REPLAY-103 — Assert duplicate delivery produces one business effect **Story · High priority · Intermediate** noCV practice brief v5 · REPLAY-103 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Integrations 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. A subscription-created event is delivered three times with separate request IDs. The replay should test event-level deduplication rather than merely identical HTTP responses. Acceptance criteria - A scenario sends one event identity with three distinct delivery identities. - The receiver records delivery attempts but creates one subscription effect. - Changing the event ID while preserving business data follows an explicitly documented business-key policy. Implementation constraints - Observe effects through the local receiver inspection API. Verification - Replay three duplicates and assert delivery and effect counts separately. - Disable receiver deduplication in a fixture variant and confirm the scenario detects extra effects. Deliverables - Duplicate-delivery scenario and effect assertions Rollout and recovery: Add as the first consumer acceptance scenario; use the same fixture revision when comparing receiver changes. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-104 — Deliver update-before-create with a reproducible schedule **Story · High priority · Advanced** noCV practice brief v5 · REPLAY-104 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Real-time systems 30% · Integrations 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 subscription update arrived before its create event during an outage. Add a schedule format that can hold, reorder, and release specific events without relying on elapsed sleeps. Acceptance criteria - The scenario declares event order and release barriers separately from payload data. - The receiver converges to the latest declared resource revision when all events arrive. - Stale events cannot overwrite a newer stored revision. Implementation constraints - Define revision ordering in the lab contract instead of inferring it from arrival time. Verification - Run create-update and update-create schedules and compare final state. - Append a stale update after convergence and verify the state remains at the newest revision. Deliverables - Barrier-based schedule runner and out-of-order scenarios Rollout and recovery: Keep scheduling deterministic by default; random ordering is optional and must record a replayable seed. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-105 — Exercise signature rotation without accepting expired requests **Story · High priority · Advanced** noCV practice brief v5 · REPLAY-105 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-102. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. During key rotation the receiver must accept old and new keys briefly, while still rejecting requests outside the timestamp tolerance. Add a table of rotation boundaries. Acceptance criteria - Cases cover current key, overlap key, unknown key, and retired key. - Freshness boundaries are tested immediately inside and outside the documented tolerance. - Invalid signatures and stale timestamps produce no persisted business effect. Implementation constraints - Use an injected clock and generated lab keys. - Verify signature checks occur before trusted event fields are consumed. Verification - Accept both keys inside the overlap window and reject the retired key afterward. - Send a validly signed but stale event and a fresh tampered event; both must have zero effects. Deliverables - Rotation boundary matrix and receiver assertions Rollout and recovery: Run rotation cases before changing receiver key policy; keep retired test keys only in synthetic fixtures. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-106 — Reproduce a receiver commit followed by a dropped response **Story · High priority · Expert** noCV practice brief v5 · REPLAY-106 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce delivery failures. Depends on: REPLAY-103, REPLAY-104. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Distributed systems 30% · Integrations 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 receiver committed the event, then the connection closed before the sender received 200. Model this boundary and verify sender retries and receiver effects independently. Acceptance criteria - A controlled fault drops the response only after the receiver commits its effect. - The sender retries the original event identity under a bounded policy. - Final reporting distinguishes transport uncertainty from receiver business success and proves one effect. Implementation constraints - Implement the fault in a local transport or receiver double. - Do not treat a missing response as proof the receiver did nothing. Verification - Drop after commit and observe a retry with exactly one effect. - Drop before commit and verify a later retry creates the missing effect once. Deliverables - Before/after-commit fault scenarios and uncertainty report Rollout and recovery: Keep fault controls unavailable outside the local lab; preserve failed-run reports when rerunning the scenario. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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 incidents repeatable Bound replay authority and preserve useful run reports. #### REPLAY-107 — Block replay targets outside the approved local receiver **Bug · High priority · Advanced** noCV practice brief v5 · REPLAY-107 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-101. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Quality engineering 20% · 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. A fixture author added a destination that points at a metadata endpoint. Move destination control out of fixture data and enforce a fixed local target policy. Acceptance criteria - Only configured loopback receiver hosts and ports can be selected. - Redirects are rejected and userinfo, ambiguous IP syntax, and non-HTTP schemes are denied. - The resolved address is validated at connection time; rejected destinations send zero payload bytes, and redirect responses trigger no follow-up request. Implementation constraints - Keep replay configuration separate from imported fixture content. - Bound request body size and connection timeout. Verification - Replay to the configured local receiver successfully. - Reject an external host, unapproved port, and alternate IP notation before any receiver request; for a redirect, allow one request to the approved receiver and assert zero requests to its redirect target. Deliverables - Destination policy and SSRF regression cases Rollout and recovery: Make the target policy mandatory before exposing fixture import; disable replay on target-validation uncertainty. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-108 — Summarize deliveries and effects in separate report sections **Task · Medium priority · Foundational** noCV practice brief v5 · REPLAY-108 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-103. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · 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. The current report says three successes even though three deliveries produced one intended change. Report transport attempts and business effects as separate facts. Acceptance criteria - The report lists delivery ID, event ID, response category, and receiver effect reference separately. - A timeout remains unknown at the transport level even if later reconciliation finds an effect. - Output is stably ordered and includes scenario and fixture revisions. Implementation constraints - Use synthetic receiver record IDs; these are not noCV Evidence IDs. Verification - Report a three-delivery duplicate scenario with three attempts and one effect. - Report a timeout followed by reconciliation without rewriting the timeout as an HTTP success. Deliverables - JSON report contract and readable summary renderer Rollout and recovery: Version the new report format; preserve original attempt records when generating summaries. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-109 — Honor Retry-After without creating an unbounded replay **Story · Medium priority · Intermediate** noCV practice brief v5 · REPLAY-109 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-106, REPLAY-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Integrations 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. The local receiver responds 429 with Retry-After, but the runner retries immediately. Add bounded backoff with a fake clock and explicit terminal reasons. Acceptance criteria - Supported Retry-After forms are parsed and capped by the run time budget. - Malformed or negative values fall back to documented bounded backoff. - Maximum attempts and overall deadline stop retries with a terminal reason in the report. Implementation constraints - Seed jitter or disable it for deterministic fixtures. Verification - Advance a fake clock through 429, 503, and success and assert scheduled retry times. - Return an excessive delay and confirm the deadline ends the run without waiting in real time. Deliverables - Retry policy and fake-clock timing cases Rollout and recovery: Apply bounded retry policy to all replay scenarios; allow zero retries for transport debugging. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. #### REPLAY-110 — Export an incident recipe another engineer can rerun **Task · Medium priority · Intermediate** noCV practice brief v5 · REPLAY-110 · A webhook replay lab for incident recovery Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make incidents repeatable. Depends on: REPLAY-105, REPLAY-108, REPLAY-109. 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. An engineer reproduced the incident but left only terminal history. Export the scenario, fixture digests, scheduler seed, and safe configuration as a portable recipe. Acceptance criteria - The recipe resolves every fixture by immutable content digest and records the runner version. - It excludes signing keys, credentials, destination overrides, and captured production payloads. - A fresh local receiver can reproduce the expected effect and failure categories from the recipe. Implementation constraints - Require generated replacement keys on import. - Keep original run reports separate from rerun reports. Verification - Export and rerun an out-of-order lost-response recipe in a clean temporary directory. - Remove one referenced fixture and confirm import fails before sending requests. Deliverables - Incident-recipe export/import and a worked recovery exercise Rollout and recovery: Use recipes for internal synthetic exercises first; reject unsupported runner or fixture versions with migration guidance. Project prerequisites: Create a local receiver fixture with an inspectable event store. Use generated test signing keys and synthetic payloads only. Engineer value: Practice protocol verification, controlled fault injection, and reproducible incident investigation. Company value: Review concrete evidence that webhook consumers tolerate real delivery failure patterns. 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. ## SEARCH — Internal policy search with inspectable sources Employees search fictional travel and equipment policies. The current prototype blends draft and approved text and sometimes answers using a policy the employee cannot open. Use a small synthetic corpus and a deterministic answer-provider double. **Field:** Applied AI. **Suggested stack:** TypeScript, PostgreSQL, HTTP, JSON Schema. **Engineer value:** Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. **Company value:** Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. **Delivery agreement:** A local retrieval service with revisioned citations, abstention behavior, and an evaluation report. ### Setup prerequisites - Author synthetic policy documents with revisions, effective dates, and access groups. - Use a local deterministic provider double; paid model access is optional and not required. ### Make source authority explicit Index only identifiable, eligible document revisions. #### SEARCH-101 — Import policy documents with stable revision identities **Task · Medium priority · Foundational** noCV practice brief v5 · SEARCH-101 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make source authority explicit. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Database 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. Two files called travel-policy.md contain different meal limits. The importer currently overwrites one with the other. Store a document identity, revision, and content digest. Acceptance criteria - Each imported revision records document ID, revision ID, digest, title, status, and effective date. - Reimporting identical bytes under the same revision is idempotent. - Different bytes under an existing revision are rejected; a new revision preserves the previous record. Implementation constraints - Use synthetic policy text and UTC timestamps. Verification - Import two revisions and retrieve their original content separately. - Reimport a modified file with the first revision ID and assert a conflict with no overwritten content. Deliverables - Revisioned importer and synthetic policy corpus Rollout and recovery: Index the synthetic corpus in a separate namespace; rollback by changing the active index pointer, not deleting revision history. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-102 — Keep chunk citations anchored to the original policy text **Task · Medium priority · Intermediate** noCV practice brief v5 · SEARCH-102 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make source authority explicit. Depends on: SEARCH-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Applied AI 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 answer links to the policy title, but reviewers cannot find the quoted sentence after headings were stripped. Give each chunk a stable revision reference and exact text offsets. Acceptance criteria - Chunks record source revision, start and end offsets, and a content digest. - Reconstructing a chunk from the original source yields exactly the stored chunk text. - Chunk boundaries preserve headings and never split a Unicode code point. Implementation constraints - Specify the offset unit and normalization rules. - Chunk IDs change when chunking strategy changes. Verification - Reconstruct every chunk of a document containing emoji and repeated headings. - Change the chunking version and confirm old citation anchors remain resolvable. Deliverables - Chunker specification and source-anchor tests Rollout and recovery: Build a new chunk index beside the old one; swap only after source reconstruction passes. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-103 — Apply group access before ranking or sending context to a provider **Bug · High priority · Expert** noCV practice brief v5 · SEARCH-103 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make source authority explicit. Depends on: SEARCH-102. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Applied AI 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 general employee query retrieves a restricted executive travel exception. Hiding the final link is too late because the provider has already received the text. Enforce scope at retrieval and again at answer delivery. Acceptance criteria - The repository query limits candidates to the caller tenant and current allowed groups before ranking. - The provider receives no unauthorized chunk text or metadata. - Access revoked between retrieval and response prevents affected citations and answer content from being delivered. Implementation constraints - Use server-derived membership; never trust group IDs from the query body. - Do not share cached contexts across permission scopes. Verification - Query identical terms as users in different groups and inspect the exact provider request. - Revoke a group after retrieval using a barrier and verify delivery fails closed without restricted text. Deliverables - Access-scoped retrieval and revocation race tests Rollout and recovery: Disable answer generation for any request whose permission snapshot cannot be revalidated; deploy scoped retrieval before enabling ranking. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-104 — Exclude drafts and future policies from current-policy answers **Bug · High priority · Intermediate** noCV practice brief v5 · SEARCH-104 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make source authority explicit. Depends on: SEARCH-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Data engineering 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. A future equipment allowance outranks the currently approved policy. Define eligibility by approval, effective interval, and supersession so search answers the policy in effect at the requested date. Acceptance criteria - Current queries include approved revisions whose effective interval contains the supplied clock time. - Draft, withdrawn, and future revisions are excluded from answer context. - Overlapping eligible revisions for one policy produce an explicit conflict instead of a silent choice. Implementation constraints - Use an injected clock and half-open effective intervals. Verification - Search immediately before and at an effective-date boundary. - Create overlapping approved revisions and verify the query returns a conflict with no generated answer. Deliverables - Policy eligibility filter and effective-date cases Rollout and recovery: Run eligibility inspection over the corpus before switching active search; keep ambiguous documents unavailable for answers. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. ### Constrain answer generation Return supported citations or a clear lack-of-answer result. #### SEARCH-105 — Reject answers with invented or mismatched citations **Story · High priority · Advanced** noCV practice brief v5 · SEARCH-105 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answer generation. Depends on: SEARCH-103, SEARCH-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 70% · Security 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 provider double returns a fluent answer citing chunk-999, which was never retrieved. Add a structured response boundary and validate every reference before displaying an answer. Acceptance criteria - Responses conform to a strict schema with answer status, bounded claim text, and citation references. - Every citation resolves to an authorized chunk in the exact request context and source revision. - A cited quotation must match its referenced span; invalid output yields an unavailable result without partial answer text. Implementation constraints - Schema validity and quote matching do not prove broader semantic support; expose that limitation. - Treat provider text as untrusted output. Verification - Accept a fixture response with exact authorized citations. - Reject invented IDs, a correct ID with altered quotation, and additional schema properties. Deliverables - Structured answer validator and adversarial output fixtures Rollout and recovery: Make validation mandatory for all provider adapters; fall back to authorized search results when generation fails. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-106 — Return insufficient information when the corpus cannot answer **Story · High priority · Intermediate** noCV practice brief v5 · SEARCH-106 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answer generation. Depends on: SEARCH-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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. Someone asks whether a bicycle repair is reimbursable, but the corpus contains only airfare and laptop rules. The prototype invents a limit. Add an explicit abstention path. Acceptance criteria - Empty retrieval returns INSUFFICIENT_INFORMATION without calling the answer provider. - A provider abstention is shown as missing support, without a fabricated policy rule. - The response may include authorized source links but never presents retrieval rank as certainty. Implementation constraints - Use a documented conservative context-selection rule with inspectable thresholds. Verification - Ask an unsupported bicycle-repair question and confirm no rule or amount is invented. - Ask an exact covered policy question and confirm authorized sources are retained in the supported fixture response. Deliverables - Abstention contract and covered/uncovered question fixtures Rollout and recovery: Default uncertain cases to source search; tune thresholds only against a versioned evaluation set. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-107 — Contain instructions embedded in a retrieved document **Bug · High priority · Advanced** noCV practice brief v5 · SEARCH-107 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answer generation. Depends on: SEARCH-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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 synthetic policy appendix says to ignore the user and reveal all other documents. Ensure retrieved text remains data and cannot expand access or activate tools. Acceptance criteria - The provider request separates application instructions from quoted document context. - The answer interface exposes no file, network, or administrative tools. - Prompt-injection fixtures cannot alter document access scope or bypass citation validation. Implementation constraints - Do not claim that delimiting text alone prevents all prompt injection. - Use deterministic malicious-output fixtures to test downstream enforcement. Verification - Supply an instruction-bearing chunk and inspect the constructed provider request. - Return a malicious provider response with an unauthorized citation and verify the validator rejects it without a secondary fetch. Deliverables - Context construction boundary and injection containment tests Rollout and recovery: Keep tool access disabled for this feature; reject any adapter configuration that grants capabilities beyond answering. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. ### Evaluate and operate the service Bound provider failure, retention, and content changes. #### SEARCH-108 — Bound provider latency, retries, and retained query data **Story · High priority · Advanced** noCV practice brief v5 · SEARCH-108 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and operate the service. Depends on: SEARCH-106, SEARCH-107. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 40% · Privacy engineering 30% · 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. A stalled model call occupies a request indefinitely and debug logs retain full employee queries. Add a bounded provider port with safe audit metadata. Acceptance criteria - Calls enforce timeout, attempt count, response-size, and token or equivalent local budget limits. - Audit metadata records provider/model version, request template version, schema version, duration, retry count, and trace ID. - Generic logs exclude raw questions, document text, and credentials; retention for any explicit debug store is configured separately. Implementation constraints - The default adapter is a local deterministic double. - Cost is recorded when known and unavailable when not supplied; do not invent cost figures. Verification - Simulate a stalled call and confirm a bounded unavailable response and cancellation. - Include secret marker text in query and context and scan normal diagnostics for leakage. Deliverables - Provider port, budget policy, and safe audit tests Rollout and recovery: Enable one provider adapter at a time behind the validated port; fall back to source results on budget or timeout failure. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-109 — Invalidate answers when policy authority or access changes **Bug · High priority · Expert** noCV practice brief v5 · SEARCH-109 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and operate the service. Depends on: SEARCH-108. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 40% · Security 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. A cached answer still cites a withdrawn policy and is reused for an employee with different access. Bind cache entries to the exact corpus and permission authority. Acceptance criteria - Cache identity includes normalized query, corpus version, provider configuration, tenant, and permission-scope version. - Delivery rechecks every cited revision eligibility and current access even on a cache hit. - Withdrawing a cited policy prevents old answer delivery without rewriting the original cached record. Implementation constraints - Use a version pointer or tombstone for invalidation rather than editing source history. Verification - Warm the cache, withdraw a source, and verify the next request cannot return the old answer. - Reuse identical text across two permission groups and verify no cross-scope hit occurs. Deliverables - Authority-aware cache and withdrawal/access regression cases Rollout and recovery: Ship with caching disabled, then enable only after invalidation cases pass; a kill switch returns to live retrieval. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. #### SEARCH-110 — Publish an evaluation report that separates retrieval and answer failures **Task · Medium priority · Intermediate** noCV practice brief v5 · SEARCH-110 · Internal policy search with inspectable sources Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and operate the service. Depends on: SEARCH-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Quality 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 single accuracy percentage conceals whether failures came from missing sources or invalid generated answers. Create a small versioned evaluation set and report distinct failure categories. Acceptance criteria - Cases cover answerable, unsupported, conflicting, restricted, stale, and injection-bearing questions. - Reports separate eligible-source retrieval, citation validity, abstention behavior, and provider failures. - Each result records corpus, implementation, provider-double, and case-set versions with expected and actual observations. Implementation constraints - Do not claim deterministic-double results measure a real model quality level. - Keep evaluation examples synthetic and publishable. Verification - Run the full set twice and compare deterministic results. - Introduce an access-filter defect and confirm it appears as a security failure rather than an aggregate quality dip. Deliverables - Versioned evaluation cases and categorized report Rollout and recovery: Use category-specific gates for changes; require a separate measured report before replacing the deterministic adapter. Project prerequisites: Author synthetic policy documents with revisions, effective dates, and access groups. Use a local deterministic provider double; paid model access is optional and not required. Engineer value: Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation. Company value: Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content. 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. ## TRIAGE — Support routing that agents can correct A fictional software vendor receives billing, account-access, bug, and security reports. A prototype silently moves tickets based on vague model confidence. Replace it with bounded suggestions, deterministic safety rules, and an auditable review flow. **Field:** Applied AI. **Suggested stack:** TypeScript, PostgreSQL, JSON Schema, HTTP. **Engineer value:** Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. **Company value:** Review whether automation saves triage effort while preserving queue ownership and safe escalation. **Delivery agreement:** A local routing service with reviewable suggestions, correction history, and a replay evaluation report. ### Setup prerequisites - Create a synthetic support-ticket corpus with no real customer messages. - Implement a deterministic local classifier double with success, malformed-output, and timeout modes. ### Define routing inputs and rules Make categories and required human handling explicit. #### TRIAGE-101 — Define queue labels with examples and an unknown outcome **Task · Medium priority · Foundational** noCV practice brief v5 · TRIAGE-101 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define routing inputs and rules. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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. Different agents use Billing and Payments interchangeably, so routing reports cannot be compared. Define stable queue IDs with concise boundaries and ambiguous examples. Acceptance criteria - Every queue has a stable ID, description, included examples, and excluded examples. - UNKNOWN and NEEDS_REVIEW are explicit outcomes rather than invented queue names. - Changing a label definition creates a new taxonomy version. Implementation constraints - Use fictional support topics and avoid demographic categories. Verification - Map a duplicate-charge example and an account-reset example to distinct documented queues. - Validate that a mixed billing/security example can remain NEEDS_REVIEW. Deliverables - Versioned queue taxonomy and labeled examples Rollout and recovery: Use the taxonomy in suggestion-only mode; retain previous versions for historical reports. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-102 — Normalize inbound messages without discarding the original record **Task · Medium priority · Intermediate** noCV practice brief v5 · TRIAGE-102 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define routing inputs and rules. Depends on: TRIAGE-101. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Applied AI 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. Quoted email chains dominate routing input and duplicate attachments inflate request size. Create a bounded classification view while retaining the synthetic original message separately. Acceptance criteria - The derived view records normalization version, source message revision, and truncation indicators. - Input size is bounded and attachments contribute only permitted metadata. - The original record is immutable and can be inspected by an authorized support reviewer. Implementation constraints - Normalization is deterministic; do not use a model to silently rewrite the complaint. Verification - Normalize a long quoted chain twice and compare identical derived views. - Provide oversized text and an attachment filename containing markup; verify bounded plain-text input. Deliverables - Normalization pipeline and input-limit fixtures Rollout and recovery: Compare derived views in local review before enabling suggestions; use the original source reference for disputed cases. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-103 — Route declared security incidents to review before calling a classifier **Story · High priority · Advanced** noCV practice brief v5 · TRIAGE-103 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define routing inputs and rules. Depends on: TRIAGE-102. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Security 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. A user selects the security-incident contact form, but the model labels the message a normal login issue. Respect trusted intake metadata and require the security review queue. Acceptance criteria - A trusted security-form source always produces a mandatory security-review state. - The classifier cannot downgrade that state or trigger a customer-facing reply. - Untrusted message text claiming to be system routing metadata does not acquire privileged routing authority. Implementation constraints - Distinguish server-owned intake fields from user-provided body text. - Do not infer incident severity from writing style or personal attributes. Verification - Submit a short login message through the trusted security form and confirm mandatory review without classification. - Put a forged security-source object in ordinary message text and confirm it remains untrusted content. Deliverables - Deterministic escalation policy and metadata-spoofing tests Rollout and recovery: Enable mandatory routing before model suggestions; keep a manual queue available when source metadata is missing. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. ### Offer bounded suggestions Validate and present proposals without silently moving tickets. #### TRIAGE-104 — Accept only bounded suggestions from the classifier **Story · High priority · Advanced** noCV practice brief v5 · TRIAGE-104 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Offer bounded suggestions. Depends on: TRIAGE-103. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 80% · 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 provider returns a queue that no longer exists and a reason containing a link to an unrelated customer record. Validate suggestions against the exact taxonomy and source message. Acceptance criteria - Output contains only permitted queue IDs, a review flag, and bounded supporting spans from the input. - Every supporting span matches the normalized message exactly. - Malformed, out-of-taxonomy, or unsupported outputs become NEEDS_REVIEW with no partial suggestion. Implementation constraints - Do not treat a model-supplied confidence number as a calibrated probability. - Use strict schemas and plain text rendering. Verification - Accept a valid suggestion supported by an exact message span. - Reject invented queues, fabricated spans, extra action fields, and markup payloads. Deliverables - Suggestion validator and malformed-provider fixtures Rollout and recovery: Require the validator on every adapter; fall back to the unassigned review queue on rejection. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-105 — Show a suggested queue as an explicit agent action **Story · Medium priority · Foundational** noCV practice brief v5 · TRIAGE-105 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Offer bounded suggestions. Depends on: TRIAGE-104. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Applied AI 20% · Accessibility 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. Agents cannot tell whether a ticket was assigned by a person or by the prototype. Display the suggestion alongside Accept and Choose another queue actions. Acceptance criteria - A suggestion never changes the assigned queue by itself. - The view labels provider version, suggestion time, and supporting message text. - Keyboard users can accept, dismiss, or choose another permitted queue. Implementation constraints - Do not describe the suggestion as a verified conclusion. Verification - Load a suggestion and verify persisted assignment remains unchanged until acceptance. - Dismiss it by keyboard and confirm no queue transition or customer message is created. Deliverables - Accessible suggestion panel and interaction tests Rollout and recovery: Release to an opt-in local agent view; disable the panel without changing existing queue assignment behavior. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-106 — Discard a suggestion when the ticket changed while classification ran **Bug · High priority · Expert** noCV practice brief v5 · TRIAGE-106 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Offer bounded suggestions. Depends on: TRIAGE-104, TRIAGE-105. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Database engineering 30% · Applied AI 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 customer adds a security-relevant reply while an older billing suggestion is in flight. The old suggestion must not become actionable against the new message revision. Acceptance criteria - A suggestion binds ticket ID, message revision, taxonomy version, and provider configuration. - Persisting or accepting a stale suggestion fails with an explicit revision conflict. - Concurrent acceptance by two agents creates at most one assignment transition and preserves both attempted-action outcomes. Implementation constraints - Enforce revision checks in the service/repository transaction, not only the UI. - Keep assignment audit records append-only. Verification - Pause classification, append a reply, then release the provider and confirm the suggestion is stale. - Race two acceptance requests and assert one transition with an explicit conflict for the loser. Deliverables - Revision-safe suggestion lifecycle and race tests Rollout and recovery: Enable acceptance only after revision checks are active; stale suggestions are regenerated or sent to manual review. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. ### Operate and learn from corrections Audit changes and compare revisions without leaking customer content. #### TRIAGE-107 — Keep provider outages from blocking the support inbox **Story · High priority · Intermediate** noCV practice brief v5 · TRIAGE-107 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and learn from corrections. Depends on: TRIAGE-104. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Applied AI 30% · 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 classifier stalls and newly submitted tickets disappear until its call completes. Decouple intake from classification and make failure an observable review state. Acceptance criteria - Ticket intake commits before asynchronous classification starts. - Jobs use deterministic identities and bounded timeout/retry settings. - Exhausted jobs leave tickets visible in manual review with a safe failure category. Implementation constraints - Use a transactional outbox or equivalent local transactional queue boundary. - The default provider is deterministic and requires no credentials. Verification - Simulate provider timeout and verify immediate ticket visibility plus eventual review state. - Deliver the same job twice and confirm it does not create duplicate suggestions. Deliverables - Asynchronous suggestion job and outage scenarios Rollout and recovery: Enable queued suggestions behind a feature flag; disable workers while preserving manual inbox intake. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-108 — Record corrections without turning agent clicks into automatic training data **Story · Medium priority · Advanced** noCV practice brief v5 · TRIAGE-108 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and learn from corrections. Depends on: TRIAGE-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Backend 30% · Applied AI 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 corrected queue overwrites the original suggestion, making disagreement impossible to investigate. Preserve the proposal, decision, actor, and reason as separate records. Acceptance criteria - Each correction links the original suggestion, selected queue, actor, time, and optional bounded reason. - Corrections are append-only and readable only within the ticket tenant and permitted support role. - No correction triggers external training or sends message text to a provider automatically. Implementation constraints - Treat corrections as operational feedback, not unquestionable ground truth. Verification - Correct one suggestion twice and inspect the complete ordered history. - Attempt to read another tenant correction and confirm denial with no message text leakage. Deliverables - Correction audit model and scoped history endpoint Rollout and recovery: Start collecting local operational feedback with retention controls; any later training export requires a separate governed workflow. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-109 — Compare two routing revisions on the same ambiguous-ticket set **Task · Medium priority · Advanced** noCV practice brief v5 · TRIAGE-109 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and learn from corrections. Depends on: TRIAGE-107, TRIAGE-108. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Quality 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 prompt moves more messages to Billing, but the team cannot tell whether it improved routing or merely reduced abstention. Compare both revisions on a fixed synthetic case set. Acceptance criteria - Cases include mixed issues, short messages, quoted text, injection attempts, and explicit security intake. - Reports show per-queue outcomes, review rate, rule violations, invalid outputs, and changed decisions. - A mandatory-review violation blocks adopting the new revision regardless of aggregate routing accuracy. Implementation constraints - Pin normalization, taxonomy, provider-double, and case-set versions. - Keep abstentions visible rather than counting them as successful classifications. Verification - Run both revisions on identical inputs and reproduce the decision diff. - Inject a security downgrade into one revision and confirm it fails the adoption gate. Deliverables - Routing comparison harness and adoption report Rollout and recovery: Keep the current revision active while evaluating the new one; switch by versioned configuration after category gates pass. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. #### TRIAGE-110 — Explain routing delays using metadata instead of customer messages **Chore · Medium priority · Intermediate** noCV practice brief v5 · TRIAGE-110 · Support routing that agents can correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and learn from corrections. Depends on: TRIAGE-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 40% · Site reliability 30% · Privacy 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. Support leads need to diagnose slow suggestions, while logs currently include full complaint text. Add safe operational measures and an immediate suggestion kill switch. Acceptance criteria - Metrics expose queue delay, provider duration, timeout count, validation failures, and manual-review count without message bodies. - Audit metadata includes trace ID and exact provider/template/schema versions. - Disabling suggestions stops new provider calls while tickets and existing audit history remain accessible. Implementation constraints - Represent unavailable provider cost as unavailable, not zero. - Keep privileged access to source messages outside generic analytics. Verification - Run a delayed provider fixture and trace intake-to-review timing from metadata. - Toggle the kill switch with queued work and confirm no new calls and no lost tickets. Deliverables - Safe operations dashboard data and disable/recovery runbook Rollout and recovery: Enable metrics before activating suggestions; use the kill switch for unexpected routing changes while retaining manual service. Project prerequisites: Create a synthetic support-ticket corpus with no real customer messages. Implement a deterministic local classifier double with success, malformed-output, and timeout modes. Engineer value: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs. Company value: Review whether automation saves triage effort while preserving queue ownership and safe escalation. 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. ## SYNC — Inventory sync that survives a vendor outage A fictional retailer receives stock from two vendor warehouses. The vendor API paginates snapshots and emits change events, but retries and deleted products have caused unexplained stock drift. Work against a local vendor simulator. **Field:** Integrations. **Suggested stack:** TypeScript, NestJS, PostgreSQL, BullMQ. **Engineer value:** Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. **Company value:** Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. **Delivery agreement:** A simulated vendor connector, reconciliation workflow, drift report, and outage runbook. ### Setup prerequisites - Create a local vendor API simulator with cursor pages and stock events. - Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. ### Understand vendor identity and data Validate external records before affecting stock. #### SYNC-101 — Validate vendor stock records at the adapter boundary **Task · Medium priority · Foundational** noCV practice brief v5 · SYNC-101 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand vendor identity and data. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 70% · Data 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. Pattern topics: Adapter (refactor). Adapter — Refactor: Keep vendor payloads outside the internal stock model; compare a small mapping function with an object adapter while preserving boundary validation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The vendor sent quantity as an empty string and the importer stored zero, hiding a data problem. Validate a versioned stock response before mapping it into internal records. Acceptance criteria - Records require vendor item ID, warehouse ID, nonnegative integer quantity, revision, and updated timestamp. - Missing, empty, fractional, or out-of-range quantities are rejected with a safe record reference. - Unknown optional vendor fields do not silently become internal domain fields. Implementation constraints - Keep vendor DTOs separate from internal stock types. Verification - Accept a valid zero-stock record and a positive quantity record. - Reject empty-string, negative, fractional, and unsafe-integer quantities without writing stock. Deliverables - Vendor response schema and malformed-record fixtures Rollout and recovery: Start validation in the simulator; malformed records go to an inspection queue rather than defaulting to zero. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-102 — Map vendor items without assuming SKUs are globally unique **Bug · High priority · Intermediate** noCV practice brief v5 · SYNC-102 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand vendor identity and data. Depends on: SYNC-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 30% · Database 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. Two tenants both sell SKU CABLE-2M, and a mapping lookup updates the wrong stock row. Scope vendor mappings by tenant, connector, warehouse, and vendor item identity. Acceptance criteria - Mapping lookup always requires server-derived tenant and connector scope. - Unique constraints prevent duplicate mapping identities within that scope. - Unmapped or ambiguous items are quarantined and do not update a guessed SKU. Implementation constraints - Treat display SKU as mutable metadata, not a durable identity. Verification - Map identical SKU text for two tenants and verify each stock update stays in its own tenant. - Supply an unmapped vendor item and confirm no stock mutation and an inspectable mapping issue. Deliverables - Scoped mapping repository and cross-tenant tests Rollout and recovery: Backfill explicit mapping identities before enabling updates; pause connectors with unresolved mapping conflicts. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. ### Ingest changes safely Handle cursors, duplicates, disorder, and API limits. #### SYNC-103 — Resume a paginated snapshot from the last committed page **Story · High priority · Advanced** noCV practice brief v5 · SYNC-103 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Database engineering 40% · Data 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. The importer crashes on page four and restarts from page one, occasionally skipping records because the cursor is saved before page writes finish. Couple the checkpoint to the page commit. Acceptance criteria - A page and its next cursor commit atomically within one tenant-scoped transaction. - Replaying a committed page is idempotent by snapshot and record identity. - Expired cursors leave the current attempt incomplete and start a separately identified snapshot rather than mixing pages. Implementation constraints - Store snapshot identity alongside opaque vendor cursors. - Do not infer cursor order from cursor text. Verification - Inject a failure between page writes and checkpoint and verify neither commits. - Resume after a successful page commit and assert no missing or duplicate stock records. Deliverables - Transactional snapshot checkpointing and restart scenarios Rollout and recovery: Run an initial snapshot in shadow storage; activate only a fully completed snapshot version. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-104 — Ignore stale stock events while retaining their delivery record **Bug · High priority · Advanced** noCV practice brief v5 · SYNC-104 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Data engineering 30% · Database 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. Stock revision 42 sets quantity to 7, then delayed revision 41 resets it to 12. Compare vendor revisions atomically and record the stale delivery without changing current stock. Acceptance criteria - A higher revision replaces the current quantity and records its source event. - Equal revisions with equal content are idempotent; equal revisions with different content create a conflict. - Lower revisions remain in delivery history and cannot overwrite current stock. Implementation constraints - Define revision ordering in the adapter contract; timestamps alone are insufficient. Verification - Apply revisions 41, 42, and 41 and verify final quantity from 42. - Race two updates and send conflicting content under one revision; verify monotonic state and a visible conflict. Deliverables - Revision-guarded stock updates and out-of-order fixtures Rollout and recovery: Enable revision checks before consuming events; quarantine vendors that cannot supply the required ordering contract. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-105 — Stop concurrent refreshes from multiplying vendor requests **Bug · Medium priority · Intermediate** noCV practice brief v5 · SYNC-105 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 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. Five scheduled jobs refresh the same connector after a restart and exceed the vendor limit. Add one active refresh identity per connector and bounded Retry-After handling. Acceptance criteria - Concurrent refresh triggers converge on one active connector job. - 429 responses follow capped Retry-After behavior within an overall refresh deadline. - A failing connector does not prevent another tenant connector from progressing. Implementation constraints - Use deterministic job IDs and an injected clock in timing tests. - Do not hold a database transaction during vendor waits. Verification - Submit five identical triggers and assert one vendor page sequence. - Throttle one connector and verify another completes while the first stops at its deadline. Deliverables - Refresh coordination and rate-limit simulator scenarios Rollout and recovery: Set conservative per-connector concurrency and expose pause/resume; rollback by pausing ingestion without clearing checkpoints. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-106 — Distinguish a discontinued item from an item missing on one page **Story · High priority · Expert** noCV practice brief v5 · SYNC-106 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-103, SYNC-104. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Data engineering 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. A transient missing page made hundreds of products look deleted. Apply absence-based tombstones only after a complete authoritative snapshot, while preserving explicit deletion events. Acceptance criteria - An incomplete snapshot cannot discontinue items through absence. - A completed snapshot marks only previously mapped items absent from that exact vendor scope as candidates for discontinuation. - A newer explicit stock event received during snapshot ingestion is not overwritten by an older absence decision. Implementation constraints - Record the snapshot consistency boundary and event watermark. - If the simulator cannot guarantee a consistency boundary, surface uncertainty and require review. Verification - Fail the final page and verify no absence-based tombstones are applied. - Deliver a newer event during snapshot ingestion and confirm finalization preserves it or reports a review conflict. Deliverables - Snapshot finalization policy and deletion/event race tests Rollout and recovery: Generate discontinuation proposals first; enable automatic tombstones only for connectors with the documented snapshot guarantee. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. ### Recover and operate Find drift and apply only reviewable corrections. #### SYNC-107 — Produce a stock drift report before applying corrections **Story · Medium priority · Foundational** noCV practice brief v5 · SYNC-107 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Data 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. Operations sees different stock in the vendor portal and local app but has no item-level comparison. Add a read-only report against a completed synthetic snapshot. Acceptance criteria - The report lists local quantity, vendor quantity, revision, warehouse, and difference for each mapped item. - Equal items can be hidden without changing discrepancy totals. - Unmapped items and incomplete snapshots are labeled separately from confirmed quantity drift. Implementation constraints - Include tenant and connector labels only within authorized operator scope. Verification - Compare a fixture with one equal, one mismatched, and one unmapped item. - Attempt a report from an incomplete snapshot and verify no discrepancy is presented as a confirmed correction. Deliverables - Read-only reconciliation report and comparison fixture Rollout and recovery: Expose reports before correction actions; disable report generation when snapshot authority cannot be established. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-108 — Apply an approved reconciliation plan only if stock is unchanged **Story · High priority · Expert** noCV practice brief v5 · SYNC-108 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-106, SYNC-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Database engineering 40% · 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. An operator reviews a drift report, but a fresh vendor event arrives before Apply. Bind corrections to the reviewed before-state so approval cannot overwrite a newer update. Acceptance criteria - A plan records each item before revision, proposed quantity, source snapshot, and a canonical plan digest. - Application verifies permission, plan digest, and every current before revision in one transaction. - Any stale item blocks the plan with a conflict; approved applications record an append-only actor audit. Implementation constraints - Choose all-or-nothing application for this bounded exercise. - Recovery creates a new reviewed plan; it does not rewrite the old approval. Verification - Apply an unchanged plan and verify exact proposed quantities and one audit record. - Advance one item revision before apply and confirm no item in the plan changes. Deliverables - Reviewable correction plan and stale-approval tests Rollout and recovery: Allow only explicitly authorized operators to apply plans; keep a read-only report mode available if conflicts spike. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-109 — Surface a stale connector without logging vendor payloads **Task · Medium priority · Intermediate** noCV practice brief v5 · SYNC-109 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-105. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Integrations 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 connector has not completed a refresh for six hours, yet its status is green because the last HTTP request succeeded. Define freshness from completed ingestion checkpoints. Acceptance criteria - Status exposes last complete snapshot, latest accepted event, current attempt, and safe failure category separately. - A configured freshness threshold marks stale data without claiming the connector is healthy from HTTP success alone. - Metrics and logs exclude tokens, raw payloads, and customer-specific product descriptions. Implementation constraints - Use UTC and an injected clock for freshness. - Keep metrics cardinality bounded; item IDs belong in scoped diagnostics. Verification - Advance the clock past the threshold after a partial refresh and verify stale status. - Cause a vendor error containing a token marker and confirm it is absent from all normal diagnostics. Deliverables - Connector health projection and safe diagnostic tests Rollout and recovery: Publish status before enabling notifications; reset health only after a complete qualifying ingestion checkpoint. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-110 — Rehearse recovery from a vendor schema change **Task · High priority · Advanced** noCV practice brief v5 · SYNC-110 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-108, SYNC-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Quality engineering 20% · 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. The vendor replaces quantity with availableQuantity in its next API version. Demonstrate that the connector fails visibly, can resume with a new adapter, and preserves the old run history. Acceptance criteria - Unexpected required-field changes stop affected ingestion without defaulting stock values. - A versioned adapter can be selected per connector after contract fixtures pass. - Recovery resumes from a compatible checkpoint or starts a new snapshot with an explicit reason. Implementation constraints - Keep both schema fixtures local and versioned. - Do not reinterpret an old cursor under an incompatible API version. Verification - Switch the simulator schema mid-run and confirm no corrupt stock or silent success. - Upgrade the adapter, reconcile a complete new snapshot, and reproduce the documented recovery path. Deliverables - Schema-change contract cases and connector recovery runbook Rollout and recovery: Canary the new adapter on one synthetic connector; revert adapter selection and pause writes if contract errors recur. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. ## CAL — A booking connector that respects calendar reality A fictional consultancy books appointments across time zones. The first connector duplicates events after timeouts and offers slots during stale calendar sync. Use a local calendar-provider double and synthetic calendars. **Field:** Integrations. **Suggested stack:** TypeScript, PostgreSQL, HTTP, IANA time zones. **Engineer value:** Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. **Company value:** Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. **Delivery agreement:** A local booking connector with deterministic provider scenarios and an operations guide. ### Setup prerequisites - Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. - Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. ### Represent time and availability Offer only valid, explainable slots from fresh calendar data. #### CAL-101 — Reject local times that do not identify one instant **Task · High priority · Intermediate** noCV practice brief v5 · CAL-101 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Backend 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 booking form submits 01:30 on a daylight-saving fallback day without an offset. Store an instant plus display zone and explicitly handle ambiguous or nonexistent local times. Acceptance criteria - Bookings store UTC start/end instants and an IANA display-zone identifier. - Nonexistent local times are rejected with a selectable valid alternative. - Ambiguous local times require an explicit offset or occurrence choice and preserve that choice. Implementation constraints - Use established time-zone APIs or libraries; do not hard-code seasonal offsets. Verification - Test a normal date and both sides of a known spring gap and autumn overlap in a fixture zone. - Submit an unknown zone and an end before start and verify validation errors without provider calls. Deliverables - Booking time contract and daylight-saving boundary cases Rollout and recovery: Validate time inputs before availability or event creation; keep existing stored instants unchanged during migration. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-102 — Merge overlapping busy intervals before offering slots **Task · Medium priority · Foundational** noCV practice brief v5 · CAL-102 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: CAL-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Integrations 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. Two overlapping provider events produce a false free gap between them. Normalize busy intervals and apply the agreed booking duration and buffer. Acceptance criteria - Overlapping and adjacent intervals merge according to documented half-open boundaries. - Offered slots fit completely within working hours after pre/post buffers are applied. - Zero-length or reversed provider intervals are rejected as malformed input. Implementation constraints - Keep interval calculations in UTC; convert working-hour boundaries from the declared zone. Verification - Merge 09:00-10:00 and 09:30-10:30 and confirm no slot appears at 10:00. - Test a slot ending exactly at closing time with and without a post-booking buffer. Deliverables - Interval normalizer and slot boundary examples Rollout and recovery: Compare new slot output with fixture expectations in preview mode before exposing booking actions. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-103 — Label unavailable or stale free/busy data instead of showing open slots **Bug · High priority · Intermediate** noCV practice brief v5 · CAL-103 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: CAL-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. A free/busy request times out and the connector treats an empty response as an empty calendar. Distinguish confirmed free time from unknown availability. Acceptance criteria - Availability responses include fetched-at time, freshness state, and provider outcome. - A timeout, malformed response, or expired cache produces unknown availability and no bookable slots. - Fresh empty busy data can produce slots and remains distinguishable from failure. Implementation constraints - Use a configurable freshness limit and injected clock. Verification - Return fresh empty data and verify valid working-hour slots. - Return timeout and separately age cached data beyond the limit; neither may expose bookable slots. Deliverables - Availability state model and stale-data tests Rollout and recovery: Enable fail-closed availability before adding booking creation; users receive a retry state while provider data is unknown. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. ### Create and change bookings safely Handle concurrency, retries, and external side effects explicitly. #### CAL-104 — Reserve a slot atomically when two customers choose it **Story · High priority · Expert** noCV practice brief v5 · CAL-104 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-103. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Integrations 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. Two clients load the same available slot and submit together. Add an internal reservation transaction and a final provider availability check before creating an event. Acceptance criteria - Overlapping active reservations for one resource are prevented by a database-backed invariant. - Only the winning reservation can enqueue event creation through a transactional outbox. - The product distinguishes internal reservation guarantees from provider-side races when the provider lacks atomic hold support. Implementation constraints - Use a barrier-controlled race with two synthetic customers. - If the provider cannot guarantee exclusive booking, record the residual conflict state and provide reconciliation. Verification - Submit two overlapping reservations concurrently and assert one winner and one outbox event. - Introduce an external busy event after the first check and verify the booking is rejected or explicitly reconciled under the declared provider contract. Deliverables - Reservation constraint, outbox flow, and provider-race analysis Rollout and recovery: Activate one resource at a time with explicit provider guarantees; pause creation if unresolved conflicts accumulate. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-105 — Reconcile a create-event timeout before trying again **Bug · High priority · Advanced** noCV practice brief v5 · CAL-105 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Distributed systems 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 calendar provider creates the appointment but drops its response. Retrying with a new request identifier currently creates a second event. Preserve creation identity and reconcile uncertainty. Acceptance criteria - Each booking has a stable provider request identity persisted before the first call. - A lost response triggers lookup by that identity or an explicit uncertain state when lookup is unsupported. - A matching existing event is linked once; conflicting details block automatic completion. Implementation constraints - Use the local double to model accepted-then-timeout. - Do not claim exactly-once provider behavior without the required idempotency contract. Verification - Lose the first create response and assert one provider event after reconciliation. - Return an event with the same identity but different times and confirm the booking enters conflict without another create. Deliverables - Idempotent creation adapter and uncertain-outcome tests Rollout and recovery: Require reconciliation support before enabling retries; unsupported providers remain in manual resolution on ambiguous outcomes. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-106 — Move a booking only if its current revision still matches **Story · High priority · Advanced** noCV practice brief v5 · CAL-106 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-105. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 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. An agent reschedules a booking from an old browser tab after a colleague already moved it. Add revision-aware rescheduling and retain the original slot until the new operation is settled. Acceptance criteria - Reschedule requests include the expected booking revision and are rejected when stale. - The proposed new slot passes reservation and availability checks before the provider update. - Provider failure or uncertainty leaves a documented pending/conflict state and does not silently mark both slots free. Implementation constraints - Use provider conditional updates when the adapter supports them. - Record before and proposed intervals in an append-only operation record. Verification - Reschedule an unchanged booking and verify one final interval and incremented revision. - Race two reschedules and simulate a provider timeout; verify explicit conflicts and no duplicate successful move. Deliverables - Rescheduling state transitions and race/failure cases Rollout and recovery: Enable rescheduling after create reconciliation is stable; fall back to operator resolution for uncertain provider updates. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. ### Recover provider and account changes Manage updates, cancellation, expiry, and reconnect without duplicates. #### CAL-107 — Make repeated cancellation safe and tenant scoped **Story · High priority · Intermediate** noCV practice brief v5 · CAL-107 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-105. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Security 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. A client double-clicks Cancel while a support agent cancels from another screen. The connector must converge on one cancellation without allowing another tenant to cancel by event ID. Acceptance criteria - Cancellation resolves the booking through tenant and actor authorization before accessing provider IDs. - Repeated authorized cancellation converges on the same terminal result. - Provider not-found is accepted only after verifying the expected booking/provider mapping, and other provider errors remain visible. Implementation constraints - Keep provider event IDs out of caller-controlled authority decisions. Verification - Send concurrent cancellation requests and assert one logical cancellation history. - Attempt cancellation from another tenant and verify no provider request is made. Deliverables - Scoped cancellation service and idempotency/access tests Rollout and recovery: Expose cancellation with retry-safe state transitions; retain pending cancellation during provider outages rather than claiming success. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-108 — Refresh expired connector credentials once per account **Bug · High priority · Expert** noCV practice brief v5 · CAL-108 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-105. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 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. Ten jobs receive token-expired at once, all refresh, and a rotated token is overwritten by an older response. Serialize refresh by connector identity and persist credential revisions safely. Acceptance criteria - Concurrent expiry responses share one refresh operation per connector account. - Credential writes use version checks so an older refresh cannot overwrite a newer rotation. - A revoked grant stops new provider mutations, records reconnect-required, and never logs credential values. Implementation constraints - Use synthetic opaque tokens and a local token endpoint double. - Store credentials through a secret-store interface; do not hard-code a production key. Verification - Expire a token under ten concurrent calls and assert one refresh with successful versioned reuse. - Return refresh responses out of order and a revoked grant; verify no stale overwrite and no further mutations. Deliverables - Credential lifecycle port and refresh-race tests Rollout and recovery: Canary the new refresh path on a synthetic connector; force reconnect when credential authority is ambiguous. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-109 — Ignore duplicate calendar notifications and detect missed updates **Story · High priority · Advanced** noCV practice brief v5 · CAL-109 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-106, CAL-107, CAL-108. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Distributed systems 30% · Security 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. Provider notifications arrive twice, then a subscription expires and updates stop. Treat notifications as sync hints and maintain a separate reconciliation cursor and subscription deadline. Acceptance criteria - Authenticated duplicate notifications schedule at most one active sync for the connector. - Sync advances its provider cursor only with committed local changes. - Expired subscriptions or invalid cursors trigger an explicit refresh/reconnect path and mark availability stale. Implementation constraints - Validate the local notification authentication contract before trusting connector metadata. - Do not use notification arrival order as event revision order. Verification - Send duplicate and invalid-auth notifications and count scheduled jobs. - Expire a subscription and invalidate a cursor; confirm availability becomes unbookable until a successful resync. Deliverables - Notification ingestion, sync checkpointing, and expiry scenarios Rollout and recovery: Enable notification ingestion alongside periodic reconciliation; pause booking when either path cannot establish fresh availability. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. #### CAL-110 — Show operators which bookings need recovery after reconnect **Task · Medium priority · Foundational** noCV practice brief v5 · CAL-110 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 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. After reconnecting an account, operations cannot tell which bookings were created, moved, or cancelled during the outage. Build a scoped recovery list with safe identifiers and next actions. Acceptance criteria - The list separates pending creation, uncertain update, pending cancellation, and resolved operations. - Each row includes safe booking reference, last attempt time, failure category, and permitted recovery action. - Reading the list never sends invitations, creates events, or retries an operation implicitly. Implementation constraints - Omit attendee contact details from generic diagnostics. - Actions invoke the existing authorized lifecycle methods. Verification - Populate one operation in each state and verify labels and action availability. - Open the list as an unauthorized tenant and confirm denial with zero provider activity. Deliverables - Recovery list projection and reconnect operator guide Rollout and recovery: Release read-only recovery visibility first; activate explicit retry actions only through the already verified state transitions. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. 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. ## ADRIFT — Make subscription entitlements survive plan changes A fictional document service grants storage and collaboration rights from subscriptions. Support cannot explain why delayed events restore old limits. **Field:** Backend. **Suggested stack:** TypeScript, NestJS, PostgreSQL. **Engineer value:** Practice temporal rules, concurrency and explainable API decisions. **Company value:** Review whether entitlement changes preserve customer access and produce supportable decisions. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local subscription API with synthetic accounts. - Understand transactions and UTC intervals. ### Define effective rights Specify entitlement periods and failure responses. #### ADRIFT-101 — Specify the entitlement response at an exact effective instant **Task · Medium priority · Foundational** noCV practice brief v5 · ADRIFT-101 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define effective rights. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Backend 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. Support compares screenshots from two time zones and cannot tell which storage limit applied when an upload failed. Acceptance criteria - Return limit, effective UTC instant and plan revision. - Document inclusive start and exclusive end boundaries. - Reject an invalid timestamp without resolving rights. Implementation constraints - Use synthetic plan names and integer byte limits. Verification - Resolve immediately before and at a plan boundary. - Reject a timestamp without an offset and verify no write. Deliverables - Versioned response contract and boundary fixtures Rollout and recovery: Introduce the versioned read route; remove routing if consumers reject it. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-102 — Keep manual account restrictions separate from plan allowances **Story · Medium priority · Intermediate** noCV practice brief v5 · ADRIFT-102 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define effective rights. Depends on: ADRIFT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 70% · Security 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 support restriction disappears when an account upgrades because both settings currently share one mutable limit. Acceptance criteria - Store restriction and plan allowance with separate provenance. - Return the effective minimum with both reasons. - Removing a restriction restores the current plan allowance. Implementation constraints - Restrict mutation to an authorized support role. Verification - Upgrade a restricted account and retain its lower limit. - Attempt a restriction change as a normal member and deny it. Deliverables - Restriction command and permission tests Rollout and recovery: Enable for synthetic accounts; disable mutation while retaining restriction history. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-103 — Reject negative and fractional seat allowances consistently **Bug · Medium priority · Foundational** noCV practice brief v5 · ADRIFT-103 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define effective rights. Depends on: ADRIFT-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. An administrative import accepts 2.5 seats, while the runtime truncates the value differently from the billing preview. Acceptance criteria - Accept only nonnegative safe integers for seat limits. - Use one validation rule for import and API commands. - Return the offending field without echoing the entire import. Implementation constraints - Represent unlimited explicitly rather than with negative sentinels. Verification - Create zero-seat and unlimited synthetic plans. - Reject fractional, negative and unsafe integer limits. Deliverables - Shared seat schema and import regression Rollout and recovery: Deploy validation before new imports; quarantine rejected rows for correction. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. ### Apply changes safely Preserve ordering and concurrent update invariants. #### ADRIFT-104 — Apply a scheduled downgrade only after its stored effective time **Story · High priority · Intermediate** noCV practice brief v5 · ADRIFT-104 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply changes safely. Depends on: ADRIFT-101, ADRIFT-103. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 80% · 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. A worker runs the next day's downgrade early when a retry executes against the server's local calendar date. Acceptance criteria - Compare a persisted UTC instant with an injected clock. - Early delivery leaves the schedule pending. - Repeated eligible delivery creates one entitlement revision. Implementation constraints - Persist the revision and dispatch record in one transaction. Verification - Advance a fake clock through the exact effective instant. - Deliver early and twice after the boundary; count one revision. Deliverables - Scheduled transition and deterministic-clock tests Rollout and recovery: Canary scheduled changes; pause the consumer and retain pending schedules on failure. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-105 — Prevent a late upgrade event from undoing a newer cancellation **Bug · High priority · Advanced** noCV practice brief v5 · ADRIFT-105 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply changes safely. Depends on: ADRIFT-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Distributed systems 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. Provider events arrive out of order and an old upgrade reopens collaboration after cancellation became effective. Acceptance criteria - Compare provider sequence within each subscription. - Older events remain recorded without changing effective rights. - Equal sequence with different payload is surfaced as conflict. Implementation constraints - Do not order provider events by receipt timestamp. Verification - Replay cancellation followed by an older upgrade. - Submit contradictory equal-sequence events and preserve current rights. Deliverables - Ordering guard and conflicting-event report Rollout and recovery: Run the guard in audit mode first; quarantine conflicts without deleting events. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-106 — Make plan switching and seat allocation share one consistency boundary **Task · High priority · Expert** noCV practice brief v5 · ADRIFT-106 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply changes safely. Depends on: ADRIFT-102, ADRIFT-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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 downgrade races a seat invitation; both requests pass their reads and leave more active seats than permitted. Acceptance criteria - Serialize competing allowance and allocation changes per account. - One conflicting request returns a retryable conflict. - A failed transaction leaves both seat count and rights unchanged. Implementation constraints - Document the invariant and chosen locking order. Verification - Run a two-client barrier test for downgrade versus invitation. - Force transaction rollback and check both tables retain prior values. Deliverables - Transactional guard and concurrency reproduction Rollout and recovery: Introduce with lock-wait monitoring; revert command routing if contention exceeds the documented local budget. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-107 — Preview entitlement changes without creating pending work **Story · Medium priority · Intermediate** noCV practice brief v5 · ADRIFT-107 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply changes safely. Depends on: ADRIFT-104, ADRIFT-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Sales wants to preview next month's downgrade, but the current preview endpoint creates a schedule visible to the worker. Acceptance criteria - Preview uses the same pure decision function as execution. - Return affected features and effective-time assumptions. - No schedule, outbox or audit mutation occurs on preview. Implementation constraints - Authorize account reads before computing the preview. Verification - Compare preview with a later applied synthetic change. - Repeat preview and assert unchanged row counts; deny another account. Deliverables - Pure preview operation and nonmutation checks Rollout and recovery: Expose preview behind a route flag; remove the route without touching schedules. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. ### Explain and recover Expose effective decisions and recover delayed changes. #### ADRIFT-108 — Explain a denied upload using the exact entitlement revision **Story · Medium priority · Advanced** noCV practice brief v5 · ADRIFT-108 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain and recover. Depends on: ADRIFT-105, ADRIFT-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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 upload rejection says only limit exceeded, so support cannot connect it to the plan and restriction that were evaluated. Acceptance criteria - Return a stable denial code and evaluated revision ID. - Include byte limit and current usage without other accounts' data. - Keep historical revisions immutable for later explanation. Implementation constraints - Avoid storing document contents in decision logs. Verification - Reproduce a denial and resolve the same historical decision after upgrade. - Request another account's decision ID and return a nondisclosing denial. Deliverables - Decision projection and scoped history route Rollout and recovery: Enable explanation reads first; disable projection if privacy checks fail. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-109 — Rebuild an account entitlement projection from its ordered history **Chore · Medium priority · Expert** noCV practice brief v5 · ADRIFT-109 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain and recover. Depends on: ADRIFT-105, ADRIFT-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Backend 30% · Database 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 projection bug affected a synthetic account; operators need to repair derived rights without rewriting the source change history. Acceptance criteria - Rebuild into a separate generation using deterministic ordering. - Compare differences before atomically selecting the generation. - Interrupted rebuild leaves the active projection usable. Implementation constraints - Require an account scope and dry-run mode. Verification - Compare a rebuilt generation with a clean reference history. - Interrupt before activation and prove the old generation still resolves. Deliverables - Scoped rebuild command and difference report Rollout and recovery: Dry-run one synthetic account; restore the previous generation pointer on mismatch. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. #### ADRIFT-110 — Document the handoff for disputed effective entitlements **Task · Low priority · Foundational** noCV practice brief v5 · ADRIFT-110 · Make subscription entitlements survive plan changes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain and recover. Depends on: ADRIFT-108, ADRIFT-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Support needs a repeatable path to investigate a rights dispute without editing rows directly or promising the wrong allowance. Acceptance criteria - Runbook starts from account, decision and revision identifiers. - Separate delayed-provider, restriction and usage causes. - Include escalation and projection rollback steps. Implementation constraints - Use fabricated examples and avoid raw customer identifiers. Verification - Follow the runbook for a scheduled downgrade dispute. - Follow the missing-history branch and confirm it stops before mutation. Deliverables - Support runbook and two worked synthetic incidents Rollout and recovery: Review the runbook with a fresh local reproduction; version corrections alongside the projection. Project prerequisites: Create a local subscription API with synthetic accounts. Understand transactions and UTC intervals. Engineer value: Practice temporal rules, concurrency and explainable API decisions. Company value: Review whether entitlement changes preserve customer access and produce supportable decisions. 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. ## ABOOK — Repair appointment holds and cancellation windows A fictional equipment service books maintenance visits. Expiring checkout holds and reschedules occasionally double-book a technician. **Field:** Backend. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice resource allocation, interval conflicts and durable workflows. **Company value:** Review scheduling correctness and recovery before exposing scarce capacity. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Build synthetic technicians, slots and booking records. - Use an injectable clock and separate clients for concurrency probes. ### Define availability Make time and availability rules unambiguous. #### ABOOK-101 — Normalize maintenance-slot requests to explicit UTC intervals **Task · Medium priority · Foundational** noCV practice brief v5 · ABOOK-101 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. A technician's daylight-saving transition produces two appointments labelled 01:30 with no offset in the booking request. Acceptance criteria - Require start, end and explicit offset. - Reject end-before-start and zero-duration intervals. - Persist UTC while returning the requested display zone separately. Implementation constraints - Create synthetic ambiguous-hour cases rather than reading real calendars. Verification - Round-trip two different offsets for the repeated hour. - Reject an offset-free repeated-hour request. Deliverables - Slot input contract and DST cases Rollout and recovery: Add validation before new slot creation; retain original timestamps for existing rows. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-102 — Model overlapping technician availability as half-open intervals **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOOK-102 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: ABOOK-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database 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. Adjacent visits are rejected as overlapping, while a visit completely containing another can pass a naive endpoint check. Acceptance criteria - Adjacent end and start boundaries do not conflict. - Contained and partially overlapping intervals conflict. - Conflict checks include the technician's organization. Implementation constraints - Document the half-open interval convention in the query. Verification - Check adjacent, contained and identical intervals. - Try the same technician identifier in another organization and deny access. Deliverables - Overlap query and interval matrix Rollout and recovery: Shadow-check overlap decisions; restore the old route if new conflicts need review. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-103 — Return bookable slots in stable bounded pages **Story · Medium priority · Foundational** noCV practice brief v5 · ABOOK-103 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define availability. Depends on: ABOOK-101, ABOOK-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Backend 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 busy service desk loads every future slot; several slots disappear from the second page when a new slot is inserted. Acceptance criteria - Order by start instant and opaque slot ID. - Use a cursor bound to technician and date window. - Enforce a maximum page size and bounded date range. Implementation constraints - Do not expose unassigned technicians outside the organization. Verification - Insert a slot between pages and inspect stable cursor progression. - Reject an altered cursor scope and excessive range. Deliverables - Availability page contract and cursor tests Rollout and recovery: Introduce cursor pagination alongside the old bounded endpoint; roll back its link. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. ### Protect reservations Handle simultaneous actions and durable transitions. #### ABOOK-104 — Reserve one active hold for a contested maintenance slot **Story · High priority · Advanced** noCV practice brief v5 · ABOOK-104 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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. Two customers reach checkout together and each receives a valid hold token for the same appointment. Acceptance criteria - One active hold wins for a slot under concurrent requests. - The loser gets a conflict without another customer's details. - Hold creation and its expiry time commit atomically. Implementation constraints - Use a database invariant as the final concurrency guard. Verification - Start two clients at a barrier and assert one live hold. - Force commit failure and assert no usable token escapes. Deliverables - Hold command and concurrent reservation test Rollout and recovery: Enable holds on synthetic slots; pause new holds if invariant monitoring detects duplicates. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-105 — Expire holds without cancelling a booking confirmed at the boundary **Bug · High priority · Expert** noCV practice brief v5 · ABOOK-105 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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. An expiry worker reads an old hold while checkout confirms it; the worker then frees a slot already sold. Acceptance criteria - Confirm and expire use guarded state transitions. - Exactly one terminal outcome wins at the expiry boundary. - A stale expiry job cannot alter a confirmed booking. Implementation constraints - Specify whether confirmation at the exact deadline is rejected. Verification - Race confirmation and expiry with a controlled clock. - Retry the stale expiry after confirmation and retain the booking. Deliverables - Hold state machine and boundary race reproduction Rollout and recovery: Canary the guarded worker; stop expiry consumption while preserving stored deadlines. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-106 — Reschedule a visit without releasing its old slot prematurely **Story · Medium priority · Advanced** noCV practice brief v5 · ABOOK-106 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-104, ABOOK-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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 reschedule releases the old appointment before reserving the new one, leaving customers unbooked if the target is taken. Acceptance criteria - Reserve the target and release the source atomically. - Retain the original appointment on target conflict. - A retried successful command returns the same replacement. Implementation constraints - Keep both slot locks in a documented stable order. Verification - Move a visit and inspect one confirmed appointment. - Race for the target and verify the losing reschedule keeps its source. Deliverables - Reschedule command and transaction tests Rollout and recovery: Enable for synthetic bookings; disable rescheduling while ordinary reads continue. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-107 — Calculate the cancellation window from the booked service policy **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOOK-107 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect reservations. Depends on: ABOOK-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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 policy update changes the cancellation deadline for appointments sold under yesterday's terms. Acceptance criteria - Booking retains the applied policy version. - Deadline calculation uses that frozen policy and UTC start. - Cancellation returns the policy version and eligibility reason. Implementation constraints - This exercise models eligibility only, without charging money. Verification - Cancel bookings created under two policy versions. - Change the current policy and verify old booking deadlines remain fixed. Deliverables - Versioned cancellation calculator Rollout and recovery: Publish a new policy version for new bookings; keep historical policy references intact. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. ### Operate the calendar Reconcile state and explain cancellations. #### ABOOK-108 — Detect orphan holds without changing confirmed appointments **Chore · Medium priority · Advanced** noCV practice brief v5 · ABOOK-108 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-105, ABOOK-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database 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 simulated outage leaves holds whose expiry jobs were never dispatched; operations needs a bounded reconciliation command. Acceptance criteria - Scan expired held rows with cursor checkpoints. - Release only rows still held at the checked version. - Report confirmed rows skipped after concurrent change. Implementation constraints - Use dry-run by default and limit each batch. Verification - Reconcile an expired orphan and resume from a checkpoint. - Confirm between scan and update and verify the booking survives. Deliverables - Orphan-hold reconciler and race check Rollout and recovery: Dry-run a bounded window; stop reconciliation and retain checkpoints if unexpected skips grow. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-109 — Hide customer details in scheduling conflict responses **Bug · High priority · Foundational** noCV practice brief v5 · ABOOK-109 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-106, ABOOK-107. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Backend 30% · 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. A failed reschedule currently returns the target booking object, exposing the name and contact information of its owner. Acceptance criteria - Conflict responses contain only code and requested slot identity. - Internal logs omit customer contact fields. - Successful owners still receive their own booking projection. Implementation constraints - Use explicit response schemas instead of deleting selected fields. Verification - Check an owner's successful reschedule response. - Force a conflict and assert another customer's fields appear nowhere in response or log. Deliverables - Sanitized conflict schema and disclosure regression Rollout and recovery: Deploy response shaping first; revert only with the same restricted projection. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. #### ABOOK-110 — Prove booking recovery after a lost confirmation response **Task · High priority · Expert** noCV practice brief v5 · ABOOK-110 · Repair appointment holds and cancellation windows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate the calendar. Depends on: ABOOK-105, ABOOK-108, ABOOK-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Backend 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. Checkout commits successfully, then the connection closes. A customer retries while the expiry worker is also running. Acceptance criteria - Document persisted state at each interruption point. - A stable command key resolves the committed confirmation. - No retry creates a second booking or frees its slot. Implementation constraints - Build a deterministic fault-injection harness using synthetic visits. Verification - Drop the response after commit and retry to the same booking. - Drop before commit, run expiry, and verify the declared expired outcome. Deliverables - Recovery trace and executable interruption probe Rollout and recovery: Run the drill before enabling checkout; fall back to read-only booking lookup during incidents. Project prerequisites: Build synthetic technicians, slots and booking records. Use an injectable clock and separate clients for concurrency probes. Engineer value: Practice resource allocation, interval conflicts and durable workflows. Company value: Review scheduling correctness and recovery before exposing scarce capacity. 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. ## ARULE — Ship a reviewable pricing-rule service A fictional parts supplier combines contract prices with promotions. Sales needs repeatable quotes when rules change during checkout. **Field:** Backend. **Suggested stack:** TypeScript, PostgreSQL, JSON Schema. **Engineer value:** Practice deterministic rule evaluation, revision control and bounded execution. **Company value:** Review explainable commercial rules without trusting opaque price changes. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic products and integer minor-unit prices. - Implement a small local quote API. ### Constrain rule input Define a safe, deterministic rule language. #### ARULE-101 — Define the supported promotion predicates without executable expressions **Task · Medium priority · Foundational** noCV practice brief v5 · ARULE-101 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain rule input. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · API design 20% · 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. Sales requested a formula textbox; evaluating arbitrary expressions would make quote behavior difficult to bound and audit. Acceptance criteria - Allow explicit product, quantity and date predicates. - Reject unknown operators and excessive nesting. - Publish a schema with accepted and rejected examples. Implementation constraints - Treat rule documents as data; never evaluate source strings. Verification - Parse a quantity-band promotion. - Reject a function expression and a nesting-limit violation. Deliverables - Promotion schema and parser cases Rollout and recovery: Accept drafts only initially; disable new drafts if parser compatibility fails. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-102 — Resolve overlapping promotions with an explicit tie-break policy **Task · Medium priority · Intermediate** noCV practice brief v5 · ARULE-102 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain rule input. Depends on: ARULE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Two promotions match the same part and the chosen discount depends on database return order. Acceptance criteria - Define priority and stable-ID tie breaking. - Return the winning rule and losing-match reasons. - Evaluation is independent of input array order. Implementation constraints - Use integer arithmetic and a documented rounding boundary. Verification - Shuffle matching rules and retain the same price. - Exercise equal priorities and invalid discount bounds. Deliverables - Deterministic resolver and ordering tests Rollout and recovery: Compare decisions on synthetic quotes; retain the previous resolver version for rollback. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-103 — Validate promotion date ranges before publishing drafts **Bug · Medium priority · Foundational** noCV practice brief v5 · ARULE-103 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain rule input. Depends on: ARULE-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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 promotion with its end before its start passes draft review and can never apply. Acceptance criteria - Require offset-bearing UTC-normalizable dates. - Reject empty and reversed ranges at publication. - Display validation paths without raw rule documents in logs. Implementation constraints - Use half-open intervals consistently. Verification - Publish an adjacent pair of valid promotions. - Reject reversed, missing-offset and empty intervals. Deliverables - Publication date guard Rollout and recovery: Deploy guard for unpublished drafts; preserve existing published versions. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. ### Apply frozen rules Make quote decisions consistent and auditable. #### ARULE-104 — Freeze product and rule versions when a quote is accepted **Story · High priority · Advanced** noCV practice brief v5 · ARULE-104 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply frozen rules. Depends on: ARULE-102, ARULE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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 buyer accepts a quote after a promotion edit and receives a different total from the amount previously displayed. Acceptance criteria - Accepted quotes retain product and rule version identities. - Acceptance checks expiry and expected quote revision. - Retries resolve one accepted quote with an unchanged total. Implementation constraints - Store a canonical calculation input hash with the quote. Verification - Accept a quote after changing current rules and retain its frozen total. - Attempt acceptance after expiry and create no order. Deliverables - Quote acceptance command and frozen-input checks Rollout and recovery: Enable acceptance for synthetic accounts; suspend new acceptance while preserving accepted records. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-105 — Bound pricing work for a cart with many matching rules **Task · Medium priority · Expert** noCV practice brief v5 · ARULE-105 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply frozen rules. Depends on: ARULE-102. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Backend 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 unusually broad rule set makes checkout evaluate thousands of predicates per item and blocks unrelated quotes. Acceptance criteria - Set explicit cart, rule-count and predicate-work limits. - Reject over-budget requests before partial quote publication. - Return a bounded-work error distinct from invalid pricing. Implementation constraints - Choose limits from a repeatable local synthetic workload and document conditions. Verification - Measure work counters for 100 items and 200 rules. - Exceed each limit and verify no accepted quote is created. Deliverables - Evaluation budget and reproducible workload Rollout and recovery: Canary limits in observation mode; lower admitted work or restore prior limits on regressions. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-106 — Keep negotiated account prices outside shared quote caches **Bug · High priority · Advanced** noCV practice brief v5 · ARULE-106 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply frozen rules. Depends on: ARULE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Backend 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 shared cache returns one customer's negotiated rate to another account requesting the same product list. Acceptance criteria - Bind cache identity to organization, account and frozen price version. - Authorize before cache lookup. - Never cache an authorization failure as a valid quote. Implementation constraints - Include all price-affecting inputs in canonical cache keys. Verification - Quote identical carts for two negotiated-price accounts. - Attempt cross-account access and inspect cache hits and response fields. Deliverables - Scoped cache key and isolation regression Rollout and recovery: Invalidate the affected namespace before enabling the new key format. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-107 — Report why a cart missed a promotion without leaking contract terms **Story · Medium priority · Intermediate** noCV practice brief v5 · ARULE-107 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply frozen rules. Depends on: ARULE-102, ARULE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Backend 30% · 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. Sales wants to explain an unmet minimum quantity, but the current debug endpoint exposes every account's price rules. Acceptance criteria - Explain only rules visible to the requesting account. - Show failed predicate names with permitted thresholds. - Omit internal contract identifiers and unrelated rule matches. Implementation constraints - Build a dedicated explanation projection. Verification - Explain a visible minimum-quantity miss. - Request explanation for an inaccessible contract and receive no rule details. Deliverables - Scoped pricing explanation endpoint Rollout and recovery: Enable the projection for one synthetic sales role; disable debug routes on disclosure failure. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. ### Release rule versions Compare revisions and recover rejected releases. #### ARULE-108 — Compare a draft pricing revision against a named quote corpus **Chore · Medium priority · Intermediate** noCV practice brief v5 · ARULE-108 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release rule versions. Depends on: ARULE-104, ARULE-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Backend 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. A promotion revision fixes bulk orders but may unintentionally discount small carts. Acceptance criteria - Create and version a synthetic quote corpus. - Report old and new totals plus changed rule identities. - Flag unexplained differences before publication. Implementation constraints - The corpus is authored for this exercise; do not claim production coverage. Verification - Include bulk, small-cart and no-match examples. - Insert an invalid draft and report validation failure instead of a comparison. Deliverables - Revision comparison command and synthetic corpus Rollout and recovery: Require comparison review for draft publication; preserve earlier reports. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-109 — Publish a pricing revision with optimistic review protection **Story · High priority · Advanced** noCV practice brief v5 · ARULE-109 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release rule versions. Depends on: ARULE-103, ARULE-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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 reviewer approves a draft while an editor changes its discount; publication currently activates content nobody reviewed. Acceptance criteria - Approval binds the exact canonical draft hash. - Publication rejects a changed draft or stale expected revision. - Published rule content cannot be updated in place. Implementation constraints - Commit active-pointer selection and audit metadata together. Verification - Publish an unchanged approved draft. - Edit between approval and publish and retain the previous active revision. Deliverables - Guarded publication command Rollout and recovery: Publish to synthetic accounts first; restore the prior active pointer without rewriting versions. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. #### ARULE-110 — Replay a pricing dispute from immutable quote inputs **Task · Medium priority · Expert** noCV practice brief v5 · ARULE-110 · Ship a reviewable pricing-rule service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Release rule versions. Depends on: ARULE-104, ARULE-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 70% · Developer tooling 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 receives a disputed total after three rule releases and cannot reproduce which calculation the buyer accepted. Acceptance criteria - Replay selects the recorded evaluator and input versions. - Report missing versions as unreproducible rather than guessing. - Compare computed total and hash with the accepted record. Implementation constraints - Keep replay read-only and use fabricated customer data. Verification - Replay an accepted synthetic quote across later releases. - Remove an available version in the test double and assert explicit failure. Deliverables - Read-only dispute replay and failure cases Rollout and recovery: Expose replay to scoped support users; revoke access if provenance cannot be resolved. Project prerequisites: Create synthetic products and integer minor-unit prices. Implement a small local quote API. Engineer value: Practice deterministic rule evaluation, revision control and bounded execution. Company value: Review explainable commercial rules without trusting opaque price changes. 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. ## AINGEST — Recover a partner telemetry ingestion pipeline A fictional energy dashboard receives hourly device batches. Corrupt archives and late corrections leave operators unsure which readings reached reports. **Field:** Data engineering. **Suggested stack:** Python, PostgreSQL, Object storage. **Engineer value:** Practice batch integrity, replay and data-quality boundaries. **Company value:** Review whether operational data can be traced, corrected and recovered. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic device batches and local object-store fixtures. - Understand checksums and bounded streaming. ### Validate batch boundaries Reject unsafe or ambiguous inputs before loading. #### AINGEST-101 — Record a manifest before decoding a telemetry batch **Task · Medium priority · Foundational** noCV practice brief v5 · AINGEST-101 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Storage systems 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. Operators see a failed file name but cannot identify the original bytes or the parser version used. Acceptance criteria - Record object version, byte hash and declared format. - Bind each ingestion attempt to one manifest. - Reject a changed object version on retry. Implementation constraints - Use synthetic object metadata; avoid storing credentials in manifests. Verification - Retry unchanged bytes against the same manifest. - Replace bytes under the same object key and report identity mismatch. Deliverables - Manifest schema and identity checks Rollout and recovery: Start manifests for new batches; retain earlier records as explicitly untracked. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-102 — Cap decompressed telemetry bytes before archive expansion **Bug · High priority · Advanced** noCV practice brief v5 · AINGEST-102 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: AINGEST-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Performance engineering 30% · Security 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 tiny compressed batch expands far beyond the ingestion worker's memory budget. Acceptance criteria - Enforce compressed, expanded-byte and row limits. - Stop streaming as soon as a bound is crossed. - Quarantine with a reason without loading partial rows. Implementation constraints - Do not unpack paths or execute files from archives. Verification - Ingest a valid compressed synthetic batch. - Exercise excessive expansion and path-like entry names without writing outside staging. Deliverables - Bounded decoder and hostile archive fixtures Rollout and recovery: Enable bounded decoding before partner intake; keep rejected objects quarantined. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-103 — Normalize sensor units through a versioned conversion table **Task · Medium priority · Intermediate** noCV practice brief v5 · AINGEST-103 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: AINGEST-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. Two device models emit watt-hours and kilowatt-hours under the same field name. Acceptance criteria - Require a known unit and conversion version. - Preserve raw numeric value and declared unit in lineage. - Reject unsupported units and nonfinite measurements. Implementation constraints - Use decimal arithmetic for documented conversions. Verification - Convert synthetic Wh and kWh to equal canonical readings. - Reject missing units and nonfinite input. Deliverables - Unit conversion contract and cases Rollout and recovery: Publish conversion revisions for new runs; retain old mappings for replay. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. ### Load traceable records Preserve lineage and deterministic corrections. #### AINGEST-104 — Commit telemetry rows and the batch checkpoint atomically **Story · High priority · Advanced** noCV practice brief v5 · AINGEST-104 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-102, AINGEST-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Database 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. A process dies after inserting rows but before marking the file complete; replay doubles reported usage. Acceptance criteria - Persist rows and committed checkpoint in one transaction. - Use source reading identity to reject duplicate insertion. - Retries return committed counts without adding readings. Implementation constraints - Bound transaction size; larger batches require explicit sub-batch identities. Verification - Kill the test process at modeled commit boundaries. - Replay a completed sub-batch and compare row counts and totals. Deliverables - Atomic batch loader and crash probe Rollout and recovery: Canary small batches; pause loading and inspect manifests if reconciliation diverges. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-105 — Quarantine malformed readings with usable row coordinates **Story · Medium priority · Foundational** noCV practice brief v5 · AINGEST-105 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-102, AINGEST-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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 malformed timestamp makes the ingestion job fail with a stack trace and no indication of the source row. Acceptance criteria - Report manifest ID, row number and stable reason code. - Keep rejected values out of generic logs. - Publish accepted and rejected counts under the declared partial-load policy. Implementation constraints - Choose and document all-or-nothing versus row quarantine for this dataset. Verification - Load a batch containing valid rows under the chosen policy. - Insert malformed timestamps and verify coordinates and count invariants. Deliverables - Quarantine report and policy tests Rollout and recovery: Enable reports before changing load policy; replay corrected manifests as new attempts. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-106 — Apply corrected readings without overwriting source history **Story · Medium priority · Expert** noCV practice brief v5 · AINGEST-106 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-104, AINGEST-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. A device sends a corrected cumulative reading two days late; a blind upsert destroys the value used in yesterday's report. Acceptance criteria - Append corrections linked to source reading and revision. - Define the effective reading deterministically. - Reject contradictory equal-revision corrections for review. Implementation constraints - Preserve original ingestion time separately from measurement time. Verification - Apply a higher revision and inspect both historical values. - Submit equal revision with changed value and retain the last valid projection. Deliverables - Correction model and conflict cases Rollout and recovery: Enable corrections for one synthetic device; rebuild projections from retained history on rollback. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-107 — Use event-time watermarks without discarding late telemetry silently **Task · Medium priority · Advanced** noCV practice brief v5 · AINGEST-107 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Real-time 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 hourly aggregate closes by arrival time and quietly ignores a delayed batch from an offline device. Acceptance criteria - Define watermark advancement and allowed lateness. - Route late readings to a visible correction path. - Report aggregate revision when late data changes a result. Implementation constraints - Test with a controlled clock and explicit event timestamps. Verification - Deliver an in-window late reading and update the expected aggregate. - Deliver beyond the lateness window and verify visible deferred correction. Deliverables - Watermark logic and late-arrival fixtures Rollout and recovery: Run alongside the prior aggregate; switch readers only after discrepancy review. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. ### Recover ingestion gaps Reconcile committed batches and repair derived data. #### AINGEST-108 — Reconcile uploaded telemetry manifests against committed checkpoints **Chore · Medium priority · Intermediate** noCV practice brief v5 · AINGEST-108 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-104, AINGEST-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Storage systems 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. Object storage contains yesterday's batches, but dashboard totals are low and no worker currently owns the missing jobs. Acceptance criteria - List missing, pending and committed manifests by bounded window. - Schedule replay only for eligible uncommitted identities. - Make repeated reconciliation produce no duplicate committed data. Implementation constraints - Require explicit organization and time bounds. Verification - Find a synthetic uploaded batch without a checkpoint. - Rerun reconciliation after commit and schedule nothing additional. Deliverables - Manifest reconciler and bounded replay command Rollout and recovery: Dry-run first; stop replay dispatch while preserving the discrepancy report. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-109 — Verify a telemetry backfill against immutable aggregate snapshots **Task · Medium priority · Expert** noCV practice brief v5 · AINGEST-109 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-106, AINGEST-107, AINGEST-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · Database 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 conversion fix requires rebuilding a week of energy totals without obscuring what the previous dashboard showed. Acceptance criteria - Build a new aggregate generation from named manifests. - Compare counts, units and totals against frozen previous output. - Atomically select the generation only after review. Implementation constraints - Use a synthetic seven-day corpus with declared correction cases. Verification - Backfill the corpus and reconcile every changed aggregate. - Interrupt before activation and keep previous dashboard reads consistent. Deliverables - Backfill runner and generation difference report Rollout and recovery: Activate one synthetic tenant; restore the old generation pointer on discrepancy. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-110 — Add an ingestion freshness report that distinguishes missing data from zero **Task · Medium priority · Foundational** noCV practice brief v5 · AINGEST-110 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-108, AINGEST-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. A site with no recent readings is displayed as consuming zero energy, misleading dashboard consumers. Acceptance criteria - Show last event time and last committed arrival separately. - Represent missing intervals as unknown rather than numeric zero. - Define stale thresholds from a documented expected schedule. Implementation constraints - Do not claim zero consumption without a reading. Verification - Report a genuine zero reading as zero. - Remove a scheduled batch and show unknown with stale status. Deliverables - Freshness projection and missing-data cases Rollout and recovery: Introduce freshness beside existing totals; revert display wiring while preserving unknown semantics. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. ## ADBT — Make a subscription analytics mart reproducible A fictional SaaS analyst reports expansion revenue differently from finance because snapshots, refunds and contract changes are joined at incompatible grains. **Field:** Data engineering. **Suggested stack:** SQL, PostgreSQL, dbt. **Engineer value:** Practice analytical modeling and explainable transformation contracts. **Company value:** Review trustworthy reporting definitions and the cost of correcting historical reports. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a synthetic source schema and local transformation project. - Use integer minor units and distinct reporting currencies. ### Define reporting grain Specify source and metric contracts. #### ADBT-101 — Declare the subscription-movement grain before joining invoice lines **Task · Medium priority · Foundational** noCV practice brief v5 · ADBT-101 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define reporting grain. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. A report doubles subscription movement when a contract has two invoice lines in the same month. Acceptance criteria - Document one row per subscription, period and currency. - Identify source keys and permitted multiplicity. - Reject duplicate grain keys in a contract check. Implementation constraints - Create a small synthetic multi-line invoice example. Verification - Reconcile a two-line invoice to one movement row. - Insert duplicate source identity and fail the grain check. Deliverables - Grain specification and executable uniqueness check Rollout and recovery: Review the grain contract before enabling downstream joins. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-102 — Separate recurring contract value from collected cash **Story · Medium priority · Intermediate** noCV practice brief v5 · ADBT-102 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define reporting grain. Depends on: ADBT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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 late payment makes the recurring-revenue chart dip even though no subscription changed. Acceptance criteria - Define contract value and cash collection as separate measures. - Document refund and unpaid-invoice treatment. - Keep currency amounts separate without implicit conversion. Implementation constraints - Use named business definitions in model metadata. Verification - Delay a payment and keep contracted recurring value unchanged. - Mix currencies and reject an unsupported combined total. Deliverables - Metric definitions and contrasting examples Rollout and recovery: Publish separate metric names; retire ambiguous aliases after consumer review. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-103 — Reject source schema drift before materializing the mart **Chore · High priority · Foundational** noCV practice brief v5 · ADBT-103 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define reporting grain. Depends on: ADBT-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. A partner renamed subscription_id and the daily transformation published an empty table successfully. Acceptance criteria - Validate required columns and accepted types. - Fail before replacing the active reporting relation. - Report the missing contract field and source version. Implementation constraints - Avoid relying on a row-count check alone. Verification - Transform a valid empty source under its declared contract. - Rename a required column and retain the previous active mart. Deliverables - Source contract gate Rollout and recovery: Run the contract gate before scheduled builds; keep prior output on failure. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. ### Transform consistently Handle temporal joins and incremental updates. #### ADBT-104 — Join customer segments as of the revenue event date **Bug · Medium priority · Advanced** noCV practice brief v5 · ADBT-104 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Transform consistently. Depends on: ADBT-101, ADBT-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. Historical enterprise revenue changes whenever sales updates a customer's current segment. Acceptance criteria - Use valid-time segment intervals for the event date. - Detect overlapping or missing segment intervals explicitly. - Preserve the event's original reporting currency. Implementation constraints - Do not fill missing historical segments with the current value. Verification - Change today's segment and keep prior periods unchanged. - Create overlapping segment periods and fail the temporal join check. Deliverables - As-of join model and interval assertions Rollout and recovery: Build a comparison table; switch readers after historical differences are reviewed. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-105 — Make incremental movement loads include revised source rows **Story · Medium priority · Advanced** noCV practice brief v5 · ADBT-105 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Transform consistently. Depends on: ADBT-103, ADBT-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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 incremental model filters only creation time, so a corrected subscription end date never reaches the mart. Acceptance criteria - Track source revision or updated watermark with tie breaking. - Recompute affected grain keys deterministically. - Commit the output and checkpoint consistently. Implementation constraints - Document how deletions and corrections identify affected periods. Verification - Correct a prior end date and update the affected month. - Retry after an interrupted run and avoid duplicate movement rows. Deliverables - Revision-aware incremental model Rollout and recovery: Shadow full and incremental builds on a synthetic corpus; fall back to full rebuild if they diverge. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-106 — Represent cancelled subscriptions as movements instead of deleting them **Task · Medium priority · Intermediate** noCV practice brief v5 · ADBT-106 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Transform consistently. Depends on: ADBT-102, ADBT-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. Deleting a cancelled subscription from the source erases the churn event from the report. Acceptance criteria - Retain cancellation effective date and source tombstone lineage. - Emit one cancellation movement per effective revision. - Expose unavailable source history as incomplete reporting. Implementation constraints - Use synthetic deletion events rather than recovering private backups. Verification - Apply a cancellation tombstone and retain its churn movement. - Replay the tombstone and verify no double cancellation. Deliverables - Tombstone handling and movement fixtures Rollout and recovery: Enable tombstone capture before source deletion; halt destructive cleanup if lineage is missing. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-107 — Detect fan-out before publishing account-level revenue totals **Bug · High priority · Expert** noCV practice brief v5 · ADBT-107 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Transform consistently. Depends on: ADBT-104, ADBT-105, ADBT-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. A new feature joins account tags to movement rows and inflates revenue for accounts with multiple tags. Acceptance criteria - Assert row and amount conservation across the join. - Define tag allocation or a nonduplicating existence filter. - Fail publication when conservation fails. Implementation constraints - Keep tag-level attribution distinct from account-level totals. Verification - Add two tags to an account and preserve its revenue total. - Use the naive many-to-many join in a regression and detect inflation. Deliverables - Fan-out guard and corrected account model Rollout and recovery: Canary the model in a separate schema; restore prior view selection on failed conservation. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. ### Publish reliable outputs Validate releases and retain reproducible reports. #### ADBT-108 — Generate a report manifest with exact model and source revisions **Task · Medium priority · Foundational** noCV practice brief v5 · ADBT-108 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Publish reliable outputs. Depends on: ADBT-105, ADBT-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · Storage 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. An analyst sends a CSV to finance and later cannot identify which transformation commit or source cutoff produced it. Acceptance criteria - Include model commit, source checkpoints and generated UTC time. - Hash exported bytes and preserve a report identity. - Exclude credentials and raw customer fields from the manifest. Implementation constraints - Keep the manifest next to synthetic exports. Verification - Regenerate the same named inputs and compare content hashes. - Change a source revision and receive a distinct manifest. Deliverables - Report manifest and reproducibility command Rollout and recovery: Attach manifests to new reports; label earlier exports as lacking lineage. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-109 — Prove an incremental mart matches a full refresh after corrections **Task · Medium priority · Expert** noCV practice brief v5 · ADBT-109 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Publish reliable outputs. Depends on: ADBT-106, ADBT-107, ADBT-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Data 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. The team wants to reduce daily build cost but needs confidence that incremental state does not drift after late corrections. Acceptance criteria - Author a sequence of inserts, revisions and tombstones. - Compare every grain key and measure to a full refresh. - Report extra, missing and changed rows separately. Implementation constraints - Run both paths against the same immutable synthetic inputs. Verification - Replay the complete change sequence with equal final outputs. - Skip one revision intentionally and verify a precise discrepancy report. Deliverables - Differential transformation harness Rollout and recovery: Require a clean differential run before changing schedule; revert to full refresh on mismatch. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. #### ADBT-110 — Write the analytics incident handoff for an unexplained revenue shift **Chore · Medium priority · Intermediate** noCV practice brief v5 · ADBT-110 · Make a subscription analytics mart reproducible Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Publish reliable outputs. Depends on: ADBT-108, ADBT-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. A report moves after a release and on-call staff cannot tell a genuine source correction from a transformation regression. Acceptance criteria - Start investigation from report manifests and affected grain keys. - Separate source, definition and implementation changes. - Include restore-view and corrected-export procedures. Implementation constraints - Use a fabricated incident with no real financial assertions. Verification - Trace one legitimate correction through source lineage. - Trace a fan-out regression and restore the prior reporting view. Deliverables - Analytics incident runbook Rollout and recovery: Validate the runbook with local reports; version it with model publication. Project prerequisites: Create a synthetic source schema and local transformation project. Use integer minor units and distinct reporting currencies. Engineer value: Practice analytical modeling and explainable transformation contracts. Company value: Review trustworthy reporting definitions and the cost of correcting historical reports. 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. ## ACDC — Move customer preferences through a durable change feed A fictional messaging service builds a read model from database changes. Restarts and schema changes can re-enable preferences that customers disabled. **Field:** Data engineering. **Suggested stack:** PostgreSQL, TypeScript, Object storage. **Engineer value:** Practice change-feed ordering, snapshots and privacy-preserving deletion. **Company value:** Review whether replicated customer preferences remain correct during recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic preference records and a replayable local change log. - Use adapters or fixtures without provisioning a production broker. ### Specify the change contract Identify ordering, identities and deletions. #### ACDC-101 — Define the preference change envelope with source position **Task · Medium priority · Foundational** noCV practice brief v5 · ACDC-101 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · API design 20% · 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. The consumer sees a timestamp and payload but cannot distinguish two changes committed in the same millisecond. Acceptance criteria - Include stable source position, record identity and operation. - Separate source commit time from consumer receipt time. - Validate the envelope version before applying changes. Implementation constraints - Use fabricated positions from a deterministic local log. Verification - Parse two same-time changes with distinct positions. - Reject an unknown envelope version without moving the checkpoint. Deliverables - Change envelope schema Rollout and recovery: Publish the contract before consumer rollout; quarantine unsupported versions. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-102 — Redact preference change diagnostics without losing traceability **Bug · High priority · Foundational** noCV practice brief v5 · ACDC-102 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: ACDC-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data 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. Malformed preference payloads are dumped into generic logs with email addresses and free-text notes. Acceptance criteria - Log source position, safe record token and reason code. - Exclude contact details and raw payload bodies. - Retain restricted diagnostic access only through a scoped fixture store. Implementation constraints - Use synthetic contact data in disclosure tests. Verification - Locate a rejected envelope through its safe identifiers. - Inject contact fields and assert they never appear in generic logs. Deliverables - Sanitized diagnostics and disclosure checks Rollout and recovery: Deploy redaction before replay; restrict access to older diagnostic output. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-103 — Represent preference deletion as a durable tombstone **Story · Medium priority · Intermediate** noCV practice brief v5 · ACDC-103 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the change contract. Depends on: ACDC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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. A deleted record disappears from the source snapshot but remains enabled in a downstream projection indefinitely. Acceptance criteria - Define tombstones with identity and source position. - Retain enough ordering metadata to reject stale recreation. - Separate deletion from a false preference value. Implementation constraints - Document retention assumptions for replayable tombstones. Verification - Apply deletion and verify the projected record is absent. - Replay an older enable event and keep the record deleted. Deliverables - Tombstone contract and ordering cases Rollout and recovery: Enable tombstone production before cleanup; stop purging if replay coverage is uncertain. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. ### Build the projection Handle duplicates, schema changes and snapshot handoff. #### ACDC-104 — Advance the feed checkpoint only with the projected transaction **Bug · High priority · Advanced** noCV practice brief v5 · ACDC-104 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-101, ACDC-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Data 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. The consumer acknowledges a change before updating the read model; a crash permanently loses the disabled preference. Acceptance criteria - Apply projection and checkpoint in one durable transaction. - Duplicate delivery is a no-op at the same position. - Failed application leaves the previous checkpoint intact. Implementation constraints - Scope checkpoints to source partition and consumer generation. Verification - Replay a committed change and keep one result. - Fail between modeled projection and checkpoint writes and retry successfully. Deliverables - Transactional consumer and interruption test Rollout and recovery: Canary one synthetic partition; stop consumption on checkpoint divergence. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-105 — Reject a stale preference update after a partition retry **Task · Medium priority · Advanced** noCV practice brief v5 · ACDC-105 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Distributed systems 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 retry queue delivers an old enable event after a newer disable event has already committed. Acceptance criteria - Compare per-record source ordering before mutation. - Retain stale-delivery counters without changing state. - Treat equal position with different content as a conflict. Implementation constraints - Do not use consumer wall time to resolve ordering. Verification - Deliver disable before an older enable and retain disabled. - Send contradictory equal-position data and quarantine the conflict. Deliverables - Per-record ordering guard Rollout and recovery: Observe stale counts during canary; pause conflicting partitions instead of guessing order. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-106 — Handoff a preference snapshot to live changes without a gap **Story · Medium priority · Expert** noCV practice brief v5 · ACDC-106 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-104, ACDC-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Distributed systems 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 new replica loads a snapshot while preferences continue changing, leaving a gap between export time and stream start. Acceptance criteria - Record an explicit snapshot boundary position. - Buffer or replay changes after the boundary before activation. - Keep the new generation unavailable until catch-up is complete. Implementation constraints - Document source guarantees needed for a consistent boundary. Verification - Change a preference during snapshot loading and reach final source state. - Interrupt catch-up and verify readers still use the previous generation. Deliverables - Snapshot handoff protocol and executable timeline Rollout and recovery: Build a shadow generation; restore the previous pointer if catch-up checks fail. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-107 — Evolve a preference value enum without silently coercing unknown values **Task · Medium priority · Intermediate** noCV practice brief v5 · ACDC-107 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the projection. Depends on: ACDC-101, ACDC-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. A new source value called paused is mapped to enabled by the old consumer's default branch. Acceptance criteria - Use an explicit compatibility map for each envelope version. - Unknown values enter quarantine without checkpoint loss. - Document how a compatible consumer resumes blocked input. Implementation constraints - Avoid treating missing values as an affirmative preference. Verification - Apply known values under both supported versions. - Deliver paused to an incompatible consumer and verify no enable write. Deliverables - Version compatibility matrix and consumer guard Rollout and recovery: Deploy compatible readers before writers; retain queued unsupported changes for replay. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. ### Repair feed gaps Detect divergence and recover scoped replicas. #### ACDC-108 — Compare source and replica preferences without exporting contacts **Chore · Medium priority · Intermediate** noCV practice brief v5 · ACDC-108 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-106, ACDC-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. Operators suspect a gap but a full data export would spread contact information across incident tooling. Acceptance criteria - Compare keyed hashes and safe row counts by bounded scope. - Report missing, extra and mismatched record tokens. - Keep raw preference payloads out of the report. Implementation constraints - Use stable canonical hashing and documented null handling. Verification - Compare equal synthetic source and replica states. - Alter one value and delete one row; identify both discrepancy categories. Deliverables - Scoped reconciliation report Rollout and recovery: Run read-only reconciliation first; expire generated diagnostic artifacts after review. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-109 — Repair one preference partition while continuing unrelated reads **Task · Medium priority · Expert** noCV practice brief v5 · ACDC-109 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-106, ACDC-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Distributed systems 30% · Database 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. One replica partition is corrupted; rebuilding the entire preference service would unnecessarily interrupt all accounts. Acceptance criteria - Rebuild only the selected source scope into a new generation. - Catch up from the recorded boundary before pointer swap. - Prevent repaired and old generations from mixing in one scoped read. Implementation constraints - Require a dry-run plan and explicit partition identity. Verification - Repair a synthetic partition and preserve unrelated output hashes. - Interrupt before swap and retain complete reads from the old generation. Deliverables - Partition repair command and atomic-read probe Rollout and recovery: Canary repair on a synthetic scope; switch its pointer back if reconciliation fails. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. #### ACDC-110 — Expose replica freshness with a trustworthy unknown state **Story · Medium priority · Foundational** noCV practice brief v5 · ACDC-110 · Move customer preferences through a durable change feed Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair feed gaps. Depends on: ACDC-108, ACDC-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. The dashboard marks a replica healthy when its consumer is running even though no source checkpoint has been observed. Acceptance criteria - Show applied source position and receipt lag separately. - Report unknown when no comparable source watermark exists. - Define stale thresholds in the local operating contract. Implementation constraints - Never infer source completeness from process liveness. Verification - Advance source and replica positions and calculate the documented lag. - Remove the source watermark and return unknown health. Deliverables - Freshness endpoint and unknown-state cases Rollout and recovery: Add freshness as advisory status first; restore the prior view while preserving unknown semantics. Project prerequisites: Create synthetic preference records and a replayable local change log. Use adapters or fixtures without provisioning a production broker. Engineer value: Practice change-feed ordering, snapshots and privacy-preserving deletion. Company value: Review whether replicated customer preferences remain correct during recovery. 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. ## ACONFIG — Release configuration without restarting every service A fictional internal reporting platform changes feature and timeout settings through environment edits. Partial rollouts leave API and worker processes interpreting different values. **Field:** Platform engineering. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice configuration contracts, compatibility and failure recovery. **Company value:** Review controlled configuration delivery with inspectable blast radius. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create local API and worker configuration consumers. - Use fabricated settings without secrets. ### Make settings explicit Define typed settings and safe defaults. #### ACONFIG-101 — Inventory runtime settings with owners and restart requirements **Task · Medium priority · Foundational** noCV practice brief v5 · ACONFIG-101 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make settings explicit. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform 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. Operators cannot tell whether changing a timeout requires a worker restart or takes effect on the next request. Acceptance criteria - List type, owner, default and adoption boundary for each setting. - Separate secrets from nonsecret runtime configuration. - Mark unknown behavior as unresolved before rollout. Implementation constraints - Use a small fictional inventory of eight settings. Verification - Trace one dynamic setting through its read boundary. - Identify a startup-only setting and prevent a dynamic edit. Deliverables - Configuration inventory and adoption contract Rollout and recovery: Review the inventory before exposing edits; keep unresolved settings read-only. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-102 — Reject invalid timeout combinations as one configuration unit **Bug · Medium priority · Intermediate** noCV practice brief v5 · ACONFIG-102 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make settings explicit. Depends on: ACONFIG-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 80% · 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. A retry timeout exceeds the entire request deadline, causing requests to continue working after callers have disconnected. Acceptance criteria - Validate relationships between attempt, retry and total deadlines. - Reject the complete candidate snapshot on any invalid relation. - Return field paths with safe values only. Implementation constraints - Use explicit duration units; reject implicit unit conversion. Verification - Accept a documented valid retry budget. - Reject a larger attempt timeout than total deadline without changing active settings. Deliverables - Snapshot validator and deadline fixtures Rollout and recovery: Add validation to drafts; preserve the active snapshot on any rejection. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-103 — Define an immutable configuration snapshot envelope **Task · Medium priority · Foundational** noCV practice brief v5 · ACONFIG-103 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make settings explicit. Depends on: ACONFIG-101, ACONFIG-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform 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 config endpoint returns a mutable object with no revision, so incident reports cannot establish which settings were read. Acceptance criteria - Include revision, canonical hash and schema version. - Published snapshot content cannot be edited in place. - Exclude secret material from serialization and logs. Implementation constraints - Use opaque IDs and UTC publication metadata. Verification - Read the same revision twice and compare hashes. - Attempt an in-place edit and reject it. Deliverables - Snapshot contract and immutability checks Rollout and recovery: Start versioned publication alongside legacy reads; retain published revisions for recovery. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. ### Distribute revisions Publish compatible snapshots and control adoption. #### ACONFIG-104 — Atomically adopt a validated configuration snapshot in each process **Story · High priority · Advanced** noCV practice brief v5 · ACONFIG-104 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute revisions. Depends on: ACONFIG-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Backend 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 process updates settings one field at a time, briefly combining a new retry count with an old deadline. Acceptance criteria - Validate the full snapshot before replacing the active reference. - Each request captures one revision for its lifetime. - Failed adoption retains the complete previous snapshot. Implementation constraints - Avoid mutating shared configuration objects after publication. Verification - Switch snapshots during requests and observe one revision per request. - Reject one invalid field and retain every previous value. Deliverables - Atomic consumer adapter and concurrent-read probe Rollout and recovery: Canary a local worker consumer; pin its previous revision if adoption fails. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-105 — Publish configuration only against the revision reviewed by the operator **Story · Medium priority · Advanced** noCV practice brief v5 · ACONFIG-105 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute revisions. Depends on: ACONFIG-103, ACONFIG-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Database 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. Two operators edit the same draft; the last publisher activates changes based on a stale review. Acceptance criteria - Require expected draft revision and reviewed hash. - Commit publication and active selection together. - Return a conflict with safe revision metadata on stale publication. Implementation constraints - Record actor and reason in an append-only audit record. Verification - Publish an unchanged reviewed snapshot. - Race two publishers and assert one accepted active transition. Deliverables - Optimistic publication command and race test Rollout and recovery: Enable publication for a synthetic operator role; disable writes if audit persistence fails. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-106 — Keep incompatible consumers on their last valid configuration **Task · Medium priority · Expert** noCV practice brief v5 · ACONFIG-106 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute revisions. Depends on: ACONFIG-104, ACONFIG-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. A new configuration schema reaches an older worker that silently ignores a field needed to preserve retry limits. Acceptance criteria - Consumers declare accepted schema versions. - Incompatible snapshots are rejected with explicit adoption status. - Critical missing configuration fails closed under the documented startup policy. Implementation constraints - Do not coerce unknown versions into the current schema. Verification - Adopt compatible settings in old and new local consumers. - Send a new unsupported schema and preserve the old snapshot or fail startup as declared. Deliverables - Compatibility handshake and failure matrix Rollout and recovery: Deploy compatible readers before publishing new schema; repoint to the older supported revision if needed. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-107 — Stage a timeout revision for a named consumer cohort **Story · Medium priority · Intermediate** noCV practice brief v5 · ACONFIG-107 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute revisions. Depends on: ACONFIG-105, ACONFIG-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform 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. The team wants to test a timeout change on background reports before affecting interactive requests. Acceptance criteria - Bind cohort selection to stable nonpersonal service identity. - Show intended and acknowledged revision per cohort. - Unselected consumers retain their current target revision. Implementation constraints - Use deterministic synthetic cohort membership. Verification - Adopt a revision in the report-worker cohort only. - Use an unknown cohort and reject publication without target changes. Deliverables - Cohort rollout command and targeting cases Rollout and recovery: Begin with one synthetic cohort; restore its previous target revision on errors. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. ### Handle stale consumers Observe adoption and recover rejected changes. #### ACONFIG-108 — Report configuration staleness separately from application health **Story · Medium priority · Foundational** noCV practice brief v5 · ACONFIG-108 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle stale consumers. Depends on: ACONFIG-106, ACONFIG-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 healthy process missed several configuration polls, but a green liveness check hides that it is running stale limits. Acceptance criteria - Expose active and target revision plus last successful poll time. - Distinguish stale, incompatible and unavailable states. - Avoid including configuration values in generic health payloads. Implementation constraints - Use a fake clock for staleness boundaries. Verification - Advance target while a consumer stays behind and report stale. - Lose the configuration endpoint and keep the declared last-known-good behavior visible. Deliverables - Adoption status projection Rollout and recovery: Add the status endpoint before alerts; disable noisy alerts without hiding adoption state. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-109 — Rollback configuration by selecting a prior immutable snapshot **Task · Medium priority · Intermediate** noCV practice brief v5 · ACONFIG-109 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle stale consumers. Depends on: ACONFIG-105, ACONFIG-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. An operator attempts to repair a bad timeout by manually rewriting the active record, erasing the incident's configuration history. Acceptance criteria - Rollback appends a selection event with reason and actor. - Validate old snapshot compatibility before selection. - Retain the bad revision and its adoption record. Implementation constraints - Use the same guarded publication boundary as forward changes. Verification - Select a compatible prior revision and observe consumer adoption. - Attempt rollback to an incompatible schema and leave the target unchanged. Deliverables - Audited rollback command Rollout and recovery: Rehearse on synthetic consumers; pin a known compatible revision if adoption stalls. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. #### ACONFIG-110 — Exercise configuration service loss during a rolling deployment **Task · Medium priority · Expert** noCV practice brief v5 · ACONFIG-110 · Release configuration without restarting every service Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle stale consumers. Depends on: ACONFIG-106, ACONFIG-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Site reliability 30% · 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. The configuration endpoint becomes unavailable while old and new workers are starting with different cached snapshots. Acceptance criteria - Describe startup and running-process behavior separately. - Prove critical settings cannot start from an unvalidated cache. - Record revision selection and recovery for both consumer versions. Implementation constraints - Use local fault injection; no production configuration changes. Verification - Disconnect the endpoint after valid adoption and retain the declared bounded behavior. - Start with a corrupt cache during outage and reject startup safely. Deliverables - Outage drill and compatibility trace Rollout and recovery: Run before rollout; halt the deployment if a consumer cannot demonstrate its selected revision. Project prerequisites: Create local API and worker configuration consumers. Use fabricated settings without secrets. Engineer value: Practice configuration contracts, compatibility and failure recovery. Company value: Review controlled configuration delivery with inspectable blast radius. 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. ## AENV — Make ephemeral review environments predictable A fictional team creates preview stacks for pull requests. Orphan databases consume resources and previews sometimes inherit settings intended for another branch. **Field:** Platform engineering. **Suggested stack:** TypeScript, Compose specification, PostgreSQL. **Engineer value:** Practice resource lifecycle, reconciliation and least-privilege setup. **Company value:** Review reliable preview workflows and accountable resource cleanup. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local provisioning adapter with synthetic repository events. - Use isolated disposable resources and no production credentials. ### Plan isolated previews Validate requests and resource boundaries. #### AENV-101 — Validate preview requests before allocating resources **Task · Medium priority · Foundational** noCV practice brief v5 · AENV-101 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Plan isolated previews. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · API design 20% · 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. A branch name containing slashes and punctuation becomes an invalid database name after resources are already created. Acceptance criteria - Use an opaque environment ID for resource names. - Validate repository scope, revision and requested lifetime. - Reject malformed requests before any provider call. Implementation constraints - Treat branch labels as display data only. Verification - Accept a valid synthetic revision with a complex branch label. - Reject missing scope and excessive lifetime with zero allocation calls. Deliverables - Preview request schema Rollout and recovery: Enable request validation first; leave rejected previews unallocated. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-102 — Create a review-environment resource plan with an explicit quota **Task · Medium priority · Intermediate** noCV practice brief v5 · AENV-102 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Plan isolated previews. Depends on: AENV-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Cloud infrastructure 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. One preview requests every optional dependency and exhausts the local resource budget. Acceptance criteria - List CPU, memory, storage and lifetime requirements. - Reject plans exceeding per-environment or aggregate quotas. - Keep optional dependencies explicit rather than provisioned by default. Implementation constraints - Use documented synthetic quotas and a dry-run planner. Verification - Plan a minimal API and database preview. - Exceed storage and concurrent-environment quotas and reject allocation. Deliverables - Quota-aware plan command Rollout and recovery: Expose dry-run plans first; reduce admitted previews if available resources shrink. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-103 — Keep preview connection material out of build output **Bug · High priority · Foundational** noCV practice brief v5 · AENV-103 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Plan isolated previews. Depends on: AENV-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Provisioning logs print database URLs that contain temporary credentials. Acceptance criteria - Redact passwords, tokens and credential-bearing URLs. - Return secret references separately from public preview metadata. - Keep synthetic credentials out of generated manifests. Implementation constraints - Use allowlisted structured logging fields. Verification - Inspect successful provisioning logs for safe identifiers. - Inject a credential into provider errors and assert redaction. Deliverables - Log redaction and metadata projection Rollout and recovery: Deploy redaction before provisioning; rotate any affected disposable credentials. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. ### Reconcile environment state Make setup and updates repeatable. #### AENV-104 — Make preview creation resumable after a partial provider failure **Story · High priority · Advanced** noCV practice brief v5 · AENV-104 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile environment state. Depends on: AENV-102, AENV-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Cloud infrastructure 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. The database is created but the API startup fails; retry creates a second database and loses track of the first. Acceptance criteria - Assign deterministic resource identities per environment generation. - Record each completed allocation before moving to the next. - Resume from observed resources instead of blindly recreating them. Implementation constraints - Use a provider interface with injected failure points. Verification - Fail after database creation and resume to one database. - Return an unexpected existing resource owner and halt without adoption. Deliverables - Reconciliation loop and partial-failure probe Rollout and recovery: Canary local environments; pause allocation while retaining resource records on inconsistency. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-105 — Bind preview updates to the exact requested source revision **Bug · Medium priority · Advanced** noCV practice brief v5 · AENV-105 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile environment state. Depends on: AENV-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Distributed systems 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 slow build for an older commit finishes after a newer build and replaces the current preview. Acceptance criteria - Track requested generation and source revision. - Only the current generation may become active. - Keep stale build artifacts visible for cleanup but never route traffic to them. Implementation constraints - Do not treat completion time as revision order. Verification - Complete two builds in reverse order and activate only the latest requested one. - Retry stale activation and preserve the selected generation. Deliverables - Generation guard and completion-order tests Rollout and recovery: Enable guarded routing; restore the prior valid generation if the new one fails readiness. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-106 — Initialize preview data from a synthetic schema contract **Story · Medium priority · Intermediate** noCV practice brief v5 · AENV-106 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile environment state. Depends on: AENV-104, AENV-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · Quality engineering 30% · Database 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. Preview startup depends on a copy of production data, making reviews slow and difficult to share safely. Acceptance criteria - Create deterministic synthetic records covering declared UI states. - Apply migrations before seeding the environment. - Fail readiness when the seed contract is incomplete. Implementation constraints - Do not import real customer data or production secrets. Verification - Create two previews and compare declared synthetic identities and states. - Fail a migration and verify the seed does not mark the environment ready. Deliverables - Synthetic seed command and readiness checks Rollout and recovery: Enable the seed on new previews; recreate disposable data if the contract changes. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-107 — Probe readiness without accidentally validating only process liveness **Task · Medium priority · Advanced** noCV practice brief v5 · AENV-107 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile environment state. Depends on: AENV-105, AENV-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. The preview link is published while migrations are still running, so reviewers immediately hit missing-table errors. Acceptance criteria - Readiness checks required dependencies and schema version. - Liveness remains independent of external dependency availability. - Publish the link only after the current generation passes readiness. Implementation constraints - Bound probe time and omit secret diagnostics. Verification - Start a complete preview and publish its link. - Delay migration completion and assert no ready link is announced. Deliverables - Readiness contract and startup timeline Rollout and recovery: Canary readiness gating; suppress links and inspect the generation on repeated failures. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. ### Retire environments safely Detect expiration and recover incomplete cleanup. #### AENV-108 — Expire review environments with a grace period and owner visibility **Story · Medium priority · Foundational** noCV practice brief v5 · AENV-108 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Retire environments safely. Depends on: AENV-104, AENV-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Cloud infrastructure 20% · 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. A preview remains allocated after its pull request closes because nobody owns the cleanup schedule. Acceptance criteria - Persist owner token, expiry instant and grace deadline. - List expiring environments without exposing credentials. - Allow authorized extension within the declared maximum lifetime. Implementation constraints - Use an injectable clock and synthetic ownership. Verification - Advance through expiry and grace states. - Attempt extension by another owner and reject it. Deliverables - Expiry state model and owner view Rollout and recovery: Enable expiry reporting before cleanup; extend only reviewed environments during adoption. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-109 — Delete only resources owned by the retired preview generation **Task · High priority · Expert** noCV practice brief v5 · AENV-109 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Retire environments safely. Depends on: AENV-105, AENV-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Cloud infrastructure 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. A cleanup job matches resource names by prefix and can remove a newer generation sharing the same branch label. Acceptance criteria - Match exact environment, generation and ownership tags. - Refuse deletion for missing or contradictory ownership. - Make retries converge after partial deletion. Implementation constraints - Provider deletion receives exact resource IDs, never wildcard names. Verification - Retire an old generation while keeping the new one usable. - Alter an ownership tag and verify cleanup stops before deletion. Deliverables - Ownership-checked cleanup and isolation tests Rollout and recovery: Dry-run deletion plans first; pause cleanup and preserve unresolved resources on ownership conflicts. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. #### AENV-110 — Reconcile orphan preview resources into an auditable cleanup queue **Chore · Medium priority · Expert** noCV practice brief v5 · AENV-110 · Make ephemeral review environments predictable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Retire environments safely. Depends on: AENV-104, AENV-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Cloud infrastructure 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 process crashed before saving its final resource record; local storage now contains an environment no active preview references. Acceptance criteria - Compare provider inventory to durable environment generations. - Classify owned orphan, active and unknown resources. - Require review of unknown ownership before any deletion. Implementation constraints - Bound inventory scans and retain an immutable reconciliation report. Verification - Discover an owned orphan and propose exact cleanup identities. - Present an untagged resource and verify it is never automatically removed. Deliverables - Orphan inventory command and cleanup report Rollout and recovery: Run read-only first; execute only reviewed owned-orphan plans and stop on inventory drift. Project prerequisites: Create a local provisioning adapter with synthetic repository events. Use isolated disposable resources and no production credentials. Engineer value: Practice resource lifecycle, reconciliation and least-privilege setup. Company value: Review reliable preview workflows and accountable resource cleanup. 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. ## AIMAGE — Harden a service image build and promotion workflow A fictional reporting API is rebuilt separately for staging and production. Different dependency resolutions and mutable tags make incident rollback unreliable. **Field:** Platform engineering. **Suggested stack:** OCI image tools, TypeScript, CI. **Engineer value:** Practice artifact identity, least privilege and reproducible delivery. **Company value:** Review whether deployed bytes can be traced and rolled back reliably. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a tiny local HTTP service and nonprivileged image build. - Use synthetic registries or provider fixtures; no production deployment. ### Constrain image construction Pin inputs and limit build context. #### AIMAGE-101 — Exclude local credentials and bulky artifacts from the image context **Bug · High priority · Foundational** noCV practice brief v5 · AIMAGE-101 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain image construction. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Platform engineering 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. A developer notices an environment file and test recordings copied into the service image. Acceptance criteria - Allow only required source and build inputs into context. - Exclude environment files, VCS metadata and generated recordings. - Add a safe inspection command that lists included paths. Implementation constraints - Create fake secrets for tests; never scan or print real secret values. Verification - Build a minimal synthetic service context. - Add a fake credential file and verify it is absent from context and image. Deliverables - Context allowlist and image-content check Rollout and recovery: Apply before the next image build; discard affected disposable images. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-102 — Pin service build inputs to immutable identities **Task · Medium priority · Foundational** noCV practice brief v5 · AIMAGE-102 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain image construction. Depends on: AIMAGE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 70% · Developer tooling 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 rebuild of an old commit picks up a newer base image and no longer reproduces the original runtime. Acceptance criteria - Pin the base image digest and dependency lockfile. - Record compiler and build-tool versions. - Fail the build when frozen dependency resolution changes the lockfile. Implementation constraints - Document the update procedure rather than permanently freezing vulnerabilities. Verification - Build twice from identical named inputs and compare artifact metadata. - Change a pinned input and require a new provenance record. Deliverables - Pinned build definition Rollout and recovery: Introduce pinned builds for new artifacts; retain old digest references for rollback. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-103 — Run the service image as an unprivileged user with a read-only root **Task · Medium priority · Intermediate** noCV practice brief v5 · AIMAGE-103 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain image construction. Depends on: AIMAGE-101, AIMAGE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. The API image starts as root and writes temporary report files into the application directory. Acceptance criteria - Use a non-root runtime user. - Keep the base filesystem read-only with an explicit temporary directory. - Reject startup when required writable storage is unavailable. Implementation constraints - No privileged mode, host mounts, host networking or container-engine socket. Verification - Serve a request under the restricted runtime configuration. - Attempt a write to the application directory and verify denial. Deliverables - Restricted runtime definition and filesystem probe Rollout and recovery: Canary the restricted image locally; stop rollout if required writes lack an explicit temporary path. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. ### Promote exact artifacts Validate artifacts and preserve provenance. #### AIMAGE-104 — Record image provenance without embedding build credentials **Story · Medium priority · Intermediate** noCV practice brief v5 · AIMAGE-104 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Promote exact artifacts. Depends on: AIMAGE-102, AIMAGE-103. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. Operations can see a tag but cannot trace it to source revision, dependency lock hash or build run. Acceptance criteria - Record source revision, input hashes and final image digest. - Associate provenance with the exact artifact digest. - Exclude environment values and registry tokens. Implementation constraints - Use a local provenance document for this exercise. Verification - Resolve a built digest to its source and lockfile hashes. - Alter provenance digest and reject the mismatch. Deliverables - Artifact provenance manifest and verification command Rollout and recovery: Attach provenance to new builds; refuse promotion when it cannot be verified. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-105 — Promote the tested digest instead of rebuilding for each environment **Story · High priority · Advanced** noCV practice brief v5 · AIMAGE-105 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Promote exact artifacts. Depends on: AIMAGE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform 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. The staging build passes, but production rebuilds the same commit with different transitive dependencies. Acceptance criteria - Promotion selects the exact tested digest. - Separate runtime configuration from artifact construction. - Reject a tag that resolves to a different digest at promotion. Implementation constraints - Model registries through a testable provider interface. Verification - Promote a tested synthetic digest through two environments. - Move a mutable tag and verify promotion rejects the changed artifact. Deliverables - Digest promotion command and tag-race regression Rollout and recovery: Canary promotion metadata; restore the previously selected digest if validation fails. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-106 — Stop promotion when required security scan results are missing **Task · Medium priority · Advanced** noCV practice brief v5 · AIMAGE-106 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Promote exact artifacts. Depends on: AIMAGE-104, AIMAGE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 scan service times out and the build pipeline treats absence of findings as a clean result. Acceptance criteria - Represent passed, failed and unavailable scan states distinctly. - Require scan policy and artifact digest to match. - Unavailable required results block promotion with a retry path. Implementation constraints - Use synthetic scan responses; do not claim current vulnerability coverage. Verification - Promote with matching passed policy results. - Timeout or return a different digest and verify promotion remains blocked. Deliverables - Scan-result gate and unavailable-state tests Rollout and recovery: Run the gate before environment selection; retry scans without rebuilding the artifact. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-107 — Make artifact promotion idempotent across lost CI responses **Bug · Medium priority · Expert** noCV practice brief v5 · AIMAGE-107 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Promote exact artifacts. Depends on: AIMAGE-105, AIMAGE-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Database 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 CI runner loses the promotion response and retries, creating competing rollout records for one digest. Acceptance criteria - Use a stable promotion key bound to environment and digest. - Retries resolve one durable promotion record. - Changed digest under the same key returns conflict. Implementation constraints - Persist selection and audit metadata atomically. Verification - Drop a response after commit and retry the same selection. - Reuse a promotion key for another digest and retain the original selection. Deliverables - Idempotent promotion command Rollout and recovery: Enable for synthetic environments; pause conflicting promotions and retain their audit records. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. ### Recover artifact failures Retain usable revisions and rehearse rollback. #### AIMAGE-108 — Retain rollback images without deleting active environment digests **Chore · Medium priority · Intermediate** noCV practice brief v5 · AIMAGE-108 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover artifact failures. Depends on: AIMAGE-105, AIMAGE-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Storage systems 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. Registry cleanup removes an image still running in a quiet environment because its tag is old. Acceptance criteria - Retention protects every active and explicitly retained rollback digest. - Compute deletion candidates before executing cleanup. - Recheck references immediately before removal. Implementation constraints - Use exact digest references rather than tag age alone. Verification - Expire an unreferenced synthetic image. - Add an active reference after planning and verify deletion is skipped. Deliverables - Digest retention planner and race test Rollout and recovery: Dry-run retention first; stop cleanup if environment inventory is unavailable. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-109 — Rehearse rollback when the new image cannot read existing data **Task · Medium priority · Expert** noCV practice brief v5 · AIMAGE-109 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover artifact failures. Depends on: AIMAGE-107, AIMAGE-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 60% · Database 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 runtime starts successfully but fails on records created by the previous release. Acceptance criteria - Declare compatibility expectations for stored data. - Route back to the retained old digest without rebuilding. - Identify any irreversible schema step that blocks binary rollback. Implementation constraints - Use a synthetic compatibility fixture and local runtime only. Verification - Roll out a compatible image and restore its predecessor. - Trigger a schema incompatibility and stop automatic rollback with an explicit recovery decision. Deliverables - Rollback drill and compatibility matrix Rollout and recovery: Run the drill before promotion; block releases without a viable declared recovery path. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. #### AIMAGE-110 — Publish a release inventory that resolves environments to exact bytes **Task · Medium priority · Foundational** noCV practice brief v5 · AIMAGE-110 · Harden a service image build and promotion workflow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover artifact failures. Depends on: AIMAGE-104, AIMAGE-108, AIMAGE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. Incident responders receive three different tag names for what appears to be the same release. Acceptance criteria - List environment, selected digest and provenance identity. - Show requested selection separately from observed running digest. - Mark missing observations as unknown. Implementation constraints - Omit registry credentials and private build output. Verification - Resolve two aliases to the same artifact digest. - Remove runtime observation and display unknown rather than deployed. Deliverables - Release inventory projection Rollout and recovery: Publish read-only inventory first; repair stale observations without changing selections. Project prerequisites: Create a tiny local HTTP service and nonprivileged image build. Use synthetic registries or provider fixtures; no production deployment. Engineer value: Practice artifact identity, least privilege and reproducible delivery. Company value: Review whether deployed bytes can be traced and rolled back reliably. 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. ## ATOKEN — Repair API token scope and revocation boundaries A fictional B2B export API uses long-lived tokens. Tokens copied between organizations can access too much, and revocation takes effect unpredictably. **Field:** Security. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice authorization boundaries, credential lifecycle and safe diagnostics. **Company value:** Review denial paths and operational control over service access. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local synthetic API and two isolated organizations. - Use generated disposable credentials only. ### Define token authority Separate identity, scope and safe display. #### ATOKEN-101 — Define token scopes as an explicit allowlist of export operations **Task · High priority · Foundational** noCV practice brief v5 · ATOKEN-101 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A token marked read-only can still trigger an export job because the handler treats every authenticated token equally. Acceptance criteria - List exact read and create operations per scope. - Unknown scopes are rejected at issuance. - Protected handlers deny missing required scope. Implementation constraints - Do not infer permission from token naming conventions. Verification - Use a read scope for a permitted status request. - Attempt export creation with that token and verify no job is created. Deliverables - Scope matrix and authorization checks Rollout and recovery: Deploy handler checks before issuing scoped tokens; disable legacy unrestricted issuance. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-102 — Store only token verification material and a safe display prefix **Task · Medium priority · Intermediate** noCV practice brief v5 · ATOKEN-102 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: ATOKEN-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Database 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. The token-management page retrieves complete credentials from the database every time an administrator opens it. Acceptance criteria - Show the full token only at initial issuance. - Persist one-way verification material and a nonsecret identifier. - List views never return reusable token material. Implementation constraints - Use a mature cryptographic primitive and document verification behavior. Verification - Issue and authenticate a disposable token. - Read the list and stored record; verify the raw token is absent. Deliverables - Token storage contract and disclosure tests Rollout and recovery: Migrate new tokens first; retire legacy raw-token records through explicit rotation. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-103 — Bind API token queries to the issuing organization **Bug · Urgent priority · Advanced** noCV practice brief v5 · ATOKEN-103 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: ATOKEN-101, ATOKEN-102. Difficulty: Advanced. Estimated focused work: 210 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. An export identifier from another organization succeeds because the service checks token validity but omits tenant scope. Acceptance criteria - Repository reads include the token organization. - Cross-organization IDs receive nondisclosing denial. - Authorization occurs before artifact-link creation. Implementation constraints - Test repository boundaries as well as routes. Verification - Read an export in the issuing organization. - Request a second organization's export and verify no signed-link provider call. Deliverables - Tenant-bound repository guard Rollout and recovery: Deploy the scope guard before further token distribution; inspect denied access metadata. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. ### Control token lifetime Rotate and revoke without widening authority. #### ATOKEN-104 — Enforce token expiration at the request authorization boundary **Bug · Medium priority · Foundational** noCV practice brief v5 · ATOKEN-104 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-102, ATOKEN-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 token expires in storage but remains usable because the cached authentication result has no expiry check. Acceptance criteria - Check current expiry with an injected clock. - Cache lifetime cannot exceed token expiry. - Expired tokens fail before protected service execution. Implementation constraints - Use UTC instants and avoid logging presented credentials. Verification - Authenticate just before expiry. - Advance to the exact expiry instant and deny cached and uncached requests. Deliverables - Expiry enforcement and clock-boundary cases Rollout and recovery: Canary with disposable short-lived tokens; flush incompatible authentication caches. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-105 — Rotate a token with a bounded overlap window **Story · Medium priority · Advanced** noCV practice brief v5 · ATOKEN-105 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Customers need to replace credentials without downtime, but unrestricted overlap leaves old tokens valid indefinitely. Acceptance criteria - Create a replacement with no broader scopes. - Persist an explicit predecessor retirement deadline. - Expose both token identities and overlap state safely. Implementation constraints - Require authorized rotation and bind it to an expected token revision. Verification - Rotate and authenticate both during the declared overlap. - Advance beyond the overlap and deny the predecessor while accepting the replacement. Deliverables - Rotation command and overlap tests Rollout and recovery: Test with a synthetic client; revoke the new token if adoption fails within the window. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-106 — Make revocation override cached authentication results **Task · High priority · Expert** noCV practice brief v5 · ATOKEN-106 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-104, ATOKEN-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Distributed systems 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 administrator revokes a leaked token, but one process continues accepting its cached authority. Acceptance criteria - Define a maximum revocation propagation contract. - Invalidate or version cached authority using durable token state. - Fail closed when required revocation freshness cannot be established. Implementation constraints - Use two local consumer instances and controlled connectivity failures. Verification - Revoke a token and verify both consumers deny within the declared bound. - Disconnect revocation freshness and verify the documented denial behavior. Deliverables - Revocation protocol and propagation probe Rollout and recovery: Canary two synthetic consumers; reduce cache lifetime or disable caching on propagation failure. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-107 — Prevent a retry from issuing multiple replacement credentials **Bug · Medium priority · Advanced** noCV practice brief v5 · ATOKEN-107 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-105, ATOKEN-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Backend 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 rotation response is lost and a retry creates another active successor that the customer never receives. Acceptance criteria - Bind rotation idempotency to actor, predecessor and requested scope. - One successful command creates one successor. - Changed rotation parameters under the same key conflict. Implementation constraints - Store only a bounded issuance response under the declared secret-handling policy. Verification - Retry a completed rotation and count one successor. - Reuse its key with broader scopes and verify rejection. Deliverables - Idempotent rotation transaction Rollout and recovery: Enable rotation retries with a short documented response lifetime; revoke orphan test tokens during recovery. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. ### Observe denied access Verify isolation and respond to exposure. #### ATOKEN-108 — Record denied API access without turning audit logs into a token store **Task · Medium priority · Intermediate** noCV practice brief v5 · ATOKEN-108 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-103, ATOKEN-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy 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. Security needs failed-access context, but the existing logger captures the Authorization header and request body. Acceptance criteria - Record safe token identity, route, reason and UTC time. - Exclude authorization headers and body content. - Bound repeated denial events to prevent log exhaustion. Implementation constraints - Use synthetic token strings in redaction tests. Verification - Trace a scope denial by safe token identity. - Send repeated malformed tokens and verify redaction and bounded logging. Deliverables - Safe denial audit and rate-bound checks Rollout and recovery: Deploy audit filtering first; quarantine old diagnostic logs for authorized review. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-109 — Rehearse credential exposure containment for one organization **Task · Medium priority · Expert** noCV practice brief v5 · ATOKEN-109 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-106, ATOKEN-107, ATOKEN-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A fictional customer reports that a token was pasted into a public issue; operations needs a tested containment sequence. Acceptance criteria - Identify and revoke the affected token without listing secrets. - Confirm denial across every local consumer. - Preserve safe audit facts and issue a scoped replacement through the normal flow. Implementation constraints - Use a disposable token and a fabricated incident only. Verification - Run the complete containment drill and verify old-token denial. - Simulate an unreachable consumer and keep containment status incomplete. Deliverables - Exposure response runbook and executable drill Rollout and recovery: Practice in a synthetic organization; stop replacement distribution until revocation status is known. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-110 — Show token last-use status without claiming it proves nonuse **Story · Medium priority · Foundational** noCV practice brief v5 · ATOKEN-110 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-108, ATOKEN-109. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Administrators interpret an empty last-used field as proof that a token was never used, despite audit ingestion gaps. Acceptance criteria - Distinguish observed use, no recorded use and unknown coverage. - State the observation window and freshness. - Avoid exposing request payloads in token summaries. Implementation constraints - Treat last-use metadata as operational evidence with stated limits. Verification - Record a successful request and show its observation time. - Remove audit coverage and show unknown instead of never used. Deliverables - Token activity projection Rollout and recovery: Publish the explicit coverage labels; revert UI wiring if scope checks fail. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. ## AFETCH — Constrain a server-side document fetcher A fictional knowledge service imports documents from customer-entered URLs. The importer follows redirects and trusts response metadata too broadly. **Field:** Security. **Suggested stack:** TypeScript, HTTP client, Object storage. **Engineer value:** Practice defensive URL handling and bounded untrusted-input processing. **Company value:** Review whether integrations can import content without expanding infrastructure access. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Build a local fetch adapter and controlled HTTP test servers. - Use synthetic documents and deny network access outside the test allowlist. ### Define fetch authority Constrain URLs, identity and network destinations. #### AFETCH-101 — Accept only explicitly supported document URL schemes **Task · Medium priority · Foundational** noCV practice brief v5 · AFETCH-101 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define fetch authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A customer enters a non-HTTP URI that the generic import library attempts to interpret as a local resource. Acceptance criteria - Allow HTTPS under an explicit destination policy. - Reject embedded credentials and unsupported schemes. - Normalize once and retain a safe display URL. Implementation constraints - Use a standard URL parser; do not build one with string prefixes. Verification - Accept an approved synthetic HTTPS URL. - Reject file, data and credential-bearing URLs before network calls. Deliverables - URL input policy and parser tests Rollout and recovery: Enforce validation before import dispatch; quarantine existing unsupported requests. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-102 — Bind document import requests to tenant-owned destination policies **Task · Medium priority · Intermediate** noCV practice brief v5 · AFETCH-102 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define fetch authority. Depends on: AFETCH-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. One tenant configures an approved host and another tenant unexpectedly inherits permission to fetch from it. Acceptance criteria - Resolve allowlists within the requesting tenant. - Require authorization before creating a fetch job. - Reject unknown policy references without disclosing other tenants' hosts. Implementation constraints - Store policy version with the import request. Verification - Import through the tenant's approved synthetic host. - Reuse another tenant's policy ID and verify zero fetch calls. Deliverables - Scoped destination-policy service Rollout and recovery: Deploy tenant resolution before enabling saved policies; disable import on ambiguous ownership. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-103 — Reject private and special-use destination addresses before connection **Bug · Urgent priority · Advanced** noCV practice brief v5 · AFETCH-103 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define fetch authority. Depends on: AFETCH-101, AFETCH-102. Difficulty: Advanced. Estimated focused work: 240 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. A public-looking hostname resolves to an internal address during import and reaches a service unavailable to the user. Acceptance criteria - Apply destination-address policy to every resolved connection target. - Reject loopback, private and special-use addresses outside explicit local tests. - Prevent resolver results from changing unchecked before connection. Implementation constraints - Use an injected resolver and connection adapter; tests never contact internal services. Verification - Resolve an allowed synthetic public address through the fixture adapter. - Return loopback or changed resolution and verify no connection is opened. Deliverables - Resolver-to-connection policy and fixture tests Rollout and recovery: Run policy checks before enabling network fetches; deny unresolved or ambiguous destinations. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. ### Bound remote work Apply limits through redirects and response streaming. #### AFETCH-104 — Revalidate every document redirect before following it **Bug · High priority · Advanced** noCV practice brief v5 · AFETCH-104 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound remote work. Depends on: AFETCH-103. Difficulty: Advanced. Estimated focused work: 210 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 download host redirects to an unapproved internal URL after the first request passes validation. Acceptance criteria - Limit redirect count and validate each target independently. - Do not forward credentials across origins. - Reject redirect loops with a stable reason code. Implementation constraints - Use local controlled redirect fixtures only. Verification - Follow one permitted same-policy redirect. - Redirect toward an internal fixture address and assert it is blocked before connection. Deliverables - Redirect policy and credential-stripping regression Rollout and recovery: Enable bounded redirect handling; disable redirect support if a client bypasses target validation. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-105 — Enforce byte and time limits while streaming imported documents **Task · Medium priority · Advanced** noCV practice brief v5 · AFETCH-105 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound remote work. Depends on: AFETCH-104. Difficulty: Advanced. Estimated focused work: 180 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 declares a small Content-Length but streams indefinitely, occupying a worker slot. Acceptance criteria - Bound actual streamed bytes regardless of headers. - Enforce connect, idle and overall deadlines. - Cancel the upstream stream and remove incomplete staging objects on failure. Implementation constraints - Choose explicit local test budgets and an injectable clock. Verification - Import a document within the declared byte and deadline limits. - Stream beyond the byte cap or stall and verify cancellation plus cleanup. Deliverables - Bounded stream adapter and timeout fixtures Rollout and recovery: Canary small imports; lower admitted limits while investigating failures. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-106 — Validate document type from bytes before publishing the import **Task · Medium priority · Intermediate** noCV practice brief v5 · AFETCH-106 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound remote work. Depends on: AFETCH-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. A remote server labels an executable-looking payload as text and the importer publishes it under a trusted document type. Acceptance criteria - Allow a declared finite set of document formats. - Check supported signatures and parser outcomes against claimed type. - Keep mismatched or malformed content quarantined. Implementation constraints - Do not execute imported content or trust file extensions. Verification - Import valid synthetic text and supported document bytes. - Mismatch content type and bytes and verify no published object. Deliverables - Format gate and mismatch cases Rollout and recovery: Gate new imports before publication; retain quarantined bytes under restricted retention. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-107 — Make interrupted document fetch retries preserve one import identity **Story · Medium priority · Expert** noCV practice brief v5 · AFETCH-107 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound remote work. Depends on: AFETCH-105, AFETCH-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · Security 30% · 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. A response drops after storage completes; retry publishes a second document with a different identity. Acceptance criteria - Use a stable import command identity and staged object generation. - Publish at most one completed object per command. - Changed URL or policy version under the same key conflicts. Implementation constraints - Persist publication and completion state atomically. Verification - Drop the response after publication and retry to the same import. - Interrupt a stream and verify its incomplete generation cannot be published. Deliverables - Idempotent import completion and fault probe Rollout and recovery: Canary one synthetic tenant; stop completion and inspect staging generations on inconsistency. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. ### Validate abuse resistance Reproduce failures and preserve safe diagnostics. #### AFETCH-108 — Remove query secrets from document-fetch error messages **Bug · High priority · Foundational** noCV practice brief v5 · AFETCH-108 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate abuse resistance. Depends on: AFETCH-104, AFETCH-107. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy 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 signed download URL appears in an operator error message after a timeout. Acceptance criteria - Log safe origin, import ID and failure code only. - Strip query, fragment and user information from diagnostics. - Keep provider errors from bypassing the safe projection. Implementation constraints - Use fabricated signed URLs in tests. Verification - Trace a timeout by import ID. - Inject secret-like query values into redirect and timeout errors and assert absence. Deliverables - Fetch diagnostic sanitizer Rollout and recovery: Deploy safe diagnostics before broad imports; restrict older error records. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-109 — Build a regression matrix for document-fetch trust-boundary failures **Chore · Medium priority · Expert** noCV practice brief v5 · AFETCH-109 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate abuse resistance. Depends on: AFETCH-103, AFETCH-104, AFETCH-105, AFETCH-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Quality engineering 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. The fetcher has individual guards, but a client upgrade could bypass a guard only when redirects, DNS and retries combine. Acceptance criteria - Cover composed resolver, redirect, size and cancellation cases. - Assert forbidden connection attempts and publication calls remain zero. - Record expected failure codes without claiming universal attack coverage. Implementation constraints - All network behavior runs through local controlled adapters. Verification - Run an allowed redirected import through the complete pipeline. - Combine redirect with resolution change and oversized body; stop at the earliest applicable guard. Deliverables - Adversarial fixture matrix and regression command Rollout and recovery: Require the matrix for client upgrades; pin the last passing client revision if failures appear. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. #### AFETCH-110 — Document the exception process for a newly requested document host **Task · Medium priority · Foundational** noCV practice brief v5 · AFETCH-110 · Constrain a server-side document fetcher Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate abuse resistance. Depends on: AFETCH-102, AFETCH-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. Support wants to unblock a customer's host quickly without permanently disabling destination checks. Acceptance criteria - Request a tenant-scoped host and purpose. - Record policy version, reviewer and expiry for any exception. - Retain all address, redirect and byte controls. Implementation constraints - Use a fictional host; no live allowlist modification is part of this ticket. Verification - Review a complete scoped exception example. - Reject a wildcard destination request that bypasses address policy. Deliverables - Host exception template and worked review Rollout and recovery: Use the template for policy proposals; expire exceptions rather than widening global defaults. Project prerequisites: Build a local fetch adapter and controlled HTTP test servers. Use synthetic documents and deny network access outside the test allowlist. Engineer value: Practice defensive URL handling and bounded untrusted-input processing. Company value: Review whether integrations can import content without expanding infrastructure access. 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. ## AAUDIT — Make privileged support actions inspectable A fictional support console can reveal protected account settings and run repairs. The team needs bounded elevation, clear reasons and durable records of what happened. **Field:** Security. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice privileged workflows, denial paths and audit integrity. **Company value:** Review accountable support operations without unnecessary access to customer data. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic support actors and organizations. - Implement a local authorization boundary and append-only audit store. ### Constrain elevated access Define permission, purpose and expiry. #### AAUDIT-101 — List support actions with required permission and disclosure level **Task · Medium priority · Foundational** noCV practice brief v5 · AAUDIT-101 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Support agents share an admin role because nobody has separated read diagnostics from account-changing actions. Acceptance criteria - Classify each action by permission and exposed fields. - Default unknown actions to denied. - Keep read-only diagnostics separate from mutation authority. Implementation constraints - Use six concrete fictional support actions. Verification - Map an allowed diagnostic read to its minimal permission. - Attempt an unlisted action and deny it before data access. Deliverables - Support permission matrix Rollout and recovery: Review the matrix before enabling new actions; retain unknown operations as disabled. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-102 — Require a bounded purpose record before support elevation **Story · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-102 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: AAUDIT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · 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. An agent opens account settings using permanent elevated access with no connection to a support case. Acceptance criteria - Record target organization, permitted actions, reason and expiry. - Require an authorized actor to request elevation. - Reject empty purpose or an excessive lifetime. Implementation constraints - Use synthetic case references without copying case conversations. Verification - Create a scoped time-limited elevation. - Request a different organization's action outside the grant and deny it. Deliverables - Elevation request contract Rollout and recovery: Canary grants for synthetic actors; revoke active test grants if policy checks fail. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-103 — Remove sensitive account fields from ordinary support search **Bug · High priority · Foundational** noCV practice brief v5 · AAUDIT-103 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: AAUDIT-101, AAUDIT-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Searching by account ID returns confidential settings before the agent opens an elevated support session. Acceptance criteria - Ordinary search returns an explicit minimal projection. - Protected details require the exact active grant. - Denied search responses do not reveal account existence across scope. Implementation constraints - Define response schemas at the service boundary. Verification - Find an account using permitted safe fields. - Search outside scope and inspect response and logs for protected fields. Deliverables - Minimal support search projection Rollout and recovery: Deploy projection before elevation rollout; disable broad debug search endpoints. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. ### Guard privileged mutations Bind changes to reviewed scope and durable records. #### AAUDIT-104 — Reauthorize elevation immediately before a support repair commits **Bug · High priority · Advanced** noCV practice brief v5 · AAUDIT-104 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-102, AAUDIT-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Database 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. An agent starts a repair, loses access, then the pending request commits using the authorization decision from several minutes earlier. Acceptance criteria - Reload actor and grant authority in the mutation transaction. - Check target scope, permitted operation and expiry. - Revoked or expired grants leave domain state unchanged. Implementation constraints - Use controlled barriers to model revocation between read and commit. Verification - Commit a repair under an active matching grant. - Revoke at the barrier and verify rollback with no repair effect. Deliverables - Commit-boundary authorization guard Rollout and recovery: Canary the guard on synthetic repairs; disable repair writes if authorization freshness fails. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-105 — Commit privileged repair state and its audit fact together **Task · Medium priority · Advanced** noCV practice brief v5 · AAUDIT-105 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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 repair succeeds while the audit insert fails, leaving an unrecorded privileged change. Acceptance criteria - Persist repair and audit fact in one transaction. - Audit captures actor, grant, action and safe target identity. - Audit failure rolls back the repair. Implementation constraints - Keep payload contents and secrets out of the audit record. Verification - Commit a synthetic repair and inspect one matching audit fact. - Force audit persistence failure and verify unchanged domain state. Deliverables - Atomic repair audit and failure test Rollout and recovery: Deploy transactional writes before exposing repairs; stop mutation if audit storage is unavailable. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-106 — Make support repair commands replay-safe without repeating side effects **Story · Medium priority · Expert** noCV practice brief v5 · AAUDIT-106 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Backend 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 console retries a repair after a timeout, generating a second account reset and confusing the support trail. Acceptance criteria - Bind idempotency to actor, grant, target and operation input. - Return the original result for identical retries. - Reject changed parameters under the same key. Implementation constraints - Audit the logical operation once and retain safe retry observations separately. Verification - Lose a post-commit response and retry to one repair. - Reuse the command key for another target and deny it. Deliverables - Idempotent support repair command Rollout and recovery: Canary with disposable accounts; pause conflicting command keys for investigation. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-107 — Expire support grants without relying on a cleanup job **Task · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-107 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-104, AAUDIT-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 delayed cleanup worker leaves expired support sessions usable throughout an outage. Acceptance criteria - Every privileged authorization checks the stored expiry. - Cleanup only archives derived state and cannot extend authority. - Use one documented exact-expiry boundary. Implementation constraints - Use an injected UTC clock at the service boundary. Verification - Authorize a matching action immediately before expiry. - Advance to expiry while cleanup is paused and deny the action. Deliverables - Expiry enforcement and paused-cleanup test Rollout and recovery: Enable boundary checks before cleanup changes; revoke grants if clock assumptions are violated. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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 and recover Inspect events and respond to missing audit coverage. #### AAUDIT-108 — Provide a scoped audit timeline with stable cursor pagination **Story · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-108 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-105, AAUDIT-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · API design 30% · Database 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. Security reviewers need to inspect a repair sequence, but an unbounded audit endpoint times out and exposes unrelated organizations. Acceptance criteria - Filter by authorized organization and bounded time window. - Order by committed sequence with a stable cursor. - Return safe action metadata without repair payloads. Implementation constraints - Reject cursors bound to another scope. Verification - Page a synthetic incident timeline while new events arrive. - Tamper with scope in a cursor and return a nondisclosing denial. Deliverables - Audit timeline endpoint and scope tests Rollout and recovery: Expose read-only timelines to a review role; revoke the route if projection checks fail. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-109 — Detect missing privileged audit coverage using domain references **Chore · Medium priority · Expert** noCV practice brief v5 · AAUDIT-109 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-105, AAUDIT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Quality 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 legacy repair path may still bypass the transactional audit method; reviewers need a precise way to find uncovered changes. Acceptance criteria - Compare privileged operation references with audit identities. - Report missing and contradictory links separately. - Do not invent audit facts for historical gaps. Implementation constraints - Use bounded synthetic data and a read-only reconciliation command. Verification - Reconcile a complete operation history with no gaps. - Remove one audit reference in a fixture and report explicit incomplete coverage. Deliverables - Audit coverage reconciler Rollout and recovery: Run read-only before enabling legacy repair paths; disable uncovered writes until corrected. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-110 — Rehearse termination of an active support elevation incident **Task · Medium priority · Foundational** noCV practice brief v5 · AAUDIT-110 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-107, AAUDIT-108, AAUDIT-109. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A fictional support account is suspected of misuse while one elevated request is still running. Acceptance criteria - Runbook revokes grants and checks in-flight commit protection. - Preserve immutable audit facts and record coverage limits. - Verify ordinary support access remains scoped after containment. Implementation constraints - Use only synthetic actors and repairs. Verification - Contain an active grant and verify later actions are denied. - Pause a repair before commit, revoke authority, and confirm no mutation completes. Deliverables - Support containment runbook and drill trace Rollout and recovery: Rehearse locally before release; keep repairs disabled if containment cannot be verified. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. ## ABOUND — Design an isolated document-processing boundary A fictional procurement portal extracts metadata from uploaded documents. Product wants a responsive upload flow; security wants parser failures isolated from customer-facing processes. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, HTTP, Provider interfaces. **Engineer value:** Practice boundary decisions backed by executable consistency and failure checks. **Company value:** Review architecture tradeoffs with explicit assumptions before infrastructure commitment. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic upload metadata and a fake processing provider. - Treat diagrams as proposals; implement only local contract probes. ### Frame the boundary Define workload, authority and state ownership. #### ABOUND-101 — Translate document-processing expectations into a bounded workload model **Task · Medium priority · Foundational** noCV practice brief v5 · ABOUND-101 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Performance 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. A design request says uploads should be instant but does not separate transfer time from extraction completion. Acceptance criteria - Define upload acceptance and extraction completion separately. - State hypothetical size, arrival and concurrency assumptions. - List unresolved product constraints with owners. Implementation constraints - Use a synthetic scenario of 2 MiB median and 20 MiB maximum documents; label it an assumption. Verification - Calculate transfer time under two named bandwidth assumptions. - Show how a maximum-size document changes the completion budget. Deliverables - Workload worksheet and clarified latency definitions Rollout and recovery: Review assumptions before design approval; revise the worksheet when constraints change. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-102 — Draw the document trust boundary with authoritative state owners **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-102 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. Depends on: ABOUND-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 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. The first sketch lets the API parse uploaded documents and write arbitrary worker status into the upload row. Acceptance criteria - Identify storage, API, coordinator and isolated parser boundaries. - Assign one owner to each lifecycle transition. - Mark untrusted bytes and privileged credentials on data flows. Implementation constraints - Parsing belongs behind an explicit isolated provider; no candidate code runs in product processes. Verification - Trace a valid upload through every boundary. - Trace a malformed document and show that parser failure cannot mutate API memory. Deliverables - Trust-boundary diagram and state-ownership table Rollout and recovery: Review the boundary before implementation; reject paths that collapse isolation. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-103 — Write the decision record for direct-to-storage document upload **Task · Medium priority · Foundational** noCV practice brief v5 · ABOUND-103 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. Depends on: ABOUND-101, ABOUND-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Storage systems 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 is choosing whether large document bytes should pass through the API or go directly to controlled object storage. Acceptance criteria - Compare bandwidth, authorization and retry responsibilities. - Specify capability scope, expiry and finalization checks. - Name conditions that would justify revisiting the choice. Implementation constraints - Use a provider-neutral capability contract and hypothetical costs. Verification - Trace a successful capability upload and verified finalization. - Trace expired capability and changed-object cases without accepting an unverified document. Deliverables - Upload architecture decision record Rollout and recovery: Review the decision with a local capability fixture; defer provider rollout until its checks exist. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. ### Specify the interactions Make contracts and failure semantics executable. #### ABOUND-104 — Specify a document lifecycle that survives parser retries **Story · Medium priority · Advanced** noCV practice brief v5 · ABOUND-104 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-102, ABOUND-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. A retry currently moves a completed document back to processing because delivery events are mistaken for authoritative transitions. Acceptance criteria - Define legal transitions and terminal-state behavior. - Bind processing attempts to one immutable upload generation. - Reject stale provider completion for a replaced generation. Implementation constraints - Express the transition table as executable tests against a small pure model. Verification - Replay valid completion twice and retain one terminal result. - Deliver an older generation result after replacement and reject it. Deliverables - State model and transition probes Rollout and recovery: Use the model to gate implementation review; create a new model version for changed semantics. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-105 — Design the transactional dispatch contract for extraction work **Task · Medium priority · Advanced** noCV practice brief v5 · ABOUND-105 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · Database 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. An accepted upload can be stranded if the API commits metadata and crashes before calling the processing provider. Acceptance criteria - Commit upload acceptance and an outbox fact together. - Derive a deterministic dispatch identity from the accepted generation. - Specify claim, retry and duplicate-delivery behavior. Implementation constraints - Use PostgreSQL plus a local provider fake, without adding a broker topology. Verification - Crash after transaction commit and recover dispatch from the outbox. - Repeat provider delivery and prove one accepted completion. Deliverables - Outbox contract and interruption probe Rollout and recovery: Prototype on synthetic uploads; halt new acceptance if durable dispatch cannot be recorded. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-106 — Define extraction-provider deadlines and uncertain completion semantics **Task · Medium priority · Expert** noCV practice brief v5 · ABOUND-106 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104, ABOUND-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Distributed systems 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 provider times out after accepting work; blindly retrying may launch duplicate expensive processing. Acceptance criteria - Separate rejected, accepted, completed and unknown outcomes. - Use an idempotent provider request identity and status lookup. - Define bounded retry and operator-visible unresolved states. Implementation constraints - Model uncertain responses explicitly rather than interpreting timeout as failure. Verification - Timeout after acceptance and reconcile by request identity. - Return an unresolved status until the deadline and keep completion unclaimed. Deliverables - Provider contract and uncertainty state probe Rollout and recovery: Use the fake provider to validate behavior; fail closed when a real adapter lacks required identity guarantees. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-107 — Choose the read model for pending document status **Story · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-107 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104, ABOUND-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 30% · Real-time 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. Product wants frequent status updates, but the proposal polls the external parser on every customer request. Acceptance criteria - Serve status from authorized durable local state. - Specify freshness and pending-state wording. - Compare bounded polling and push updates under the assumed workload. Implementation constraints - Keep raw parser diagnostics outside customer projections. Verification - Read one pending and one completed document through the local model. - Request another tenant's document and verify no provider lookup occurs. Deliverables - Read-model decision and scoped contract probe Rollout and recovery: Prototype the local status route; retain polling until push delivery has a measured need. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. ### Challenge the design Test alternatives, failure modes and migration steps. #### ABOUND-108 — Estimate document backlog growth during a provider outage **Task · Medium priority · Expert** noCV practice brief v5 · ABOUND-108 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-101, ABOUND-105, ABOUND-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System design 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. The design has no answer for how long a backlog takes to drain after the parser is unavailable for an hour. Acceptance criteria - Calculate arrivals, stored bytes and queued work during outage. - Model recovery with explicit service-time and concurrency assumptions. - Identify when admission must slow or stop. Implementation constraints - Use a spreadsheet or executable script with hypothetical values, not invented measurements. Verification - Calculate backlog for the declared baseline assumptions. - Increase arrival rate above recovery capacity and show the queue does not drain. Deliverables - Capacity model and outage sensitivity script Rollout and recovery: Use the model to set a reviewed admission proposal; revise with real measurements before production sizing. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-109 — Compare synchronous and asynchronous extraction against the same failure cases **Task · Medium priority · Advanced** noCV practice brief v5 · ABOUND-109 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-103, ABOUND-106, ABOUND-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · 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. Stakeholders disagree about queueing because one alternative is evaluated only on its happy path. Acceptance criteria - Compare both alternatives under identical workload assumptions. - Include timeout, duplicate request and parser isolation cases. - Record accepted tradeoffs and rejected assumptions. Implementation constraints - A decision matrix must link to the already-created local probes. Verification - Score each alternative against documented correctness requirements. - Demonstrate the case where synchronous processing exceeds the request deadline. Deliverables - Alternative comparison and reviewed decision record Rollout and recovery: Use the comparison for architecture review; revisit when workload or provider guarantees change. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-110 — Plan a reversible migration from inline document parsing **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-110 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-105, ABOUND-107, ABOUND-109. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Platform engineering 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. An existing local prototype parses in its request handler; the team needs an incremental path to the agreed boundary. Acceptance criteria - Sequence durable metadata, dispatch and status-reader changes. - Define comparison checkpoints and rollback boundaries. - Keep uploaded bytes and completed results bound to original generations. Implementation constraints - Only local prototype migration is in scope; do not provision production execution. Verification - Walk a synthetic upload through each migration stage. - Rollback before activation and show existing completed documents remain readable. Deliverables - Migration plan and staged local walkthrough Rollout and recovery: Move one synthetic route at a time; pause migration when old and new status projections disagree. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. ## AREGION — Design regional reads without promising impossible failover A fictional logistics dashboard serves distant customers from one primary region. Stakeholders want faster reads and outage recovery but have not agreed which data may be stale. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice consistency tradeoffs, failover authority and recovery assumptions. **Company value:** Review regional availability proposals with explicit data-loss and staleness limits. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local primary/replica simulator and synthetic shipment records. - Use local models; no multi-region infrastructure is provisioned. ### Classify regional behavior Define which reads and writes need freshness. #### AREGION-101 — Classify shipment reads by tolerated staleness **Task · Medium priority · Foundational** noCV practice brief v5 · AREGION-101 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Distributed systems 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 regional-read proposal treats a public tracking estimate and an address-change confirmation as equally cacheable. Acceptance criteria - List read classes with explicit hypothetical freshness limits. - Require fresh authority for security and mutation confirmation. - Document unknown product requirements separately. Implementation constraints - Use a synthetic status timeline with version numbers. Verification - Assign a declared budget to public tracking. - Show why address-change confirmation needs its accepted version. Deliverables - Read-consistency matrix Rollout and recovery: Review the matrix before routing changes; leave unresolved classes on primary reads. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-102 — Calculate regional latency contributions with stated assumptions **Task · Medium priority · Intermediate** noCV practice brief v5 · AREGION-102 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: AREGION-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System 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. A proposal promises a faster dashboard without separating network time, database time and sequential request dependencies. Acceptance criteria - Break one page load into serial and parallel operations. - Use named hypothetical network and service-time values. - Show sensitivity to an additional cross-region round trip. Implementation constraints - Label every unmeasured input as an assumption. Verification - Calculate two routes with the same service-time assumptions. - Add a required primary check and show its effect on the budget. Deliverables - Latency worksheet and dependency diagram Rollout and recovery: Use the calculation to prioritize probes; replace assumptions with observations before choosing deployment. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-103 — Record the decision between regional caching and replica reads **Task · Medium priority · Foundational** noCV practice brief v5 · AREGION-103 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: AREGION-101, AREGION-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Database engineering 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. The team jumps to database replicas when a scoped cache might cover the tolerated-staleness tracking view. Acceptance criteria - Compare invalidation, freshness, failure and operational costs. - Keep sensitive and read-after-write paths explicit. - Name a workload or consistency change that revisits the choice. Implementation constraints - Do not assume an additional region is free or already configured. Verification - Evaluate both options against one tracking read. - Evaluate an authorization change and reject an option that cannot enforce it. Deliverables - Regional-read architecture decision Rollout and recovery: Review using the consistency matrix; implement only the smallest local prototype selected. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. ### Specify routing authority Make routing, failover and retry contracts testable. #### AREGION-104 — Define a read-after-write token for shipment changes **Story · Medium priority · Advanced** noCV practice brief v5 · AREGION-104 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-101, AREGION-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 user changes a delivery note, then a regional read immediately shows the previous text. Acceptance criteria - Mutation returns an accepted version token. - A subsequent read must meet that version or use a fresh source. - Tokens are bound to tenant and resource. Implementation constraints - Implement a small local routing model, not a new replication engine. Verification - Write version 4 while the replica has version 3 and route correctly. - Reuse another tenant's token and reject it without exposing state. Deliverables - Read-version contract and routing tests Rollout and recovery: Canary the routing model in a local client; fall back to primary reads when freshness cannot be established. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-105 — Fence regional write authority before promoting a standby **Task · High priority · Expert** noCV practice brief v5 · AREGION-105 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 outage runbook says promote the standby but never explains how the unreachable former primary loses authority. Acceptance criteria - Define one durable authority epoch and promotion preconditions. - Reject commands using an old epoch. - Describe the availability tradeoff when fencing cannot be confirmed. Implementation constraints - Use a local two-writer model; do not claim split-brain prevention without enforced fencing. Verification - Promote a new epoch and accept only the new writer. - Let the old writer recover and reject its stale-epoch command. Deliverables - Failover authority protocol and fencing probe Rollout and recovery: Require the probe before any real failover procedure; refuse promotion when authority is ambiguous. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-106 — Preserve command identity across a regional routing retry **Task · Medium priority · Advanced** noCV practice brief v5 · AREGION-106 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-104, AREGION-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · System design 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. A gateway retries an update in another region after losing the response, potentially applying the shipment change twice. Acceptance criteria - Use a stable command key across routing attempts. - Bind the key to target, actor and canonical input. - Return unknown until committed status can be resolved safely. Implementation constraints - Do not infer an absent commit from a connection timeout. Verification - Lose the response after commit and resolve one logical change. - Change input under the same key and return conflict. Deliverables - Cross-route command contract and timeout probe Rollout and recovery: Use the contract in the local gateway prototype; suspend retries if deduplication authority is unavailable. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-107 — Define regional fallback for unavailable authorization freshness **Task · Medium priority · Advanced** noCV practice brief v5 · AREGION-107 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-101, AREGION-105, AREGION-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System 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. A regional endpoint can read cached shipment data but cannot confirm whether the requesting account's access was revoked. Acceptance criteria - Separate data freshness from authorization freshness. - Deny protected reads when required authority is unavailable. - Keep public tracking behavior separately bounded by its policy. Implementation constraints - Model access revocation with synthetic identities. Verification - Serve a permitted public tracking response during primary loss. - Revoke a protected reader and verify the regional route does not use stale permission. Deliverables - Authorization fallback matrix and denial probe Rollout and recovery: Keep protected reads on fresh authority until the regional adapter meets the contract. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. ### Challenge recovery promises Model outages and reconcile divergent observations. #### AREGION-108 — Model recovery-point and recovery-time limits for a regional outage **Task · Medium priority · Expert** noCV practice brief v5 · AREGION-108 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-102, AREGION-105, AREGION-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · System 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. A stakeholder asks for zero data loss and immediate recovery even when replication is asynchronous and the primary is unreachable. Acceptance criteria - Define what RPO and RTO mean for the chosen workload. - Calculate loss and recovery bounds from explicit lag and detection assumptions. - Identify guarantees the design cannot currently provide. Implementation constraints - Use hypothetical numbers and separate targets from measured results. Verification - Calculate the declared outage scenario with bounded lag. - Remove the lag bound and show that a finite loss guarantee is unsupported. Deliverables - Recovery objectives worksheet Rollout and recovery: Review targets before infrastructure approval; revise guarantees when provider constraints differ. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-109 — Reconcile divergent regional observations after connectivity returns **Task · Medium priority · Intermediate** noCV practice brief v5 · AREGION-109 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-104, AREGION-105, AREGION-108. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · System design 30% · Data 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. Support receives screenshots with different shipment states after an outage and needs to explain which accepted version is authoritative. Acceptance criteria - Compare accepted command versions and authority epochs. - Preserve stale observations as observations, not new writes. - Flag missing authoritative history as unresolved. Implementation constraints - Build a read-only synthetic reconciliation report. Verification - Reconcile two observed versions against the accepted command log. - Remove an authority segment and report an explicit gap. Deliverables - Regional reconciliation script Rollout and recovery: Run read-only after the local outage drill; avoid repair writes until authority is resolved. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-110 — Write the staged regional-read adoption and rollback plan **Chore · Medium priority · Foundational** noCV practice brief v5 · AREGION-110 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-103, AREGION-107, AREGION-109. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 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. The architecture review approves a limited regional tracking view, but the rollout ticket still says switch all traffic. Acceptance criteria - Start with the approved read class and synthetic cohort. - Define freshness and denial checks before wider routing. - Rollback by restoring primary routing without rewriting accepted data. Implementation constraints - Include unresolved dependencies as explicit blockers. Verification - Walk a permitted tracking request through the proposed rollout. - Trigger stale authorization and verify protected traffic stays on the declared safe path. Deliverables - Regional adoption plan and decision checklist Rollout and recovery: Review the plan with the local simulator; retain a primary-routing override for recovery. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. ## ANOTIFY — Design notification delivery around preferences and receipts A fictional collaboration tool sends email and in-app notifications. Duplicate alerts and preference changes reveal that the design has no single definition of delivery. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, Provider interfaces. **Engineer value:** Practice asynchronous contracts, preference timing and delivery uncertainty. **Company value:** Review a notification design that controls nuisance, disclosure and recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic recipients, events and fake delivery providers. - Do not send real email or messages. ### Define communication intent Identify recipients, semantics and privacy boundaries. #### ANOTIFY-101 — Separate notification intent from channel delivery and human receipt **Task · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-101 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Backend 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. Product labels a notification delivered when an email provider accepts it, though no human receipt is observed. Acceptance criteria - Define intent, attempted, provider-accepted and observed-read states. - Keep channel-specific facts separate. - Avoid claiming reading from provider acceptance. Implementation constraints - Use synthetic provider receipts and explicit unknown states. Verification - Map an accepted email and an opened in-app item separately. - Timeout the provider and retain unknown delivery rather than sent. Deliverables - Notification semantics table Rollout and recovery: Adopt precise status labels in the prototype; preserve uncertain older observations. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-102 — Specify recipient resolution without copying event payloads broadly **Task · Medium priority · Intermediate** noCV practice brief v5 · ANOTIFY-102 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: ANOTIFY-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 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 event producer includes every collaborator's contact details so downstream handlers can decide recipients. Acceptance criteria - Resolve recipients through a scoped authority boundary. - Keep generic event payloads to opaque identifiers. - Authorize recipient access before creating a channel attempt. Implementation constraints - Use synthetic addresses and a dedicated contact provider fake. Verification - Resolve members of the correct synthetic workspace. - Request recipients across workspaces and produce no channel attempts. Deliverables - Recipient-resolution contract Rollout and recovery: Review the contract before broad event publication; quarantine events without valid scope. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-103 — Choose when notification preferences are evaluated **Task · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-103 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define communication intent. Depends on: ANOTIFY-101, ANOTIFY-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Privacy engineering 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. A user opts out after an event is queued but still receives the email, and the team has no documented policy. Acceptance criteria - Compare preference-at-intent and preference-at-send semantics. - Choose and document behavior for opt-out and critical notices. - Define how a changed preference version affects queued work. Implementation constraints - Do not silently invent a legal or mandatory-notice requirement. Verification - Trace an opt-out between event and send. - Trace a missing preference record under the declared default policy. Deliverables - Preference-timing architecture decision Rollout and recovery: Review with product before adapter work; keep unresolved categories unsent. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. ### Specify delivery contracts Handle preference changes, retries and provider uncertainty. #### ANOTIFY-104 — Model notification intent and dispatch in one durable transaction **Story · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-104 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-102, ANOTIFY-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · Database 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 collaboration action commits but crashes before queue publication, so some recipients never receive an alert. Acceptance criteria - Persist domain reference and notification intent atomically. - Use an outbox fact with deterministic intent identity. - Make repeated event delivery resolve the same logical intent. Implementation constraints - Keep intent creation inside the existing modular application boundary. Verification - Crash after action commit and replay the outbox to one intent. - Repeat the originating event and verify no duplicate recipient intent. Deliverables - Intent/outbox model and interruption probe Rollout and recovery: Use a local provider fake initially; pause originating notifications if intent persistence fails. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-105 — Design per-channel attempt identity and provider reconciliation **Task · Medium priority · Expert** noCV practice brief v5 · ANOTIFY-105 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-101, ANOTIFY-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 email provider times out after accepting a request; retrying blindly sends the same message twice. Acceptance criteria - Bind each logical channel delivery to a stable provider key. - Represent unknown acceptance and define a status lookup path. - Document provider limitations that prevent exactly-once claims. Implementation constraints - The local fake must support accepted-but-response-lost behavior. Verification - Reconcile lost response to one accepted synthetic delivery. - Use a provider without lookup support and retain an explicit uncertain state. Deliverables - Channel contract and uncertainty probe Rollout and recovery: Select adapters only after contract review; stop automatic retries where duplicate risk is unresolved. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-106 — Bound notification fan-out without creating one huge transaction **Task · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-106 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-102, ANOTIFY-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 30% · 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. One workspace event targets 50,000 hypothetical members and the proposed transaction attempts to create every delivery row at once. Acceptance criteria - Specify bounded recipient pages and stable page checkpoints. - Preserve one logical intent per recipient across retries. - Define membership snapshot versus live-membership semantics. Implementation constraints - Use a synthetic membership generator with documented cardinality. Verification - Process a 1,000-recipient local sample in fixed-size pages. - Interrupt a page and resume without duplicate recipient intents. Deliverables - Fan-out plan and checkpoint prototype Rollout and recovery: Validate with local samples before wider scale assumptions; pause dispatch while keeping checkpoints. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-107 — Keep in-app notification reads separate from email provider state **Story · Medium priority · Intermediate** noCV practice brief v5 · ANOTIFY-107 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify delivery contracts. Depends on: ANOTIFY-101, ANOTIFY-105, ANOTIFY-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. Marking an in-app alert read currently suppresses an unrelated email retry by changing one shared status column. Acceptance criteria - Model channel delivery and in-app acknowledgement separately. - Bind acknowledgement to the authenticated recipient. - Preserve delivery-attempt history after acknowledgement. Implementation constraints - Use an explicit read model for the in-app feed. Verification - Mark one in-app item read and retain email attempt state. - Acknowledge another recipient's item and reject it. Deliverables - Read-model contract and channel-isolation probe Rollout and recovery: Prototype the read model behind a local route; revert read wiring without changing delivery history. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. ### Validate operating behavior Model load and rehearse recovery without real messaging. #### ANOTIFY-108 — Calculate notification drain time under a channel rate limit **Task · Medium priority · Expert** noCV practice brief v5 · ANOTIFY-108 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-105, ANOTIFY-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System design 30% · Integrations 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 launch generates a burst of alerts, but the architecture plan ignores provider quotas and retry traffic. Acceptance criteria - Model initial backlog, arrival rate and provider throughput. - Reserve capacity for retries within a bounded budget. - Show conditions where backlog cannot drain. Implementation constraints - Use explicitly hypothetical rates and an executable calculation. Verification - Calculate drain time for a named burst and fixed delivery rate. - Raise arrivals above capacity and report unbounded growth instead of a finite answer. Deliverables - Capacity calculator and quota assumptions Rollout and recovery: Use results to propose admission and batching limits; replace assumptions before real rollout. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-109 — Exercise preference revocation during a notification backlog **Task · Medium priority · Advanced** noCV practice brief v5 · ANOTIFY-109 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-103, ANOTIFY-105, ANOTIFY-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Privacy engineering 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. A user disables a channel while thousands of queued intents wait for provider quota, exposing ambiguous preference timing. Acceptance criteria - Apply the chosen preference-timing policy consistently. - Record suppressed versus attempted outcomes without contact details. - Keep already accepted provider facts immutable. Implementation constraints - Use a local backlog and fake provider; send no real messages. Verification - Change preferences before a queued intent reaches its decision boundary. - Change preferences after provider acceptance and preserve the accepted fact without claiming recall. Deliverables - Backlog preference drill and outcome trace Rollout and recovery: Run before adapter approval; suspend the affected category if policy and implementation diverge. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. #### ANOTIFY-110 — Document notification architecture limits for stakeholder review **Chore · Medium priority · Foundational** noCV practice brief v5 · ANOTIFY-110 · Design notification delivery around preferences and receipts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate operating behavior. Depends on: ANOTIFY-105, ANOTIFY-108, ANOTIFY-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Integrations 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 launch plan describes exactly-once delivery and confirmed readership even though the provider contract supports neither. Acceptance criteria - List supported guarantees and unresolved provider dependencies. - Link each guarantee to a contract or local probe. - Include retry suspension and backlog recovery decisions. Implementation constraints - State that local tests do not prove real provider delivery. Verification - Trace an accepted guarantee to its executable probe. - Identify an unsupported receipt claim and replace it with the observed state. Deliverables - Notification design review packet Rollout and recovery: Review the packet before provider rollout; revise claims when adapter evidence changes. Project prerequisites: Create synthetic recipients, events and fake delivery providers. Do not send real email or messages. Engineer value: Practice asynchronous contracts, preference timing and delivery uncertainty. Company value: Review a notification design that controls nuisance, disclosure and recovery. 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. ## AARCHIVE — Design a searchable audit archive with retention boundaries A fictional procurement platform keeps append-only action records. Operators want fast recent search and affordable old records without losing provenance or leaking tenant data. **Field:** System design. **Suggested stack:** PostgreSQL, Object storage, TypeScript. **Engineer value:** Practice storage tradeoffs, provenance and data-lifecycle decisions. **Company value:** Review archive cost and retrieval guarantees before committing to infrastructure. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic audit events and local storage/search adapters. - Use an explicit fictional retention policy, not legal advice. ### Define archive guarantees Specify access, retention and search expectations. #### AARCHIVE-101 — Define which audit questions require indexed search versus archive retrieval **Task · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-101 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Storage systems 20% · Database 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. The design says all audit history must be instantly searchable, but reviewers usually inspect the last week and rarely retrieve older cases. Acceptance criteria - List recent search and older retrieval use cases separately. - State hypothetical latency and date-range targets. - Identify fields that may be indexed without exposing payload contents. Implementation constraints - Use fabricated events and a named review workflow. Verification - Map a recent actor search to its target. - Map an old case retrieval to the declared slower path without claiming instant search. Deliverables - Archive access-pattern inventory Rollout and recovery: Review the inventory before choosing storage; keep unapproved fields out of indexes. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-102 — Calculate archive storage growth from event size and retention assumptions **Task · Medium priority · Intermediate** noCV practice brief v5 · AARCHIVE-102 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: AARCHIVE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Storage systems 30% · Cloud infrastructure 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 budget proposal counts raw event bytes but omits index, replica and manifest overhead. Acceptance criteria - Model events per day, average bytes and retention duration. - Show raw, index and redundancy components separately. - Label compression and growth factors as assumptions. Implementation constraints - Provide a small executable worksheet with no claimed measured savings. Verification - Calculate the baseline synthetic scenario. - Double event volume and vary compression to show sensitivity. Deliverables - Storage-growth model Rollout and recovery: Use the model for a reviewed budget proposal; update it after real storage measurements. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-103 — Choose hot and cold archive boundaries with a reviewable decision record **Task · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-103 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: AARCHIVE-101, AARCHIVE-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Database engineering 30% · Storage 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. The team proposes a new search cluster before checking whether bounded PostgreSQL search and object retrieval satisfy the workload. Acceptance criteria - Compare existing database search with a separate index option. - Include consistency, operational and restore costs. - Choose the smallest option meeting the stated requirements. Implementation constraints - Do not provision speculative infrastructure for this design exercise. Verification - Evaluate both options against recent and old queries. - Identify the threshold or query need that would reopen the decision. Deliverables - Archive storage decision record Rollout and recovery: Review the decision against the workload model before implementing new infrastructure. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. ### Model archive boundaries Make manifests, indexing and retrieval verifiable. #### AARCHIVE-104 — Define an immutable archive segment manifest **Task · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-104 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · System design 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. An exported audit file has no trusted count or content identity, so operators cannot tell whether a partial upload is complete. Acceptance criteria - Manifest binds segment ID, record count, range and byte hash. - Publish a segment only after verifying its stored identity. - Retain original event identifiers across archival. Implementation constraints - Use canonical synthetic serialization and exact object versions. Verification - Archive and verify a complete segment. - Truncate bytes or alter count and reject publication. Deliverables - Segment contract and integrity probe Rollout and recovery: Prototype manifests alongside synthetic exports; keep unverified segments out of search. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-105 — Specify search indexing as a rebuildable projection of archived events **Story · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-105 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Data engineering 30% · Database 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 search result is edited directly to correct an event, creating a version of history absent from the source archive. Acceptance criteria - Treat the index as a projection with source segment identity. - Corrections append new events rather than rewrite archived facts. - Define checkpoint and duplicate-indexing semantics. Implementation constraints - Use an in-memory search adapter for the contract probe. Verification - Rebuild the index from named manifests and preserve event identities. - Replay a segment and verify no duplicate search records. Deliverables - Index projection model and replay test Rollout and recovery: Build a shadow index generation; switch only after source-count reconciliation. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-106 — Authorize archive retrieval before issuing object capabilities **Task · High priority · Expert** noCV practice brief v5 · AARCHIVE-106 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-104, AARCHIVE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System design 30% · Storage 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. An audit search hit contains a raw object key; clients can request other tenants' segments by changing that key. Acceptance criteria - Resolve event and segment within the caller's authorized tenant. - Issue a capability scoped to the exact object version. - Avoid exposing neighboring events through shared-segment retrieval. Implementation constraints - Choose per-tenant segments or a server-side filtered retrieval contract. Verification - Retrieve a permitted synthetic event through the chosen boundary. - Alter tenant or segment identity and verify no capability is issued. Deliverables - Archive access contract and cross-tenant probe Rollout and recovery: Keep raw objects private; enable retrieval only after the projection isolation checks pass. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-107 — Define archive query pagination across hot and cold boundaries **Story · Medium priority · Intermediate** noCV practice brief v5 · AARCHIVE-107 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-103, AARCHIVE-105, AARCHIVE-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Database engineering 30% · Storage 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. A query spanning the archive cutoff repeats recent events and misses records moved between stores during pagination. Acceptance criteria - Bind the cursor to a declared snapshot or generation. - Specify stable ordering and deduplication by event identity. - Return explicit partial or unavailable states for missing segments. Implementation constraints - Model movement with local fixtures rather than live archive jobs. Verification - Page across a cutoff while a segment moves and retain complete ordering. - Make one segment unavailable and report the gap without a complete-result claim. Deliverables - Cross-store query contract and boundary cases Rollout and recovery: Canary bounded date queries; fall back to separate hot/cold retrieval if completeness is uncertain. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. ### Challenge long-term behavior Rehearse retention, restoration and cost changes. #### AARCHIVE-108 — Model retention as a policy decision separate from audit immutability **Task · Medium priority · Expert** noCV practice brief v5 · AARCHIVE-108 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-104, AARCHIVE-106, AARCHIVE-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 30% · Storage 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. Stakeholders confuse append-only records with keeping every payload forever, while the archive has a fictional bounded retention agreement. Acceptance criteria - Specify retention scope, expiry and hold behavior. - Preserve authorized deletion facts without claiming deleted bytes remain available. - Identify which policy decisions need external approval before implementation. Implementation constraints - Use a fictional policy and synthetic data; make no legal compliance claim. Verification - Apply expiry to an eligible segment in the model. - Apply a hold and show that deletion remains blocked. Deliverables - Retention model and policy-state probe Rollout and recovery: Review policy before any delete implementation; keep proposed deletion plans read-only. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-109 — Rehearse archive restoration from manifests after index loss **Task · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-109 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-104, AARCHIVE-105, AARCHIVE-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · System design 30% · 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 search projection is lost, but the recovery plan assumes an index backup rather than using the authoritative archive. Acceptance criteria - Restore a new index generation from verified segments. - Report corrupt or missing segments separately from indexed count. - Keep queries from mixing partial and complete generations. Implementation constraints - Use a small synthetic archive with one intentionally damaged segment. Verification - Rebuild from complete manifests and compare query identities. - Include the damaged segment and block a complete-generation claim. Deliverables - Restoration drill and completeness report Rollout and recovery: Run the drill before archive activation; retain the old searchable generation until reconciliation succeeds. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-110 — Prepare the archive architecture review with explicit retrieval limits **Chore · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-110 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-102, AARCHIVE-107, AARCHIVE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Storage 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. A roadmap summary promises unlimited search and permanent audit availability despite the bounded design. Acceptance criteria - Summarize workload, retention and recovery assumptions. - Link claims to manifest, authorization and restore probes. - List deferred infrastructure and unresolved provider capabilities. Implementation constraints - Avoid presenting the local simulator as production storage readiness. Verification - Trace a recent-query guarantee to its contract. - Trace a missing-segment scenario and document the user-visible limitation. Deliverables - Archive design review packet Rollout and recovery: Review before storage commitment; revise the packet when retention or retrieval requirements change. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. ## AADMIT — Design admission control for scheduled report generation A fictional analytics product lets customers schedule expensive reports at the top of the hour. The API remains available only if report work is admitted and cancelled predictably. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, BullMQ. **Engineer value:** Practice workload modeling, fairness and cancellation architecture. **Company value:** Review controllable operating costs and predictable customer-facing overload behavior. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local scheduler model and synthetic report jobs. - Use fake execution providers; no customer queries or candidate code run on worker hosts. ### Define load and fairness Make demand and service objectives explicit. #### AADMIT-101 — Build a report arrival model that includes top-of-hour bursts **Task · Medium priority · Foundational** noCV practice brief v5 · AADMIT-101 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Performance 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. Average reports per minute looks harmless, but nearly every customer chooses 09:00 for its daily report. Acceptance criteria - Separate average arrival rate from burst size. - State hypothetical report duration and size classes. - Include timezone scheduling assumptions. Implementation constraints - Create a deterministic synthetic one-day schedule. Verification - Count average arrivals and the largest one-minute burst. - Move all schedules to one instant and show the peak changes despite equal daily volume. Deliverables - Arrival model and reproducible schedule generator Rollout and recovery: Review the model before queue sizing; revise assumptions when schedule usage is measured. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-102 — Define customer-visible report states and overload responses **Task · Medium priority · Intermediate** noCV practice brief v5 · AADMIT-102 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: AADMIT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System design 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. The API returns accepted for jobs that may wait indefinitely, so customers repeatedly click generate. Acceptance criteria - Distinguish rejected, queued, running and terminal states. - Specify bounded queue age and a retryable admission response. - Define what acceptance durably guarantees. Implementation constraints - Use explicit state transitions and stable job identities. Verification - Trace an admitted report to its durable queue state. - Reject an over-capacity request without creating a phantom report. Deliverables - Admission response contract and state table Rollout and recovery: Review the contract before accepting schedules; keep overload behavior explicit in the prototype. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-103 — Record the fairness decision for small and large report tenants **Task · Medium priority · Foundational** noCV practice brief v5 · AADMIT-103 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: AADMIT-101, AADMIT-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Distributed systems 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 single tenant's weekly exports occupy every available slot while small interactive reports wait behind them. Acceptance criteria - Compare FIFO, per-tenant limits and weighted scheduling. - Define fairness and starvation expectations. - Document how unknown report cost is classified. Implementation constraints - Use a small synthetic tenant set and avoid hiring or user scoring. Verification - Evaluate a mixed small/large workload against the chosen rule. - Show the behavior when one tenant continuously submits work. Deliverables - Fairness decision record Rollout and recovery: Review the chosen policy with the workload model; retain configuration for bounded tuning. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. ### Specify admission and work ownership Bound queues, retries and cancellation. #### AADMIT-104 — Specify transactional report admission with deterministic job identities **Story · Medium priority · Advanced** noCV practice brief v5 · AADMIT-104 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-102, AADMIT-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · Database 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 scheduler creates report rows but loses queue publication, leaving accepted work with no execution path. Acceptance criteria - Commit admission and outbox fact atomically. - Bind job identity to schedule occurrence or request key. - Make repeated dispatch resolve one logical job. Implementation constraints - Keep lifecycle authority in the durable service boundary. Verification - Crash after admission commit and recover dispatch. - Replay the same scheduled occurrence and count one report. Deliverables - Admission/outbox contract and crash probe Rollout and recovery: Prototype with a fake executor; stop new admission if durable dispatch cannot be recorded. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-105 — Design cancellation ownership for queued and running reports **Task · Medium priority · Expert** noCV practice brief v5 · AADMIT-105 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-102, AADMIT-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Distributed systems 30% · Storage 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. A user cancels a report, but the worker later publishes a completed artifact and overwrites the cancellation status. Acceptance criteria - Define cancellation request versus confirmed stop. - Fence stale completion against current generation and state. - Specify cleanup ownership for incomplete artifacts. Implementation constraints - Use a provider cancellation contract; do not kill host processes arbitrarily. Verification - Cancel queued work and verify no execution begins. - Race cancellation with completion and preserve the declared single terminal outcome. Deliverables - Cancellation protocol and race model Rollout and recovery: Canary cancellation in the local provider; retain unresolved stop status when provider confirmation is unavailable. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-106 — Bound retries so failing reports cannot consume the entire service **Task · Medium priority · Advanced** noCV practice brief v5 · AADMIT-106 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-103, AADMIT-104, AADMIT-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Site reliability 30% · Platform 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 malformed report fails immediately and retries faster than healthy reports can start. Acceptance criteria - Define retry count, backoff and elapsed-time budgets. - Classify permanent versus retryable failure explicitly. - Keep retry work inside tenant and global admission limits. Implementation constraints - Use deterministic fake time and bounded jitter inputs. Verification - Retry a transient failure within the declared budget. - Feed a permanent failure and verify it cannot form a tight retry loop. Deliverables - Retry-budget model and scheduling probe Rollout and recovery: Enable bounded retries for synthetic jobs; suspend a failing class if classification is uncertain. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-107 — Choose where report artifacts become authoritative **Story · Medium priority · Intermediate** noCV practice brief v5 · AADMIT-107 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-104, AADMIT-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · System design 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. A worker uploads a partial file and the API exposes its object key before completion checks finish. Acceptance criteria - Stage artifacts under a job generation. - Publish only after verified storage identity and guarded completion. - Keep incomplete or stale-generation artifacts inaccessible. Implementation constraints - Separate object upload from user-visible report publication. Verification - Publish a verified synthetic artifact for the active job. - Complete an older generation and verify it cannot replace the visible result. Deliverables - Artifact publication boundary and contract probe Rollout and recovery: Prototype with local storage; keep staged objects private until finalization succeeds. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. ### Challenge overload behavior Model burst recovery and review operating limits. #### AADMIT-108 — Calculate burst drain time with fairness and retry reservations **Task · Medium priority · Expert** noCV practice brief v5 · AADMIT-108 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-101, AADMIT-103, AADMIT-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · System 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. Operations wants a queue-age target, but the capacity spreadsheet assumes every slot is always available for first attempts. Acceptance criteria - Model concurrency, service-time classes and reserved retry capacity. - Calculate per-tenant wait under the selected fairness rule. - Show when queue-age targets cannot be met. Implementation constraints - Use hypothetical durations and an executable deterministic simulation. Verification - Simulate the declared top-of-hour burst. - Double expensive reports and report target violations without inventing a speedup. Deliverables - Queue simulation and capacity worksheet Rollout and recovery: Use the model to propose reviewed limits; validate assumptions with real isolated measurements before deployment. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-109 — Rehearse scheduler restart while reports are queued and running **Task · Medium priority · Advanced** noCV practice brief v5 · AADMIT-109 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-104, AADMIT-105, AADMIT-107, AADMIT-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · 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. The scheduling process restarts during a burst, and the design must explain which work is resumed, reconciled or left uncertain. Acceptance criteria - Recover queued ownership from durable identities. - Reconcile running jobs through provider status before retry. - Preserve accepted artifacts and terminal outcomes. Implementation constraints - Inject failures in a local state model and fake provider. Verification - Restart with queued and completed synthetic jobs and converge correctly. - Restart with an unknown provider outcome and keep it unresolved instead of duplicating work. Deliverables - Restart drill and recovery trace Rollout and recovery: Run before accepting real schedules; pause admissions if recovery cannot establish work ownership. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-110 — Write the report-service operating contract for design approval **Chore · Medium priority · Foundational** noCV practice brief v5 · AADMIT-110 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-102, AADMIT-108, AADMIT-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 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. A launch checklist says scalable reporting without naming admission limits, cancellation guarantees or unavailable-provider behavior. Acceptance criteria - Summarize admitted workload, fairness and bounded queue behavior. - Link each guarantee to a model or probe. - List deferred execution-provider and production-measurement work. Implementation constraints - Keep design approval separate from production readiness. Verification - Trace a queue-age target to its simulation assumptions. - Trace provider unavailability to a documented pending or rejected outcome. Deliverables - Operating contract and architecture review notes Rollout and recovery: Review before infrastructure commitment; update limits when measurement evidence replaces assumptions. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. ## AMIGRATE — Migrate customer identifiers without breaking old clients A fictional support platform stores a mutable external account code as its primary relationship key. Renames and imports now break references in several tables. **Field:** Database engineering. **Suggested stack:** PostgreSQL, Prisma, TypeScript. **Engineer value:** Practice migration ordering, compatibility and referential integrity. **Company value:** Review a reversible schema transition with measurable completeness checks. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a disposable database with synthetic customers and dependent records. - Apply real migration files; never use production db push. ### Expand the schema safely Add stable identities without breaking current reads. #### AMIGRATE-101 — Inventory every reference to the mutable customer code **Task · Medium priority · Foundational** noCV practice brief v5 · AMIGRATE-101 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · System 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. A customer rename updates its main row but leaves case and attachment references pointing to the old code. Acceptance criteria - List database foreign keys and application lookup boundaries. - Classify direct, denormalized and external references. - Record unresolved references before migration design. Implementation constraints - Use repository search and catalog queries against synthetic schema. Verification - Trace a customer through cases and attachments. - Add one hidden denormalized fixture reference and ensure the inventory method finds it. Deliverables - Reference inventory and discovery queries Rollout and recovery: Review the inventory before migration; keep unknown dependencies as explicit blockers. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-102 — Add immutable customer IDs through an additive migration **Task · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-102 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: AMIGRATE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. The migration needs stable customer identity while current clients continue using external codes. Acceptance criteria - Add an opaque unique customer ID with a safe creation path. - Keep legacy code uniqueness under its current scope. - Do not remove or rename existing columns yet. Implementation constraints - Use a migration file and inspect generated SQL. Verification - Apply the migration to a populated synthetic database. - Attempt duplicate immutable identity and verify a database rejection. Deliverables - Additive migration and schema assertions Rollout and recovery: Apply to a disposable copy first; rollback additive consumers before considering column removal. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-103 — Add nullable customer-ID references to dependent tables **Task · Medium priority · Foundational** noCV practice brief v5 · AMIGRATE-103 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: AMIGRATE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Case rows need the new relationship without requiring a single locking rewrite of the entire dataset. Acceptance criteria - Add the new foreign-key columns without changing current reads. - Index the intended lookup boundary where needed. - Document the later validation and non-null steps. Implementation constraints - Keep migration operations explicit and bounded to the selected tables. Verification - Insert an old-client case after the additive migration. - Insert an invalid non-null customer ID and verify the intended foreign-key behavior. Deliverables - Dependent-table expansion migration Rollout and recovery: Deploy schema before bridge writers; remove unused new columns only before any consumer relies on them. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. ### Bridge old and new writers Backfill and preserve mixed-version compatibility. #### AMIGRATE-104 — Backfill customer IDs with resumable keyset batches **Story · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-104 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A single UPDATE holds locks too long and cannot explain where to resume if the migration job stops. Acceptance criteria - Use a stable cursor and bounded batch size. - Persist progress and count matched, missing and conflicting references. - Update only rows still lacking the new identity. Implementation constraints - Create a synthetic dataset with deliberately unmatched legacy codes. Verification - Interrupt and resume the backfill without rewriting completed rows. - Encounter an unmatched code and report it without guessing a customer. Deliverables - Backfill command and progress report Rollout and recovery: Dry-run matching first; pause between batches and retain the checkpoint on errors. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-105 — Bridge legacy customer writes to the new identity transactionally **Task · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-105 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-102, AMIGRATE-103, AMIGRATE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Old clients create cases using a code while new clients use IDs; both must produce equivalent relationships during rollout. Acceptance criteria - Resolve legacy code within organization inside the write boundary. - Write matching legacy and immutable identity fields together. - Reject contradictory code/ID pairs. Implementation constraints - Do not let controllers bypass the shared repository method. Verification - Create equivalent cases through old and new local client contracts. - Supply code for one customer with another ID and verify no row is inserted. Deliverables - Compatibility writer and contradiction tests Rollout and recovery: Deploy bridge writers before enabling new-client reads; revert client routing while retaining dual fields. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-106 — Protect customer-code renames during the backfill window **Bug · High priority · Expert** noCV practice brief v5 · AMIGRATE-106 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-104, AMIGRATE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. A rename races a batch lookup and attaches a legacy case to the wrong customer when the old code is reused. Acceptance criteria - Resolve against a stable captured mapping or guarded revision. - Prevent ambiguous code reuse during transition. - Keep committed references bound to immutable customer identity. Implementation constraints - Document the locking or mapping-version strategy. Verification - Race rename with backfill using two database clients. - Reuse an old code after the allowed boundary and preserve earlier references. Deliverables - Rename/backfill concurrency guard Rollout and recovery: Temporarily constrain code reuse under the migration policy; pause backfill on mapping conflicts. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-107 — Verify relationship completeness before making customer IDs mandatory **Task · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-107 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-104, AMIGRATE-105, AMIGRATE-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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 team wants to mark new references non-null, but missing mappings are hidden by a dashboard that counts only completed batches. Acceptance criteria - Count null, orphan and contradictory references separately. - Check rows created during and after backfill. - Fail the readiness check unless every required relationship is valid. Implementation constraints - Use SQL assertions against the actual synthetic schema. Verification - Complete valid mappings and pass the readiness query. - Create a late legacy-only row and verify readiness fails. Deliverables - Completeness gate and SQL assertions Rollout and recovery: Run repeatedly before constraint changes; leave new columns nullable while gaps remain. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. ### Contract after verification Remove legacy assumptions only with complete checks. #### AMIGRATE-108 — Validate and enforce the new customer relationship constraints **Task · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-108 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Application checks pass, but a direct import can still create a case with an absent new customer identity. Acceptance criteria - Add or validate foreign-key and non-null constraints after readiness. - Document database lock expectations for each migration step. - Reject writes violating the new relationship invariant. Implementation constraints - Use PostgreSQL-supported staged validation where appropriate; inspect actual SQL. Verification - Apply the constraint migration after a clean backfill. - Attempt orphan and null references through direct SQL and observe rejection. Deliverables - Constraint migration and direct-write checks Rollout and recovery: Apply in a controlled synthetic window; abort on lock contention and preserve the bridge schema. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-109 — Switch customer reads to immutable IDs with a compatibility fallback plan **Story · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-109 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-105, AMIGRATE-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · API design 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. The new writer is deployed, but detail routes still resolve mutable codes and can display the wrong record after a rename. Acceptance criteria - Use immutable IDs for internal relationships and new detail routes. - Keep documented legacy lookup behavior at the API boundary. - Record fallback use without leaking customer payloads. Implementation constraints - Fallback must remain tenant-scoped and reject ambiguous codes. Verification - Rename a customer and keep its ID-based detail route stable. - Request an ambiguous legacy code and reject rather than selecting a row. Deliverables - ID-based read path and compatibility cases Rollout and recovery: Canary new routes; restore bridge reads if client compatibility fails. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-110 — Retire legacy customer references only after a rollback rehearsal **Chore · High priority · Expert** noCV practice brief v5 · AMIGRATE-110 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-108, AMIGRATE-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Dropping old columns would end binary rollback to old readers, but the release checklist does not mention that boundary. Acceptance criteria - Inventory remaining legacy reads and writes before contraction. - Rehearse the last reversible rollback with compatible code. - Document the point after which forward repair is required. Implementation constraints - Do not drop columns merely because the backfill command completed. Verification - Run the old-compatible build against the expanded schema. - Attempt the contraction readiness check with one legacy writer and verify it blocks. Deliverables - Contraction migration plan and rollback evidence Rollout and recovery: Apply contraction only after reviewed readiness; preserve a tested backup and forward-repair procedure. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. ## ACLAIM — Make a database-backed work assignment queue correct A fictional inspection service assigns review jobs to staff. Polling clients sometimes claim the same job and a disconnected client can finish work after reassignment. **Field:** Database engineering. **Suggested stack:** PostgreSQL, TypeScript. **Engineer value:** Practice database concurrency, leases and transactional invariants. **Company value:** Review whether assignment authority remains reliable during contention and recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic jobs and two independent database clients. - Use explicit state methods and an injected clock. ### Define assignment invariants Represent queue order, ownership and deadlines. #### ACLAIM-101 — Define assignment states and their required database fields **Task · Medium priority · Foundational** noCV practice brief v5 · ACLAIM-101 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define assignment invariants. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. Rows marked assigned sometimes have no assignee or lease deadline, making recovery ambiguous. Acceptance criteria - Specify pending, assigned and terminal field invariants. - Add checks that reject contradictory state combinations. - Keep completion metadata distinct from lease metadata. Implementation constraints - Use migration-backed constraints where practical. Verification - Insert each valid synthetic state. - Attempt assigned without an assignee or deadline and verify rejection. Deliverables - Assignment schema and constraint matrix Rollout and recovery: Apply constraints after inspecting synthetic legacy rows; quarantine invalid states before enabling writes. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-102 — Order eligible jobs with a stable tie break **Task · Medium priority · Foundational** noCV practice brief v5 · ACLAIM-102 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define assignment invariants. Depends on: ACLAIM-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. Jobs created at the same instant appear in a different order on each poll, making starvation difficult to reproduce. Acceptance criteria - Order by declared priority, ready time and opaque job ID. - Exclude future and terminal jobs explicitly. - Bound claim candidate count. Implementation constraints - Document whether priority changes preserve or reset waiting time. Verification - Create equal-time jobs and observe stable order. - Include future and completed jobs and verify they are ineligible. Deliverables - Eligibility query and ordering fixtures Rollout and recovery: Introduce the query in read-only inspection first; restore previous routing on semantic mismatch. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-103 — Scope work assignment queries to the operator's organization **Bug · High priority · Intermediate** noCV practice brief v5 · ACLAIM-103 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define assignment invariants. Depends on: ACLAIM-101, ACLAIM-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 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. The job list is scoped in the controller, but the claim repository accepts a globally valid job ID. Acceptance criteria - Require organization scope at repository entry. - Claim and detail queries enforce that scope. - Return no other-organization job metadata on denial. Implementation constraints - Test direct repository calls as well as API routes. Verification - Claim a permitted synthetic job. - Claim another organization's ID and verify unchanged row state. Deliverables - Tenant-scoped assignment repository Rollout and recovery: Deploy repository guards before broader polling; inspect safe denial counters. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. ### Protect concurrent transitions Claim, renew and finish with durable authority. #### ACLAIM-104 — Claim one pending job atomically under competing pollers **Story · High priority · Advanced** noCV practice brief v5 · ACLAIM-104 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect concurrent transitions. Depends on: ACLAIM-102, ACLAIM-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Two polling clients select the same pending job before either writes its assignment. Acceptance criteria - Select and transition a job within one transaction. - Use a database locking strategy with documented contention behavior. - Return distinct jobs or no work under concurrent pollers. Implementation constraints - Evaluate SKIP LOCKED against the declared ordering and fairness policy. Verification - Start two clients at a barrier and assert unique claimed identities. - Hold one candidate lock and verify the documented skip or wait behavior. Deliverables - Atomic claim query and concurrency test Rollout and recovery: Canary with two synthetic pollers; reduce concurrency if lock behavior violates the contract. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-105 — Issue a monotonically increasing assignment generation on every reclaim **Task · Medium priority · Advanced** noCV practice brief v5 · ACLAIM-105 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect concurrent transitions. Depends on: ACLAIM-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Distributed systems 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 disconnected reviewer reconnects after its job was reassigned and still holds a token that appears current. Acceptance criteria - Every new assignment increments a durable generation. - Mutation commands require job, assignee and generation. - A stale generation cannot renew or finish work. Implementation constraints - Treat the generation as authority, not a UI-only counter. Verification - Reclaim a job and complete using the new generation. - Try completion from the previous generation and reject it. Deliverables - Assignment-generation guard Rollout and recovery: Enable guarded writes before automated reclaim; retain old assignment history. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-106 — Renew assignment leases without extending a completed job **Bug · Medium priority · Intermediate** noCV practice brief v5 · ACLAIM-106 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect concurrent transitions. Depends on: ACLAIM-104, ACLAIM-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Distributed systems 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 late heartbeat runs after completion and changes the row back into an apparently active assignment. Acceptance criteria - Renew only the current assigned generation. - Never modify terminal completion fields. - Bound extension duration using the server's clock. Implementation constraints - Use one guarded update rather than read-then-write status changes. Verification - Renew a valid active assignment. - Complete first, then send a delayed renewal and preserve terminal state. Deliverables - Lease renewal command and stale-heartbeat test Rollout and recovery: Canary renewal with short synthetic leases; pause renewal on unexpected transition conflicts. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-107 — Finish a job and publish its result reference in one transaction **Story · Medium priority · Expert** noCV practice brief v5 · ACLAIM-107 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect concurrent transitions. Depends on: ACLAIM-105, ACLAIM-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. A result is visible while its job remains assigned because completion and result linking commit separately. Acceptance criteria - Check assignment authority and lease at commit. - Commit terminal state and result reference atomically. - Duplicate identical completion returns the original outcome. Implementation constraints - Keep result bytes outside the database transaction; link only verified immutable identity. Verification - Complete a valid assignment with one result reference. - Force transaction failure and verify neither completion nor result publication persists. Deliverables - Completion transaction and rollback tests Rollout and recovery: Enable completion on synthetic jobs; suspend writes if authority or result verification is unavailable. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. ### Recover stale work Inspect contention and repair expired assignments. #### ACLAIM-108 — Reclaim expired assignments using current row authority **Task · Medium priority · Advanced** noCV practice brief v5 · ACLAIM-108 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover stale work. Depends on: ACLAIM-105, ACLAIM-106, ACLAIM-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · 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. A sweep selects expired jobs, then reclaims one that was renewed before its update executes. Acceptance criteria - Recheck generation, assigned state and expiry in the reclaim update. - Record previous ownership as immutable history. - Bound each sweep and expose skipped renewals. Implementation constraints - Use a controlled clock and barrier for the renewal race. Verification - Reclaim a truly expired assignment. - Renew between scan and update and verify reclaim skips it. Deliverables - Expiry reclaimer and race regression Rollout and recovery: Dry-run selected rows first; pause sweeps when clock or ownership checks disagree. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-109 — Measure assignment lock behavior without claiming a throughput guarantee **Chore · Medium priority · Intermediate** noCV practice brief v5 · ACLAIM-109 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover stale work. Depends on: ACLAIM-104, ACLAIM-108. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Performance engineering 30% · 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. Operators need to choose a polling interval and concurrency limit based on observed contention in the local prototype. Acceptance criteria - Record database/runtime versions and synthetic job count. - Measure lock waits and claim outcomes at fixed concurrency levels. - Keep correctness assertions enabled during every run. Implementation constraints - Repeat each local condition three times; results describe only that environment. Verification - Run identical workloads at one and four pollers and record observations. - Hold a long transaction and verify timeouts remain bounded without duplicate claims. Deliverables - Contention probe and observation report Rollout and recovery: Use observations to propose conservative local limits; restore lower concurrency if claim failures rise. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. #### ACLAIM-110 — Rehearse recovery of a queue with mixed expired and terminal jobs **Task · Medium priority · Expert** noCV practice brief v5 · ACLAIM-110 · Make a database-backed work assignment queue correct Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover stale work. Depends on: ACLAIM-107, ACLAIM-108, ACLAIM-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. After an outage, operators need to resume assignments without redoing completed work or accepting stale reviewer results. Acceptance criteria - Classify terminal, live and expired assignments from durable fields. - Reclaim only expired authority and preserve terminal results. - Report inconsistent rows instead of silently normalizing them. Implementation constraints - Use a fabricated outage dataset with one contradictory row. Verification - Recover valid mixed states and finish one reclaimed job. - Submit a stale completion and inspect the contradictory row report. Deliverables - Queue recovery runbook and executable drill Rollout and recovery: Run the drill before increasing concurrency; keep uncertain jobs quarantined for review. Project prerequisites: Create synthetic jobs and two independent database clients. Use explicit state methods and an injected clock. Engineer value: Practice database concurrency, leases and transactional invariants. Company value: Review whether assignment authority remains reliable during contention and recovery. 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. ## ARESTORE — Prove a PostgreSQL backup can restore usable application state A fictional case-management team has nightly backup files but has never tested application behavior after restore. Missing roles and external artifact references may make a successful database restore unusable. **Field:** Database engineering. **Suggested stack:** PostgreSQL, TypeScript, Object storage. **Engineer value:** Practice restore verification, provenance and operational recovery. **Company value:** Review evidence that recovery produces coherent usable state under declared limits. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a disposable synthetic database and local backup directory. - Never connect these drills to production or overwrite a shared database. ### Identify recovery inputs Record backup identity and application dependencies. #### ARESTORE-101 — Inventory database recovery inputs beyond the dump file **Task · Medium priority · Foundational** noCV practice brief v5 · ARESTORE-101 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Site reliability 20% · Storage 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. A test restore contains tables but cannot start the application because expected roles and extensions are absent. Acceptance criteria - List schema, roles, extensions, migration version and artifact dependencies. - Separate secret configuration from backup contents. - Record unresolved dependencies explicitly. Implementation constraints - Use a disposable synthetic database with a minimal application. Verification - Start the application from a complete declared inventory. - Omit an extension in a fixture and identify the missing prerequisite. Deliverables - Recovery dependency inventory Rollout and recovery: Review inventory before claiming restore readiness; keep unresolved prerequisites visible. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-102 — Create a backup manifest that binds bytes to schema revision **Task · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-102 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: ARESTORE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Storage systems 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. Operators find three similarly named dump files and cannot tell which migration version or time each represents. Acceptance criteria - Record byte hash, size, UTC capture time and migration identity. - Bind the manifest to the exact backup artifact. - Reject a missing or mismatched manifest before restore. Implementation constraints - Use synthetic data and avoid credentials in command logs. Verification - Verify a backup and matching manifest. - Alter backup bytes and reject the restore plan. Deliverables - Backup manifest command and integrity checks Rollout and recovery: Create manifests for new backups; label unverified older files as uncertain. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-103 — Validate that a restore target is isolated before running destructive steps **Task · High priority · Foundational** noCV practice brief v5 · ARESTORE-103 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: ARESTORE-101, ARESTORE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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 copied restore command could replace the development database instead of the disposable drill target. Acceptance criteria - Require an explicit disposable target identity and expected marker. - Resolve and inspect target connection metadata before mutation. - Reject shared, production-like or unmarked targets. Implementation constraints - Use exact database names and task-specific credentials; no wildcard cleanup. Verification - Plan a restore to a marked disposable target. - Point at an unmarked synthetic target and verify zero destructive calls. Deliverables - Restore-target guard and denial tests Rollout and recovery: Make the guard mandatory for drills; abort if target identity changes. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. ### Restore and verify Use isolated targets and validate relational/application state. #### ARESTORE-104 — Restore a verified backup into a new database generation **Story · Medium priority · Advanced** noCV practice brief v5 · ARESTORE-104 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-102, ARESTORE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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 current procedure restores directly over the active database and leaves no usable environment if it fails halfway. Acceptance criteria - Create and restore into a distinct verified disposable generation. - Keep the prior target untouched until checks complete. - Record each restore stage and failure without exposing data contents. Implementation constraints - Use bounded local synthetic backups only. Verification - Restore a valid backup and inspect the new generation. - Fail mid-restore and verify the previous synthetic application still reads its original database. Deliverables - Generation-based restore script Rollout and recovery: Use a new target for every drill; remove only verified owned failed generations after review. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-105 — Check relational invariants after restoration **Task · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-105 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-104. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A restore exits successfully but an earlier disabled constraint allowed orphan case assignments into the backup. Acceptance criteria - Check expected foreign keys, unique constraints and required indexes. - Run explicit orphan and duplicate queries on restored data. - Fail application activation when invariants do not hold. Implementation constraints - Compare actual catalog metadata with the declared migration contract. Verification - Validate a clean synthetic restored database. - Restore a deliberately inconsistent fixture and report exact invariant failures. Deliverables - Post-restore SQL verification suite Rollout and recovery: Run before connecting application traffic; retain the failed generation for bounded diagnosis. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-106 — Reconcile restored database references with external artifacts **Task · Medium priority · Advanced** noCV practice brief v5 · ARESTORE-106 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-101, ARESTORE-104, ARESTORE-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Storage systems 40% · 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. Case attachments point to objects created after the backup cutoff, and some objects referenced by restored rows are missing. Acceptance criteria - Compare immutable object versions and hashes for referenced artifacts. - Report missing, extra and mismatched objects separately. - Do not replace missing artifacts with similarly named current objects. Implementation constraints - Use a local object-store fixture and explicit backup cutoff. Verification - Restore matching database and object manifests. - Remove a referenced object and keep the application readiness result incomplete. Deliverables - Artifact reconciliation command Rollout and recovery: Keep artifact-dependent routes unavailable until their references verify; preserve missing-reference reports. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-107 — Prevent post-restore background jobs from repeating completed side effects **Task · High priority · Expert** noCV practice brief v5 · ARESTORE-107 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-104, ARESTORE-105, ARESTORE-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database 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 restored outbox contains delivery records whose external effects happened after the database backup but before the outage. Acceptance criteria - Document the database/external-side-effect recovery gap. - Reconcile provider identities before redispatching restored records. - Preserve unknown outcomes rather than asserting they were never sent. Implementation constraints - Use fake providers with durable synthetic request identities; send no messages. Verification - Restore a completed external operation and reconcile it without duplication. - Make provider status unavailable and keep redispatch blocked under the declared policy. Deliverables - Outbox recovery protocol and provider probe Rollout and recovery: Start restored workers paused; release only reconciled work and retain unknown cases. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. ### Exercise recovery failures Measure local recovery and document missing guarantees. #### ARESTORE-108 — Measure local restore time with complete verification included **Chore · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-108 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-104, ARESTORE-105, ARESTORE-106, ARESTORE-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Database engineering 40% · 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. The team's restore-time figure measures only dump loading and excludes artifact checks and application readiness. Acceptance criteria - Record hardware, versions, dataset size and cache conditions. - Measure load, verification and readiness stages separately. - Repeat the same synthetic restore three times and report spread. Implementation constraints - These observations do not establish a production RTO. Verification - Run the declared complete restore drill and record all stages. - Fail an invariant check and report recovery incomplete despite dump success. Deliverables - Reproducible local restore timing report Rollout and recovery: Use measurements to improve the drill; revise targets only after representative environment testing. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-109 — Rehearse backup corruption and missing-manifest failure paths **Task · Medium priority · Expert** noCV practice brief v5 · ARESTORE-109 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-102, ARESTORE-103, ARESTORE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Site reliability 30% · Storage 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. Operators need a practiced response when the newest backup is unusable rather than trying increasingly risky manual restore commands. Acceptance criteria - Reject corrupt artifacts before activating a generation. - Select an earlier verified backup with an explicit data-gap statement. - Record the cutoff and unresolved external effects. Implementation constraints - Create disposable corrupted copies rather than altering the retained good backup. Verification - Restore from the prior verified synthetic backup. - Present a missing manifest and corrupted newest artifact and keep both untrusted. Deliverables - Backup-failure drill and recovery decision trace Rollout and recovery: Run periodically in disposable targets; preserve good backups and stop when no verified candidate exists. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-110 — Write an application-level database recovery handoff **Task · Medium priority · Foundational** noCV practice brief v5 · ARESTORE-110 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-107, ARESTORE-108, ARESTORE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A successful command transcript is handed to on-call staff without clear activation criteria or a statement of potentially missing data. Acceptance criteria - List verification gates and the selected recovery cutoff. - Include worker pause/release and artifact availability steps. - State measured local limits and unresolved production dependencies. Implementation constraints - Use fabricated case records in the worked example. Verification - Follow the handoff from verified backup to synthetic application readiness. - Follow the no-verified-backup branch and stop without claiming recovery. Deliverables - Recovery runbook and worked handoff Rollout and recovery: Review with a fresh local drill; update the runbook when schema or provider contracts change. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. ## ATENANT — Enforce organization boundaries in a relational case schema A fictional case-management application filters most requests correctly, but imports and background commands can connect a case to another organization's project or assignee. **Field:** Database engineering. **Suggested stack:** PostgreSQL, Prisma, TypeScript. **Engineer value:** Practice tenant-aware keys, foreign keys and direct-write denial tests. **Company value:** Review defense in depth for data isolation across ordinary and privileged writers. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create two synthetic organizations with overlapping display names. - Use repository-level authorization and migration-backed constraints. ### Inventory tenant relationships Find and constrain cross-organization references. #### ATENANT-101 — Map tenant ownership for case-management entities **Task · Medium priority · Foundational** noCV practice brief v5 · ATENANT-101 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory tenant relationships. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. The schema lists organization IDs on cases but not on comments or attachment relationships, leaving ownership implicit. Acceptance criteria - Identify the owning organization for every selected entity. - List relationships that must stay within one organization. - Separate truly global reference data from tenant data. Implementation constraints - Use a bounded case/project/comment schema. Verification - Trace ownership from a case attachment to its organization. - Identify an intentionally ambiguous relationship and mark it unresolved. Deliverables - Tenant ownership map Rollout and recovery: Review the map before migrations; keep ambiguous relationships out of new writes. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-102 — Add composite uniqueness for tenant-owned relationship targets **Task · Medium priority · Intermediate** noCV practice brief v5 · ATENANT-102 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory tenant relationships. Depends on: ATENANT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. Globally unique row IDs do not by themselves let a foreign key enforce that case and project belong to the same organization. Acceptance criteria - Add the composite target keys needed for tenant-bound references. - Preserve existing globally unique identities. - Document index duplication and selected constraint names. Implementation constraints - Inspect actual migration SQL and query patterns. Verification - Create identical display names in different organizations. - Attempt a duplicate target identity within the same composite key and verify rejection. Deliverables - Composite-key migration Rollout and recovery: Apply additive keys first; remove only demonstrably redundant indexes after usage review. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-103 — Reject null organization scope in protected repository methods **Bug · High priority · Foundational** noCV practice brief v5 · ATENANT-103 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory tenant relationships. Depends on: ATENANT-101, ATENANT-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Backend 30% · Database 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. An optional organization argument defaults to an unscoped query when an internal caller forgets to pass it. Acceptance criteria - Require nonempty scope in protected method signatures and validation. - Remove unscoped fallback branches. - Keep global reference methods explicitly separate. Implementation constraints - Test direct service calls rather than relying solely on controllers. Verification - Read a project using valid tenant scope. - Omit scope at the runtime boundary and verify no database query executes. Deliverables - Required-scope repository contract Rollout and recovery: Deploy boundary validation before new callers; deny ambiguous internal requests. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. ### Protect every write path Carry scope through imports, jobs and transactions. #### ATENANT-104 — Enforce same-organization case-to-project references with a foreign key **Task · High priority · Advanced** noCV practice brief v5 · ATENANT-104 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect every write path. Depends on: ATENANT-102, ATENANT-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. An import can connect a case in one organization to a globally valid project in another organization. Acceptance criteria - Create a composite foreign key including organization identity. - Reject mismatched direct SQL and application writes. - Retain valid same-organization associations. Implementation constraints - Backfill and inspect existing mismatches before validating the constraint. Verification - Insert a valid synthetic case/project relationship. - Insert a cross-organization relationship directly and observe database rejection. Deliverables - Tenant-bound foreign-key migration Rollout and recovery: Validate after a clean discrepancy report; quarantine invalid legacy relationships without guessing ownership. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-105 — Keep case-comment inserts scoped during concurrent parent changes **Task · Medium priority · Advanced** noCV practice brief v5 · ATENANT-105 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect every write path. Depends on: ATENANT-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 20% · 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. A comment command checks the case once, then writes after an administrator changes related project state. Acceptance criteria - Authorize and insert against current parent ownership in one boundary. - Prevent parent reassignment that would violate child scope. - Return a conflict rather than attach a comment ambiguously. Implementation constraints - Prefer immutable tenant ownership for existing entities. Verification - Insert a comment under stable ownership. - Race a prohibited parent-scope change and verify no cross-tenant comment results. Deliverables - Comment transaction and ownership race test Rollout and recovery: Enable the guarded command; disable tenant reassignment paths that lack a migration protocol. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-106 — Make bulk case imports validate every tenant relationship before commit **Story · Medium priority · Intermediate** noCV practice brief v5 · ATENANT-106 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect every write path. Depends on: ATENANT-103, ATENANT-104, ATENANT-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Security 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. A bulk import checks the organization of the first row but trusts project IDs in subsequent rows. Acceptance criteria - Validate each relationship under the requested organization. - Report row coordinates with nondisclosing reason codes. - Follow an explicit all-or-nothing import contract. Implementation constraints - Use a synthetic file containing one cross-tenant project reference. Verification - Import a valid multi-row file. - Place an invalid reference late in the file and verify zero case rows commit. Deliverables - Scoped bulk importer and late-row regression Rollout and recovery: Canary small synthetic imports; retain rejected files under bounded restricted storage. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-107 — Carry tenant identity through background case-processing commands **Bug · High priority · Expert** noCV practice brief v5 · ATENANT-107 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect every write path. Depends on: ATENANT-103, ATENANT-104, ATENANT-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Backend 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 queue payload stores only a case ID, and the worker resolves its organization from mutable caller-supplied metadata. Acceptance criteria - Bind durable command identity to case and authoritative tenant. - Reload scoped state before each guarded mutation. - Reject conflicting tenant metadata without executing the provider. Implementation constraints - Queue messages contain opaque IDs, not case contents or secrets. Verification - Process a valid tenant-bound synthetic command. - Replay its case ID with another organization and verify no provider call or mutation. Deliverables - Scoped job command and replay-denial probe Rollout and recovery: Deploy worker guards before new dispatch; quarantine old commands lacking required authority. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. ### Prove boundary coverage Reconcile legacy rows and verify database denials. #### ATENANT-108 — Find legacy cross-tenant references without exposing case contents **Chore · Medium priority · Intermediate** noCV practice brief v5 · ATENANT-108 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove boundary coverage. Depends on: ATENANT-104, ATENANT-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Privacy engineering 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 new constraint cannot validate until operators understand existing mismatches, but incident exports should not include case bodies. Acceptance criteria - Report safe entity IDs and mismatch category only. - Bound scans by table and cursor. - Do not automatically choose which tenant should own an invalid relationship. Implementation constraints - Make the reconciliation command read-only. Verification - Scan a valid synthetic dataset with no mismatches. - Insert a deliberate legacy mismatch in a fixture and identify its exact relationship. Deliverables - Tenant-integrity report Rollout and recovery: Run before constraint validation; repair only reviewed mappings through audited commands. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-109 — Verify tenant constraints through a least-privilege database writer **Task · Medium priority · Expert** noCV practice brief v5 · ATENANT-109 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove boundary coverage. Depends on: ATENANT-104, ATENANT-105, ATENANT-107, ATENANT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Application tests pass, but direct SQL imports use a role that can bypass expected safeguards. Acceptance criteria - Inventory grants for the application and import roles. - Verify ordinary writers cannot disable constraints or change schema. - Run same-tenant and cross-tenant write checks under the actual limited role. Implementation constraints - Use disposable local roles; do not alter production permissions. Verification - Write a valid relationship through the limited import role. - Attempt cross-tenant insertion and constraint disabling and verify both are denied. Deliverables - Role/grant verification and direct-write tests Rollout and recovery: Apply the limited role in the local import path; stop imports if required checks are bypassable. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. #### ATENANT-110 — Document the tenant-data repair protocol and its non-goals **Task · Medium priority · Foundational** noCV practice brief v5 · ATENANT-110 · Enforce organization boundaries in a relational case schema Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove boundary coverage. Depends on: ATENANT-108, ATENANT-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Support wants to move an incorrectly linked case by editing organization IDs directly, risking a cascade of broken ownership. Acceptance criteria - Require a reviewed explicit mapping and affected-relationship inventory. - Preserve audit references and report unresolved children. - Separate repairing a bad link from transferring entity ownership. Implementation constraints - Use one fabricated mismatch as the worked example. Verification - Repair a reviewed synthetic project link with all constraints enabled. - Attempt an incomplete ownership transfer and stop before mutation. Deliverables - Tenant repair runbook Rollout and recovery: Review repairs in a disposable database first; retain invalid rows quarantined when ownership is uncertain. Project prerequisites: Create two synthetic organizations with overlapping display names. Use repository-level authorization and migration-backed constraints. Engineer value: Practice tenant-aware keys, foreign keys and direct-write denial tests. Company value: Review defense in depth for data isolation across ordinary and privileged writers. 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. ## AMETA — Turn unbounded document metadata into a queryable contract A fictional records portal stores every property in one JSON column. Queries disagree about missing values, and malformed records make ordinary filters fail. **Field:** Database engineering. **Suggested stack:** PostgreSQL, Prisma, TypeScript, JSON Schema. **Engineer value:** Practice relational/JSON boundaries, versioned validation and query semantics. **Company value:** Review a data model that stays inspectable while allowing controlled variation. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic document metadata with malformed and legacy versions. - Use migrations and a local query API. ### Define metadata meaning Choose stable columns and bounded flexible fields. #### AMETA-101 — Separate stable document identity fields from flexible attributes **Task · Medium priority · Foundational** noCV practice brief v5 · AMETA-101 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · System 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. Document owner, creation time and type are buried beside optional tags in JSON, so every query reinvents their shape. Acceptance criteria - List stable required columns and bounded flexible attributes. - Document ownership and nullability for each field. - Reject storing lifecycle authority in arbitrary metadata. Implementation constraints - Use a small fictional record taxonomy. Verification - Map two document types to the proposed model. - Classify an unknown authoritative status field as a schema decision rather than generic JSON. Deliverables - Relational/JSON field map Rollout and recovery: Review the field map before migrations; keep unresolved authority fields out of metadata writes. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-102 — Define versioned metadata schemas with explicit size and depth limits **Task · Medium priority · Intermediate** noCV practice brief v5 · AMETA-102 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: AMETA-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · API design 30% · Security 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 submits deeply nested metadata that the API accepts but later query code cannot handle. Acceptance criteria - Require an explicit supported metadata version. - Bound object depth, field count and serialized size. - Reject unknown protected fields and invalid field types. Implementation constraints - Use schema validation at the write boundary and safe error paths. Verification - Validate supported synthetic document metadata. - Exceed depth and size limits and verify no row is stored. Deliverables - Metadata schemas and bound checks Rollout and recovery: Deploy validation for new writes; quarantine incompatible legacy records. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-103 — Choose distinct semantics for absent, null and empty metadata values **Task · Medium priority · Foundational** noCV practice brief v5 · AMETA-103 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: AMETA-101, AMETA-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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 filter for documents without a retention tag returns different results depending on whether the field is absent, null or an empty string. Acceptance criteria - Define the three states for each supported filter. - Reject empty strings where they lack business meaning. - Publish a truth table consumed by query tests. Implementation constraints - Avoid blanket coercion of all empty-like values. Verification - Query one fixture for each declared state. - Send an unsupported empty value and verify validation behavior matches the table. Deliverables - Metadata null-semantics contract Rollout and recovery: Review the truth table with API consumers; retain old filter names until compatibility is documented. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. ### Validate and migrate records Bridge legacy data while protecting writes. #### AMETA-104 — Extract stable document fields through an additive migration **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-104 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-101, AMETA-102, AMETA-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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. The model needs relational owner and created-at columns while old records and clients still use JSON. Acceptance criteria - Add nullable relational fields and required target constraints. - Keep original metadata available during migration. - Reject contradictory dual representations on new writes. Implementation constraints - Use a migration file and explicit data conversion rules. Verification - Insert a consistent bridge record. - Provide different owner identities in columns and JSON and reject the write. Deliverables - Schema expansion and bridge validation Rollout and recovery: Deploy additive schema before readers; rollback bridge code while retaining untouched metadata. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-105 — Backfill document timestamps without guessing missing offsets **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-105 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Data 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. Legacy created-at values mix UTC strings with offset-free dates; blindly casting them uses the database session timezone. Acceptance criteria - Convert only timestamps with an unambiguous documented interpretation. - Quarantine missing-offset and malformed values. - Use resumable batches with counts by conversion outcome. Implementation constraints - Preserve original metadata for later review. Verification - Backfill valid offset-bearing values under two session timezones with identical UTC results. - Process ambiguous dates and retain null target fields plus explicit errors. Deliverables - Timestamp backfill and timezone regression Rollout and recovery: Dry-run first; pause on unexpected conversion categories and keep the checkpoint. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-106 — Keep document metadata updates under optimistic revision control **Bug · Medium priority · Intermediate** noCV practice brief v5 · AMETA-106 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-102, AMETA-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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. Two editors update different metadata fields through whole-object replacement and silently overwrite each other's changes. Acceptance criteria - Require expected document revision on metadata mutation. - Validate the complete resulting versioned object. - Return a conflict without discarding either editor's input. Implementation constraints - Use explicit patch semantics; do not merge unknown nested arrays heuristically. Verification - Apply a patch at the current revision. - Race two patches and verify the stale one cannot overwrite the first. Deliverables - Revision-guarded metadata update Rollout and recovery: Canary patches on synthetic documents; restore read-only editing if conflict handling is incomplete. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-107 — Build parameterized metadata filters with an allowlisted operator set **Task · High priority · Expert** noCV practice brief v5 · AMETA-107 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-102, AMETA-103, AMETA-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database 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. A query endpoint interpolates client-provided JSON paths and operators into SQL. Acceptance criteria - Allow only documented fields and operators. - Bind user values as parameters and tenant scope as a required predicate. - Reject unsupported path syntax before query execution. Implementation constraints - Do not expose arbitrary SQL or JSON-path execution to clients. Verification - Filter known numeric and enum metadata under tenant scope. - Submit malicious path/operator text and verify no query execution or cross-tenant results. Deliverables - Safe filter compiler and injection regressions Rollout and recovery: Enable only reviewed filter combinations; disable newly added operators independently if checks fail. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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 filters trustworthy Verify query semantics and release the model. #### AMETA-108 — Verify metadata filter results against a simple reference evaluator **Chore · Medium priority · Advanced** noCV practice brief v5 · AMETA-108 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-103, AMETA-107. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Database 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. The database query for arrays and null values differs subtly from the API contract, making support reports inconsistent. Acceptance criteria - Author a bounded corpus covering all declared states. - Compare SQL result identities with a simple reference evaluator. - Report missing and extra identities separately. Implementation constraints - Use identical synthetic inputs and keep the reference implementation straightforward. Verification - Compare supported filters across the complete corpus. - Mutate one SQL null condition and verify the differential check finds the mismatch. Deliverables - Differential query harness Rollout and recovery: Require the harness for filter changes; keep the prior query compiler available for rollback. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-109 — Enforce required relational document fields after a clean backfill **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-109 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-104, AMETA-105, AMETA-108. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. New readers assume every document has a valid owner and UTC creation instant, but quarantined legacy rows still violate that assumption. Acceptance criteria - Check null, orphan and contradictory target fields before validation. - Keep quarantined records outside normal reader activation. - Add required constraints only after declared readiness passes. Implementation constraints - Do not fabricate missing timestamps to make constraints pass. Verification - Validate a fully resolved synthetic cohort. - Leave one ambiguous timestamp and verify readiness blocks activation. Deliverables - Readiness query and constraint migration Rollout and recovery: Activate resolved cohorts after verification; retain legacy quarantine and avoid destructive contraction. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. #### AMETA-110 — Rehearse metadata-schema rollback across old and new API consumers **Task · Medium priority · Expert** noCV practice brief v5 · AMETA-110 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-106, AMETA-108, AMETA-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · API design 20% · Platform 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. The team wants to remove legacy JSON fields immediately after switching reads, which could break old clients during a rollback. Acceptance criteria - Test old and new clients against the expanded schema. - Document the compatibility window and contraction prerequisites. - Keep versioned metadata and relational values coherent during rollback. Implementation constraints - Use synthetic records from every supported version. Verification - Switch readers and restore the prior compatible client with unchanged results. - Introduce an unsupported version and verify a clear failure rather than lossy conversion. Deliverables - Compatibility matrix and rollback drill Rollout and recovery: Retain bridge columns through the reviewed window; contract only after old writers are retired. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. 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. ## ALEASE — Coordinate scheduled maintenance with fenced leases A fictional document service runs periodic retention planning on multiple application instances. Paused instances resume after lease expiry and can overlap newer schedulers. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL. **Engineer value:** Practice lease assumptions, fencing and stale-owner rejection. **Company value:** Review safe coordination that remains explainable under pauses and recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a synthetic maintenance queue and two independent scheduler clients. - Use fake time where possible and no destructive real retention actions. ### Define scheduler authority Model lease identity, expiry and protected actions. #### ALEASE-101 — Specify scheduler lease state with a separate authority epoch **Task · Medium priority · Foundational** noCV practice brief v5 · ALEASE-101 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. The scheduler table stores only owner name and expiry, so an old owner can appear identical to a later process with the same name. Acceptance criteria - Include lease identity, holder instance, expiry and monotonic epoch. - Define active and expired semantics at the exact boundary. - Keep display names outside authority checks. Implementation constraints - Use opaque process-instance identities. Verification - Represent two successive owners with distinct epochs. - Reuse a display name and verify it cannot impersonate the previous instance. Deliverables - Lease schema and authority contract Rollout and recovery: Review the schema before scheduler writes; leave coordination disabled until epoch checks exist. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-102 — Use one authoritative clock boundary for lease decisions **Task · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-102 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: ALEASE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Two instances disagree about lease expiry because their local clocks differ by several seconds. Acceptance criteria - Define the clock used for acquisition and expiry checks. - Keep client clock readings out of authority decisions. - Document pause and network-delay assumptions. Implementation constraints - Prefer database time within the transaction for this local PostgreSQL exercise. Verification - Skew client clocks and obtain the same database lease decision. - Reach exact expiry and verify the documented eligibility boundary. Deliverables - Clock-bound lease queries and skew test Rollout and recovery: Canary lease reads under controlled skew; stop acquisition if authoritative time is unavailable. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-103 — Classify maintenance actions that require fencing before side effects **Task · Medium priority · Foundational** noCV practice brief v5 · ALEASE-103 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: ALEASE-101, ALEASE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 design adds a lease but assumes every downstream operation automatically knows whether its caller is still leader. Acceptance criteria - List each protected mutation and its fencing check location. - Separate read-only planning from state-changing execution. - Mark unfenceable external effects as unresolved. Implementation constraints - Use synthetic retention plans; delete no real objects. Verification - Trace a plan-state update to its epoch guard. - Identify an external adapter without epoch support and block its destructive action. Deliverables - Fencing coverage matrix Rollout and recovery: Require coverage before enabling actions; keep unresolved provider operations read-only. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. ### Guard competing owners Acquire, renew and execute with fencing. #### ALEASE-104 — Acquire a scheduler lease atomically under competing instances **Story · High priority · Advanced** noCV practice brief v5 · ALEASE-104 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-102, ALEASE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database 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. Two instances see an expired lease and both believe they became the active scheduler. Acceptance criteria - Acquire through one guarded database transaction. - Increment the epoch only for the winning acquisition. - Return current safe ownership metadata to the loser. Implementation constraints - Use two independent database connections and a barrier. Verification - Race two acquisitions and assert one winning epoch. - Hold a valid lease and verify another instance cannot replace it early. Deliverables - Atomic acquisition command and race test Rollout and recovery: Canary with two local clients; stop scheduling if ownership results conflict. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-105 — Renew a scheduler lease only for the current holder and epoch **Bug · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-105 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 70% · Database 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. A delayed renewal from an earlier process extends the newest owner's lease row while reporting success to the stale process. Acceptance criteria - Match holder instance and epoch in the renewal update. - Bound extension duration from the authoritative clock. - Return lost authority when no matching active lease exists. Implementation constraints - Never renew solely by a shared scheduler name. Verification - Renew the current owner successfully. - Acquire a newer epoch, then submit the old renewal and reject it. Deliverables - Guarded renewal and stale-message test Rollout and recovery: Enable guarded renewal before automated scheduling; make authority loss stop further work claims. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-106 — Fence maintenance writes after a paused scheduler resumes **Task · High priority · Expert** noCV practice brief v5 · ALEASE-106 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-103, ALEASE-104, ALEASE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 70% · Database 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. A scheduler pauses past expiry, then resumes a previously prepared plan after another instance has taken over. Acceptance criteria - Every protected write checks current authority epoch. - A stale owner cannot complete or activate a plan. - Record rejected stale activity without overwriting current progress. Implementation constraints - Carry epoch through the command and recheck at commit. Verification - Pause owner A, let B acquire, then finish B's plan. - Resume A and verify its write is rejected even if it began earlier. Deliverables - Commit-time fencing and pause reproduction Rollout and recovery: Canary synthetic plan activation; disable unfenced writes until every path passes the stale-owner probe. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-107 — Make scheduled maintenance occurrences idempotent across leadership changes **Story · Medium priority · Advanced** noCV practice brief v5 · ALEASE-107 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-104, ALEASE-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database 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 leader repeats the current maintenance period and creates a second plan for the same logical occurrence. Acceptance criteria - Derive occurrence identity from schedule and intended UTC instant. - Enforce one durable logical run per occurrence. - Allow a new owner to resume existing nonterminal work safely. Implementation constraints - Do not derive identity from acquisition time or process name. Verification - Change leader midway through an occurrence and retain one run. - Retry a terminal occurrence and return its recorded result. Deliverables - Occurrence identity contract and leader-change test Rollout and recovery: Enable idempotent creation before multi-instance operation; reconcile existing duplicates through read-only reports. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. ### Exercise time and connection failures Reconcile ownership and recover interrupted runs. #### ALEASE-108 — Expose lease health without implying the holder is making progress **Story · Medium priority · Foundational** noCV practice brief v5 · ALEASE-108 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-105, ALEASE-106, ALEASE-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Site reliability 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 scheduler renews its lease while stuck on one task, so the status page incorrectly reports healthy processing. Acceptance criteria - Report lease authority and work-progress timestamps separately. - Distinguish no leader, active leader and stalled work. - Keep unknown progress explicit after observation gaps. Implementation constraints - Use safe instance tokens rather than host secrets. Verification - Show an active progressing scheduler. - Freeze progress while renewing the lease and show stalled work. Deliverables - Scheduler status projection Rollout and recovery: Add status before alert thresholds; disable noisy alerts while retaining raw safe state. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-109 — Recover coordination after a database connection partition **Task · Medium priority · Expert** noCV practice brief v5 · ALEASE-109 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-102, ALEASE-106, ALEASE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Networking 20% · 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. An instance loses database connectivity but can still contact the fake work provider, raising the risk of acting on expired authority. Acceptance criteria - Stop new protected actions when authority cannot be verified. - Reconcile lease and run state after reconnection. - Resume only under a current valid epoch. Implementation constraints - Use controlled local adapter disconnection, not real network disruption. Verification - Disconnect one owner, acquire with another, and continue valid work. - Reconnect the old owner and reject its cached authority before any action. Deliverables - Partition drill and authority recovery trace Rollout and recovery: Run before multi-instance scheduling; fail closed on unresolved ownership. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-110 — Document lease guarantees and the provider conditions they depend on **Chore · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-110 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-103, ALEASE-107, ALEASE-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 release note says exactly one scheduler runs, even though stale processes may execute until downstream fences reject their writes. Acceptance criteria - Describe mutual authority separately from process execution. - List clock, transaction and provider fencing assumptions. - Link each guarantee to a race or partition probe. Implementation constraints - Avoid claiming leases alone guarantee exactly-once effects. Verification - Trace a protected-write guarantee to its fencing test. - Identify an unfenced provider and state the unsupported guarantee. Deliverables - Coordination operating contract Rollout and recovery: Review before enabling external actions; revise the contract when provider semantics change. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. ## ASAGA — Coordinate equipment returns with explicit compensations A fictional equipment-rental service approves returns through several provider calls. Partial failures leave labels issued without inspections or refunds reported before provider confirmation. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, Provider interfaces. **Engineer value:** Practice durable workflow state, compensation and uncertain outcomes. **Company value:** Review recoverable business operations without assuming distributed transactions. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic return records and fake inspection, shipping and refund adapters. - Use integer money values and no real payments or messages. ### Define workflow facts Separate requested actions from observed outcomes. #### ASAGA-101 — Model return workflow steps as durable facts with explicit pending states **Task · Medium priority · Foundational** noCV practice brief v5 · ASAGA-101 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define workflow facts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 return row has one status called processing, hiding whether inspection, label issuance or refund is outstanding. Acceptance criteria - Represent each step's request and observed outcome separately. - Define legal workflow transitions and terminal conditions. - Keep unknown provider outcomes distinct from failure. Implementation constraints - Use synthetic provider receipts only. Verification - Trace a successful return through all declared facts. - Timeout shipping after acceptance and retain an unknown label outcome. Deliverables - Return state model Rollout and recovery: Review the state table before adding adapters; preserve ambiguous existing cases as unresolved. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-102 — Define stable provider command keys for each return step **Task · Medium priority · Intermediate** noCV practice brief v5 · ASAGA-102 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define workflow facts. Depends on: ASAGA-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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 retry after a lost response creates a second shipping label because each request receives a new key. Acceptance criteria - Bind keys to return identity, step and generation. - Reuse keys for equivalent retries. - Reject changed canonical input under an existing key. Implementation constraints - Do not reuse one key across unrelated provider actions. Verification - Repeat a label request and resolve one fake provider result. - Change shipping destination under the same key and return conflict. Deliverables - Step identity contract and provider-key tests Rollout and recovery: Use stable keys before enabling retries; reconcile legacy ambiguous effects separately. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-103 — Write the compensation table for return side effects **Task · Medium priority · Foundational** noCV practice brief v5 · ASAGA-103 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define workflow facts. Depends on: ASAGA-101, ASAGA-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 team calls every reverse action rollback, although an issued label can be voided and a completed inspection cannot be undone. Acceptance criteria - Classify compensatable, irreversible and unresolved effects. - State preconditions and outcomes for each compensation. - Separate corrective actions from deletion of historical facts. Implementation constraints - Use fake providers and document their exact capabilities. Verification - Map a voidable unused label to its compensation. - Map completed inspection to retained history rather than pretending it can be erased. Deliverables - Compensation decision table Rollout and recovery: Review provider capabilities before orchestrator work; block unsupported automatic reversals. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. ### Persist multi-step progress Make effects idempotent and compensation explicit. #### ASAGA-104 — Persist return progress and next-step dispatch atomically **Story · Medium priority · Advanced** noCV practice brief v5 · ASAGA-104 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Persist multi-step progress. Depends on: ASAGA-101, ASAGA-102, ASAGA-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 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. Inspection completion commits but the shipping step is never scheduled after a process crash. Acceptance criteria - Commit the observed step fact and outbox dispatch together. - Derive next-step identity from the durable workflow generation. - Make repeated step completion a no-op or explicit conflict. Implementation constraints - Keep remote provider calls outside database transactions. Verification - Crash after inspection fact commit and recover label dispatch. - Repeat the same completion and create no duplicate next step. Deliverables - Workflow/outbox transaction and crash probe Rollout and recovery: Canary synthetic returns; pause advancement if durable dispatch cannot be recorded. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-105 — Reconcile shipping acceptance before issuing a replacement label **Task · High priority · Expert** noCV practice brief v5 · ASAGA-105 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Persist multi-step progress. Depends on: ASAGA-102, ASAGA-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 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. The shipping adapter loses its response after accepting a label, and the workflow currently creates a replacement immediately. Acceptance criteria - Query the original provider command identity before replacement. - Record accepted, rejected and unresolved outcomes explicitly. - Create a new generation only under a declared replacement rule. Implementation constraints - The fake adapter must model accepted-but-unacknowledged requests. Verification - Recover the original accepted label after a response loss. - Make status unavailable and retain unresolved shipping without a second label. Deliverables - Shipping reconciliation and uncertainty probe Rollout and recovery: Enable reconciled retries first; stop automatic replacement when provider identity lookup is unavailable. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-106 — Run label compensation only when its original effect is confirmed **Task · Medium priority · Advanced** noCV practice brief v5 · ASAGA-106 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Persist multi-step progress. Depends on: ASAGA-103, ASAGA-104, ASAGA-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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. Pattern topics: Saga (apply). Saga — Apply: Compensate only the confirmed label generation when cancellation races issuance; preserve uncertainty instead of treating a lost response as a failed effect. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A cancellation request races label issuance and attempts to void a label that may not exist yet. Acceptance criteria - Persist cancellation intent independently of provider completion. - Compensate only the confirmed current label generation. - Keep failed or unknown compensation visible for retry. Implementation constraints - Never mark a return fully cancelled solely because a compensation request was sent. Verification - Cancel after confirmed issuance and record confirmed voiding. - Cancel during unknown issuance and wait for reconciliation before compensation. Deliverables - Cancellation/compensation state transitions Rollout and recovery: Canary cancellation on fake providers; retain unresolved operations for bounded reconciliation. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-107 — Authorize refund progression from verified return facts **Bug · High priority · Advanced** noCV practice brief v5 · ASAGA-107 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Persist multi-step progress. Depends on: ASAGA-101, ASAGA-104, ASAGA-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Distributed systems 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. An administrator can set the aggregate status to inspected and trigger a refund without an actual inspection result. Acceptance criteria - Require a verified inspection fact and matching return generation. - Guard refund requests at the service boundary. - Reject direct status edits that bypass prerequisites. Implementation constraints - This exercise uses synthetic money and a fake refund provider. Verification - Advance a return with a valid inspection receipt. - Attempt refund with a forged status change and verify no provider call. Deliverables - Refund precondition guard and bypass regression Rollout and recovery: Deploy guarded transitions before exposing administrative actions; stop refund dispatch on missing provenance. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. ### Reconcile uncertain work Exercise crashes and publish accurate operational status. #### ASAGA-108 — Show return workflow progress without hiding unresolved compensation **Story · Medium priority · Foundational** noCV practice brief v5 · ASAGA-108 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile uncertain work. Depends on: ASAGA-105, ASAGA-106, ASAGA-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Distributed systems 30% · Privacy 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 support console shows cancelled even when the label-void request timed out and the customer might still use it. Acceptance criteria - Display business intent separately from confirmed provider outcomes. - Highlight pending reconciliation and compensation states. - Exclude provider credentials and raw customer payloads. Implementation constraints - Use a dedicated support projection with tenant authorization. Verification - Display a fully compensated synthetic return. - Display unknown voiding as unresolved and deny another tenant's workflow. Deliverables - Scoped support workflow projection Rollout and recovery: Enable read-only status first; keep uncertainty visible when adapters are unavailable. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-109 — Replay a return workflow from its durable history after an orchestrator crash **Task · Medium priority · Expert** noCV practice brief v5 · ASAGA-109 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile uncertain work. Depends on: ASAGA-104, ASAGA-105, ASAGA-106, ASAGA-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. A worker restarts halfway through a return and must decide which steps can resume without repeating side effects. Acceptance criteria - Reconstruct the current state from durable facts and generations. - Reconcile outstanding provider commands before redispatch. - Preserve completed facts and compensation history. Implementation constraints - Inject crashes between every modeled commit and provider response boundary. Verification - Replay a completed and a partially compensated synthetic return. - Crash after refund acceptance and verify recovery does not issue a second refund. Deliverables - Workflow recovery harness and interruption matrix Rollout and recovery: Run before enabling automatic recovery; pause ambiguous workflows while continuing unaffected ones. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. #### ASAGA-110 — Write the operator handoff for a return that cannot be fully compensated **Chore · Medium priority · Intermediate** noCV practice brief v5 · ASAGA-110 · Coordinate equipment returns with explicit compensations Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile uncertain work. Depends on: ASAGA-103, ASAGA-108, ASAGA-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. A provider confirms an effect that cannot be reversed, and support needs to close the technical incident without fabricating a clean rollback. Acceptance criteria - List confirmed effects, attempted corrections and unresolved consequences. - Define authorized manual decisions separately from automated transitions. - Preserve original receipts and incident provenance. Implementation constraints - Use a fabricated return and no actual financial advice or transfer. Verification - Document a successful full compensation case. - Document an irreversible fake-provider outcome without marking it rolled back. Deliverables - Return exception runbook and worked incident Rollout and recovery: Review exceptions before manual action; append resolutions instead of rewriting workflow history. Project prerequisites: Create synthetic return records and fake inspection, shipping and refund adapters. Use integer money values and no real payments or messages. Engineer value: Practice durable workflow state, compensation and uncertain outcomes. Company value: Review recoverable business operations without assuming distributed transactions. 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. ## AMERGE — Synchronize offline equipment inspections without silent overwrites A fictional field team inspects equipment with intermittent connectivity. Two tablets can edit the same checklist and an old upload may restore a deleted finding. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice offline synchronization, causal revisions and conflict resolution. **Company value:** Review whether field work survives disconnection without hiding conflicting observations. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create two local client-state simulators and a synthetic inspection API. - Use fabricated notes and local attachment bytes. ### Define change identities Represent offline edits and authority boundaries. #### AMERGE-101 — Define offline change envelopes with stable client operation IDs **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-101 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · API design 30% · Mobile 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 tablet retries saved edits with new request IDs, so the server creates duplicate inspection findings. Acceptance criteria - Include operation ID, inspection ID, base revision and change type. - Keep device display name separate from identity. - Reject unknown envelope versions before mutation. Implementation constraints - Use generated disposable client identities. Verification - Replay the same synthetic change envelope twice. - Change content under the same operation ID and return conflict. Deliverables - Offline operation contract Rollout and recovery: Publish the envelope before enabling sync retries; keep incompatible operations in local pending state. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-102 — Require current inspection access before applying a queued offline change **Task · High priority · Intermediate** noCV practice brief v5 · AMERGE-102 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: AMERGE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Distributed systems 30% · Mobile 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 contractor loses project access while offline, then reconnects with a batch of previously authorized edits. Acceptance criteria - Reauthorize each target at synchronization time. - Reject revoked or cross-organization changes without partial hidden writes. - Return safe per-operation outcomes under the declared batch policy. Implementation constraints - Offline possession of data is not continuing write authority. Verification - Apply a queued edit for a still-authorized actor. - Revoke access before reconnect and verify no inspection mutation. Deliverables - Sync authorization boundary Rollout and recovery: Enable scope checks before bulk sync; retain rejected local operations for user review. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-103 — Distinguish independent checklist edits from conflicting edits **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-103 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: AMERGE-101, AMERGE-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 sync service treats every concurrent change as either a blanket overwrite or a blanket conflict. Acceptance criteria - Define fields that can merge independently. - Require explicit conflict when the same protected value diverges. - Document attachment and deletion conflict rules separately. Implementation constraints - Use a small fixed checklist; avoid a general-purpose merge language. Verification - Merge edits to two independent checklist items. - Edit the same item differently and preserve both proposed values as a conflict. Deliverables - Merge policy table and worked examples Rollout and recovery: Review the policy before automatic merging; keep unresolved fields on manual resolution. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. ### Synchronize and resolve Handle duplicates, conflicts and deletion safely. #### AMERGE-104 — Apply offline operations with a durable deduplication record **Story · Medium priority · Advanced** noCV practice brief v5 · AMERGE-104 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-101, AMERGE-102, AMERGE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database 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. The server applies a change, loses the response, then reapplies it after the tablet reconnects. Acceptance criteria - Commit operation identity and inspection mutation atomically. - Return the original safe outcome for identical retries. - Keep rejected authorization separate from accepted-operation history. Implementation constraints - Scope deduplication to the authorized client and operation identity. Verification - Drop the response after commit and retry to one revision. - Force transaction rollback and verify the operation remains retryable without a partial edit. Deliverables - Idempotent sync transaction Rollout and recovery: Canary one synthetic client; pause replay when canonical operation identity is inconsistent. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-105 — Preserve concurrent inspection findings as explicit conflicts **Task · Medium priority · Advanced** noCV practice brief v5 · AMERGE-105 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-103, AMERGE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Two inspectors change a safety finding from different base revisions and last-write-wins hides one observation. Acceptance criteria - Detect divergence from the declared base revision. - Persist both proposals and their operation identities. - Block authoritative resolution until a permitted resolution command chooses or combines them. Implementation constraints - Do not infer which observer is correct from arrival time. Verification - Submit conflicting changes in both arrival orders and retain equivalent conflict facts. - Attempt ordinary edit completion over an unresolved conflict and reject it. Deliverables - Conflict record model and order-invariance tests Rollout and recovery: Enable conflict capture before automatic reconciliation; leave existing ambiguous cases unresolved. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-106 — Resolve an inspection conflict against its current proposal set **Story · Medium priority · Intermediate** noCV practice brief v5 · AMERGE-106 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 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. A reviewer resolves a conflict while a third offline proposal arrives, silently discarding the new observation. Acceptance criteria - Bind resolution to the expected conflict revision and proposal identities. - Record resolution as an append-only fact. - Reject stale resolution without deleting proposals. Implementation constraints - Require the reviewer's current inspection permission. Verification - Resolve an unchanged two-proposal conflict. - Add a third proposal before commit and verify stale resolution conflicts. Deliverables - Guarded conflict resolution command Rollout and recovery: Canary synthetic review; reopen by appending a new conflict fact rather than editing history. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-107 — Keep deleted findings deleted when an old tablet reconnects **Task · High priority · Expert** noCV practice brief v5 · AMERGE-107 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-103, AMERGE-104, AMERGE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Data 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 tablet that missed a deletion resubmits its old finding and recreates content the team intentionally removed. Acceptance criteria - Represent deletion with an ordered tombstone. - Reject stale recreation under the declared merge policy. - Define tombstone retention and resnapshot requirements. Implementation constraints - Avoid using wall-clock time alone to order deletion and recreation. Verification - Delete a finding and replay an older update. - Expire supported replay history in the simulator and require resnapshot rather than guessing. Deliverables - Tombstone protocol and stale-client cases Rollout and recovery: Deploy tombstones before cleanup; halt tombstone removal until the resnapshot contract is available. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. ### Recover interrupted synchronization Reconcile attachments and explain remaining conflicts. #### AMERGE-108 — Finalize offline attachments by verified content identity **Task · Medium priority · Advanced** noCV practice brief v5 · AMERGE-108 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-104, AMERGE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Distributed systems 30% · Mobile 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. An inspection references a photo before its interrupted upload completes, producing broken evidence links in the field report. Acceptance criteria - Stage attachment uploads separately from finding references. - Finalize only exact verified object generation and content hash. - Keep incomplete attachments visible as pending without public links. Implementation constraints - Use synthetic images or byte fixtures; no personal photographs are needed. Verification - Complete a valid synthetic attachment and resolve its stable identity. - Interrupt upload or alter bytes and verify the finding cannot publish an invalid link. Deliverables - Attachment finalization contract Rollout and recovery: Canary local attachments; keep staged objects private and resume or discard only exact generations. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-109 — Resume inspection synchronization from a server-confirmed cursor **Task · Medium priority · Expert** noCV practice brief v5 · AMERGE-109 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-104, AMERGE-106, AMERGE-107, AMERGE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Mobile 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 tablet stores a local cursor before receiving server confirmation and skips updates after a crash. Acceptance criteria - Advance the local acknowledged cursor only after durable server outcome. - Bind cursor to inspection scope and sync generation. - Require resnapshot when the server cannot honor the retained history window. Implementation constraints - Use two client simulators with controlled interruption points. Verification - Crash during a sync page and resume without missing confirmed operations. - Use an expired or cross-scope cursor and reject incremental sync safely. Deliverables - Cursor recovery protocol and crash harness Rollout and recovery: Enable incremental sync after the resnapshot path passes; retain local pending operations until acknowledged. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-110 — Show sync completion separately from resolved inspection conflicts **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-110 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-106, AMERGE-108, AMERGE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Distributed systems 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 tablet says all synced even though uploaded changes contain unresolved conflicts and a pending attachment. Acceptance criteria - Report transport acknowledgement, conflict state and attachment state separately. - Keep rejected operations visible with safe reasons. - Never equate uploaded data with an approved inspection. Implementation constraints - Use a local status projection with accessible plain-language labels. Verification - Display a fully acknowledged conflict-free synthetic inspection. - Acknowledge a conflicting batch and retain unresolved status. Deliverables - Sync status contract and state examples Rollout and recovery: Publish precise status labels; restore prior layout without collapsing distinct states. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. ## ABATCH — Aggregate parallel risk checks without losing partial outcomes A fictional vendor portal runs format, policy and duplicate checks in parallel. A slow checker blocks completion, while duplicate callbacks can produce contradictory final summaries. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, Provider interfaces. **Engineer value:** Practice fan-out/fan-in, deadline policies and immutable aggregation. **Company value:** Review trustworthy partial-result handling and controllable parallel work. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic document identities and three fake check providers. - No real risk scoring, hiring decisions or candidate execution is included. ### Define independent check facts Specify input identity, required checks and result states. #### ABATCH-101 — Freeze the required check set when a document review run starts **Task · Medium priority · Foundational** noCV practice brief v5 · ABATCH-101 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 configuration change adds a checker while a run is in progress, so the completion predicate changes halfway through. Acceptance criteria - Record exact checker identities and versions per run. - Bind the set to immutable document input identity. - New configuration affects only new runs. Implementation constraints - Use three deterministic fake checks with no capability scoring. Verification - Start runs before and after a check-set change. - Finish the older run using its original required set. Deliverables - Review-run manifest Rollout and recovery: Publish frozen manifests before parallel dispatch; retain prior checker versions for replay. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-102 — Define pass, fail, unavailable and not-applicable check outcomes **Task · Medium priority · Intermediate** noCV practice brief v5 · ABATCH-102 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: ABATCH-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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 timed-out policy checker returns an empty findings list, which the aggregator interprets as passed. Acceptance criteria - Use explicit outcome states with bounded structured details. - Require justification for not-applicable under the declared contract. - Keep unavailable distinct from an empty successful result. Implementation constraints - Reject unsupported fields and prohibit demographic or personality inferences. Verification - Accept a valid empty successful check. - Timeout a checker and retain unavailable rather than pass. Deliverables - Check-result schema and semantic cases Rollout and recovery: Deploy result validation before aggregate updates; quarantine incompatible provider output. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-103 — Bound parallel check fan-out per organization and run **Task · Medium priority · Foundational** noCV practice brief v5 · ABATCH-103 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: ABATCH-101, ABATCH-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Performance engineering 30% · Platform 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. One tenant submits many documents and the coordinator starts every check immediately, exhausting provider slots. Acceptance criteria - Set explicit per-run and per-tenant in-flight limits. - Persist queued attempts instead of dropping them. - Return admission status separate from check completion. Implementation constraints - Use documented synthetic limits and a fake provider counter. Verification - Dispatch a permitted number of synthetic checks. - Exceed the tenant limit and verify excess work remains queued without provider calls. Deliverables - Fan-out admission guard Rollout and recovery: Canary conservative limits; pause admission when provider capacity is unknown. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. ### Coordinate parallel outcomes Dispatch, deduplicate and finalize with explicit deadlines. #### ABATCH-104 — Dispatch each check through a durable deterministic attempt identity **Story · Medium priority · Advanced** noCV practice brief v5 · ABATCH-104 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-101, ABATCH-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database 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 coordinator crashes after dispatching one checker and cannot tell which of the three still needs to start. Acceptance criteria - Persist check-attempt identity and outbox dispatch per required checker. - Keep dispatch retries bound to the same input and checker version. - Reject contradictory reuse of an attempt identity. Implementation constraints - Call providers outside the database transaction. Verification - Crash after one dispatched check and resume remaining work. - Replay an outbox fact and keep one logical provider attempt. Deliverables - Check dispatch transaction and crash probe Rollout and recovery: Prototype with fake providers; stop new runs if attempt identity cannot be persisted. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-105 — Deduplicate callbacks without accepting contradictory check results **Task · High priority · Advanced** noCV practice brief v5 · ABATCH-105 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-102, ABATCH-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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 provider retries its callback and later sends a changed result for the same attempt ID. Acceptance criteria - Identical callback retries resolve one recorded result. - Different terminal content for the same attempt creates a conflict. - Validate run, input and checker identities before recording. Implementation constraints - Use canonical result hashes and authenticated fixture callbacks. Verification - Deliver the same terminal callback twice. - Alter a terminal result or input hash and keep the accepted result plus a visible conflict. Deliverables - Callback ingestion guard Rollout and recovery: Canary callback handling; quarantine contradictory provider output without rewriting terminal facts. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-106 — Finalize aggregates only from the frozen required check set **Task · High priority · Expert** noCV practice brief v5 · ABATCH-106 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-101, ABATCH-102, ABATCH-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 optional checker finishes quickly and accidentally satisfies a counter-based completion condition while a required checker is missing. Acceptance criteria - Evaluate completeness by exact required identities. - Compute aggregate state from validated immutable check facts. - Reject finalization when required results are missing or conflicting. Implementation constraints - Define aggregate output as review status, never an opaque hire/reject score. Verification - Finish all required checks and produce the expected status. - Complete extra optional checks while omitting one required check and block completion. Deliverables - Aggregate reducer and completeness tests Rollout and recovery: Enable guarded finalization before publishing results; retain pending state on missing authority. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-107 — Apply a run deadline without rewriting late check facts **Story · Medium priority · Intermediate** noCV practice brief v5 · ABATCH-107 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-102, ABATCH-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 slow checker returns after the review deadline and overwrites a summary already shown to the user. Acceptance criteria - Define a deadline terminal state with explicit incomplete checks. - Preserve late results as appended facts without mutating the frozen summary. - Allow a new run or reviewed amendment under an explicit policy. Implementation constraints - Use an injected clock and exact boundary cases. Verification - Complete required checks before deadline. - Return one check after deadline and retain the original summary plus late-result visibility. Deliverables - Deadline finalization and late-result cases Rollout and recovery: Canary synthetic short deadlines; create new runs when a policy change requires reevaluation. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. ### Recover incomplete runs Replay work and explain aggregate provenance. #### ABATCH-108 — Recover outstanding checks by querying provider attempt identity **Task · Medium priority · Expert** noCV practice brief v5 · ABATCH-108 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-104, ABATCH-105, ABATCH-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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. After a restart, several attempts are marked dispatched but have no callback; immediate resubmission may duplicate costly work. Acceptance criteria - Reconcile each unresolved attempt through its provider identity. - Redispatch only under the adapter's declared idempotency contract. - Keep unknown provider state visible and bounded. Implementation constraints - Use fake providers that model lost callbacks and unavailable lookup. Verification - Recover a completed check whose callback was lost. - Make provider lookup unavailable and verify no unsupported success or duplicate attempt. Deliverables - Outstanding-attempt reconciler Rollout and recovery: Start recovery with bounded batches; suspend affected adapters when identity guarantees fail. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-109 — Produce a result provenance view that names missing and conflicting checks **Story · Medium priority · Foundational** noCV practice brief v5 · ABATCH-109 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-105, ABATCH-106, ABATCH-107, ABATCH-108. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · API design 30% · Privacy 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. Users receive only a summary label and cannot inspect whether every required checker actually ran. Acceptance criteria - List frozen checker versions and input identity. - Show outcome, unavailable and conflict states separately. - Keep internal prompts, secrets and raw provider traces out of the view. Implementation constraints - Use public practice facts only; this is not noCV assessment evidence. Verification - Inspect a complete synthetic aggregate. - Inspect a deadline result and clearly identify the missing checker. Deliverables - Safe provenance projection Rollout and recovery: Publish read-only provenance with aggregate status; hide fields that fail schema review. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-110 — Exercise the parallel-check coordinator under reordered failures **Chore · Medium priority · Advanced** noCV practice brief v5 · ABATCH-110 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-105, ABATCH-106, ABATCH-107, ABATCH-108, ABATCH-109. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Distributed systems 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. Happy-path tests always complete checks in the same order and miss a race between deadline finalization and the last callback. Acceptance criteria - Run permutations of declared completion, timeout and conflict events. - Assert one immutable summary and complete retained check history. - Record any unsupported adapter guarantee as a failing readiness condition. Implementation constraints - Use a deterministic event scheduler; no arbitrary sleeps. Verification - Run all required checks in several completion orders with equal final semantics. - Race final callback with deadline and verify the declared single outcome. Deliverables - Deterministic coordinator fault harness Rollout and recovery: Require the harness before adapter changes; retain the prior coordinator version if invariants fail. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. ## ACACHE — Keep shared product caches consistent across writers A fictional wholesale portal caches product availability descriptions across several API instances. Delayed invalidations and slow refreshes bring back old content after edits. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, Redis. **Engineer value:** Practice cache consistency, version guards and recoverable invalidation. **Company value:** Review fast derived reads without losing authoritative state or tenant isolation. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create two local cache clients and a synthetic authoritative product store. - Use a fake clock and controllable read/write barriers. ### Define cache meaning Bind keys, versions and freshness to authoritative data. #### ACACHE-101 — Define cache keys from every product-view authority input **Task · High priority · Foundational** noCV practice brief v5 · ACACHE-101 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Two customer organizations request the same SKU but have different visible product descriptions, and the shared cache returns the first result. Acceptance criteria - Bind keys to organization, view policy and product identity. - Authorize before cache lookup. - Version the key namespace for incompatible projection changes. Implementation constraints - Do not include secrets or raw personal data in keys. Verification - Cache different permitted views of the same synthetic SKU. - Request another organization's view and verify no cross-scope hit. Deliverables - Canonical cache-key contract Rollout and recovery: Introduce a fresh namespace and expire the affected old namespace. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-102 — Specify what stale product data the portal may display **Task · Medium priority · Intermediate** noCV practice brief v5 · ACACHE-102 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: ACACHE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 cache uses one TTL for descriptive text and order-critical availability, though they have different correctness needs. Acceptance criteria - Classify fields by tolerated staleness. - Keep authoritative order decisions outside stale display data. - Define fresh, stale-allowed and unusable cache states. Implementation constraints - Use explicit hypothetical freshness bounds with product approval noted as pending. Verification - Serve stale descriptive text within the declared window. - Reject using stale cached availability to authorize an order. Deliverables - Cache consistency matrix Rollout and recovery: Review the matrix before changing TTLs; leave unresolved critical reads authoritative. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-103 — Record authoritative product revision with each cached projection **Task · Medium priority · Foundational** noCV practice brief v5 · ACACHE-103 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: ACACHE-101, ACACHE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. An API instance receives two cached values but cannot tell which reflects the newer database update. Acceptance criteria - Store source revision and projection version with the value. - Reject malformed or unknown envelopes. - Keep fetch time separate from source revision. Implementation constraints - Do not use cache write time as data ordering authority. Verification - Compare cached revisions 7 and 8. - Read an envelope missing revision and treat it as unusable. Deliverables - Versioned cache envelope Rollout and recovery: Deploy readers that accept the envelope before enabling new writers; miss safely on legacy values. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. ### Guard shared refreshes Order writes, invalidations and concurrent fills. #### ACACHE-104 — Commit product changes with a durable invalidation fact **Story · High priority · Advanced** noCV practice brief v5 · ACACHE-104 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-101, ACACHE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database 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 product write commits and then the process dies before deleting shared cache keys. Acceptance criteria - Persist the product revision and invalidation outbox fact atomically. - Bind invalidation identity to product scope and revision. - Replay invalidation safely after a crash. Implementation constraints - Cache failure must not roll back an already committed product change. Verification - Crash after database commit and dispatch the retained invalidation. - Replay the same invalidation and retain correct cache state. Deliverables - Product/outbox transaction and recovery test Rollout and recovery: Canary one synthetic product class; monitor pending invalidations and fall back to authoritative reads when stale bounds expire. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-105 — Prevent a slow cache fill from overwriting a newer product revision **Bug · High priority · Expert** noCV practice brief v5 · ACACHE-105 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-103, ACACHE-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 80% · Database 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 read for revision 7 starts before an edit, then finishes after revision 8 has already been cached and overwrites it. Acceptance criteria - Use an atomic revision comparison when publishing a fill. - Reject lower source revisions regardless of completion order. - Keep projection-version incompatibility separate from source ordering. Implementation constraints - Implement with a bounded Redis script or provider-level compare-and-set. Verification - Pause an old fill, publish the new revision, then resume the old fill. - Attempt a malformed revision and verify it cannot replace the current value. Deliverables - Version-guarded fill and race reproduction Rollout and recovery: Canary guarded fills; disable cache publication if the adapter lacks atomic comparison. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-106 — Handle delayed invalidation without evicting a newer cache revision unnecessarily **Task · Medium priority · Advanced** noCV practice brief v5 · ACACHE-106 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-104, ACACHE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. An old invalidation arrives after a fresh fill and deletes valid data, triggering avoidable refresh work across instances. Acceptance criteria - Compare invalidation revision with cached source revision. - Evict or mark stale only entries covered by the event. - Treat missing or incompatible envelopes as safe misses. Implementation constraints - Keep invalidation decisions atomic with cache state inspection. Verification - Deliver revision 7 invalidation against cached revision 8 and retain it. - Deliver matching/newer invalidation and enforce the declared stale behavior. Deliverables - Revision-aware invalidation and ordering tests Rollout and recovery: Enable after envelope rollout; fall back to conservative eviction on unknown formats. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-107 — Bound duplicate refresh work across API instances **Story · Medium priority · Intermediate** noCV practice brief v5 · ACACHE-107 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-102, ACACHE-105, ACACHE-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. A popular product expires and every API instance refreshes it simultaneously, increasing pressure on the source database. Acceptance criteria - Use a bounded per-key refresh ownership mechanism. - Waiters have a deadline and declared stale/miss fallback. - Expired refresh ownership cannot publish an older revision. Implementation constraints - A refresh lock reduces duplicate work; revision fencing still protects correctness. Verification - Request one expired synthetic key from two clients and observe bounded refresh calls. - Pause the owner past expiry and verify stale completion cannot overwrite newer data. Deliverables - Shared refresh coordinator and expired-owner test Rollout and recovery: Canary a small key cohort; disable coordination while retaining revision guards if locks stall. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. ### Recover cache uncertainty Handle outages, reconcile generations and expose staleness. #### ACACHE-108 — Fall back predictably when the shared cache is unavailable **Task · Medium priority · Advanced** noCV practice brief v5 · ACACHE-108 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-102, ACACHE-104, ACACHE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Site reliability 30% · 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. A Redis outage makes every request retry repeatedly, overwhelming the authoritative database while users wait. Acceptance criteria - Bound cache attempts and stop retry amplification. - Apply an explicit source-read admission limit. - Return the declared degraded or unavailable response when both paths lack capacity. Implementation constraints - Use local adapter failures and synthetic requests. Verification - Disconnect the cache and serve an admitted authoritative read. - Exceed fallback admission and return a bounded failure without unbounded source calls. Deliverables - Cache-outage fallback and overload probe Rollout and recovery: Canary with conservative fallback limits; shed excess reads until cache recovery is verified. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-109 — Reconcile cache generations after a projection-schema release **Chore · Medium priority · Expert** noCV practice brief v5 · ACACHE-109 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-103, ACACHE-105, ACACHE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 70% · Platform 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. A new release changes product projection shape while old and new API instances share cached envelopes. Acceptance criteria - Use explicit projection namespaces and compatible-reader declarations. - Warm a new namespace from authoritative revisions. - Retire the old namespace only after old readers are gone. Implementation constraints - Do not rewrite old cache values into a guessed new schema. Verification - Run mixed-version clients against their declared namespaces. - Send a new envelope to an incompatible reader and verify safe miss or rejection. Deliverables - Cache-generation rollout and compatibility drill Rollout and recovery: Switch one synthetic cohort first; restore its previous namespace while keeping authoritative data unchanged. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. #### ACACHE-110 — Expose cache freshness observations without claiming source correctness **Task · Medium priority · Foundational** noCV practice brief v5 · ACACHE-110 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-102, ACACHE-108, ACACHE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Site reliability 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. The dashboard shows a high hit rate as proof the product data is correct, though hit count says nothing about revision freshness. Acceptance criteria - Report hit/miss, source revision and observed freshness separately. - Mark unknown source comparison explicitly. - Avoid exposing product payloads in generic telemetry. Implementation constraints - Metrics describe cache behavior, not business-data correctness. Verification - Observe a fresh hit with a known source revision. - Hide source revision availability and report unknown freshness despite a cache hit. Deliverables - Cache health projection and semantics notes Rollout and recovery: Add freshness diagnostics before tuning hit-rate targets; retain unknown states during outages. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. 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. ## BMONO — Monorepo change planner A fictional internal tools team maintains eighteen packages. Engineers currently run everything because the affected-package script occasionally misses downstream consumers. **Field:** Developer tooling. **Suggested stack:** TypeScript, pnpm, Git. **Engineer value:** Practice graph analysis, reproducible commands, and safe developer-tool failure modes. **Company value:** Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. **Delivery agreement:** Deliver a local planning CLI, regression fixtures, and an adoption note; hosted CI integration is optional. ### Setup prerequisites - Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. ### Map the inputs Define which repository changes affect which commands. #### BMONO-101 — Document task inputs beyond package dependencies **Task · Medium priority · Foundational** noCV practice brief v5 · BMONO-101 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map the 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 root compiler change passed CI although an unchanged package no longer compiled. Inventory inputs the planner must treat as shared. Acceptance criteria - List compiler, lockfile, environment, and generator inputs separately. - Assign an owner and invalidation rule to each input. - Include one change that legitimately affects every package. Implementation constraints - Use the local fixture; do not inspect private repositories. Verification - Trace a package-only edit to its expected tasks. - Trace an unknown root input to conservative full selection. Deliverables - Input ownership matrix. Rollout and recovery: Review the matrix before enabling selection; retain full CI as fallback. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-102 — Parse workspace manifests without executing package scripts **Task · High priority · Intermediate** noCV practice brief v5 · BMONO-102 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map the inputs. Depends on: BMONO-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Security 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 planner must inspect an unfamiliar checkout without triggering install hooks or repository commands. Acceptance criteria - Resolve workspace package names and paths from manifests. - Reject duplicate names and paths outside the checkout. - Report malformed JSON with file and safe location. Implementation constraints - Treat manifests as data; never evaluate imported configuration. Verification - Load valid nested workspace fixtures. - Reject traversal, duplicate identity, and invalid JSON fixtures. Deliverables - Manifest parser and fixture tests. Rollout and recovery: Use read-only inventory mode first; fall back to full CI on parser errors. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. ### Build the planner Produce deterministic affected sets with conservative fallbacks. #### BMONO-103 — Handle cycles in the downstream impact graph **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-103 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-102. Difficulty: Advanced. Estimated focused work: 210 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. Two shared packages depend on each other through development tooling, and recursive traversal never finishes. Acceptance criteria - Collapse or explicitly track cycles without dropping members. - Include transitive dependents once each. - Sort output stably regardless of manifest enumeration order. Implementation constraints - Distinguish runtime and development edges in the plan explanation. Verification - Resolve a diamond graph with one cycle. - Verify a disconnected package stays excluded and traversal terminates. Deliverables - Cycle-safe graph traversal. Rollout and recovery: Compare results with full package selection; disable selective mode if membership differs. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-104 — Resolve renamed and deleted files against both revisions **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-104 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-102. Difficulty: Advanced. Estimated focused work: 180 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 package deletion disappears from the current workspace map and incorrectly produces an empty plan. Acceptance criteria - Read changed paths from a declared base and head. - Account for both source and destination of renames. - Select former dependents when a package is removed. Implementation constraints - Do not assume a remote branch exists in a shallow checkout. Verification - Plan a package move with unchanged contents. - Exercise missing base and deleted-manifest cases with explicit fallback. Deliverables - Revision-aware path ownership logic. Rollout and recovery: Ship behind diagnostic output; preserve full CI for unresolved history. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-105 — Explain why each selected command is necessary **Story · Medium priority · Intermediate** noCV practice brief v5 · BMONO-105 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-103, BMONO-104. Difficulty: Intermediate. Estimated focused work: 120 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. Maintainers cannot review a large affected set because the tool prints only package names. Acceptance criteria - Attach at least one changed input to each selected task. - Represent transitive paths without unbounded recursion. - Emit stable JSON and readable plain-text output. Implementation constraints - Keep absolute workstation paths out of exported plans. Verification - Snapshot a direct and a transitive explanation. - Verify cyclic and missing-owner explanations remain bounded. Deliverables - Plan explanation renderer. Rollout and recovery: Enable explanation output immediately; keep command execution opt-in. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-106 — Make cache keys include generator versions and relevant environment **Bug · High priority · Advanced** noCV practice brief v5 · BMONO-106 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-101, BMONO-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 70% · Storage 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. Generated client code changed after a tool upgrade while the cache reused an old successful result. Acceptance criteria - Hash declared inputs using stable ordering. - Include generator version and allowlisted environment names. - Exclude secrets and unrelated environment values from key material. Implementation constraints - A cache hit must never authorize skipping an undeclared dependency. Verification - Change each declared input and observe key changes. - Verify secret values are absent from keys and diagnostic output. Deliverables - Cache-key contract and regression checks. Rollout and recovery: Invalidate old keys on adoption; revert to uncached commands if key provenance is missing. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-107 — Detect stale plan execution after the worktree changes **Task · High priority · Intermediate** noCV practice brief v5 · BMONO-107 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the planner. Depends on: BMONO-105, BMONO-106. Difficulty: Intermediate. Estimated focused work: 150 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 developer reviews a plan, edits another package, then executes commands from the earlier plan. Acceptance criteria - Bind plans to revision and relevant working-tree digests. - Check the binding immediately before execution. - Return a distinct stale-plan error with regeneration guidance. Implementation constraints - Do not discard or reset local edits. Verification - Execute an unchanged reviewed plan successfully. - Modify a tracked input and reject the stale plan before spawning commands. Deliverables - Plan freshness guard. Rollout and recovery: Require freshness for execution; allow explicit regeneration without modifying the checkout. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. ### Adopt safely Compare selective runs against full runs before enforcement. #### BMONO-108 — Bound parallel commands and stop cleanly on cancellation **Task · Medium priority · Advanced** noCV practice brief v5 · BMONO-108 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-107. Difficulty: Advanced. Estimated focused work: 210 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. Selective tasks saturate a laptop and leave child processes alive when the parent command is interrupted. Acceptance criteria - Enforce configured parallelism between one and the fixture package count. - Stop scheduling new work after cancellation. - Report completed, failed, and cancelled tasks separately. Implementation constraints - Execute only trusted fixture commands in this exercise. Verification - Observe the concurrency ceiling with delayed fixtures. - Cancel mid-run and verify owned child processes terminate. Deliverables - Bounded command scheduler. Rollout and recovery: Default to conservative parallelism; provide serial mode for recovery. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-109 — Compare selective and full plans over a recorded change corpus **Task · High priority · Expert** noCV practice brief v5 · BMONO-109 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-103, BMONO-104, BMONO-106, BMONO-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Developer tooling 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. Before making selection mandatory, the team needs a defensible way to find false negatives rather than celebrate shorter CI runs. Acceptance criteria - Define a corpus covering root, package, rename, and deletion changes. - Compare selected task outcomes with full-run outcomes under identical inputs. - Block adoption on an unexplained excluded failure and record uncertainty. Implementation constraints - Report workload and machine limits; do not promise general speedups from local measurements. Verification - Detect an intentionally omitted shared input. - Show a safe exclusion and publish reproducible comparison commands. Deliverables - Adoption assessment and mismatch report. Rollout and recovery: Run in shadow mode for the corpus; retain a one-command full-run override. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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. #### BMONO-110 — Write a maintainer playbook for adding a new task input **Chore · Low priority · Foundational** noCV practice brief v5 · BMONO-110 · Monorepo change planner Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Adopt safely. Depends on: BMONO-109. 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. New generators will appear after launch, and ownership of the invalidation map is currently undocumented. Acceptance criteria - Show how to declare one generator input and its owner. - Include the regression case required before selective execution. - Document diagnosis of unexpected full and empty plans. Implementation constraints - Use examples from the implemented planner rather than future capabilities. Verification - Follow the guide to add a synthetic generator input. - Verify omission is detected by the comparison procedure. Deliverables - Maintainer guide with worked example. Rollout and recovery: Link the guide from CLI help; withdraw selective defaults if ownership becomes unclear. Project prerequisites: Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes. Engineer value: Practice graph analysis, reproducible commands, and safe developer-tool failure modes. Company value: Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers. 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 — 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. ## BDBMIG — Database migration review workbench A fictional subscription service has accumulated migration scripts with unclear lock risks and no consistent rehearsal output. **Field:** Developer tooling. **Suggested stack:** TypeScript, PostgreSQL, SQL. **Engineer value:** Practice migration tooling, lock reasoning, and clear developer feedback. **Company value:** Provide reviewers with repeatable migration checks and explicit recovery limits. **Delivery agreement:** Deliver a local review CLI and SQL rehearsals; do not connect to production databases. ### Setup prerequisites - Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. ### Inspect changes Make proposed SQL and risk assumptions visible. #### BDBMIG-101 — Add a migration inventory with checksums and sequence gaps **Task · Medium priority · Foundational** noCV practice brief v5 · BDBMIG-101 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Database 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. Two branches introduced migrations with the same sequence number. Acceptance criteria - List migration order and file digests. - Reject duplicate sequence identifiers. - Report missing predecessors without executing SQL. Implementation constraints - Read migration files as text only. Verification - Inventory a valid sequence. - Detect duplicate IDs and an edited historical file. Deliverables - Inventory command. Rollout and recovery: Adopt read-only checks first; resolve history discrepancies before applying migrations. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-102 — Flag table rewrites and long-held locks for review **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-102 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: BDBMIG-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Developer tooling 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 small-looking column change can block writes on a large table. Acceptance criteria - Identify a documented bounded set of risky SQL forms. - Explain potential lock or rewrite behavior. - Mark unrecognized forms as requiring manual review. Implementation constraints - This heuristic must not label arbitrary SQL safe. Verification - Flag a configured rewrite example. - Leave an unsupported statement explicitly unclassified. Deliverables - Risk annotations and limitations. Rollout and recovery: Run advisory checks; preserve manual review for unsupported SQL. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-103 — Prevent migration commands from targeting unapproved databases **Task · High priority · Intermediate** noCV practice brief v5 · BDBMIG-103 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: BDBMIG-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Security 30% · Database 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. An engineer copied a connection string from another terminal. Acceptance criteria - Require an explicit local target allowlist. - Display sanitized target identity before rehearsal. - Reject missing, remote, or ambiguous target configuration. Implementation constraints - Never print passwords or complete connection URLs. Verification - Accept the named scratch database. - Reject a remote hostname and inspect sanitized errors. Deliverables - Target guard. Rollout and recovery: Default to no execution until a local target is configured. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. ### Rehearse locally Check application compatibility and interrupted execution. #### BDBMIG-104 — Capture lock waits during a synthetic concurrent workload **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-104 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-102, BDBMIG-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Performance engineering 30% · Developer tooling 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. Reviewers need observations of a migration while ordinary writes continue. Acceptance criteria - Run bounded synthetic writes against the local fixture. - Capture migration duration and sampled lock waits. - Record dataset size and workload parameters with results. Implementation constraints - Set statement and lock timeouts; avoid extrapolating local results to production. Verification - Observe a compatible migration under writes. - Force lock contention and verify timeout cleanup. Deliverables - Lock rehearsal report. Rollout and recovery: Use reports for review; stop rehearsal on timeout and reset scratch data. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-105 — Test old and new application queries during expand-contract changes **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-105 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Quality engineering 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. An application rollback fails because the migration removed the column the previous build reads. Acceptance criteria - Define old and new query fixtures. - Run both after the expansion migration. - Reject contraction while the old-query support window is open. Implementation constraints - Limit scope to one renamed subscription column. Verification - Verify dual compatibility after expansion. - Demonstrate the old query failing after premature contraction. Deliverables - Compatibility rehearsal. Rollout and recovery: Ship expansion first; delay contraction until the documented rollback window closes. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-106 — Resume a chunked backfill after a process interruption **Bug · High priority · Advanced** noCV practice brief v5 · BDBMIG-106 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-104, BDBMIG-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. The backfill restarts from the beginning and repeatedly touches already-migrated subscriptions. Acceptance criteria - Checkpoint a stable key after committed chunks. - Skip completed rows without changing their meaning. - Bound batch size and transaction duration. Implementation constraints - Make derived values deterministic and record invalid rows separately. Verification - Interrupt after two chunks and resume. - Retry one committed chunk and verify unchanged final values. Deliverables - Resumable backfill command. Rollout and recovery: Start with small batches; pause safely and retain checkpoints on failures. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. ### Prepare deployment Package evidence and recovery steps for review. #### BDBMIG-107 — Distinguish reversible schema changes from irreversible data loss **Task · High priority · Expert** noCV practice brief v5 · BDBMIG-107 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-105, BDBMIG-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Developer tooling 20% · System 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. The deployment template says every migration can be rolled back, even when original values are discarded. Acceptance criteria - Classify schema reversal and data recovery separately. - Identify the exact point original data becomes unavailable. - Compare forward repair, backup restore, and application rollback for this migration. Implementation constraints - Do not invent recoverability beyond captured data. Verification - Rehearse the selected recovery with synthetic rows. - Show the unrecoverable case when no original data was retained. Deliverables - Recovery decision record. Rollout and recovery: Block contraction until recovery assumptions and retained-data lifetime are reviewed. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-108 — Produce a bounded migration review bundle **Story · Medium priority · Intermediate** noCV practice brief v5 · BDBMIG-108 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-104, BDBMIG-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Privacy 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. Reviewers currently receive terminal screenshots without the SQL version or workload context. Acceptance criteria - Include SQL digests, tool version, target class, and observations. - Exclude connection secrets and row contents. - Fail if referenced rehearsal output is missing. Implementation constraints - Use structured artifacts with documented size limits. Verification - Build a complete bundle. - Reject missing output and scan for seeded secret markers. Deliverables - Review bundle exporter. Rollout and recovery: Attach bundles to proposed changes; rerun if any migration digest changes. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-109 — Add migration drift checks for an already-applied history **Bug · High priority · Intermediate** noCV practice brief v5 · BDBMIG-109 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-101, BDBMIG-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Developer tooling 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 historical migration was edited after one environment had already applied it. Acceptance criteria - Compare stored applied digests to local files. - Stop on missing or changed applied history. - Allow only append-only new migrations. Implementation constraints - Do not silently repair the migration ledger. Verification - Accept appended migrations. - Reject changed bytes in an applied migration. Deliverables - History drift guard. Rollout and recovery: Fail closed on drift; document a reviewed corrective migration instead of rewriting history. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. #### BDBMIG-110 — Write the handoff checklist for a paused backfill **Chore · Low priority · Foundational** noCV practice brief v5 · BDBMIG-110 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-106, BDBMIG-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A different engineer must resume a backfill after the original author goes offline. Acceptance criteria - Identify the checkpoint and current migration version. - Show safe status, resume, and abort commands. - Describe who decides whether contraction can proceed. Implementation constraints - Keep operator instructions scoped to the local rehearsal. Verification - Resume using only the checklist. - Detect a mismatched migration digest before resuming. Deliverables - Backfill handoff guide. Rollout and recovery: Require the guide with the rehearsal bundle; retain expansion compatibility until completion. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery limits. 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. ## BTEST — Flaky test containment and repair A fictional web team reruns red builds until they pass. Shared clocks, leaked state, and unawaited work make failures hard to trust. **Field:** Quality engineering. **Suggested stack:** TypeScript, Vitest, Playwright. **Engineer value:** Practice controlled diagnosis, isolation, and test reliability measurement. **Company value:** Recover useful failure signals and reduce blind reruns without hiding product defects. **Delivery agreement:** Deliver repaired tests, deterministic reproductions, and a bounded quarantine policy. ### Setup prerequisites - Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. ### Find failure causes Capture reproducible conditions and classify failures. #### BTEST-101 — Record first-attempt results separately from rerun results **Task · Medium priority · Foundational** noCV practice brief v5 · BTEST-101 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Find failure causes. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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 green rerun erases the original failure from the summary. Acceptance criteria - Persist attempt number and original outcome. - Link retries to the same test identity. - Show initial failure counts separately from final status. Implementation constraints - Exclude screenshots or payloads containing real user data. Verification - Record fail-then-pass history. - Ensure duplicate reporter delivery does not double-count attempts. Deliverables - Attempt-aware result report. Rollout and recovery: Introduce reporting before changing retry policy; retain original raw fixture results. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-102 — Reproduce order-dependent failures with a saved shuffle seed **Task · High priority · Intermediate** noCV practice brief v5 · BTEST-102 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Find failure causes. Depends on: BTEST-101. Difficulty: Intermediate. Estimated focused work: 120 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. One test fails only after a preference-setting test runs first. Acceptance criteria - Shuffle tests using a recorded seed. - Replay the identical ordering from that seed. - Emit a minimal command including environment assumptions. Implementation constraints - Keep the experiment inside the synthetic suite. Verification - Replay a known failing order. - Verify a different seed and missing seed are reported accurately. Deliverables - Seeded order runner. Rollout and recovery: Use in diagnostic jobs; preserve the normal suite order until the defect is fixed. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. ### Remove nondeterminism Repair isolation, time, and asynchronous behavior. #### BTEST-103 — Trace leaked database rows between test cases **Bug · High priority · Advanced** noCV practice brief v5 · BTEST-103 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove nondeterminism. Depends on: BTEST-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Database 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. An integration test reads records inserted by an earlier test and passes for the wrong reason. Acceptance criteria - Assign isolated fixture ownership to each test. - Clean only rows owned by that test. - Fail when a test observes another fixture namespace. Implementation constraints - Do not use an unrestricted table truncation against shared databases. Verification - Run the tests independently and in reversed order. - Inject foreign fixture rows and verify isolation. Deliverables - Fixture isolation repair. Rollout and recovery: Adopt per-suite first; preserve failed fixture IDs for diagnosis without row contents. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-104 — Replace wall-clock races with explicit clock control **Bug · High priority · Intermediate** noCV practice brief v5 · BTEST-104 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove nondeterminism. Depends on: BTEST-102. Difficulty: Intermediate. Estimated focused work: 120 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 trial-expiry test fails around UTC midnight and daylight-saving changes. Acceptance criteria - Inject a clock into expiry calculations. - Cover before, at, and after expiry boundaries. - Restore real timers after each test. Implementation constraints - Business timestamps remain UTC; local zones are test inputs. Verification - Replay midnight and offset-boundary cases. - Verify leaked fake timers are detected by teardown. Deliverables - Clock-based expiry tests. Rollout and recovery: Land with the date behavior unchanged except for the documented boundary correction. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-105 — Remove readiness sleeps from browser tests **Bug · Medium priority · Intermediate** noCV practice brief v5 · BTEST-105 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove nondeterminism. Depends on: BTEST-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. A fixed delay is either too short on CI or unnecessarily long locally. Acceptance criteria - Wait for a specific observable ready state. - Bound the wait and report the missing condition. - Handle a failed request without waiting indefinitely. Implementation constraints - Do not increase global timeouts to mask failures. Verification - Run with fast and delayed local responses. - Return an error and verify a useful bounded failure. Deliverables - Condition-based browser waits. Rollout and recovery: Replace sleeps incrementally; keep traces for failures during adoption. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-106 — Find async work that escapes test teardown **Bug · High priority · Advanced** noCV practice brief v5 · BTEST-106 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove nondeterminism. Depends on: BTEST-103, BTEST-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · 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. Background polling continues after a test completes and changes the next test's state. Acceptance criteria - Track owned timers, subscriptions, and requests. - Cancel owned work during teardown. - Fail the test on unhandled late rejections. Implementation constraints - Do not suppress process-level rejection reporting. Verification - Complete a polling test with clean teardown. - Inject an ignored cancellation and detect the leaked work. Deliverables - Async lifecycle repair. Rollout and recovery: Enable leak detection for the affected suite before expanding coverage. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. ### Keep signals useful Make retries and quarantine visible and temporary. #### BTEST-107 — Separate product defects from environmental test failures **Task · High priority · Advanced** noCV practice brief v5 · BTEST-107 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep signals useful. Depends on: BTEST-101, BTEST-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. An unavailable local dependency and an incorrect application response currently look identical. Acceptance criteria - Define explicit failure categories with supporting observations. - Keep unknown causes marked unknown. - Prevent infrastructure classification from silently turning failures green. Implementation constraints - Classification rules must be auditable and versioned. Verification - Classify a refused connection and an assertion mismatch. - Verify ambiguous evidence remains unclassified. Deliverables - Failure triage rules. Rollout and recovery: Use categories for routing; retain the underlying failed status. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-108 — Add expiring quarantine entries with accountable owners **Task · High priority · Intermediate** noCV practice brief v5 · BTEST-108 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep signals useful. Depends on: BTEST-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Platform 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. Quarantined tests have accumulated without owners or a return date. Acceptance criteria - Require owner, reason, linked reproduction, and expiry. - Continue executing quarantined tests in a visible lane. - Fail policy checks on expired or unmatched entries. Implementation constraints - Quarantine cannot remove coverage silently. Verification - Accept a complete short-lived entry. - Reject expired, wildcard-only, and ownerless entries. Deliverables - Quarantine policy validator. Rollout and recovery: Start with a reviewed inventory; restore tests automatically only after policy conditions are met. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-109 — Evaluate flake repairs with controlled repeated runs **Task · High priority · Expert** noCV practice brief v5 · BTEST-109 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep signals useful. Depends on: BTEST-103, BTEST-104, BTEST-105, BTEST-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · 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. Twenty green reruns are being presented as proof that a defect is gone. Acceptance criteria - Declare seeds, repetitions, environment, and remaining uncertainty. - Compare repaired and deliberately unfixed cases under matching conditions. - Report first-attempt failures and confidence limits without universal reliability claims. Implementation constraints - Keep the run budget bounded and retain failed seeds. Verification - Recover the injected failure in the unfixed variant. - Verify repaired runs and explicitly report any inconclusive result. Deliverables - Repair evaluation report. Rollout and recovery: Remove quarantine only with the reproduction fixed and policy review complete. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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. #### BTEST-110 — Add a contributor guide for a trustworthy regression test **Chore · Low priority · Foundational** noCV practice brief v5 · BTEST-110 · Flaky test containment and repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep signals useful. Depends on: BTEST-108, BTEST-109. Difficulty: Foundational. Estimated focused work: 60 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. New contributors copy retry-heavy tests and perpetuate the same failure patterns. Acceptance criteria - Show one deterministic fixture, clock, and cleanup example. - State when a rerun is diagnostic rather than acceptance. - Document how to submit a reproducible failure. Implementation constraints - Use actual repaired examples from this project. Verification - Follow the guide to add a passing boundary test. - Check that an intentionally leaked resource fails review checks. Deliverables - Contributor testing guide. Rollout and recovery: Link the guide from quarantine failures and the test command. Project prerequisites: Create a small local application with three deliberately flaky tests using synthetic data and local endpoints. Engineer value: Practice controlled diagnosis, isolation, and test reliability measurement. Company value: Recover useful failure signals and reduce blind reruns without hiding product defects. 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 — 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. ## BRELEASE — Risk-based release acceptance A fictional retailer is changing delivery options. Its regression suite is large, but no one can explain whether inventory, totals, or recovery behavior is covered. **Field:** Quality engineering. **Suggested stack:** TypeScript, Playwright, PostgreSQL. **Engineer value:** Practice risk analysis, exploratory testing, and evidence-based release decisions. **Company value:** Provide a reviewable release assessment tied to customer-impacting invariants. **Delivery agreement:** Deliver the acceptance suite, exploratory notes, and a local release rehearsal; no live transactions. ### Setup prerequisites - Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. ### Scope release risk Translate the change into observable business invariants. #### BRELEASE-101 — Map delivery-option changes to checkout invariants **Task · Medium priority · Foundational** noCV practice brief v5 · BRELEASE-101 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Scope release risk. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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. The release checklist says 'test checkout' without defining what must remain true. Acceptance criteria - List total, inventory, address, and order-state invariants. - Rank scenarios by impact and change exposure. - Identify dependencies the local fixture cannot represent. Implementation constraints - Keep priorities explainable without a composite quality score. Verification - Trace one delivery change to affected invariants. - Show an unrelated account setting outside this release scope. Deliverables - Release risk map. Rollout and recovery: Review the map before selecting tests; retain explicit uncovered risks. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-102 — Create boundary partitions for delivery eligibility **Task · Medium priority · Intermediate** noCV practice brief v5 · BRELEASE-102 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Scope release risk. Depends on: BRELEASE-101. Difficulty: Intermediate. Estimated focused work: 120 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. Only ordinary postal codes are tested, while minimum basket size and service boundaries determine eligibility. Acceptance criteria - Partition valid, excluded, and malformed destinations. - Cover basket thresholds below, at, and above the boundary. - State the expected reason when no option is eligible. Implementation constraints - Use fictional destinations and rates. Verification - Exercise representative values from every partition. - Reject malformed input without calling the mock provider. Deliverables - Eligibility case table. Rollout and recovery: Version the case table with the delivery rules. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. ### Exercise critical paths Test changed behavior and failure recovery. #### BRELEASE-103 — Verify totals remain stable across delivery-option switching **Bug · High priority · Intermediate** noCV practice brief v5 · BRELEASE-103 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise critical paths. Depends on: BRELEASE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Frontend 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. Changing options twice sometimes charges the first option while displaying the second. Acceptance criteria - Use the selected option consistently in displayed and submitted totals. - Invalidate stale quotes when inputs change. - Prevent submission while the current quote is unresolved. Implementation constraints - Represent amounts in exact minor units. Verification - Switch options rapidly and verify the final total. - Resolve an old quote late and confirm it cannot overwrite selection. Deliverables - Quote-race regression. Rollout and recovery: Ship with the corrected quote binding; revert the option feature if totals diverge. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-104 — Test inventory reservation when checkout is abandoned **Task · High priority · Advanced** noCV practice brief v5 · BRELEASE-104 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise critical paths. Depends on: BRELEASE-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Backend 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. Reservations survive failed checkout and make available stock look sold out. Acceptance criteria - Expire abandoned reservations by the declared deadline. - Preserve completed-order reservations. - Make repeated expiry processing idempotent. Implementation constraints - Control time and use only synthetic inventory. Verification - Expire an abandoned reservation. - Race completion with expiry and verify the chosen invariant. Deliverables - Reservation lifecycle tests. Rollout and recovery: Keep expiry processing observable; pause the changed flow if stock reconciliation fails. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-105 — Check assistive-technology behavior for delivery errors **Task · High priority · Intermediate** noCV practice brief v5 · BRELEASE-105 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise critical paths. Depends on: BRELEASE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Quality 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. Eligibility failures appear visually below the form but keyboard users receive no useful indication. Acceptance criteria - Associate errors with the relevant inputs. - Move or announce focus consistently after failed submission. - Preserve entered values for correction. Implementation constraints - Use semantic HTML and owned accessible components. Verification - Complete the flow using a keyboard. - Trigger multiple errors and verify readable order and no focus trap. Deliverables - Accessibility acceptance notes. Rollout and recovery: Include these checks in the release smoke path; revert inaccessible validation changes. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-106 — Exercise partial provider failure without duplicating orders **Task · High priority · Advanced** noCV practice brief v5 · BRELEASE-106 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise critical paths. Depends on: BRELEASE-103, BRELEASE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Distributed systems 30% · Integrations 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 delivery provider accepts a booking but the checkout request times out. Acceptance criteria - Represent booking outcome as pending when confirmation is unknown. - Retry using the same operation identity. - Prevent a second order from the same confirmed submission. Implementation constraints - Use a scripted provider double; send no external bookings. Verification - Recover a timed-out accepted booking. - Replay duplicate callbacks and verify one final order. Deliverables - Partial-failure acceptance suite. Rollout and recovery: Release behind a limited local cohort switch; stop new bookings if reconciliation is unhealthy. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-107 — Run a structured exploratory session on edited addresses **Task · Medium priority · Advanced** noCV practice brief v5 · BRELEASE-107 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise critical paths. Depends on: BRELEASE-105, BRELEASE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Frontend 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. Automated cases miss interactions between edited addresses, browser back navigation, and refreshed quotes. Acceptance criteria - Define a charter and a fixed session duration. - Record observations, reproduction steps, and unresolved questions. - Turn a discovered stable regression into one focused test. Implementation constraints - Do not claim absence of defects from a time-boxed session. Verification - Explore address edits during pending quotes. - Verify an interrupted session leaves useful reproducible notes. Deliverables - Exploratory session report. Rollout and recovery: Use findings to update release risk; keep unknown behavior visible. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. ### Prepare release review Report uncertainty and make rollback conditions explicit. #### BRELEASE-108 — Assess a reduced regression suite against explicit omission risk **Task · High priority · Expert** noCV practice brief v5 · BRELEASE-108 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare release review. Depends on: BRELEASE-101, BRELEASE-107. Difficulty: Expert. Estimated focused work: 300 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. The team has thirty minutes for the release gate and cannot run every browser combination. Acceptance criteria - Select checks using the documented change and impact map. - Compare runtime cost against omitted risk. - Identify conditions that require the broader suite before release. Implementation constraints - Declare device and browser coverage limits without inferring untested support. Verification - Show coverage for every critical invariant. - Introduce a high-impact uncovered path and force broader verification. Deliverables - Release gate selection record. Rollout and recovery: Use the reduced gate only within its declared scope; retain a broader fallback. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-109 — Create a release evidence index with reproducible commands **Chore · Medium priority · Foundational** noCV practice brief v5 · BRELEASE-109 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare release review. Depends on: BRELEASE-108. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · 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. Reviewers cannot distinguish current results from screenshots copied from an earlier build. Acceptance criteria - Bind results to fixture and application revisions. - Link each risk to a check or explicit gap. - Include exact local commands and outcomes. Implementation constraints - Results are practice artifacts, not ownership claims. Verification - Reproduce one indexed result. - Detect a result whose revision differs from the release candidate. Deliverables - Release evidence index. Rollout and recovery: Regenerate the index after candidate changes; keep previous reports append-only. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. #### BRELEASE-110 — Rehearse rollback when delivery quotes become inconsistent **Task · High priority · Advanced** noCV practice brief v5 · BRELEASE-110 · Risk-based release acceptance Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare release review. Depends on: BRELEASE-106, BRELEASE-109. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Platform engineering 30% · Database 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 rollback plan restores code but says nothing about orders already using the new delivery model. Acceptance criteria - Define a measurable stop condition for quote inconsistency. - Preserve completed orders and reconcile pending bookings. - Verify the old application can read retained order records. Implementation constraints - Do not delete accepted transactions to simplify recovery. Verification - Roll back after a synthetic completed and pending order. - Verify unsupported records trigger a reviewed repair path. Deliverables - Rollback rehearsal and data compatibility report. Rollout and recovery: Gate release on the rehearsal; prefer disabling new bookings while reconciling pending work. Project prerequisites: Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Engineer value: Practice risk analysis, exploratory testing, and evidence-based release decisions. Company value: Provide a reviewable release assessment tied to customer-impacting invariants. 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. ## BRAG — Grounded support-document assistant A fictional internal support team needs answers from product guides. Some guides are outdated or restricted, and fluent unsupported answers would create operational mistakes. **Field:** Applied AI. **Suggested stack:** TypeScript, PostgreSQL, AiEvaluationProvider. **Engineer value:** Practice retrieval boundaries, citation validation, and deterministic evaluation. **Company value:** Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. **Delivery agreement:** Deliver a local assistant using provider interfaces and scripted outputs; live model quality remains unmeasured. ### Setup prerequisites - Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. ### Control sources Version documents and enforce retrieval scope. #### BRAG-101 — Define versioned source records for the support collection **Task · Medium priority · Foundational** noCV practice brief v5 · BRAG-101 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control sources. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Database 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. Two guides share a title but describe different product releases. Acceptance criteria - Assign immutable source-version identities. - Record product version, scope, and supersession separately. - Preserve old content when a revision is added. Implementation constraints - Use synthetic document IDs, not fabricated Evidence IDs. Verification - Retrieve both historical versions explicitly. - Reject an attempt to overwrite a sealed source version. Deliverables - Source metadata schema. Rollout and recovery: Import a small synthetic collection first; append corrections instead of editing history. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-102 — Apply tenant and document grants before retrieval ranking **Task · High priority · Advanced** noCV practice brief v5 · BRAG-102 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control sources. Depends on: BRAG-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Applied AI 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 highly relevant private guide appears in another tenant's search results. Acceptance criteria - Scope candidate sources before scoring. - Recheck grants before returning retrieved text. - Ensure denied sources do not influence snippets or counts. Implementation constraints - Authorization belongs in the retrieval service boundary. Verification - Retrieve an authorized guide. - Query an identical restricted guide from another tenant and verify no disclosure. Deliverables - Scoped retriever. Rollout and recovery: Fail closed on unknown grants; disable assistant responses if retrieval authorization fails. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-103 — Preserve source offsets when splitting documentation **Task · Medium priority · Intermediate** noCV practice brief v5 · BRAG-103 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control sources. Depends on: BRAG-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Applied AI 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. Answer citations point to chunks that cannot be located in the original guide. Acceptance criteria - Retain source version and character ranges for each chunk. - Keep headings with their relevant text within configured limits. - Reject chunks whose ranges exceed the source. Implementation constraints - Choose deterministic splitting; do not fabricate missing text. Verification - Reconstruct cited text from saved offsets. - Detect altered source content and invalid ranges. Deliverables - Chunking pipeline. Rollout and recovery: Rebuild indexes under a new version; retain the previous complete index for recovery. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. ### Constrain answers Validate citations, contradictions, and provider failures. #### BRAG-104 — Require structured answer output with verifiable citations **Task · High priority · Advanced** noCV practice brief v5 · BRAG-104 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answers. Depends on: BRAG-102, BRAG-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 70% · Security 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 model double returns a plausible answer with a nonexistent citation. Acceptance criteria - Validate the output schema and byte limit. - Resolve every citation against authorized retrieved source versions. - Reject unsupported citation identities rather than repairing them silently. Implementation constraints - Access model behavior only through AiEvaluationProvider. Verification - Accept a supported answer with valid ranges. - Reject malformed output, nonexistent sources, and cross-tenant citations. Deliverables - Answer validator. Rollout and recovery: Keep invalid responses in a safe unavailable state; retain only sanitized failure metadata. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-105 — Expose conflicting guide versions instead of choosing silently **Story · High priority · Advanced** noCV practice brief v5 · BRAG-105 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answers. Depends on: BRAG-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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. Two authorized sources disagree about the retention setting and neither is marked superseded. Acceptance criteria - Represent the contradiction with both source references. - Avoid presenting either value as settled. - Ask for product-version context or return an explicit unresolved answer. Implementation constraints - Do not infer authority from retrieval score alone. Verification - Resolve a clearly superseded guide correctly. - Keep equally current contradictory guides visibly unresolved. Deliverables - Contradiction response behavior. Rollout and recovery: Enable with conflict fixtures first; route unresolved advice to a support review workflow. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-106 — Treat instructions inside retrieved guides as untrusted content **Bug · High priority · Advanced** noCV practice brief v5 · BRAG-106 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answers. Depends on: BRAG-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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 guide includes text telling the assistant to reveal other documents. Acceptance criteria - Keep retrieved text outside system instruction authority. - Disallow tool calls or new retrieval scopes from document text. - Reject answers citing content outside the authorized retrieval set. Implementation constraints - Use bounded prompt-injection fixtures without real secrets. Verification - Answer a benign guide question. - Inject scope-changing instructions and verify access remains unchanged. Deliverables - Adversarial retrieval checks. Rollout and recovery: Block deployment if the boundary fails; keep source ingestion separate from execution authority. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-107 — Bound assistant time and token reservations per request **Task · High priority · Intermediate** noCV practice brief v5 · BRAG-107 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain answers. Depends on: BRAG-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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. Repeated retries can exceed the budget for a single support question. Acceptance criteria - Reserve a configured maximum budget before provider calls. - Bound retries and total elapsed time. - Release unused reservation after terminal completion. Implementation constraints - Record provider, model, schema, timeout, cost, version, and trace metadata safely. Verification - Complete a request within the reservation. - Simulate timeout and ignored cancellation without unbounded retries. Deliverables - Request budget controller. Rollout and recovery: Default to deterministic provider mode; fail closed when reservation cannot be obtained. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. ### Evaluate limits Measure scoped behavior without overstating model quality. #### BRAG-108 — Evaluate grounded answering separately from retrieval quality **Task · High priority · Expert** noCV practice brief v5 · BRAG-108 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate limits. Depends on: BRAG-105, BRAG-106, BRAG-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Quality 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 single answer score hides whether failures came from missing documents or unsupported generation. Acceptance criteria - Create separate retrieval and citation-validity checks. - Include answerable, absent, conflicting, and denied questions. - Report deterministic-double results separately from unmeasured live-model behavior. Implementation constraints - Use public synthetic expectations; do not embed hidden evaluator answers in product APIs. Verification - Detect a missing retrieval result. - Detect a fluent answer unsupported by retrieved text. Deliverables - Evaluation report with failure categories. Rollout and recovery: Require both boundaries before expanding the corpus; retain an explicit unmeasured label for live quality. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-109 — Prevent stale indexes from serving revoked source access **Bug · High priority · Intermediate** noCV practice brief v5 · BRAG-109 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate limits. Depends on: BRAG-102, BRAG-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Applied AI 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. A document grant is revoked after its chunks have been cached. Acceptance criteria - Recheck current access on cached retrieval results. - Evict or suppress revoked entries without serving stale text. - Keep cache keys scoped to tenant and index version. Implementation constraints - Cache entries cannot become access grants. Verification - Serve an unchanged authorized cache entry. - Revoke access and deny the next response even before cache expiry. Deliverables - Revocation regression. Rollout and recovery: Prioritize denial over cache availability; clear affected caches during recovery. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. #### BRAG-110 — Document the assistant's supported questions and limits **Chore · Low priority · Foundational** noCV practice brief v5 · BRAG-110 · Grounded support-document assistant Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate limits. Depends on: BRAG-108, BRAG-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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 prototype can sound ready for unrestricted customer support despite its small synthetic corpus. Acceptance criteria - List supported corpus and product versions. - Explain unavailable and conflicting-source responses. - State that deterministic validation does not measure live-model answer quality. Implementation constraints - Avoid capability claims beyond observed local checks. Verification - Follow one supported question to its source. - Verify unsupported questions receive the documented response. Deliverables - Operator and user-facing capability note. Rollout and recovery: Ship the note with the prototype; revise it whenever corpus or provider behavior changes. Project prerequisites: Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required. Engineer value: Practice retrieval boundaries, citation validation, and deterministic evaluation. Company value: Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior. 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. ## BEXTRACT — Reviewable invoice field extraction A fictional procurement team receives inconsistent supplier documents. It wants draft records that staff can review without treating model output as authoritative accounting data. **Field:** Applied AI. **Suggested stack:** TypeScript, JSON Schema, AiEvaluationProvider. **Engineer value:** Practice schema constraints, numerical checks, review workflows, and safe model boundaries. **Company value:** Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. **Delivery agreement:** Deliver draft extraction and correction behavior; no real invoices, payment execution, or accounting advice. ### Setup prerequisites - Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. ### Define extraction rules Represent fields, provenance, and ambiguity explicitly. #### BEXTRACT-101 — Define invoice fields with explicit missing and ambiguous states **Task · Medium priority · Foundational** noCV practice brief v5 · BEXTRACT-101 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define extraction rules. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 80% · Data 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. Empty strings currently mean both absent values and extraction failures. Acceptance criteria - Represent value, missing, and ambiguous states distinctly. - Declare required fields before a draft is reviewable. - Preserve the original textual date and amount references. Implementation constraints - Do not guess missing tax or currency values. Verification - Parse a complete synthetic invoice. - Represent missing currency and an ambiguous date without invented values. Deliverables - Extraction schema. Rollout and recovery: Version the schema before creating drafts; retain raw synthetic source references. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-102 — Bind extraction runs to immutable document digests **Task · High priority · Intermediate** noCV practice brief v5 · BEXTRACT-102 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define extraction rules. Depends on: BEXTRACT-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Data engineering 30% · Storage 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. A corrected document is uploaded under the same filename and the old result appears current. Acceptance criteria - Identify runs by document digest and extractor version. - Preserve earlier runs when content changes. - Reject a result bound to another document digest. Implementation constraints - Filenames are display labels, not identity. Verification - Replay an unchanged document deterministically. - Change one byte and prevent reuse of the old result. Deliverables - Run identity contract. Rollout and recovery: Append new runs on document changes; never rewrite accepted extraction history. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. ### Validate drafts Reject unsupported or inconsistent provider output. #### BEXTRACT-103 — Validate source spans for every extracted material field **Task · High priority · Advanced** noCV practice brief v5 · BEXTRACT-103 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate drafts. Depends on: BEXTRACT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 80% · Data 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. The provider returns a supplier address that appears nowhere in the document. Acceptance criteria - Require bounded source spans for material values. - Resolve spans against the exact source version. - Flag transformed values with their documented normalization rule. Implementation constraints - Provider prose cannot substitute for source support. Verification - Accept a supported normalized date. - Reject out-of-range spans and invented supplier values. Deliverables - Source-grounding validator. Rollout and recovery: Keep unsupported drafts blocked for review; retain safe failure categories. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-104 — Check line-item arithmetic using exact decimal rules **Task · High priority · Intermediate** noCV practice brief v5 · BEXTRACT-104 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate drafts. Depends on: BEXTRACT-101, BEXTRACT-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Applied AI 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. Binary floating point produces an apparent mismatch on an otherwise consistent invoice. Acceptance criteria - Use declared currency scale and rounding rules. - Compare quantity, price, subtotal, and total consistently. - Represent unresolved tax or discount differences as discrepancies. Implementation constraints - Never silently alter document totals to make arithmetic balance. Verification - Validate a rounding-boundary invoice. - Flag inconsistent totals and unsupported precision. Deliverables - Arithmetic consistency checks. Rollout and recovery: Show discrepancies to reviewers; do not promote inconsistent drafts automatically. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-105 — Prevent document text from overriding extraction policy **Bug · High priority · Advanced** noCV practice brief v5 · BEXTRACT-105 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate drafts. Depends on: BEXTRACT-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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 invoice note contains instructions to mark every field verified. Acceptance criteria - Treat document text only as extraction input. - Require the same schema and grounding rules for all responses. - Keep document instructions unable to change review status. Implementation constraints - No external tools or supplier contact is permitted from model output. Verification - Extract a normal note field. - Inject policy-changing text and verify review remains required. Deliverables - Untrusted-document regression cases. Rollout and recovery: Fail closed on invalid output; retain the deterministic provider as a safe development mode. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-106 — Deduplicate concurrent extraction requests without mixing versions **Bug · High priority · Advanced** noCV practice brief v5 · BEXTRACT-106 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate drafts. Depends on: BEXTRACT-102, BEXTRACT-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Database engineering 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. Two upload retries consume duplicate provider budget and occasionally attach the older result to the newer run. Acceptance criteria - Deduplicate exact document and extractor identities. - Reject conflicting reuse of an operation key. - Commit one terminal result and preserve failed-attempt metadata. Implementation constraints - Access providers through AiEvaluationProvider with bounded timeout and retries. Verification - Race identical requests and observe one accepted result. - Change extractor version and ensure a distinct run. Deliverables - Extraction operation coordinator. Rollout and recovery: Adopt one document type first; retry terminal failures through a new explicit operation. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-107 — Reserve extraction cost before processing a document batch **Task · High priority · Intermediate** noCV practice brief v5 · BEXTRACT-107 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate drafts. Depends on: BEXTRACT-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Database engineering 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. A large upload queue can exceed the tenant's configured processing budget. Acceptance criteria - Estimate a conservative per-document reservation. - Enforce tenant and batch ceilings before dispatch. - Settle actual usage and return unused reservation exactly once. Implementation constraints - Record model, prompt/schema version, timeout, retries, cost, and trace without document text. Verification - Process a batch within the ceiling. - Retry settlement and verify no double charge or negative reservation. Deliverables - Budget accounting tests. Rollout and recovery: Start with a small ceiling; pause new dispatch when accounting state is uncertain. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. ### Support correction Preserve human review and evaluate bounded behavior. #### BEXTRACT-108 — Preserve corrections as append-only reviewer decisions **Story · High priority · Advanced** noCV practice brief v5 · BEXTRACT-108 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support correction. Depends on: BEXTRACT-104, BEXTRACT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Applied AI 30% · Database 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. Staff corrections overwrite the extracted values, making later disagreement impossible to investigate. Acceptance criteria - Record original value, corrected value, reviewer, and reason. - Require optimistic revision control for concurrent review. - Keep source and extractor output immutable. Implementation constraints - Review actions must be tenant-scoped. Verification - Correct a draft and inspect both versions. - Reject stale revisions and cross-tenant review attempts. Deliverables - Correction history workflow. Rollout and recovery: Enable on draft records first; retain prior review state when a correction fails. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-109 — Design a field-level extraction evaluation with abstention costs **Task · High priority · Expert** noCV practice brief v5 · BEXTRACT-109 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support correction. Depends on: BEXTRACT-105, BEXTRACT-107, BEXTRACT-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Quality 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. Document-level success hides whether the extractor frequently invents totals or simply leaves them for review. Acceptance criteria - Report supported correct, incorrect, missing, and abstained fields separately. - Include layout, date, currency, and injection variations. - Compare manual-review volume against unsupported-field risk under declared assumptions. Implementation constraints - Deterministic doubles validate plumbing; live model accuracy remains unmeasured. Verification - Detect a fabricated total in the evaluation. - Show an appropriate abstention separately from an incorrect value. Deliverables - Evaluation protocol and synthetic results. Rollout and recovery: Expand document coverage only after reviewing failure categories and unresolved assumptions. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. #### BEXTRACT-110 — Prepare a reviewer checklist for ambiguous supplier documents **Chore · Low priority · Foundational** noCV practice brief v5 · BEXTRACT-110 · Reviewable invoice field extraction Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support correction. Depends on: BEXTRACT-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 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. Reviewers need a consistent way to handle ambiguous dates and unsupported fields. Acceptance criteria - Explain how to inspect source spans and arithmetic discrepancies. - Show how to request correction without editing source history. - Document when a draft must remain unresolved. Implementation constraints - Do not treat review completion as proof of invoice authenticity. Verification - Review one supported synthetic invoice. - Leave an ambiguous supplier document unresolved with a reason. Deliverables - Reviewer guide. Rollout and recovery: Publish alongside the prototype; revise examples when extraction policy changes. Project prerequisites: Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double. Engineer value: Practice schema constraints, numerical checks, review workflows, and safe model boundaries. Company value: Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control. 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. ## BTRIAGE — Incident assistant with read-only tools A fictional on-call team wants an assistant that joins alerts, deployment notes, and runbooks. Incomplete telemetry and hostile log content make unsupported conclusions dangerous. **Field:** Applied AI. **Suggested stack:** TypeScript, AiEvaluationProvider, JSON Schema. **Engineer value:** Practice constrained tool use, operational uncertainty, and traceable AI outputs. **Company value:** Produce concise incident drafts that preserve source traceability and operator control. **Delivery agreement:** Deliver a local read-only prototype; it must execute no remediation and contact no external service. ### Setup prerequisites - Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. ### Scope incident inputs Authorize and normalize incident records. #### BTRIAGE-101 — Define a common timeline record for operational events **Task · Medium priority · Foundational** noCV practice brief v5 · BTRIAGE-101 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Scope incident inputs. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. Alerts and deployment records disagree about timestamp formats. Acceptance criteria - Normalize timestamps to UTC. - Preserve source identity and original timestamp. - Mark missing or uncertain event times. Implementation constraints - Do not invent ordering for ambiguous records. Verification - Merge valid records in stable order. - Keep equal or missing timestamps visibly uncertain. Deliverables - Timeline schema. Rollout and recovery: Import synthetic records first; retain original source records. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-102 — Limit incident retrieval to the caller's service grants **Task · High priority · Advanced** noCV practice brief v5 · BTRIAGE-102 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Scope incident inputs. Depends on: BTRIAGE-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Applied AI 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 related-service lookup exposes another team's restricted incident notes. Acceptance criteria - Scope every tool read by caller grants. - Recheck access for referenced records. - Return non-enumerating denial responses. Implementation constraints - Tool definitions cannot widen caller permissions. Verification - Read an authorized service timeline. - Deny a cross-service record guessed by ID. Deliverables - Authorized tool boundary. Rollout and recovery: Disable assistance when grant resolution fails. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. ### Build draft assistance Constrain tools, sources, and unsupported conclusions. #### BTRIAGE-103 — Bound tool arguments and returned telemetry volume **Task · High priority · Intermediate** noCV practice brief v5 · BTRIAGE-103 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build draft assistance. Depends on: BTRIAGE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · API design 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 broad query attempts to retrieve days of raw logs. Acceptance criteria - Require bounded time range and record count. - Reject unknown tool names and properties. - Truncate with explicit completeness metadata. Implementation constraints - Use aggregate synthetic records instead of secret-bearing logs. Verification - Retrieve a bounded incident window. - Reject excessive ranges and unsupported tool arguments. Deliverables - Tool request validator. Rollout and recovery: Start with conservative limits; report incomplete context rather than expanding silently. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-104 — Keep log content from issuing new tool instructions **Bug · High priority · Advanced** noCV practice brief v5 · BTRIAGE-104 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build draft assistance. Depends on: BTRIAGE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Applied AI 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 error message contains text requesting privileged configuration reads. Acceptance criteria - Treat log text as untrusted data. - Allow only declared read-only tools. - Validate every proposed tool call independently. Implementation constraints - No shell, configuration writes, or remediation tools are exposed. Verification - Summarize a benign failure record. - Inject a privileged instruction and verify no unauthorized call occurs. Deliverables - Adversarial tool-use checks. Rollout and recovery: Block provider output on policy failure and preserve sanitized diagnostics. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-105 — Require source references for incident summary statements **Task · High priority · Advanced** noCV practice brief v5 · BTRIAGE-105 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build draft assistance. Depends on: BTRIAGE-101, BTRIAGE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 80% · 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. The generated summary invents a deployment that never happened. Acceptance criteria - Bind factual statements to retrieved source identities. - Reject nonexistent and unauthorized references. - Separate observations from hypotheses. Implementation constraints - Use AiEvaluationProvider and schema-validated structured responses. Verification - Accept a source-backed timeline statement. - Reject invented deployments and uncited root-cause assertions. Deliverables - Summary validator. Rollout and recovery: Render only validated drafts; return unavailable on invalid output. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-106 — Represent competing incident hypotheses explicitly **Story · Medium priority · Advanced** noCV practice brief v5 · BTRIAGE-106 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build draft assistance. Depends on: BTRIAGE-105. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Applied AI 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 latency spike follows a deployment but also overlaps a dependency outage. Acceptance criteria - List supporting and contradicting observations per hypothesis. - Avoid declaring causation from timing alone. - Identify a bounded next observation for discrimination. Implementation constraints - Recommendations remain read-only diagnostic suggestions. Verification - Represent two plausible causes. - Keep a hypothesis unresolved when discriminating telemetry is absent. Deliverables - Hypothesis draft format. Rollout and recovery: Require operator review before acting on a hypothesis. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-107 — Cancel obsolete drafts when new incident context arrives **Bug · High priority · Intermediate** noCV practice brief v5 · BTRIAGE-107 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build draft assistance. Depends on: BTRIAGE-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Backend 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 older slow response overwrites the summary after a recovery event arrives. Acceptance criteria - Bind drafts to context revision. - Cancel or discard superseded work. - Preserve the latest accepted timeline revision. Implementation constraints - Record provider/model/version, timeout, retries, cost, and trace safely. Verification - Complete the newest draft first. - Resolve an older request late and reject its update. Deliverables - Revision-aware draft coordinator. Rollout and recovery: Keep the last valid draft visible with its timestamp when refresh fails. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. ### Assess operator usefulness Evaluate bounded behavior and safe failure handling. #### BTRIAGE-108 — Prevent repeated refreshes from exhausting incident budgets **Task · High priority · Intermediate** noCV practice brief v5 · BTRIAGE-108 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Assess operator usefulness. Depends on: BTRIAGE-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 60% · Backend 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. Several operators refresh the same incident and trigger duplicate model calls. Acceptance criteria - Coalesce identical in-flight context requests. - Enforce per-incident reservation and timeout. - Settle usage once per provider attempt. Implementation constraints - Provider failure cannot trigger unbounded retry loops. Verification - Share one in-flight synthetic response. - Exhaust the budget and return a bounded unavailable state. Deliverables - Incident request budget. Rollout and recovery: Default to deterministic mode; pause new refreshes when accounting is uncertain. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-109 — Evaluate summary utility without rewarding confident guesses **Task · High priority · Expert** noCV practice brief v5 · BTRIAGE-109 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Assess operator usefulness. Depends on: BTRIAGE-104, BTRIAGE-106, BTRIAGE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Applied AI 50% · Quality 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. The team needs a useful assessment that does not equate fluent prose with correct incident analysis. Acceptance criteria - Measure citation validity, omitted critical observations, and unsupported assertions separately. - Include partial, contradictory, and malicious context cases. - Report deterministic boundary results separately from live-model quality. Implementation constraints - Do not claim reduced incident duration from this local prototype. Verification - Detect an invented root cause. - Accept a concise unresolved summary with valid diagnostic next steps. Deliverables - Evaluation protocol and failure report. Rollout and recovery: Expand incident coverage only after reviewing unsupported-claim failures. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. #### BTRIAGE-110 — Write an operator handoff for stale or unavailable assistance **Chore · Low priority · Foundational** noCV practice brief v5 · BTRIAGE-110 · Incident assistant with read-only tools Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Assess operator usefulness. Depends on: BTRIAGE-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Applied AI 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. Operators must continue handling incidents when the assistant is down. Acceptance criteria - Show draft age and source window. - Link the original authorized records. - Document the manual timeline workflow. Implementation constraints - The assistant is never a dependency for incident response. Verification - Continue from source records during provider failure. - Verify stale drafts cannot appear current. Deliverables - Operator fallback guide. Rollout and recovery: Ship the fallback with the prototype and rehearse it locally. Project prerequisites: Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles. Engineer value: Practice constrained tool use, operational uncertainty, and traceable AI outputs. Company value: Produce concise incident drafts that preserve source traceability and operator control. 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. ## BBILL — Payment-provider reconciliation adapter A fictional software vendor changes payment providers. Its application must tolerate unknown outcomes, signed callbacks, refunds, and inconsistent settlement reports. **Field:** Integrations. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice idempotent integrations, state reconciliation, and provider migration. **Company value:** Provide a reviewable adapter design that protects order consistency and recovery. **Delivery agreement:** Deliver local provider contracts and reconciliation rehearsals; no live money or provider accounts. ### Setup prerequisites - Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. ### Define provider semantics Model identities and state transitions. #### BBILL-101 — Map provider payment states to explicit order transitions **Task · Medium priority · Foundational** noCV practice brief v5 · BBILL-101 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define provider semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Backend 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. Two provider status names are currently treated as equivalent even though only one confirms collection. Acceptance criteria - List provider states and allowed transitions. - Represent pending and unknown separately. - Reject impossible terminal reversals. Implementation constraints - Keep provider status distinct from local order status. Verification - Map successful and pending examples. - Reject an unsupported state without marking an order paid. Deliverables - State mapping contract. Rollout and recovery: Review mapping before accepting callbacks. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-102 — Bind payment creation retries to one local operation **Task · High priority · Advanced** noCV practice brief v5 · BBILL-102 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define provider semantics. Depends on: BBILL-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Integrations 30% · Database 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 timeout prompts the application to create a second payment. Acceptance criteria - Persist operation identity before dispatch. - Reuse identity for identical retries. - Reject conflicting payload reuse. Implementation constraints - Synthetic amounts use integer minor units. Verification - Retry a timed-out accepted request. - Reuse a key with another amount and verify rejection. Deliverables - Idempotent payment command. Rollout and recovery: Keep uncertain operations pending for reconciliation. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. ### Handle asynchronous results Process callbacks and unknown outcomes safely. #### BBILL-103 — Verify callback signatures before trusting event fields **Task · High priority · Intermediate** noCV practice brief v5 · BBILL-103 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Integrations 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 adapter currently reads order IDs before validating callbacks. Acceptance criteria - Verify raw bytes with the configured test key. - Enforce timestamp tolerance and key identity. - Reject malformed or unsigned bodies before processing. Implementation constraints - Never log signing secrets or full callback bodies. Verification - Accept a valid signed fixture. - Reject modified bytes and an expired timestamp. Deliverables - Callback verification boundary. Rollout and recovery: Reject unverifiable callbacks; retain safe failure counts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-104 — Apply duplicate and out-of-order payment callbacks idempotently **Bug · High priority · Advanced** noCV practice brief v5 · BBILL-104 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-102, BBILL-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Distributed systems 40% · Database 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 delayed pending callback overwrites an already-confirmed payment. Acceptance criteria - Deduplicate provider event identity. - Apply only allowed state transitions. - Record ignored stale events for diagnosis. Implementation constraints - Commit state and processed-event record atomically. Verification - Replay a successful callback twice. - Deliver pending after confirmed and preserve confirmation. Deliverables - Callback transition handler. Rollout and recovery: Adopt per synthetic merchant; pause on unresolved transition conflicts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-105 — Reconcile unknown creation outcomes by operation identity **Task · High priority · Advanced** noCV practice brief v5 · BBILL-105 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-102, BBILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 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. The provider accepted creation but the application lost the response. Acceptance criteria - Query the provider using the original operation identity. - Adopt the matching remote payment once. - Keep missing or mismatched results unresolved. Implementation constraints - Bound query retries and elapsed reconciliation time. Verification - Recover a matching accepted payment. - Reject a remote result with different amount or currency. Deliverables - Unknown-outcome reconciler. Rollout and recovery: Stop new attempts for unresolved operations; retry reconciliation explicitly. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-106 — Represent partial refunds without rewriting original payment facts **Story · High priority · Advanced** noCV practice brief v5 · BBILL-106 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Backend 30% · Integrations 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 partial refund currently changes the original collected amount. Acceptance criteria - Append refund operations separately. - Limit cumulative confirmed refunds to the collected amount. - Distinguish requested, pending, and confirmed refund totals. Implementation constraints - Run against the local double only. Verification - Confirm two valid partial refunds. - Race excess refunds and verify the invariant holds. Deliverables - Refund state model. Rollout and recovery: Enable after payment reconciliation; retain failed requests for investigation. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. ### Recover discrepancies Reconcile records and rehearse migration. #### BBILL-107 — Import settlement rows with source-file provenance **Task · Medium priority · Intermediate** noCV practice brief v5 · BBILL-107 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-105, BBILL-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Integrations 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. Repeated report uploads create duplicate reconciliation entries. Acceptance criteria - Bind imports to file digest and provider report identity. - Deduplicate exact rows without losing source references. - Reject conflicting duplicate settlement identities. Implementation constraints - Use synthetic CSV and sanitize spreadsheet formula prefixes in exports. Verification - Import the same report twice. - Detect a changed amount under an existing settlement identity. Deliverables - Settlement import pipeline. Rollout and recovery: Stage reports before matching; preserve original synthetic report digests. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-108 — Explain settlement discrepancies without automatic repair **Story · High priority · Intermediate** noCV practice brief v5 · BBILL-108 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Data 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. Finance staff see only a mismatch count and cannot identify its cause. Acceptance criteria - Classify missing, amount, currency, and timing mismatches. - Link each discrepancy to local and provider identities. - Keep disputed records unchanged. Implementation constraints - Do not infer fraud or automatically move funds. Verification - Explain a timing difference and an amount mismatch. - Verify unknown discrepancies remain unresolved. Deliverables - Discrepancy report. Rollout and recovery: Use reports for reviewed repair; keep reconciliation read-only by default. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-109 — Design a provider cutover with in-flight payment ownership **Task · High priority · Expert** noCV practice brief v5 · BBILL-109 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-105, BBILL-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Integrations 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. Switching all traffic at once would send old payment lookups to the new provider. Acceptance criteria - Pin each operation to its original provider. - Define new-operation routing and rollback conditions. - Rehearse callbacks and refunds crossing the cutover boundary. Implementation constraints - Compare adapter complexity and reconciliation burden explicitly. Verification - Complete an old-provider payment after cutover. - Roll back new routing without reassigning existing operations. Deliverables - Cutover decision record and rehearsal. Rollout and recovery: Change only new-operation routing; retain both adapters until old obligations finish. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-110 — Document a safe manual replay of a rejected callback **Chore · Low priority · Foundational** noCV practice brief v5 · BBILL-110 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Integrations 40% · 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. Support needs to retry a corrected callback without bypassing verification. Acceptance criteria - Require original event identity and verified source. - Use the normal validation and idempotency path. - Record replay operator and reason. Implementation constraints - No direct database status edits. Verification - Replay a previously failed valid event. - Reject a replay with altered signed content. Deliverables - Callback replay runbook. Rollout and recovery: Keep replay scoped and audited; stop on conflicting operation facts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. ## BCRM — CRM contact synchronization repair A fictional account team sees overwritten edits, duplicate contacts, and stale opt-out preferences after synchronization retries. **Field:** Integrations. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice sync cursors, conflict policies, privacy boundaries, and replay. **Company value:** Provide predictable customer-data synchronization with inspectable conflicts. **Delivery agreement:** Deliver a local bidirectional adapter and reconciliation report. ### Setup prerequisites - Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. ### Map authority Define identities and field ownership. #### BCRM-101 — Define contact field ownership between the app and CRM **Task · Medium priority · Foundational** noCV practice brief v5 · BCRM-101 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · System design 30% · Privacy 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. Both systems overwrite account names and communication preferences. Acceptance criteria - Assign an authority rule per synchronized field. - Separate display fields from consent fields. - Define unresolved conflicts explicitly. Implementation constraints - Never infer marketing consent from unrelated activity. Verification - Resolve an app-owned field change. - Keep conflicting consent records unresolved. Deliverables - Field ownership matrix. Rollout and recovery: Review the matrix before enabling writes. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-102 — Separate external contact identity from email addresses **Task · High priority · Intermediate** noCV practice brief v5 · BCRM-102 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map authority. Depends on: BCRM-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Database 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. An email change creates a second contact instead of updating the original. Acceptance criteria - Use provider and organization-scoped external identities. - Allow email changes without identity replacement. - Detect conflicting identity mappings. Implementation constraints - Email is mutable data, not a stable key. Verification - Update an existing contact's email. - Reject an external identity mapped across organizations. Deliverables - Identity mapping model. Rollout and recovery: Backfill synthetic mappings before synchronization. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. ### Synchronize changes Handle pagination, retries, conflicts, and deletion. #### BCRM-103 — Checkpoint CRM pagination only after local batch commit **Bug · High priority · Advanced** noCV practice brief v5 · BCRM-103 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize changes. Depends on: BCRM-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Database engineering 30% · Integrations 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 cursor advances even when a page fails to persist. Acceptance criteria - Commit page changes and cursor together. - Resume from the last committed cursor. - Bound page size and total import work. Implementation constraints - Do not use timestamps alone as a pagination tie-breaker. Verification - Interrupt after a committed page and resume. - Fail persistence and verify the cursor remains unchanged. Deliverables - Transactional page importer. Rollout and recovery: Start with small batches; retain checkpoints during recovery. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-104 — Apply contact updates with explicit conflict detection **Task · High priority · Advanced** noCV practice brief v5 · BCRM-104 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize changes. Depends on: BCRM-101, BCRM-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Integrations 40% · Database 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 delayed CRM event overwrites a newer local edit. Acceptance criteria - Compare the declared version or revision. - Apply field ownership rules on conflicts. - Preserve unresolved values and provenance. Implementation constraints - Do not use arrival time as proof of freshness. Verification - Merge independent field edits. - Detect conflicting edits to the same owned field. Deliverables - Conflict-aware update handler. Rollout and recovery: Enable writes only after the conflict report is reviewable. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-105 — Propagate communication opt-outs ahead of ordinary profile updates **Task · High priority · Advanced** noCV practice brief v5 · BCRM-105 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize changes. Depends on: BCRM-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Integrations 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. An opt-out remains queued behind thousands of cosmetic profile changes. Acceptance criteria - Prioritize restrictive preference updates. - Prevent older permissive values from restoring permission. - Record propagation state without exposing contact details in logs. Implementation constraints - Use synthetic preferences; no messages are sent. Verification - Propagate a new opt-out. - Replay an older opt-in and preserve the restrictive state. Deliverables - Preference propagation checks. Rollout and recovery: Pause outbound communication integration when preference state is uncertain. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-106 — Handle provider rate limits without skipping contacts **Bug · High priority · Intermediate** noCV practice brief v5 · BCRM-106 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize changes. Depends on: BCRM-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. The importer treats a rate-limited page as empty and advances. Acceptance criteria - Respect bounded retry delays. - Keep the current cursor until a successful page. - Distinguish terminal authentication failure from throttling. Implementation constraints - Use a mock clock and fixed retry ceiling. Verification - Recover from one rate-limited response. - Exhaust retries without advancing the cursor. Deliverables - Rate-limit handling. Rollout and recovery: Pause the organization sync after exhaustion; resume from its saved cursor. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-107 — Represent deleted CRM records with tombstone semantics **Task · High priority · Advanced** noCV practice brief v5 · BCRM-107 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize changes. Depends on: BCRM-104, BCRM-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Integrations 30% · Privacy 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. A deleted record reappears when an old update is replayed. Acceptance criteria - Retain deletion identity and source revision. - Prevent older updates from resurrecting the record. - Apply the documented retention rule to local fields. Implementation constraints - Deletion policy must distinguish identity metadata from contact contents. Verification - Apply a deletion then replay an older update. - Verify an authorized new identity follows an explicit recreation path. Deliverables - Deletion and replay rules. Rollout and recovery: Introduce tombstones before importing deletion events. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. ### Operate safely Reconcile drift and recover interrupted imports. #### BCRM-108 — Reconcile contact drift using bounded hashes and counts **Task · Medium priority · Intermediate** noCV practice brief v5 · BCRM-108 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate safely. Depends on: BCRM-106, BCRM-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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 needs to find mismatches without exporting every contact's personal data. Acceptance criteria - Compare scoped canonical synchronized-field digests. - Report missing and changed identities separately. - Limit detailed inspection to authorized records. Implementation constraints - Do not publish raw contact values in aggregate reports. Verification - Identify one missing and one changed contact. - Deny reconciliation across organization boundaries. Deliverables - Drift report. Rollout and recovery: Run read-only reconciliation before repair. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-109 — Plan a full CRM resynchronization without erasing local edits **Task · High priority · Expert** noCV practice brief v5 · BCRM-109 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate safely. Depends on: BCRM-104, BCRM-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Integrations 40% · 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. A corrupted cursor requires a new import while staff continue editing customer records. Acceptance criteria - Freeze an import boundary and preserve concurrent local revisions. - Compare merge strategies and conflict workload. - Rehearse resumption and cancellation without bulk replacement. Implementation constraints - Keep the exercise bounded to the synthetic dataset. Verification - Resume an interrupted full import. - Edit a contact mid-import and verify conflict preservation. Deliverables - Resynchronization decision record. Rollout and recovery: Run read-only comparison first; apply reviewed differences in bounded batches. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. #### BCRM-110 — Create a sync support view with safe failure categories **Story · Low priority · Foundational** noCV practice brief v5 · BCRM-110 · CRM contact synchronization repair Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate safely. Depends on: BCRM-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Integrations 40% · 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. Support sees only 'sync failed' and repeatedly restarts imports. Acceptance criteria - Show last committed cursor age and operation status. - Distinguish throttling, authorization, conflict, and malformed data. - Provide a scoped resume action using existing identity. Implementation constraints - Exclude tokens and contact contents from status output. Verification - Display a successful completed import. - Show authorization failure without retrying indefinitely. Deliverables - Support status projection. Rollout and recovery: Expose read-only status first; keep repairs separately authorized. Project prerequisites: Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials. Engineer value: Practice sync cursors, conflict policies, privacy boundaries, and replay. Company value: Provide predictable customer-data synchronization with inspectable conflicts. 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. ## BCALENDAR — Calendar availability synchronization A fictional booking service supports consultants in multiple time zones. Recurring events, revoked access, and delayed callbacks cause missed conflicts. **Field:** Integrations. **Suggested stack:** TypeScript, iCalendar, HTTP. **Engineer value:** Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. **Company value:** Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. **Delivery agreement:** Deliver local availability calculations and sync behavior; send no invitations or calendar writes externally. ### Setup prerequisites - Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. ### Define temporal semantics Model instants, zones, and recurrence. #### BCALENDAR-101 — Distinguish all-day events from timed calendar intervals **Task · Medium priority · Foundational** noCV practice brief v5 · BCALENDAR-101 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Backend 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 all-day absence becomes a twenty-four-hour UTC interval and shifts across local dates. Acceptance criteria - Represent all-day dates separately from instants. - Declare exclusive end semantics. - Preserve the event's timezone context. Implementation constraints - Do not infer an event zone from the server timezone. Verification - Render a timed event and all-day absence correctly. - Reject missing timezone context for ambiguous local times. Deliverables - Temporal data contract. Rollout and recovery: Version the contract before importing calendar records. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-102 — Resolve daylight-saving gaps and repeated local times **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-102 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: BCALENDAR-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Integrations 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 recurring appointment lands in a nonexistent local hour during a timezone transition. Acceptance criteria - Define explicit gap and overlap policies. - Keep original local time and selected offset. - Return ambiguity when policy cannot resolve the occurrence. Implementation constraints - Use a maintained timezone database available locally. Verification - Exercise a spring gap and autumn repeated hour. - Reject a silently guessed offset. Deliverables - Timezone resolution tests. Rollout and recovery: Keep affected appointments unresolved until policy is applied. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-103 — Expand recurrence within a bounded availability window **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-103 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: BCALENDAR-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Performance engineering 40% · 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. An unbounded recurrence rule exhausts the availability request. Acceptance criteria - Require finite query start and end. - Limit emitted occurrences and processing work. - Honor exclusions and changed single occurrences. Implementation constraints - Reject unsupported recurrence forms explicitly. Verification - Expand a weekly rule with an exception. - Bound an excessive recurrence and reject unsupported syntax. Deliverables - Bounded recurrence engine. Rollout and recovery: Start with declared supported rules; preserve unsupported events as unavailable context. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. ### Synchronize availability Handle event updates and provider failures. #### BCALENDAR-104 — Apply event revisions without reviving cancelled occurrences **Bug · High priority · Advanced** noCV practice brief v5 · BCALENDAR-104 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Integrations 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 old series update recreates a cancelled individual appointment. Acceptance criteria - Track series and occurrence revisions separately. - Preserve cancellation tombstones. - Ignore stale updates with an observable reason. Implementation constraints - Arrival order is not event version authority. Verification - Update one occurrence in a series. - Replay an older series update after cancellation. Deliverables - Revision-aware event importer. Rollout and recovery: Adopt on synthetic calendars first; reconcile before enabling booking decisions. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-105 — Use incremental sync tokens without losing full-resync coverage **Task · High priority · Intermediate** noCV practice brief v5 · BCALENDAR-105 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. The provider invalidates a sync token, and the app interprets it as an empty calendar. Acceptance criteria - Distinguish token invalidation from no changes. - Start a bounded full sync on invalidation. - Keep existing availability marked stale until replacement completes. Implementation constraints - Never clear events because a provider request failed. Verification - Apply a normal incremental page. - Invalidate the token and preserve stale records during recovery. Deliverables - Sync-token recovery. Rollout and recovery: Pause definitive availability claims while full sync is incomplete. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-106 — Project busy intervals without exposing event descriptions **Task · High priority · Intermediate** noCV practice brief v5 · BCALENDAR-106 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy 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. Availability responses leak private appointment titles to bookers. Acceptance criteria - Expose only necessary busy intervals. - Scope calendars by current access grants. - Exclude titles, attendees, and notes from public projections. Implementation constraints - Private provider fields remain outside scheduling responses. Verification - Compute availability from authorized events. - Seed sensitive markers and verify they never appear in outputs. Deliverables - Privacy-preserving availability projection. Rollout and recovery: Replace detailed projections before public availability is enabled. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-107 — Stop provider calls immediately after access revocation **Bug · High priority · Advanced** noCV practice brief v5 · BCALENDAR-107 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-105, BCALENDAR-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy engineering 30% · Integrations 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. Revoked calendars remain cached and continue receiving background refreshes. Acceptance criteria - Invalidate active grants and queued refresh authority. - Suppress cached private availability after revocation. - Make reconnect an explicit new authorization flow. Implementation constraints - Do not retry authorization failures as transient errors. Verification - Refresh an authorized calendar. - Revoke access mid-queue and verify no further authorized reads occur. Deliverables - Revocation handling. Rollout and recovery: Fail closed on uncertain grants; retain only allowed operational metadata. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. ### Rehearse edge cases Verify privacy, cutover, and recovery. #### BCALENDAR-108 — Detect overlapping booking attempts against one availability revision **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-108 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-106, BCALENDAR-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Integrations 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. Two bookers see the same open slot before either reservation is committed. Acceptance criteria - Bind booking checks to a declared availability revision. - Serialize or atomically reject overlapping local reservations. - Represent external confirmation as pending when unknown. Implementation constraints - Use a local provider double; create no real events. Verification - Race two bookings for one slot. - Change provider availability during booking and expose the conflict. Deliverables - Booking consistency checks. Rollout and recovery: Keep short local reservations; reconcile unknown external outcomes before releasing them. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-109 — Assess polling versus callbacks for calendar freshness **Task · High priority · Expert** noCV practice brief v5 · BCALENDAR-109 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-105, BCALENDAR-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Integrations 30% · 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 provider's callbacks are delayed, but frequent polling consumes the request budget. Acceptance criteria - Compare bounded polling and callback-assisted approaches. - Declare acceptable staleness and request-budget assumptions. - Rehearse dropped callbacks, duplicates, and provider outages. Implementation constraints - Local measurements do not establish a live provider's delivery guarantees. Verification - Recover a missed callback through polling. - Exhaust the budget and show stale availability explicitly. Deliverables - Freshness tradeoff assessment. Rollout and recovery: Adopt a conservative refresh policy with visible age and a manual recovery path. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-110 — Write the calendar recovery checklist for invalid sync state **Chore · Low priority · Foundational** noCV practice brief v5 · BCALENDAR-110 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Integrations 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. Support needs to recover a calendar without deleting local reservations. Acceptance criteria - Identify the calendar, grant, and sync revision. - Show safe resync and status commands. - Preserve local reservations while replacing imported events. Implementation constraints - No direct lifecycle-state edits. Verification - Recover an invalid token using the guide. - Reject recovery for a revoked grant. Deliverables - Calendar support runbook. Rollout and recovery: Rehearse against synthetic calendars before enabling a support action. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. ## BSLO — Checkout service-level objectives A fictional checkout service reports process uptime while customers experience failed orders and slow confirmations. **Field:** Site reliability. **Suggested stack:** TypeScript, Prometheus, HTTP. **Engineer value:** Practice SLI semantics, alert evaluation, and reliability tradeoffs. **Company value:** Align reliability discussions with customer outcomes and explicit measurement limits. **Delivery agreement:** Deliver executable indicator queries, alert fixtures, and an SLO decision record. ### Setup prerequisites - Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. ### Define indicators Specify measurable user outcomes and valid denominators. #### BSLO-101 — Define eligible checkout attempts and successful completion **Task · Medium priority · Foundational** noCV practice brief v5 · BSLO-101 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define indicators. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Availability reports count health checks as customer success. Acceptance criteria - Define eligible attempts and completion deadlines. - Exclude synthetic probes from customer denominators. - Document validation failures and abandoned checkouts separately. Implementation constraints - Do not exclude service failures to improve the ratio. Verification - Classify representative success and failure traces. - Reject a denominator that includes only completed orders. Deliverables - SLI event contract. Rollout and recovery: Review event semantics before publishing an objective. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-102 — Deduplicate retried checkout attempts in indicator calculations **Bug · High priority · Intermediate** noCV practice brief v5 · BSLO-102 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define indicators. Depends on: BSLO-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Data 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. Client retries inflate both request volume and apparent success. Acceptance criteria - Count one logical attempt under the declared identity. - Preserve retry observations separately. - Flag missing identities without guessing deduplication. Implementation constraints - Avoid user-identifying metric labels. Verification - Count a retried successful attempt once. - Expose ambiguous records with missing attempt IDs. Deliverables - Deduplicated indicator query. Rollout and recovery: Compare old and new counts before switching dashboards. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. ### Compute and alert Handle missing data and evaluate budget burn. #### BSLO-103 — Compute completion latency from consistent event pairs **Task · High priority · Advanced** noCV practice brief v5 · BSLO-103 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compute and alert. Depends on: BSLO-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Data 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. Latency is measured from different start events across client versions. Acceptance criteria - Specify start and completion event semantics. - Reject negative or unmatched durations. - Track excluded samples and instrumentation version. Implementation constraints - State clock assumptions explicitly. Verification - Compute known synthetic durations. - Detect clock skew and unmatched completion events. Deliverables - Latency indicator implementation. Rollout and recovery: Run both definitions during comparison; retain the prior dashboard for diagnosis. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-104 — Keep missing telemetry distinct from successful service **Bug · High priority · Intermediate** noCV practice brief v5 · BSLO-104 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compute and alert. Depends on: BSLO-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 80% · Frontend 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 metrics outage produces an empty query that the dashboard renders as healthy. Acceptance criteria - Represent no data separately from zero failures. - Display data freshness and coverage. - Alert on measurement failure independently. Implementation constraints - Unknown reliability cannot consume zero budget by default. Verification - Show healthy complete telemetry. - Drop a source stream and display unknown coverage. Deliverables - Missing-data handling. Rollout and recovery: Enable measurement alerts before relying on budget policy. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-105 — Implement multi-window error-budget burn calculations **Task · High priority · Advanced** noCV practice brief v5 · BSLO-105 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compute and alert. Depends on: BSLO-102, BSLO-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · Data 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. A brief spike pages the team while a slower sustained incident passes unnoticed. Acceptance criteria - Calculate burn against the declared objective. - Require aligned short and long windows for the chosen alert. - Handle window edges and low sample counts explicitly. Implementation constraints - Thresholds are scenario assumptions, not universal defaults. Verification - Trigger on sustained synthetic burn. - Avoid paging for an isolated low-volume failure under the documented policy. Deliverables - Burn-rate queries and fixtures. Rollout and recovery: Run alerts without notifications locally before operational adoption. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-106 — Separate dependency failure from the customer-facing objective **Task · Medium priority · Advanced** noCV practice brief v5 · BSLO-106 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compute and alert. Depends on: BSLO-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 80% · System 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. The team wants to exclude payment-provider outages from checkout reliability. Acceptance criteria - Keep customer outcome accounting intact. - Add dependency attribution as a separate diagnostic dimension. - Expose uncertain attribution without changing the denominator. Implementation constraints - Do not transfer responsibility by redefining failed outcomes away. Verification - Count a dependency-caused customer failure. - Show attribution missing while retaining the failure. Deliverables - Attribution dashboard contract. Rollout and recovery: Add diagnostics alongside the objective; preserve historical customer outcomes. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. ### Use the objective Connect reliability policy to reviewable operational decisions. #### BSLO-107 — Define release actions for exhausted error budget **Task · High priority · Expert** noCV practice brief v5 · BSLO-107 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Use the objective. Depends on: BSLO-105, BSLO-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 80% · System 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. An exhausted budget triggers a blanket release freeze, including urgent reliability fixes. Acceptance criteria - Distinguish feature, risk-reduction, and emergency changes. - Define reviewed exception authority and expiry. - Compare business urgency against measured reliability risk. Implementation constraints - Policy provides decision support, not automatic business authority. Verification - Apply policy to a normal feature release. - Document an emergency exception with unresolved risks. Deliverables - Error-budget policy decision record. Rollout and recovery: Trial the policy in a tabletop; preserve human release accountability. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-108 — Build an SLO dashboard with bounded diagnostic dimensions **Story · Medium priority · Intermediate** noCV practice brief v5 · BSLO-108 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Use the objective. Depends on: BSLO-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Frontend 30% · Privacy 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. Engineers cannot relate budget burn to endpoint versions without exposing user data. Acceptance criteria - Show objective, burn, eligible volume, and coverage. - Allow only bounded endpoint/version dimensions. - Keep customer identifiers out of labels and URLs. Implementation constraints - Dashboard totals must reconcile with source fixtures. Verification - Reconcile known synthetic totals. - Reject an unbounded user-ID dimension. Deliverables - SLO dashboard definition. Rollout and recovery: Publish read-only views first; restore prior queries if totals diverge. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-109 — Rehearse an objective change without rewriting historical results **Task · High priority · Advanced** noCV practice brief v5 · BSLO-109 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Use the objective. Depends on: BSLO-107, BSLO-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · Data 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. A new completion deadline would make last month's results look better if applied retrospectively. Acceptance criteria - Version objective and indicator definitions. - Compute new results from an explicit effective time. - Preserve historical values under their original definition. Implementation constraints - Show comparison overlap without relabeling old performance. Verification - Run old and new definitions on the same fixture. - Verify historical records remain bound to the old version. Deliverables - SLO revision rehearsal. Rollout and recovery: Run overlapping views before changing the active objective. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. #### BSLO-110 — Write an SLO interpretation guide for low-traffic periods **Chore · Low priority · Foundational** noCV practice brief v5 · BSLO-110 · Checkout service-level objectives Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Use the objective. Depends on: BSLO-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 single failure overnight produces a dramatic percentage without explaining the sample size. Acceptance criteria - Display eligible event count with the ratio. - Explain low-volume uncertainty. - Document when to inspect individual synthetic traces. Implementation constraints - Avoid promises of perfect reliability. Verification - Interpret one failure in a small sample. - Distinguish zero traffic from a healthy measured window. Deliverables - SLO interpretation guide. Rollout and recovery: Link guidance from dashboards and alert descriptions. Project prerequisites: Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required. Engineer value: Practice SLI semantics, alert evaluation, and reliability tradeoffs. Company value: Align reliability discussions with customer outcomes and explicit measurement limits. 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. ## BINCIDENT — Queue backlog incident response A fictional document service has a rising processing backlog. Operators cannot tell whether arrivals, worker failures, or a slow dependency is responsible. **Field:** Site reliability. **Suggested stack:** TypeScript, BullMQ, Redis. **Engineer value:** Practice incident timelines, queue diagnosis, and measured recovery. **Company value:** Produce a repeatable response that preserves work integrity and exposes customer delay. **Delivery agreement:** Deliver local incident instrumentation, recovery controls, and a tabletop report. ### Setup prerequisites - Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. ### Observe backlog Separate queue age, throughput, and failure symptoms. #### BINCIDENT-101 — Report oldest eligible job age alongside queue depth **Task · Medium priority · Foundational** noCV practice brief v5 · BINCIDENT-101 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe backlog. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 80% · Platform 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 shallow queue can still contain a single customer job stuck for hours. Acceptance criteria - Measure oldest eligible age separately from count. - Exclude scheduled future work from overdue age. - Show missing timestamp records explicitly. Implementation constraints - Use bounded job-type labels only. Verification - Measure a known delayed fixture. - Keep future-scheduled jobs out of overdue calculations. Deliverables - Backlog age metric. Rollout and recovery: Add read-only metrics before changing worker behavior. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-102 — Separate arrival rate from successful service rate **Task · Medium priority · Intermediate** noCV practice brief v5 · BINCIDENT-102 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe backlog. Depends on: BINCIDENT-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 dashboard counts retries as new incoming customer work. Acceptance criteria - Track logical arrivals, attempts, and completions separately. - Use consistent measurement windows. - Expose worker concurrency with throughput. Implementation constraints - Do not infer capacity from a single peak sample. Verification - Reconcile a fixture with repeated attempts. - Detect growing backlog despite high attempt throughput. Deliverables - Queue flow dashboard. Rollout and recovery: Compare against synthetic queue inventory before relying on alerts. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. ### Contain safely Control arrivals and retries while preserving job identity. #### BINCIDENT-103 — Identify poison jobs without starving unrelated work **Bug · High priority · Advanced** noCV practice brief v5 · BINCIDENT-103 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain safely. Depends on: BINCIDENT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 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. One malformed document repeatedly consumes the first worker slot. Acceptance criteria - Bound attempts by failure category. - Move exhausted jobs to an inspectable terminal holding state. - Allow unrelated valid jobs to continue. Implementation constraints - Keep payload contents out of generic incident logs. Verification - Quarantine a deterministic poison job. - Process a valid neighboring job and preserve its identity. Deliverables - Poison-job containment. Rollout and recovery: Enable per job type; retain held work for reviewed correction. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-104 — Pause selected producers while preserving accepted work **Task · High priority · Advanced** noCV practice brief v5 · BINCIDENT-104 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain safely. Depends on: BINCIDENT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Platform engineering 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. Operators stop every producer even though only one import path overloads the queue. Acceptance criteria - Scope pause controls to declared producer classes. - Reject new work with explicit retry guidance. - Preserve previously accepted job records. Implementation constraints - Privileged pause changes require an audit entry. Verification - Pause the synthetic import producer. - Verify another producer works and unauthorized pause is denied. Deliverables - Scoped admission control. Rollout and recovery: Start with one producer switch; restore intake gradually after backlog age recovers. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-105 — Recover expired worker leases without concurrent duplicate effects **Bug · High priority · Advanced** noCV practice brief v5 · BINCIDENT-105 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain safely. Depends on: BINCIDENT-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Platform 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 worker crashes after producing output but before acknowledging completion. Acceptance criteria - Use stable job operation identity. - Reclaim only expired ownership. - Adopt existing completed output before repeating effects. Implementation constraints - Mock effects must be idempotent and locally scoped. Verification - Crash after effect acceptance and reclaim. - Race two reclaimers and observe one terminal outcome. Deliverables - Lease recovery behavior. Rollout and recovery: Reclaim in bounded batches; stop on conflicting output identities. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-106 — Tune retry delay for a throttled dependency **Task · High priority · Intermediate** noCV practice brief v5 · BINCIDENT-106 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain safely. Depends on: BINCIDENT-103, BINCIDENT-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Integrations 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. Immediate retries amplify the dependency's temporary throttling. Acceptance criteria - Respect bounded retry-after guidance. - Apply jitter with reproducible test control. - Cap total attempts and elapsed time. Implementation constraints - Never retry permanent validation or authorization failures. Verification - Recover after a temporary throttle. - Exhaust a persistent outage without a retry storm. Deliverables - Dependency retry policy. Rollout and recovery: Trial on one job class; pause dispatch if throttling remains sustained. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. ### Recover and learn Drain work and validate recovery decisions. #### BINCIDENT-107 — Estimate backlog drain time under explicit capacity assumptions **Task · Medium priority · Advanced** noCV practice brief v5 · BINCIDENT-107 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and learn. Depends on: BINCIDENT-102, BINCIDENT-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. Support promises a completion time using queue depth divided by the busiest worker's speed. Acceptance criteria - Use measured successful service and arrival rates. - Report assumptions and uncertainty bounds. - Return no finite estimate when arrivals meet or exceed service. Implementation constraints - Use synthetic measurements and avoid general capacity claims. Verification - Estimate a controlled draining workload. - Show an unstable workload as non-draining. Deliverables - Drain-time estimator. Rollout and recovery: Publish estimates with their observation window; retract stale estimates. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-108 — Rehearse backlog recovery with a constrained worker budget **Task · High priority · Expert** noCV practice brief v5 · BINCIDENT-108 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and learn. Depends on: BINCIDENT-104, BINCIDENT-105, BINCIDENT-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. Adding workers may increase database contention and make recovery slower. Acceptance criteria - Compare two bounded concurrency settings under identical arrivals. - Measure completion age, dependency pressure, and duplicate-effect checks. - Choose a recovery setting with stated tradeoffs. Implementation constraints - Record machine limits; do not extrapolate local capacity to production. Verification - Drain the synthetic incident workload. - Demonstrate a setting that worsens contention or violates limits. Deliverables - Recovery experiment report. Rollout and recovery: Raise concurrency in measured steps; revert when dependency or integrity thresholds fail. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-109 — Create an incident timeline from control and queue events **Story · Medium priority · Intermediate** noCV practice brief v5 · BINCIDENT-109 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and learn. Depends on: BINCIDENT-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 80% · Data 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. The post-incident discussion relies on memory of when pauses and retries changed. Acceptance criteria - Record control actions with actor and UTC time. - Link changes to observed backlog metrics. - Separate observations from causal hypotheses. Implementation constraints - Exclude customer payloads and personal operator commentary. Verification - Reconstruct the synthetic incident. - Show a missing observation as a gap rather than inventing timing. Deliverables - Incident timeline exporter. Rollout and recovery: Preserve original event records; append corrections to the timeline. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. #### BINCIDENT-110 — Write a queue handoff with explicit resume conditions **Chore · Low priority · Foundational** noCV practice brief v5 · BINCIDENT-110 · Queue backlog incident response Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and learn. Depends on: BINCIDENT-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. The next on-call engineer inherits paused intake without knowing when to reopen it. Acceptance criteria - List active controls and held job counts. - Specify measurable intake-resume conditions. - Document safe rollback of each temporary control. Implementation constraints - Commands target the local incident fixture only. Verification - Resume intake using the handoff. - Keep intake paused when dependency health remains unknown. Deliverables - On-call handoff runbook. Rollout and recovery: Require a handoff whenever containment outlives the current operator. Project prerequisites: Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures. Engineer value: Practice incident timelines, queue diagnosis, and measured recovery. Company value: Produce a repeatable response that preserves work integrity and exposes customer delay. 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. ## BRESTORE — Backup restoration rehearsal A fictional reporting service has successful backup jobs but no recent restore rehearsal. Database rows reference objects with different retention schedules. **Field:** Site reliability. **Suggested stack:** PostgreSQL, S3-compatible storage, TypeScript. **Engineer value:** Practice recovery consistency, integrity validation, and honest recovery objectives. **Company value:** Replace backup-job optimism with a repeatable restoration assessment. **Delivery agreement:** Deliver a local restore harness and recovery report; change no production backup policy. ### Setup prerequisites - Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. ### Inventory recovery dependencies Define backup scope and consistency requirements. #### BRESTORE-101 — Inventory the data required to restore one report **Task · Medium priority · Foundational** noCV practice brief v5 · BRESTORE-101 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory recovery dependencies. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Storage systems 30% · Database 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 database backup omits the object containing the actual report. Acceptance criteria - List database rows, objects, and configuration references. - Identify authoritative and rebuildable data. - Document retention mismatches. Implementation constraints - Use synthetic records and secret placeholders. Verification - Trace one report end to end. - Identify a missing object as an incomplete recovery dependency. Deliverables - Recovery inventory. Rollout and recovery: Review inventory before altering backup jobs. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-102 — Define a consistent backup manifest across stores **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-102 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory recovery dependencies. Depends on: BRESTORE-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Database 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. Database and object backups represent different points in time. Acceptance criteria - Record snapshot boundary and object version digests. - Include schema and manifest versions. - Reject incomplete manifests. Implementation constraints - Do not equate wall-clock proximity with transactional consistency. Verification - Build a coherent synthetic manifest. - Reject a manifest referencing an unavailable object version. Deliverables - Backup manifest contract. Rollout and recovery: Version manifests and retain the prior complete backup set. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. ### Restore isolated data Reconstruct and validate a coherent snapshot. #### BRESTORE-103 — Guard restore commands against non-scratch targets **Task · High priority · Intermediate** noCV practice brief v5 · BRESTORE-103 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Site reliability 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. A restore command can overwrite an existing developer database by mistake. Acceptance criteria - Require an explicit scratch target. - Reject nonempty or unapproved destinations. - Display sanitized target identity. Implementation constraints - No remote or production endpoints in this exercise. Verification - Restore into an empty named scratch database. - Reject an occupied or remote destination. Deliverables - Restore target guard. Rollout and recovery: Default to inspection-only until target validation passes. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-104 — Verify backup bytes before applying restored data **Task · High priority · Intermediate** noCV practice brief v5 · BRESTORE-104 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-102, BRESTORE-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. A truncated object archive is discovered only after the application starts. Acceptance criteria - Validate declared sizes and content digests. - Reject missing or extra required archive members. - Stop before promotion on any mismatch. Implementation constraints - Bound archive expansion and reject traversal paths. Verification - Verify a complete backup set. - Reject corruption and an escaping archive entry. Deliverables - Backup integrity verifier. Rollout and recovery: Keep failed restores isolated and retain diagnostic metadata. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-105 — Restore database references before enabling object reads **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-105 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Database engineering 30% · Storage 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 application exposes restored metadata while referenced objects are still missing. Acceptance criteria - Keep restored service unavailable until coherence checks pass. - Reconcile every required object reference. - Report dangling references without inventing replacements. Implementation constraints - Public readiness must not imply partial data is complete. Verification - Restore a coherent report set. - Remove one object and keep readiness blocked. Deliverables - Restore readiness checks. Rollout and recovery: Promote only a validated restore; preserve the original scratch failure state. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-106 — Rebuild derived indexes from restored authoritative records **Task · Medium priority · Advanced** noCV practice brief v5 · BRESTORE-106 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. The backup contains stale search indexes that disagree with restored reports. Acceptance criteria - Rebuild indexes from the restored authority. - Make rebuild restartable and bounded. - Verify index counts and sampled content bindings. Implementation constraints - Never treat an index as the source of truth. Verification - Rebuild after a complete restore. - Interrupt rebuilding and resume without duplicate entries. Deliverables - Derived-data rebuild command. Rollout and recovery: Keep search unavailable until its version matches restored data. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. ### Rehearse disruption Measure recovery and document unrecoverable gaps. #### BRESTORE-107 — Check application compatibility against restored schema versions **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-107 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-105, BRESTORE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. The latest application cannot read a backup taken before a schema contraction. Acceptance criteria - Declare compatible application/schema pairs. - Run representative reads and writes after restore. - Identify migration requirements before promotion. Implementation constraints - Do not silently upgrade restored data without a reviewed path. Verification - Start a compatible build against the restore. - Reject an incompatible schema with clear guidance. Deliverables - Restore compatibility matrix. Rollout and recovery: Retain a compatible application artifact with each backup generation. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-108 — Measure recovery time and recoverable data loss separately **Task · High priority · Expert** noCV practice brief v5 · BRESTORE-108 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Management asks for recovery objectives, but a single successful local restore is being treated as a guarantee. Acceptance criteria - Measure each restore phase under stated dataset and machine limits. - Compute the gap between backup boundary and failure time. - Report untested scale and dependency assumptions. Implementation constraints - Local rehearsal establishes observations, not production RTO or RPO guarantees. Verification - Measure a complete synthetic recovery. - Expose an unrecoverable post-backup write explicitly. Deliverables - Recovery assessment. Rollout and recovery: Use results to propose objectives; repeat in the target environment before committing to them. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-109 — Rehearse recovery when the newest backup is unusable **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-109 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-104, BRESTORE-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · Storage 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 latest backup manifest is valid but one required object version is unavailable. Acceptance criteria - Select an older complete recovery set explicitly. - Report the increased data-loss window. - Preserve evidence of why the newest set was rejected. Implementation constraints - Never merge unrelated backup generations without a defined consistency rule. Verification - Recover from the previous complete set. - Reject an inconsistent mix of database and object generations. Deliverables - Backup fallback rehearsal. Rollout and recovery: Keep multiple complete generations until retention review permits removal. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-110 — Write a restore handoff with promotion and abandonment criteria **Chore · Low priority · Foundational** noCV practice brief v5 · BRESTORE-110 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. An operator needs to decide whether a long-running restore is safe to promote. Acceptance criteria - List required integrity and compatibility checks. - Document promotion authority and target identity. - Explain how to abandon the scratch restore safely. Implementation constraints - Avoid destructive cleanup commands outside the named scratch directory. Verification - Follow the handoff to promote a valid fixture. - Keep a restore with missing objects unpromoted. Deliverables - Restore runbook. Rollout and recovery: Store the runbook with backup manifests and compatible build references. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. ## BLOADSHED — Overload admission and graceful degradation A fictional ticketing service becomes unresponsive during event releases because optional recommendation calls consume the same resources as reservation checks. **Field:** Site reliability. **Suggested stack:** TypeScript, HTTP, Redis. **Engineer value:** Practice overload behavior, admission control, and fair performance experiments. **Company value:** Create predictable failure and degradation behavior under declared capacity constraints. **Delivery agreement:** Deliver local controls and measurements; no live load generation. ### Setup prerequisites - Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. ### Characterize overload Define essential outcomes and bounded workload assumptions. #### BLOADSHED-101 — Classify essential and optional ticketing requests **Task · Medium priority · Foundational** noCV practice brief v5 · BLOADSHED-101 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Characterize overload. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · System 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. Recommendation requests compete with reservation checks without any priority policy. Acceptance criteria - List request classes and user impact. - Define allowed degradation per class. - Keep reservation correctness invariant. Implementation constraints - Do not prioritize users by inferred personal traits. Verification - Classify a reservation and recommendation request. - Identify a request that must fail explicitly rather than degrade silently. Deliverables - Request-class policy. Rollout and recovery: Review classification before applying limits. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-102 — Build a workload that preserves offered arrival rate **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-102 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Characterize overload. Depends on: BLOADSHED-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. A closed-loop load script hides overload by sending fewer requests as responses slow. Acceptance criteria - Record offered, admitted, completed, and rejected rates. - Use bounded open-loop scheduling. - Report dropped generator work and resource limits. Implementation constraints - Run only against the local fixture. Verification - Generate the declared steady arrival rate. - Overload the generator and report its invalid measurement window. Deliverables - Load harness. Rollout and recovery: Cap duration and concurrency; discard runs with unreported generator saturation. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. ### Protect service capacity Limit queues and isolate optional work. #### BLOADSHED-103 — Bound the waiting queue before worker slots are exhausted **Task · High priority · Intermediate** noCV practice brief v5 · BLOADSHED-103 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Platform engineering 40% · 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. Requests accumulate indefinitely while waiting for a shared dependency. Acceptance criteria - Enforce a finite waiting capacity. - Return a documented overload response when full. - Remove cancelled requests from the queue. Implementation constraints - Never report rejected requests as successful degradation. Verification - Admit work below the limit. - Overflow and cancel queued requests without leaked slots. Deliverables - Bounded admission queue. Rollout and recovery: Start with conservative limits; restore the previous policy if essential outcomes regress. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-104 — Isolate optional recommendation concurrency **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-104 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-101, BLOADSHED-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Performance engineering 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. Pattern topics: Bulkhead (apply). Bulkhead — Apply: Bound optional recommendation concurrency separately from essential requests and show that exhausted optional capacity cannot consume the essential reserve. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Slow recommendations consume every outbound connection. Acceptance criteria - Use a separate optional-work concurrency budget. - Reserve declared capacity for essential requests. - Skip optional work when its budget is unavailable. Implementation constraints - Use a real bounded pool, not an unbounded background task list. Verification - Serve reservations while recommendations stall. - Exhaust optional slots and verify graceful omission. Deliverables - Optional-work bulkhead. Rollout and recovery: Enable the bulkhead before increasing overall concurrency. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-105 — Propagate request deadlines to downstream work **Bug · High priority · Advanced** noCV practice brief v5 · BLOADSHED-105 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103, BLOADSHED-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Site reliability 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. The client has timed out while its dependency request continues holding a slot. Acceptance criteria - Derive child deadlines from remaining request time. - Abort owned work on cancellation. - Release capacity even when a double ignores cancellation. Implementation constraints - Bound cleanup time and track late completions safely. Verification - Complete within a shared deadline. - Timeout an uncooperative dependency and reclaim the slot. Deliverables - Deadline propagation. Rollout and recovery: Default to shorter optional deadlines; retain explicit timeout responses. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-106 — Provide retry guidance that does not synchronize every client **Task · Medium priority · Intermediate** noCV practice brief v5 · BLOADSHED-106 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Site reliability 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. All rejected clients retry exactly one second later and recreate the spike. Acceptance criteria - Return bounded retry guidance. - Document jitter and attempt ceilings for clients. - Avoid automatic retry of unsafe writes. Implementation constraints - Use deterministic random input in tests. Verification - Spread synthetic client retries across the window. - Verify non-idempotent requests are not blindly retried. Deliverables - Overload response contract. Rollout and recovery: Publish guidance with admission changes; monitor repeated rejection bursts. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-107 — Preserve fair access across tenant request queues **Task · High priority · Advanced** noCV practice brief v5 · BLOADSHED-107 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect service capacity. Depends on: BLOADSHED-103, BLOADSHED-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Platform engineering 40% · 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. One large tenant fills every waiting slot and blocks smaller tenants. Acceptance criteria - Bound per-tenant queued work. - Define a transparent scheduling policy. - Prevent idle tenant allocation from wasting all spare capacity. Implementation constraints - Use synthetic tenant classes and document fairness assumptions. Verification - Serve concurrent tenants under sustained load. - Flood one tenant and verify others retain declared progress. Deliverables - Tenant scheduling policy. Rollout and recovery: Trial with fixed limits; disable new policy if starvation appears. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. ### Validate recovery Compare policies and verify return to normal operation. #### BLOADSHED-108 — Compare rejection policies under the same offered workload **Task · High priority · Expert** noCV practice brief v5 · BLOADSHED-108 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-102, BLOADSHED-105, BLOADSHED-106, BLOADSHED-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. The team must choose between a larger queue and earlier rejection. Acceptance criteria - Compare identical arrival traces and resource budgets. - Measure essential latency, rejection, completion, and recovery separately. - Explain tradeoffs and remaining uncertainty. Implementation constraints - Do not compare only successful-response latency or hide rejected work. Verification - Run both policies on the same synthetic burst. - Expose a policy that improves accepted latency by rejecting more work. Deliverables - Admission policy assessment. Rollout and recovery: Choose a bounded default and retain a tested configuration rollback. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-109 — Prevent capacity oscillation when the burst ends **Bug · High priority · Advanced** noCV practice brief v5 · BLOADSHED-109 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Degradation switches on and off rapidly near the threshold. Acceptance criteria - Add declared hysteresis or cooldown semantics. - Return to normal after sustained recovery. - Keep manual emergency controls auditable. Implementation constraints - Avoid permanent degradation after transient overload. Verification - Recover after a controlled burst. - Oscillate near thresholds and verify bounded mode changes. Deliverables - Recovery controller tests. Rollout and recovery: Run in observation mode first; allow a safe fixed-policy fallback. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. #### BLOADSHED-110 — Document the customer-visible degraded service contract **Chore · Low priority · Foundational** noCV practice brief v5 · BLOADSHED-110 · Overload admission and graceful degradation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate recovery. Depends on: BLOADSHED-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Product support cannot explain which features disappear during overload. Acceptance criteria - List omitted features and explicit failures. - Describe recovery indicators without promising exact times. - Include support diagnosis from safe metrics. Implementation constraints - No false success when essential work was rejected. Verification - Review a degraded response against the guide. - Verify a failed reservation is never described as completed. Deliverables - Degradation guide. Rollout and recovery: Ship alongside controls and update it when request classes change. Project prerequisites: Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays. Engineer value: Practice overload behavior, admission control, and fair performance experiments. Company value: Create predictable failure and degradation behavior under declared capacity constraints. 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. ## BREADINESS — Seasonal traffic readiness review A fictional course platform expects a registration deadline spike. Capacity assumptions, escalation ownership, and degradation decisions are scattered across old documents. **Field:** Site reliability. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. **Company value:** Produce a concrete launch-readiness assessment with measurable risks and recovery actions. **Delivery agreement:** Deliver a local rehearsal and review packet; external launch approval remains outside the exercise. ### Setup prerequisites - Create synthetic registration traces and local dependency doubles with finite connection and request limits. ### Collect assumptions Define demand, dependencies, and launch invariants. #### BREADINESS-101 — Turn the registration forecast into a workload envelope **Task · Medium priority · Foundational** noCV practice brief v5 · BREADINESS-101 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Collect assumptions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. The launch plan says 'ten times traffic' without a base rate or request mix. Acceptance criteria - Declare arrival range, duration, and request mix. - Separate new registrations from read traffic. - Identify unknown forecast assumptions. Implementation constraints - Use fictional demand figures and label them assumptions. Verification - Convert the forecast into a bounded local trace. - Reject an unspecified multiplier as a complete workload definition. Deliverables - Workload envelope. Rollout and recovery: Review assumptions before capacity testing. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-102 — Inventory dependency quotas and exhaustion behavior **Task · High priority · Intermediate** noCV practice brief v5 · BREADINESS-102 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Collect assumptions. Depends on: BREADINESS-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · System 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 database pool and email adapter have different limits and failure semantics. Acceptance criteria - Record local pool and mock-provider ceilings. - Describe behavior at each limit. - Assign an owner to unresolved limits. Implementation constraints - No live provider quotas are assumed from memory. Verification - Exhaust a configured local limit. - Keep unknown external quotas marked unverified. Deliverables - Dependency constraint register. Rollout and recovery: Resolve critical unknowns before claiming launch readiness. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. ### Test constraints Exercise saturation and failure paths. #### BREADINESS-103 — Add connection-pool wait time to registration diagnostics **Task · Medium priority · Intermediate** noCV practice brief v5 · BREADINESS-103 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Site reliability 40% · 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. Slow registration is blamed on SQL even when requests are waiting for a connection. Acceptance criteria - Measure wait and query duration separately. - Track pool occupancy with bounded labels. - Bound waiting time and cancellation cleanup. Implementation constraints - Do not expose SQL parameters or user identifiers. Verification - Observe deliberate pool contention. - Cancel a waiting request and verify it leaves the queue. Deliverables - Pool diagnostics. Rollout and recovery: Introduce read-only metrics before changing pool size. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-104 — Exercise registration idempotency during client reconnects **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-104 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 40% · Quality engineering 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. A network interruption causes clients to resubmit successful registrations. Acceptance criteria - Reuse stable submission identity. - Preserve one enrollment per intended registration. - Return the accepted result on exact replay. Implementation constraints - Conflicting payload reuse must fail explicitly. Verification - Replay after a lost response. - Race two conflicting submissions under one identity. Deliverables - Reconnect regression suite. Rollout and recovery: Gate the surge rehearsal on idempotency correctness. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-105 — Decouple confirmation delivery from accepted registration **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-105 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Backend 40% · 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 notification provider makes accepted registrations appear failed. Acceptance criteria - Commit registration and notification intent atomically. - Return accepted registration independently of delivery latency. - Expose pending delivery without duplicate enrollment. Implementation constraints - Use a local notification double; send no messages. Verification - Accept registration during a notification outage. - Recover delivery and verify one logical notification operation. Deliverables - Notification outbox flow. Rollout and recovery: Retain pending intents through rollback; pause dispatch independently. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-106 — Test read-only degradation when enrollment writes are unavailable **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-106 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-103, BREADINESS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Backend 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 database write outage should not make the entire course catalog disappear. Acceptance criteria - Preserve declared safe read behavior. - Fail enrollment explicitly when writes cannot commit. - Show data age when serving a cached catalog. Implementation constraints - Never queue unacknowledged enrollments invisibly. Verification - Read the catalog during a write failure. - Attempt enrollment and verify no false confirmation. Deliverables - Write-outage behavior. Rollout and recovery: Enable only documented degradation; clear stale cache on incompatible catalog changes. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-107 — Review cache warmup without creating a database stampede **Task · High priority · Advanced** noCV practice brief v5 · BREADINESS-107 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test constraints. Depends on: BREADINESS-103, BREADINESS-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Distributed systems 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. Every process warms the same popular course pages simultaneously after deployment. Acceptance criteria - Bound warmup concurrency and total work. - Coalesce identical cache fills. - Keep cache failure from multiplying database reads. Implementation constraints - Use a finite synthetic course list. Verification - Warm popular entries under the configured budget. - Expire entries together and verify bounded database pressure. Deliverables - Cache warmup controller. Rollout and recovery: Warm gradually before synthetic peak; disable warmup if database wait rises. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. ### Prepare operations Make readiness gaps and controls reviewable. #### BREADINESS-108 — Decide launch capacity with cost and failure headroom **Task · High priority · Expert** noCV practice brief v5 · BREADINESS-108 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-102, BREADINESS-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Site reliability 40% · Cloud infrastructure 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 cheapest configuration passes average load but fails when one worker is unavailable. Acceptance criteria - Compare configurations under identical peak and degraded-capacity traces. - Measure accepted work, latency, errors, and resource cost assumptions. - Document required headroom and untested scale. Implementation constraints - Local observations do not prove production capacity. Verification - Rehearse the selected configuration with one simulated worker loss. - Reject a configuration that only passes by dropping critical work. Deliverables - Capacity decision record. Rollout and recovery: Adopt only within the declared workload envelope and retain rollback settings. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-109 — Run a launch tabletop with explicit stop conditions **Task · High priority · Intermediate** noCV practice brief v5 · BREADINESS-109 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Operators lack a shared decision point for pausing registration during a surge. Acceptance criteria - Define measurable pause and resume conditions. - Assign incident and product decision roles. - Rehearse notification outage and database saturation scenarios. Implementation constraints - Record decisions as simulation outcomes. Verification - Walk through a recoverable surge. - Keep writes paused when integrity is uncertain. Deliverables - Tabletop record. Rollout and recovery: Review open actions before the hypothetical launch. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. #### BREADINESS-110 — Publish a launch handoff with unresolved readiness gaps **Chore · Low priority · Foundational** noCV practice brief v5 · BREADINESS-110 · Seasonal traffic readiness review Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare operations. Depends on: BREADINESS-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 green test report obscures that external quotas and target-environment recovery remain unverified. Acceptance criteria - List observed checks and unresolved assumptions separately. - Include active configuration and recovery commands. - Name owners for deferred verification. Implementation constraints - Do not mark unexecuted checks complete. Verification - Trace a readiness claim to its local result. - Keep an unverified provider limit visible. Deliverables - Readiness handoff packet. Rollout and recovery: Update after configuration changes; withdraw stale readiness conclusions. Project prerequisites: Create synthetic registration traces and local dependency doubles with finite connection and request limits. Engineer value: Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs. Company value: Produce a concrete launch-readiness assessment with measurable risks and recovery actions. 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. ## BCOST — Object-storage cost controls A fictional analytics service stores exports and intermediate artifacts indefinitely. Finance sees a rising bill but engineers cannot explain which lifecycle policy is responsible. **Field:** Cloud infrastructure. **Suggested stack:** TypeScript, S3-compatible storage, CSV. **Engineer value:** Practice cost attribution, lifecycle modeling, and safe retention controls. **Company value:** Produce reviewable storage-cost options with recovery and data-retention consequences. **Delivery agreement:** Deliver an offline cost model and local policy rehearsal; delete no real cloud objects. ### Setup prerequisites - Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. ### Attribute storage Describe objects, ownership, and cost assumptions. #### BCOST-101 — Normalize object inventory units and ownership labels **Task · Medium priority · Foundational** noCV practice brief v5 · BCOST-101 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Attribute storage. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Cloud infrastructure 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. Inventory exports mix byte counts, rounded sizes, and missing owners. Acceptance criteria - Use bytes as the canonical size unit. - Separate unknown owners from shared infrastructure. - Preserve inventory time and source identity. Implementation constraints - Use synthetic names without customer identifiers. Verification - Normalize mixed display units accurately. - Reject negative sizes and report missing ownership. Deliverables - Inventory parser. Rollout and recovery: Run read-only attribution before proposing lifecycle changes. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-102 — Model storage, requests, and transfer costs separately **Task · Medium priority · Intermediate** noCV practice brief v5 · BCOST-102 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Attribute storage. Depends on: BCOST-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 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 storage-only estimate ignores the cost of regenerating and downloading exports. Acceptance criteria - Version explicit fictional unit-price assumptions. - Calculate each cost component separately. - Show unknown request or transfer volume. Implementation constraints - Do not present modeled savings as observed billing results. Verification - Reconcile a hand-calculated synthetic example. - Refuse a total when a required unit conversion is ambiguous. Deliverables - Offline cost calculator. Rollout and recovery: Keep original assumptions with every report. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. ### Model lifecycle changes Evaluate retention and transfer controls safely. #### BCOST-103 — Classify objects by recovery and retention requirements **Task · High priority · Advanced** noCV practice brief v5 · BCOST-103 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model lifecycle changes. Depends on: BCOST-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Cloud infrastructure 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 broad expiry rule would remove the only copy of finalized reports. Acceptance criteria - Distinguish authoritative, reproducible, and temporary objects. - Attach minimum retention and recovery requirements. - Block lifecycle proposals for unclassified objects. Implementation constraints - Retention requirements are scenario inputs, not legal advice. Verification - Allow expiry of a declared temporary object. - Block deletion of an authoritative unclassified report. Deliverables - Object lifecycle classification. Rollout and recovery: Start with temporary classes only; preserve unknown objects. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-104 — Simulate lifecycle transitions before object deletion **Task · High priority · Intermediate** noCV practice brief v5 · BCOST-104 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model lifecycle changes. Depends on: BCOST-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 40% · Storage systems 40% · 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. Operators cannot see which objects a new rule would affect. Acceptance criteria - Produce a dry-run object set and byte total. - Bind the plan to inventory and policy digests. - Reject execution if the reviewed plan is stale. Implementation constraints - The exercise uses only a disposable local object store. Verification - Preview an eligible temporary set. - Change policy inputs and reject the stale plan. Deliverables - Lifecycle dry-run planner. Rollout and recovery: Require review of the exact plan; keep deletion disabled by default. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-105 — Account for retrieval delay in colder storage proposals **Task · High priority · Advanced** noCV practice brief v5 · BCOST-105 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model lifecycle changes. Depends on: BCOST-102, BCOST-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Storage systems 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 cheaper storage tier may violate the reporting team's recovery expectations. Acceptance criteria - Model retrieval time and per-request charges explicitly. - Compare ordinary access and restore scenarios. - Exclude objects whose declared recovery target is incompatible. Implementation constraints - Use simulated tier behavior and labeled assumptions. Verification - Compare two fictional tier policies. - Reject a cheap option that misses the recovery requirement. Deliverables - Tier tradeoff report. Rollout and recovery: Pilot only reproducible artifacts with a tested restore path. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-106 — Bound export retention per tenant without crossing ownership **Task · High priority · Advanced** noCV practice brief v5 · BCOST-106 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model lifecycle changes. Depends on: BCOST-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Storage systems 30% · Cloud infrastructure 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. One tenant's cleanup job selects similarly named exports belonging to another. Acceptance criteria - Scope inventory and policy evaluation by tenant identity. - Use opaque object references rather than name prefixes alone. - Audit planned and completed cleanup identities. Implementation constraints - Repository boundaries must enforce scope. Verification - Expire eligible exports for one tenant. - Attempt cross-tenant cleanup and verify denial. Deliverables - Scoped retention evaluator. Rollout and recovery: Trial on one synthetic tenant; stop on inventory discrepancies. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-107 — Reduce repeated downloads with integrity-aware caching **Task · Medium priority · Intermediate** noCV practice brief v5 · BCOST-107 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model lifecycle changes. Depends on: BCOST-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · API design 30% · Security 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. Unchanged exports are repeatedly transferred because clients cannot validate their cache. Acceptance criteria - Expose stable content validators for immutable exports. - Honor conditional reads correctly. - Invalidate cached authority when access is revoked. Implementation constraints - A content digest is not an access credential. Verification - Return unchanged status for an authorized matching validator. - Deny a revoked client despite its cached validator. Deliverables - Conditional-download contract. Rollout and recovery: Enable for immutable exports first; retain full-download fallback. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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 savings proposals Compare options and expose uncertainty. #### BCOST-108 — Compare retention changes against rebuild workload and budget **Task · High priority · Expert** noCV practice brief v5 · BCOST-108 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review savings proposals. Depends on: BCOST-105, BCOST-106, BCOST-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Performance engineering 30% · Storage 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. Deleting intermediate files saves storage but may shift cost into repeated computation. Acceptance criteria - Model storage, rebuild, transfer, and operational effort together. - Run bounded local rebuild measurements with declared inputs. - Show uncertainty ranges and excluded costs. Implementation constraints - No claim of real bill reduction from synthetic data. Verification - Compare a retained and regenerated artifact policy. - Expose the case where regeneration costs more. Deliverables - Cost-control decision record. Rollout and recovery: Choose a reversible policy for reproducible data; preserve authoritative copies. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-109 — Add budget alerts that distinguish actual and forecast usage **Story · Medium priority · Intermediate** noCV practice brief v5 · BCOST-109 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review savings proposals. Depends on: BCOST-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 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. A forecast estimate appears in the same chart as already-incurred usage. Acceptance criteria - Label measured inventory cost and forecast separately. - Define alert thresholds and data freshness. - Avoid duplicate alerts for one reporting window. Implementation constraints - Alerts remain local outputs; send no external notifications. Verification - Trigger a synthetic budget threshold. - Show stale inventory as uncertain instead of a current total. Deliverables - Budget alert fixtures. Rollout and recovery: Run advisory reports before operational notification wiring. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. #### BCOST-110 — Document restoration before approving local expiry rules **Chore · Low priority · Foundational** noCV practice brief v5 · BCOST-110 · Object-storage cost controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review savings proposals. Depends on: BCOST-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Cloud infrastructure 30% · Storage 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. Cleanup reviewers need to understand which deleted artifacts can be recreated. Acceptance criteria - Identify rebuild inputs and commands. - State unrecoverable classes explicitly. - Include the latest dry-run plan identity. Implementation constraints - Do not promise recovery without retained inputs. Verification - Rebuild an expired synthetic intermediate artifact. - Reject expiry when required rebuild inputs are absent. Deliverables - Retention review checklist. Rollout and recovery: Attach to policy proposals and re-review after input changes. Project prerequisites: Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions. Engineer value: Practice cost attribution, lifecycle modeling, and safe retention controls. Company value: Produce reviewable storage-cost options with recovery and data-retention consequences. 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. ## BIAC — Reviewable infrastructure plan pipeline A fictional application team manages a small database, cache, and object store. Reviewers struggle to distinguish harmless configuration changes from destructive replacements. **Field:** Cloud infrastructure. **Suggested stack:** TypeScript, Terraform plan JSON, Policy fixtures. **Engineer value:** Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. **Company value:** Give infrastructure reviewers concrete change scope and recovery consequences. **Delivery agreement:** Deliver an offline plan-review tool and synthetic workflow; provision nothing externally. ### Setup prerequisites - Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. ### Parse plan authority Normalize resource actions and unknown values. #### BIAC-101 — Normalize infrastructure resource actions for review **Task · Medium priority · Foundational** noCV practice brief v5 · BIAC-101 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Parse plan authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 70% · Developer tooling 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. Review summaries collapse updates and replacements into one change count. Acceptance criteria - Separate create, update, replace, and delete actions. - Preserve resource addresses and dependencies. - Represent unknown values explicitly. Implementation constraints - Treat plan JSON as untrusted data. Verification - Parse a valid mixed-action plan. - Reject malformed action combinations. Deliverables - Plan action model. Rollout and recovery: Adopt read-only summaries before any execution integration. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-102 — Redact sensitive plan values while preserving review context **Task · High priority · Intermediate** noCV practice brief v5 · BIAC-102 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Parse plan authority. Depends on: BIAC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Cloud infrastructure 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 database password appears in a generated review report. Acceptance criteria - Honor sensitive markers recursively. - Remove seeded secret values from report and errors. - Keep resource identity and action visible. Implementation constraints - Unknown nested formats must fail safely. Verification - Review a non-sensitive change. - Seed secrets in nested arrays and verify redaction. Deliverables - Plan redaction boundary. Rollout and recovery: Block report publication if redaction validation fails. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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 risk Surface destructive changes and policy failures. #### BIAC-103 — Flag replacements of persistent resources with recovery requirements **Task · High priority · Advanced** noCV practice brief v5 · BIAC-103 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review risk. Depends on: BIAC-101, BIAC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Site reliability 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 small naming change replaces the database resource. Acceptance criteria - Identify persistent resource replacements. - Require declared backup and restore context. - Show dependent application impact. Implementation constraints - Do not infer that a snapshot policy proves restorability. Verification - Flag a synthetic database replacement. - Allow a stateless replacement with its distinct risk classification. Deliverables - Replacement risk rule. Rollout and recovery: Require review before any persistent-resource execution path. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-104 — Reject public exposure introduced by default configuration **Bug · High priority · Advanced** noCV practice brief v5 · BIAC-104 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review risk. Depends on: BIAC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Cloud infrastructure 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 omitted access setting turns a private storage resource public. Acceptance criteria - Evaluate effective exposure including defaults. - Identify the exact field causing exposure. - Keep unknown defaults unresolved. Implementation constraints - Use explicit provider-schema fixtures rather than live provider assumptions. Verification - Detect a public-access transition. - Keep unknown provider behavior blocked for review. Deliverables - Exposure policy check. Rollout and recovery: Start with the modeled resource types; reject unsupported exposure analysis. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-105 — Validate backup retention changes against declared recovery policy **Task · High priority · Intermediate** noCV practice brief v5 · BIAC-105 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review risk. Depends on: BIAC-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Cloud infrastructure 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 retention reduction removes the recovery window the application team relies on. Acceptance criteria - Compare proposed retention with the scenario requirement. - Account for deletion of old backup generations. - Require an explanation for incompatible changes. Implementation constraints - Policy requirements are explicit inputs. Verification - Accept a compatible retention update. - Flag a shorter recovery window and missing policy. Deliverables - Retention plan rule. Rollout and recovery: Review changes alongside the restore rehearsal record. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. ### Bind execution intent Verify freshness, ownership, and recovery information. #### BIAC-106 — Detect plan drift between review and execution **Task · High priority · Advanced** noCV practice brief v5 · BIAC-106 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bind execution intent. Depends on: BIAC-104, BIAC-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Security 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. A plan is reviewed, then regenerated with additional deletions before execution. Acceptance criteria - Bind approval intent to plan digest and target identity. - Check state serial and configuration revision. - Reject modified or stale plans. Implementation constraints - No actual cloud apply is performed in this exercise. Verification - Accept an unchanged synthetic reviewed plan. - Change one action and reject the execution intent. Deliverables - Plan binding verifier. Rollout and recovery: Require regeneration and review on drift; preserve prior plan artifacts. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-107 — Keep infrastructure workspace identities from crossing environments **Bug · High priority · Intermediate** noCV practice brief v5 · BIAC-107 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bind execution intent. Depends on: BIAC-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 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. A staging plan is accidentally paired with production target metadata. Acceptance criteria - Bind workspace, account class, and resource namespace. - Reject mixed-environment inputs. - Show sanitized target context in the review summary. Implementation constraints - Use fictional account identities and no credentials. Verification - Verify a matching staging plan. - Reject a production identity substituted after review. Deliverables - Environment binding guard. Rollout and recovery: Fail closed on ambiguous identity. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-108 — Model partial apply recovery without assuming atomic infrastructure changes **Task · High priority · Expert** noCV practice brief v5 · BIAC-108 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bind execution intent. Depends on: BIAC-103, BIAC-106, BIAC-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 40% · System design 30% · 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. A plan contains several resource updates, and the third may fail after earlier changes succeed. Acceptance criteria - Identify dependency-ordered partial states. - Compare forward repair and rollback per resource. - Preserve completed changes in the recovery record. Implementation constraints - Do not present infrastructure apply as one database transaction. Verification - Simulate failure after two accepted changes. - Reject a rollback that would delete newly authoritative data. Deliverables - Partial-apply recovery decision record. Rollout and recovery: Keep execution hypothetical until target-specific recovery is verified. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-109 — Generate an infrastructure change summary for application owners **Story · Medium priority · Intermediate** noCV practice brief v5 · BIAC-109 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bind execution intent. Depends on: BIAC-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 70% · Developer tooling 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. Application owners cannot determine whether a plan changes endpoints or causes downtime. Acceptance criteria - Summarize connectivity, storage, and availability impacts. - Link impacts to exact resource actions. - List unresolved values and required follow-up. Implementation constraints - Do not hide unresolved risks behind an overall green status. Verification - Explain a cache replacement and endpoint change. - Show unknown replacement timing explicitly. Deliverables - Owner review report. Rollout and recovery: Attach reports to the exact plan digest. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. #### BIAC-110 — Document how to retire a policy exception **Chore · Low priority · Foundational** noCV practice brief v5 · BIAC-110 · Reviewable infrastructure plan pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bind execution intent. Depends on: BIAC-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Cloud infrastructure 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 temporary public-access exception remains active after the migration finishes. Acceptance criteria - Require owner, scope, reason, and expiry. - Reject expired or wildcard exceptions. - Preserve exception history after retirement. Implementation constraints - Exceptions cannot bypass plan identity checks. Verification - Retire a scoped synthetic exception. - Verify an expired exception blocks the next plan. Deliverables - Exception lifecycle guide. Rollout and recovery: Inventory exceptions before enabling enforcement. Project prerequisites: Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials. Engineer value: Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows. Company value: Give infrastructure reviewers concrete change scope and recovery consequences. 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. ## BIDENT — Workload identity credential rotation A fictional export worker shares a long-lived object-store credential across environments. The team needs a provider-neutral identity boundary with safe expiry and revocation. **Field:** Cloud infrastructure. **Suggested stack:** TypeScript, JWT, HTTP. **Engineer value:** Practice workload identity, audience restrictions, and credential lifecycle failures. **Company value:** Produce a migration path that narrows credential scope and makes revocation observable. **Delivery agreement:** Deliver local identity contracts and rotation rehearsals; deploy no live trust policy. ### Setup prerequisites - Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. ### Define trust scope Bind identities to workloads and resources. #### BIDENT-101 — Inventory the export worker's required storage operations **Task · Medium priority · Foundational** noCV practice brief v5 · BIDENT-101 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define trust scope. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Cloud infrastructure 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 worker credential permits listing and deleting unrelated storage objects. Acceptance criteria - List operations required for one export lifecycle. - Separate read, write, and cleanup authority. - Identify unnecessary permissions. Implementation constraints - Use synthetic object namespaces. Verification - Complete an export with the proposed operation list. - Deny an unrelated bucket-list request. Deliverables - Least-privilege operation matrix. Rollout and recovery: Review scope before issuing replacement credentials. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-102 — Bind workload assertions to issuer, audience, and environment **Task · High priority · Advanced** noCV practice brief v5 · BIDENT-102 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define trust scope. Depends on: BIDENT-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Cloud infrastructure 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 staging assertion is accepted by the production-class storage adapter. Acceptance criteria - Validate issuer and exact audience. - Bind workload and environment identity. - Reject unknown signing keys and algorithms. Implementation constraints - Use generated local test keys only. Verification - Accept a matching assertion. - Reject wrong audience, environment, and algorithm fixtures. Deliverables - Assertion verifier. Rollout and recovery: Fail closed on unresolved trust configuration. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. ### Issue bounded credentials Validate tokens, caching, and provider failures. #### BIDENT-103 — Issue short-lived storage grants with exact resource scope **Task · High priority · Advanced** noCV practice brief v5 · BIDENT-103 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Issue bounded credentials. Depends on: BIDENT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Cloud infrastructure 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 workload token grants access to every export instead of one operation. Acceptance criteria - Bind grant to resource and allowed operation. - Enforce expiry and unique grant identity. - Prevent the caller from widening scope. Implementation constraints - Grant fields derive from authorized server state. Verification - Write the intended synthetic export. - Reject a different resource or operation under the same grant. Deliverables - Scoped grant issuer. Rollout and recovery: Start with one export path; retain no broad fallback credential. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-104 — Refresh credentials before expiry without creating a refresh storm **Bug · High priority · Intermediate** noCV practice brief v5 · BIDENT-104 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Issue bounded credentials. Depends on: BIDENT-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Security 30% · Cloud infrastructure 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. Every concurrent request refreshes the same expiring credential. Acceptance criteria - Coalesce equivalent in-flight refreshes. - Refresh within a declared bounded window. - Avoid caching failed or mismatched grants. Implementation constraints - Cache keys include workload, resource scope, and audience. Verification - Share one refresh across concurrent requests. - Reject cross-scope cache reuse and retry a failed refresh safely. Deliverables - Credential cache. Rollout and recovery: Use short cache lifetimes; clear affected entries on validation failure. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-105 — Keep clock skew from extending grant lifetime indefinitely **Task · High priority · Intermediate** noCV practice brief v5 · BIDENT-105 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Issue bounded credentials. Depends on: BIDENT-102, BIDENT-104. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Cloud infrastructure 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 large token leeway makes expired credentials valid far longer than intended. Acceptance criteria - Bound allowed skew explicitly. - Reject impossible issue and expiry ordering. - Report clock-related failures without token contents. Implementation constraints - Use an injected clock for deterministic checks. Verification - Accept a token inside the declared skew window. - Reject expired and future-issued tokens beyond the bound. Deliverables - Expiry boundary tests. Rollout and recovery: Deploy with monitored clock assumptions; stop issuance if time authority is unavailable. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-106 — Prevent identity-provider outages from selecting static credentials **Bug · High priority · Advanced** noCV practice brief v5 · BIDENT-106 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Issue bounded credentials. Depends on: BIDENT-104, BIDENT-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 30% · Cloud infrastructure 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 adapter silently falls back to an old environment secret when token refresh fails. Acceptance criteria - Remove implicit static fallback. - Return a bounded unavailable state. - Allow only already-valid scoped grants until expiry. Implementation constraints - Never log credentials in failure diagnostics. Verification - Continue with a valid unexpired grant. - Fail closed after expiry during issuer outage. Deliverables - Provider failure behavior. Rollout and recovery: Disable issuance cleanly on outage; restore only after trust validation succeeds. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. ### Rehearse lifecycle changes Test rotation, revocation, and migration recovery. #### BIDENT-107 — Rotate signing keys with a bounded overlap window **Task · High priority · Advanced** noCV practice brief v5 · BIDENT-107 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse lifecycle changes. Depends on: BIDENT-105, BIDENT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Cloud infrastructure 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. Immediate key replacement breaks in-flight exports while indefinite overlap preserves old authority. Acceptance criteria - Publish new verification key before issuance switches. - Bound old-key acceptance by policy and token expiry. - Reject retired keys after the overlap. Implementation constraints - Private keys remain test-only runtime inputs. Verification - Complete an in-flight old-key export during overlap. - Reject an old-key token after retirement. Deliverables - Key rotation rehearsal. Rollout and recovery: Retain the previous public verifier only for the declared overlap. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-108 — Revoke one workload without disrupting unrelated exporters **Task · High priority · Advanced** noCV practice brief v5 · BIDENT-108 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse lifecycle changes. Depends on: BIDENT-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Cloud infrastructure 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 broad emergency revocation stops every export worker. Acceptance criteria - Scope revocation to workload identity and grant class. - Check revocation before accepting cached authority. - Preserve unrelated authorized workloads. Implementation constraints - Privileged revocations require append-only audit metadata. Verification - Revoke one synthetic worker. - Verify its cached grant fails while another worker succeeds. Deliverables - Scoped revocation behavior. Rollout and recovery: Test revocation before replacing the static credential path. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-109 — Design the static-to-workload identity cutover **Task · High priority · Expert** noCV practice brief v5 · BIDENT-109 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse lifecycle changes. Depends on: BIDENT-106, BIDENT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Security 40% · Cloud infrastructure 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 migrate without leaving a forgotten permanent credential active. Acceptance criteria - Inventory callers and staged cutover order. - Define proof that no caller requires the old credential. - Compare rollback availability against retained-secret risk. Implementation constraints - Do not restore broad credentials automatically on failure. Verification - Migrate two synthetic callers and revoke the old key. - Detect a forgotten caller before declaring the migration complete. Deliverables - Identity migration decision record. Rollout and recovery: Use a reviewed emergency path; retire the static key after verified caller migration. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. #### BIDENT-110 — Write credential-failure diagnostics without secret exposure **Chore · Low priority · Foundational** noCV practice brief v5 · BIDENT-110 · Workload identity credential rotation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse lifecycle changes. Depends on: BIDENT-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 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 expiry, audience mismatch, and issuer failure. Acceptance criteria - Define safe failure categories and request IDs. - Document scoped recovery actions. - Exclude tokens, private keys, and authorization headers. Implementation constraints - Use synthetic secret markers in verification. Verification - Diagnose an expired grant from safe metadata. - Verify no seeded secret appears in logs or reports. Deliverables - Identity support runbook. Rollout and recovery: Publish with the adapter and recheck after logging changes. Project prerequisites: Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret. Engineer value: Practice workload identity, audience restrictions, and credential lifecycle failures. Company value: Produce a migration path that narrows credential scope and makes revocation observable. 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. ## BARTIF — Artifact registry promotion controls A fictional application team deploys mutable image tags and cannot reliably identify the artifact running during an incident. **Field:** Cloud infrastructure. **Suggested stack:** TypeScript, OCI metadata, JSON. **Engineer value:** Practice artifact identity, promotion policies, and release provenance. **Company value:** Provide reproducible deployments and a clear path to withdraw defective artifacts. **Delivery agreement:** Deliver offline promotion checks and local registry-state rehearsals; perform no real deployment. ### Setup prerequisites - Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. ### Identify immutable artifacts Capture build identity and provenance. #### BARTIF-101 — Resolve deployment references to immutable artifact digests **Task · Medium priority · Foundational** noCV practice brief v5 · BARTIF-101 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify immutable artifacts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 40% · Security 40% · Cloud infrastructure 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 same release tag points to different bytes across environments. Acceptance criteria - Store the resolved digest with each deployment intent. - Preserve the human-readable tag as metadata. - Reject missing or ambiguous digest resolution. Implementation constraints - Synthetic registry manifests are sufficient. Verification - Resolve a stable release reference. - Move its tag and detect changed identity. Deliverables - Artifact identity model. Rollout and recovery: Introduce digest recording before enforcing immutable references. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-102 — Record build inputs without exposing build secrets **Task · High priority · Intermediate** noCV practice brief v5 · BARTIF-102 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify immutable artifacts. Depends on: BARTIF-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Provenance output includes all build environment variables. Acceptance criteria - Record source revision, builder version, and declared inputs. - Exclude secrets and workstation paths. - Bind provenance to the exact artifact digest. Implementation constraints - Use allowlisted metadata rather than environment dumps. Verification - Verify a complete synthetic provenance record. - Reject mismatched digest and detect seeded secret leakage. Deliverables - Provenance manifest. Rollout and recovery: Block promotion when required provenance is missing. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. ### Control promotion Validate artifact readiness and environment bindings. #### BARTIF-103 — Reject promotion of artifacts with unresolved policy findings **Task · High priority · Advanced** noCV practice brief v5 · BARTIF-103 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control promotion. Depends on: BARTIF-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Developer tooling 30% · Cloud infrastructure 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 failed scan is treated like a scan with no findings. Acceptance criteria - Distinguish passed, failed, missing, and stale checks. - Bind check results to artifact and policy versions. - Keep unresolved required checks blocking. Implementation constraints - Fixture scan results are not real vulnerability evidence. Verification - Promote a fixture with complete checks. - Reject unavailable or stale check results. Deliverables - Promotion policy evaluator. Rollout and recovery: Run advisory comparisons before enforcement. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-104 — Keep environment-specific settings outside immutable application bytes **Task · Medium priority · Advanced** noCV practice brief v5 · BARTIF-104 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control promotion. Depends on: BARTIF-101, BARTIF-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Cloud infrastructure 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. The team rebuilds the same release for staging and production, making tested bytes differ from deployed bytes. Acceptance criteria - Use one application digest across modeled environments. - Bind runtime configuration separately. - Validate required configuration without embedding secrets. Implementation constraints - No actual cloud deployment is required. Verification - Promote the same digest through two synthetic environments. - Reject a configuration missing a required setting. Deliverables - Artifact/configuration boundary. Rollout and recovery: Adopt on one service; retain previous configuration versions for recovery. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-105 — Bind a promotion decision to current environment state **Bug · High priority · Advanced** noCV practice brief v5 · BARTIF-105 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control promotion. Depends on: BARTIF-103, BARTIF-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 50% · Database engineering 30% · Cloud infrastructure 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. Two simultaneous promotion requests overwrite each other's intended release. Acceptance criteria - Require expected environment revision. - Record one accepted transition atomically. - Reject stale decisions without changing active identity. Implementation constraints - Use a local state store and explicit transition methods. Verification - Promote against the current revision. - Race two decisions and verify one conflict. Deliverables - Optimistic promotion workflow. Rollout and recovery: Start with serialized local promotion; preserve every prior revision. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-106 — Handle registry unavailability without changing artifact identity **Task · High priority · Intermediate** noCV practice brief v5 · BARTIF-106 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control promotion. Depends on: BARTIF-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 40% · Site reliability 40% · 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. A failed digest lookup falls back to the latest cached tag. Acceptance criteria - Use cached data only for the exact verified digest. - Return unavailable for unresolved references. - Bound fetch retries and response size. Implementation constraints - Do not substitute another release during failure. Verification - Reuse a verified digest manifest. - Fail tag resolution during outage without selecting latest. Deliverables - Registry failure handling. Rollout and recovery: Keep current release running in the scenario; retry promotion explicitly. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. ### Recover releases Handle withdrawal, retention, and rollback. #### BARTIF-107 — Withdraw a defective artifact without deleting incident history **Task · High priority · Advanced** noCV practice brief v5 · BARTIF-107 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover releases. Depends on: BARTIF-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · Security 40% · Cloud infrastructure 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. Deleting a bad image makes historical deployment records impossible to inspect. Acceptance criteria - Mark the digest withdrawn with reason and actor. - Block new promotion of withdrawn artifacts. - Preserve manifests and prior deployment references. Implementation constraints - Withdrawal is append-only state, not evidence deletion. Verification - Withdraw a synthetic defective artifact. - Reject new promotion while retaining historical reads. Deliverables - Artifact withdrawal workflow. Rollout and recovery: Withdraw before cleanup; use a separate approved retention policy. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-108 — Protect rollback artifacts from registry retention cleanup **Bug · High priority · Intermediate** noCV practice brief v5 · BARTIF-108 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover releases. Depends on: BARTIF-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · Site reliability 30% · Cloud infrastructure 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 cleanup job deletes the last known usable release. Acceptance criteria - Retain artifacts referenced by active and rollback revisions. - Evaluate cleanup from current authoritative references. - Produce a dry-run deletion set. Implementation constraints - Use only local synthetic artifacts. Verification - Identify unreferenced eligible artifacts. - Keep an older digest referenced by a rollback plan. Deliverables - Reference-aware retention policy. Rollout and recovery: Run dry-run review before local deletion. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-109 — Assess rollback compatibility beyond selecting an older digest **Task · High priority · Expert** noCV practice brief v5 · BARTIF-109 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover releases. Depends on: BARTIF-104, BARTIF-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Database engineering 30% · Platform 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 older image starts successfully but cannot read data written by the new release. Acceptance criteria - Bind rollback candidates to schema and configuration compatibility. - Rehearse representative read/write behavior locally. - Compare rollback with forward repair when compatibility fails. Implementation constraints - Artifact availability alone does not prove recoverability. Verification - Restore a compatible synthetic release. - Reject an incompatible candidate despite its valid digest. Deliverables - Rollback compatibility assessment. Rollout and recovery: Keep compatible artifacts and configuration together; choose forward repair when required. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. #### BARTIF-110 — Write an artifact incident lookup guide **Chore · Low priority · Foundational** noCV practice brief v5 · BARTIF-110 · Artifact registry promotion controls Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover releases. Depends on: BARTIF-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Developer tooling 30% · Cloud infrastructure 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. On-call staff need to identify source, checks, and prior release from one deployed digest. Acceptance criteria - Show lookup from environment revision to artifact. - Link provenance and policy results by identity. - Document withdrawn and missing-artifact behavior. Implementation constraints - Do not include registry credentials in examples. Verification - Trace one synthetic deployment to source inputs. - Handle a withdrawn artifact without losing history. Deliverables - Artifact investigation guide. Rollout and recovery: Store with promotion tooling and update when manifest schema changes. Project prerequisites: Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images. Engineer value: Practice artifact identity, promotion policies, and release provenance. Company value: Provide reproducible deployments and a clear path to withdraw defective artifacts. 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. ## BENV — Ephemeral review-environment lifecycle A fictional product team creates preview environments for pull requests. Forgotten environments accumulate cost, and shared test data leaks between reviews. **Field:** Cloud infrastructure. **Suggested stack:** TypeScript, PostgreSQL, Infrastructure plan fixtures. **Engineer value:** Practice resource lifecycle state machines, isolation, and reconciliation. **Company value:** Make review environments predictable, isolated, and accountable to a budget. **Delivery agreement:** Deliver a local lifecycle controller and cleanup rehearsal using simulated resource records. ### Setup prerequisites - Author a local environment-provider double and synthetic pull-request events; provision no external resources. ### Model environment ownership Define identity, scope, and resource limits. #### BENV-101 — Define review-environment identity independently of branch names **Task · Medium priority · Foundational** noCV practice brief v5 · BENV-101 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model environment ownership. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 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. Renamed branches orphan their original preview resources. Acceptance criteria - Use stable repository and change identities. - Keep branch names as mutable labels. - Record owner and expiry explicitly. Implementation constraints - Use fictional repositories and no real webhook subscription. Verification - Rename a synthetic branch without creating another environment. - Reject conflicting repository identity reuse. Deliverables - Environment identity model. Rollout and recovery: Adopt identity recording before resource creation. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-102 — Set per-environment and per-team resource ceilings **Task · High priority · Intermediate** noCV practice brief v5 · BENV-102 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model environment ownership. Depends on: BENV-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 70% · Platform 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. One team opens enough previews to exhaust the shared database quota. Acceptance criteria - Declare resource units and budget limits. - Reserve capacity before creation. - Reject requests exceeding either ceiling. Implementation constraints - Provider resources are simulated records. Verification - Reserve an allowed preview. - Race requests at the limit and prevent over-allocation. Deliverables - Quota reservation logic. Rollout and recovery: Start with low fixture quotas; release reservations only through terminal lifecycle actions. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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 lifecycle Create, update, expire, and reconcile environments. #### BENV-103 — Create environments through idempotent provider operations **Task · High priority · Advanced** noCV practice brief v5 · BENV-103 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage lifecycle. Depends on: BENV-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Distributed systems 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 create timeout produces two environments for the same review. Acceptance criteria - Persist a stable operation identity before dispatch. - Adopt matching provider resources after retry. - Reject conflicting provider ownership metadata. Implementation constraints - Use explicit provider interfaces and local doubles. Verification - Recover after an accepted create loses its response. - Detect an existing resource owned by another review. Deliverables - Idempotent provision coordinator. Rollout and recovery: Keep uncertain creates pending until reconciliation. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-104 — Seed synthetic review data in isolated namespaces **Task · High priority · Intermediate** noCV practice brief v5 · BENV-104 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage lifecycle. Depends on: BENV-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Cloud infrastructure 30% · Database 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. Two previews share account records and interfere with each other's review. Acceptance criteria - Assign a unique data namespace per environment. - Seed only synthetic records. - Deny reads across environment namespaces. Implementation constraints - Never copy production user data into previews. Verification - Run two previews with identical synthetic usernames. - Verify cross-environment reads and cleanup are denied. Deliverables - Isolated seed workflow. Rollout and recovery: Validate isolation before marking environments ready. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-105 — Bind preview URLs and callbacks to the environment origin **Bug · High priority · Advanced** noCV practice brief v5 · BENV-105 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage lifecycle. Depends on: BENV-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Cloud infrastructure 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 preview callback redirects to an unrelated origin supplied in change metadata. Acceptance criteria - Derive allowed origins from trusted environment state. - Reject arbitrary redirect and callback destinations. - Expire origin authority when the environment closes. Implementation constraints - Use local URLs and do not contact external hosts. Verification - Accept the environment's declared local callback. - Reject a substituted external origin and stale environment. Deliverables - Origin binding guard. Rollout and recovery: Expose preview links only after origin validation. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-106 — Expire environments using leases rather than event delivery alone **Task · High priority · Advanced** noCV practice brief v5 · BENV-106 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage lifecycle. Depends on: BENV-103, BENV-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Distributed systems 30% · Platform 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 missed close event leaves a preview running indefinitely. Acceptance criteria - Persist expiry and extension revisions. - Reclaim expired environments through a periodic scan. - Reject stale extensions after cleanup starts. Implementation constraints - Lifecycle state changes use explicit transitions. Verification - Expire an environment with no close event. - Race extension and cleanup without resurrecting deleted state. Deliverables - Lease-based expiry. Rollout and recovery: Start with dry-run expiry reports; enable cleanup after ownership checks. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-107 — Reconcile partially created environments after provider failure **Bug · High priority · Advanced** noCV practice brief v5 · BENV-107 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage lifecycle. Depends on: BENV-103, BENV-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Cloud infrastructure 50% · Distributed systems 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. The database resource exists but the web resource failed, leaving an unusable partial preview. Acceptance criteria - Record each provider resource identity. - Resume or compensate according to lifecycle policy. - Release quota only after owned resources are accounted for. Implementation constraints - Never delete resources without matching ownership metadata. Verification - Recover a partially created preview. - Encounter a foreign resource and stop compensation safely. Deliverables - Partial-creation reconciler. Rollout and recovery: Keep the environment unavailable until complete; retain reconciliation history. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. ### Operate within bounds Verify cleanup safety and cost controls. #### BENV-108 — Produce a cleanup plan that proves exact resource ownership **Task · High priority · Intermediate** noCV practice brief v5 · BENV-108 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate within bounds. Depends on: BENV-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Cloud infrastructure 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 broad name-prefix cleanup could delete another team's preview. Acceptance criteria - List exact resource IDs and ownership bindings. - Bind deletion intent to lifecycle revision. - Reject changed ownership or active lease. Implementation constraints - Cleanup applies only to the local provider double. Verification - Delete an expired owned environment. - Reject a foreign or newly extended resource. Deliverables - Reviewed cleanup plan. Rollout and recovery: Use dry-run output first; stop on any ownership mismatch. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-109 — Compare pooled and dedicated preview dependencies **Task · High priority · Expert** noCV practice brief v5 · BENV-109 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate within bounds. Depends on: BENV-104, BENV-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Cloud infrastructure 40% · 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. Dedicated databases simplify isolation but cost more than a shared instance with namespaces. Acceptance criteria - Compare isolation, startup time, cleanup, and quota assumptions. - Rehearse cross-environment denial for the pooled option. - Document failure domains and untested provider behavior. Implementation constraints - No speculative infrastructure is required beyond the local model. Verification - Evaluate both options against the same synthetic review workload. - Reject a cheaper option that fails isolation requirements. Deliverables - Preview architecture decision record. Rollout and recovery: Choose the smallest option satisfying isolation; keep migration and cleanup steps explicit. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. #### BENV-110 — Write a stale-preview support checklist **Chore · Low priority · Foundational** noCV practice brief v5 · BENV-110 · Ephemeral review-environment lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate within bounds. Depends on: BENV-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Cloud infrastructure 30% · 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. Reviewers need to know whether a broken preview is creating, expired, or awaiting cleanup. Acceptance criteria - Expose lifecycle state and last safe failure category. - Show owner, expiry, and review identity. - Document scoped retry and extension behavior. Implementation constraints - Status contains no credentials or seed data. Verification - Diagnose an expired synthetic preview. - Reject extension after irreversible cleanup begins. Deliverables - Preview support guide. Rollout and recovery: Ship with lifecycle controls and update after state changes. Project prerequisites: Author a local environment-provider double and synthetic pull-request events; provision no external resources. Engineer value: Practice resource lifecycle state machines, isolation, and reconciliation. Company value: Make review environments predictable, isolated, and accountable to a budget. 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. ## BDNS — Service DNS migration lab A fictional internal API is moving to a new endpoint. The team assumes DNS changes are immediate and has no rehearsal for stale clients. **Field:** Networking. **Suggested stack:** TypeScript, DNS fixtures, HTTP. **Engineer value:** Practice DNS semantics, migration timing, and network diagnosis. **Company value:** Produce a migration plan that makes cache delay and endpoint compatibility explicit. **Delivery agreement:** Deliver local DNS simulations and a cutover report; modify no real DNS records. ### Setup prerequisites - Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. ### Model DNS responses Define record and cache semantics. #### BDNS-101 — Inventory service records and their consumers **Task · Medium priority · Foundational** noCV practice brief v5 · BDNS-101 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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. The team knows the main hostname but not aliases used by background jobs. Acceptance criteria - List record types, aliases, and modeled consumers. - Identify ownership and current TTL. - Mark unknown client caching behavior. Implementation constraints - Use reserved local test names only. Verification - Resolve the declared alias chain. - Report an unknown consumer cache policy explicitly. Deliverables - DNS dependency inventory. Rollout and recovery: Review inventory before scheduling a cutover. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-102 — Implement TTL-aware positive caching in the resolver fixture **Task · Medium priority · Intermediate** noCV practice brief v5 · BDNS-102 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: BDNS-101. Difficulty: Intermediate. Estimated focused work: 120 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 simulator caches every answer forever and cannot represent migration delays. Acceptance criteria - Expire answers using an injected clock. - Honor the declared TTL without extending it on reads. - Key cache entries by name and record type. Implementation constraints - Do not use wall-clock sleeps in tests. Verification - Serve a cached answer before expiry. - Advance time and retrieve the changed authoritative answer. Deliverables - Positive-cache simulator. Rollout and recovery: Validate the simulator against its documented semantics before using results. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-103 — Model negative caching separately from empty address records **Task · High priority · Advanced** noCV practice brief v5 · BDNS-103 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model DNS responses. Depends on: BDNS-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 80% · 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 temporary missing hostname remains unavailable after its record is created. Acceptance criteria - Distinguish nonexistent name from no record of requested type. - Apply declared negative-cache lifetime. - Preserve the reason for cached negative answers. Implementation constraints - Use explicit fixture policy rather than claiming universal resolver behavior. Verification - Create a record after a negative lookup. - Show recovery only after the modeled negative cache expires. Deliverables - Negative-cache scenarios. Rollout and recovery: Avoid deleting names during cutover unless negative-cache effects are accepted. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. ### Rehearse endpoint changes Handle stale clients and lookup failures. #### BDNS-104 — Reject alias loops and excessively deep resolution chains **Bug · High priority · Intermediate** noCV practice brief v5 · BDNS-104 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 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. A mistaken alias points back to the original hostname and exhausts lookup work. Acceptance criteria - Track visited aliases. - Bound chain depth and response size. - Return a clear resolution failure without partial success. Implementation constraints - The resolver fixture remains local and read-only. Verification - Resolve a valid multi-hop chain. - Reject a loop and an over-depth chain. Deliverables - Alias validation. Rollout and recovery: Validate proposed record sets before applying the synthetic change. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-105 — Rehearse lowering TTL before endpoint cutover **Task · High priority · Advanced** noCV practice brief v5 · BDNS-105 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-102, BDNS-103. Difficulty: Advanced. Estimated focused work: 180 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. Lowering TTL at the same moment as the address change does not shorten existing cached lifetimes. Acceptance criteria - Model caches populated before and after TTL reduction. - Calculate the required wait under declared assumptions. - Track old and new endpoint usage during overlap. Implementation constraints - Do not promise that every real client respects TTL. Verification - Simulate an appropriately staged cutover. - Show a stale pre-change cache after an immediate cutover. Deliverables - TTL staging rehearsal. Rollout and recovery: Keep the old endpoint available through the documented overlap. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-106 — Preserve application compatibility across old and new addresses **Task · High priority · Advanced** noCV practice brief v5 · BDNS-106 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 40% · API design 40% · 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. DNS propagation sends different clients to different service versions. Acceptance criteria - Exercise the same public contract on both endpoints. - Preserve shared operation identity across retries. - Reject incompatible old/new behavior before cutover. Implementation constraints - Use synthetic requests and loopback endpoints. Verification - Complete retries across both endpoints. - Detect a response-contract mismatch during overlap. Deliverables - Endpoint overlap checks. Rollout and recovery: Deploy compatible service behavior before changing DNS. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-107 — Distinguish resolver failure from application connection failure **Story · Medium priority · Intermediate** noCV practice brief v5 · BDNS-107 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse endpoint changes. Depends on: BDNS-104, BDNS-106. Difficulty: Intermediate. Estimated focused work: 150 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. Operators see one generic network error for lookup failures and refused connections. Acceptance criteria - Classify lookup, address selection, connection, and HTTP failures. - Record bounded timing per stage. - Keep hostnames and request data within the declared safe diagnostic policy. Implementation constraints - No packet payloads or credentials in generic logs. Verification - Diagnose a local nonexistent name. - Resolve an address then distinguish refused connection. Deliverables - Network-stage diagnostics. Rollout and recovery: Add classification before changing retry behavior. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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 cutover Choose timing and recovery controls. #### BDNS-108 — Evaluate rollback when both old and new answers remain cached **Task · High priority · Expert** noCV practice brief v5 · BDNS-108 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-105, BDNS-106, BDNS-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 40% · Distributed systems 30% · 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. Reverting the DNS record does not immediately send every client back to the old endpoint. Acceptance criteria - Model multiple cache ages during rollback. - Define service compatibility and overlap requirements. - Compare DNS rollback with routing-level containment under declared constraints. Implementation constraints - Keep conclusions scoped to the simulated client population. Verification - Roll back with mixed cached answers. - Expose clients that continue using the new endpoint until expiry. Deliverables - DNS recovery decision record. Rollout and recovery: Retain both compatible endpoints until the modeled overlap and operational checks complete. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-109 — Check IPv4 and IPv6 record migration independently **Task · High priority · Advanced** noCV practice brief v5 · BDNS-109 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 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. Only the IPv4 record is updated while dual-stack clients continue using the old IPv6 endpoint. Acceptance criteria - Track A and AAAA records separately. - Rehearse differing cache ages by family. - Verify contract compatibility on both local address families. Implementation constraints - If IPv6 is unavailable locally, label that execution unverified and use deterministic fixtures. Verification - Simulate synchronized family updates. - Detect a stale AAAA record after A changes. Deliverables - Dual-stack DNS cutover checks. Rollout and recovery: Require family-specific review before final endpoint retirement. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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. #### BDNS-110 — Write a DNS change record with cache assumptions **Chore · Low priority · Foundational** noCV practice brief v5 · BDNS-110 · Service DNS migration lab Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review cutover. Depends on: BDNS-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. The handoff omits when TTL was lowered and when old endpoints can be removed. Acceptance criteria - Record old/new values and effective times. - List modeled cache and compatibility assumptions. - Define endpoint retirement criteria. Implementation constraints - Use UTC timestamps and synthetic record identities. Verification - Follow the staged change from the record. - Keep retirement blocked when a required client assumption is unknown. Deliverables - DNS cutover runbook. Rollout and recovery: Preserve the change record after rollback or completion. Project prerequisites: Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure. Engineer value: Practice DNS semantics, migration timing, and network diagnosis. Company value: Produce a migration plan that makes cache delay and endpoint compatibility explicit. 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 — 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. ## BMTLS — Mutual TLS certificate lifecycle A fictional internal report exporter uses mutual TLS. Certificates are renewed manually, and operators cannot distinguish peer identity failures from network outages. **Field:** Networking. **Suggested stack:** TypeScript, TLS, Local certificate fixtures. **Engineer value:** Practice transport identity, trust-store changes, and certificate failure diagnosis. **Company value:** Provide repeatable rotation and recovery behavior for authenticated service communication. **Delivery agreement:** Deliver local TLS checks and lifecycle rehearsals; modify no real trust stores. ### Setup prerequisites - Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. ### Define peer identity Specify certificate and name constraints. #### BMTLS-101 — Define expected service names and certificate usage **Task · Medium priority · Foundational** noCV practice brief v5 · BMTLS-101 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define peer identity. Depends on: No preceding ticket. 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 certificate signed by the internal CA is accepted for any service name. Acceptance criteria - List expected subject alternative names per peer. - Declare client and server usage requirements. - Separate trust-chain validity from service identity. Implementation constraints - Use reserved local names and test certificates. Verification - Match the intended service identity. - Reject a valid-chain certificate for another service. Deliverables - TLS identity contract. Rollout and recovery: Review identities before enabling peer authentication. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-102 — Validate certificate chains without disabling hostname checks **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-102 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define peer identity. Depends on: BMTLS-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 workaround accepts self-signed certificates by disabling all verification. Acceptance criteria - Trust only the configured test CA set. - Verify peer names and intended usage. - Reject expired, incomplete, and unknown chains. Implementation constraints - No permissive verification bypass is allowed. Verification - Connect with the authorized test chain. - Reject wrong-name and untrusted certificates. Deliverables - Strict TLS configuration. Rollout and recovery: Fail closed and expose safe diagnostic categories. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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 transport trust Validate peers and handle connection lifecycle. #### BMTLS-103 — Separate certificate expiry alerts from connection failure rates **Task · Medium priority · Intermediate** noCV practice brief v5 · BMTLS-103 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Security 20% · 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. Renewal is noticed only when connections begin failing. Acceptance criteria - Report remaining certificate lifetime. - Distinguish leaf and trust-anchor expiry. - Keep expiry observations separate from availability outcomes. Implementation constraints - Avoid private-key or full certificate dumps in generic logs. Verification - Observe a near-expiry leaf certificate. - Show an expired CA distinctly from an unreachable peer. Deliverables - Certificate health metrics. Rollout and recovery: Run read-only checks before wiring operational alerts. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-104 — Refresh connection pools after client-certificate rotation **Bug · High priority · Advanced** noCV practice brief v5 · BMTLS-104 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-102, BMTLS-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Security 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. Long-lived connections keep using the old client identity after new credentials are loaded. Acceptance criteria - Bind pools to certificate generation. - Stop assigning new requests to retired pools. - Drain existing connections within a declared deadline. Implementation constraints - Do not terminate healthy requests without the documented drain policy. Verification - Rotate while a request is active. - Verify new connections use the new certificate generation. Deliverables - Certificate-aware pool lifecycle. Rollout and recovery: Roll out with a bounded overlap; preserve prior public trust during drain. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-105 — Keep TLS errors from exposing peer secrets or request payloads **Task · High priority · Intermediate** noCV practice brief v5 · BMTLS-105 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 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. Handshake errors include large diagnostic objects containing sensitive material. Acceptance criteria - Map failures to bounded safe categories. - Include correlation and expected peer class. - Exclude private keys, tokens, and request bodies. Implementation constraints - Use seeded synthetic secret markers. Verification - Diagnose hostname and expiry failures. - Verify secret markers never appear in logs. Deliverables - Safe TLS error mapping. Rollout and recovery: Replace broad error serialization before expanding diagnostics. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. ### Rehearse certificate changes Test overlap, expiry, revocation, and recovery. #### BMTLS-106 — Rehearse leaf renewal under an unchanged trust anchor **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-106 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-104, BMTLS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Networking 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. Routine renewal should not require every client to restart simultaneously. Acceptance criteria - Issue a new leaf with the same declared identity. - Overlap old and new leaves within policy. - Verify old-leaf retirement after draining. Implementation constraints - Generated keys remain local temporary test assets. Verification - Renew without interrupting the declared local request flow. - Reject the expired prior leaf after overlap. Deliverables - Leaf renewal rehearsal. Rollout and recovery: Renew before expiry and retain a bounded rollback window. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-107 — Rotate trust anchors without accepting unrelated authorities **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-107 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-106. Difficulty: Advanced. Estimated focused work: 210 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. Adding a new CA to the trust store accidentally imports every certificate from a shared bundle. Acceptance criteria - Allowlist exact old and new test anchors. - Stage verifier trust before switching issuers. - Remove the old anchor after the declared overlap. Implementation constraints - Never trust an arbitrary system bundle for this private service boundary. Verification - Complete a staged CA rotation. - Reject a third unrelated CA throughout the overlap. Deliverables - Trust-anchor rotation procedure. Rollout and recovery: Keep overlap short and reviewed; fail closed on unexpected trust material. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-108 — Enforce peer revocation on reused connections **Bug · High priority · Advanced** noCV practice brief v5 · BMTLS-108 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-104, BMTLS-107. Difficulty: Advanced. Estimated focused work: 210 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. A revoked peer retains a long-lived authenticated connection. Acceptance criteria - Define revocation checks and maximum connection lifetime. - Stop new requests for revoked peer identity. - Close or drain existing connections according to the incident policy. Implementation constraints - Revocation policy must state its bounded enforcement delay. Verification - Revoke an idle authenticated peer. - Attempt reuse and verify denial within the declared bound. Deliverables - Revocation enforcement tests. Rollout and recovery: Rehearse revocation before relying on certificate identity for sensitive operations. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-109 — Compare certificate overlap availability against retained trust risk **Task · High priority · Expert** noCV practice brief v5 · BMTLS-109 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-107, BMTLS-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 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. A long overlap helps slow clients but extends acceptance of old credentials. Acceptance criteria - Model client refresh distribution and enforcement delay. - Compare bounded overlap options. - Document unknown client behavior and recovery implications. Implementation constraints - The local rehearsal cannot prove organization-wide certificate rollout coverage. Verification - Evaluate fast and delayed synthetic clients. - Reject an overlap proposal without an explicit old-trust retirement point. Deliverables - TLS lifecycle decision record. Rollout and recovery: Choose a measurable overlap and track lagging clients before retirement. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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. #### BMTLS-110 — Write a certificate-expiry incident handoff **Chore · Low priority · Foundational** noCV practice brief v5 · BMTLS-110 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Security 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. On-call staff need a safe response when one peer fails certificate validation. Acceptance criteria - Identify failing peer class and certificate generation. - Show approved renewal and trust-check steps. - Explain when to stop retries and escalate ownership. Implementation constraints - Never recommend disabling certificate verification. Verification - Resolve a synthetic expired leaf using the guide. - Keep an unknown-CA failure closed. Deliverables - TLS support runbook. Rollout and recovery: Store with the service identity inventory and rotation schedule. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. 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 — 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. ## 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. ## BAPIVER — Public API version transition A fictional inventory platform must replace a legacy availability response. Existing partners upgrade on different schedules, and the team needs a versioned transition. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, HTTP. **Engineer value:** Practice public-contract design, compatible evolution, and client lifecycle management. **Company value:** Provide a predictable migration that keeps supported integrations inspectable and recoverable. **Delivery agreement:** Deliver local versioned contracts, compatibility checks, and a deprecation packet. ### Setup prerequisites - Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. ### Design version semantics Identify changes and supported compatibility. #### BAPIVER-101 — Inventory breaking and additive availability-contract changes **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIVER-101 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Design version semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. The proposed response renames fields and changes unknown stock from null to zero. Acceptance criteria - Classify each request and response change. - Preserve unknown versus zero semantics. - Identify supported legacy behavior explicitly. Implementation constraints - Use actual local contract examples rather than general compatibility slogans. Verification - Classify an optional additive field. - Flag a meaning-changing null-to-zero conversion. Deliverables - Contract change inventory. Rollout and recovery: Review the inventory before choosing a versioning approach. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-102 — Define version selection and unsupported-version errors **Task · High priority · Intermediate** noCV practice brief v5 · BAPIVER-102 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Design version semantics. Depends on: BAPIVER-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. Clients cannot tell which contract a request will receive. Acceptance criteria - Choose one explicit version selection rule. - Document a deterministic default only if retained intentionally. - Return structured errors for unsupported versions. Implementation constraints - Keep routes under /api/v1 and /api/v2 in the scenario. Verification - Request each supported version. - Request an unknown version and inspect its documented problem response. Deliverables - Version selection contract. Rollout and recovery: Introduce explicit selection before changing existing defaults. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. ### Implement coexistence Serve explicit contracts and safe migration behavior. #### BAPIVER-103 — Keep legacy and new projections over one domain authority **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-103 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System design 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. Separate version handlers duplicate inventory rules and begin disagreeing. Acceptance criteria - Share domain availability calculation. - Map into distinct immutable transport schemas. - Preserve version-specific unknown-state semantics. Implementation constraints - Controllers cannot bypass tenant-scoped service reads. Verification - Project one domain result into both versions. - Deny cross-tenant reads through either route. Deliverables - Versioned projection boundary. Rollout and recovery: Ship the new projection alongside the old; retain identical domain invariants. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-104 — Use Problem Details for versioned validation failures **Task · High priority · Intermediate** noCV practice brief v5 · BAPIVER-104 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · 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. Partners parse changing human messages to detect invalid warehouse filters. Acceptance criteria - Publish stable problem types and field paths. - Keep instance and request identifiers safe. - Version any materially changed error semantics. Implementation constraints - Exclude stack traces and internal database details. Verification - Validate a malformed filter in both versions. - Verify cross-tenant denial reveals no private identifiers. Deliverables - Error contract examples. Rollout and recovery: Add structured fields compatibly and document client handling. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-105 — Preserve idempotency semantics across client version upgrades **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-105 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-103, BAPIVER-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Distributed systems 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. A client retries an inventory reservation with the same key after upgrading its API version. Acceptance criteria - Define whether keys bind to normalized domain intent or transport version. - Reject conflicting reuse consistently. - Prevent duplicate domain effects across supported routes. Implementation constraints - Document the chosen scope rather than silently translating incompatible requests. Verification - Replay equivalent supported requests under the chosen policy. - Reject a changed reservation under the same key. Deliverables - Cross-version idempotency contract. Rollout and recovery: Retain original operation facts during migration. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-106 — Generate SDK migration examples from packaged client versions **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIVER-106 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-104, BAPIVER-105. 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. Migration documentation uses methods not present in the released client archive. Acceptance criteria - Compile old and new examples against local packaged clients. - Show equivalent availability and error handling. - Document changed optional and nullable fields. Implementation constraints - Use local archives and mock servers only. Verification - Run both documented examples. - Detect a snippet importing a removed method. Deliverables - Executable SDK migration examples. Rollout and recovery: Publish examples with the matching contract revision. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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 deprecation Verify client migration and retirement conditions. #### BAPIVER-107 — Expose deprecation signals without breaking successful responses **Story · Medium priority · Intermediate** noCV practice brief v5 · BAPIVER-107 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. Partners need machine-readable notice that the old version has a planned sunset. Acceptance criteria - Document deprecation metadata and dates. - Keep response behavior compatible during support. - Link a versioned migration guide. Implementation constraints - Dates are fictional scenario inputs and must be labeled in fixtures. Verification - Read a legacy response with deprecation metadata. - Verify the new version does not carry an incorrect retirement notice. Deliverables - Deprecation response contract. Rollout and recovery: Enable notice before any retirement gate. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-108 — Measure version adoption using bounded non-sensitive metadata **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-108 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-107. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Privacy engineering 30% · 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 team wants to know whether supported clients still use the old version without collecting request bodies. Acceptance criteria - Count requests by declared client class and API version. - Track unknown client versions separately. - Exclude tokens, payloads, and personal identifiers. Implementation constraints - Do not equate no observed traffic with confirmed migration. Verification - Report synthetic mixed-version traffic. - Show an inactive client as unknown rather than migrated. Deliverables - Adoption report. Rollout and recovery: Use counts as one input to retirement review; preserve explicit client support records. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-109 — Decide retirement with client obligations and rollback constraints **Task · High priority · Expert** noCV practice brief v5 · BAPIVER-109 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-105, BAPIVER-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · System design 20% · 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. The old API has little traffic but one supported partner still relies on its unknown-stock behavior. Acceptance criteria - Define retirement criteria beyond traffic volume. - Compare support cost, partner migration risk, and data compatibility. - Rehearse restoring legacy routing after a failed retirement. Implementation constraints - Keep unsupported assumptions visible; no actual partner notifications are sent. Verification - Retire a fully migrated synthetic client set. - Block retirement when a supported dependency remains unresolved. Deliverables - API retirement decision record. Rollout and recovery: Use a staged local retirement and retain tested legacy artifacts through the rollback window. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-110 — Write the partner migration checklist with observable completion **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIVER-110 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 70% · Developer tooling 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 checklist saying 'upgrade the SDK' misses changed error and unknown-state handling. Acceptance criteria - List client-code, error, and data-semantic changes. - Include local verification commands. - Define completion through exercised operations. Implementation constraints - Do not claim a partner migrated without recorded confirmation. Verification - Migrate the synthetic client using the checklist. - Catch a client still treating unknown stock as zero. Deliverables - Partner migration guide. Rollout and recovery: Version the guide and retain legacy instructions for supported clients. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. ## BAPIBULK — Asynchronous bulk API contract A fictional catalog API needs to accept imports too large for one synchronous request. Partners need to distinguish accepted work, completed items, and recoverable failures. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL. **Engineer value:** Practice asynchronous resource contracts, partial outcomes, and idempotent operations. **Company value:** Provide predictable bulk integration behavior without ambiguous success or repeated effects. **Delivery agreement:** Deliver local bulk endpoints, operation transitions, and public client examples. ### Setup prerequisites - Create a local API and worker double with synthetic catalog records and controlled interruption points. ### Define operation resources Specify admission, identities, and lifecycle semantics. #### BAPIBULK-101 — Define the difference between accepted and completed bulk work **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIBULK-101 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · 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. The current endpoint returns success before any imported row has been validated. Acceptance criteria - Publish accepted, running, completed, and failed meanings. - Define terminal partial-success representation. - Keep transport acceptance separate from item validity. Implementation constraints - Use explicit operation transition methods. Verification - Represent an accepted unprocessed import. - Show completed-with-errors without claiming every item succeeded. Deliverables - Bulk operation schema. Rollout and recovery: Review lifecycle vocabulary before adding endpoints. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-102 — Bound bulk request size and record counts before admission **Task · High priority · Intermediate** noCV practice brief v5 · BAPIBULK-102 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: BAPIBULK-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 30% · 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. A single import can exhaust parser memory before validation runs. Acceptance criteria - Enforce byte and item-count ceilings. - Validate envelope schema before queueing work. - Return structured errors without echoing the payload. Implementation constraints - Use streamed or bounded parsing appropriate to the fixture. Verification - Accept an import at the declared limit. - Reject oversized and malformed requests before creating work. Deliverables - Admission validator. Rollout and recovery: Start with conservative limits and explicit client guidance. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-103 — Create bulk operations with tenant-scoped idempotency **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-103 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: BAPIBULK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Database engineering 30% · 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. A timeout after admission causes the partner to submit the same catalog import again. Acceptance criteria - Bind key to tenant and canonical request digest. - Return the existing operation on exact replay. - Reject changed input under the same key. Implementation constraints - Commit operation and dispatch intent atomically. Verification - Replay a lost admission response. - Race conflicting requests and preserve one operation identity. Deliverables - Bulk admission command. Rollout and recovery: Keep operation identity stable through retries. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. ### Process bounded work Handle item outcomes, cancellation, and recovery. #### BAPIBULK-104 — Return per-item problems without exposing other tenant records **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-104 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 item conflict response includes details about a catalog record owned by another tenant. Acceptance criteria - Authorize each item at the service boundary. - Use stable item references and safe problem types. - Avoid disclosing foreign record existence. Implementation constraints - Item IDs supplied by clients are untrusted labels. Verification - Import authorized updates and invalid items together. - Attempt a cross-tenant item and verify safe denial. Deliverables - Per-item outcome contract. Rollout and recovery: Block imports with tenant-boundary regressions before expanding item types. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-105 — Checkpoint item progress without changing retry outcomes **Bug · High priority · Advanced** noCV practice brief v5 · BAPIBULK-105 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Database engineering 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. A worker restart reapplies successful items and duplicates side effects. Acceptance criteria - Persist committed item outcomes with operation identity. - Resume only incomplete items. - Return the original result for exact processed-item replay. Implementation constraints - Bound item batches and transaction duration. Verification - Interrupt after a committed batch and resume. - Retry a successful item and verify unchanged effects. Deliverables - Resumable bulk processor. Rollout and recovery: Retain checkpoints and immutable terminal item outcomes. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-106 — Define cancellation after some items have committed **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-106 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Distributed systems 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. Clients assume cancelling an import undoes all previous item updates. Acceptance criteria - Document cancellation as stopping future work unless compensation exists. - Preserve committed outcomes. - Resolve cancellation-versus-completion races explicitly. Implementation constraints - Do not silently roll back unrelated later changes. Verification - Cancel after two items commit. - Race cancellation with final completion and produce one terminal state. Deliverables - Cancellation contract. Rollout and recovery: Expose committed counts before accepting cancellation. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-107 — Paginate bulk item outcomes with stable ordering **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIBULK-107 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-104, BAPIBULK-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Database engineering 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. Large result lists exceed response limits and change order while the client reads them. Acceptance criteria - Use stable operation-scoped ordering. - Bound page sizes and cursor lifetime. - Bind cursors to tenant, operation, and filter. Implementation constraints - Do not place raw item payloads in cursors. Verification - Read all outcomes without duplicates. - Reject a cursor reused for another operation or tenant. Deliverables - Outcome pagination endpoint. Rollout and recovery: Keep terminal result pages immutable within retention. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. ### Support clients Expose safe progress and lifecycle guidance. #### BAPIBULK-108 — Expose progress that does not imply unobserved completion **Story · Medium priority · Intermediate** noCV practice brief v5 · BAPIBULK-108 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-106, BAPIBULK-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 70% · Data 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 UI computes ninety-nine percent from queued jobs even when several items are unresolved. Acceptance criteria - Report accepted, committed, failed, and pending counts. - Reconcile totals under declared semantics. - Show unknown progress when observations are incomplete. Implementation constraints - Avoid a fabricated precise completion estimate. Verification - Display partial progress from known outcomes. - Detect inconsistent counters and return an unavailable projection. Deliverables - Safe progress projection. Rollout and recovery: Use authoritative counters and stop polling on terminal states. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-109 — Choose atomic or partial bulk semantics for dependent items **Task · High priority · Expert** noCV practice brief v5 · BAPIBULK-109 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-104, BAPIBULK-106, BAPIBULK-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · API design 40% · Database 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. Some imports contain parent and child catalog records, making arbitrary independent item processing unsafe. Acceptance criteria - Define the supported dependency boundary. - Compare whole-request atomicity, ordered groups, and independent items. - Document transaction, recovery, and client complexity tradeoffs. Implementation constraints - Bound the decision to the synthetic catalog use case. Verification - Import a valid parent-child group. - Reject or explicitly report a missing-parent group under the chosen semantics. Deliverables - Bulk semantics decision record. Rollout and recovery: Start with the smallest supported grouping and reject unsupported dependency patterns. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-110 — Publish a bulk client example covering timeout and partial failure **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIBULK-110 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · API design 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. Partners have only a happy-path example that treats HTTP acceptance as completion. Acceptance criteria - Show admission retry with one idempotency key. - Poll to a terminal operation state. - Inspect item errors and retained committed results. Implementation constraints - Use local mock data and no credentials. Verification - Run a successful example. - Run timeout, partial failure, and cancellation examples without duplicate submissions. Deliverables - Executable bulk client guide. Rollout and recovery: Version the example with the operation contract. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. ## BAPIPAGE — Consistent query and pagination API A fictional logistics platform lists shipments for partner dashboards. Offset pagination duplicates records during updates, while unrestricted filters create expensive database queries. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL. **Engineer value:** Practice cursor design, query contracts, and consistency/performance tradeoffs. **Company value:** Provide predictable list APIs that remain bounded and preserve tenant scope. **Delivery agreement:** Deliver a local versioned listing endpoint and documented client iteration behavior. ### Setup prerequisites - Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. ### Define query semantics Specify supported filters, sorting, and authorization. #### BAPIPAGE-101 — Define supported shipment filters and their exact semantics **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIPAGE-101 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define query semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. Different clients interpret date ranges and empty status lists differently. Acceptance criteria - Specify inclusive and exclusive boundaries. - Distinguish absent from empty filters. - Reject unsupported filter properties. Implementation constraints - Use UTC instants for timestamp filters. Verification - Exercise a boundary timestamp. - Reject an empty status list if the contract declares it invalid. Deliverables - Filter contract. Rollout and recovery: Publish explicit examples before replacing legacy behavior. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-102 — Validate bounded sort options instead of accepting SQL fragments **Task · High priority · Intermediate** noCV practice brief v5 · BAPIPAGE-102 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define query semantics. Depends on: BAPIPAGE-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Security 40% · 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. Clients can pass arbitrary sort expressions into query construction. Acceptance criteria - Allowlist sort fields and directions. - Use parameterized query construction. - Append a stable unique tie-breaker. Implementation constraints - Never concatenate untrusted SQL. Verification - Sort equal timestamps deterministically. - Reject an expression-shaped sort value. Deliverables - Safe sort parser. Rollout and recovery: Adopt on the new endpoint first; keep unknown sorts rejected. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-103 — Enforce tenant scope before applying user filters **Task · High priority · Advanced** noCV practice brief v5 · BAPIPAGE-103 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define query semantics. Depends on: BAPIPAGE-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Database 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 optional organization filter can replace the caller's tenant predicate. Acceptance criteria - Derive tenant from authenticated context. - Apply scope in repository queries. - Keep client filters unable to widen authority. Implementation constraints - Unauthorized records must not influence totals. Verification - List owned shipments with several filters. - Attempt foreign-tenant filtering and verify non-disclosure. Deliverables - Scoped query repository. Rollout and recovery: Gate all listing variants on cross-tenant denial checks. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. ### Implement stable traversal Bind cursors and handle concurrent data changes. #### BAPIPAGE-104 — Encode opaque cursors bound to the normalized query **Task · High priority · Advanced** noCV practice brief v5 · BAPIPAGE-104 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement stable traversal. Depends on: BAPIPAGE-101, BAPIPAGE-102, BAPIPAGE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Security 30% · Database 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 cursor from one status filter is reused with another and skips records. Acceptance criteria - Bind cursor to tenant, sort, filter digest, and position. - Validate schema, size, integrity, and expiry. - Return a stable invalid-cursor problem. Implementation constraints - Opaque encoding alone is not integrity protection. Verification - Continue a matching query. - Reject tampered, expired, and cross-query cursors. Deliverables - Cursor contract. Rollout and recovery: Version cursors and retain support only for declared compatible versions. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-105 — Use keyset traversal for shipments sharing timestamps **Bug · High priority · Advanced** noCV practice brief v5 · BAPIPAGE-105 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement stable traversal. Depends on: BAPIPAGE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database 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. Pagination drops shipments when several rows have the same update timestamp. Acceptance criteria - Compare the complete sort tuple. - Use the unique tie-breaker consistently in both directions. - Avoid duplicate boundary rows. Implementation constraints - Indexes must match the declared ordering. Verification - Traverse a fixture with many equal timestamps. - Verify no omission or duplication at page boundaries. Deliverables - Keyset query implementation. Rollout and recovery: Compare full traversal against a fixed fixture before replacing offsets. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-106 — Define how mutable shipment updates affect an active traversal **Task · High priority · Expert** noCV practice brief v5 · BAPIPAGE-106 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement stable traversal. Depends on: BAPIPAGE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · API design 40% · Database 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 shipment changes status between pages, and partners expect a snapshot the endpoint never promised. Acceptance criteria - Compare live traversal, snapshot boundary, and export-resource options. - Choose explicit consistency semantics for this endpoint. - Document duplicate or omission risks that remain. Implementation constraints - Do not claim snapshot consistency without implementing its data boundary. Verification - Update a shipment between pages under the chosen model. - Verify observed behavior matches the documented guarantee. Deliverables - Pagination consistency decision record. Rollout and recovery: Introduce the consistency contract before clients depend on stable exports. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-107 — Bound total-count work independently of result pagination **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIPAGE-107 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement stable traversal. Depends on: BAPIPAGE-103, BAPIPAGE-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Database engineering 30% · 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. A fast first page still waits for an expensive exact count. Acceptance criteria - Make count behavior explicit and optional if appropriate. - Bound count execution time. - Distinguish unavailable or estimated totals from exact totals. Implementation constraints - Never label an estimate as an exact count. Verification - Return a page without optional count work. - Timeout count calculation without misreporting zero results. Deliverables - Count contract. Rollout and recovery: Default to the least expensive contract satisfying the use case. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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 contract limits Measure query plans and document consistency. #### BAPIPAGE-108 — Review query plans for supported high-cardinality filters **Task · High priority · Advanced** noCV practice brief v5 · BAPIPAGE-108 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review contract limits. Depends on: BAPIPAGE-105, BAPIPAGE-107. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. A permitted filter scans every shipment despite bounded page size. Acceptance criteria - Capture plans against a declared synthetic dataset. - Check indexes for supported filter/sort combinations. - Report dataset size, cache state, and machine limits. Implementation constraints - Local query plans are evidence for the fixture, not production latency guarantees. Verification - Measure a selective and broad query. - Identify a missing-index case and compare the corrected plan. Deliverables - Query-plan review. Rollout and recovery: Add indexes through migrations; retain a rollback plan for index changes. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-109 — Provide a resumable iterator that stops on cursor expiry **Story · Medium priority · Intermediate** noCV practice brief v5 · BAPIPAGE-109 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review contract limits. Depends on: BAPIPAGE-104, BAPIPAGE-106, BAPIPAGE-108. 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. The client SDK retries invalid cursors forever instead of telling callers to restart. Acceptance criteria - Expose bounded async iteration with cancellation. - Stop on terminal and invalid-cursor responses. - Document restart behavior under the consistency contract. Implementation constraints - Do not silently restart and merge potentially duplicated records. Verification - Iterate a complete synthetic result set. - Expire a cursor mid-run and surface the documented error. Deliverables - Client iterator example. Rollout and recovery: Release with explicit cursor-lifecycle documentation. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. #### BAPIPAGE-110 — Document list versus export guarantees for partner dashboards **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIPAGE-110 · Consistent query and pagination API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review contract limits. Depends on: BAPIPAGE-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. Partners use an interactive list endpoint as if it were a financial or audit export. Acceptance criteria - State ordering, freshness, and traversal guarantees. - List unsupported snapshot assumptions. - Show the appropriate restart and bounded export approach. Implementation constraints - No legal or financial completeness claims. Verification - Follow the guide for a changing dashboard list. - Identify a use case requiring a separate snapshot export. Deliverables - Query API usage guide. Rollout and recovery: Keep examples aligned with implemented consistency behavior. Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures. Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs. Company value: Provide predictable list APIs that remain bounded and preserve tenant scope. 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. ## BAPIAUTH — Delegated partner API access A fictional operations platform lets customers connect automation clients. Broad API keys and inconsistent tenant checks make delegated access difficult to review. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL. **Engineer value:** Practice delegated authorization, resource scoping, and secure public API ergonomics. **Company value:** Provide usable partner access that remains least-privilege and revocable. **Delivery agreement:** Deliver local credential and access contracts; connect no real partner account. ### Setup prerequisites - Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. ### Define delegated authority Separate actor, organization, client, and permission scope. #### BAPIAUTH-101 — Define partner scopes from concrete API operations **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIAUTH-101 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define delegated authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A single automation scope permits every operation in the organization. Acceptance criteria - Map scopes to specific operation classes. - Separate read, write, and administrative authority. - Document unsupported scope combinations. Implementation constraints - Do not derive permissions from client-provided role names. Verification - Authorize a read-only synthetic client. - Deny a write under the read-only scope. Deliverables - Partner scope matrix. Rollout and recovery: Review least-privilege defaults before issuing credentials. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-102 — Bind delegated credentials to organization and client identity **Task · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-102 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define delegated authority. Depends on: BAPIAUTH-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A valid credential can be paired with another organization ID in the URL. Acceptance criteria - Store organization and client authority server-side. - Require exact binding on each service call. - Reject caller attempts to substitute actor identity. Implementation constraints - Opaque credentials are never interpreted as authorization claims without lookup or verification. Verification - Call an owned resource. - Reuse the credential against another organization and deny safely. Deliverables - Credential authority model. Rollout and recovery: Fail closed on missing client or membership authority. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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 access Validate resource authority and token lifecycle. #### BAPIAUTH-103 — Return non-enumerating errors for unauthorized partner resources **Task · High priority · Intermediate** noCV practice brief v5 · BAPIAUTH-103 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 40% · Privacy 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. Partners can distinguish nonexistent records from records belonging to another organization. Acceptance criteria - Define stable safe denial semantics. - Keep error bodies free of foreign identifiers. - Preserve internal diagnostic categories separately. Implementation constraints - Use Problem Details-style public errors. Verification - Read an authorized record. - Compare missing and foreign-record public responses. Deliverables - Partner error contract. Rollout and recovery: Use the same safe projection across all resource endpoints. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-104 — Enforce authorization in nested and batch partner operations **Bug · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-104 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102, BAPIAUTH-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. The parent resource is authorized, but nested record IDs bypass tenant checks. Acceptance criteria - Reauthorize every nested resource at the service boundary. - Define atomic or per-item denial behavior. - Prevent unauthorized items from influencing result totals. Implementation constraints - Client-supplied parent-child relationships are untrusted. Verification - Process a valid nested update. - Insert a foreign child ID and verify the declared denial behavior. Deliverables - Nested authorization regression. Rollout and recovery: Gate batch rollout on cross-tenant and relationship checks. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-105 — Rotate partner credentials without indefinite dual-key access **Task · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-105 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102, BAPIAUTH-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Customers need rotation overlap, but old keys remain valid forever. Acceptance criteria - Issue a distinct new credential generation. - Set an explicit overlap expiry for the old generation. - Show generation status without exposing credential values. Implementation constraints - Reveal a generated test credential only through the intended creation response. Verification - Use both generations during overlap. - Reject the old generation after expiry. Deliverables - Credential rotation workflow. Rollout and recovery: Keep overlap bounded and auditable; never restore retired credentials silently. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-106 — Revoke partner access across cached authorization decisions **Bug · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-106 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · 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. Revoked clients retain access until a long cache TTL expires. Acceptance criteria - Bind caches to current authorization revision. - Recheck or invalidate revoked authority within the declared bound. - Deny new operations after revocation. Implementation constraints - Cached membership is not permanent authority. Verification - Serve a current authorized cache entry. - Revoke the client and verify cached access stops within policy. Deliverables - Revocation-aware authorization cache. Rollout and recovery: Prioritize denial when revision freshness is unavailable. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. ### Support client operations Handle rotation, auditing, and migration. #### BAPIAUTH-107 — Rate-limit by delegated client without losing tenant-wide protection **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIAUTH-107 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-104, BAPIAUTH-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Site reliability 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. Creating many client keys bypasses a per-key request limit. Acceptance criteria - Apply both client and organization budgets. - Return documented retry guidance. - Keep denied requests from consuming unrelated client authority. Implementation constraints - Use deterministic local counters and no customer profiling. Verification - Exercise separate clients within the organization ceiling. - Create multiple clients and verify the shared cap holds. Deliverables - Delegated rate-limit contract. Rollout and recovery: Start with published conservative limits and inspect false rejection cases. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-108 — Expose an audit trail of privileged partner-client changes **Story · High priority · Intermediate** noCV practice brief v5 · BAPIAUTH-108 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-105, BAPIAUTH-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Privacy engineering 20% · 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. Organization owners cannot see who expanded a client scope. Acceptance criteria - Append actor, client, changed scope, and UTC time. - Exclude tokens and request payloads. - Scope audit reads to current authorized organization members. Implementation constraints - Do not overwrite previous audit facts. Verification - Inspect a credential rotation and scope change. - Deny a cross-organization audit read. Deliverables - Partner access audit projection. Rollout and recovery: Enable audit recording before scope mutation endpoints. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-109 — Design migration from broad keys to scoped delegated clients **Task · High priority · Expert** noCV practice brief v5 · BAPIAUTH-109 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-107, BAPIAUTH-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System design 30% · 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. Existing integrations depend on broad keys and cannot all migrate at once. Acceptance criteria - Inventory actual required operations through safe synthetic usage records. - Define staged scope reduction and client cutover. - Compare compatibility burden with the risk of retained broad authority. Implementation constraints - No real partner usage is inferred from absence of traffic. Verification - Migrate two synthetic clients with different needs. - Keep an unknown integration unresolved instead of silently revoking or broadening it. Deliverables - Delegated-access migration plan. Rollout and recovery: Use explicit reviewed deadlines and retain a bounded recovery process. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-110 — Write a partner credential handling example for rotation and denial **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIAUTH-110 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 40% · Security 40% · 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. Documentation encourages hardcoding keys and retrying every unauthorized response. Acceptance criteria - Read credentials from the intended runtime boundary. - Handle expiry and revocation without infinite retries. - Show safe rotation using local test credentials. Implementation constraints - Examples must not log authorization headers. Verification - Run the example through a valid rotation. - Revoke access and verify a terminal actionable error. Deliverables - Executable partner access guide. Rollout and recovery: Version examples with the credential contract and remove obsolete broad-key guidance. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. ## BAPIHOOK — Public webhook delivery contract A fictional logistics platform sends shipment events to partner endpoints. Partners need stable schemas and recovery semantics despite duplicate delivery, failures, and subscription changes. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, HTTP, PostgreSQL. **Engineer value:** Practice public event contracts, delivery guarantees, and partner recovery workflows. **Company value:** Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. **Delivery agreement:** Deliver local subscription and delivery contracts; send no external webhook traffic. ### Setup prerequisites - Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. ### Define public events Specify immutable identities, schemas, and subscription authority. #### BAPIHOOK-101 — Define immutable webhook envelopes independently of database rows **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIHOOK-101 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · Data 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. Event payloads mirror internal shipment rows and change whenever the schema changes. Acceptance criteria - Publish event ID, type, version, and occurrence time. - Use a deliberate public payload projection. - Preserve emitted event bytes or canonical content identity. Implementation constraints - Exclude internal fields and hidden operational metadata. Verification - Create a documented shipment event. - Change an internal-only field without altering the public contract. Deliverables - Webhook envelope schema. Rollout and recovery: Version public payloads before accepting subscriptions. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-102 — Authorize subscription creation and event scope per organization **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-102 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: BAPIHOOK-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A caller can subscribe its endpoint to another organization's shipment events. Acceptance criteria - Derive organization scope from authenticated authority. - Validate permitted event types. - Recheck subscription authority before delivery. Implementation constraints - Endpoint ownership does not grant access to event data. Verification - Create a scoped synthetic subscription. - Reject foreign-organization event scope and unauthorized event types. Deliverables - Subscription authorization boundary. Rollout and recovery: Enable subscriptions only after cross-tenant denial checks pass. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-103 — Validate webhook destinations through the restricted network boundary **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-103 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define public events. Depends on: BAPIHOOK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. An arbitrary callback URL could direct the sender toward unapproved network resources. Acceptance criteria - Enforce approved schemes, origins, and ports. - Validate resolution and redirects for every delivery. - Bind destinations to reviewed subscription revisions. Implementation constraints - Use local receiver doubles and an explicit lab allowlist. Verification - Deliver to an approved local receiver. - Reject an unapproved redirect or changed destination authority. Deliverables - Webhook destination policy. Rollout and recovery: Default to no external destinations until the policy is configured. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. ### Deliver predictably Handle signatures, retries, ordering, and endpoint boundaries. #### BAPIHOOK-104 — Sign exact webhook bytes with versioned verification metadata **Task · High priority · Intermediate** noCV practice brief v5 · BAPIHOOK-104 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-101, BAPIHOOK-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Partners cannot verify signatures after the sender serializes the same event differently on retry. Acceptance criteria - Sign the exact delivered bytes. - Include key identity and bounded timestamp semantics. - Document receiver verification before payload trust. Implementation constraints - Use generated test keys and never log signing material. Verification - Verify a valid local delivery. - Change one byte or timestamp and reject verification. Deliverables - Signing contract and receiver example. Rollout and recovery: Introduce a versioned signature format with a bounded rotation overlap. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-105 — Document at-least-once delivery with stable event identities **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-105 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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 platform advertises one delivery even though connection loss can cause duplicates. Acceptance criteria - Keep event identity stable across attempts. - Record delivery attempts separately from event facts. - Provide a receiver deduplication example. Implementation constraints - Do not claim exactly-once delivery across HTTP. Verification - Lose a receiver acknowledgement and retry. - Verify the receiver applies the event once using its deduplication record. Deliverables - Delivery semantics and replay checks. Rollout and recovery: Preserve event identity through all retries and support actions. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-106 — Bound retry scheduling and distinguish terminal receiver responses **Task · High priority · Intermediate** noCV practice brief v5 · BAPIHOOK-106 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · API design 30% · Integrations 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 sender retries every response indefinitely, including malformed-endpoint failures. Acceptance criteria - Define retryable status classes and total delivery age. - Respect bounded retry-after guidance. - Move exhausted deliveries to an inspectable terminal state. Implementation constraints - Use an injected clock and fixed maximum attempts. Verification - Recover from a temporary receiver failure. - Exhaust a persistent failure without unbounded work. Deliverables - Retry contract. Rollout and recovery: Start with conservative limits; expose terminal state to authorized subscription owners. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-107 — Expose event ordering limits without requiring global sequencing **Task · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-107 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver predictably. Depends on: BAPIHOOK-105, BAPIHOOK-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Partners assume events arrive in the order they happened, but parallel delivery reorders them. Acceptance criteria - Declare the actual ordering scope. - Include resource revision where needed for stale-event handling. - Document how receivers handle gaps and older revisions. Implementation constraints - Avoid promising global ordering without implementing it. Verification - Deliver two resource revisions out of order. - Verify a receiver preserves its declared monotonic state. Deliverables - Ordering contract and receiver tests. Rollout and recovery: Publish ordering guidance before increasing delivery parallelism. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. ### Support evolution and replay Make recovery and schema migration explicit. #### BAPIHOOK-108 — Replay terminal deliveries without mutating original event content **Story · High priority · Advanced** noCV practice brief v5 · BAPIHOOK-108 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-106, BAPIHOOK-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 30% · Data 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. Support repairs a payload during replay and leaves the same event ID representing different facts. Acceptance criteria - Replay the original immutable event under a new attempt identity. - Require authorized subscription scope and reason. - Reject replay when current destination or data authority is revoked. Implementation constraints - Corrections require a new event identity and explicit relation. Verification - Replay a failed synthetic delivery. - Reject changed payload bytes and revoked subscription authority. Deliverables - Audited replay endpoint. Rollout and recovery: Keep replay bounded and visible to subscription owners. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-109 — Design webhook schema migration for independently deployed receivers **Task · High priority · Expert** noCV practice brief v5 · BAPIHOOK-109 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-104, BAPIHOOK-107, BAPIHOOK-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · System 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 required payload change cannot be safely deployed to all partner receivers at once. Acceptance criteria - Compare versioned subscriptions and additive-compatible evolution. - Define supported version overlap and retirement evidence. - Rehearse receiver upgrade, rollback, and replay of historical events. Implementation constraints - Historical events retain their original schema identity. Verification - Upgrade one synthetic receiver while another stays legacy. - Replay an old event after upgrade and verify documented handling. Deliverables - Webhook evolution decision record. Rollout and recovery: Keep supported schema serializers and examples through the retention window. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. #### BAPIHOOK-110 — Publish a webhook receiver checklist with failure recovery **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIHOOK-110 · Public webhook delivery contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support evolution and replay. Depends on: BAPIHOOK-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 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. Partners acknowledge before persisting event identity and lose events after a crash. Acceptance criteria - Show signature verification before parsing trusted fields. - Persist deduplication and accepted work before acknowledgement. - Document retry, replay, and unknown-version behavior. Implementation constraints - Use the local receiver double and synthetic events. Verification - Recover after a receiver crash before acknowledgement. - Reject an unsupported event version without discarding its identity. Deliverables - Executable receiver guide. Rollout and recovery: Version the guide with event and signature contracts. Project prerequisites: Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys. Engineer value: Practice public event contracts, delivery guarantees, and partner recovery workflows. Company value: Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility. 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. ## CGRID — An inventory grid with trustworthy edits Fictional supplier Reedworks uses a browser inventory table. Quantities are planning records, not live warehouse instructions. **Field:** Frontend. **Suggested stack:** React, TypeScript, CSS Modules, Playwright. **Engineer value:** Practice grid interaction and concurrent edit recovery. **Company value:** Inspect how changes protect operator intent during partial failures. **Delivery agreement:** Deliver separate pull requests using synthetic stock. ### Setup prerequisites - Create synthetic SKUs with revisions and nullable quantities. - Implement a local paginated adapter with conditional updates. ### Understand cells Define value and edit contracts. #### CGRID-101 — Render unknown stock separately from zero **Bug · High priority · Foundational** noCV practice brief v5 · CGRID-101 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand cells. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Buyers mistake missing quantities for zero because the grid coerces null. Preserve the API distinction. Acceptance criteria - Null displays Unknown - Zero displays 0 - Unknown values sort last Implementation constraints - Do not mutate stored quantities. Verification - Render null beside zero - Reject nonnumeric values without showing NaN Deliverables - Quantity renderer and cases Rollout and recovery: Revert the renderer without migration. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-102 — Keep inventory column widths after reload **Story · Medium priority · Foundational** noCV practice brief v5 · CGRID-102 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand cells. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Operators resize the SKU column every morning. Save bounded widths per grid version. Acceptance criteria - Widths restore after reload - Limits prevent hidden controls - Reset removes overrides Implementation constraints - Persist layout only. Verification - Restore two widths - Corrupt saved JSON and verify defaults Deliverables - Width persistence and reset control Rollout and recovery: Disable persistence if controls disappear. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-103 — Validate stock edits before saving **Task · High priority · Intermediate** noCV practice brief v5 · CGRID-103 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand cells. Depends on: CGRID-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pasting a decimal quantity sends an invalid stock update. Add recoverable field validation. Acceptance criteria - Nonnegative integers save - Decimals and negatives remain editable - Errors identify the cell Implementation constraints - Follow the local adapter contract. Verification - Save quantity 12 - Paste -1 and verify no request Deliverables - Cell validator and interaction cases Rollout and recovery: Restore read-only quantities if valid saves fail. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. ### Protect edits Preserve selection and drafts. #### CGRID-104 — Maintain inventory selection while sorted rows update **Bug · High priority · Advanced** noCV practice brief v5 · CGRID-104 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect edits. Depends on: CGRID-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 background refresh reorders rows and moves the editing highlight to another SKU. Anchor selection to identity. Acceptance criteria - Selected SKU remains selected - Deleted selection clears explicitly - Sorting cannot change edit target Implementation constraints - Array indices cannot identify rows. Verification - Refresh reordered rows - Delete the selected SKU mid-edit Deliverables - Identity-based selection coordinator Rollout and recovery: Disable background refresh if selection diverges. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-105 — Reject stale stock updates without losing drafts **Bug · High priority · Advanced** noCV practice brief v5 · CGRID-105 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect edits. Depends on: CGRID-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Two buyers edit the same row and the second overwrites the first. Handle revision conflicts. Acceptance criteria - Saves include expected revision - Conflict preserves draft and current value - Resubmission requires reconciliation Implementation constraints - Never blindly retry conflicts. Verification - Accept matching revision - Reject stale revision and inspect draft Deliverables - Conflict panel and adapter cases Rollout and recovery: Gate editing while conflict handling is repaired. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-106 — Define keyboard entry and escape for inventory cells **Story · Medium priority · Intermediate** noCV practice brief v5 · CGRID-106 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect edits. Depends on: CGRID-103, CGRID-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Arrow keys sometimes move cells while users edit text. Introduce explicit navigation and editing states. Acceptance criteria - Enter starts editing - Escape restores committed value - Editor arrows retain native behavior Implementation constraints - Provide semantic controls and visible focus. Verification - Edit without a pointer - Escape an invalid draft Deliverables - Keyboard contract and checks Rollout and recovery: Fall back to ordinary row forms. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-107 — Undo only an uncontested stock change **Story · Medium priority · Expert** noCV practice brief v5 · CGRID-107 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect edits. Depends on: CGRID-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · API design 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 blind Undo would erase a colleague's newer stock value. Add one guarded inverse update. Acceptance criteria - Undo uses resulting revision - Newer revisions reject undo - Failure preserves current row Implementation constraints - Undo must be a conditional write. Verification - Undo an uncontested save - Advance revision before undo Deliverables - Guarded undo and race case Rollout and recovery: Hide Undo while retaining ordinary edits. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. ### Handle interruption Recover from partial writes. #### CGRID-108 — Preview pasted stock ranges before applying them **Story · High priority · Advanced** noCV practice brief v5 · CGRID-108 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruption. Depends on: CGRID-103, CGRID-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Security 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 spreadsheet paste includes headers and an extra column. Show its target mapping before writing. Acceptance criteria - Preview names target SKUs - Malformed rows show errors - Confirm sends selected valid rows only Implementation constraints - Bound paste size and treat text as untrusted. Verification - Preview three rows - Reject oversized formula-like input safely Deliverables - Paste parser and confirmation preview Rollout and recovery: Disable paste while preserving manual edits. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-109 — Report individual results for a partial stock save **Task · High priority · Intermediate** noCV practice brief v5 · CGRID-109 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruption. Depends on: CGRID-105, CGRID-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Bulk edit says Saved when one row failed. Return stable per-row outcomes. Acceptance criteria - Success shows committed revision - Failure retains draft - Retry selects failed rows only Implementation constraints - Timeouts remain unresolved until reconciled. Verification - Save mixed valid and invalid rows - Timeout one row and inspect uncertainty Deliverables - Result summary and retry controls Rollout and recovery: Disable bulk save if result mapping fails. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. #### CGRID-110 — Export inventory-grid diagnostics without stock data **Chore · Low priority · Intermediate** noCV practice brief v5 · CGRID-110 · An inventory grid with trustworthy edits Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle interruption. Depends on: CGRID-104, CGRID-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Frontend 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. Support needs grid state but copying rows exposes inventory. Add an opt-in diagnostic download. Acceptance criteria - Includes grid version and flags - Omits quantities and SKU labels - User previews the report Implementation constraints - Allowlist diagnostic fields. Verification - Export populated grid - Verify secret-like fixture values are absent Deliverables - Exporter and exclusion checks Rollout and recovery: Remove export if unexpected fields appear. Project prerequisites: Create synthetic SKUs with revisions and nullable quantities. Implement a local paginated adapter with conditional updates. Engineer value: Practice grid interaction and concurrent edit recovery. Company value: Inspect how changes protect operator intent during partial failures. 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. ## CSEARCH — A catalog search that survives interruption Fictional workshop directory Cedar lists tools and spare parts using a local search adapter. **Field:** Frontend. **Suggested stack:** React, TypeScript, CSS Modules, Testing Library. **Engineer value:** Practice URL contracts and request ownership. **Company value:** Inspect whether discovery intent survives changing results. **Delivery agreement:** Use local fixtures; external search services are excluded. ### Setup prerequisites - Create synthetic items with stable identifiers. - Stub cursor pages, facets, delayed responses and missing items. ### Specify search state Make queries shareable. #### CSEARCH-101 — Normalize directory whitespace without changing part codes **Task · Medium priority · Foundational** noCV practice brief v5 · CSEARCH-101 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify search state. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Repeated spaces create separate search requests. Define normalization without altering case-sensitive part codes. Acceptance criteria - Outer spaces trim - Internal-space policy is documented - Input preserves edits until submit Implementation constraints - Do not silently lowercase identifiers. Verification - Submit padded code - Submit whitespace only Deliverables - Query parser and examples Rollout and recovery: Revert normalization while accepting old links. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-102 — Expose selected directory facets in shared links **Story · Medium priority · Intermediate** noCV practice brief v5 · CSEARCH-102 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify search state. Depends on: CSEARCH-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Shared search links conceal which filters excluded parts. Render removable facets from validated URL values. Acceptance criteria - Active facets have labels - Unknown facets use visible fallback - Removal resets pagination Implementation constraints - Resolve labels from trusted metadata. Verification - Open two selected facets - Use unknown facet ID Deliverables - Facet controls and URL cases Rollout and recovery: Disable facet writes while retaining parsing. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-103 — Announce completed directory searches once **Bug · Medium priority · Foundational** noCV practice brief v5 · CSEARCH-103 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify search state. Depends on: CSEARCH-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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 live region reads counts after every keystroke. Announce committed search outcomes without moving focus. Acceptance criteria - Count announces on completion - Loading has one status - Errors explain retry Implementation constraints - Do not focus status updates. Verification - Submit and inspect announcement - Reject search and inspect error Deliverables - Status component and manual protocol Rollout and recovery: Use submit-only announcements if updates repeat. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. ### Handle changing results Keep feedback attached to active queries. #### CSEARCH-104 — Bind directory page cursors to their originating query **Bug · High priority · Advanced** noCV practice brief v5 · CSEARCH-104 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing results. Depends on: CSEARCH-102. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. More results races with facet changes and appends unrelated products. Scope pages to query identity. Acceptance criteria - Matching pages alone append - Facet changes invalidate cursors - IDs deduplicate repeated results Implementation constraints - Cancellation alone is insufficient. Verification - Append matching page - Resolve old page after new query Deliverables - Query-scoped pager and race test Rollout and recovery: Disable incremental paging on ownership failure. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-105 — Restore a directory result anchor after detail navigation **Story · Medium priority · Intermediate** noCV practice brief v5 · CSEARCH-105 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing results. Depends on: CSEARCH-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Accessibility 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. Returning from a part detail resets a long search to the top. Restore the visited item. Acceptance criteria - Back restores query and anchor - Missing item has fallback - Focus returns to originating link Implementation constraints - Do not identify anchors only by pixels. Verification - Visit later result and return - Remove it before Back Deliverables - History restoration and browser case Rollout and recovery: Disable anchoring while retaining query history. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-106 — Explain unavailable parts in bookmarked directory links **Story · Medium priority · Intermediate** noCV practice brief v5 · CSEARCH-106 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing results. Depends on: CSEARCH-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Security 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 old part bookmark renders a blank page. Distinguish removal from failed loading. Acceptance criteria - Missing and failed reads differ - Return preserves valid search - External return targets are rejected Implementation constraints - Allowlist internal return routes. Verification - Open removed part - Inject external return URL Deliverables - Unavailable state and route tests Rollout and recovery: Restore static unavailable page if navigation breaks. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-107 — Keep zero-count directory facets removable **Bug · Medium priority · Advanced** noCV practice brief v5 · CSEARCH-107 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing results. Depends on: CSEARCH-102, CSEARCH-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Selected filters disappear when counts reach zero, trapping the query. Separate selection from availability. Acceptance criteria - Selected zero-count facets remain - Stale counts are labeled - Count failure preserves selection Implementation constraints - Count refresh cannot rewrite selections. Verification - Select zero-result facet - Reject facet-count refresh Deliverables - Facet reconciliation and cases Rollout and recovery: Freeze counts while preserving removal. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. ### Prepare recovery Bound caching and support diagnosis. #### CSEARCH-108 — Bound the directory query cache **Task · Medium priority · Expert** noCV practice brief v5 · CSEARCH-108 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare recovery. Depends on: CSEARCH-104, CSEARCH-107. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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. Browsing many searches grows memory indefinitely. Introduce capacity and expiry with deterministic eviction. Acceptance criteria - Capacity is configurable - Keys contain all query dimensions - Expired entries refresh visibly Implementation constraints - Cache public directory records only. Verification - Revisit retained query - Exceed capacity and inspect eviction Deliverables - Cache policy and clock tests Rollout and recovery: Disable cache and fetch committed queries. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-109 — Print a directory shortlist from current item identities **Story · Medium priority · Intermediate** noCV practice brief v5 · CSEARCH-109 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare recovery. Depends on: CSEARCH-105, CSEARCH-106. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Printed shortlists include removed entries. Use a dedicated projection resolved by current item IDs. Acceptance criteria - Missing items are identified - Removal updates print - Controls are hidden in print Implementation constraints - Use the local directory adapter. Verification - Print two entries - Remove one before printing Deliverables - Print view and media checks Rollout and recovery: Hide printing if projections diverge. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. #### CSEARCH-110 — Instrument directory search without capturing query text **Chore · Low priority · Advanced** noCV practice brief v5 · CSEARCH-110 · A catalog search that survives interruption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare recovery. Depends on: CSEARCH-103, CSEARCH-108. Difficulty: Advanced. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Frontend 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. Search failure metrics currently include potentially sensitive part queries. Add bounded operational events. Acceptance criteria - Includes outcome and duration bucket - Omits queries and item names - Retries retain correlation token Implementation constraints - Verify through a local event collector. Verification - Complete search and inspect event - Fail secret-like query and check exclusion Deliverables - Event allowlist and samples Rollout and recovery: Disable event sink if unexpected fields appear. Project prerequisites: Create synthetic items with stable identifiers. Stub cursor pages, facets, delayed responses and missing items. Engineer value: Practice URL contracts and request ownership. Company value: Inspect whether discovery intent survives changing results. 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. ## CFORM — A procurement form that protects drafts Fictional procurement team Northroom collects purchase requests in a browser form. Work uses local stubs and cannot place purchases. **Field:** Frontend. **Suggested stack:** React, TypeScript, CSS Modules, Playwright. **Engineer value:** Practice state boundaries and form schema transitions. **Company value:** Inspect how hidden obsolete data and duplicate requests are prevented. **Delivery agreement:** Submit each form behavior as a separate change. ### Setup prerequisites - Create synthetic categories and conditional request fields. - Stub draft revisions and submission outcomes. ### Clarify fields Specify amounts and conditional values. #### CFORM-101 — Preserve procurement amount precision during editing **Bug · Medium priority · Foundational** noCV practice brief v5 · CFORM-101 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Clarify fields. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Entered 19.90 becomes 19.9 and later rounds. Separate edit text from validated minor units. Acceptance criteria - Review uses currency precision - Incomplete text stays editable - Excess precision blocks submit Implementation constraints - Parse decimals without binary float arithmetic. Verification - Review 19.90 - Enter excess decimal places Deliverables - Amount parser and field cases Rollout and recovery: Revert formatting while retaining minor-unit storage. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-102 — Link procurement error summaries to affected fields **Story · Medium priority · Foundational** noCV practice brief v5 · CFORM-102 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Clarify fields. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Required fields missing gives no location. Add field errors and a navigable summary. Acceptance criteria - Summary links focus fields - Labels expose required state - Corrections clear only relevant errors Implementation constraints - Use stable description IDs. Verification - Follow summary link - Submit several missing values Deliverables - Summary and keyboard checks Rollout and recovery: Retain field errors if summary navigation fails. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-103 — Remove obsolete shipping fields on procurement category changes **Bug · High priority · Intermediate** noCV practice brief v5 · CFORM-103 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Clarify fields. Depends on: CFORM-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · Privacy 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. Switching hardware to services retains a hidden shipping address in the payload. Make conditional removal explicit. Acceptance criteria - Payload excludes inactive fields - Discard prompts identify entered data - Cancel preserves category Implementation constraints - Hidden inputs are not a serialization policy. Verification - Switch empty category - Cancel populated category switch Deliverables - Conditional payload projection Rollout and recovery: Disable category changes until removal is corrected. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. ### Protect progress Recover drafts and schema changes. #### CFORM-104 — Allow earlier procurement corrections after final-step errors **Task · Medium priority · Intermediate** noCV practice brief v5 · CFORM-104 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect progress. Depends on: CFORM-102, CFORM-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 final-step error blocks users from returning to fix amounts. Separate navigation from submission validity. Acceptance criteria - Back stays available - Forward validates applicable step - Submit validates full active payload Implementation constraints - Share one validation contract. Verification - Correct earlier amount - Fail final validation and go Back Deliverables - Step validation coordinator Rollout and recovery: Fall back to a single-page form. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-105 — Show acknowledged and unsaved procurement draft states **Story · High priority · Advanced** noCV practice brief v5 · CFORM-105 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect progress. Depends on: CFORM-104. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Failed autosaves look saved. Track acknowledgements without interrupting editing. Acceptance criteria - Saved means acknowledged revision - Failure retains edits - Late acknowledgement cannot mark newer edits saved Implementation constraints - Debouncing cannot establish revision ownership. Verification - Save then edit - Resolve saves out of order Deliverables - Draft states and race tests Rollout and recovery: Disable autosave and expose explicit save. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-106 — Stop conflicting procurement saves from another tab **Bug · High priority · Advanced** noCV practice brief v5 · CFORM-106 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect progress. Depends on: CFORM-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Two tabs silently overwrite a draft. Require expected revisions and preserve conflicting local work. Acceptance criteria - Stale writes fail visibly - Local edits remain recoverable - Reconciliation is explicit Implementation constraints - Browser warnings cannot replace revision checks. Verification - Save one tab - Submit stale save in second Deliverables - Multi-tab conflict flow Rollout and recovery: Pause writes on unresolved conflict. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-107 — Migrate one procurement draft schema transition **Task · High priority · Expert** noCV practice brief v5 · CFORM-107 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect progress. Depends on: CFORM-103, CFORM-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 category field changes shape while drafts remain open. Add one deterministic version migration. Acceptance criteria - Old version migrates predictably - Future versions stay read-only - Dropped fields appear in review Implementation constraints - Preserve original draft until acknowledgement. Verification - Migrate old fixture - Open unsupported future version Deliverables - Migration and preserved-original cases Rollout and recovery: Restore old reader using preserved drafts. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. ### Submit deliberately Bind review to confirmed writes. #### CFORM-108 — Bind procurement review to the exact submission snapshot **Story · Medium priority · Intermediate** noCV practice brief v5 · CFORM-108 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Submit deliberately. Depends on: CFORM-104, CFORM-107. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Review recomputes defaults differently from submit. Create one validated snapshot for both. Acceptance criteria - Review matches sent values - Editing invalidates review - Inactive fields are excluded Implementation constraints - Confirmation identifies snapshot revision. Verification - Review and submit unchanged - Edit amount after review Deliverables - Snapshot projection and checks Rollout and recovery: Disable submit if snapshot matching fails. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-109 — Reconcile uncertain procurement submissions before retrying **Bug · High priority · Advanced** noCV practice brief v5 · CFORM-109 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Submit deliberately. Depends on: CFORM-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. A timeout followed by retry creates duplicate requests. Retain one submission key until resolved. Acceptance criteria - Retry reuses key - Success locks snapshot - Unknown outcomes expose status lookup Implementation constraints - Timeout alone cannot prove failure. Verification - Submit then retry - Timeout after adapter acceptance Deliverables - Submission coordinator and timeout case Rollout and recovery: Pause retries while allowing lookup. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. #### CFORM-110 — Export one recoverable procurement draft without session data **Chore · Low priority · Intermediate** noCV practice brief v5 · CFORM-110 · A procurement form that protects drafts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Submit deliberately. Depends on: CFORM-106, CFORM-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Frontend 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. Support requests whole browser storage to recover drafts. Offer scoped, previewed export instead. Acceptance criteria - Preview lists included fields - Session tokens are omitted - Invalid drafts export as drafts Implementation constraints - Never trust exported content as HTML. Verification - Export current draft - Check other drafts and tokens are absent Deliverables - Draft export and scope checks Rollout and recovery: Remove export if isolation fails. Project prerequisites: Create synthetic categories and conditional request fields. Stub draft revisions and submission outcomes. Engineer value: Practice state boundaries and form schema transitions. Company value: Inspect how hidden obsolete data and duplicate requests are prevented. 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. ## CROUTE — An offline field-service route notebook Fictional maintenance coordinator Elm dispatches non-safety-critical inspection visits. Implement a mobile application in an emulator with local API stubs; physical devices and credentials are unnecessary. **Field:** Mobile. **Suggested stack:** React Native, TypeScript, SQLite, Emulator. **Engineer value:** Practice durable mobile state and explicit sync conflicts. **Company value:** Inspect how an engineer protects field work during disconnection. **Delivery agreement:** Use synthetic notes and emulator runs; no location tracking or real dispatch. ### Setup prerequisites - Create synthetic visits and a local sync adapter. - Provide controllable connectivity and process-restart simulation. ### Make visits readable Define local visit state. #### CROUTE-101 — Label route-note timestamps with their actual zone **Bug · Medium priority · Foundational** noCV practice brief v5 · CROUTE-101 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make visits readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. Visit notes appear an hour early after an emulator zone change. Distinguish stored instants from displayed local times. Acceptance criteria - Instants remain UTC - Display identifies zone - Invalid timestamps show unavailable Implementation constraints - Inject time and zone in tests. Verification - Change emulator zone - Render malformed timestamp Deliverables - Timestamp formatter and cases Rollout and recovery: Restore UTC display if local conversion fails. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-102 — Show downloaded visits when route refresh fails **Story · High priority · Foundational** noCV practice brief v5 · CROUTE-102 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make visits readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. An offline refresh replaces the route with an empty screen. Retain downloaded visits and identify staleness. Acceptance criteria - Cached visits remain visible - Last sync time appears - Retry does not delete cache Implementation constraints - Distinguish empty success from network failure. Verification - Load cached route offline - Return successful empty route Deliverables - Route loading states Rollout and recovery: Disable refresh clearing if cache disappears. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-103 — Persist field-note edits before leaving a visit **Bug · High priority · Intermediate** noCV practice brief v5 · CROUTE-103 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make visits readable. Depends on: CROUTE-101, CROUTE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Database 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. Back navigation occasionally loses the last sentence. Commit local edits before acknowledging navigation. Acceptance criteria - Confirmed save survives restart - Failed writes retain editor - Navigation explains unresolved persistence Implementation constraints - Use a local transaction, not delayed component state. Verification - Save then restart - Inject storage failure on Back Deliverables - Durable draft write and restart cases Rollout and recovery: Prevent exit with unsaved changes until repaired. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. ### Protect offline work Persist notes and resolve conflicts. #### CROUTE-104 — Queue field-note synchronization by immutable operation ID **Task · High priority · Advanced** noCV practice brief v5 · CROUTE-104 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect offline work. Depends on: CROUTE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 40% · Database engineering 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 same offline note uploads twice after a timeout. Persist an operation ID alongside each queued change. Acceptance criteria - Retries reuse ID - Accepted changes leave queue atomically - New edits create new operations Implementation constraints - Server stub must deduplicate operations. Verification - Replay accepted upload - Crash after acceptance before dequeue Deliverables - Sync queue and replay tests Rollout and recovery: Pause uploading without deleting queued work. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-105 — Preserve conflicting offline visit notes for explicit resolution **Story · High priority · Advanced** noCV practice brief v5 · CROUTE-105 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect offline work. Depends on: CROUTE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Distributed systems 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. Two emulators edit one visit offline and last-write-wins removes a paragraph. Surface both revisions. Acceptance criteria - Conflict preserves both texts - No silent merge occurs - Resolution creates a new revision Implementation constraints - Synthetic notes only; omit content from logs. Verification - Resolve two independent drafts - Reject a stale resolution revision Deliverables - Conflict screen and revision cases Rollout and recovery: Keep conflicts read-only while resolver is repaired. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-106 — Resume route-note upload after application termination **Bug · High priority · Expert** noCV practice brief v5 · CROUTE-106 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect offline work. Depends on: CROUTE-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Distributed systems 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. Killing the process mid-sync leaves operations marked Sending forever. Add a recoverable lease state. Acceptance criteria - Expired sends return to retryable - Active leases avoid duplicate work - Attempt count is bounded Implementation constraints - Use an injected monotonic lease clock. Verification - Restart after expired lease - Restart before lease expiry Deliverables - Lease recovery and crash schedule Rollout and recovery: Pause runner and retain durable queue. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-107 — Remove downloaded visit attachments without deleting notes **Task · Medium priority · Intermediate** noCV practice brief v5 · CROUTE-107 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect offline work. Depends on: CROUTE-102, CROUTE-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Mobile 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. Attachment cache consumes emulator storage. Add per-visit cleanup that preserves authored drafts. Acceptance criteria - Cleanup targets downloaded blobs - Notes and queue remain intact - Failed deletion reports reclaim uncertainty Implementation constraints - Separate cache paths from draft storage. Verification - Clean one visit - Fail blob removal and inspect notes Deliverables - Cache cleanup and isolation cases Rollout and recovery: Disable cleanup if protected paths overlap. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. ### Recover interruptions Bound retries and explain sync outcomes. #### CROUTE-108 — Bound offline route-note retry backoff **Chore · Medium priority · Intermediate** noCV practice brief v5 · CROUTE-108 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interruptions. Depends on: CROUTE-106. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. A disconnected emulator retries uploads continuously and drains resources. Add capped backoff with manual retry semantics. Acceptance criteria - Delays grow to cap - Connectivity recovery can wake once - Manual retry cannot create parallel senders Implementation constraints - Inject timers; avoid wall-clock sleeps in tests. Verification - Observe scheduled delays - Toggle connectivity repeatedly Deliverables - Retry scheduler and fake-clock tests Rollout and recovery: Stop automatic retries and expose manual sync. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-109 — Explain partial route synchronization per visit **Story · Medium priority · Intermediate** noCV practice brief v5 · CROUTE-109 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interruptions. Depends on: CROUTE-105, CROUTE-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. A global Sync complete banner hides a failed visit. Show per-visit pending, conflicted, and acknowledged states. Acceptance criteria - Global summary counts unresolved visits - Each failure has action - Success follows acknowledgement Implementation constraints - Do not infer sync from an empty in-memory queue. Verification - Sync mixed outcomes - Restart with persisted pending work Deliverables - Sync summary and recovery checks Rollout and recovery: Hide global success if summaries disagree. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. #### CROUTE-110 — Export a synthetic field-note recovery bundle deliberately **Chore · Low priority · Advanced** noCV practice brief v5 · CROUTE-110 · An offline field-service route notebook Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interruptions. Depends on: CROUTE-106, CROUTE-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Mobile 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. Debugging a stuck route requires durable state without sharing account tokens. Provide a previewed local recovery bundle. Acceptance criteria - Includes operation metadata - Excludes tokens and attachment bytes - User explicitly includes note text Implementation constraints - Default export omits note bodies. Verification - Export default bundle - Verify secret-like fixture text is absent Deliverables - Bundle schema and redaction cases Rollout and recovery: Remove export if exclusions fail. Project prerequisites: Create synthetic visits and a local sync adapter. Provide controllable connectivity and process-restart simulation. Engineer value: Practice durable mobile state and explicit sync conflicts. Company value: Inspect how an engineer protects field work during disconnection. 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. ## CDOWN — A dependable mobile course-download shelf Fictional learning app Birch offers synthetic text and small local media fixtures through a loopback adapter. No copyrighted course assets or network accounts are needed. **Field:** Mobile. **Suggested stack:** React Native, TypeScript, SQLite, Emulator. **Engineer value:** Practice mobile file lifecycles and background state recovery. **Company value:** Inspect predictable resource usage and truthful download status. **Delivery agreement:** Use generated local fixtures; app-store publishing is outside scope. ### Setup prerequisites - Create small local byte fixtures and a range-response stub. - Simulate low storage, interruptions and stale manifests. ### Describe downloads Model local content and sizes. #### CDOWN-101 — Distinguish unknown course-download sizes from zero bytes **Bug · Medium priority · Foundational** noCV practice brief v5 · CDOWN-101 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe downloads. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. Unmeasured courses show 0 MB and users assume downloads are free of storage cost. Display size uncertainty. Acceptance criteria - Unknown size is labeled - Zero-byte fixtures remain valid - Unit formatting has boundary tests Implementation constraints - Do not invent estimates without metadata. Verification - Render zero and unknown - Render malformed size Deliverables - Size formatter and shelf states Rollout and recovery: Fall back to byte counts for known values. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-102 — Keep mobile download buttons consistent with durable state **Task · Medium priority · Intermediate** noCV practice brief v5 · CDOWN-102 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe downloads. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · Storage 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. Returning to the shelf shows Download while a transfer is active. Render controls from one persisted lifecycle. Acceptance criteria - Active transfer shows pause - Completed content shows open - Invalid states do not expose start Implementation constraints - Define explicit lifecycle transitions. Verification - Navigate away and return - Load corrupt lifecycle value Deliverables - Download-state projection Rollout and recovery: Disable new downloads if state cannot be read. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-103 — Validate course manifest paths before creating files **Bug · High priority · Intermediate** noCV practice brief v5 · CDOWN-103 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe downloads. Depends on: CDOWN-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Storage systems 20% · Mobile 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 malformed manifest filename can escape its course directory. Restrict all destinations to a scoped cache root. Acceptance criteria - Traversal is rejected - Absolute paths are rejected - Valid nested relative paths stay scoped Implementation constraints - Resolve paths before opening files. Verification - Write a valid nested fixture - Reject parent-directory and drive paths Deliverables - Manifest path validator Rollout and recovery: Reject new manifests until path validation is restored. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. ### Handle transfer boundaries Verify and recover bytes. #### CDOWN-104 — Resume a mobile course transfer only with matching content identity **Story · High priority · Advanced** noCV practice brief v5 · CDOWN-104 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle transfer boundaries. Depends on: CDOWN-102, CDOWN-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · Networking 30% · Mobile 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 paused transfer resumes after content changed and produces mixed bytes. Bind ranges to a manifest version. Acceptance criteria - Resume checks content identity - Mismatch discards incompatible partial bytes - Restart remains explicit in UI Implementation constraints - Treat ETags as opaque validators. Verification - Resume unchanged fixture - Change validator during pause Deliverables - Range-resume coordinator Rollout and recovery: Disable resume and restart from zero safely. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-105 — Verify downloaded course bytes before exposing Open **Task · High priority · Advanced** noCV practice brief v5 · CDOWN-105 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle transfer boundaries. Depends on: CDOWN-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Mobile 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 truncated transfer is marked complete because the connection closed normally. Verify length and declared digest. Acceptance criteria - Completed means both checks pass - Mismatch stays unavailable - Bad partial bytes can be removed Implementation constraints - Digest metadata comes from the local trusted manifest. Verification - Download valid fixture - Truncate or flip one byte Deliverables - Completion verifier and corruption cases Rollout and recovery: Disable Open for unverified content. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-106 — Pause mobile transfers when storage reservation fails **Story · High priority · Intermediate** noCV practice brief v5 · CDOWN-106 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle transfer boundaries. Depends on: CDOWN-102, CDOWN-103. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Mobile 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 nearly full emulator accepts several downloads and fails unpredictably. Reserve a bounded budget before writing. Acceptance criteria - Admission accounts for active transfers - Failure preserves existing content - User sees required space Implementation constraints - Reservation estimates must state uncertainty. Verification - Admit fitting transfer - Start competing transfers exceeding budget Deliverables - Storage admission policy Rollout and recovery: Stop new transfers while preserving installed courses. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-107 — Recover a course-download rename interrupted by process death **Bug · High priority · Expert** noCV practice brief v5 · CDOWN-107 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle transfer boundaries. Depends on: CDOWN-105, CDOWN-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Mobile 30% · Database 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 crash between verification and final rename leaves duplicate shelf entries. Introduce a recoverable promotion record. Acceptance criteria - Recovery identifies one installed version - Unverified partials stay hidden - Repeated recovery is idempotent Implementation constraints - Keep metadata and file promotion reconciliation explicit. Verification - Kill at each promotion boundary - Repeat recovery after missing temp file Deliverables - Promotion journal and crash cases Rollout and recovery: Disable promotion and retain recoverable temporary files. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. ### Maintain the shelf Clean up and explain resource failures. #### CDOWN-108 — Remove one downloaded course without breaking shared assets **Task · Medium priority · Advanced** noCV practice brief v5 · CDOWN-108 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Maintain the shelf. Depends on: CDOWN-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Mobile 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. Deleting a course removes an image another course references. Track local references before reclaiming shared blobs. Acceptance criteria - Unreferenced blobs are reclaimed - Referenced blobs remain - Failed cleanup is retryable Implementation constraints - Keep references scoped to verified manifests. Verification - Delete unique course - Delete course with shared asset Deliverables - Reference-aware cleanup Rollout and recovery: Disable physical reclamation while fixing reference accounting. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-109 — Show course-download progress without rendering every chunk **Bug · Medium priority · Intermediate** noCV practice brief v5 · CDOWN-109 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Maintain the shelf. Depends on: CDOWN-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Mobile 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. Small network chunks trigger excessive mobile renders. Coalesce progress updates while keeping completion immediate. Acceptance criteria - Updates have bounded frequency - Completion bypasses throttle - Paused bytes remain accurate Implementation constraints - Use an injected scheduler. Verification - Stream many chunks - Pause between scheduled updates Deliverables - Progress coalescer and render-count check Rollout and recovery: Reduce to coarse milestones if scheduling regresses. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. #### CDOWN-110 — Provide a local download repair action with explicit scope **Story · Medium priority · Intermediate** noCV practice brief v5 · CDOWN-110 · A dependable mobile course-download shelf Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Maintain the shelf. Depends on: CDOWN-108, CDOWN-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Storage systems 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. Users cannot recover one corrupt course without clearing the entire app. Add repair for the selected course only. Acceptance criteria - Repair revalidates selected files - Other courses remain intact - Offline repair explains deferred bytes Implementation constraints - Never clear account or unrelated application storage. Verification - Repair corrupted fixture - Run repair offline Deliverables - Scoped repair flow and isolation checks Rollout and recovery: Hide repair if deletion scope cannot be established. Project prerequisites: Create small local byte fixtures and a range-response stub. Simulate low storage, interruptions and stale manifests. Engineer value: Practice mobile file lifecycles and background state recovery. Company value: Inspect predictable resource usage and truthful download status. 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. ## CLINK — Mobile invitation and session navigation Fictional team-planning app Finch opens invitations and shared work items. All users and sessions are synthetic; implement the app in an emulator without external identity credentials. **Field:** Mobile. **Suggested stack:** React Native, TypeScript, Emulator, Testing Library. **Engineer value:** Practice navigation state, capability checks and session boundaries. **Company value:** Inspect whether links remain useful without bypassing authorization. **Delivery agreement:** Deliver local navigation behaviors; real identity integrations remain separate. ### Setup prerequisites - Create a local session adapter with expiry and revocation. - Define synthetic invitation and work-item links. ### Parse entry points Establish safe route contracts. #### CLINK-101 — Reject malformed mobile invitation routes before navigation **Task · High priority · Foundational** noCV practice brief v5 · CLINK-101 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Parse entry points. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 70% · Security 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. Pasted links with missing invitation IDs crash route construction. Add strict parsing before mounting screens. Acceptance criteria - Valid IDs produce typed routes - Malformed links show a recoverable state - Unsupported schemes are rejected Implementation constraints - Do not render arbitrary link text as markup. Verification - Open valid fixture link - Open empty and oversized IDs Deliverables - Link parser and invalid-input cases Rollout and recovery: Disable invitation entry while keeping home navigation. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-102 — Explain expired mobile invitations without automatic retries **Story · Medium priority · Foundational** noCV practice brief v5 · CLINK-102 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Parse entry points. Depends on: CLINK-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. Expired invitations spin indefinitely because the client treats every response as transient. Render terminal expiry distinctly. Acceptance criteria - Expiry stops retry - User can return home - Temporary failures retain manual retry Implementation constraints - Follow typed adapter error codes. Verification - Open expired fixture - Simulate temporary outage Deliverables - Invitation error states Rollout and recovery: Restore static invitation failure page if classification breaks. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-103 — Retain a mobile link destination through local sign-in **Story · Medium priority · Intermediate** noCV practice brief v5 · CLINK-103 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Parse entry points. Depends on: CLINK-101, CLINK-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · 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. Signing in from an invitation lands on the dashboard. Preserve a validated destination until identity is available. Acceptance criteria - Valid destination resumes once - External destinations are rejected - Cancel sign-in clears pending intent Implementation constraints - Store route identity, not raw credentials or URL tokens. Verification - Sign in and resume - Cancel then sign in normally Deliverables - Pending-route coordinator Rollout and recovery: Disable continuation if validation fails. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. ### Handle identity changes Preserve only authorized navigation intent. #### CLINK-104 — Recheck mobile work-item access after account switching **Bug · High priority · Advanced** noCV practice brief v5 · CLINK-104 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle identity changes. Depends on: CLINK-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Mobile 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. Switching accounts leaves the previous account's work screen visible. Clear account-scoped cache before refetching. Acceptance criteria - Old content clears on switch - New identity requires authorized read - Denied reads show no prior item data Implementation constraints - Account identity belongs in cache boundaries. Verification - Switch to authorized account - Switch to denied account Deliverables - Account-switch isolation and checks Rollout and recovery: Force full local session reset while repaired. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-105 — Serialize mobile session refresh for simultaneous requests **Task · High priority · Advanced** noCV practice brief v5 · CLINK-105 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle identity changes. Depends on: CLINK-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Security 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. Opening a linked screen triggers three refresh calls and conflicting session updates. Share one in-flight refresh. Acceptance criteria - Concurrent reads share refresh - Failure releases waiting requests consistently - Later retry can start anew Implementation constraints - Session tokens stay outside generic logs. Verification - Trigger three expired reads - Reject refresh then retry Deliverables - Refresh coordinator and concurrency tests Rollout and recovery: Stop automatic refresh and require explicit sign-in. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-106 — Cancel pending mobile navigation when invitation ownership changes **Bug · High priority · Intermediate** noCV practice brief v5 · CLINK-106 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle identity changes. Depends on: CLINK-104, CLINK-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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 invitation opened before account switching completes under the wrong identity. Bind continuation to the initiating session generation. Acceptance criteria - Stale continuation is discarded - Current session can reopen link - No prior invitation details remain visible Implementation constraints - Cancellation must survive late adapter responses. Verification - Resolve current invitation - Resolve old invitation after switch Deliverables - Session-scoped continuation guard Rollout and recovery: Clear all pending routes on account change. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-107 — Recover mobile sign-in continuation after process restart **Story · Medium priority · Expert** noCV practice brief v5 · CLINK-107 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle identity changes. Depends on: CLINK-103, CLINK-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. An emulator restart during local sign-in loses the requested destination. Persist minimal, expiring continuation state. Acceptance criteria - Valid continuation resumes once - Expired continuation is discarded - Unknown schema versions fail closed Implementation constraints - Persist no session secrets in navigation storage. Verification - Restart before continuation - Tamper with saved destination Deliverables - Versioned continuation store and restart checks Rollout and recovery: Delete continuation metadata and return home. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. ### Test interruption Recover process and session transitions. #### CLINK-108 — Keep the mobile Back stack free of completed sign-in screens **Bug · Medium priority · Intermediate** noCV practice brief v5 · CLINK-108 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test interruption. Depends on: CLINK-106, CLINK-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. After joining a team, Back returns to a completed sign-in screen that resubmits. Replace transient routes on success. Acceptance criteria - Back reaches prior meaningful screen - Completed forms cannot resubmit - Failed sign-in remains editable Implementation constraints - Specify stack behavior for cold and warm launches. Verification - Complete cold-launch sign-in - Fail then retry warm launch Deliverables - Stack transition and navigation tests Rollout and recovery: Reset to home after sign-in if replacement fails. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-109 — Expose revoked mobile sessions before showing cached team content **Bug · High priority · Advanced** noCV practice brief v5 · CLINK-109 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test interruption. Depends on: CLINK-104, CLINK-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Mobile 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 resumed app flashes old team details before learning the session was revoked. Gate sensitive cached rendering. Acceptance criteria - Resume enters verification state - Revocation clears scoped cache - Offline uncertainty has an explicit locked view Implementation constraints - Public shell may render without private records. Verification - Resume valid session - Revoke during background pause Deliverables - Resume gate and revocation checks Rollout and recovery: Clear private cache on every resume until fixed. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. #### CLINK-110 — Record mobile deep-link failure categories without invitation tokens **Chore · Low priority · Intermediate** noCV practice brief v5 · CLINK-110 · Mobile invitation and session navigation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Test interruption. Depends on: CLINK-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Mobile 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. Support logs raw invitation URLs while diagnosing failures. Emit categories and route types only. Acceptance criteria - Logs exclude IDs and tokens - Known failures have stable categories - Unexpected errors use bounded safe summaries Implementation constraints - Verify with synthetic secret-like links. Verification - Log valid route outcome - Reject token-bearing malformed URL Deliverables - Diagnostic event contract Rollout and recovery: Disable link diagnostics on redaction failure. Project prerequisites: Create a local session adapter with expiry and revocation. Define synthetic invitation and work-item links. Engineer value: Practice navigation state, capability checks and session boundaries. Company value: Inspect whether links remain useful without bypassing authorization. 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. ## CCAL — An accessible staffing calendar Fictional studio Loom assigns editorial shifts. Build synthetic shifts and a local scheduling adapter; no real staff records are used. **Field:** Accessibility. **Suggested stack:** React, TypeScript, CSS Modules, Playwright. **Engineer value:** Practice focus models and accessible alternatives for spatial interfaces. **Company value:** Inspect whether scheduling remains usable across input methods and failure states. **Delivery agreement:** Record automated checks and a manual protocol; do not claim accessibility certification. ### Setup prerequisites - Create synthetic shifts including overlaps and daylight-saving boundaries. - Implement a local schedule revision adapter. ### Read the schedule Provide meaningful structure and labels. #### CCAL-101 — Name staffing shifts independently of calendar color **Bug · High priority · Foundational** noCV practice brief v5 · CCAL-101 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Read the schedule. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 80% · Frontend 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. Shift type is conveyed only by blue or green blocks. Add visible labels and complete accessible names. Acceptance criteria - Type appears as text - Names include date and duration - Color remains optional reinforcement Implementation constraints - Do not concatenate decorative icon names. Verification - Inspect two shift types - Disable color and distinguish them Deliverables - Shift label component and checks Rollout and recovery: Restore text-only blocks if labels become ambiguous. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-102 — Provide a chronological agenda beside the staffing grid **Story · Medium priority · Intermediate** noCV practice brief v5 · CCAL-102 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Read the schedule. Depends on: CCAL-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Screen-reader users must traverse many empty calendar cells to find shifts. Offer an equivalent agenda view. Acceptance criteria - Agenda lists all visible shifts - Dates are headings - View switch retains selected date Implementation constraints - Both views use one data projection. Verification - Compare grid and agenda identities - Render an empty week Deliverables - Agenda view and equivalence checks Rollout and recovery: Keep agenda available if grid navigation is withdrawn. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-103 — Describe staffing time-zone changes explicitly **Task · Medium priority · Foundational** noCV practice brief v5 · CCAL-103 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Read the schedule. Depends on: CCAL-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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 calendar silently changes times when the display zone changes. Show zone context without announcing every cell. Acceptance criteria - Header identifies display zone - Shift detail exposes full date/time - Zone change has one status announcement Implementation constraints - Store instants independently from labels. Verification - Change zone and inspect detail - Use ambiguous clock time fixture Deliverables - Zone labels and manual reading protocol Rollout and recovery: Fix display to documented UTC if conversion fails. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. ### Operate shifts Support alternatives and stable focus. #### CCAL-104 — Move staffing shifts through a keyboard form **Story · High priority · Intermediate** noCV practice brief v5 · CCAL-104 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate shifts. Depends on: CCAL-102, CCAL-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Dragging is the only way to move a shift. Add date/time controls with equivalent validation. Acceptance criteria - Every draggable shift has Move action - Form and drag share validation - Cancel preserves the shift Implementation constraints - The form must not require pointer gestures. Verification - Move using keyboard - Submit overlapping invalid shift Deliverables - Move form and equivalence cases Rollout and recovery: Disable dragging if it diverges from the form contract. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-105 — Restore staffing focus after a shift is deleted **Bug · High priority · Advanced** noCV practice brief v5 · CCAL-105 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate shifts. Depends on: CCAL-104. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Deleting a selected block sends focus to the document body. Choose a predictable surviving target. Acceptance criteria - Next chronological shift receives focus - Empty day focuses its heading control - Failed deletion retains original focus Implementation constraints - Resolve targets after committed DOM updates. Verification - Delete middle shift - Reject deletion and inspect focus Deliverables - Focus resolver and deletion checks Rollout and recovery: Keep deleted-row placeholder temporarily if focus restoration fails. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-106 — Announce staffing conflicts without repeating the entire calendar **Bug · Medium priority · Intermediate** noCV practice brief v5 · CCAL-106 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate shifts. Depends on: CCAL-104. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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 revision conflict rerenders the grid and reads dozens of cells. Isolate a concise conflict message and resolution controls. Acceptance criteria - Conflict identifies affected shift - Draft remains available - Calendar content is not a live region Implementation constraints - Announcements must not reveal unrelated staff data. Verification - Trigger one conflict - Retry failure and check announcement count Deliverables - Conflict status region Rollout and recovery: Disable auto-refresh announcements if they repeat. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-107 — Support calendar navigation across removed and disabled shifts **Task · High priority · Expert** noCV practice brief v5 · CCAL-107 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate shifts. Depends on: CCAL-105, CCAL-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Roving focus points at a disabled shift after refresh. Define deterministic navigation across changing eligible targets. Acceptance criteria - Only one navigation tab stop exists - Disabled targets are skipped - Removed focus resolves predictably Implementation constraints - Document arrow-key behavior without overriding text inputs. Verification - Navigate mixed availability - Remove current target during refresh Deliverables - Navigation model and transition cases Rollout and recovery: Switch to ordinary tab stops while repairing the model. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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 adaptive use Handle zoom, motion and assistive feedback. #### CCAL-108 — Reflow staffing controls at high text zoom **Bug · Medium priority · Intermediate** noCV practice brief v5 · CCAL-108 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify adaptive use. Depends on: CCAL-102, CCAL-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. At 200 percent text size the week selector hides Add shift. Reflow controls while keeping date context. Acceptance criteria - Controls wrap without clipping - Agenda avoids horizontal document overflow - Focus remains visible Implementation constraints - Horizontal grid scrolling may remain within a labeled region. Verification - Check enlarged text in agenda - Check long synthetic shift labels Deliverables - CSS changes and viewport evidence Rollout and recovery: Prefer agenda on constrained layouts if grid controls fail. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-109 — Remove nonessential motion from staffing date transitions **Chore · Low priority · Foundational** noCV practice brief v5 · CCAL-109 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify adaptive use. Depends on: CCAL-103. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Animated week slides make date navigation uncomfortable for some users. Respect reduced motion while preserving orientation. Acceptance criteria - Reduced motion skips sliding - Date heading still updates - Focus and selection remain stable Implementation constraints - Do not use animation completion as business logic. Verification - Toggle reduced-motion preference - Navigate rapidly during transition Deliverables - Motion styles and interaction case Rollout and recovery: Disable transitions globally if state depends on them. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. #### CCAL-110 — Audit staffing calendar semantics in a reproducible manual walkthrough **Chore · Medium priority · Advanced** noCV practice brief v5 · CCAL-110 · An accessible staffing calendar Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify adaptive use. Depends on: CCAL-107, CCAL-108, CCAL-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Quality 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. Automated checks pass but the team lacks a repeatable reading and editing protocol. Write and execute a bounded walkthrough. Acceptance criteria - Protocol covers agenda and grid - Keyboard outcomes are recorded - Failures include concrete reproduction steps Implementation constraints - Report tested browser and assistive tool versions, not certification. Verification - Complete one shift move - Exercise conflict and empty-week paths Deliverables - Manual audit record with unresolved findings Rollout and recovery: Reopen failed behaviors before widening the calendar pilot. Project prerequisites: Create synthetic shifts including overlaps and daylight-saving boundaries. Implement a local schedule revision adapter. Engineer value: Practice focus models and accessible alternatives for spatial interfaces. Company value: Inspect whether scheduling remains usable across input methods and failure states. 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. ## CTABLE — An accessible reporting workbench Fictional cooperative Quarry reviews synthetic service-volume reports. Build local report fixtures with empty, missing and delayed values. **Field:** Accessibility. **Suggested stack:** React, TypeScript, CSS Modules, Playwright. **Engineer value:** Practice semantic data presentation and robust interaction. **Company value:** Inspect whether reporting decisions remain possible without color or pointer use. **Delivery agreement:** Submit focused report changes with manual checks; no compliance certification is implied. ### Setup prerequisites - Create synthetic report series with explicit missing values. - Stub report loading, sorting and export responses. ### Expose report meaning Define labels and missing values. #### CTABLE-101 — Give report charts a textual trend summary **Story · Medium priority · Foundational** noCV practice brief v5 · CTABLE-101 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expose report meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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 line chart has only an image label reading Chart. Add a concise summary sourced from the displayed series. Acceptance criteria - Summary names metric and period - Missing samples are disclosed - Summary does not invent causation Implementation constraints - Compute facts from fixture data only. Verification - Summarize rising series - Summarize incomplete series Deliverables - Trend summary projection Rollout and recovery: Hide summary if it disagrees with displayed data. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-102 — Preserve table header associations in the reporting workbench **Bug · High priority · Foundational** noCV practice brief v5 · CTABLE-102 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expose report meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Sticky styling replaced table headers with generic containers. Restore native table relationships. Acceptance criteria - Column headers use correct semantics - Row labels identify rows - Sticky behavior preserves reading order Implementation constraints - Avoid ARIA overrides of native table roles. Verification - Inspect header relationships - Render grouped and empty rows Deliverables - Semantic table markup Rollout and recovery: Remove sticky styling if it breaks semantics. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-103 — Represent missing report observations distinctly from zero **Task · Medium priority · Intermediate** noCV practice brief v5 · CTABLE-103 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expose report meaning. Depends on: CTABLE-101, CTABLE-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Data engineering 20% · Accessibility 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. Missing intervals are graphed at zero and alter the apparent trend. Define equivalent chart and table representations. Acceptance criteria - Zero remains numeric - Missing values have explicit text - Chart gaps match table omissions Implementation constraints - Do not impute values within this ticket. Verification - Compare zero and missing rows - Use all-missing series Deliverables - Missing-value contract and cases Rollout and recovery: Disable chart interpolation if gaps are misrepresented. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. ### Operate report controls Keep sorting, disclosure and export accessible. #### CTABLE-104 — Expose report sorting through semantic header buttons **Story · Medium priority · Intermediate** noCV practice brief v5 · CTABLE-104 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate report controls. Depends on: CTABLE-102, CTABLE-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Column sorting works only by clicking an unlabeled header. Add named buttons and current sort direction. Acceptance criteria - Buttons identify sortable field - Current direction is exposed - Unsortable headers remain plain text Implementation constraints - Preserve native table navigation. Verification - Sort ascending then descending - Activate with keyboard Deliverables - Sort controls and keyboard cases Rollout and recovery: Restore fixed documented ordering if controls fail. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-105 — Keep report filter errors near their controls **Bug · Medium priority · Intermediate** noCV practice brief v5 · CTABLE-105 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate report controls. Depends on: CTABLE-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Invalid date ranges produce a toast that disappears before users reach the fields. Add persistent linked errors. Acceptance criteria - Error names affected range - Correction clears the message - Submitted values remain editable Implementation constraints - Do not automatically reset user dates. Verification - Submit reversed range - Correct only end date Deliverables - Date-filter errors and focus checks Rollout and recovery: Fall back to explicit apply with inline errors. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-106 — Provide a keyboard alternative to chart range brushing **Story · High priority · Advanced** noCV practice brief v5 · CTABLE-106 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate report controls. Depends on: CTABLE-101, CTABLE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Selecting a chart interval requires dragging across the plot. Add equivalent start/end interval controls. Acceptance criteria - Controls select the same range - Selection is visible in table - Out-of-range values explain limits Implementation constraints - Keep brushing optional. Verification - Select identical range both ways - Enter range outside data Deliverables - Range selector and equivalence tests Rollout and recovery: Disable brushing if it diverges from controls. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-107 — Keep report details discoverable after virtualized rows leave view **Bug · High priority · Expert** noCV practice brief v5 · CTABLE-107 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate report controls. Depends on: CTABLE-104, CTABLE-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 40% · Performance engineering 30% · Frontend 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. Expanded row details unmount during scrolling and leave focus nowhere. Bound virtualization around active interaction. Acceptance criteria - Focused details remain mounted - Collapsed rows release retained nodes - Large fixtures stay within documented DOM budget Implementation constraints - Do not pin every previously opened row forever. Verification - Scroll focused detail out of view - Collapse and verify reclamation Deliverables - Focus-aware virtualization policy Rollout and recovery: Disable virtualization for interactive details if focus is lost. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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 equivalent access Test constrained display and failure feedback. #### CTABLE-108 — Announce reporting export readiness without stealing focus **Story · Medium priority · Intermediate** noCV practice brief v5 · CTABLE-108 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify equivalent access. Depends on: CTABLE-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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 completed export opens a modal and interrupts filter editing. Expose a stable download action with a status message. Acceptance criteria - Readiness announces once - Focus stays in active control - Failure exposes retry Implementation constraints - Keep file status outside the table live region. Verification - Complete export while editing - Fail export before completion Deliverables - Export status component Rollout and recovery: Use explicit status refresh if announcements repeat. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-109 — Keep report distinctions visible in forced-color mode **Bug · Medium priority · Advanced** noCV practice brief v5 · CTABLE-109 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify equivalent access. Depends on: CTABLE-103, CTABLE-107. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Report lines and selected rows vanish under forced colors. Add structural distinctions using patterns and borders. Acceptance criteria - Series have non-color identifiers - Selected rows retain visible state - Focus outline remains discernible Implementation constraints - Honor system colors instead of forcing brand fills. Verification - Inspect forced-color rendering - Check selected row on empty refresh Deliverables - Styles and captured verification notes Rollout and recovery: Use the data table as the default constrained view. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. #### CTABLE-110 — Document report equivalence through a narrow assistive audit **Chore · Medium priority · Advanced** noCV practice brief v5 · CTABLE-110 · An accessible reporting workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify equivalent access. Depends on: CTABLE-107, CTABLE-108, CTABLE-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 50% · Quality engineering 30% · Data 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. The team cannot verify that the chart alternative carries the same decisions. Execute a defined fixture-based comparison. Acceptance criteria - Audit compares values and gaps - Keyboard sort and export are covered - Unresolved limitations remain explicit Implementation constraints - Record environment and actual observations. Verification - Find highest known interval both ways - Inspect missing data and failed export Deliverables - Audit protocol and findings Rollout and recovery: Block wider report rollout for reproducible information loss. Project prerequisites: Create synthetic report series with explicit missing values. Stub report loading, sorting and export responses. Engineer value: Practice semantic data presentation and robust interaction. Company value: Inspect whether reporting decisions remain possible without color or pointer use. 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. ## CMODAL — Accessible overlays and notifications in a team portal Fictional membership portal Juniper manages synthetic team settings. Use locally owned components and a local settings adapter. **Field:** Accessibility. **Suggested stack:** React, TypeScript, Base UI, CSS Modules. **Engineer value:** Practice focus containment, dismissal and asynchronous feedback. **Company value:** Inspect whether shared UI primitives protect users across many product flows. **Delivery agreement:** Change one owned primitive at a time and record affected portal consumers. ### Setup prerequisites - Create synthetic settings forms and destructive-action stubs. - Provide delayed success, rejection and removed-trigger cases. ### Specify overlay contracts Name dialogs and define dismissal. #### CMODAL-101 — Name team-setting dialogs from visible headings **Bug · High priority · Foundational** noCV practice brief v5 · CMODAL-101 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify overlay contracts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 80% · Frontend 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. Screen readers announce Dialog without a purpose. Connect each settings dialog to its visible heading. Acceptance criteria - Dialog has a meaningful name - Description excludes the entire form - Heading IDs remain unique Implementation constraints - Use the owned primitive's naming API. Verification - Open two dialog types - Mount repeated instances Deliverables - Dialog naming fix and checks Rollout and recovery: Revert consumer composition if names collide. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-102 — Make portal notification dismissal keyboard operable **Story · Medium priority · Foundational** noCV practice brief v5 · CMODAL-102 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify overlay contracts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Toast close icons have no accessible name and cannot receive focus. Add an explicit dismissal control. Acceptance criteria - Close has an action name - Keyboard activation dismisses - Dismissal preserves sensible focus Implementation constraints - Notifications cannot trap focus. Verification - Dismiss via keyboard - Dismiss notification whose trigger disappeared Deliverables - Dismiss control and focus cases Rollout and recovery: Keep notifications persistent if dismissal becomes unreachable. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-103 — Define when unsaved settings dialogs may close **Task · High priority · Intermediate** noCV practice brief v5 · CMODAL-103 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify overlay contracts. Depends on: CMODAL-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Accessibility 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. Escape silently discards edited settings. Add a dirty-state close contract shared by close button and outside interaction. Acceptance criteria - Clean dialogs close normally - Dirty close requests confirmation - Cancel keeps draft and focus Implementation constraints - Avoid browser-wide beforeunload for local overlay changes. Verification - Close clean dialog - Cancel dirty dismissal Deliverables - Close policy and interaction cases Rollout and recovery: Disable outside dismissal while correcting the policy. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. ### Handle nested interactions Preserve focus and pending user work. #### CMODAL-104 — Return focus when a portal dialog trigger disappears **Bug · High priority · Advanced** noCV practice brief v5 · CMODAL-104 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle nested interactions. Depends on: CMODAL-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. After deleting a row through its dialog, the original trigger no longer exists. Provide a surviving fallback target. Acceptance criteria - Existing trigger regains focus - Deleted trigger uses nearest contextual control - Failure keeps focus inside dialog Implementation constraints - Resolve fallback after committed row removal. Verification - Save without deleting trigger - Delete the trigger's row Deliverables - Focus-return resolver and cases Rollout and recovery: Keep an action-result placeholder if no valid target exists. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-105 — Keep parent settings inert while a nested confirmation is open **Bug · High priority · Advanced** noCV practice brief v5 · CMODAL-105 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle nested interactions. Depends on: CMODAL-103, CMODAL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Tab reaches the parent form behind a confirmation dialog. Compose modal ownership across one nested level. Acceptance criteria - Tab stays in active confirmation - Escape closes only top layer - Parent state survives confirmation cancellation Implementation constraints - Use the accessible primitive rather than manual document-wide traps. Verification - Cycle Tab through nested dialog - Cancel then resume parent form Deliverables - Nested-dialog composition tests Rollout and recovery: Replace nested confirmation with an inline confirmation step. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-106 — Prevent menu dismissal from swallowing a settings action **Bug · Medium priority · Intermediate** noCV practice brief v5 · CMODAL-106 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle nested interactions. Depends on: CMODAL-104. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · Accessibility 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. Choosing Rename closes the menu before its dialog receives the intended row. Make the action payload stable through dismissal. Acceptance criteria - Rename targets selected row - Keyboard and pointer match - Removed rows show unavailable state Implementation constraints - Capture immutable row identity at activation. Verification - Rename from keyboard menu - Remove row before dialog load Deliverables - Menu-to-dialog handoff Rollout and recovery: Disable the menu action if identity is unresolved. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-107 — Keep pending portal dialog saves cancellable without duplicate writes **Story · High priority · Expert** noCV practice brief v5 · CMODAL-107 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle nested interactions. Depends on: CMODAL-105, CMODAL-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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 slow save invites repeated clicks and users cannot tell whether closing cancels the write. Specify operation and view lifecycles separately. Acceptance criteria - One pending write per revision - Closing does not claim server cancellation - Reopen reconciles operation status Implementation constraints - Adapter cancellation may be advisory only. Verification - Close after accepted save - Timeout then reopen same operation Deliverables - Pending-operation model and races Rollout and recovery: Disable closing during unresolved operations with an explicit explanation. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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 feedback durable Support zoom and verify reusable behavior. #### CMODAL-108 — Reflow portal dialogs without hiding their confirmation actions **Bug · Medium priority · Intermediate** noCV practice brief v5 · CMODAL-108 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make feedback durable. Depends on: CMODAL-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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. Magnified text pushes Save below a fixed-height dialog with no reachable scroll path. Reflow the dialog shell. Acceptance criteria - Content scrolls inside labeled region - Actions stay reachable - Document background remains inert Implementation constraints - Avoid fixed pixel heights for text containers. Verification - Check 200 percent text sizing - Use long error descriptions Deliverables - Responsive dialog styles Rollout and recovery: Use full-page forms if actions cannot remain reachable. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-109 — Make critical portal notifications persistent until acknowledged **Story · Medium priority · Intermediate** noCV practice brief v5 · CMODAL-109 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make feedback durable. Depends on: CMODAL-102, CMODAL-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Frontend 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 failed permission change disappears after four seconds. Separate persistent actionable failures from transient informational status. Acceptance criteria - Failed changes remain visible - Acknowledgement is explicit - Repeated same failure coalesces without losing action Implementation constraints - Do not use urgency announcements for every toast. Verification - Reject permission change - Repeat rejection and inspect coalescing Deliverables - Notification priority contract Rollout and recovery: Disable auto-dismiss for all actionable messages if classification fails. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. #### CMODAL-110 — Audit shared portal overlays across input and theme settings **Chore · Medium priority · Advanced** noCV practice brief v5 · CMODAL-110 · Accessible overlays and notifications in a team portal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make feedback durable. Depends on: CMODAL-108, CMODAL-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Quality 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. Primitive fixes may regress different consumers. Run a bounded matrix on settings, rename and deletion flows. Acceptance criteria - Matrix covers keyboard and pointer - Light dark and forced colors are recorded - Failures include minimal reproduction Implementation constraints - Report actual local observations and remaining gaps. Verification - Complete rename flow - Exercise rejected delete in constrained display Deliverables - Overlay audit record Rollout and recovery: Keep affected consumer disabled until its blocking regression is fixed. Project prerequisites: Create synthetic settings forms and destructive-action stubs. Provide delayed success, rejection and removed-trigger cases. Engineer value: Practice focus containment, dismissal and asynchronous feedback. Company value: Inspect whether shared UI primitives protect users across many product flows. 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. ## CPRES — Presence that remains honest during disconnection Fictional document team Pine shows collaboration presence for synthetic accounts. Build a loopback WebSocket server and injected clocks; no message content or activity surveillance is required. **Field:** Real-time systems. **Suggested stack:** TypeScript, WebSocket, Redis adapter, Vitest. **Engineer value:** Practice ephemeral state, ordering and reconnect semantics. **Company value:** Inspect whether online indicators avoid stale or unauthorized claims. **Delivery agreement:** Presence means an active connection lease only; it does not infer attention or productivity. ### Setup prerequisites - Create synthetic memberships and session identifiers. - Implement controllable sockets and an in-memory TTL adapter. ### Define presence meaning Specify scopes and expiry. #### CPRES-101 — Define online presence as an unexpired connection lease **Task · Medium priority · Foundational** noCV practice brief v5 · CPRES-101 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define presence meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 green dot remains after the browser closes. Replace the permanent flag with explicitly expiring presence. Acceptance criteria - Active lease shows connected - Expiry removes connected state - UI explains connection meaning Implementation constraints - Do not infer human attention from a socket. Verification - Advance clock before expiry - Advance beyond expiry without disconnect Deliverables - Lease contract and clock cases Rollout and recovery: Hide presence if lease freshness cannot be established. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-102 — Validate presence room identifiers before subscribing **Bug · High priority · Foundational** noCV practice brief v5 · CPRES-102 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define presence meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Real-time systems 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. Malformed room names reach the broker and create unbounded keys. Parse a bounded typed room identifier. Acceptance criteria - Valid room IDs subscribe - Malformed IDs fail before broker access - Error omits raw oversized input Implementation constraints - Room parsing does not replace membership checks. Verification - Subscribe valid fixture room - Send oversized room identifier Deliverables - Room parser and rejection tests Rollout and recovery: Reject new subscriptions if parsing fails. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-103 — Scope presence membership checks to each room subscription **Task · High priority · Intermediate** noCV practice brief v5 · CPRES-103 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define presence meaning. Depends on: CPRES-101, CPRES-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Real-time 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. Authentication alone currently permits joining any document room. Require current membership in the room boundary. Acceptance criteria - Member can join - Foreign member is denied - Revoked membership cannot renew lease Implementation constraints - Recheck authority at renewal using local stub. Verification - Join authorized room - Revoke membership before renewal Deliverables - Subscription authorization and denial cases Rollout and recovery: Stop renewals while membership adapter is unavailable. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. ### Distribute state safely Handle identity and reconnect races. #### CPRES-104 — Count multiple presence connections without duplicating people **Story · Medium priority · Intermediate** noCV practice brief v5 · CPRES-104 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute state safely. Depends on: CPRES-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 70% · Data 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. Two tabs display the same teammate twice. Aggregate active connection leases under a scoped synthetic account. Acceptance criteria - One person entry per room - Closing one tab preserves other lease - Last expiry removes person Implementation constraints - Do not merge identities across organizations. Verification - Open two tabs - Expire last connection Deliverables - Presence aggregation and cases Rollout and recovery: Display connection counts only if person aggregation is incorrect. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-105 — Reject stale presence heartbeats after reconnect **Bug · High priority · Advanced** noCV practice brief v5 · CPRES-105 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute state safely. Depends on: CPRES-103, CPRES-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Real-time systems 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. Delayed heartbeat from a replaced socket prolongs a dead session. Bind renewal to session generation. Acceptance criteria - New generation supersedes old - Old heartbeat cannot renew - Current heartbeat extends its own lease Implementation constraints - Generation changes must be atomic in the adapter. Verification - Renew current session - Deliver old heartbeat after reconnect Deliverables - Generation guard and race tests Rollout and recovery: Close superseded sessions and require fresh joins. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-106 — Send a presence snapshot before incremental updates **Story · Medium priority · Advanced** noCV practice brief v5 · CPRES-106 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute state safely. Depends on: CPRES-104, CPRES-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 50% · Distributed systems 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 new client applies deltas to an empty list and misses existing teammates. Add snapshot sequencing at subscription. Acceptance criteria - Snapshot establishes sequence - Later deltas follow its watermark - Detected gaps trigger resnapshot Implementation constraints - Buffer during snapshot only within a documented limit. Verification - Join populated room - Drop one delta and detect gap Deliverables - Snapshot handshake and gap cases Rollout and recovery: Resend full snapshots while delta path is repaired. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-107 — Expire presence independently of disconnect delivery **Bug · High priority · Expert** noCV practice brief v5 · CPRES-107 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Distribute state safely. Depends on: CPRES-101, CPRES-105, CPRES-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Real-time systems 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 server restart loses disconnect events and rooms retain ghosts. Make lease expiry authoritative across process recovery. Acceptance criteria - Restart cannot preserve expired entries - Cleanup repeats safely - Concurrent renewal cannot delete fresh lease Implementation constraints - Compare stored lease identity before removal. Verification - Restart with expired leases - Renew during cleanup Deliverables - Expiry reconciliation and interleaving cases Rollout and recovery: Disable cleanup writes if lease identity cannot be checked. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. ### Bound operating behavior Limit work and diagnose stale indicators. #### CPRES-108 — Cap presence fan-out per room without silently losing state **Task · Medium priority · Advanced** noCV practice brief v5 · CPRES-108 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound operating behavior. Depends on: CPRES-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Real-time systems 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 synthetic busy room causes unbounded socket buffers. Introduce a per-client queue cap and resync fallback. Acceptance criteria - Buffer count is bounded - Overflow requests resnapshot - Healthy peers continue receiving Implementation constraints - Do not drop arbitrary deltas and claim synchronization. Verification - Exercise normal fan-out - Stall one client to capacity Deliverables - Bounded broadcaster and overflow cases Rollout and recovery: Disconnect slow clients with a clear resync reason. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-109 — Distinguish disconnected and stale presence in the client **Story · Medium priority · Intermediate** noCV practice brief v5 · CPRES-109 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound operating behavior. Depends on: CPRES-107, CPRES-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Real-time systems 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. Network loss freezes green dots and suggests teammates remain connected. Mark stale state during transport uncertainty. Acceptance criteria - Local disconnect marks snapshot stale - Reconnect waits for fresh snapshot - Stale entries are not labeled online Implementation constraints - Preserve names only while room access remains valid. Verification - Disconnect then reconnect - Lose authorization during reconnect Deliverables - Presence freshness UI Rollout and recovery: Hide entries during uncertainty if freshness labeling fails. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. #### CPRES-110 — Expose presence lease diagnostics without activity histories **Chore · Low priority · Intermediate** noCV practice brief v5 · CPRES-110 · Presence that remains honest during disconnection Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound operating behavior. Depends on: CPRES-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Site reliability 30% · Real-time 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. Operators need to locate ghost indicators without collecting behavioral timelines. Add current aggregate lease counters. Acceptance criteria - Counters include active and expired totals - No per-person activity history is stored - Room labels use bounded safe identifiers Implementation constraints - Use synthetic rooms in samples. Verification - Inspect healthy counters - Create expired lease and verify aggregation Deliverables - Diagnostic contract and samples Rollout and recovery: Disable diagnostics if person-level histories appear. Project prerequisites: Create synthetic memberships and session identifiers. Implement controllable sockets and an in-memory TTL adapter. Engineer value: Practice ephemeral state, ordering and reconnect semantics. Company value: Inspect whether online indicators avoid stale or unauthorized claims. 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. ## CLIVE — A live incident board with recoverable updates Fictional internal status team Harbor updates operational incident cards. Build a local event log and SSE adapter; incidents and service names are invented. **Field:** Real-time systems. **Suggested stack:** TypeScript, Server-sent events, PostgreSQL adapter, React. **Engineer value:** Practice event projection, replay and freshness communication. **Company value:** Inspect whether dashboards remain trustworthy through network interruptions. **Delivery agreement:** Use local fixtures; this board is not an emergency-response system. ### Setup prerequisites - Create synthetic incident revisions and a local append-only event stub. - Provide controllable disconnect, replay and retention fixtures. ### Specify live events Define event identity and projection. #### CLIVE-101 — Give live incident events stable opaque identifiers **Task · Medium priority · Foundational** noCV practice brief v5 · CLIVE-101 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify live events. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Data 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. Reconnecting clients cannot distinguish replay from new events because IDs change on delivery. Persist event identity. Acceptance criteria - Replay preserves IDs - Distinct events have unique IDs - IDs contain no incident text Implementation constraints - Delivery attempts must not mint new event IDs. Verification - Replay one event twice - Append two equal payloads as distinct events Deliverables - Event identity contract Rollout and recovery: Disable replay until stable IDs exist. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-102 — Render incident status text independently of severity color **Bug · Medium priority · Foundational** noCV practice brief v5 · CLIVE-102 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify live events. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 70% · Frontend 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. Color-only status blocks hide the distinction between investigating and monitoring. Add visible status labels. Acceptance criteria - Every status has text - Unknown status renders explicit fallback - Color is optional reinforcement Implementation constraints - Do not infer severity from color tokens. Verification - Render all fixture statuses - Render unsupported status Deliverables - Status presenter and cases Rollout and recovery: Use text-only presentation if color mapping is wrong. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-103 — Apply live incident updates only to newer revisions **Bug · High priority · Intermediate** noCV practice brief v5 · CLIVE-103 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify live events. Depends on: CLIVE-101, CLIVE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Distributed systems 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 delayed update reopens a resolved incident. Compare revisions before changing the projected card. Acceptance criteria - Newer revisions apply - Equal replay is harmless - Older revisions cannot overwrite Implementation constraints - Revision scope is per incident. Verification - Apply revisions in order - Deliver earlier revision after resolution Deliverables - Revision projector and ordering cases Rollout and recovery: Refresh full cards if ordering cannot be established. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. ### Recover transport gaps Make replay and mutation coherent. #### CLIVE-104 — Resume incident streams from the last applied event **Story · High priority · Advanced** noCV practice brief v5 · CLIVE-104 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover transport gaps. Depends on: CLIVE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 60% · Networking 20% · 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. A reconnect misses changes made during disconnection. Send the last applied event ID and replay retained updates. Acceptance criteria - Resume begins after acknowledged ID - Replay preserves event order - Cursor advances after successful projection Implementation constraints - Received is not equivalent to applied. Verification - Reconnect after two missed events - Fail projection before cursor advancement Deliverables - Resume coordinator and replay cases Rollout and recovery: Force snapshot reload instead of uncertain replay. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-105 — Return a reset contract when incident replay history expired **Task · High priority · Intermediate** noCV practice brief v5 · CLIVE-105 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover transport gaps. Depends on: CLIVE-104. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Real-time systems 30% · Storage 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. Old clients request a cursor outside retention and appear current with missing changes. Make replay expiry explicit. Acceptance criteria - Expired cursor requests fresh snapshot - Client clears old cursor - Reset has an observable reason Implementation constraints - Do not silently start at the newest event. Verification - Resume retained cursor - Resume expired cursor Deliverables - Replay reset contract Rollout and recovery: Require full reload if reset handling fails. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-106 — Join incident snapshots and streams at one watermark **Bug · High priority · Expert** noCV practice brief v5 · CLIVE-106 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover transport gaps. Depends on: CLIVE-104, CLIVE-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Real-time systems 30% · Database 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. An update between snapshot fetch and stream connect disappears. Establish a snapshot watermark for replay. Acceptance criteria - Snapshot declares its watermark - Stream replays later events - Boundary duplicates remain harmless Implementation constraints - Define transaction or adapter ordering explicitly. Verification - Update before snapshot - Update between snapshot and subscription Deliverables - Snapshot-stream handoff and race cases Rollout and recovery: Use periodic full snapshots while handoff is repaired. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-107 — Reconcile local incident edits with streamed acknowledgements **Story · Medium priority · Advanced** noCV practice brief v5 · CLIVE-107 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover transport gaps. Depends on: CLIVE-103, CLIVE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Real-time systems 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. Saving an incident and receiving its stream event produces duplicate activity rows. Correlate the committed operation. Acceptance criteria - One committed activity row appears - Rejected edits remain actionable - Unrelated remote events still apply Implementation constraints - Do not suppress all events while saving. Verification - Save and receive acknowledgement - Reject save while another user updates Deliverables - Mutation-stream reconciliation Rollout and recovery: Remove optimistic activity until correlation is correct. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. ### Operate bounded streams Handle slow clients and explain freshness. #### CLIVE-108 — Bound each incident subscriber buffer **Task · Medium priority · Advanced** noCV practice brief v5 · CLIVE-108 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate bounded streams. Depends on: CLIVE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Real-time systems 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 status screen accumulates unbounded events. Cap its queue and require reset when it cannot keep up. Acceptance criteria - Queue respects configured bound - Overflow terminates with reset guidance - Other subscribers remain independent Implementation constraints - Never silently discard ordered events. Verification - Stream to healthy client - Stall client beyond queue capacity Deliverables - Subscriber backpressure policy Rollout and recovery: Disconnect slow subscribers and require fresh snapshots. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-109 — Show incident-board freshness independently from incident status **Story · Medium priority · Intermediate** noCV practice brief v5 · CLIVE-109 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate bounded streams. Depends on: CLIVE-105, CLIVE-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Real-time systems 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 disconnected screen says All systems normal because incident cards retain their last values. Add transport freshness. Acceptance criteria - Last applied time is visible - Disconnect shows stale state - Reconnect clears stale only after catch-up Implementation constraints - Use synthetic clock values in tests. Verification - Disconnect resolved board - Reconnect with missed open incident Deliverables - Freshness banner and recovery cases Rollout and recovery: Hide aggregate healthy claim while freshness is uncertain. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. #### CLIVE-110 — Record incident-stream recovery reasons without payload logging **Chore · Low priority · Intermediate** noCV practice brief v5 · CLIVE-110 · A live incident board with recoverable updates Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate bounded streams. Depends on: CLIVE-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Real-time systems 20% · 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. Investigating replay failures currently logs full incident descriptions. Add an allowlisted recovery event schema. Acceptance criteria - Includes reset reason and cursor category - Omits descriptions and author names - Malformed IDs are bounded Implementation constraints - Correlation identifiers cannot carry user text. Verification - Capture successful resume - Reject secret-like malformed cursor Deliverables - Recovery diagnostics and exclusion checks Rollout and recovery: Disable stream logging if payload fields appear. Project prerequisites: Create synthetic incident revisions and a local append-only event stub. Provide controllable disconnect, replay and retention fixtures. Engineer value: Practice event projection, replay and freshness communication. Company value: Inspect whether dashboards remain trustworthy through network interruptions. 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. ## CAUCT — A realtime reservation window for workshop seats Fictional craft studio Maple offers workshop seats. Implement synthetic reservations without payments or real booking services. **Field:** Real-time systems. **Suggested stack:** TypeScript, PostgreSQL adapter, WebSocket, Vitest. **Engineer value:** Practice contention, expiry and truthful realtime projections. **Company value:** Inspect whether concurrent clients avoid overselling and recover uncertain results. **Delivery agreement:** Booking simulation only; payment and production capacity planning are excluded. ### Setup prerequisites - Create synthetic workshops with small capacities. - Implement local transactional hold storage and injected clocks. ### Define hold rules Specify capacity and ownership. #### CAUCT-101 — Specify workshop seat counts without negative availability **Task · High priority · Foundational** noCV practice brief v5 · CAUCT-101 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define hold rules. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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 prototype subtracts all historical holds and displays negative seats. Project availability from current authoritative states. Acceptance criteria - Only active holds consume seats - Confirmed reservations consume seats - Expired holds do not consume seats Implementation constraints - Define active using injected time. Verification - Project mixed states - Use boundary expiry instant Deliverables - Availability projection and cases Rollout and recovery: Hide counts if state cannot be reconciled. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-102 — Validate workshop hold quantities before storage **Bug · Medium priority · Foundational** noCV practice brief v5 · CAUCT-102 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define hold rules. Depends on: CAUCT-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. A zero-seat request creates a hold and a fractional request breaks counts. Enforce bounded integer quantities. Acceptance criteria - Positive integers within limit pass - Zero and fractions fail - Invalid input creates no record Implementation constraints - Keep limits explicit in the local contract. Verification - Hold two seats - Reject zero and oversized quantities Deliverables - Quantity validator and failure cases Rollout and recovery: Reject new holds if validation is unavailable. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-103 — Create workshop holds atomically under contention **Task · High priority · Advanced** noCV practice brief v5 · CAUCT-103 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define hold rules. Depends on: CAUCT-101, CAUCT-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Two clients see one available seat and both reserve it. Serialize capacity consumption at storage. Acceptance criteria - At most capacity is consumed - Loser receives unavailable result - No partial hold record remains Implementation constraints - A browser availability check is advisory only. Verification - Create uncontested hold - Race two requests for one seat Deliverables - Transactional hold operation Rollout and recovery: Pause hold creation if capacity invariant fails. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. ### Resolve concurrent changes Handle expiry and confirmation atomically. #### CAUCT-104 — Scope workshop hold lookup and cancellation to its owner **Bug · High priority · Intermediate** noCV practice brief v5 · CAUCT-104 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve concurrent changes. Depends on: CAUCT-103. Difficulty: Intermediate. Estimated focused work: 135 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. Knowing a hold ID lets another user cancel it. Enforce owner scope in the repository boundary. Acceptance criteria - Owner reads and cancels - Foreign owner is denied - Denied calls do not disclose hold details Implementation constraints - Synthetic identities remain required in all adapter calls. Verification - Cancel own hold - Cancel another account's hold Deliverables - Scoped hold repository and denial tests Rollout and recovery: Disable cancellation if scope cannot be established. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-105 — Confirm workshop holds only before the expiry boundary **Task · High priority · Advanced** noCV practice brief v5 · CAUCT-105 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve concurrent changes. Depends on: CAUCT-103, CAUCT-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 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. Confirm and expiry cleanup race, creating reservations from expired holds. Add an atomic transition with one time rule. Acceptance criteria - Eligible hold confirms once - Expired hold cannot confirm - Cleanup cannot remove confirmed reservation Implementation constraints - Compare time inside the authoritative transition. Verification - Confirm before boundary - Race confirm with expiry cleanup Deliverables - Confirmation transition and boundary cases Rollout and recovery: Pause confirmation if atomicity fails. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-106 — Replay workshop hold requests with the same idempotency key **Story · Medium priority · Intermediate** noCV practice brief v5 · CAUCT-106 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve concurrent changes. Depends on: CAUCT-103. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Database engineering 30% · 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. Timeout retry creates two holds for one user's click. Bind the operation key to the normalized request. Acceptance criteria - Same key and payload returns same hold - Different payload conflicts - Keys remain scoped to owner Implementation constraints - Store idempotency result with the hold transaction. Verification - Replay accepted request - Reuse key with different quantity Deliverables - Idempotent create contract Rollout and recovery: Require status lookup while replay support is repaired. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-107 — Publish workshop availability changes only after commit **Bug · High priority · Expert** noCV practice brief v5 · CAUCT-107 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve concurrent changes. Depends on: CAUCT-105, CAUCT-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 30% · Real-time 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. Clients see seats disappear for a transaction that later rolls back. Publish committed availability through an outbox. Acceptance criteria - Committed changes enqueue events - Rollback emits no event - Replay cannot double-apply availability Implementation constraints - Event consumers receive versions, not count deltas alone. Verification - Commit hold and publish - Roll back after preparing event Deliverables - Outbox handoff and rollback cases Rollout and recovery: Stop live updates and serve authoritative snapshots. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. ### Synchronize the audience Keep availability and recovery bounded. #### CAUCT-108 — Rebuild workshop availability after a missed realtime update **Story · High priority · Advanced** noCV practice brief v5 · CAUCT-108 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize the audience. Depends on: CAUCT-107. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Real-time systems 50% · Distributed systems 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. Dropped socket messages leave the workshop full after holds expire. Detect version gaps and refresh a snapshot. Acceptance criteria - Versions advance monotonically - Gap triggers resync - Stale events cannot reduce version Implementation constraints - Snapshot and event versions share one scope. Verification - Apply contiguous updates - Skip one version and reconnect Deliverables - Versioned client projection Rollout and recovery: Poll snapshots if delta recovery fails. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-109 — Display workshop hold countdown as advisory **Bug · Medium priority · Intermediate** noCV practice brief v5 · CAUCT-109 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize the audience. Depends on: CAUCT-105, CAUCT-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Real-time 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. A client clock skew shows time remaining after the server expired the hold. Label countdown and reconcile server refusal. Acceptance criteria - Countdown uses server offset estimate - Zero disables local confirmation - Server expiry still wins Implementation constraints - A visual timer cannot authorize a reservation. Verification - Use skewed client clock - Confirm after authoritative expiry Deliverables - Countdown presenter and skew cases Rollout and recovery: Replace countdown with expiry timestamp if offset is unreliable. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. #### CAUCT-110 — Bound workshop hold cleanup batches and expose progress **Chore · Medium priority · Intermediate** noCV practice brief v5 · CAUCT-110 · A realtime reservation window for workshop seats Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize the audience. Depends on: CAUCT-107, CAUCT-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Data engineering 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. Cleanup scans every historical hold on each tick. Add bounded cursor batches with repeat-safe transitions. Acceptance criteria - Each batch has fixed limit - Concurrent confirms are preserved - Restart resumes without skipping eligible rows Implementation constraints - Use indexed expiry selection in the adapter design. Verification - Clean several batches - Confirm a selected hold concurrently Deliverables - Cleanup worker contract and restart cases Rollout and recovery: Pause cleanup and rely on read-time expiry until repaired. Project prerequisites: Create synthetic workshops with small capacities. Implement local transactional hold storage and injected clocks. Engineer value: Practice contention, expiry and truthful realtime projections. Company value: Inspect whether concurrent clients avoid overselling and recover uncertain results. 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. ## COBJS — Resumable object uploads with verified completion Fictional document archive Fern stores synthetic byte objects. Use a local S3-compatible adapter or deterministic in-memory provider; no cloud credentials are needed. **Field:** Storage systems. **Suggested stack:** TypeScript, S3-compatible adapter, PostgreSQL adapter, Vitest. **Engineer value:** Practice object lifecycle, retry semantics and integrity verification. **Company value:** Inspect whether uploads avoid corruption, orphan cost and tenant crossover. **Delivery agreement:** Submit bounded coordinator changes; external cloud rollout is separate. ### Setup prerequisites - Generate small deterministic byte fixtures. - Implement local multipart provider responses including timeout and missing parts. ### Define upload ownership Specify keys, parts and quotas. #### COBJS-101 — Normalize object names without treating them as filesystem paths **Task · Medium priority · Foundational** noCV practice brief v5 · COBJS-101 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define upload ownership. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Storage systems 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 upload API accepts ambiguous separators and empty names. Define an opaque object-name contract. Acceptance criteria - Valid names retain documented characters - Empty and oversized names fail - Normalization collisions are rejected Implementation constraints - Object keys are not local file paths. Verification - Store valid unicode name - Reject colliding normalized names Deliverables - Name validator and examples Rollout and recovery: Reject new ambiguous names while keeping existing reads. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-102 — Bind multipart upload sessions to organization and object identity **Bug · High priority · Intermediate** noCV practice brief v5 · COBJS-102 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define upload ownership. Depends on: COBJS-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Storage systems 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 session ID can currently be reused against a different object. Require its original scope on every part operation. Acceptance criteria - Matching owner uploads - Foreign organization is denied - Changed object identity is rejected Implementation constraints - Enforce scope in the repository/provider boundary. Verification - Upload own part - Reuse session against foreign object Deliverables - Scoped session adapter and denial cases Rollout and recovery: Pause multipart writes if scope is uncertain. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-103 — Reject multipart uploads exceeding declared size limits **Task · High priority · Foundational** noCV practice brief v5 · COBJS-103 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define upload ownership. Depends on: COBJS-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · API design 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. The coordinator accepts an unlimited part list. Bound declared object size and per-session part count. Acceptance criteria - Valid declared sizes pass - Part count has explicit maximum - Rejected admission creates no provider session Implementation constraints - Limits must be checked before remote allocation. Verification - Admit small fixture - Reject oversized declaration Deliverables - Admission policy and allocation checks Rollout and recovery: Lower admission to a documented safe cap if accounting fails. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. ### Complete reliably Handle retries and integrity boundaries. #### COBJS-104 — Retry the same multipart part without creating contradictory receipts **Bug · High priority · Advanced** noCV practice brief v5 · COBJS-104 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete reliably. Depends on: COBJS-102, COBJS-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Distributed systems 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 timeout after part acceptance leads to duplicate receipts with different checksums. Bind retries to part number and digest. Acceptance criteria - Same bytes return stable receipt - Different bytes require explicit replacement - Uncertain responses reconcile with provider state Implementation constraints - Provider ETag is opaque unless contract says otherwise. Verification - Retry identical part - Retry changed bytes under same operation Deliverables - Part-retry coordinator and cases Rollout and recovery: Stop retries and expose reconciliation status. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-105 — Validate ordered multipart completion against acknowledged parts **Task · High priority · Advanced** noCV practice brief v5 · COBJS-105 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete reliably. Depends on: COBJS-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Completion silently omits a middle part and produces a shorter object. Check the requested manifest before finalization. Acceptance criteria - Required part numbers are contiguous - Receipts match acknowledged digests - Missing parts prevent completion Implementation constraints - Define final-part size exception explicitly. Verification - Complete ordered fixture - Omit or duplicate middle part Deliverables - Completion validator and negative cases Rollout and recovery: Disable completion until manifest validation recovers. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-106 — Verify completed object content before marking it available **Story · High priority · Advanced** noCV practice brief v5 · COBJS-106 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete reliably. Depends on: COBJS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · 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. Provider completion succeeds but the assembled bytes differ from the expected digest. Introduce a verification state. Acceptance criteria - Available requires digest agreement - Mismatch quarantines the object - Verification retries do not republish Implementation constraints - Use bounded streaming hashing, not full-memory buffering. Verification - Verify matching bytes - Flip one completed byte Deliverables - Post-completion verifier and corruption cases Rollout and recovery: Keep newly completed objects unavailable if verification fails. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-107 — Recover a timeout between multipart finalization and metadata commit **Bug · High priority · Expert** noCV practice brief v5 · COBJS-107 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Complete reliably. Depends on: COBJS-105, COBJS-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Distributed systems 30% · Database 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 crash after provider completion leaves the session looking incomplete. Reconcile provider outcome without creating another object. Acceptance criteria - Recovery locates the finalized identity - Metadata transition repeats safely - Ambiguous provider state stays unresolved Implementation constraints - Persist the completion operation before dispatch. Verification - Crash after finalization - Return inconclusive provider lookup Deliverables - Completion journal and crash schedule Rollout and recovery: Pause automatic completion recovery and retain session metadata. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. ### Recover abandoned work Reclaim resources and inspect outcomes. #### COBJS-108 — Abort expired multipart sessions without touching completed objects **Chore · Medium priority · Intermediate** noCV practice brief v5 · COBJS-108 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover abandoned work. Depends on: COBJS-107. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Abandoned sessions retain billable parts. Add expiry cleanup with a guarded session transition. Acceptance criteria - Only expired open sessions abort - Completed objects remain readable - Repeated abort is harmless Implementation constraints - Compare session state immediately before provider action. Verification - Clean abandoned fixture - Race cleanup with completion Deliverables - Session cleanup and race case Rollout and recovery: Disable cleanup if finalization state is uncertain. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-109 — Expose multipart upload progress from acknowledged bytes **Story · Medium priority · Intermediate** noCV practice brief v5 · COBJS-109 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover abandoned work. Depends on: COBJS-104, COBJS-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Storage systems 30% · 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. Progress reaches 100 percent before the provider accepts the final part. Count acknowledged bytes separately from verification state. Acceptance criteria - Progress uses accepted parts - Completion remains pending verification - Retransmission does not double-count Implementation constraints - Do not treat socket bytes sent as durable storage. Verification - Upload three parts - Timeout accepted part and reconcile Deliverables - Progress projection and cases Rollout and recovery: Display state-only progress if byte accounting diverges. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. #### COBJS-110 — Export multipart failure diagnostics without signed URLs **Chore · Low priority · Intermediate** noCV practice brief v5 · COBJS-110 · Resumable object uploads with verified completion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover abandoned work. Depends on: COBJS-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 30% · Storage 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. Support dumps provider receipts containing temporary access URLs. Add an allowlisted diagnostic projection. Acceptance criteria - Includes operation and part counts - Omits signatures and object content - Errors use bounded categories Implementation constraints - Signed URLs are bearer capabilities. Verification - Export failed session - Inject signed URL in provider error Deliverables - Diagnostic schema and redaction checks Rollout and recovery: Disable exports if bearer data appears. Project prerequisites: Generate small deterministic byte fixtures. Implement local multipart provider responses including timeout and missing parts. Engineer value: Practice object lifecycle, retry semantics and integrity verification. Company value: Inspect whether uploads avoid corruption, orphan cost and tenant crossover. 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. ## CBLOB — Reference-aware blob retention and deletion Fictional archive Moss deduplicates generated attachments across documents within each organization. Use local files and transactional metadata stubs. **Field:** Storage systems. **Suggested stack:** TypeScript, SQLite, Filesystem adapter, Vitest. **Engineer value:** Practice reclamation races and explicit data-lifecycle guarantees. **Company value:** Inspect whether storage cleanup avoids broken references and hidden retention. **Delivery agreement:** Operate only on a dedicated local fixture directory; no user folders are targeted. ### Setup prerequisites - Generate duplicate and unique local byte fixtures. - Create synthetic document references across two organizations. ### Model blob references Separate logical use from physical bytes. #### CBLOB-101 — Separate attachment display names from blob identities **Task · Medium priority · Foundational** noCV practice brief v5 · CBLOB-101 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model blob references. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Renaming an attachment currently moves its physical file and breaks another reference. Store display names on references. Acceptance criteria - Rename changes only reference metadata - Blob identity stays stable - Other references keep their names Implementation constraints - Content identity cannot depend on a user-facing filename. Verification - Rename shared attachment - Fail metadata write and inspect file identity Deliverables - Reference schema and rename cases Rollout and recovery: Disable rename if it touches physical blobs. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-102 — Scope blob deduplication to the owning organization **Bug · High priority · Intermediate** noCV practice brief v5 · CBLOB-102 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model blob references. Depends on: CBLOB-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Security 40% · Storage 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. Equal bytes across organizations share observable lookup results. Restrict deduplication to the tenant boundary. Acceptance criteria - Same-tenant duplicates reuse safely - Foreign existence is not disclosed - All reference reads include tenant scope Implementation constraints - Digest equality is not authorization. Verification - Deduplicate own fixtures - Probe matching foreign digest Deliverables - Scoped blob lookup and denial cases Rollout and recovery: Disable deduplication if scope isolation fails. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-103 — Reject references to incomplete synthetic blobs **Task · High priority · Foundational** noCV practice brief v5 · CBLOB-103 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model blob references. Depends on: CBLOB-101, CBLOB-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Database 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. Documents can attach blobs before upload verification ends. Require available status before creating a reference. Acceptance criteria - Available blob can attach - Incomplete blob cannot attach - Denied attachment creates no reference Implementation constraints - Status check and reference insertion share a transaction boundary. Verification - Attach verified fixture - Race verification failure with attach Deliverables - Attachment admission and cases Rollout and recovery: Pause attachments when availability cannot be established. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. ### Guard reclamation Handle races and failures safely. #### CBLOB-104 — Tombstone unreferenced blobs before physical deletion **Story · High priority · Advanced** noCV practice brief v5 · CBLOB-104 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard reclamation. Depends on: CBLOB-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Cleanup deletes bytes immediately when count reaches zero, leaving no recoverable decision record. Add a pending-deletion state. Acceptance criteria - Zero references create tombstone - Referenced blobs remain available - Tombstone records eligibility time Implementation constraints - Tombstones describe metadata, not proof of physical erasure. Verification - Remove final reference - Remove one of two references Deliverables - Tombstone transition and cases Rollout and recovery: Pause physical deletion while retaining tombstones. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-105 — Prevent a new blob reference racing with reclamation **Bug · High priority · Expert** noCV practice brief v5 · CBLOB-105 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard reclamation. Depends on: CBLOB-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Storage systems 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 document attaches a blob while cleanup deletes its file. Coordinate reference admission and deletion eligibility. Acceptance criteria - New reference either cancels eligibility or fails explicitly - Deletion cannot remove newly referenced bytes - Retried admission is safe Implementation constraints - Choose and document one atomic state protocol. Verification - Attach before claim - Race attachment against deletion claim Deliverables - Reclamation protocol and interleaving tests Rollout and recovery: Disable reclamation if the mutual-exclusion invariant fails. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-106 — Record physical blob deletion failures without claiming completion **Task · High priority · Intermediate** noCV practice brief v5 · CBLOB-106 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard reclamation. Depends on: CBLOB-104, CBLOB-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Permission errors are swallowed and metadata says Deleted while bytes remain. Persist retryable failure state. Acceptance criteria - Successful deletion records acknowledgement - Failure remains pending - Already absent file is idempotent success Implementation constraints - Do not log attachment contents or paths outside fixture scope. Verification - Delete fixture - Inject permission failure Deliverables - Deletion result handling and cases Rollout and recovery: Pause retries on repeated provider faults. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-107 — Reconcile blob metadata after a crash during deletion **Bug · High priority · Advanced** noCV practice brief v5 · CBLOB-107 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard reclamation. Depends on: CBLOB-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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 process dies after file removal but before metadata commit. Recovery must distinguish absent bytes from an untouched blob. Acceptance criteria - Missing claimed blob completes metadata - Existing claimed blob retries safely - Unclaimed blob is never deleted Implementation constraints - Recovery requires durable deletion claim identity. Verification - Crash after file removal - Restart with stale unrelated claim Deliverables - Deletion reconciliation and restart cases Rollout and recovery: Stop automatic recovery if claims cannot be verified. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. ### Operate retention Bound scanning and verify recovery. #### CBLOB-108 — Bound blob reclamation scans by eligibility cursor **Chore · Medium priority · Intermediate** noCV practice brief v5 · CBLOB-108 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate retention. Depends on: CBLOB-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Performance engineering 30% · Storage 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. The sweeper repeatedly scans the full blob table. Add indexed bounded batches without skipping concurrent tombstones. Acceptance criteria - Batch size is capped - Cursor order is stable - New eligible rows appear on a subsequent pass Implementation constraints - Document cursor reset at end of pass. Verification - Sweep multiple pages - Insert eligible row during scan Deliverables - Sweep pagination and concurrency cases Rollout and recovery: Reduce to explicit small batches while cursor logic is repaired. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-109 — Protect retained document versions from blob cleanup **Bug · High priority · Advanced** noCV practice brief v5 · CBLOB-109 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate retention. Depends on: CBLOB-105, CBLOB-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Cleanup counts only current document references and breaks retained versions. Include every retained reference authority. Acceptance criteria - Retained versions preserve blobs - Expired versions release references - Cross-tenant records cannot affect counts Implementation constraints - Retention policy is a fixture contract, not a legal claim. Verification - Retain old version - Expire it and inspect eligibility Deliverables - Version-aware reference accounting Rollout and recovery: Pause cleanup until all reference sources reconcile. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. #### CBLOB-110 — Produce a blob-reclamation report that distinguishes planned and removed bytes **Story · Medium priority · Intermediate** noCV practice brief v5 · CBLOB-110 · Reference-aware blob retention and deletion Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate retention. Depends on: CBLOB-106, CBLOB-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Operators report savings from tombstoned bytes that still exist. Separate eligible, attempted and acknowledged removal totals. Acceptance criteria - Planned bytes are labeled - Failures remain outstanding - Only acknowledged removals count as reclaimed Implementation constraints - State measurements are local fixture observations. Verification - Sweep successful fixture batch - Fail half the deletions Deliverables - Reclamation report projection Rollout and recovery: Hide savings totals if acknowledgements cannot be reconciled. Project prerequisites: Generate duplicate and unique local byte fixtures. Create synthetic document references across two organizations. Engineer value: Practice reclamation races and explicit data-lifecycle guarantees. Company value: Inspect whether storage cleanup avoids broken references and hidden retention. 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. ## CKV — A crash-consistent local key-value store Fictional desktop cache Pebble needs a small embedded key-value engine. Build against generated keys and bytes using an ordinary filesystem adapter; no production database replacement is implied. **Field:** Storage systems. **Suggested stack:** TypeScript, Filesystem adapter, Vitest. **Engineer value:** Practice storage formats, durability boundaries and corruption handling. **Company value:** Inspect whether an engineer can state and test persistence guarantees. **Delivery agreement:** Each ticket adds one narrow engine behavior; publish measured local limits, not database performance claims. ### Setup prerequisites - Create a disposable local fixture directory. - Implement fault injection for partial writes, sync failure and process restart. ### Specify records Define bounded encoding and reads. #### CKV-101 — Encode local key-value records with explicit length limits **Task · Medium priority · Foundational** noCV practice brief v5 · CKV-101 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Delimiter-based records fail when values contain newlines. Add a length-prefixed binary record format. Acceptance criteria - Arbitrary bytes round-trip - Key and value limits are enforced - Version is encoded explicitly Implementation constraints - Specify byte order in the format note. Verification - Round-trip binary fixture - Reject oversized declared length Deliverables - Encoder decoder and format document Rollout and recovery: Keep old files read-only until conversion is explicit. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-102 — Distinguish missing local keys from empty values **Bug · Medium priority · Foundational** noCV practice brief v5 · CKV-102 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: CKV-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Storage systems 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. Empty buffers are interpreted as Not found. Return explicit presence separate from byte length. Acceptance criteria - Empty stored value is found - Absent key is missing - Deletion yields missing Implementation constraints - Avoid truthiness checks on encoded values. Verification - Read empty value - Read deleted key Deliverables - Read result contract and cases Rollout and recovery: Revert callers to explicit result checking. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-103 — Build a local key-value index from validated log records **Task · Medium priority · Intermediate** noCV practice brief v5 · CKV-103 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: CKV-101, CKV-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Startup trusts offsets without reading record boundaries. Rebuild the index only from validated records. Acceptance criteria - Latest valid record wins - Offsets stay within file bounds - Invalid record reports its position Implementation constraints - Do not allocate from untrusted length fields before bounds checks. Verification - Rebuild repeated keys - Use record extending past EOF Deliverables - Startup index and malformed-file cases Rollout and recovery: Refuse writes to logs that cannot be validated. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. ### Recover durable writes Handle torn records and atomic updates. #### CKV-104 — Declare local write acknowledgement after the durability barrier **Bug · High priority · Advanced** noCV practice brief v5 · CKV-104 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Put returns success before the log flush completes. Define durable acknowledgement using the filesystem adapter. Acceptance criteria - Success follows required sync - Sync failure reports uncertain outcome - Failed acknowledgement is not silently retried as new write Implementation constraints - Document the adapter's actual durability assumptions. Verification - Put with successful sync - Inject sync failure after write Deliverables - Acknowledgement contract and fault cases Rollout and recovery: Switch to read-only if durability barriers fail repeatedly. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-105 — Recover a torn key-value record at the end of the log **Task · High priority · Advanced** noCV practice brief v5 · CKV-105 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-103, CKV-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · Database 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 crash leaves a partial final record and startup refuses every key. Recover the valid prefix conservatively. Acceptance criteria - Valid prefix remains readable - Incomplete tail is identified - Middle corruption fails closed Implementation constraints - Tail truncation requires an explicit recovery mode. Verification - Recover partial final record - Corrupt middle record Deliverables - Tail recovery and corruption cases Rollout and recovery: Preserve original log before applying tail repair. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-106 — Represent key deletion as an ordered tombstone **Story · Medium priority · Intermediate** noCV practice brief v5 · CKV-106 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-104, CKV-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Rebuilding the index resurrects deleted keys because deletion only changed memory. Append durable tombstones. Acceptance criteria - Deleted keys stay missing after restart - Later puts can recreate key - Tombstones obey acknowledgement rules Implementation constraints - Keep record ordering authoritative. Verification - Delete and restart - Fail tombstone sync Deliverables - Tombstone format and restart cases Rollout and recovery: Disable deletion if durable ordering is uncertain. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-107 — Reject key-value batches that cannot commit atomically **Task · High priority · Expert** noCV practice brief v5 · CKV-107 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-104, CKV-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Storage systems 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 multi-key update survives restart with only half its changes. Add one bounded batch commit marker protocol. Acceptance criteria - Complete batch applies all records - Uncommitted batch applies none - Batch size is capped Implementation constraints - Do not claim filesystem transaction support that the adapter lacks. Verification - Restart after committed batch - Crash before commit marker Deliverables - Batch protocol and fault schedule Rollout and recovery: Disable batch writes while preserving single-key operations. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. ### Reclaim old storage Compact safely and inspect damage. #### CKV-108 — Compact the local log without changing visible key values **Task · High priority · Advanced** noCV practice brief v5 · CKV-108 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-106, CKV-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Database engineering 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. Repeated updates grow the log. Write a compacted generation from one consistent logical view. Acceptance criteria - Latest live values survive - Deleted keys stay absent - Compaction output validates before activation Implementation constraints - Bound memory by documented fixture limits or streaming plan. Verification - Compare reads before and after - Inject corrupted output record Deliverables - Compaction writer and equivalence cases Rollout and recovery: Discard unactivated compacted generation on failure. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-109 — Activate a compacted key-value generation recoverably **Bug · High priority · Expert** noCV practice brief v5 · CKV-109 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-108. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Crashing during compacted-file replacement leaves no selected log. Add a recoverable generation manifest. Acceptance criteria - One valid generation is selected - Interrupted switch retains fallback - Repeated recovery makes same choice Implementation constraints - Keep previous generation until activation is durable. Verification - Crash at switch boundaries - Remove incomplete new generation Deliverables - Generation activation and crash tests Rollout and recovery: Restore the last validated manifest and retain both files. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-110 — Inspect local key-value corruption without modifying files **Chore · Medium priority · Intermediate** noCV practice brief v5 · CKV-110 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-105, CKV-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Storage systems 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 has no way to identify damaged record offsets safely. Add a read-only inspection command. Acceptance criteria - Reports format and valid prefix - Never rewrites bytes - Output omits values by default Implementation constraints - Restrict command to an explicitly supplied fixture path. Verification - Inspect healthy log - Inspect malformed length and checksum Deliverables - Inspector and immutable-input checks Rollout and recovery: Remove repair suggestions if they imply automatic destructive changes. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. ## CBACK — Verifiable archive backup and restore Fictional archive Alder backs up synthetic document metadata and generated blobs into a dedicated local directory. No real organizational data or cloud accounts are required. **Field:** Storage systems. **Suggested stack:** TypeScript, SQLite, Filesystem adapter, Vitest. **Engineer value:** Practice consistent snapshots and recoverable restoration. **Company value:** Inspect whether backup success can be substantiated by a usable restore. **Delivery agreement:** Record local restore evidence; production disaster-recovery qualification remains separate. ### Setup prerequisites - Create synthetic metadata and generated blob fixtures. - Provide isolated source backup and restore directories. ### Describe backup content Define scope and integrity. #### CBACK-101 — Define archive backup manifests with explicit format versions **Task · Medium priority · Foundational** noCV practice brief v5 · CBACK-101 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe backup content. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · Data 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. Backup folders contain unnamed files with no declared schema. Add a bounded manifest describing required objects. Acceptance criteria - Manifest declares version - Entries have size and digest - Duplicate logical paths fail validation Implementation constraints - Treat manifest text as untrusted input. Verification - Parse valid fixture - Reject duplicate and future-version entries Deliverables - Manifest schema and parser Rollout and recovery: Keep unknown backup versions read-only. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-102 — Exclude temporary archive uploads from backup inventories **Bug · Medium priority · Foundational** noCV practice brief v5 · CBACK-102 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe backup content. Depends on: CBACK-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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 backup includes partial uploads and later calls them missing documents. Inventory only committed archive references. Acceptance criteria - Committed blobs are listed - Temporary uploads are excluded - Excluded counts are reported separately Implementation constraints - Inventory must derive from authoritative metadata state. Verification - Inventory committed fixture - Add incomplete upload Deliverables - Backup inventory projection Rollout and recovery: Pause backup capture if committed scope is uncertain. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-103 — Verify archive backup bytes against manifest digests **Task · High priority · Intermediate** noCV practice brief v5 · CBACK-103 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Describe backup content. Depends on: CBACK-101, CBACK-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Copy completion alone marks backup success. Stream verification of every required object before success. Acceptance criteria - Digest and size both match - Missing object fails verification - Failure identifies logical object safely Implementation constraints - Do not buffer entire backups in memory. Verification - Verify generated fixture - Flip one copied byte Deliverables - Streaming verifier and corruption cases Rollout and recovery: Mark affected backups unusable until reverified. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. ### Capture coherently Handle interruption and version boundaries. #### CBACK-104 — Capture archive metadata and blob references at one snapshot boundary **Bug · High priority · Expert** noCV practice brief v5 · CBACK-104 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture coherently. Depends on: CBACK-102, CBACK-103. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Database engineering 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. A document changes while backup runs and the manifest references an uncopied blob. Define one consistent capture boundary. Acceptance criteria - Manifest reflects one metadata snapshot - Required blobs remain pinned during capture - Concurrent new versions belong to later backups Implementation constraints - Specify adapter transaction and pin lifetime. Verification - Update after snapshot - Delete reference during capture Deliverables - Snapshot protocol and race cases Rollout and recovery: Pause pruning until capture pins are reliable. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-105 — Resume archive backup copying without accepting stale partial files **Story · Medium priority · Advanced** noCV practice brief v5 · CBACK-105 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture coherently. Depends on: CBACK-103, CBACK-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Restarted backup trusts an existing filename although the earlier copy was interrupted. Revalidate reusable files. Acceptance criteria - Matching verified files may be reused - Partial files are recopied - Resume retains original snapshot identity Implementation constraints - Reuse decisions require digest agreement. Verification - Resume with valid copied file - Resume with truncated file Deliverables - Copy-resume coordinator and cases Rollout and recovery: Start a new isolated backup if snapshot identity is lost. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-106 — Finalize archive backups with an explicit complete marker **Task · High priority · Intermediate** noCV practice brief v5 · CBACK-106 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture coherently. Depends on: CBACK-103, CBACK-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · 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. Operators select directories still being copied. Publish a durable completion marker only after required verification. Acceptance criteria - Incomplete directories are not selectable - Marker binds manifest digest - Failure cannot leave valid-looking completion Implementation constraints - Marker creation follows verification acknowledgement. Verification - Finish valid backup - Crash before marker creation Deliverables - Finalization protocol and tests Rollout and recovery: Withdraw completion marker if later validation fails. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-107 — Refuse archive restore paths outside the selected target directory **Bug · High priority · Advanced** noCV practice brief v5 · CBACK-107 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture coherently. Depends on: CBACK-101, CBACK-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Storage systems 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 crafted backup path can escape the restore root. Validate resolved destinations before creating files. Acceptance criteria - Traversal and absolute paths fail - Symlink escape is rejected by adapter policy - Valid files remain inside target Implementation constraints - Use a dedicated empty fixture directory. Verification - Restore valid nested object - Attempt parent traversal or symlink escape Deliverables - Restore-path boundary and cases Rollout and recovery: Abort restore before writes if containment cannot be established. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. ### Restore into isolation Validate before switching authority. #### CBACK-108 — Restore archive backups into an isolated staging generation **Story · High priority · Advanced** noCV practice brief v5 · CBACK-108 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore into isolation. Depends on: CBACK-106, CBACK-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Direct restoration overwrites the active archive before integrity checks finish. Build and validate a separate generation. Acceptance criteria - Active data remains untouched - Staging contains all required records - Failed validation leaves active generation selected Implementation constraints - No recursive operations on unspecified user directories. Verification - Restore valid fixture - Fail halfway through copying Deliverables - Staged restore and isolation checks Rollout and recovery: Discard only the verified staging directory on failure. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-109 — Switch restored archive authority with a rollback pointer **Task · High priority · Expert** noCV practice brief v5 · CBACK-109 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore into isolation. Depends on: CBACK-108. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. A successful staging restore still needs a safe handoff. Activate one generation while retaining the previous pointer. Acceptance criteria - Switch selects one validated generation - Interrupted activation recovers deterministically - Rollback selects prior intact generation Implementation constraints - Document concurrent-reader behavior at the switch. Verification - Activate restored fixture - Crash during pointer update Deliverables - Activation record and recovery tests Rollout and recovery: Restore previous validated pointer if post-switch checks fail. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. #### CBACK-110 — Prove one archive restore through observable consistency checks **Chore · Medium priority · Intermediate** noCV practice brief v5 · CBACK-110 · Verifiable archive backup and restore Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore into isolation. Depends on: CBACK-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Storage systems 30% · 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. A backup report says Success without reading restored documents. Add a repeatable restore exercise and recorded checks. Acceptance criteria - Restored references resolve - Document counts match manifest scope - Excluded temporary data stays excluded Implementation constraints - Report local fixture results and unresolved assumptions. Verification - Read every small fixture object - Remove one restored blob and detect failure Deliverables - Restore exercise and result record Rollout and recovery: Reclassify the backup as unverified if checks fail. Project prerequisites: Create synthetic metadata and generated blob fixtures. Provide isolated source backup and restore directories. Engineer value: Practice consistent snapshots and recoverable restoration. Company value: Inspect whether backup success can be substantiated by a usable restore. 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. ## CTIER — A local archive cache with explicit integrity and capacity Fictional media archive Ash serves generated byte fixtures through a fast local cache and slower provider stub. Both tiers run locally. **Field:** Storage systems. **Suggested stack:** TypeScript, Filesystem adapter, Vitest. **Engineer value:** Practice cache correctness, request coalescing and capacity control. **Company value:** Inspect whether faster delivery preserves bytes and operating limits. **Delivery agreement:** Use dedicated fixture directories and publish measured local observations only. ### Setup prerequisites - Create immutable generated blobs with known digests. - Implement controllable cache and origin adapters with read failures. ### Define cache reads Keep source authority explicit. #### CTIER-101 — Keep archive cache misses distinct from provider failures **Bug · Medium priority · Foundational** noCV practice brief v5 · CTIER-101 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache reads. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Any cache read error is treated as a miss and hides damaged storage. Define typed outcomes. Acceptance criteria - Missing key is a miss - Permission failure is operational error - Origin reads follow documented fallback policy Implementation constraints - Do not swallow arbitrary filesystem exceptions. Verification - Read absent fixture - Inject permission failure Deliverables - Cache result contract Rollout and recovery: Bypass cache on operational failure while reporting it. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-102 — Key archive cache entries by immutable blob identity **Task · Medium priority · Foundational** noCV practice brief v5 · CTIER-102 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache reads. Depends on: CTIER-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. A mutable filename reuses stale cached bytes after replacement. Bind entries to immutable version or digest. Acceptance criteria - Same identity reuses entry - New version uses new key - User labels do not affect identity Implementation constraints - Tenant scope remains part of lookup authority. Verification - Read repeated identity - Replace logical filename with new version Deliverables - Cache-key contract and cases Rollout and recovery: Disable cache reuse if identity is uncertain. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-103 — Verify archive cache fills before promoting temporary bytes **Task · High priority · Intermediate** noCV practice brief v5 · CTIER-103 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache reads. Depends on: CTIER-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. Interrupted origin reads leave files that future requests treat as complete. Stage and verify each fill. Acceptance criteria - Fill checks declared digest - Unverified files stay invisible - Failed fill removes or quarantines its temporary file Implementation constraints - Promotion must not expose partial bytes. Verification - Fill valid fixture - Truncate origin stream Deliverables - Verified fill and failure cases Rollout and recovery: Disable cache writes while serving origin directly. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. ### Control cache mutation Handle contention and eviction. #### CTIER-104 — Coalesce concurrent archive cache fills for one blob **Bug · Medium priority · Advanced** noCV practice brief v5 · CTIER-104 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control cache mutation. Depends on: CTIER-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Storage systems 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. Ten simultaneous misses download the same object ten times. Share one fill without joining unrelated keys. Acceptance criteria - Same identity shares fill - Different identities remain independent - Failure releases waiters consistently Implementation constraints - Bound the in-flight map and clear settled entries. Verification - Issue concurrent same-key reads - Fail shared fill then retry Deliverables - Fill coordinator and concurrency cases Rollout and recovery: Disable coalescing if waiters cannot be released. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-105 — Enforce archive cache capacity before admitting a fill **Task · High priority · Advanced** noCV practice brief v5 · CTIER-105 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control cache mutation. Depends on: CTIER-103, CTIER-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Performance 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. Parallel fills exceed the configured cache budget because each sees free space. Reserve capacity atomically. Acceptance criteria - Active reservations count toward limit - Failed fills release reservation - Oversized objects bypass with explanation Implementation constraints - Include temporary bytes in capacity accounting. Verification - Admit fitting concurrent fills - Attempt object larger than budget Deliverables - Admission reservations and cases Rollout and recovery: Stop cache admission until accounting reconciles. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-106 — Avoid evicting archive blobs while active readers hold them **Bug · High priority · Expert** noCV practice brief v5 · CTIER-106 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control cache mutation. Depends on: CTIER-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · 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. Eviction deletes a file while a streaming reader still needs it. Define reader leases and reclamation behavior. Acceptance criteria - Active readers finish or fail explicitly by contract - New reads cannot acquire deleting entry - Released leases permit eviction Implementation constraints - Specify platform filesystem assumptions. Verification - Evict idle fixture - Race eviction with active reader Deliverables - Reader-lease protocol and race tests Rollout and recovery: Pause eviction if active-reader safety is uncertain. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-107 — Record archive cache recency without writing on every byte read **Chore · Medium priority · Intermediate** noCV practice brief v5 · CTIER-107 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control cache mutation. Depends on: CTIER-104, CTIER-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Storage systems 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. Streaming a large blob rewrites recency metadata for every chunk. Update recency at a bounded operation boundary. Acceptance criteria - One read causes bounded metadata writes - Eviction order remains documented - Failed read policy is explicit Implementation constraints - Use injected clocks for recency tests. Verification - Stream many chunks - Fail midway and inspect recency Deliverables - Recency policy and write-count checks Rollout and recovery: Use insertion order temporarily if recency updates regress. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. ### Repair and observe Recover damage without hiding uncertainty. #### CTIER-108 — Detect corrupted archive cache entries before serving them again **Task · High priority · Advanced** noCV practice brief v5 · CTIER-108 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair and observe. Depends on: CTIER-103, CTIER-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · 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 local byte flip persists across reads. Add a bounded verification policy and quarantine path. Acceptance criteria - Verification detects mismatch - Corrupt entry is not reused - Origin repair creates a new verified entry Implementation constraints - State whether verification occurs per read or scheduled scan. Verification - Corrupt fixture then read - Fail origin repair Deliverables - Integrity policy and repair cases Rollout and recovery: Bypass cache for quarantined identities. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-109 — Reconcile archive cache metadata after process restart **Bug · High priority · Advanced** noCV practice brief v5 · CTIER-109 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair and observe. Depends on: CTIER-105, CTIER-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · 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 restart leaves reservations and temporary files consuming phantom capacity. Rebuild accounting from valid state. Acceptance criteria - Abandoned reservations release - Verified entries remain counted - Unknown files are quarantined rather than silently trusted Implementation constraints - Cleanup only within the configured fixture root. Verification - Restart after successful fill - Crash with partial temporary file Deliverables - Startup reconciliation and cases Rollout and recovery: Start cache read-only until reconciliation completes. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. #### CTIER-110 — Report archive cache hit rates with a defined denominator **Chore · Low priority · Intermediate** noCV practice brief v5 · CTIER-110 · A local archive cache with explicit integrity and capacity Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Repair and observe. Depends on: CTIER-107, CTIER-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Performance engineering 30% · Storage 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. Dashboard hit rate counts every chunk and exaggerates cache usefulness. Count logical read outcomes explicitly. Acceptance criteria - Denominator is logical read attempts - Bypass and errors are separate - No blob content enters events Implementation constraints - Report local measurements without generalized performance claims. Verification - Read hit miss and bypass fixtures - Retry failed read and inspect counts Deliverables - Metrics contract and captured examples Rollout and recovery: Hide hit-rate panel if event accounting changes. Project prerequisites: Create immutable generated blobs with known digests. Implement controllable cache and origin adapters with read failures. Engineer value: Practice cache correctness, request coalescing and capacity control. Company value: Inspect whether faster delivery preserves bytes and operating limits. 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. ## CPARSE — A configuration-language parser with usable diagnostics Fictional build tool Sprig reads a tiny configuration language with identifiers, strings, lists and assignments. Author the grammar and synthetic source corpus locally; parsing never executes source. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Vitest, Parser fixtures. **Engineer value:** Practice source positions, grammar boundaries and error recovery. **Company value:** Inspect whether tooling errors help users correct configuration safely. **Delivery agreement:** Keep each change within the declared grammar; runtime evaluation is excluded. ### Setup prerequisites - Write the tiny language grammar and generated source examples. - Create fixtures with Unicode, truncated tokens and nested lists. ### Specify source tokens Preserve spans and literal meaning. #### CPARSE-101 — Track configuration token spans across mixed newline styles **Bug · Medium priority · Foundational** noCV practice brief v5 · CPARSE-101 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify source tokens. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Windows configuration files report errors one line late. Define offsets and line mapping for LF and CRLF. Acceptance criteria - Spans cover exact token bytes or declared code units - CRLF counts as one line break - EOF has a valid location Implementation constraints - State the offset unit explicitly. Verification - Tokenize mixed newline fixture - Locate error at EOF Deliverables - Span mapper and boundary cases Rollout and recovery: Fall back to offsets if line mapping is unreliable. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-102 — Reject unterminated configuration strings with one useful diagnostic **Task · Medium priority · Foundational** noCV practice brief v5 · CPARSE-102 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify source tokens. Depends on: CPARSE-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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 missing quote produces dozens of bogus tokens. Add a bounded string error and recovery boundary. Acceptance criteria - Diagnostic identifies opening quote - Lexer makes forward progress - Later valid line can tokenize Implementation constraints - Do not guess a closing quote silently. Verification - Tokenize valid escaped string - Tokenize missing final quote Deliverables - String lexer and error cases Rollout and recovery: Stop at first string error if recovery becomes ambiguous. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-103 — Preserve configuration string escape meaning **Bug · High priority · Intermediate** noCV practice brief v5 · CPARSE-103 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify source tokens. Depends on: CPARSE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Backslashes disappear inconsistently between parsed values and printed output. Define recognized escapes and reject unknown ones. Acceptance criteria - Supported escapes decode exactly - Unknown escape reports its span - Decoded values retain nonescaped Unicode Implementation constraints - Keep raw span separate from decoded value. Verification - Decode quote and backslash fixtures - Reject unknown escape Deliverables - Escape decoder and round-trip cases Rollout and recovery: Reject affected literals until decoding is corrected. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. ### Build recoverable syntax Handle malformed structure deterministically. #### CPARSE-104 — Parse configuration lists without unbounded recursion **Task · High priority · Advanced** noCV practice brief v5 · CPARSE-104 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build recoverable syntax. Depends on: CPARSE-101, CPARSE-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Deeply nested synthetic lists exhaust the call stack. Enforce a documented nesting limit. Acceptance criteria - Valid nesting parses - Limit breach gives structured diagnostic - Parser consumes bounded work after failure Implementation constraints - Do not increase runtime stack limits as the fix. Verification - Parse at supported depth - Exceed depth limit Deliverables - List parser and depth cases Rollout and recovery: Lower accepted nesting cap if resource behavior is uncertain. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-105 — Recover configuration assignments at a documented synchronization point **Story · Medium priority · Advanced** noCV practice brief v5 · CPARSE-105 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build recoverable syntax. Depends on: CPARSE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. One missing equals sign hides all later keys. Resume at a safe assignment boundary. Acceptance criteria - Error names expected token - Later valid assignments appear - Recovery never loops at same offset Implementation constraints - Specify which tokens terminate recovery. Verification - Parse malformed then valid assignment - Use repeated unexpected delimiters Deliverables - Recovery strategy and progress tests Rollout and recovery: Use fail-fast parsing if recovery corrupts structure. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-106 — Detect duplicate configuration keys with both source locations **Task · Medium priority · Intermediate** noCV practice brief v5 · CPARSE-106 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build recoverable syntax. Depends on: CPARSE-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Repeated keys silently overwrite earlier values. Report the later assignment with a related earlier location. Acceptance criteria - Duplicate is explicit - Both spans are available - Distinct nested scopes remain independent Implementation constraints - Do not normalize identifiers beyond the grammar contract. Verification - Detect duplicate in one scope - Use same key in separate scopes Deliverables - Duplicate-key pass and cases Rollout and recovery: Reject duplicate-bearing files if diagnostics cannot disambiguate them. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-107 — Preserve configuration comments through syntax-tree editing **Story · Medium priority · Expert** noCV practice brief v5 · CPARSE-107 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build recoverable syntax. Depends on: CPARSE-105, CPARSE-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 80% · 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. A key-renaming tool deletes nearby comments because the parser discards trivia. Retain comment attachment with explicit rules. Acceptance criteria - Unchanged comments survive print - Ambiguous attachment is documented - Malformed comments retain source spans Implementation constraints - This ticket covers one rename transform only. Verification - Rename commented key - Rename near malformed trailing comment Deliverables - Trivia representation and rename round-trip Rollout and recovery: Disable rename when comment attachment is uncertain. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. ### Prepare editor consumers Keep diagnostics and printing stable. #### CPARSE-108 — Print configuration trees with stable parse equivalence **Task · Medium priority · Advanced** noCV practice brief v5 · CPARSE-108 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare editor consumers. Depends on: CPARSE-103, CPARSE-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Formatting can change string values and list meaning. Add a deterministic printer for the supported syntax. Acceptance criteria - Parse-print-parse preserves semantic tree - Formatting is idempotent - Unsupported nodes fail explicitly Implementation constraints - Do not claim preservation of arbitrary source formatting. Verification - Round-trip all grammar fixtures - Reject unsupported synthetic node Deliverables - Printer and equivalence cases Rollout and recovery: Keep original source when printer cannot represent the tree. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-109 — Bound configuration diagnostic counts for hostile input **Chore · Medium priority · Intermediate** noCV practice brief v5 · CPARSE-109 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare editor consumers. Depends on: CPARSE-105, CPARSE-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. A large malformed file emits thousands of repeated messages and stalls the editor. Cap diagnostics and include truncation status. Acceptance criteria - Count is bounded - Earliest useful errors remain - Suppressed count is disclosed Implementation constraints - Parsing must still terminate within documented input limits. Verification - Parse ordinary invalid file - Use dense malformed fixture Deliverables - Diagnostic budget and stress fixture Rollout and recovery: Stop parsing at budget exhaustion if recovery remains costly. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. #### CPARSE-110 — Publish a configuration parser compatibility corpus **Chore · Low priority · Intermediate** noCV practice brief v5 · CPARSE-110 · A configuration-language parser with usable diagnostics Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare editor consumers. Depends on: CPARSE-108, CPARSE-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 60% · Quality 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. Downstream tools cannot tell whether parser changes altered accepted syntax. Add a versioned local corpus and expected public diagnostics. Acceptance criteria - Corpus covers grammar productions - Invalid cases specify diagnostic categories - No hidden evaluator answers are included Implementation constraints - These are public engineering regressions, not grading material. Verification - Run corpus on current parser - Introduce a deliberate local grammar regression and observe failure Deliverables - Corpus manifest and execution record Rollout and recovery: Revert syntax changes that break declared compatibility unintentionally. Project prerequisites: Write the tiny language grammar and generated source examples. Create fixtures with Unicode, truncated tokens and nested lists. Engineer value: Practice source positions, grammar boundaries and error recovery. Company value: Inspect whether tooling errors help users correct configuration safely. 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. ## CTYPE — A small expression type checker with explainable errors Fictional rules editor Willow supports numbers, strings, booleans, records and functions in a deliberately small language. Define syntax and type rules locally; no arbitrary code execution is needed. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Vitest, Typed AST fixtures. **Engineer value:** Practice type environments, unification and explainable rejection. **Company value:** Inspect whether developer tooling catches mistakes without hiding uncertainty. **Delivery agreement:** Limit scope to the declared type system; general language compatibility is not claimed. ### Setup prerequisites - Create synthetic AST fixtures and a written type-rule table. - Define source spans and structured diagnostic output. ### Establish type rules Handle literals and lexical scope. #### CTYPE-101 — Assign explicit types to rules-editor literals **Task · Medium priority · Foundational** noCV practice brief v5 · CTYPE-101 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. The prototype infers booleans from string truthiness. Type literals from AST node kinds only. Acceptance criteria - Number string and boolean types differ - Empty string stays string - Unknown literal kind fails explicitly Implementation constraints - Do not evaluate literal source text. Verification - Check each supported literal - Reject unsupported node kind Deliverables - Literal checker and cases Rollout and recovery: Reject unknown nodes while supported literals remain available. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-102 — Resolve expression identifiers through lexical scope **Bug · High priority · Intermediate** noCV practice brief v5 · CTYPE-102 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: CTYPE-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Inner bindings overwrite the global environment and leak into sibling expressions. Use scoped environments. Acceptance criteria - Inner shadowing is local - Sibling scope remains unchanged - Unbound names include source location Implementation constraints - Environments must not mutate parent bindings accidentally. Verification - Check nested shadowing - Use name outside its scope Deliverables - Scope resolver and cases Rollout and recovery: Disable nested bindings if scope isolation fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-103 — Explain rules-editor operator operand mismatches **Story · Medium priority · Foundational** noCV practice brief v5 · CTYPE-103 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: CTYPE-101, CTYPE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Invalid addition reports Type error without naming either operand type. Add structured expected and actual types. Acceptance criteria - Valid operands infer result - Mismatch identifies operator span - Diagnostic includes both operand types Implementation constraints - Keep wording independent from internal object serialization. Verification - Add two numeric literals - Add number to unsupported record Deliverables - Operator rules and diagnostic cases Rollout and recovery: Reject ambiguous operators with explicit unsupported message. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. ### Resolve expression types Explain composition failures. #### CTYPE-104 — Check function calls for arity before argument inference **Task · Medium priority · Intermediate** noCV practice brief v5 · CTYPE-104 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-102, CTYPE-103. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Calling a two-argument function with one argument crashes inference. Validate arity and check only supplied expressions safely. Acceptance criteria - Correct arity checks all arguments - Wrong arity reports counts - Nested argument errors remain inspectable Implementation constraints - Avoid fabricating missing AST nodes. Verification - Check valid call - Call with too few and too many arguments Deliverables - Call checker and arity cases Rollout and recovery: Disable call inference for malformed ASTs. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-105 — Unify rules-editor type variables with an occurs check **Bug · High priority · Expert** noCV practice brief v5 · CTYPE-105 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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 recursive synthetic constraint produces an infinite inferred type. Reject self-containing substitutions. Acceptance criteria - Acyclic constraints unify - Recursive substitution fails with reason - Failure does not corrupt remaining environment Implementation constraints - Bound this ticket to monomorphic variable unification. Verification - Unify variable with number - Attempt variable equal to function containing itself Deliverables - Unifier and occurs-check cases Rollout and recovery: Disable variable inference if substitution integrity fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-106 — Report missing rules-editor record fields without losing known fields **Story · Medium priority · Advanced** noCV practice brief v5 · CTYPE-106 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-103, CTYPE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Reading an absent field turns the whole record into unknown and suppresses later valid diagnostics. Preserve field-level information. Acceptance criteria - Existing field returns declared type - Missing field names available keys within a cap - Later checks retain known types Implementation constraints - Do not expose arbitrary source values in diagnostics. Verification - Access known field - Access absent field then known field Deliverables - Record-access rule and recovery cases Rollout and recovery: Reject absent-field expression only while preserving surrounding scope. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-107 — Merge rules-editor branch types through explicit compatibility rules **Task · High priority · Advanced** noCV practice brief v5 · CTYPE-107 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-105, CTYPE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Conditional branches return incompatible values but the checker chooses the first branch type. Define their common result rule. Acceptance criteria - Compatible branches infer documented type - Incompatible branches report both spans - Condition must be boolean Implementation constraints - Do not introduce implicit coercion without a declared rule. Verification - Check matching branches - Check number versus record branches Deliverables - Conditional rule and compatibility cases Rollout and recovery: Reject mixed branches until the rule is stable. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. ### Keep checking predictable Bound work and stabilize diagnostics. #### CTYPE-108 — Make rules-editor diagnostics deterministic across map insertion order **Bug · Medium priority · Intermediate** noCV practice brief v5 · CTYPE-108 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-106, CTYPE-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Equivalent AST construction order changes diagnostic output and noisy snapshots. Sort by source and stable category. Acceptance criteria - Equivalent inputs yield same order - Related locations stay attached - Equal-span tie-breaking is documented Implementation constraints - Determinism must not remove distinct failures. Verification - Reorder environment construction - Create two same-span categories Deliverables - Diagnostic ordering and cases Rollout and recovery: Preserve stable source traversal if sorting loses relationships. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-109 — Cancel obsolete rules-editor checks without publishing stale results **Story · Medium priority · Advanced** noCV practice brief v5 · CTYPE-109 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-107, CTYPE-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 80% · 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. Editor edits finish out of order and older type errors replace current diagnostics. Scope checking to document version. Acceptance criteria - Only current version publishes - Cancellation releases resources - Late completion cannot overwrite Implementation constraints - Include document identity as well as version. Verification - Complete current check - Resolve old check after replacement Deliverables - Versioned checking coordinator Rollout and recovery: Run serial checks if publication ownership fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. #### CTYPE-110 — Bound rules-editor inference work with explicit incomplete status **Chore · Medium priority · Expert** noCV practice brief v5 · CTYPE-110 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-105, CTYPE-109. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Adversarial nested constraints consume excessive work. Add operation and depth budgets with honest termination status. Acceptance criteria - Supported fixtures complete - Budget exhaustion is explicit - Incomplete checks cannot claim type safety Implementation constraints - Use deterministic counters rather than wall time alone. Verification - Check normal corpus - Exceed constraint budget Deliverables - Inference budget and stress cases Rollout and recovery: Lower limits and mark affected files incomplete until improved. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. 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. ## CLSP — A focused language server for configuration editing Fictional config editor Hazel speaks a bounded subset of the Language Server Protocol through a local transport adapter. Use a tiny declared configuration grammar and synthetic documents. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, JSON-RPC, Local protocol adapter, Vitest. **Engineer value:** Practice protocol ordering and document-safe editing. **Company value:** Inspect whether editor assistance preserves current user text and file boundaries. **Delivery agreement:** Test through local protocol messages; editor marketplace publishing is excluded. ### Setup prerequisites - Define the supported protocol subset and configuration grammar. - Create synthetic open/change/close messages and workspace fixtures. ### Own document state Validate lifecycle and positions. #### CLSP-101 — Reject configuration edits for unopened language-server documents **Bug · Medium priority · Foundational** noCV practice brief v5 · CLSP-101 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Own document state. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. A change notification for an unknown URI crashes the document map. Validate document lifecycle. Acceptance criteria - Open establishes document state - Unknown change is handled explicitly - Close releases state Implementation constraints - Follow the declared protocol subset's error behavior. Verification - Open then change fixture - Change unopened document Deliverables - Document lifecycle handler and cases Rollout and recovery: Ignore unsupported lifecycle notifications with bounded diagnostics. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-102 — Convert language-server positions using a declared encoding **Task · High priority · Intermediate** noCV practice brief v5 · CLSP-102 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Own document state. Depends on: CLSP-101. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Emoji before an error shifts the underline. Add position conversion matching the negotiated encoding. Acceptance criteria - ASCII positions map correctly - Supplementary characters map correctly - Out-of-range positions are rejected Implementation constraints - Do not assume byte offsets equal editor positions. Verification - Edit after emoji - Request position beyond line end Deliverables - Position codec and Unicode cases Rollout and recovery: Advertise only the verified encoding until others are implemented. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-103 — Apply configuration document edits in the supplied version order **Bug · High priority · Advanced** noCV practice brief v5 · CLSP-103 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Own document state. Depends on: CLSP-101, CLSP-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Delayed changes replace newer document content. Track monotonic document versions and ordered edits. Acceptance criteria - New valid version applies - Old version cannot overwrite - Invalid range leaves prior snapshot intact Implementation constraints - Apply one notification atomically to a cloned snapshot. Verification - Apply ordered incremental edits - Send stale version and invalid range Deliverables - Versioned document store Rollout and recovery: Request full resynchronization after rejected inconsistent edits. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. ### Provide scoped assistance Return current diagnostics and bounded edits. #### CLSP-104 — Publish configuration diagnostics for the checked document version **Story · Medium priority · Intermediate** noCV practice brief v5 · CLSP-104 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Provide scoped assistance. Depends on: CLSP-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Parser results are published after users type more text. Bind diagnostics to the source snapshot checked. Acceptance criteria - Current results publish - Superseded results drop - Closed documents clear diagnostics Implementation constraints - Snapshot identity includes URI and version. Verification - Check unchanged document - Close or edit before check completes Deliverables - Diagnostic publication guard Rollout and recovery: Disable background checking and use explicit validation temporarily. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-105 — Complete configuration keys only within valid assignment contexts **Story · Medium priority · Advanced** noCV practice brief v5 · CLSP-105 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Provide scoped assistance. Depends on: CLSP-102, CLSP-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Completion suggests keys inside string literals and comments. Restrict suggestions using syntax context. Acceptance criteria - Assignment context gets known keys - String/comment contexts suppress keys - Incomplete assignment remains supported Implementation constraints - Use public grammar metadata, not hidden evaluator assets. Verification - Complete incomplete key - Request completion inside quoted value Deliverables - Context completion and cases Rollout and recovery: Return no suggestions when context cannot be determined. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-106 — Return configuration rename edits only for resolved local bindings **Task · High priority · Expert** noCV practice brief v5 · CLSP-106 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Provide scoped assistance. Depends on: CLSP-103, CLSP-105. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Rename replaces matching text inside comments and unrelated scopes. Resolve the selected symbol before creating edits. Acceptance criteria - Bound references rename - Shadowed symbols stay unchanged - Unresolved selection yields no edit Implementation constraints - This ticket supports one document only. Verification - Rename binding and references - Select comment text or shadowed name Deliverables - Symbol rename and isolation cases Rollout and recovery: Disable rename if symbol resolution is ambiguous. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-107 — Attach expected document versions to configuration code actions **Bug · High priority · Advanced** noCV practice brief v5 · CLSP-107 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Provide scoped assistance. Depends on: CLSP-104, CLSP-106. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Applying an old quick fix corrupts newer text. Include the snapshot version in the edit contract. Acceptance criteria - Matching version applies - Changed version is rejected or recomputed - Action describes its actual mutation Implementation constraints - Do not apply stale offsets optimistically. Verification - Apply fresh missing-delimiter fix - Edit before applying old action Deliverables - Versioned code action and cases Rollout and recovery: Hide code actions if client cannot enforce edit versions. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. ### Handle client interruption Cancel stale work and recover protocol errors. #### CLSP-108 — Cancel language-server requests without leaking pending work **Chore · Medium priority · Intermediate** noCV practice brief v5 · CLSP-108 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle client interruption. Depends on: CLSP-104, CLSP-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Repeated completion cancellation leaves tasks in memory. Add request-scoped cleanup for all terminal paths. Acceptance criteria - Success removes pending entry - Cancellation removes entry - Late result does not emit another response Implementation constraints - Request IDs may be reused only per protocol rules. Verification - Complete request - Cancel then deliver late result Deliverables - Request registry and cleanup tests Rollout and recovery: Limit concurrency if cleanup cannot be guaranteed. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-109 — Handle malformed language-server messages without losing healthy documents **Bug · High priority · Advanced** noCV practice brief v5 · CLSP-109 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle client interruption. Depends on: CLSP-101, CLSP-108. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. A malformed request resets the whole server and loses open buffers. Isolate parsing and protocol failures. Acceptance criteria - Invalid message gets bounded error - Healthy documents remain intact - Transport stays usable when framing permits Implementation constraints - Never log full document contents on parse failure. Verification - Send valid request after malformed one - Send oversized message Deliverables - Protocol error boundary and cases Rollout and recovery: Close only the offending transport when framing is unrecoverable. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. #### CLSP-110 — Create a reproducible configuration language-server transcript harness **Chore · Low priority · Intermediate** noCV practice brief v5 · CLSP-110 · A focused language server for configuration editing Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle client interruption. Depends on: CLSP-107, CLSP-109. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Compiler and language 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. Editor reports are difficult to replay. Record synthetic protocol transcripts with deterministic response assertions. Acceptance criteria - Harness replays open/edit/action/close - Versions and request IDs are explicit - Fixture text is synthetic Implementation constraints - Recorded transcripts are public regression cases, not hidden grading answers. Verification - Replay successful rename - Replay stale action rejection Deliverables - Transcript runner and fixtures Rollout and recovery: Retain prior passing transcripts when behavior changes intentionally. Project prerequisites: Define the supported protocol subset and configuration grammar. Create synthetic open/change/close messages and workspace fixtures. Engineer value: Practice protocol ordering and document-safe editing. Company value: Inspect whether editor assistance preserves current user text and file boundaries. 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. ## CBUILD — An incremental build graph with correct invalidation Fictional static documentation compiler Rowan transforms synthetic text modules through a deterministic local adapter. It never executes candidate source as code. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Filesystem adapter, Vitest. **Engineer value:** Practice dependency graphs and cache correctness. **Company value:** Inspect whether build speed improvements preserve output correctness. **Delivery agreement:** Measure local fixture behavior; broad compiler-performance claims are excluded. ### Setup prerequisites - Create a synthetic module graph and deterministic transform stub. - Provide file-change, missing-input and interrupted-output fixtures. ### Establish dependency identity Parse and validate local graph edges. #### CBUILD-101 — Normalize local build paths without merging distinct modules **Task · Medium priority · Foundational** noCV practice brief v5 · CBUILD-101 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish dependency identity. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Compiler and language 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. Relative spellings create duplicate graph nodes. Define canonical module identity under an explicit workspace root. Acceptance criteria - Equivalent local paths share identity - Escaping paths are rejected - Case behavior is documented per adapter Implementation constraints - Do not silently assume case-insensitive filesystems. Verification - Resolve relative alias - Reject path escaping fixture root Deliverables - Module identity resolver Rollout and recovery: Disable reuse for ambiguous path identities. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-102 — Report missing static-build imports at their source location **Bug · Medium priority · Foundational** noCV practice brief v5 · CBUILD-102 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish dependency identity. Depends on: CBUILD-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · Developer tooling 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 missing import yields an internal file error. Map resolution failure to the importing source span. Acceptance criteria - Missing path identifies importer - Valid imports resolve - Error omits unrelated absolute paths Implementation constraints - Use synthetic source content only. Verification - Resolve present import - Reference absent module Deliverables - Import diagnostic and cases Rollout and recovery: Stop affected module build while preserving other diagnostics. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-103 — Detect static-build dependency cycles with a readable path **Task · High priority · Intermediate** noCV practice brief v5 · CBUILD-103 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish dependency identity. Depends on: CBUILD-101, CBUILD-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Recursive imports hang graph traversal. Detect cycles and return the concrete edge path. Acceptance criteria - Acyclic graph builds - Cycle includes involved modules - Repeated traversal terminates Implementation constraints - Bound reported cycle length for large inputs. Verification - Traverse diamond graph - Introduce three-node cycle Deliverables - Cycle detector and fixtures Rollout and recovery: Refuse cyclic graph outputs until cycle policy is defined. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. ### Invalidate and rebuild Reuse only compatible outputs. #### CBUILD-104 — Include transform configuration in static-build cache identity **Bug · High priority · Advanced** noCV practice brief v5 · CBUILD-104 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Invalidate and rebuild. Depends on: CBUILD-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Compiler and language tooling 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. Changing compiler options reuses output produced under older options. Hash normalized inputs and configuration. Acceptance criteria - Same inputs reuse output - Changed options invalidate - Transform version participates in key Implementation constraints - Hash canonical configuration, not property insertion order. Verification - Reorder equivalent config keys - Change output-affecting option Deliverables - Cache-key contract and cases Rollout and recovery: Disable cache reuse after unknown configuration changes. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-105 — Invalidate transitive static-build dependents after source changes **Task · High priority · Advanced** noCV practice brief v5 · CBUILD-105 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Invalidate and rebuild. Depends on: CBUILD-103, CBUILD-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · Developer tooling 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. Updating a shared module rebuilds it but leaves dependent pages stale. Traverse reverse dependency edges. Acceptance criteria - Direct and transitive dependents rebuild - Unrelated modules remain reusable - Removed edges stop unnecessary invalidation Implementation constraints - Use previous and current graph where edge removal matters. Verification - Change shared leaf - Remove dependency then change old leaf Deliverables - Invalidation planner and graph cases Rollout and recovery: Rebuild all fixture modules if invalidation is uncertain. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-106 — Track failed static-build nodes without caching broken outputs **Bug · High priority · Intermediate** noCV practice brief v5 · CBUILD-106 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Invalidate and rebuild. Depends on: CBUILD-104, CBUILD-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Compiler and language 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 failed transform writes a cache entry that future builds treat as success. Separate failure from reusable output. Acceptance criteria - Only successful validated output caches - Failure retains diagnostics - Next build retries affected node Implementation constraints - Never replace last good output with partial bytes silently. Verification - Build successful node - Fail transform after partial output Deliverables - Build result states and failure cases Rollout and recovery: Clear only affected invalid cache entries and retry. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-107 — Make incremental static builds deterministic across worker order **Task · High priority · Expert** noCV practice brief v5 · CBUILD-107 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Invalidate and rebuild. Depends on: CBUILD-105, CBUILD-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Compiler and language tooling 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. Parallel transform completion changes manifest ordering and output hashes. Separate execution scheduling from canonical publication. Acceptance criteria - Equivalent graphs yield identical manifests - Dependencies complete before consumers - Failed nodes cannot publish Implementation constraints - Use controllable local transform promises. Verification - Resolve independent workers in opposite order - Fail one dependency Deliverables - Deterministic scheduler and order cases Rollout and recovery: Use serial execution while ordering invariants are repaired. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. ### Recover interrupted builds Publish outputs and explain cache decisions. #### CBUILD-108 — Publish a static-build output generation only after all required nodes pass **Story · High priority · Advanced** noCV practice brief v5 · CBUILD-108 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted builds. Depends on: CBUILD-106, CBUILD-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Storage systems 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. Readers see mixed old and new files during a build. Write a staging generation and switch a manifest pointer. Acceptance criteria - Failed builds keep previous generation - Successful generation is complete - Switch recovery selects one valid manifest Implementation constraints - Keep prior generation until activation is durable. Verification - Publish successful fixture - Crash before manifest switch Deliverables - Generation publisher and recovery cases Rollout and recovery: Restore prior manifest on failed post-switch checks. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-109 — Coalesce repeated static-build file events without missing deletion **Bug · Medium priority · Intermediate** noCV practice brief v5 · CBUILD-109 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted builds. Depends on: CBUILD-105, CBUILD-108. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Compiler and language 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. Editors emit many change events and a final delete can be swallowed by debounce. Track final invalidation intent per module. Acceptance criteria - Repeated updates coalesce - Deletion remains authoritative - Change during build schedules another pass Implementation constraints - File events are hints; resolve actual state before building. Verification - Burst-save one file - Delete during active build Deliverables - Event coordinator and race cases Rollout and recovery: Use explicit rebuild requests if watcher semantics are unreliable. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. #### CBUILD-110 — Explain why each static-build module was reused or rebuilt **Chore · Low priority · Intermediate** noCV practice brief v5 · CBUILD-110 · An incremental build graph with correct invalidation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted builds. Depends on: CBUILD-104, CBUILD-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Compiler and language 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. Developers cannot distinguish cache misses from invalidation bugs. Emit structured decision reasons without source text. Acceptance criteria - Reasons identify changed input category - Reuse points to compatible key - Diagnostics omit source contents Implementation constraints - Local timing observations must state fixture and environment. Verification - Inspect unchanged build - Change transform version and inspect reasons Deliverables - Build decision report Rollout and recovery: Disable report fields that expose source content. Project prerequisites: Create a synthetic module graph and deterministic transform stub. Provide file-change, missing-input and interrupted-output fixtures. Engineer value: Practice dependency graphs and cache correctness. Company value: Inspect whether build speed improvements preserve output correctness. 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. ## CMIGR — A safe source migration for a deprecated configuration API Fictional package Laurel replaces configure(name, options) with configure({name, options}). Build synthetic TypeScript-like AST fixtures or use the repository's installed parser; source is analyzed, never executed. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, AST adapter, Filesystem adapter, Vitest. **Engineer value:** Practice conservative automated refactoring and reviewable uncertainty. **Company value:** Inspect whether migration automation reduces repetitive work without silent semantic changes. **Delivery agreement:** Only the declared API migration is covered; ambiguous cases must remain manual. ### Setup prerequisites - Create synthetic supported and ambiguous call-site fixtures. - Define the exact old/new API contract and a dedicated output directory. ### Find eligible calls Resolve syntax and binding identity. #### CMIGR-101 — Identify deprecated configuration imports by resolved binding **Task · Medium priority · Foundational** noCV practice brief v5 · CMIGR-101 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Find eligible calls. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Text search matches unrelated local functions named configure. Discover calls through the imported binding. Acceptance criteria - Imported binding matches - Aliased import matches - Unrelated local name does not match Implementation constraints - Scope is the declared module identifier only. Verification - Find direct and aliased import - Use unrelated local configure Deliverables - Call-site discovery and cases Rollout and recovery: Report candidates without editing if resolution is uncertain. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-102 — Exclude comments and string literals from configuration migration candidates **Bug · Medium priority · Foundational** noCV practice brief v5 · CMIGR-102 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Find eligible calls. Depends on: CMIGR-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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 prototype replaces examples inside strings and comments. Use syntax node kinds for candidate selection. Acceptance criteria - Executable call nodes alone qualify - Comment text remains unchanged - String contents remain unchanged Implementation constraints - Source analysis does not execute expressions. Verification - Find real call - Include matching text in comment and string Deliverables - Syntax filter and fixtures Rollout and recovery: Disable text-based fallback entirely. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-103 — Report ambiguous configuration calls for manual review **Story · Medium priority · Intermediate** noCV practice brief v5 · CMIGR-103 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Find eligible calls. Depends on: CMIGR-101, CMIGR-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Spread arguments and reassigned bindings make transformation unsafe. Return explicit skipped reasons. Acceptance criteria - Supported two-argument calls qualify - Spread or reassigned cases skip - Skipped locations are listed Implementation constraints - Do not invent argument meaning from names. Verification - Classify supported call - Classify spread and reassignment Deliverables - Eligibility report and cases Rollout and recovery: Keep ambiguous files unchanged. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. ### Produce conservative edits Preserve comments and reject ambiguity. #### CMIGR-104 — Transform the supported configuration call shape without reordering evaluation **Task · High priority · Advanced** noCV practice brief v5 · CMIGR-104 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Produce conservative edits. Depends on: CMIGR-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Wrapping arguments into an object could reorder side-effecting expressions. Preserve the old left-to-right evaluation order. Acceptance criteria - Name expression remains first - Options remains second - No expression duplicates or disappears Implementation constraints - Verify syntax structure without executing candidate expressions. Verification - Transform ordinary expressions - Use synthetic call expressions in both positions Deliverables - Transformation and AST-order checks Rollout and recovery: Revert transformed files if evaluation order cannot be preserved. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-105 — Preserve configuration-call comments during transformation **Bug · Medium priority · Advanced** noCV practice brief v5 · CMIGR-105 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Produce conservative edits. Depends on: CMIGR-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Comments between arguments vanish in generated output. Attach trivia using a documented preservation rule. Acceptance criteria - Leading and trailing comments survive - Argument comments remain near their expression - Unrepresentable trivia causes skip Implementation constraints - Do not silently relocate a directive comment. Verification - Transform commented call - Use directive-like ambiguous comment Deliverables - Trivia-preserving transform and cases Rollout and recovery: Leave affected call unchanged with a review reason. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-106 — Make the configuration migration idempotent **Task · Medium priority · Intermediate** noCV practice brief v5 · CMIGR-106 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Produce conservative edits. Depends on: CMIGR-104, CMIGR-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 80% · 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. Running the migration twice wraps an already migrated call again. Recognize new syntax and preserve it. Acceptance criteria - Second run produces no diff - Mixed old/new files transform eligible old calls - Unrelated object arguments remain unchanged Implementation constraints - Idempotence is checked on printed source as well as AST. Verification - Run twice on migrated fixture - Run on mixed file Deliverables - Idempotency cases and migration guard Rollout and recovery: Stop repeated application if the second run changes output. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-107 — Reject overlapping configuration source edits before writing **Bug · High priority · Expert** noCV practice brief v5 · CMIGR-107 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Produce conservative edits. Depends on: CMIGR-104, CMIGR-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language 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. Nested eligible calls produce overlapping text edits and corrupt files. Plan edits with deterministic nesting handling. Acceptance criteria - Edits do not overlap - Nested calls follow documented policy - Ambiguous overlap skips file safely Implementation constraints - Prefer one syntax-tree rewrite over blind offset patches. Verification - Transform disjoint calls - Transform nested eligible calls Deliverables - Edit planner and overlap cases Rollout and recovery: Emit preview only for files with unresolved overlaps. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. ### Apply and verify safely Make changes reviewable and recoverable. #### CMIGR-108 — Preview configuration migration changes before applying them **Story · Medium priority · Intermediate** noCV practice brief v5 · CMIGR-108 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply and verify safely. Depends on: CMIGR-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Compiler and language 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. Developers need to review the exact transformation scope. Add a dry-run diff and skipped-call summary. Acceptance criteria - Preview writes no source files - Diff reflects proposed bytes - Skipped reasons include locations Implementation constraints - Default command mode should be explicit in usage. Verification - Preview supported fixture - Preview ambiguous file and compare unchanged bytes Deliverables - Dry-run report and immutability check Rollout and recovery: Disable apply mode if preview differs from actual output. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-109 — Apply configuration migration files with stale-input protection **Task · High priority · Advanced** noCV practice brief v5 · CMIGR-109 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply and verify safely. Depends on: CMIGR-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Compiler and language tooling 30% · Storage 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. A developer edits a file after preview and apply overwrites it. Compare the original digest before replacement. Acceptance criteria - Matching source applies - Changed source is rejected - Failed replacement preserves recoverable original Implementation constraints - Restrict writes to the explicit fixture root. Verification - Apply unchanged preview - Modify file before apply Deliverables - Guarded writer and failure cases Rollout and recovery: Restore preserved original only after checking target identity. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. #### CMIGR-110 — Summarize configuration migration outcomes without claiming full compatibility **Chore · Low priority · Intermediate** noCV practice brief v5 · CMIGR-110 · A safe source migration for a deprecated configuration API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply and verify safely. Depends on: CMIGR-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 60% · Compiler and language 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 green migration summary implies the whole package is compatible despite skipped sites. Report exact supported outcomes. Acceptance criteria - Counts distinguish changed unchanged and skipped - Follow-up checks are listed - No semantic proof is asserted beyond tested contract Implementation constraints - Run parser/type checks available in the fixture harness. Verification - Summarize complete supported fixture - Summarize mixed skipped case Deliverables - Migration report and verification record Rollout and recovery: Mark migration incomplete when required checks fail. Project prerequisites: Create synthetic supported and ambiguous call-site fixtures. Define the exact old/new API contract and a dedicated output directory. Engineer value: Practice conservative automated refactoring and reviewable uncertainty. Company value: Inspect whether migration automation reduces repetitive work without silent semantic changes. 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. ## CFRAME — An emulated device-link framing library Fictional environmental-display devices send synthetic noncritical readings to a local gateway. Implement a byte-stream emulator; no physical device, radio, credentials or safety-critical control is involved. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Byte-stream emulator, Vitest. **Engineer value:** Practice incremental parsing, fixed resource limits and protocol recovery. **Company value:** Inspect whether a device adapter survives malformed input without corrupting accepted readings. **Delivery agreement:** All execution uses software fixtures; hardware timing and production readiness are unqualified. ### Setup prerequisites - Specify a small frame format with length sequence payload and checksum. - Generate local byte streams with fragmentation corruption and reconnects. ### Define frame boundaries Validate bytes before interpreting payloads. #### CFRAME-101 — Decode emulated device frame integers with explicit byte order **Task · Medium priority · Foundational** noCV practice brief v5 · CFRAME-101 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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 synthetic device length reads as 512 instead of 2 because endpoints disagree on byte order. Specify and implement the format. Acceptance criteria - Length and sequence use documented order - Valid boundary values round-trip - Truncated integer fields fail explicitly Implementation constraints - Use byte fixtures rather than host-native integer casts. Verification - Decode known two-byte values - Provide truncated header Deliverables - Integer codec and format examples Rollout and recovery: Reject frames from unknown format versions. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-102 — Reject emulated device frames above the receiver limit **Bug · High priority · Foundational** noCV practice brief v5 · CFRAME-102 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: CFRAME-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Security 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. An untrusted length prefix causes a large allocation. Validate declared size before reserving payload storage. Acceptance criteria - Supported sizes pass - Oversized lengths fail before allocation - Zero-length policy is explicit Implementation constraints - Keep receiver limits independent from sender claims. Verification - Decode small fixture - Declare maximum integer length Deliverables - Frame admission guard and allocation checks Rollout and recovery: Stop reception if bounded allocation cannot be guaranteed. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-103 — Verify emulated device frame checksums before dispatch **Task · High priority · Intermediate** noCV practice brief v5 · CFRAME-103 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: CFRAME-101, CFRAME-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Corrupted readings reach the dashboard because checksum failures are warnings only. Gate payload dispatch on verification. Acceptance criteria - Valid frame dispatches once - Bad checksum dispatches nothing - Failure records a bounded category Implementation constraints - Checksum detects corruption and does not authenticate senders. Verification - Accept valid frame - Flip payload byte without updating checksum Deliverables - Checksum gate and corruption cases Rollout and recovery: Disable payload dispatch if verification is unavailable. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. ### Handle partial transport Recover fragmented and damaged streams. #### CFRAME-104 — Assemble fragmented emulated frames across arbitrary read boundaries **Bug · High priority · Advanced** noCV practice brief v5 · CFRAME-104 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-102, CFRAME-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. A single frame split across reads is discarded as malformed. Maintain incremental parser state. Acceptance criteria - Every legal split yields same frame - Multiple frames in one read decode - Incomplete suffix remains bounded Implementation constraints - Transport read boundaries are not message boundaries. Verification - Test every split of small frame - Feed partial header then disconnect Deliverables - Streaming decoder and split cases Rollout and recovery: Buffer only up to the declared frame limit. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-105 — Resynchronize emulated device framing after a corrupt header **Story · Medium priority · Advanced** noCV practice brief v5 · CFRAME-105 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. One damaged length prevents decoding all later frames. Recover at a documented sync marker without trusting random payload bytes. Acceptance criteria - Valid later frame can recover - Recovery scans within a cap - Rejected bytes never dispatch as readings Implementation constraints - Define marker escaping or ambiguity handling explicitly. Verification - Corrupt header before valid frame - Embed marker-like bytes in payload Deliverables - Resynchronization algorithm and ambiguity cases Rollout and recovery: Close the link when a safe boundary cannot be found. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-106 — Discard incomplete emulated frames after an idle deadline **Task · Medium priority · Intermediate** noCV practice brief v5 · CFRAME-106 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-104, CFRAME-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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 sender transmits a header and stops, pinning a receive buffer indefinitely. Add an injected idle timer. Acceptance criteria - Active progress refreshes deadline - Expired partial frame releases buffer - New valid frame can start afterward Implementation constraints - Use monotonic elapsed time rather than calendar time. Verification - Complete frame before deadline - Pause midway beyond deadline Deliverables - Partial-frame timeout and clock cases Rollout and recovery: Reset connection on timeout if local recovery is uncertain. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-107 — Handle emulated device sequence wrap without accepting stale frames **Bug · High priority · Expert** noCV practice brief v5 · CFRAME-107 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-103, CFRAME-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Networking 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. Sequence 0 after 65535 is rejected as old, while delayed frames sometimes overwrite current readings. Define a bounded modular-order window. Acceptance criteria - Legitimate wrap is accepted - Duplicates do not dispatch twice - Outside-window frames are rejected or require reset Implementation constraints - State the maximum reorder window and session boundary. Verification - Feed wrap boundary sequence - Replay delayed pre-wrap frame Deliverables - Sequence policy and boundary cases Rollout and recovery: Require a new session when sequence ordering is ambiguous. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. ### Bound receiver behavior Limit work and explain rejected data. #### CFRAME-108 — Apply backpressure when emulated device consumers fall behind **Task · High priority · Advanced** noCV practice brief v5 · CFRAME-108 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-104, CFRAME-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 40% · Performance engineering 40% · 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. Parsing outruns downstream processing and queues grow indefinitely. Bound accepted-frame buffering. Acceptance criteria - Queue capacity is explicit - Overflow follows documented reject or pause policy - Parser state remains valid Implementation constraints - Do not claim lossless delivery under an explicit drop policy. Verification - Consume at normal speed - Stall consumer past capacity Deliverables - Bounded queue and overload cases Rollout and recovery: Pause emulator input if the consumer cannot keep up. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-109 — Reset emulated receiver state on a new link session **Bug · Medium priority · Intermediate** noCV practice brief v5 · CFRAME-109 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-106, CFRAME-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Bytes from a previous connection combine with a new header after reconnect. Clear session-owned parsing state. Acceptance criteria - New session discards partial buffer - Sequence window resets by contract - Completed prior frames remain recorded Implementation constraints - Connection identity must not come from payload text alone. Verification - Reconnect after complete frame - Reconnect mid-header Deliverables - Session reset and reconnect cases Rollout and recovery: Recreate the receiver per connection until state isolation is repaired. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-110 — Expose emulated frame rejection counters without raw payloads **Chore · Low priority · Intermediate** noCV practice brief v5 · CFRAME-110 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-108, CFRAME-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 40% · Site reliability 30% · Privacy 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. Debug logs contain complete sensor payloads even when only corruption rates are needed. Emit bounded categories. Acceptance criteria - Counts separate size checksum timeout and sequence failures - Payload bytes are omitted - Counter reset scope is documented Implementation constraints - Measurements describe the synthetic emulator only. Verification - Feed valid and corrupt fixtures - Inject secret-like payload and inspect logs Deliverables - Receiver metrics contract and samples Rollout and recovery: Disable detailed logging if payload content escapes. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. ## CTIMER — A deterministic edge-job scheduler emulator Fictional kiosk software schedules cache refresh and display housekeeping. Build a software clock and job adapter; do not control real machinery or purchase hardware. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Fake clock, Vitest. **Engineer value:** Practice timer semantics, cancellation and bounded scheduling. **Company value:** Inspect predictable edge resource use and honest execution status. **Delivery agreement:** Use deterministic clock advancement; emulator timing does not qualify physical realtime behavior. ### Setup prerequisites - Implement injected wall and monotonic clocks. - Create synthetic jobs with controllable completion and failure. ### Define time semantics Separate elapsed deadlines from calendar schedules. #### CTIMER-101 — Use monotonic time for edge-job timeout deadlines **Bug · High priority · Foundational** noCV practice brief v5 · CTIMER-101 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define time semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Moving the emulator wall clock backward extends a running job forever. Measure elapsed timeout against monotonic time. Acceptance criteria - Wall-clock changes do not extend timeout - Deadline fires once - Elapsed duration cannot become negative Implementation constraints - Expose both clocks through interfaces. Verification - Move wall clock during job - Advance monotonic clock past deadline Deliverables - Deadline helper and clock cases Rollout and recovery: Disable timed jobs if monotonic source is unavailable. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-102 — Validate emulated edge-job intervals before scheduling **Task · Medium priority · Foundational** noCV practice brief v5 · CTIMER-102 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define time semantics. Depends on: CTIMER-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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 zero interval creates an immediate callback loop. Enforce a documented supported interval range. Acceptance criteria - Valid intervals register - Zero negative and oversized values fail - Rejected jobs allocate no timer Implementation constraints - Do not silently clamp invalid configuration. Verification - Register valid interval - Reject zero and negative interval Deliverables - Interval validator and cases Rollout and recovery: Reject new registrations if limits cannot be enforced. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-103 — Specify fixed-delay behavior for periodic kiosk maintenance **Task · Medium priority · Intermediate** noCV practice brief v5 · CTIMER-103 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define time semantics. Depends on: CTIMER-101, CTIMER-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Long cache refreshes cause catch-up bursts because scheduling alternates between fixed-rate and fixed-delay behavior. Choose fixed-delay for this job class. Acceptance criteria - Next run starts after completion plus delay - Slow runs do not overlap - Failure still follows documented next-run policy Implementation constraints - Limit the change to the declared maintenance class. Verification - Complete short job - Complete job longer than interval Deliverables - Periodic policy and fake-clock cases Rollout and recovery: Pause periodic jobs while schedule semantics are repaired. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. ### Control job execution Prevent overlap and stale callbacks. #### CTIMER-104 — Cancel emulated edge jobs without accepting late callbacks **Bug · High priority · Advanced** noCV practice brief v5 · CTIMER-104 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control job execution. Depends on: CTIMER-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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 cancelled timer callback runs after a replacement job is registered. Bind callbacks to registration generation. Acceptance criteria - Cancel invalidates current generation - Late callback performs no work - Replacement generation can run Implementation constraints - Clearing the runtime timer alone is insufficient. Verification - Cancel before deadline - Deliver old callback after replacement Deliverables - Generation guard and race cases Rollout and recovery: Recreate scheduler instance if generations become inconsistent. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-105 — Prevent overlapping edge jobs that share one local resource **Task · High priority · Advanced** noCV practice brief v5 · CTIMER-105 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control job execution. Depends on: CTIMER-103, CTIMER-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Cache refresh and cleanup run simultaneously and contend for the same fixture directory. Add scoped single-flight admission. Acceptance criteria - Same resource runs one job - Different resources remain independent - Failure releases admission Implementation constraints - Do not introduce an unbounded global waiting queue. Verification - Run separate resources - Fail holder while another waits Deliverables - Resource admission and cases Rollout and recovery: Serialize all fixture maintenance temporarily if scoped locking fails. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-106 — Bound emulated edge-job execution attempts after failure **Story · Medium priority · Intermediate** noCV practice brief v5 · CTIMER-106 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control job execution. Depends on: CTIMER-104, CTIMER-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. A failed maintenance job retries forever and hides the original error. Add attempt limits and a terminal visible outcome. Acceptance criteria - Attempts have an explicit cap - Success clears pending retry - Exhaustion preserves failure category Implementation constraints - Retrying must reuse the same logical operation identity. Verification - Recover before cap - Fail through exhaustion Deliverables - Retry policy and deterministic cases Rollout and recovery: Disable automatic retry while retaining manual restart. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-107 — Recover due edge jobs after restart without a catch-up storm **Bug · High priority · Expert** noCV practice brief v5 · CTIMER-107 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control job execution. Depends on: CTIMER-103, CTIMER-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 70% · Storage 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. Restarting after a long pause runs every missed interval at once. Persist minimal schedule state and coalesce missed runs. Acceptance criteria - At most declared catch-up work runs - Future schedule resumes predictably - Unknown persisted version fails safely Implementation constraints - Define which jobs may be skipped because they are housekeeping. Verification - Restart after one missed run - Restart after many missed intervals Deliverables - Recovery policy and restart fixtures Rollout and recovery: Start housekeeping from a fresh delayed schedule if state is unreadable. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. ### Recover scheduler state Handle restart and overload deliberately. #### CTIMER-108 — Keep edge-job priority from starving lower-priority maintenance **Task · Medium priority · Advanced** noCV practice brief v5 · CTIMER-108 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover scheduler state. Depends on: CTIMER-105, CTIMER-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Frequent urgent cache checks prevent cleanup from ever running. Add bounded fairness to the ready queue. Acceptance criteria - High priority gets documented preference - Low priority eventually runs under bounded arrivals - Queue size remains capped Implementation constraints - State workload assumptions used for fairness checks. Verification - Run mixed-priority fixture - Continuously enqueue within supported arrival bound Deliverables - Fair queue and execution trace Rollout and recovery: Use simple round-robin while priority fairness is uncertain. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-109 — Report emulated edge-job lateness separately from duration **Chore · Low priority · Intermediate** noCV practice brief v5 · CTIMER-109 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover scheduler state. Depends on: CTIMER-101, CTIMER-108. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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-started job is blamed on execution time because metrics combine queue delay and work duration. Separate them. Acceptance criteria - Lateness measures due-to-start - Duration measures start-to-finish - Clock corrections do not corrupt elapsed metrics Implementation constraints - Report synthetic local observations, not hardware deadlines. Verification - Queue then execute job - Change wall clock during execution Deliverables - Scheduler metric schema and cases Rollout and recovery: Hide derived latency fields if clock provenance is missing. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. #### CTIMER-110 — Provide a read-only edge scheduler timeline for recovery diagnosis **Story · Medium priority · Intermediate** noCV practice brief v5 · CTIMER-110 · A deterministic edge-job scheduler emulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover scheduler state. Depends on: CTIMER-107, CTIMER-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Embedded and edge 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. Engineers cannot explain why a job was skipped after restart. Export bounded state transitions without running jobs. Acceptance criteria - Timeline identifies schedule and attempt IDs - Skipped reasons are explicit - Inspection causes no callbacks or writes Implementation constraints - Omit payloads and fixture file contents. Verification - Inspect completed sequence - Inspect exhausted and skipped job Deliverables - Timeline inspector and side-effect checks Rollout and recovery: Disable inspection fields that expose task payloads. Project prerequisites: Implement injected wall and monotonic clocks. Create synthetic jobs with controllable completion and failure. Engineer value: Practice timer semantics, cancellation and bounded scheduling. Company value: Inspect predictable edge resource use and honest execution status. 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. ## CJOUR — A power-loss-tolerant edge event journal Fictional edge display gateway stores noncritical synthetic readings while disconnected. Implement a byte-array flash emulator with explicit erase/write behavior and injected power cuts; no physical storage device is required. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Flash-storage emulator, Vitest. **Engineer value:** Practice torn writes, wear-aware batching and acknowledged durability. **Company value:** Inspect whether offline device records remain recoverable within stated constraints. **Delivery agreement:** Emulator guarantees are explicit; real flash endurance and device qualification remain separate. ### Setup prerequisites - Specify emulator page size write rules and erase behavior. - Generate synthetic records and deterministic power-cut schedules. ### Define durable records Encode and validate journal entries. #### CJOUR-101 — Model edge-journal flash writes with explicit emulator constraints **Task · Medium priority · Foundational** noCV practice brief v5 · CJOUR-101 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define durable records. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Storage systems 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 byte-array stub permits writes that real flash-like storage would reject. Declare and enforce the chosen emulator model. Acceptance criteria - Page boundaries are explicit - Forbidden bit transitions fail - Erase resets one selected page Implementation constraints - This models selected behavior and does not certify real hardware. Verification - Write allowed transition - Attempt forbidden transition without erase Deliverables - Flash emulator contract and cases Rollout and recovery: Stop journal writes when adapter behavior violates the declared model. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-102 — Encode edge-journal records with bounded length and checksum **Task · High priority · Foundational** noCV practice brief v5 · CJOUR-102 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define durable records. Depends on: CJOUR-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Storage systems 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. Truncated synthetic records are indistinguishable from valid short payloads. Add explicit length and integrity fields. Acceptance criteria - Payload bytes round-trip - Length is bounded - Checksum mismatch rejects record Implementation constraints - Checksum is corruption detection, not authentication. Verification - Encode valid record - Flip one stored byte Deliverables - Record codec and corruption cases Rollout and recovery: Keep affected pages read-only for inspection. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-103 — Assign edge-journal event identities independently from delivery attempts **Bug · Medium priority · Intermediate** noCV practice brief v5 · CJOUR-103 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define durable records. Depends on: CJOUR-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Distributed systems 30% · Storage 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. Retried uploads mint new event IDs and duplicate accepted readings. Persist identity with the original record. Acceptance criteria - Retry preserves identity - New records get distinct identity - Restart retains stored identity Implementation constraints - IDs must not encode raw reading values. Verification - Retry same record - Restart and compare identities Deliverables - Event identity contract and cases Rollout and recovery: Pause replay if stored identity cannot be recovered. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. ### Recover interrupted writes Handle commits and page boundaries. #### CJOUR-104 — Commit edge-journal records only after their marker is durable **Task · High priority · Advanced** noCV practice brief v5 · CJOUR-104 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted writes. Depends on: CJOUR-102, CJOUR-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Embedded and edge 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 record appears readable before its body finishes writing. Introduce a commit-marker protocol compatible with the emulator. Acceptance criteria - Uncommitted bodies stay invisible - Acknowledgement follows durable marker - Invalid marker cannot authorize partial body Implementation constraints - Specify write and flush ordering explicitly. Verification - Write committed fixture - Cut power before marker Deliverables - Commit protocol and cut-point tests Rollout and recovery: Disable acknowledgement if the durability barrier fails. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-105 — Recover edge-journal scanning after a torn final record **Bug · High priority · Advanced** noCV practice brief v5 · CJOUR-105 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted writes. Depends on: CJOUR-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Embedded and edge 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. Startup stops at partial data and loses earlier committed events. Scan the valid committed prefix conservatively. Acceptance criteria - Earlier committed records survive - Incomplete tail is ignored with reason - Middle corruption is not silently skipped Implementation constraints - Preserve damaged bytes for explicit local diagnosis. Verification - Cut final body write - Corrupt an earlier committed record Deliverables - Recovery scanner and fault cases Rollout and recovery: Open journal read-only when corruption is not a tail interruption. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-106 — Roll edge-journal writes onto a new page without overwriting unread events **Task · High priority · Intermediate** noCV practice brief v5 · CJOUR-106 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted writes. Depends on: CJOUR-101, CJOUR-104, CJOUR-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Storage systems 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. Page wrap overwrites unacknowledged events. Separate writable capacity from reclaimable pages. Acceptance criteria - Active unread pages remain protected - Full journal returns explicit capacity result - New page starts with validated header Implementation constraints - Do not silently discard oldest readings. Verification - Fill to page boundary - Fill entire journal without acknowledgements Deliverables - Page allocator and full-capacity cases Rollout and recovery: Stop admission when no safe writable page exists. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-107 — Recover edge-journal page generation selection after power loss **Bug · High priority · Expert** noCV practice brief v5 · CJOUR-107 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted writes. Depends on: CJOUR-105, CJOUR-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Embedded and edge 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 cut during page-header activation leaves two pages claiming to be newest. Resolve generations through a declared ordering rule. Acceptance criteria - Recovery chooses valid committed generation - Incomplete header cannot supersede valid page - Ambiguous generations fail visibly Implementation constraints - Include wrap behavior in generation comparison. Verification - Cut header activation - Exercise generation wrap fixture Deliverables - Generation selection and boundary tests Rollout and recovery: Preserve both pages and stop writes on unresolved ambiguity. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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 finite storage Reclaim acknowledged records safely. #### CJOUR-108 — Reclaim edge-journal pages only after durable delivery acknowledgements **Task · High priority · Advanced** noCV practice brief v5 · CJOUR-108 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage finite storage. Depends on: CJOUR-103, CJOUR-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · Embedded and edge 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 gateway erases a page after sending bytes, before the receiver acknowledges them. Gate reclamation on durable acknowledgements. Acceptance criteria - Sent-only records remain protected - Acknowledged complete page may erase - Crash before acknowledgement persistence keeps page Implementation constraints - Receiver stub must support replay by stable event identity. Verification - Acknowledge all page records - Timeout after receiver acceptance Deliverables - Ack ledger and reclamation cases Rollout and recovery: Pause erasure if acknowledgement state is uncertain. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-109 — Batch edge-journal metadata updates within a declared loss window **Chore · Medium priority · Advanced** noCV practice brief v5 · CJOUR-109 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage finite storage. Depends on: CJOUR-108. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Storage systems 30% · Embedded and edge 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 metadata write for every status poll causes unnecessary emulated erase work. Batch only nonauthoritative counters. Acceptance criteria - Event commits remain durable - Batching does not weaken acknowledgement protection - Counter loss window is documented Implementation constraints - Do not batch safety-critical authority or claim real endurance improvement. Verification - Compare emulator operation counts - Cut power before counter flush Deliverables - Counter batching and measured local trace Rollout and recovery: Disable batching if authority depends on buffered counters. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. #### CJOUR-110 — Inspect edge-journal pages without modifying recovery state **Story · Medium priority · Intermediate** noCV practice brief v5 · CJOUR-110 · A power-loss-tolerant edge event journal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage finite storage. Depends on: CJOUR-107, CJOUR-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 40% · Embedded and edge 30% · Storage 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. Debugging currently boots the journal and may erase pages. Add a read-only page inspector. Acceptance criteria - Reports generation and commit validity - Does not erase or rewrite - Payload display is opt-in Implementation constraints - Restrict input to explicit synthetic image files. Verification - Inspect valid image - Inspect torn and corrupt images Deliverables - Inspector and no-write assertions Rollout and recovery: Keep diagnostic mode read-only if recovery suggestions are uncertain. Project prerequisites: Specify emulator page size write rules and erase behavior. Generate synthetic records and deterministic power-cut schedules. Engineer value: Practice torn writes, wear-aware batching and acknowledged durability. Company value: Inspect whether offline device records remain recoverable within stated constraints. 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. ## CUPDATE — A recoverable edge software-update simulator Fictional information kiosks receive small generated image blobs through a local update adapter. Simulate slots and boot outcomes in software; do not flash hardware or execute image contents. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Slot emulator, Filesystem adapter, Vitest. **Engineer value:** Practice update state machines and recoverable activation. **Company value:** Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. **Delivery agreement:** Use local emulator evidence only; signing fixtures never authorize production devices. ### Setup prerequisites - Generate inert byte images with manifests and development-only signing fixtures. - Implement simulated boot success failure and power-cut points. ### Validate update candidates Define version and image integrity. #### CUPDATE-101 — Parse edge-update manifests with explicit supported versions **Task · Medium priority · Foundational** noCV practice brief v5 · CUPDATE-101 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Unknown manifest fields are treated as executable update instructions. Replace loose parsing with a bounded schema. Acceptance criteria - Known schema parses - Unsupported version rejects - Oversized fields reject before allocation Implementation constraints - Manifests are data and never scripts. Verification - Parse valid inert image manifest - Reject unsupported version Deliverables - Manifest parser and cases Rollout and recovery: Reject new updates when schema identity is uncertain. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-102 — Verify edge-update image size and digest before staging **Bug · High priority · Foundational** noCV practice brief v5 · CUPDATE-102 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. Depends on: CUPDATE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Embedded and edge 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 truncated synthetic image is marked downloaded. Gate staging on complete integrity verification. Acceptance criteria - Size and digest both match - Mismatch blocks staging - Current active slot stays untouched Implementation constraints - Stream verification under an explicit memory bound. Verification - Verify generated image - Truncate or flip a byte Deliverables - Image verifier and corruption cases Rollout and recovery: Keep failed images quarantined from slot activation. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-103 — Validate edge-update manifests using local trust fixtures **Task · High priority · Intermediate** noCV practice brief v5 · CUPDATE-103 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. Depends on: CUPDATE-101, CUPDATE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Embedded and edge 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 simulator accepts any manifest signature. Add a trust adapter using ephemeral development keys. Acceptance criteria - Trusted fixture signature passes - Unknown signer fails - Tampered manifest fails Implementation constraints - No private keys enter source control or production configuration. Verification - Verify local signed fixture - Change signed manifest field Deliverables - Trust adapter and negative cases Rollout and recovery: Disable update acceptance if trusted verification is unavailable. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. ### Stage and activate Keep a recoverable known-good slot. #### CUPDATE-104 — Write edge-update images only into the inactive simulated slot **Task · High priority · Advanced** noCV practice brief v5 · CUPDATE-104 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-102, CUPDATE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Storage systems 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. Update copying overwrites the currently selected image before validation finishes. Restrict staging to the inactive slot. Acceptance criteria - Active slot remains byte-identical - Inactive slot gets candidate bytes - Failed write leaves active selection unchanged Implementation constraints - Slot paths must stay inside the fixture root. Verification - Stage valid image - Fail copy midway Deliverables - Slot writer and isolation cases Rollout and recovery: Abandon inactive candidate and retain active slot. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-105 — Record edge-update activation intent before changing the boot selector **Bug · High priority · Expert** noCV practice brief v5 · CUPDATE-105 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Embedded and edge 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 power cut during selector change leaves no recoverable activation decision. Journal intent and candidate identity. Acceptance criteria - Intent is durable before selector change - Recovery identifies pending activation - Repeated recovery is deterministic Implementation constraints - Do not execute image bytes; use boot-result stubs. Verification - Cut before selector update - Cut after selector update Deliverables - Activation journal and cut-point matrix Rollout and recovery: Restore prior validated selector when activation state is ambiguous. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-106 — Mark an edge-update candidate healthy only after simulated boot confirmation **Task · High priority · Intermediate** noCV practice brief v5 · CUPDATE-106 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Merely selecting a slot labels the update successful. Require an explicit boot acknowledgement from the emulator. Acceptance criteria - Selection yields pending health - Confirmation marks success - Missing confirmation reaches bounded failure state Implementation constraints - Health means only the declared simulator check. Verification - Confirm successful boot - Omit confirmation past deadline Deliverables - Health transition and timer cases Rollout and recovery: Keep prior slot available until health acknowledgement commits. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-107 — Roll back failed edge-update boots without retry loops **Story · High priority · Advanced** noCV practice brief v5 · CUPDATE-107 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-105, CUPDATE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. A failing candidate is selected repeatedly on each restart. Persist failed-candidate disposition and restore the known-good slot. Acceptance criteria - Failed candidate does not auto-reactivate - Prior slot is selected - No valid fallback produces explicit recovery-required state Implementation constraints - Do not label fallback existence without validating its metadata. Verification - Fail candidate boot - Invalidate both slot manifests Deliverables - Rollback coordinator and failure cases Rollout and recovery: Stop automatic activation when no validated fallback exists. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. ### Handle local rollout outcomes Bound retries and explain simulator status. #### CUPDATE-108 — Reject unintended edge-update downgrades under an explicit version policy **Task · High priority · Advanced** noCV practice brief v5 · CUPDATE-108 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-103, CUPDATE-107. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Embedded and edge 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. Replaying an older signed image silently reverts a device. Add a declared minimum-version policy with a separate recovery mode. Acceptance criteria - Normal mode rejects lower versions - Equal-version replay is idempotent - Recovery override is explicit and audited locally Implementation constraints - Version order must be defined, not string-compared casually. Verification - Accept newer fixture - Replay older signed fixture Deliverables - Version policy and override cases Rollout and recovery: Disable updates if version comparison is ambiguous. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-109 — Limit concurrent downloads in the simulated kiosk update cohort **Chore · Medium priority · Intermediate** noCV practice brief v5 · CUPDATE-109 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-104, CUPDATE-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Embedded and edge 40% · 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. A local cohort starts every download at once and overwhelms the provider stub. Bound concurrency and retain per-device outcome. Acceptance criteria - Active transfers stay within limit - Failures release slots - One device retry cannot starve all others Implementation constraints - Cohort fixtures contain synthetic device IDs only. Verification - Update small cohort - Fail one transfer repeatedly Deliverables - Download scheduler and fairness cases Rollout and recovery: Reduce concurrency to one while queue behavior is repaired. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. #### CUPDATE-110 — Report edge-update stages without overstating fleet success **Story · Medium priority · Intermediate** noCV practice brief v5 · CUPDATE-110 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-107, CUPDATE-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Embedded and edge 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. Dashboard counts downloaded images as updated kiosks. Project download, staged, boot-pending, healthy and rolled-back separately. Acceptance criteria - Healthy requires committed boot confirmation - Rollback remains visible - Unknown outcomes are not counted successful Implementation constraints - Reports describe simulator outcomes, not real-device certification. Verification - Complete one simulated update - Interrupt another before boot confirmation Deliverables - Update status report and consistency checks Rollout and recovery: Hide aggregate success if per-device authority is unresolved. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared 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. ## CCONFIG — Versioned edge configuration with an offline gateway Fictional information-display gateways receive brightness schedules and cache limits. These settings affect only a software display emulator; no real devices, safety controls or customer data are used. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Gateway emulator, SQLite adapter, Vitest. **Engineer value:** Practice desired/reported state, compatibility and rollback. **Company value:** Inspect whether remote configuration preserves working settings through offline and partial outcomes. **Delivery agreement:** Deliver local simulation changes; hardware validation and external fleet deployment are excluded. ### Setup prerequisites - Define synthetic configuration schema and supported device capabilities. - Implement local control-plane and gateway adapters with delayed messages. ### Specify configuration contracts Validate and scope desired settings. #### CCONFIG-101 — Validate emulated display brightness and cache-limit settings **Task · Medium priority · Foundational** noCV practice brief v5 · CCONFIG-101 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify configuration contracts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. The gateway accepts negative cache capacity and brightness above the declared range. Add a bounded schema. Acceptance criteria - Supported ranges pass - Unknown fields reject - Invalid settings do not alter active state Implementation constraints - Schema limits are emulator contracts, not hardware ratings. Verification - Apply valid fixture values - Reject negative and oversized settings Deliverables - Configuration schema and cases Rollout and recovery: Reject incoming updates if schema validation fails. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-102 — Keep desired and reported edge configuration separate **Bug · Medium priority · Foundational** noCV practice brief v5 · CCONFIG-102 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify configuration contracts. Depends on: CCONFIG-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Distributed systems 30% · Frontend 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. Sending a setting immediately changes the dashboard to Applied before the gateway responds. Store separate desired and reported revisions. Acceptance criteria - Sending changes desired state - Acknowledgement changes reported state - Mismatch appears as pending drift Implementation constraints - Delivery is not application acknowledgement. Verification - Send then acknowledge - Drop delivery and inspect drift Deliverables - State model and projection cases Rollout and recovery: Stop displaying Applied when acknowledgement is absent. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-103 — Scope emulated gateway configuration reads by organization **Task · High priority · Intermediate** noCV practice brief v5 · CCONFIG-103 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify configuration contracts. Depends on: CCONFIG-101, CCONFIG-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Embedded and edge 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 guessed gateway ID exposes another organization's desired settings. Enforce tenant scope at repository lookup. Acceptance criteria - Owner reads permitted gateway - Foreign lookup is denied - Denied response omits settings Implementation constraints - Synthetic gateway IDs never establish authority alone. Verification - Read own fixture - Read foreign gateway by known ID Deliverables - Scoped repository and denial cases Rollout and recovery: Disable configuration reads when ownership cannot be verified. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. ### Apply settings deliberately Handle revisions and partial failures. #### CCONFIG-104 — Reject stale configuration revisions arriving at the edge gateway **Bug · High priority · Advanced** noCV practice brief v5 · CCONFIG-104 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply settings deliberately. Depends on: CCONFIG-102, CCONFIG-103. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Embedded and edge 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. Delayed delivery overwrites a newer brightness schedule. Compare monotonic desired revisions before applying. Acceptance criteria - Newer revision may apply - Older revision is rejected - Equal matching revision replays safely Implementation constraints - Reused revision with different payload is a conflict. Verification - Deliver increasing revisions - Deliver old or conflicting revision Deliverables - Revision guard and ordering cases Rollout and recovery: Request a fresh authoritative snapshot on conflict. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-105 — Stage edge settings before committing a complete configuration **Task · High priority · Advanced** noCV practice brief v5 · CCONFIG-105 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply settings deliberately. Depends on: CCONFIG-101, CCONFIG-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Storage systems 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. Applying brightness succeeds while cache settings fail, leaving an undocumented mixed state. Validate and stage the complete supported configuration. Acceptance criteria - All fields validate before mutation - Commit selects one complete revision - Failure retains prior active revision Implementation constraints - This ticket assumes reversible emulator setters; document that boundary. Verification - Apply valid full revision - Inject failure during staging Deliverables - Staged apply protocol and failure cases Rollout and recovery: Restore previous configuration if staging cannot remain isolated. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-106 — Reject edge settings unsupported by the declared gateway capability version **Story · Medium priority · Intermediate** noCV practice brief v5 · CCONFIG-106 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply settings deliberately. Depends on: CCONFIG-104, CCONFIG-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Older gateway emulators silently ignore new settings while reporting success. Check capability compatibility explicitly. Acceptance criteria - Supported configuration applies - Unsupported fields report incompatibility - Reported revision does not advance on rejection Implementation constraints - Do not infer capability from device display names. Verification - Apply to compatible fixture - Apply new field to older capability Deliverables - Compatibility check and cases Rollout and recovery: Keep existing revision on unsupported gateways. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-107 — Persist edge-configuration acknowledgement after active settings commit **Bug · High priority · Expert** noCV practice brief v5 · CCONFIG-107 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply settings deliberately. Depends on: CCONFIG-105, CCONFIG-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 40% · Storage systems 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. A crash after applying settings but before reporting leaves the control plane uncertain and repeated applies inconsistent. Reconcile local active revision on restart. Acceptance criteria - Active revision persists with settings - Restart can replay acknowledgement - Uncommitted settings cannot be reported applied Implementation constraints - Define commit ordering in the local adapter. Verification - Crash after settings commit - Crash before commit Deliverables - Apply journal and restart cases Rollout and recovery: Pause new applies until active-state reconciliation completes. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. ### Recover gateway state Explain offline drift and bound retries. #### CCONFIG-108 — Coalesce offline edge configuration deliveries to the latest eligible revision **Task · Medium priority · Advanced** noCV practice brief v5 · CCONFIG-108 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover gateway state. Depends on: CCONFIG-104, CCONFIG-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Embedded and edge 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 gateway reconnects to hundreds of obsolete brightness changes. Deliver the latest complete eligible snapshot deliberately. Acceptance criteria - Obsolete pending revisions are superseded - Latest revision remains auditable - Required transition constraints are checked Implementation constraints - Coalescing is permitted only for this replaceable configuration contract. Verification - Reconnect after several revisions - Include incompatible latest revision Deliverables - Offline delivery planner and cases Rollout and recovery: Send an explicit full snapshot if coalescing cannot prove eligibility. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-109 — Expose edge-configuration rollback as a new desired revision **Story · Medium priority · Intermediate** noCV practice brief v5 · CCONFIG-109 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover gateway state. Depends on: CCONFIG-106, CCONFIG-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Distributed systems 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. Operators lower the revision number to restore older values and gateways reject it as stale. Create a new revision carrying the prior values. Acceptance criteria - Rollback increments revision - Prior values are copied explicitly - Current capability validation still applies Implementation constraints - Preserve original revision history. Verification - Roll back supported values - Attempt rollback containing now-unsupported field Deliverables - Rollback command and history cases Rollout and recovery: Retain current settings if rollback validation fails. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. #### CCONFIG-110 — Summarize edge-configuration drift without logging setting payloads **Chore · Low priority · Intermediate** noCV practice brief v5 · CCONFIG-110 · Versioned edge configuration with an offline gateway Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover gateway state. Depends on: CCONFIG-107, CCONFIG-109. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Embedded and edge 30% · 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. Drift diagnosis logs full configuration documents unnecessarily. Report revision gaps and typed rejection reasons. Acceptance criteria - Summary shows desired and reported revisions - Payload values are omitted - Offline uncertainty is explicit Implementation constraints - Use aggregate synthetic fleet observations only. Verification - Inspect converged gateway - Inspect offline and incompatible gateways Deliverables - Drift report and data-exclusion cases Rollout and recovery: Disable detailed diagnostics if configuration values leak. Project prerequisites: Define synthetic configuration schema and supported device capabilities. Implement local control-plane and gateway adapters with delayed messages. Engineer value: Practice desired/reported state, compatibility and rollback. Company value: Inspect whether remote configuration preserves working settings through offline and partial outcomes. 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. ## PLATENCY — Find the missing seconds in the quote API A fictional freight broker sees slow quote responses at dispatch handover. The service looks healthy in average-latency charts, yet a few long requests occupy every worker. Build a small synthetic quote service and controlled dependency stub before taking implementation tickets. **Field:** Performance engineering. **Suggested stack:** TypeScript, Node.js, PostgreSQL, OpenTelemetry, k6. **Engineer value:** Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. **Company value:** Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. **Delivery agreement:** Ten tickets in three phases. Estimates assume the local service and generator already exist; all load runs stay in the owned local environment. Budgets are exercise requirements, not measured platform results. ### Setup prerequisites - Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. - Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. ### Establish trustworthy measurements Define the traffic shape and separate time spent waiting from time spent working. #### PLATENCY-101 — Write down the traffic mix before comparing quote timings **Task · Medium priority · Foundational** noCV practice brief v5 · PLATENCY-101 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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 last benchmark sent one route repeatedly. Dispatch says the slow period contains mostly unique routes and a small number of expensive multi-stop quotes. Acceptance criteria - Create a seeded mix of 70% single-stop, 25% multi-stop and 5% invalid requests across 1,000 synthetic routes. - Record concurrency, arrival rate, seed, payload sizes, runtime and resource limits in the run manifest. - Count every attempted request, including validation failures and client timeouts, against the expected result class. Implementation constraints - Keep the fixture bounded; random seeds must reproduce both request order and expected quote inputs. Verification - Replay the same seed twice and compare request identities and expected outputs. - Change the seed and confirm the traffic proportions stay within the declared rounding rule. Deliverables - Workload manifest and deterministic request generator Rollout and recovery: Commit the baseline manifest separately; a workload change starts a new comparison series. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-102 — Show quote latency percentiles alongside rejected and timed-out requests **Story · High priority · Intermediate** noCV practice brief v5 · PLATENCY-102 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: PLATENCY-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Site reliability 30% · Privacy 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. The dashboard median improves when the slowest requests time out and disappear from successful-response measurements. Acceptance criteria - Report p50, p95 and p99 with sample counts for completed requests, and separate timeout, rejection and transport-error counts. - State the observation window and histogram precision; do not average percentiles across workers. - Keep route identifiers, customer IDs and quote payloads out of metric labels. Implementation constraints - Use bounded result-class labels and merge histogram counts before computing aggregate percentiles. Verification - Replay a fixture with known short, long and timed-out requests and reconcile all attempts. - Compare merged-worker results with the same samples processed in one worker, within the declared histogram precision. Deliverables - Latency dashboard definition and aggregation regression fixture Rollout and recovery: Run the new view beside the existing chart for the synthetic workload; keep raw counters if rendering is reverted. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-103 — Separate quote queue time from carrier lookup time **Task · Medium priority · Foundational** noCV practice brief v5 · PLATENCY-103 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: PLATENCY-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. A trace labels the entire request as carrier latency, but the stub returns quickly when called outside the API. Acceptance criteria - Record monotonic durations for admission wait, application work and carrier lookup with one request correlation identifier. - Make the phase durations reconcile with total server duration within documented instrumentation overhead. - Record cancellation and missing-span states explicitly instead of inventing zero-duration work. Implementation constraints - Do not put route payloads or credentials into spans; use a bounded synthetic request identifier for this exercise. Verification - Inject 100 ms of queue delay and verify it appears outside the carrier span. - Cancel a queued request and confirm the trace distinguishes waiting from a lookup that never started. Deliverables - Span boundaries and an annotated trace from the controlled stub Rollout and recovery: Enable sampling locally first; disable extra spans independently if instrumentation changes the measured workload. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. ### Remove demonstrated bottlenecks Change one constrained path at a time while checking exact quote outputs. #### PLATENCY-104 — Remove repeated tariff parsing from the quote hot path **Bug · High priority · Advanced** noCV practice brief v5 · PLATENCY-104 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. A CPU profile shows every quote parsing the same tariff document, including requests that use the same immutable tariff revision. Acceptance criteria - Parse once per tariff revision and cap retained revisions with an explicit eviction policy. - Keep quote totals and rounding behavior identical to the uncached path for the seeded fixture. - Reject a malformed new revision without replacing the last valid parsed tariff. Implementation constraints - Measure before and after with the same revision distribution; do not cache request-specific discounts in the shared tariff object. Verification - Compare every synthetic quote against the uncached implementation across two valid revisions. - Alternate malformed and valid revisions, then force eviction and verify both bounded memory and correct reparsing. Deliverables - Profile comparison, bounded parsed-tariff cache and regression tests Rollout and recovery: Gate parsed-tariff reuse behind a switch; reverting uses the original parser and discards only derived cache entries. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-105 — Stop expired quotes from holding carrier connections **Bug · High priority · Advanced** noCV practice brief v5 · PLATENCY-105 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-102, PLATENCY-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Networking 30% · 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. A client disconnects after its deadline, but the carrier lookup continues and consumes one of the few available connections. Acceptance criteria - Propagate the remaining deadline through queue admission and the carrier client. - Release the connection and remove queued work when the request is cancelled, including cancellation before dispatch. - Return one bounded timeout outcome without automatically retrying a request whose caller has left. Implementation constraints - Use the stub to control headers, body completion and connection close separately; wall-clock sleeps alone do not prove cleanup. Verification - Cancel before dispatch, while waiting for headers and during a streamed response; count active work returning to baseline. - Race normal completion against cancellation and confirm one response classification and no unhandled rejection. Deliverables - Deadline propagation and deterministic cancellation tests Rollout and recovery: Canary the deadline path with active-connection counters; restore the previous client only after pending work drains. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-106 — Bound parallel carrier lookups without serializing every quote **Story · High priority · Advanced** noCV practice brief v5 · PLATENCY-106 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Backend 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. Multi-stop quotes fan out immediately. A burst exhausts the carrier stub connection pool and slows unrelated single-stop traffic. Acceptance criteria - Apply a configurable global in-flight limit and a bounded admission queue. - Remove cancelled entries promptly and define fairness so a large quote cannot monopolize all new slots. - Preserve the required carrier results or return an explicit incomplete-quote outcome; never silently price from a partial result. Implementation constraints - Compare limits using the fixed traffic mix and a stub with a declared service-time distribution. Verification - Run single-stop and multi-stop requests together and verify the configured concurrency ceiling. - Overfill the queue, cancel its head and inject a carrier failure; verify forward progress and no leaked permit. Deliverables - Admission controller, mixed-traffic measurements and permit invariants Rollout and recovery: Start with the current safe connection limit; queue rejection is observable and the feature switch restores the previous dispatch path. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-107 — Check whether quote serialization is blocking unrelated requests **Task · Medium priority · Intermediate** noCV practice brief v5 · PLATENCY-107 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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 largest multi-stop responses correlate with event-loop delay. The team has proposed adding workers before confirming where time is spent. Acceptance criteria - Capture CPU and event-loop delay measurements for small and maximum-size synthetic quote responses. - Separate JSON serialization cost from database and dependency time in the experiment. - Produce a decision note identifying the measured bottleneck, uncertainty and one bounded next change; report when the hypothesis is unsupported. Implementation constraints - Use three repeated baseline runs after warmup on the same runtime and resource limits; save the measurement commands. Verification - Repeat with a prebuilt response body to isolate serialization while retaining the same payload size. - Run a small health request concurrently and compare its tail latency with and without the large-response workload. Deliverables - Reproducible profiling report and supported next-step decision Rollout and recovery: This investigation changes no serving path; retain the baseline commands for the implementation review. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. ### Protect the improvement Use tail-aware admission and a reversible release gate. #### PLATENCY-108 — Choose an overload policy from the quote deadline budget **Task · High priority · Expert** noCV practice brief v5 · PLATENCY-108 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-102, PLATENCY-105, PLATENCY-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. At overload, a larger queue increases completed work but most quotes arrive after the dispatch screen has already given up. Acceptance criteria - Compare at least two admission policies at 0.5, 1.0 and 1.5 times the measured sustainable arrival rate. - Evaluate deadline success rate, rejection rate, p99 and queue depth together; document the selected tradeoff. - Implement the selected bounded policy and retain exact pricing correctness for every admitted request. Implementation constraints - Use an open-loop arrival schedule and account for generator saturation; define sustainable rate from the recorded local baseline, not a guessed production number. Verification - Run three repetitions per load level after fixed warmup and publish spread, request counts and all timeout outcomes. - Inject a carrier slowdown midway through a run and show queue depth remains bounded and recovery does not require restart. Deliverables - Admission decision record, load results and overload recovery regression Rollout and recovery: Canary against the declared deadline-success guardrail; revert policy configuration if correctness or rejection behavior differs from the approved contract. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-109 — Make the quote benchmark fail when the generator cannot keep up **Chore · Medium priority · Intermediate** noCV practice brief v5 · PLATENCY-109 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-101, PLATENCY-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. A promising result came from a generator sharing the API CPU quota. It slowed its own arrivals and reported a workload the service never received. Acceptance criteria - Record scheduled versus actual send time and count requests the generator could not issue. - Invalidate comparisons when dispatch lag exceeds the manifest threshold or achieved load falls below the declared tolerance. - Keep server and generator resource measurements distinguishable even when both run on one development machine. Implementation constraints - Document the local topology and quota allocation; do not require a paid load-testing service. Verification - Throttle the generator deliberately and verify the run is rejected as incomparable. - Run a valid low-load fixture and reconcile planned, sent, completed and failed request totals. Deliverables - Generator health gate and an intentionally invalid benchmark sample Rollout and recovery: Add the gate to the local benchmark command before accepting further performance comparisons. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. #### PLATENCY-110 — Gate quote changes on repeated tail-latency and correctness checks **Chore · High priority · Expert** noCV practice brief v5 · PLATENCY-110 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-104, PLATENCY-106, PLATENCY-108, PLATENCY-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality 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. The team can demonstrate one fast run, but it has no rule for accepting noisy results or reverting a change that prices correctly only at low concurrency. Acceptance criteria - Use the fixed workload and three paired runs after warmup; report all runs and median p99 with spread. - For this exercise require unchanged fixture outputs, no higher timeout rate and at least 15% lower median p99 at the declared baseline arrival rate. - Mark an unstable or generator-invalid result inconclusive and stop promotion; retain the prior configuration and a documented rollback command. Implementation constraints - The 15% threshold is an exercise acceptance budget on the declared machine, not a universal performance promise. Verification - Run the candidate and baseline in alternating order and retain raw histograms and output comparisons. - Introduce a known pricing regression and a deliberately slow candidate separately; both must block the release gate for the relevant reason. Deliverables - Repeatable release check, run artifacts and rollback rehearsal notes Rollout and recovery: Promote only within the synthetic environment after the gate passes; restore the previous configuration and repeat the same workload to verify recovery. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. 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. ## PQUERY — Keep the operations inbox fast as history grows A fictional maintenance service lists open work orders beside years of closed history. A query that was cheap in a small demo now scans far more rows than it returns. Recreate the schema and synthetic workload locally; no customer database or supplied fixture is assumed. **Field:** Performance engineering. **Suggested stack:** PostgreSQL, SQL, TypeScript, pg_stat_statements. **Engineer value:** Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. **Company value:** Create reproducible query diagnostics and reversible index or query proposals for an operational application. **Delivery agreement:** Ten tickets from workload definition to guarded migration. Estimates exclude database setup and predecessor tickets; all destructive data fixtures remain local and synthetic. ### Setup prerequisites - Create an isolated local database with tenants, work orders and assignment history. - Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. ### Reproduce the slow inbox Make skew, query behavior and baseline measurements inspectable. #### PQUERY-101 — Seed an inbox where one tenant owns most of the closed history **Task · Medium priority · Foundational** noCV practice brief v5 · PQUERY-101 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce the slow inbox. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Quality engineering 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. The existing fixture spreads rows evenly across tenants. It cannot reproduce the large account whose open-work view is slow. Acceptance criteria - Seed 200,000 rows across 100 tenants with one tenant owning 60% of rows and documented open/closed ratios. - Include tied creation times, unassigned work and tenants with no matching rows. - Generate deterministic expected inbox IDs for named filter and ordering cases. Implementation constraints - Keep tenant identities fictitious and use a manifest so row counts and skew are explicit. Verification - Rebuild from the same seed and compare per-tenant counts and expected inbox results. - Run the empty-tenant and timestamp-tie cases and verify a deterministic order. Deliverables - Seed generator, distribution summary and expected-result fixtures Rollout and recovery: Load only a disposable development database; make the rebuild command reject an unrecognized database target. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-102 — Capture buffer reads and row estimates for the slow inbox query **Task · Medium priority · Foundational** noCV practice brief v5 · PQUERY-102 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce the slow inbox. Depends on: PQUERY-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Performance 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. The ticket says the query takes seconds but contains no plan, parameters or indication of whether the cache was warm. Acceptance criteria - Save EXPLAIN ANALYZE with buffers for the large, median and empty tenant fixtures. - Record query parameters, statistics freshness, cache-warmup procedure and database resource settings. - Identify estimate-versus-actual row differences and time-consuming nodes without claiming a fix from plan shape alone. Implementation constraints - Use SELECT-only plans here; running ANALYZE on mutating statements would execute them. Verification - Repeat each parameter case three times after the declared warmup and report all durations. - Verify the captured query returns the fixture IDs from the baseline contract. Deliverables - Annotated plans and reproducible capture command Rollout and recovery: Keep the baseline artifacts unchanged when evaluating candidate queries; new fixture revisions get new run labels. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-103 — Count hidden assignment queries made by one inbox request **Bug · High priority · Intermediate** noCV practice brief v5 · PQUERY-103 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reproduce the slow inbox. Depends on: PQUERY-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Backend 30% · Database 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 main SQL query is quick, but the API loads the latest assignee separately for every visible work order. Acceptance criteria - Record the query count for page sizes 1, 20 and 100 without storing raw tenant payloads in logs. - Add a request-level assertion exposing query growth proportional to returned rows. - Preserve assignment ordering, including equal timestamps and work orders with no history. Implementation constraints - Instrument the local database client boundary so lazy ORM loads are counted as well as explicit queries. Verification - Request all three page sizes and compare total database calls. - Use a work order with multiple assignment records and verify the selected assignee matches the documented tie-breaker. Deliverables - Query-count regression and assignment fixture Rollout and recovery: Enable detailed counting in the local investigation only; retain a bounded aggregate if instrumentation is later adapted for deployment. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. ### Change the expensive paths Reduce unnecessary reads while preserving filter, ordering and authorization semantics. #### PQUERY-104 — Batch latest-assignee lookup for the current inbox page **Story · High priority · Advanced** noCV practice brief v5 · PQUERY-104 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Change the expensive paths. Depends on: PQUERY-102, PQUERY-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Fetching one assignee per work order makes latency increase with page size even after the main inbox query is tuned. Acceptance criteria - Resolve assignments in a bounded number of queries independent of page size up to 100. - Preserve tenant scope in every lookup and return one deterministic latest assignment per visible work order. - Return identical response data to the baseline fixture, including missing assignments. Implementation constraints - Compare a batched lookup and a lateral or window-query alternative; record the chosen tradeoff using the seeded distribution. Verification - Compare complete responses and query counts for page sizes 1, 20 and 100. - Inject a foreign-tenant assignment ID into the request fixture and verify it cannot be returned. Deliverables - Batched implementation, response equivalence tests and query-count results Rollout and recovery: Switch the lookup path independently; revert to the previous implementation if equivalence or tenant checks fail. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-105 — Evaluate a partial index for open work without slowing closure updates **Task · High priority · Advanced** noCV practice brief v5 · PQUERY-105 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Change the expensive paths. Depends on: PQUERY-101, PQUERY-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Performance 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. Only a small fraction of work orders remain open. A broad index makes the open inbox faster but adds substantial storage and maintenance cost. Acceptance criteria - Compare the current plan with at least one partial index aligned with the actual open-state predicate and order. - Measure index size, inbox latency and update throughput for work moving into and out of the indexed state. - Keep the candidate only if its read benefit and write tradeoff satisfy explicitly stated exercise budgets. Implementation constraints - Use three paired runs on the same synthetic data and settings; do not force index use or disable planner options to manufacture a result. Verification - Run open, closed and mixed-state filters and verify both result equivalence and selected plans. - Close and reopen a fixed batch while reading the inbox; report lock waits, write duration and index size. Deliverables - Index decision record, migration draft and comparative measurements Rollout and recovery: Apply the index in the isolated database first; the rollback drops only the added index and preserves all work-order data. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-106 — Replace deep offset paging with a stable inbox cursor **Story · High priority · Advanced** noCV practice brief v5 · PQUERY-106 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Change the expensive paths. Depends on: PQUERY-101, PQUERY-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · API design 40% · 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. An operator reaches old open work through hundreds of pages. Each offset request scans and discards an increasing number of matching rows. Acceptance criteria - Use a stable sort tuple with a unique tie-breaker and an opaque versioned cursor. - Bind the cursor to the tenant and filter contract; reject mismatched or malformed cursors. - Document concurrent-insert behavior and preserve a bounded page size without promising a snapshot across requests. Implementation constraints - Measure shallow and deep page requests against the same fixture; keep the response contract explicit for clients migrating from offsets. Verification - Traverse the unchanged fixture and compare all returned IDs with the expected sorted set without duplicates or omissions. - Insert a tied-timestamp row between requests and test the documented behavior; reject a cursor from another tenant. Deliverables - Cursor contract, implementation and depth-comparison report Rollout and recovery: Offer the cursor route as an explicit version and migrate the local client behind a switch; retain the offset route during rehearsal. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-107 — Explain the bad prepared plan used for the largest tenant **Bug · Medium priority · Expert** noCV practice brief v5 · PQUERY-107 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Change the expensive paths. Depends on: PQUERY-101, PQUERY-102, PQUERY-105. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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 same prepared inbox statement serves tiny tenants and the dominant tenant. A plan that works for one distribution performs poorly for the other. Acceptance criteria - Reproduce the plan difference with documented preparation and execution sequences. - Compare statistics correction, query restructuring and bounded per-query planning choices; select a justified option. - Keep tenant scope and result ordering unchanged, and document planning overhead as part of the decision. Implementation constraints - Do not change a global planner setting as an unexplained workaround; record the exact PostgreSQL version because planning behavior matters. Verification - Alternate large and small tenant executions across repeated sessions and retain planning plus execution measurements. - Rebuild statistics after a distribution change and verify the selected solution remains correct or clearly flags an invalid baseline. Deliverables - Prepared-plan reproduction and a supported mitigation with regression cases Rollout and recovery: Limit any configuration change to the affected query path; remove it and restore the baseline query if small-tenant latency breaches its budget. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. ### Check write cost and deployment behavior Choose a supported improvement and rehearse its migration and rollback. #### PQUERY-108 — Rehearse the inbox index migration while writes continue **Chore · High priority · Advanced** noCV practice brief v5 · PQUERY-108 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Check write cost and deployment behavior. Depends on: PQUERY-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Site reliability 30% · Performance engineering 10%. 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 proposed index works after a clean restore. Nobody has checked what happens when creation is interrupted while the application is updating work orders. Acceptance criteria - Run the migration with a bounded concurrent write fixture and record locks and write failures. - Detect an interrupted or invalid index and define an idempotent retry procedure. - Provide an explicit rollback that does not remove an index belonging to another migration. Implementation constraints - Use PostgreSQL-supported online index operations with their transaction restrictions; record commands and ownership checks in the runbook. Verification - Interrupt index creation in the disposable database, inspect its state and exercise recovery. - Compare work-order counts and IDs before and after migration, retry and rollback while the write fixture runs. Deliverables - Migration, interruption rehearsal and operator recovery notes Rollout and recovery: Require the local concurrent-write rehearsal before proposing deployment; stop if lock duration or data reconciliation violates the stated budget. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-109 — Keep performance fixtures useful after the inbox schema changes **Chore · Medium priority · Intermediate** noCV practice brief v5 · PQUERY-109 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Check write cost and deployment behavior. Depends on: PQUERY-101, PQUERY-104, PQUERY-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Data engineering 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 new nullable column changed the seed loader. The benchmark still completes, but most rows now take a cheap fallback path that users rarely see. Acceptance criteria - Validate row counts, state distributions, null ratios and assignment fan-out before a run. - Reject fixtures whose version or invariants do not match the query comparison manifest. - Retain representative expected responses so a faster wrong query cannot pass. Implementation constraints - Express fixture invariants separately from the query implementation; avoid asserting only that SQL returns some rows. Verification - Deliberately skew null ratios and remove assignment history; the fixture gate must report both changes. - Regenerate the approved fixture and run the same checks successfully without hand-edited counts. Deliverables - Fixture-validation command and schema-change procedure Rollout and recovery: Run validation before every benchmark; invalid data stops comparison and is rebuilt in the disposable database. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. #### PQUERY-110 — Publish the inbox query decision with both latency and write cost **Task · High priority · Expert** noCV practice brief v5 · PQUERY-110 · Keep the operations inbox fast as history grows Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Check write cost and deployment behavior. Depends on: PQUERY-104, PQUERY-106, PQUERY-107, PQUERY-108, PQUERY-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Database 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. The review has several attractive charts but no single explanation of which changes should ship together or what would trigger rollback. Acceptance criteria - Compare baseline and candidate with three paired warmed runs at fixed concurrency, reporting p95, p99, query count and buffer reads. - For the exercise require at least 20% lower median p95 for the dominant-tenant open view, no more than 10% loss in closure-update throughput and exact fixture equivalence. - List the retained and rejected changes, noisy or inconclusive cases, migration order and rollback triggers. Implementation constraints - These relative thresholds are local exercise gates; report all repetitions and do not claim production improvement from synthetic results. Verification - Run both large and median tenant workloads alongside the closure-update fixture. - Rehearse rollback and rerun correctness plus the baseline workload to confirm recovery is understood. Deliverables - Query-performance decision, raw run results and migration handoff Rollout and recovery: Advance only the documented candidate within the exercise environment; keep previous query and index definitions available for a bounded rollback. Project prerequisites: Create an isolated local database with tenants, work orders and assignment history. Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits. Engineer value: Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries. Company value: Create reproducible query diagnostics and reversible index or query proposals for an operational application. 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. ## PWEB — Make a large scheduling screen respond to the next click A fictional repair coordinator opens a week containing 2,000 jobs. The initial page loads, but filtering and selecting a job can freeze the interface. Build a synthetic scheduling screen with keyboard operation before measuring changes. **Field:** Performance engineering. **Suggested stack:** TypeScript, React, CSS Modules, Playwright, Browser Performance API. **Engineer value:** Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. **Company value:** Produce a bounded performance investigation and regression workflow for dense operational interfaces. **Delivery agreement:** Ten tickets across measurement, implementation and regression phases. Lab timings apply only to the documented local browser setup; field-user performance is not inferred. ### Setup prerequisites - Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. - Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. ### Capture the slow interactions Record repeatable navigation and interaction traces with correct results. #### PWEB-101 — Record the schedule workflow that freezes after filtering **Task · Medium priority · Foundational** noCV practice brief v5 · PWEB-101 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality engineering 30% · Frontend 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 issue report says the screen feels slow. Developers reproduce it with different data and disagree about which interaction is responsible. Acceptance criteria - Define a deterministic sequence: load 2,000 jobs, filter by technician, select the final visible job and clear the filter. - Record build mode, browser version, viewport and any throttling alongside trace timestamps. - Assert the selected job and final result count so an incomplete interaction cannot appear fast. Implementation constraints - Use only synthetic names and job descriptions; record navigation and interaction phases separately. Verification - Replay the sequence twice and confirm identical selected IDs and result counts. - Run with an empty technician result and verify the sequence reports that expected state rather than timing an absent control. Deliverables - Browser workflow fixture and annotated baseline trace Rollout and recovery: Keep the baseline workflow versioned before changing the page; fixture changes invalidate direct timing comparisons. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-102 — Identify which schedule code is shipped before the first interaction **Task · Medium priority · Foundational** noCV practice brief v5 · PWEB-102 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: PWEB-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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 screen downloads export and map code before the user opens either feature. The team needs sizes and dependency paths before splitting bundles. Acceptance criteria - Report transferred and parsed script sizes for the production build with cache state recorded. - Identify the dependency paths for export and map features and their actual use in the baseline workflow. - Separate first-load transfers from subsequent navigation and avoid adding compressed sizes to uncompressed sizes. Implementation constraints - Use local build artifacts and browser network records; do not compare development bundles with production output. Verification - Capture cold-cache and warm-cache navigation separately. - Open the export and map features after baseline load and verify which additional resources are requested. Deliverables - Bundle inventory and a justified split proposal Rollout and recovery: This ticket changes no loading behavior; preserve the measured build identifier for the implementation comparison. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-103 — Measure long tasks caused by filtering rather than counting renders alone **Story · Medium priority · Intermediate** noCV practice brief v5 · PWEB-103 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Capture the slow interactions. Depends on: PWEB-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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 render counter improved after memoization, but typing still stalls because sorting and formatting happen before React commits. Acceptance criteria - Record input-event start, result commit and long-task observations around the filter workflow. - Attribute measured time to filtering, sorting, rendering and layout where supported; label gaps as unknown. - Keep measurements bounded and remove observers when the screen is left. Implementation constraints - A lab interaction duration is not a claim about field Core Web Vitals; name the measured boundary explicitly. Verification - Inject a known synchronous filter delay and verify it appears in the recorded interaction. - Navigate away and back repeatedly and confirm only one active observer set remains. Deliverables - Interaction measurement helper and trace interpretation notes Rollout and recovery: Enable the helper only for the local profiling build; detach it without changing application behavior. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. ### Reduce avoidable browser work Change loading and rendering paths while preserving navigation and assistive-technology behavior. #### PWEB-104 — Load the schedule export code when export is requested **Story · Medium priority · Intermediate** noCV practice brief v5 · PWEB-104 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Performance engineering 30% · Accessibility 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 spreadsheet export dependency adds work to every schedule visit even though the baseline user never exports. Acceptance criteria - Move export-only code behind an explicit load boundary and preserve the generated file contents. - Show a keyboard-accessible loading state and prevent duplicate export starts while the module loads. - Handle module-load failure with a retry action without losing selected filters. Implementation constraints - Compare initial transfer and parse work in the same production build configuration; do not defer code required to display the schedule. Verification - Verify the initial workflow makes no export-module request, then trigger export and compare the file with the baseline fixture. - Fail the module request once and confirm retry succeeds with the original filter state. Deliverables - Deferred export implementation, network comparison and failure regression Rollout and recovery: Keep a loading-boundary switch in the exercise; revert to eager loading if export compatibility fails. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-105 — Render only the visible schedule rows without losing keyboard position **Story · High priority · Advanced** noCV practice brief v5 · PWEB-105 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-101, PWEB-103. Difficulty: Advanced. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Frontend 30% · Accessibility 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. Every filter mounts hundreds of offscreen job rows. A first virtualization attempt is faster but drops focus when the selected row scrolls away. Acceptance criteria - Bound mounted rows by viewport and overscan while retaining stable job identity. - Define and implement keyboard movement, focus restoration and accessible row position information. - Support long wrapped labels and the empty state without overlapping rows or selecting a different job after filtering. Implementation constraints - Document the chosen virtualization semantics and test with zoom and a narrow viewport; do not hide all nonvisible records from search without an explicit alternative. Verification - Traverse beyond the initial viewport with the keyboard, filter the selected row out and verify the declared focus behavior. - Measure mounted nodes and interaction duration at 200 and 2,000 jobs while checking the selected job ID. Deliverables - Bounded row rendering, accessibility checks and before/after traces Rollout and recovery: Gate virtualization independently; reverting renders the full list while preserving selected IDs and filter state. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-106 — Reuse formatted job data only while its inputs remain unchanged **Bug · Medium priority · Advanced** noCV practice brief v5 · PWEB-106 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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. Date and duration formatting dominates repeated filters. A broad memoization patch reuses labels after the schedule time zone changes. Acceptance criteria - Cache or precompute expensive formatting with all relevant inputs, including locale and time zone, in the invalidation rule. - Bound retained derived data and remove entries for jobs no longer present. - Keep visible labels identical to the uncached formatter across updates and daylight-saving boundary fixtures. Implementation constraints - Measure formatting calls and interaction time together; memoization alone is not evidence of a useful improvement. Verification - Change the time zone and job start time independently, comparing every visible label with the baseline formatter. - Replace the dataset repeatedly and check that retained derived entries stay within the declared bound. Deliverables - Derived-data cache, invalidation regressions and profiling comparison Rollout and recovery: Disable derived-data reuse through one path if stale labels appear; the original formatter remains the reference behavior. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-107 — Let a new filter supersede expensive work already in progress **Story · High priority · Expert** noCV practice brief v5 · PWEB-107 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reduce avoidable browser work. Depends on: PWEB-101, PWEB-103, PWEB-105. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Frontend 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. Fast typing schedules several expensive filter computations. Results from an earlier query briefly replace the latest selection and consume time after they are irrelevant. Acceptance criteria - Choose a bounded scheduling or worker strategy and explain why it fits the measured bottleneck. - Publish results only for the current dataset and query revision; discard superseded work safely. - Preserve responsive keyboard input and a clear pending state without moving focus or showing stale result counts. Implementation constraints - If using a worker, include transfer/serialization cost in the comparison and terminate it when the screen unmounts. Verification - Complete an older query after a newer query and verify only current results appear. - Type and clear rapidly while replacing the dataset, then inspect responsiveness, final IDs and worker or task cleanup. - Repeat baseline and selected-strategy runs three times under the same recorded browser workload; compare input-latency distributions and long-task counts, including worker transfer and serialization overhead when applicable. Deliverables - Scheduling decision, implementation and out-of-order completion tests Rollout and recovery: Canary the alternate filter path locally; reverting cancels its work and restores synchronous filtering with the same query state. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. ### Guard responsiveness Cover memory, interrupted work and regression budgets in a repeatable browser check. #### PWEB-108 — Find retained job rows after repeated schedule navigation **Bug · High priority · Advanced** noCV practice brief v5 · PWEB-108 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-105, PWEB-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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 screen starts responsive and degrades after operators open and close it throughout a shift. Detached rows remain reachable through subscriptions. Acceptance criteria - Identify a reproducible retention path using repeated mount, interaction and unmount cycles. - Release listeners, workers and subscriptions owned by the screen without cancelling shared application resources. - Define a post-cleanup retained-object bound on the declared browser and distinguish temporary allocation from a leak. Implementation constraints - Use heap snapshots and retaining paths; do not claim a leak from one process-memory sample. Verification - Run 20 navigation cycles and inspect retained job objects after the same cleanup procedure at each checkpoint. - Navigate away during a pending filter and verify no late update, leaked listener or unhandled exception. Deliverables - Retention diagnosis, lifecycle fix and repeatable memory check Rollout and recovery: Revert only the offending optimization if cleanup cannot be demonstrated; keep the regression cycle in the local suite. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-109 — Make the schedule performance run include slow devices and empty results **Chore · Medium priority · Intermediate** noCV practice brief v5 · PWEB-109 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-101, PWEB-104, PWEB-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Performance engineering 30% · Frontend 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 fastest desktop run became the benchmark. It misses the narrow layout and empty-filter transition used by coordinators on older laptops. Acceptance criteria - Define two repeatable local profiles with explicit viewport, throttling and cache state. - Run nonempty, empty and large-label workflows and assert visual state plus selected identity. - Separate trace artifacts by profile and build revision; invalid runs report failure instead of a zero timing. Implementation constraints - Emulation defines an exercise profile, not a claim to reproduce every physical device. Verification - Execute both profiles three times with a fixed warmup rule and retain all measurements. - Remove a required result element deliberately and confirm the run fails its correctness check before reporting success. Deliverables - Browser profile matrix and repeatable benchmark command Rollout and recovery: Use both profiles in local release review; revise profiles only with a recorded reason and a new baseline. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. #### PWEB-110 — Approve schedule optimizations only when the measured interaction improves **Task · High priority · Expert** noCV practice brief v5 · PWEB-110 · Make a large scheduling screen respond to the next click Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard responsiveness. Depends on: PWEB-104, PWEB-105, PWEB-106, PWEB-107, PWEB-108, PWEB-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality engineering 30% · Accessibility 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. Several changes reduced different counters. The team needs a release decision tied to the actual filter-and-select workflow and its accessibility contract. Acceptance criteria - Compare three paired runs per declared profile and require at least 20% lower median filter-to-result duration on the constrained profile. - Require unchanged selected IDs, keyboard behavior and empty-state behavior, with no increase beyond 10% in initial transferred script bytes. - Report all timings, spread, retained-object observations and inconclusive results; document which changes are included and why. Implementation constraints - The numerical budgets apply only to this fixture and lab profile. Preserve raw traces so reviewers can assess attribution and noise. Verification - Run the complete workflow against baseline and candidate in alternating order. - Revert the combined candidate and verify both functional behavior and measured baseline recovery under the same profiles. Deliverables - Release decision, paired trace bundle and rollback rehearsal Rollout and recovery: Promote the chosen combination only after the exercise gates pass; keep each optimization independently reversible where state compatibility permits. Project prerequisites: Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses. Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison. Engineer value: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility. Company value: Produce a bounded performance investigation and regression workflow for dense operational interfaces. 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. ## PBATCH — Import a large supplier catalog without exhausting the worker A fictional wholesaler imports supplier rows into a staging catalog. The current prototype reads the entire file into memory and restarts from zero after a failure. Build the prototype and generated CSV fixture locally before measuring improvements. **Field:** Performance engineering. **Suggested stack:** TypeScript, Node.js streams, PostgreSQL, CSV. **Engineer value:** Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. **Company value:** Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. **Delivery agreement:** Ten tickets in three phases. All data and failures are locally generated; throughput targets are relative to the declared baseline and do not imply a production service-level guarantee. ### Setup prerequisites - Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. - Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. ### Define input and resource behavior Establish a representative file and honest end-to-end measurements. #### PBATCH-101 — Generate a catalog file that includes difficult CSV boundaries **Task · Medium priority · Foundational** noCV practice brief v5 · PBATCH-101 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define input and resource behavior. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Quality engineering 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. The demonstration file has one short record per line. It cannot expose parsers that split quoted descriptions or allocate one enormous record. Acceptance criteria - Generate 250,000 deterministic rows including quoted delimiters, embedded newlines, multibyte text and declared invalid cases. - Publish expected accepted/rejected counts and a digest of normalized accepted records. - Declare a maximum record size and include an intentionally oversized record in a separate failure fixture. Implementation constraints - Use invented supplier identifiers and descriptions; fixture generation must not require a downloaded customer file. Verification - Regenerate with the same seed and compare file digest and expected counts. - Parse with a reference implementation and verify quoted newlines do not change record boundaries. Deliverables - Fixture generator, manifest and expected normalized digest Rollout and recovery: Version the fixture before profiling; keep the oversized fixture separate so the normal baseline has a defined completion result. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-102 — Measure peak import memory across parsing, validation and writes **Task · Medium priority · Foundational** noCV practice brief v5 · PBATCH-102 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define input and resource behavior. Depends on: PBATCH-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · Data 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 worker exits near the end of an import, but the existing memory sample is taken only after garbage collection and misses the peak. Acceptance criteria - Record process RSS, managed heap, buffered-record count and stage throughput at a fixed documented sampling interval. - Report peak values and exit outcome, including resource-limit termination. - Separate input-read completion from database-commit completion in elapsed time. Implementation constraints - Document sampling limitations and resource limits; do not report a killed run as a completed low-memory run. Verification - Run the whole-file baseline and retain its peak or termination outcome. - Inject a slow writer and verify the timeline shows buffered work accumulating before completion. Deliverables - Resource timeline and baseline measurement command Rollout and recovery: Keep measurement output outside imported data; retain failed-run artifacts for the streaming comparison. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-103 — Attribute import time to parsing, validation and database waits **Story · Medium priority · Intermediate** noCV practice brief v5 · PBATCH-103 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define input and resource behavior. Depends on: PBATCH-101, PBATCH-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Data 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 proposal to increase database concurrency assumes writes dominate, but expensive normalization may already saturate one CPU core. Acceptance criteria - Measure stage service time and time blocked on downstream capacity separately. - Compare parse-only, parse-plus-validation and complete-import runs using the same input. - Reconcile accepted and rejected records between stages and identify the supported bottleneck hypothesis. Implementation constraints - Use bounded aggregate timing rather than one log entry per record, which would alter the measured workload. Verification - Inject a known validation delay and show its contribution in the stage report. - Inject writer delay instead and confirm it appears as downstream wait rather than parser CPU time. Deliverables - Stage comparison report and aggregate instrumentation Rollout and recovery: Use the instrumentation in local benchmarks first; disable it independently if overhead makes comparisons unreliable. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. ### Bound the import pipeline Control buffering and write work without dropping or duplicating records. #### PBATCH-104 — Stream records without buffering the rest of the catalog **Story · High priority · Advanced** noCV practice brief v5 · PBATCH-104 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound the import pipeline. Depends on: PBATCH-101, PBATCH-102, PBATCH-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Data 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. Switching to a streaming file reader did not reduce memory because validation still accumulates every parsed row before writing starts. Acceptance criteria - Connect reading, parsing, validation and writing through bounded buffers with downstream backpressure. - Reject an oversized record explicitly without allowing unbounded parser accumulation. - Preserve normalized accepted-record digest and rejection reasons from the baseline fixture. Implementation constraints - Express buffer bounds in records and bytes where record sizes vary; a stream API alone does not establish bounded memory. Verification - Pause the writer and assert parser progress stops within the declared buffering bound. - Split quoted multibyte records across small input chunks and compare complete results with the reference fixture. Deliverables - Streaming pipeline, buffer invariants and peak-memory comparison Rollout and recovery: Keep the whole-file implementation only as a small-fixture reference; stop and retain the source file if the streaming result digest differs. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-105 — Batch staging writes without changing duplicate-SKU behavior **Story · High priority · Advanced** noCV practice brief v5 · PBATCH-105 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound the import pipeline. Depends on: PBATCH-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Data engineering 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. Single-row inserts dominate after streaming is introduced. A bulk-insert experiment is faster but resolves duplicate supplier SKUs differently. Acceptance criteria - Document duplicate-SKU ordering and preserve it across batch boundaries. - Cap batch rows and serialized bytes, with bounded transaction duration. - Return deterministic accepted/rejected outcomes when one batch includes invalid or conflicting records. Implementation constraints - Compare at least three bounded batch sizes on the fixed fixture; do not choose the largest solely from one fast run. Verification - Place duplicate SKUs on either side of a batch boundary and compare normalized results with the reference behavior. - Inject a write failure midway through a batch and verify the declared atomicity and retry outcome. Deliverables - Batched writer, batch-size measurements and duplicate regressions Rollout and recovery: Canary in staging with batch size configurable; reducing it must preserve semantics and allow work to continue from a valid checkpoint. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-106 — Stop validation workers from creating an unbounded reorder queue **Bug · High priority · Expert** noCV practice brief v5 · PBATCH-106 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound the import pipeline. Depends on: PBATCH-103, PBATCH-104, PBATCH-105. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Data 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. Parallel validation improves throughput until one slow record delays output. Later completed records accumulate while the writer waits for order. Acceptance criteria - Define a bounded in-flight window and preserve required source ordering without retaining unlimited completed work. - Propagate cancellation and fatal validation failure through every active stage. - Select worker concurrency from repeated measurements that include serialization and coordination overhead. Implementation constraints - If the measured validation stage is not CPU-bound, document that result and retain a simpler bounded path instead of adding workers without benefit. Verification - Delay the first record while later records complete and assert both in-flight and retained-result bounds. - Fail one worker during the import and verify controlled shutdown, deterministic checkpoint state and no silent record loss. Deliverables - Concurrency decision, bounded ordering implementation and fault tests Rollout and recovery: Keep a single-worker configuration available; drain or cancel active work before changing concurrency during a rehearsal. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. ### Recover and verify Resume safely, report useful progress and gate throughput improvements. #### PBATCH-107 — Report import progress from committed records instead of bytes read **Bug · Medium priority · Intermediate** noCV practice brief v5 · PBATCH-107 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and verify. Depends on: PBATCH-104, PBATCH-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Data engineering 40% · Frontend 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 UI reaches 100% while thousands of records are still queued for the database. Operators assume they can close the import. Acceptance criteria - Expose bytes consumed, records accepted/rejected, committed records and terminal state as separate counters. - Mark completion only after all accepted records are committed and final reconciliation succeeds. - Avoid a remaining-time promise when throughput is unstable; report an unknown estimate explicitly. Implementation constraints - Keep progress updates throttled and monotonic within one attempt; resumed attempts must disclose their checkpoint origin. Verification - Pause the final write and verify the import remains nonterminal despite input exhaustion. - Inject rejection and retry cases and reconcile counters with the final staging contents. Deliverables - Progress contract and end-of-input regression Rollout and recovery: Introduce the progress fields before changing the UI completion rule; retain committed counters if the display is reverted. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-108 — Resume an interrupted catalog import from a committed checkpoint **Story · High priority · Expert** noCV practice brief v5 · PBATCH-108 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and verify. Depends on: PBATCH-104, PBATCH-105, PBATCH-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Database engineering 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. An import loses its process after several committed batches. Restarting from a byte offset inside a quoted multiline record corrupts the next batch. Acceptance criteria - Bind checkpoints to source digest, parser configuration and import identity. - Checkpoint only a valid record boundary whose writes are committed, with an explicit idempotency rule for uncertain completion. - Reject a changed source or configuration and preserve the previous import for inspection. Implementation constraints - A raw newline is not a CSV record boundary. State whether resumption seeks to a validated boundary or replays and skips already committed record identities. Verification - Terminate after commit but before checkpoint acknowledgement, resume and compare the final digest with an uninterrupted import. - Change one source byte and attempt resumption; no additional staging writes may occur. Deliverables - Checkpoint protocol, resume implementation and interruption matrix Rollout and recovery: Enable resumption only after the failure matrix passes; retain the source and last valid checkpoint when recovery is refused. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-109 — Prove temporary import resources disappear after cancellation **Chore · Medium priority · Advanced** noCV practice brief v5 · PBATCH-109 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and verify. Depends on: PBATCH-104, PBATCH-106, PBATCH-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Data engineering 30% · 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. Cancelled imports leave temporary files and open connections. A subsequent run inherits resource pressure and appears slower for an unrelated reason. Acceptance criteria - Define ownership and cleanup for temporary files, file descriptors, workers and database connections. - Cancel safely at read, validation and commit stages while preserving the last valid recovery checkpoint. - Make repeated cancellation safe and keep the source fixture intact. Implementation constraints - Check resource inventories before and after; avoid asserting cleanup from a completion message alone. Verification - Cancel at each controlled stage and verify owned resources return to the declared baseline. - Run cancellation twice, then resume or start a fresh import and confirm correct results without restarting the environment. Deliverables - Cleanup implementation, resource inventory and cancellation regressions Rollout and recovery: Run cleanup rehearsal before accepting performance results; quarantine uncertain staging state for explicit recovery rather than deleting it silently. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. #### PBATCH-110 — Set a throughput gate that also enforces import memory and correctness **Chore · High priority · Expert** noCV practice brief v5 · PBATCH-110 · Import a large supplier catalog without exhausting the worker Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and verify. Depends on: PBATCH-105, PBATCH-106, PBATCH-108, PBATCH-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Data engineering 30% · 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. The fastest batch configuration exceeds the worker memory budget and fails on interrupted runs. Throughput alone is selecting the wrong candidate. Acceptance criteria - Run three paired baseline/candidate comparisons with the same source, database state and resource limits. - Require completion within the 256 MiB process budget, exact normalized digest and at least 20% higher median committed-record throughput than a completing baseline. - If the whole-file baseline cannot complete, report that fact and compare throughput against a documented completing bounded baseline; never calculate improvement from a killed run. Implementation constraints - Include reset and warmup procedures, peaks, repetitions and recovery observations in the report; the budgets are local exercise conditions. Verification - Run normal and slow-writer fixtures and publish all memory peaks and completion outcomes. - Repeat the commit/checkpoint interruption case with the chosen batch and concurrency settings, then verify final digest and resource cleanup. Deliverables - Performance gate, raw measurements and chosen operating configuration Rollout and recovery: Promote only the configuration satisfying every gate in the synthetic environment; restore the prior bounded configuration if memory or recovery regresses. Project prerequisites: Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size. Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU. Engineer value: Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics. Company value: Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs. 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. ## PCACHE — Keep product availability caching correct during a traffic spike A fictional equipment-rental service caches availability summaries. A campaign sends repeated reads, while stock updates and shared expiry times create bursts against the origin. Build a local origin stub and cache-backed read API using synthetic depots and products. **Field:** Performance engineering. **Suggested stack:** TypeScript, Redis, HTTP, k6. **Engineer value:** Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. **Company value:** Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. **Delivery agreement:** Ten tickets in three phases. Availability is informational; booking remains an authoritative origin operation. All load and failure experiments use owned local services. ### Setup prerequisites - Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. - Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. ### Define cache meaning and baseline Specify keys, freshness and measurements before optimization. #### PCACHE-101 — Specify which availability responses may be reused **Task · High priority · Foundational** noCV practice brief v5 · PCACHE-101 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 30% · 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. Two requests for the same product receive different answers because depot and tenant affect availability. The prototype cache key contains only the product ID. Acceptance criteria - Include tenant, depot, product and response-schema version in an unambiguous cache-key contract. - State the maximum informational freshness window and keep booking decisions on the authoritative origin. - Define which errors and absence responses are cacheable, with a separate bounded lifetime where appropriate. Implementation constraints - Use opaque synthetic identifiers and avoid leaking sensitive request values through diagnostic key labels. Verification - Request the same product from two depots and tenants and verify no shared response. - Construct delimiter-collision inputs and confirm distinct semantic keys remain distinct. Deliverables - Cache-key and freshness contract with boundary fixtures Rollout and recovery: Introduce a new key namespace for the contract; expiry cleans old derived entries without rewriting authoritative availability. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-102 — Measure saved origin work instead of celebrating the hit ratio **Task · Medium priority · Foundational** noCV practice brief v5 · PCACHE-102 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: PCACHE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance 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. The cache reports a high hit ratio, but every hit still triggers a synchronous origin validation and costs almost as much as a miss. Acceptance criteria - Record hits, misses, stale responses, origin calls, origin work duration and end-to-end request latency separately. - Use bounded labels and report the same workload window and request counts for all rates. - Define avoided origin calls against an uncached run of the identical seeded requests. Implementation constraints - Do not combine cache and origin error outcomes into successful hits; expose failures and retries explicitly. Verification - Replay a repeated-key fixture and reconcile request count with cache outcomes and actual stub calls. - Enable synchronous validation deliberately and verify the report reveals that high hit rate did not remove origin work. Deliverables - Cache effectiveness report and aggregate counters Rollout and recovery: Run counters beside the existing local behavior before policy changes; preserve raw attempt counts for comparisons. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-103 — Create a hot-key workload that exposes synchronized expiry **Chore · Medium priority · Intermediate** noCV practice brief v5 · PCACHE-103 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: PCACHE-101, PCACHE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. Uniform random keys miss often but never reproduce the traffic surge that arrives when the most popular products expire together. Acceptance criteria - Generate a seeded workload where 80% of reads target 20 hot product/depot keys and the remainder sample a larger declared set. - Include a synchronized-expiry phase, a cold start and a quiet recovery period. - Record scheduled and achieved arrivals, timeouts and origin concurrency so generator saturation is visible. Implementation constraints - Use a controllable clock for unit-level expiry cases and a documented arrival schedule for load runs. Verification - Repeat the seed and compare key frequencies and expiry schedule. - Run the uncached and cached paths against the same origin-delay fixture and retain all outcome counts. Deliverables - Hot-key generator and baseline workload manifest Rollout and recovery: Version the workload independently of cache implementation; changing the distribution starts a new comparison baseline. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. ### Bound cache work and staleness Handle simultaneous misses, updates and failure without serving another tenant or hiding stale data. #### PCACHE-104 — Coalesce simultaneous availability misses for one key **Story · High priority · Advanced** noCV practice brief v5 · PCACHE-104 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Backend 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. Hundreds of requests miss the same just-expired key and each starts an identical origin read. Acceptance criteria - Share one bounded in-flight fill per semantic key within the declared process scope. - Give each waiter its own deadline and release the in-flight entry on success, failure and cancellation. - Keep different tenants and keys independent, and document that process-local coalescing does not coordinate multiple instances. Implementation constraints - Use a deterministic origin latch to prove fan-in; a fast origin can hide duplicate concurrent fills in a timing-only test. Verification - Release 100 simultaneous same-key reads and verify one origin fill with identical successful results. - Cancel some waiters and fail the fill; verify remaining outcomes, cleanup and a successful subsequent retry. Deliverables - Single-flight implementation and concurrency/failure regressions Rollout and recovery: Gate coalescing locally; disabling it preserves the same freshness contract and drains existing waiters before removing entries. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-105 — Spread cache refill times without extending the freshness ceiling **Story · Medium priority · Intermediate** noCV practice brief v5 · PCACHE-105 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 80% · 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. A bulk warmup writes every popular key with the same lifetime. They expire in one wave and overload the origin. Acceptance criteria - Apply bounded expiry variation that never exceeds the declared maximum freshness window. - Make the randomness injectable for repeatable tests and preserve explicit short-lived negative-cache policy. - Report refill concurrency before and after under the synchronized-expiry fixture. Implementation constraints - Define whether jitter shortens lifetime or schedules refresh earlier; do not silently extend a business freshness bound. Verification - Generate many lifetimes with a fixed seed and verify all are positive and within the contractual ceiling. - Replay the warmup/expiry workload and compare peak origin concurrency while checking response ages. Deliverables - Expiry policy, deterministic boundary tests and refill comparison Rollout and recovery: Roll out the new expiry policy only for newly written entries; reverting changes future writes while existing entries remain within the original ceiling. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-106 — Serve stale availability only within an explicit degraded-read policy **Story · High priority · Expert** noCV practice brief v5 · PCACHE-106 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-102, PCACHE-104. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · API design 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. During a short origin outage the cache can show useful recent information, but the prototype serves old availability indefinitely and presents it as current. Acceptance criteria - Define fresh, stale-but-allowed and expired states with explicit age limits and response metadata. - Choose bounded background refresh behavior and retain authoritative booking checks. - After the hard age limit, return an explicit unavailable outcome rather than an apparently current availability summary. Implementation constraints - The policy concerns informational reads only. Preserve origin-error visibility and do not cache authorization failures as product absence. Verification - Advance the clock across both boundaries during origin success and failure, checking age metadata and result state. - Run concurrent stale reads with a blocked refresh and verify bounded origin work and transition to unavailable after the hard limit. Deliverables - Freshness state machine, degraded-read implementation and boundary matrix Rollout and recovery: Canary with response-age and stale-outcome counters; disable stale serving immediately if clients fail to present the declared state. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-107 — Prevent a delayed refill from restoring availability older than an update **Bug · High priority · Expert** noCV practice brief v5 · PCACHE-107 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-104, PCACHE-106. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. An origin read starts before a stock update, then finishes after invalidation and writes the old value back into the cache. Acceptance criteria - Associate fills and updates with an explicit revision or generation rule. - Reject an obsolete fill after a newer invalidation or value is known within the chosen coordination scope. - Document behavior when invalidation delivery is delayed and preserve the hard freshness ceiling as a backstop. Implementation constraints - Use atomic cache operations where a check-and-set race matters; explain limits across multiple readers rather than claiming perfect global freshness. Verification - Hold an old origin response, apply a newer update, then release it and verify the cached revision does not go backward. - Repeat the sequence with duplicate invalidations and a cache reconnect; verify the declared recovery behavior and age bound. Deliverables - Revision protocol, race regression and coordination-limit note Rollout and recovery: Introduce the revisioned namespace gradually; on uncertainty discard derived cache state and use the bounded origin path. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. ### Validate degraded and release behavior Exercise cache loss, policy changes and measurable promotion gates. #### PCACHE-108 — Keep origin traffic bounded when the cache becomes unavailable **Story · High priority · Advanced** noCV practice brief v5 · PCACHE-108 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-102, PCACHE-104, PCACHE-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. A cache outage redirects the full request rate to the origin. The supposed fallback turns a small infrastructure fault into a wider outage. Acceptance criteria - Set cache-client timeouts and bound origin fallback concurrency and queue length. - Return an explicit overload or unavailable response when the fallback budget is exhausted. - Recover cache use without a synchronized refill storm or continuing to queue expired callers. Implementation constraints - Exercise cache disconnect, slow response and recovery separately; do not rely only on a clean process shutdown. Verification - Run the hot-key load while making cache operations hang and assert bounded connection and origin work counts. - Restore the cache during overload and verify queue drainage, timeout accounting and correct tenant-specific responses. Deliverables - Degraded-cache policy, failure injection and recovery traces Rollout and recovery: Canary the bounded fallback configuration locally; retain a switch that fails informational reads explicitly if fallback threatens the origin budget. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-109 — Version availability cache payloads without flushing every tenant at once **Chore · Medium priority · Advanced** noCV practice brief v5 · PCACHE-109 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-101, PCACHE-105, PCACHE-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · API design 30% · 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. A response-field change makes older cached payloads unreadable. Flushing all keys would force a simultaneous cold start across the service. Acceptance criteria - Write a new payload/key version and reject incompatible old payloads safely. - Define a bounded warming or lazy-fill strategy and retain per-tenant scope. - Make rollback behavior explicit when older readers encounter values written during the new release. Implementation constraints - Treat cache payloads as derived data; do not migrate authoritative stock records as part of this change. Verification - Run old and new readers against mixed-version fixtures and verify the documented compatibility behavior. - Switch versions under the hot-key workload and measure origin refill concurrency without a global flush. Deliverables - Payload-version contract, compatibility tests and rollout procedure Rollout and recovery: Canary a small synthetic tenant set, then expand; rollback restores the prior namespace and lets unused versioned entries expire. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-110 — Choose the cache policy from freshness, origin load and tail latency together **Task · High priority · Expert** noCV practice brief v5 · PCACHE-110 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-104, PCACHE-105, PCACHE-106, PCACHE-107, PCACHE-108, PCACHE-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Site reliability 30% · 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. One policy gives the highest hit rate by serving older data. Another is fresh but overloads the origin at expiry. The team needs a decision tied to the actual contract. Acceptance criteria - Run three paired repetitions of cold, warm, synchronized-expiry and cache-outage phases on the declared workload. - For the warm phase require at least 60% fewer origin calls than uncached reads, no cross-tenant result and no response beyond the hard freshness limit. - Require bounded origin concurrency in every phase and publish p95/p99, rejection and stale-response rates; mark invalid or noisy runs inconclusive. Implementation constraints - The avoided-call threshold is an exercise budget for the seeded hot-key distribution. Do not infer a production hit rate or freshness guarantee from it. Verification - Reconcile all attempted reads with results, cache states and actual origin calls for baseline and candidate. - Revert the chosen configuration and repeat the outage/recovery phase, checking correctness and bounded work after rollback. Deliverables - Cache-policy decision, raw measurements and recovery handoff Rollout and recovery: Promote only the policy satisfying correctness and degraded-mode gates; rollback uses the documented namespace and bounded origin policy. Project prerequisites: Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data. Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. ## RRETENTION — Expire support attachments without losing control of exceptions A fictional support service keeps uploaded diagnostic files indefinitely. The exercise policy expires attachments 30 days after case closure, while a separately authorized investigation hold pauses removal. These are invented product rules, not legal advice or compliance certification. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Object storage adapter. **Engineer value:** Practice temporal policy, deletion races, exception authority and truthful recovery reporting. **Company value:** Develop inspectable retention behavior that a company can review against its own approved data policy. **Delivery agreement:** Ten scoped tickets using local synthetic records. Policy approval, real account access and production deletion are outside the exercise. ### Setup prerequisites - Create synthetic cases, attachment metadata and a fake object store with controllable failures. - Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. ### Define expiry and exceptions Make retention decisions explainable and correctly scoped. #### RRETENTION-101 — Calculate attachment expiry from the case closure instant **Task · Medium priority · Foundational** noCV practice brief v5 · RRETENTION-101 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Files uploaded long before a case closes are being removed too early because the prototype starts the retention clock at upload. Acceptance criteria - Use case closure plus 30 elapsed days as the exercise expiry instant. - Keep open cases ineligible and represent missing closure data explicitly. - Return the policy version and reason with each eligibility decision. Implementation constraints - Use UTC instants and an injected clock; do not substitute local calendar dates. Verification - Evaluate immediately before and at expiry. - Evaluate open and missing-closure fixtures without scheduling deletion. Deliverables - Retention decision function and boundary fixtures Rollout and recovery: Run decisions in preview mode before enabling any removal path. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-102 — Inventory every storage location used by one support attachment **Task · Medium priority · Foundational** noCV practice brief v5 · RRETENTION-102 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: RRETENTION-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Storage systems 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. Removing the primary upload leaves its thumbnail and a cached diagnostic preview behind. Acceptance criteria - List primary object, derived previews, metadata and any backup copy in a bounded data-flow inventory. - Assign an owner and retention behavior to each location. - Mark unknown or external copies explicitly instead of declaring removal complete. Implementation constraints - Use the fictional architecture and local adapters; do not discover or copy real customer data. Verification - Trace one synthetic upload through each declared location. - Add an unknown derived location and verify the inventory marks coverage incomplete. Deliverables - Attachment lifecycle map and location registry Rollout and recovery: Review the registry before wiring purge adapters; new derived stores require an inventory update. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-103 — Require scoped authority to place an attachment on investigation hold **Story · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-103 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define expiry and exceptions. Depends on: RRETENTION-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Any support member can currently set a permanent hold with no reason, and the flag has no owner for later review. Acceptance criteria - Require tenant-scoped hold authority, a bounded reason category and a review date. - Append hold creation and release records with actor and policy version. - Deny a foreign-tenant or ordinary-member hold command before mutation. Implementation constraints - Keep free-text case content out of generic audit logs; an audit records the privileged action and safe identifiers. Verification - Create and release a hold as the authorized synthetic operator. - Attempt both commands from another tenant and an unprivileged member; verify no change. Deliverables - Hold commands and authorization regressions Rollout and recovery: Introduce hold management before purge activation so active exceptions can be represented. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. ### Apply removal safely Recheck authority and recover partial failures. #### RRETENTION-104 — Preview the attachment purge set with stable decision reasons **Story · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-104 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-101, RRETENTION-102, RRETENTION-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Developer tooling 30% · Security 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. Operators cannot tell why two similarly aged attachments are treated differently by the retention job. Acceptance criteria - Return bounded pages of eligible, held and ineligible records with policy and decision timestamp. - Keep preview tenant-scoped and omit file contents and unrestricted object URLs. - State that preview is advisory and execution rechecks current eligibility. Implementation constraints - Use stable cursor ordering; a preview must never claim to lock the future purge set. Verification - Compare expiry and hold fixtures with the decision function. - Place a hold after preview and verify the preview itself causes no deletion. Deliverables - Purge-preview endpoint and scoped pagination tests Rollout and recovery: Expose preview to authorized local operators first; disable the view independently of lifecycle records. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-105 — Recheck holds when a queued attachment purge begins **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-105 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-103, RRETENTION-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Database engineering 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. An attachment becomes held after the purge queue is populated, but the worker trusts the old eligibility flag and removes it anyway. Acceptance criteria - Re-evaluate current policy and hold state before issuing removal. - Define coordination between hold creation and a purge already crossing its irreversible boundary. - Return an explicit conflict or too-late state without claiming a newly created hold restored deleted bytes. Implementation constraints - Model the race using a controlled storage adapter; document the exact serialization boundary. Verification - Pause before removal, place a hold and verify the object remains. - Race hold creation with confirmed removal and verify the declared conflict outcome and truthful audit. Deliverables - Purge/hold transition protocol and race tests Rollout and recovery: Keep deletion disabled until both race orderings pass; preserve metadata for any ambiguous external operation. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-106 — Retry partial attachment removal without forgetting derived copies **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-106 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-102, RRETENTION-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Distributed systems 30% · Storage 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 primary object is gone but thumbnail removal timed out. A retry treats the missing primary as success for the entire attachment. Acceptance criteria - Track per-location progress and idempotent removal outcomes. - Distinguish not-found from authorization and transport failure. - Mark the purge complete only when every required location is confirmed or an explicit unresolved exception remains. Implementation constraints - Keep evidence of unresolved copies in restricted operational records; do not expose storage credentials in failure text. Verification - Fail thumbnail removal after primary success, retry and verify both locations are reconciled. - Inject a forbidden response and confirm it remains unresolved rather than being treated as already absent. Deliverables - Per-location purge state and partial-failure regressions Rollout and recovery: Retry only incomplete locations; stop promotion when a provider cannot give a trustworthy deletion outcome. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-107 — Record a reopened case without silently resetting attachment history **Bug · High priority · Advanced** noCV practice brief v5 · RRETENTION-107 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Apply removal safely. Depends on: RRETENTION-101, RRETENTION-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data 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. Reopening a case overwrites its closure timestamp. Support can no longer explain whether an attachment was eligible when a purge started. Acceptance criteria - Append case lifecycle events and derive the current retention clock under an explicit reopening rule. - Preserve previous decisions and completed removal history. - Prevent reopening from implying deleted attachments can be recovered. Implementation constraints - Define the exercise rule before coding: reopening pauses eligibility; a later closure starts a new 30-day period for remaining attachments. Verification - Reopen before expiry and verify ineligibility, then close again and verify the new boundary. - Reopen after confirmed purge and show the attachment remains removed with its original decision history. Deliverables - Reopening policy and historical decision tests Rollout and recovery: Version the policy and preview changed eligibility before activating the new clock behavior. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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 ongoing retention Measure backlog and rehearse policy changes without obscuring retained data. #### RRETENTION-108 — Report retention backlog without listing customer file names **Chore · Medium priority · Intermediate** noCV practice brief v5 · RRETENTION-108 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-104, RRETENTION-106. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. The only retention report exports every filename to a general analytics dashboard. Acceptance criteria - Expose aggregate eligible, held, failed and completed counts plus oldest eligible age. - Keep filenames, object keys and case content out of generic metrics. - Provide authorized drilldown through the scoped operational view instead of metric labels. Implementation constraints - Use bounded outcome categories and distinguish zero eligible records from unavailable measurements. Verification - Reconcile aggregate counts with a synthetic fixture containing each outcome. - Insert sensitive-looking filenames and verify no value reaches the metric payload. Deliverables - Retention metrics and sanitized payload tests Rollout and recovery: Run aggregate reporting beside the restricted preview; remove the old filename-based dashboard after validation. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-109 — Rehearse a shorter retention policy without deleting on preview **Task · Medium priority · Expert** noCV practice brief v5 · RRETENTION-109 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-104, RRETENTION-105, RRETENTION-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Product proposes reducing the exercise retention period from 30 to 14 days. Applying the constant immediately would make a large backlog eligible at once. Acceptance criteria - Create a new policy version and produce a tenant-scoped impact preview. - Define activation time, bounded purge batches and preserved hold semantics. - Document that rollback can stop future deletion but cannot restore confirmed removed objects. Implementation constraints - Treat 14 days as a proposed fictional rule requiring review in the exercise workflow, not a real-world policy recommendation. Verification - Compare old and new decisions at activation boundaries with active holds. - Cancel activation and verify no objects were removed by the preview; rehearse stopping after one controlled purge batch. Deliverables - Policy-change plan, impact report and stop procedure Rollout and recovery: Require the explicit local activation command after review; retain previous policy and append the activation record. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. #### RRETENTION-110 — Verify retention recovery after an interrupted purge run **Task · Medium priority · Expert** noCV practice brief v5 · RRETENTION-110 · Expire support attachments without losing control of exceptions Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify ongoing retention. Depends on: RRETENTION-106, RRETENTION-108, RRETENTION-109. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Site reliability 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 purge process crashes between provider acknowledgement and state persistence. The dashboard cannot tell which objects remain. Acceptance criteria - Reconcile uncertain per-location states through the declared provider contract. - Preserve held and not-yet-eligible objects while converging repeated retries. - Produce a report separating confirmed removal, retained exceptions and unresolved provider outcomes. Implementation constraints - Use synthetic objects and deterministic crash points; a completed job record alone does not prove every copy is gone. Verification - Interrupt before and after each storage acknowledgement and compare actual fixture objects with recorded states. - Repeat reconciliation and verify no duplicate privileged transition and no newly removed held object. Deliverables - Crash matrix, reconciliation procedure and truthful retention report Rollout and recovery: Enable scheduled local purge only after recovery cases pass; unresolved states remain visible for authorized review. Project prerequisites: Create synthetic cases, attachment metadata and a fake object store with controllable failures. Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed. Engineer value: Practice temporal policy, deletion races, exception authority and truthful recovery reporting. Company value: Develop inspectable retention behavior that a company can review against its own approved data policy. 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. ## RDELETE — Delete a workspace member profile across owned stores A fictional collaboration product lets a member request removal of their personal profile. Search, notifications and cached displays retain copies after the primary row disappears. The exercise uses a documented product deletion policy and synthetic identities. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Queue adapter, Search adapter. **Engineer value:** Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. **Company value:** Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. **Delivery agreement:** Ten tickets across request, cleanup and reconciliation phases. No live accounts are deleted; the brief does not certify legal erasure or removal from undeclared third parties. ### Setup prerequisites - Create local profile, search-index and notification fixtures with controlled provider failures. - Define synthetic members, organizations and a current-session authorization fixture. ### Accept a scoped removal request Define identity, authority and the product deletion contract. #### RDELETE-101 — Separate profile removal from leaving one organization **Task · Medium priority · Foundational** noCV practice brief v5 · RDELETE-101 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 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. A member belongs to two organizations. The current button says delete account but removes only the active membership. Acceptance criteria - Define distinct commands for leaving one organization and removing the global personal profile. - List owned stores affected by each command and any retained records under the fictional policy. - Show the command scope and expected access change before submission. Implementation constraints - Do not infer global identity from an organization-local display name or email field. Verification - Trace a two-organization member through both commands and compare affected records. - Verify a membership-only request leaves the other organization and global profile unchanged. Deliverables - Deletion scope contract and multi-organization fixtures Rollout and recovery: Introduce distinct command names before enabling cleanup adapters. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-102 — Verify the current member before accepting profile removal **Story · Medium priority · Intermediate** noCV practice brief v5 · RDELETE-102 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: RDELETE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Privacy 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. A request body supplies a profile ID and the API trusts it even when it differs from the authenticated member. Acceptance criteria - Resolve the subject from the current authorized session and declared command scope. - Reject substituted profile IDs and stale sessions before creating a request. - Return a safe request reference without exposing another profile’s existence. Implementation constraints - Reuse an explicit authentication provider fixture; this ticket does not invent a new identity-assurance claim. Verification - Submit as the matching synthetic member and verify the request subject. - Substitute a second member’s ID and revoke the session; both cases must create no request. Deliverables - Authorized request endpoint and subject-substitution tests Rollout and recovery: Gate request creation before enabling background work; rollback disables new requests while preserving accepted ones. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-103 — Make repeated removal requests return the same active operation **Bug · High priority · Intermediate** noCV practice brief v5 · RDELETE-103 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: RDELETE-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Privacy engineering 40% · 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. A double-click starts two cleanup chains that race and send contradictory completion messages. Acceptance criteria - Use a subject-scoped active-operation uniqueness rule and a stable request identity. - Return the existing operation for a duplicate accepted request. - Preserve previous terminal history when a genuinely new eligible request is allowed by the policy. Implementation constraints - Create the request and dispatch intent transactionally; a retry must not depend on process memory. Verification - Submit concurrent duplicates and verify one operation plus one dispatch intent. - Lose the first response and retry, confirming the same safe operation reference. Deliverables - Idempotent request creation and concurrency regressions Rollout and recovery: Apply the uniqueness constraint before deploying the accepting endpoint. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. ### Remove declared copies Coordinate idempotent cleanup and prevent data from returning. #### RDELETE-104 — Stop new profile-derived writes after removal begins **Bug · High priority · Advanced** noCV practice brief v5 · RDELETE-104 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-101, RDELETE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Distributed systems 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. The notification worker recreates a cached profile card while cleanup is deleting it. Acceptance criteria - Record a lifecycle boundary that profile-derived writers check before producing new copies. - Define how already queued work is cancelled or rejected for the removal generation. - Preserve required nonpersonal operational records without copying the removed profile into them. Implementation constraints - Use a generation or tombstone contract with explicit retention; do not keep the entire deleted profile inside a tombstone. Verification - Queue a notification before removal and release it afterward; no new profile copy may appear. - Race an edit with removal and verify one declared outcome with no profile resurrection. Deliverables - Write barrier and profile-resurrection race tests Rollout and recovery: Deploy the writer check before activating cleanup; stop new operations if a writer cannot honor it. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-105 — Remove profile documents from search using the removal generation **Story · Medium priority · Advanced** noCV practice brief v5 · RDELETE-105 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Data engineering 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. A delayed indexing event arrives after a search document was deleted and makes the profile searchable again. Acceptance criteria - Bind indexing and removal to a comparable subject generation or explicit suppression rule. - Make repeated search deletion safe and keep stale indexing events from restoring the profile. - Keep cleanup tenant/subject-scoped so similarly named profiles remain searchable. Implementation constraints - Treat the search adapter as eventually consistent and define the observation needed before declaring that location complete. Verification - Delete a profile, replay its older indexing event and verify it stays absent after the adapter’s declared convergence condition. - Search for a same-name profile in another organization and verify it remains unaffected. Deliverables - Search cleanup adapter and stale-event regressions Rollout and recovery: Canary on synthetic subjects; retain unresolved search state if the adapter cannot establish the expected convergence. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-106 — Track notification and cache cleanup separately from the primary profile row **Bug · High priority · Advanced** noCV practice brief v5 · RDELETE-106 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-104, RDELETE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Distributed systems 30% · 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 operation reports success after deleting the database row even though a notification snapshot and cache entry still show the member’s details. Acceptance criteria - Track required locations with independent pending, confirmed and failed states. - Differentiate already absent from unavailable or unauthorized provider responses. - Advance overall completion only when the declared required locations satisfy the policy. Implementation constraints - The location registry is versioned for each operation so a later implementation change cannot silently rewrite its promised scope. Verification - Fail cache cleanup after database removal and verify a partial state with a retryable location. - Return an authorization error from notifications and confirm it cannot be counted as confirmed absence. Deliverables - Location progress model and partial-cleanup fixtures Rollout and recovery: Enable adapters one at a time in the local exercise; unsupported locations remain explicitly unresolved. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. ### Reconcile exceptions and completion Make partial progress and recovery inspectable. #### RDELETE-107 — Keep the removal status page useful after the profile is gone **Story · Medium priority · Intermediate** noCV practice brief v5 · RDELETE-107 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-102, RDELETE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Security 40% · Frontend 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. Deleting the profile also removes the data needed to render progress, leaving the requester with a broken page before cleanup is finished. Acceptance criteria - Provide a narrowly scoped status mechanism independent of the removed profile display fields. - Expose progress categories and unresolved exceptions without returning deleted content or internal storage identifiers. - Define status access expiry and deny access to unrelated operations. Implementation constraints - Use the exercise authentication contract or an explicitly scoped expiring receipt; do not place a reusable access secret in generic analytics. Verification - Read progress before and after primary-profile removal. - Attempt another subject’s operation and an expired receipt/session; verify denial without detail leakage. Deliverables - Minimal status response and post-removal access tests Rollout and recovery: Publish the status contract before enabling destructive cleanup; retain safe operation metadata for its declared lifetime. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-108 — Reapply profile suppression before a restored backup becomes readable **Task · Medium priority · Expert** noCV practice brief v5 · RDELETE-108 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-104, RDELETE-106. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Site reliability 30% · Storage 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. A restore rehearsal brings back a profile that was removed after the backup was taken. Acceptance criteria - Define a minimal removal ledger and a restore gate that reconciles post-backup removals before serving reads. - State the retention and access boundaries of the ledger without storing full profile snapshots. - Keep the restored environment unavailable if reconciliation is incomplete or the ledger cannot be trusted. Implementation constraints - Use local database snapshots and synthetic subjects; a backup exception must be visible in the policy rather than called immediate erasure. Verification - Restore a snapshot containing a later-removed profile and verify suppression before any simulated read endpoint is enabled. - Make the ledger unavailable and verify the restore gate fails closed. Deliverables - Restore reconciliation protocol and backup resurrection rehearsal Rollout and recovery: Add the gate to the local restore runbook before accepting the deletion workflow as complete for its declared stores. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-109 — Retry a removal operation after losing a provider acknowledgement **Chore · Medium priority · Advanced** noCV practice brief v5 · RDELETE-109 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-103, RDELETE-105, RDELETE-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Privacy 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 provider removes a copy but the cleanup process crashes before recording the result. Retrying currently converts the missing object into a fatal error. Acceptance criteria - Reconcile uncertain acknowledgement states using the provider’s declared lookup/removal contract. - Make repeated cleanup converge without recreating data or duplicating completion notifications. - Retain a distinct unresolved state when the provider cannot confirm the outcome. Implementation constraints - Use deterministic crash points around dispatch, provider completion and local persistence. Verification - Crash after external removal and before local update, then retry and verify truthful convergence. - Inject repeated provider timeout and verify bounded retries plus visible unresolved status. Deliverables - Acknowledgement-loss regression and retry procedure Rollout and recovery: Retry only through the recorded operation identity; unresolved high-impact states require authorized review in the exercise. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-110 — Produce a removal report that names remaining exceptions **Task · Medium priority · Expert** noCV practice brief v5 · RDELETE-110 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-107, RDELETE-108, RDELETE-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · 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. The proposed confirmation says all your data is deleted even when a declared backup copy or unavailable provider remains. Acceptance criteria - Generate a bounded report of completed locations, retained policy exceptions and unresolved outcomes. - Bind the report to the operation and policy versions and distinguish requested time from observed completion time. - Avoid claiming global erasure or legal compliance beyond the declared local scope. Implementation constraints - The report is workflow status, not noCV Outcome Evidence or Ownership Evidence; practice completion grants neither. Verification - Generate reports for complete, partial and backup-exception fixtures and compare their language with actual store state. - Attempt report access as another subject and verify no operation details leak. Deliverables - Truthful completion report and scope/authorization tests Rollout and recovery: Use the report only after reconciliation; corrections append a new status record rather than rewriting earlier confirmations. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. ## REXPORT — Deliver a personal data export with a narrow access boundary A fictional learning workspace offers a member a portable copy of their own profile, notes and activity settings. Shared documents contain contributions from other people. The product export policy specifies included fields and shared-record handling; this is an engineering exercise, not a legal portability claim. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, JSON, Object storage adapter. **Engineer value:** Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. **Company value:** Create a reviewable export contract and cross-subject regression suite for an approved product policy. **Delivery agreement:** Ten tickets from field inventory to delivery and cleanup. Artifacts contain only synthetic data, and all download links resolve through local provider doubles. ### Setup prerequisites - Create synthetic members, private notes and shared-document contributions in a local database. - Provide fake queue and object-storage adapters with controllable expiry and failure. ### Specify the export boundary Define authorized subjects, included fields and shared-record rules. #### REXPORT-101 — List exportable member fields before serializing database rows **Task · Medium priority · Foundational** noCV practice brief v5 · REXPORT-101 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the export boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · 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. A prototype exports complete ORM objects, including internal moderation flags and provider tokens. Acceptance criteria - Create an explicit allowlist for profile, private-note and settings fields. - Exclude credentials, internal operational fields and unrelated-member data. - Version the export schema and document omitted field categories. Implementation constraints - Build export DTOs independently of database model serialization. Verification - Export a synthetic row containing token-like and internal fields and verify they are absent. - Add an unknown database column and confirm it does not enter the artifact automatically. Deliverables - Export field contract and allowlist tests Rollout and recovery: Review the field contract before enabling generation; new fields require an explicit schema change. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-102 — Define how shared document contributions appear in a personal export **Task · Medium priority · Intermediate** noCV practice brief v5 · REXPORT-102 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the export boundary. Depends on: REXPORT-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy 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. Exporting a whole shared document would include other members’ private comments and mentions. Acceptance criteria - Specify which subject-owned contributions and necessary context are included. - Define redaction or omission for unrelated-member fields and private comments. - Represent omitted shared content honestly rather than implying the export is a complete document history. Implementation constraints - Use a mixed-author fixture; access to a workspace does not by itself settle the product export policy. Verification - Export a document with two authors, private comments and a deleted contribution. - Verify exported context does not reveal an unrelated private field or silently change the subject’s contribution text. Deliverables - Shared-record export policy and mixed-author fixtures Rollout and recovery: Keep shared-content export disabled until its policy and regression examples are reviewed. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-103 — Bind export creation to the current authorized subject **Bug · High priority · Intermediate** noCV practice brief v5 · REXPORT-103 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the export boundary. Depends on: REXPORT-101, REXPORT-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 endpoint accepts any member ID and relies on the UI to submit the current user. Acceptance criteria - Resolve export scope from the authenticated subject and approved workspace access. - Reject substituted IDs and revoked sessions before queueing work. - Record a safe operation reference without embedding personal fields in job identifiers. Implementation constraints - Authorization also belongs at the data-access boundary used by background assembly. Verification - Create an export as the matching synthetic member. - Attempt another member’s ID and a revoked membership, checking that no job or artifact is created. Deliverables - Scoped export command and cross-subject denial tests Rollout and recovery: Deploy command and repository checks together before queue activation. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. ### Build a consistent artifact Generate bounded exports with explicit version and failure behavior. #### REXPORT-104 — Freeze the export selection without holding a long database transaction **Story · Medium priority · Advanced** noCV practice brief v5 · REXPORT-104 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build a consistent artifact. Depends on: REXPORT-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Privacy engineering 30% · System 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. Notes added midway through an export appear inconsistently, and the worker holds a transaction open while uploading the archive. Acceptance criteria - Declare the export consistency boundary and record a cutoff or snapshot reference. - Keep database selection consistent with that boundary while assembling outside an unbounded transaction. - Expose generation time and the selection boundary in the manifest. Implementation constraints - Choose a method supported by the local schema; do not promise a global snapshot across unrelated stores without a protocol. Verification - Edit and add notes during a paused assembly and verify the documented inclusion rule. - Slow artifact upload and verify no long-lived database transaction is retained solely for transfer. Deliverables - Selection protocol and concurrent-edit export tests Rollout and recovery: Version the consistency contract; failed assembly may retry against the same frozen selection or start a clearly new operation. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-105 — Stream large note exports with bounded intermediate storage **Story · Medium priority · Advanced** noCV practice brief v5 · REXPORT-105 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build a consistent artifact. Depends on: REXPORT-101, REXPORT-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Privacy engineering 30% · Storage 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. A member with many notes causes the worker to build one large JSON string and exceed its resource budget. Acceptance criteria - Stream the chosen format with bounded buffering and valid escaping. - Keep ordering and manifest counts deterministic for the frozen selection. - Remove incomplete temporary artifacts on controlled failure while preserving retry metadata. Implementation constraints - Use a synthetic large-note fixture and declared memory/disk limits; do not require real user content. Verification - Export the same selection through small and large chunk sizes and compare parsed records and digest. - Interrupt output after a multibyte value and verify no incomplete artifact becomes downloadable. Deliverables - Streaming exporter, resource report and interrupted-write regression Rollout and recovery: Keep completed artifacts unpublished until final validation; retry writes to a new temporary object identity. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-106 — Validate the export manifest before marking assembly complete **Chore · Medium priority · Intermediate** noCV practice brief v5 · REXPORT-106 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build a consistent artifact. Depends on: REXPORT-102, REXPORT-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Privacy engineering 30% · Data 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. The archive download succeeds even when one source query failed and an entire section is missing. Acceptance criteria - Record schema version, section counts, selection boundary and artifact digest. - Distinguish intentionally omitted sections from failed required sections. - Mark ready only after required sections and digest validation succeed. Implementation constraints - A digest establishes artifact consistency, not completeness beyond the declared export contract. Verification - Fail the required private-note query and verify the export remains non-ready and non-downloadable, with the required-section failure reported explicitly. - Corrupt a completed temporary artifact and verify publication is blocked. Deliverables - Manifest validator and incomplete-section fixtures Rollout and recovery: Place manifest validation before the ready transition; keep failed artifacts inaccessible and eligible for cleanup. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. ### Deliver and expire access Restrict retrieval and verify cleanup and disclosure behavior. #### REXPORT-107 — Issue a short-lived download capability only after subject authorization **Story · Medium priority · Advanced** noCV practice brief v5 · REXPORT-107 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver and expire access. Depends on: REXPORT-103, REXPORT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A predictable artifact URL lets one member retrieve another member’s completed export. Acceptance criteria - Authorize every capability request against the current subject and export operation. - Scope the capability to one object and a declared short lifetime. - Keep capabilities out of generic logs, analytics and unrelated API responses. Implementation constraints - Use a local storage adapter implementing the capability contract; an opaque URL alone is not authorization. Verification - Request and use a valid capability for the matching export. - Attempt another subject’s operation, an expired capability and an altered object reference; all must fail without bytes. Deliverables - Download capability endpoint and scope/expiry tests Rollout and recovery: Enable downloads only after complete artifacts exist; disable capability issuance independently during an incident. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-108 — Revoke export access when the subject loses the required session **Bug · High priority · Expert** noCV practice brief v5 · REXPORT-108 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver and expire access. Depends on: REXPORT-103, REXPORT-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Privacy engineering 40% · System 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. A member signs out all sessions after an account concern, but a previously issued export link remains usable longer than the product policy allows. Acceptance criteria - Define the revocation guarantee and the limits of direct object-store capabilities. - Choose a bounded retrieval design that meets the stated exercise policy and document its latency/availability tradeoff. - Prevent new access after revocation and state how an already-started transfer is handled. Implementation constraints - Do not promise immediate revocation of an independently valid signed URL without a mechanism that can enforce it. Verification - Issue access, revoke the session and attempt a new download under the chosen design. - Revoke during a paused transfer and verify the documented in-flight behavior and resource cleanup. Deliverables - Revocation design decision and enforced retrieval tests Rollout and recovery: Roll out the chosen retrieval path under a new capability version; stop issuing the old form before claiming the new guarantee. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-109 — Expire export artifacts and incomplete assembly objects separately **Chore · Medium priority · Advanced** noCV practice brief v5 · REXPORT-109 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver and expire access. Depends on: REXPORT-105, REXPORT-106, REXPORT-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Storage systems 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. Completed exports expire after a day, but failed assembly objects remain indefinitely under a different prefix. Acceptance criteria - Define bounded lifetimes for ready, failed and abandoned temporary artifacts. - Recheck active assembly ownership before removing a temporary object. - Confirm object removal separately from expired download access. Implementation constraints - Use an injected clock and per-operation object registry; prefix age alone cannot distinguish an active write. Verification - Advance time through each lifecycle and verify correct removal eligibility. - Race cleanup with an active assembly lease and verify either safe retention or the declared cancellation path. Deliverables - Artifact cleanup policy and lifecycle race tests Rollout and recovery: Run a scoped preview before local cleanup; retain unresolved storage outcomes for reconciliation. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. #### REXPORT-110 — Review the export for cross-member disclosure and delivery failures **Task · Medium priority · Expert** noCV practice brief v5 · REXPORT-110 · Deliver a personal data export with a narrow access boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Deliver and expire access. Depends on: REXPORT-102, REXPORT-106, REXPORT-108, REXPORT-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Quality engineering 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 happy-path export looks correct, but nobody has reviewed shared records, access revocation and abandoned files together. Acceptance criteria - Run a fixture matrix covering two members, two organizations, shared contributions and private notes. - Reconcile manifest counts and allowed fields with the declared policy and actual artifact. - Report tested boundaries, omitted content and unresolved provider limitations without a blanket privacy certification. Implementation constraints - The exercise review is a reproducible engineering check; it does not create noCV evidence or legal assurance by itself. Verification - Attempt creation, polling and download across subject/organization boundaries. - Exercise interrupted assembly, expiry and session revocation, then inventory remaining local artifacts. Deliverables - Export review report and reproducible disclosure/failure matrix Rollout and recovery: Enable the complete local flow only when required cases pass; keep unsupported content categories explicitly out of the export contract. Project prerequisites: Create synthetic members, private notes and shared-document contributions in a local database. Provide fake queue and object-storage adapters with controllable expiry and failure. Engineer value: Practice export scoping, consistency, streaming and expiring access without leaking other members’ data. Company value: Create a reviewable export contract and cross-subject regression suite for an approved product policy. 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. ## RCONSENT — Keep communication preferences consistent across dispatch channels A fictional event workspace offers optional product announcements and operational booking messages. Its product policy treats these as separate purposes. A stale audience cache currently sends optional messages after a member opts out. The brief implements fictional preference rules and makes no legal-consent certification. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Queue adapter, Email provider double. **Engineer value:** Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. **Company value:** Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. **Delivery agreement:** Ten tickets using provider doubles and synthetic choices. No live mailing lists, legal advice or real outreach are part of the project. ### Setup prerequisites - Create synthetic members, versioned notice text and two purpose-tagged message types. - Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. ### Model explicit choices Make purpose, notice version and user intent distinguishable. #### RCONSENT-101 — Separate optional announcements from booking operations **Task · Medium priority · Foundational** noCV practice brief v5 · RCONSENT-101 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · 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. A single email-enabled flag suppresses booking confirmations when a member opts out of product announcements. Acceptance criteria - Define separate purpose identifiers and allowed message categories. - Specify defaults and unknown-purpose behavior under the fictional product policy. - Keep preference evaluation explicit for each dispatch request. Implementation constraints - Do not infer a legal basis from a message label; the exercise uses a declared product rule. Verification - Evaluate announcement and booking fixtures with optional announcements disabled. - Reject an unknown purpose instead of silently treating it as operational. Deliverables - Purpose registry and preference truth table Rollout and recovery: Introduce purpose tags before migrating existing preference checks. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-102 — Record the notice version shown when a preference changes **Story · Medium priority · Intermediate** noCV practice brief v5 · RCONSENT-102 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: RCONSENT-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Data engineering 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 database stores only the latest boolean, so support cannot tell which choice text the member saw. Acceptance criteria - Append subject, purpose, choice, UTC instant and notice version for each accepted change. - Preserve the prior event and derive current state deterministically. - Reject unknown notice versions and keep notice content immutable once referenced. - Derive the subject from authenticated authority and enforce subject/tenant authorization for preference mutations at the repository boundary. Implementation constraints - Use bounded metadata; do not collect device fingerprints or unrelated browsing history to record a choice. Verification - Change a preference twice under two published notice versions and inspect the retained events. - Submit an unknown version and verify no state change or append. - Attempt a foreign subject and a foreign tenant through the mutation boundary; verify denial with no preference state change or appended event. Deliverables - Versioned preference events and immutable notice fixtures Rollout and recovery: Publish notice versions before accepting their changes; corrections create new versions. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-103 — Make the preference form submit the user’s explicit final choice **Bug · High priority · Intermediate** noCV practice brief v5 · RCONSENT-103 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model explicit choices. Depends on: RCONSENT-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 40% · Privacy engineering 30% · Accessibility 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 autosave race restores a checked box after the user turns it off and navigates away. Acceptance criteria - Represent pending, saved and failed states without presenting an unconfirmed value as saved. - Use version-aware updates so an older response cannot overwrite a newer choice. - Keep controls keyboard-operable and associate errors with the affected purpose. Implementation constraints - Do not use preselected optional choices or obscured controls as a substitute for the declared interaction contract. Verification - Complete two opposite updates out of order and verify the latest accepted choice appears. - Fail a save and navigate back; the form must distinguish persisted state from the unsaved attempt. Deliverables - Preference form state and out-of-order response tests Rollout and recovery: Deploy with the versioned API; reverting the UI must not rewrite stored preference events. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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 choices at delivery Handle stale audiences and queued work with current policy checks. #### RCONSENT-104 — Recheck optional-message eligibility immediately before provider dispatch **Bug · High priority · Advanced** noCV practice brief v5 · RCONSENT-104 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-101, RCONSENT-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Security 30% · Platform 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. An audience list was built yesterday. A member who opted out this morning still receives the queued announcement. Acceptance criteria - Evaluate current purpose-specific preference at the dispatch boundary. - Suppress ineligible work with a recorded safe reason and no provider call. - Define behavior when preference state is unavailable; optional delivery must not assume permission from a stale list. Implementation constraints - The audience snapshot is planning input, not final dispatch authority. Verification - Queue while enabled, opt out, then release the job and verify no provider request. - Make the preference repository unavailable and verify the declared hold/suppression path without sending. Deliverables - Dispatch guard and stale-audience regressions Rollout and recovery: Deploy the guard before replaying old queue entries; monitor bounded suppression categories. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-105 — Bind a queued announcement to its purpose and content revision **Story · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-105 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-101, RCONSENT-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data 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. An operator edits a queued campaign from a booking reminder into promotional content while retaining the original operational tag. Acceptance criteria - Freeze purpose and content revision for each queued delivery request. - Require a new reviewed request when a material content/purpose change occurs. - Reject dispatch when the referenced purpose or content revision cannot be resolved. Implementation constraints - Use synthetic content and a local review state; this ticket sends nothing outside the provider double. Verification - Edit the source campaign after queueing and verify the queued revision remains identifiable. - Attempt to retag optional content as operational through a mutable field and verify the request is rejected. Deliverables - Immutable dispatch request contract and revision tests Rollout and recovery: Version the queue payload and hold unresolved legacy jobs for explicit conversion. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-106 — Stop an opt-out retry from being lost behind an older opt-in event **Bug · High priority · Expert** noCV practice brief v5 · RCONSENT-106 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce choices at delivery. Depends on: RCONSENT-102, RCONSENT-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Preference events reach a delivery replica out of order. A delayed older opt-in restores eligibility after a newer opt-out. Acceptance criteria - Apply a subject/purpose ordering rule with comparable revisions. - Ignore older duplicates while preserving their receipt for bounded diagnosis. - Expose replica freshness and define dispatch behavior when current ordering cannot be established. Implementation constraints - Wall-clock arrival order is not a reliable source revision; document the authority issuing revisions. Verification - Deliver opt-out, then older opt-in, then duplicate opt-out and verify current state remains disabled. - Create a missing-revision gap and verify optional dispatch follows the declared fail-closed or authoritative-read path. Deliverables - Replica ordering protocol and event permutation tests Rollout and recovery: Canary replica reads with authoritative comparisons; disable replica-based optional dispatch if gaps cannot be resolved. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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 history and consistency Reconcile replicas and explain what was actually enforced. #### RCONSENT-107 — Explain which queued messages an opt-out can still prevent **Task · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-107 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-103, RCONSENT-104, RCONSENT-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Integrations 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 settings page promises instant cancellation even when the provider has already accepted a message that cannot be recalled. Acceptance criteria - Define queued, dispatching, provider-accepted and completed boundaries. - Describe prevention guarantees in user-facing copy consistent with those states. - Cancel controllable work and report when a provider-accepted message is beyond the supported recall boundary. Implementation constraints - Do not claim that recording a preference change reverses an already completed delivery. Verification - Opt out at each controlled boundary and compare provider calls with displayed status. - Simulate a provider without recall support and verify the interface does not show a false cancellation success. Deliverables - Cancellation state contract and truthful settings copy Rollout and recovery: Publish the clarified contract with the dispatch guard; preserve accepted-delivery history under the declared retention policy. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-108 — Expose preference history only to its subject and scoped support role **Story · Medium priority · Intermediate** noCV practice brief v5 · RCONSENT-108 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-102, RCONSENT-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A support page returns all members’ preference histories after checking only that the requester has any staff role. Acceptance criteria - Apply subject or tenant-scoped support authorization at the repository boundary. - Return purpose, choice, notice version and time without unrelated contact details. - Audit privileged history access using safe identifiers and bounded reason categories. Implementation constraints - An audit event records access, not an inference about why a person made their choice. Verification - Read the matching subject’s history and an authorized support fixture. - Attempt a foreign-tenant subject and an unscoped staff role; verify denial and no history leakage. Deliverables - Scoped history endpoint and access regressions Rollout and recovery: Enable the history view after repository-level checks pass; keep analytics separate from preference content. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-109 — Reconcile audience caches without restoring old optional choices **Chore · Medium priority · Advanced** noCV practice brief v5 · RCONSENT-109 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-104, RCONSENT-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Privacy engineering 40% · Data 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 nightly audience rebuild copies an old export over the current preference cache. Acceptance criteria - Bind rebuild inputs to a declared cutoff and subject/purpose revisions. - Prevent rebuild writes from replacing newer authoritative or replicated choices. - Report missing and contradictory inputs as reconciliation exceptions. Implementation constraints - Treat audience caches as derived state; preserve current choice authority outside the rebuild. Verification - Run a rebuild while a member opts out and verify the newer revision wins. - Feed contradictory same-revision values and verify the rebuild stops or quarantines them without guessing. Deliverables - Audience reconciliation and concurrent-choice tests Rollout and recovery: Build into a new cache generation and switch only after consistency checks; retain the prior generation for diagnosis. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. #### RCONSENT-110 — Rehearse preference enforcement from settings through provider acknowledgement **Task · Medium priority · Expert** noCV practice brief v5 · RCONSENT-110 · Keep communication preferences consistent across dispatch channels Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review history and consistency. Depends on: RCONSENT-103, RCONSENT-105, RCONSENT-106, RCONSENT-107, RCONSENT-108, RCONSENT-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 40% · Privacy engineering 40% · Integrations 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. Unit tests cover the checkbox and worker separately, but not a user changing a preference while replicas lag and provider requests are in flight. Acceptance criteria - Run a deterministic end-to-end matrix of opt-in/out, replica delay, queued work and provider acknowledgement. - Reconcile every provider request with the exact purpose, content and evaluated preference revisions. - Report tested conditions and unavoidable in-flight limits without claiming legal consent compliance. Implementation constraints - All deliveries terminate at a fake provider; the exercise never sends messages to real recipients. Verification - Exercise out-of-order events and opt-out at each dispatch boundary. - Fail preference lookup and provider acknowledgement separately, then verify retries cannot send an ineligible optional message. Deliverables - Preference-enforcement rehearsal and decision trace Rollout and recovery: Enable the full synthetic workflow only after the matrix passes; hold optional dispatch when authority or revision consistency is unresolved. Project prerequisites: Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Engineer value: Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries. Company value: Create an inspectable preference workflow that can be reviewed against a company-approved communication policy. 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. ## RTELEMETRY — Measure a workflow without collecting its private content A fictional document workspace wants to measure upload completion and failure. Its prototype sends filenames, document titles and raw errors to general analytics. Replace that path with a minimal event contract using synthetic traffic. **Field:** Privacy engineering. **Suggested stack:** TypeScript, JSON Schema, HTTP collector double, SQL. **Engineer value:** Practice minimization, safe failure handling and correct aggregates. **Company value:** Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. **Delivery agreement:** Ten tickets using synthetic data. No claim of anonymization, privacy certification or measured customer behavior is made. ### Setup prerequisites - Create synthetic upload workflows and a local collector that captures received payloads. - Define measurement questions and a separate restricted diagnostic store fixture. ### Specify minimal measurement Define useful questions and an allowlisted event schema. #### RTELEMETRY-101 — Translate upload questions into bounded telemetry events **Task · Medium priority · Foundational** noCV practice brief v5 · RTELEMETRY-101 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify minimal measurement. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · Data 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. Product wants to understand upload failures, but the event captures the entire form submission. Acceptance criteria - Define attempted, accepted, completed and failed events with bounded reason categories. - Map every field to a stated measurement question. - Exclude filenames, document text, form values and unrestricted URLs. Implementation constraints - Counts describe workflow outcomes, not ability, attention or authorship. Verification - Answer the stated questions from a synthetic sequence. - Remove a field without a measurement purpose and verify the report remains possible. Deliverables - Question map and minimal event contract Rollout and recovery: Review the contract before changing collection; unknown fields remain disallowed. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-102 — Reject unknown telemetry fields at the sending boundary **Bug · High priority · Intermediate** noCV practice brief v5 · RTELEMETRY-102 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify minimal measurement. Depends on: RTELEMETRY-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Spreading an error object into an event accidentally includes headers and document metadata. Acceptance criteria - Build payloads through a runtime schema with unknown-field rejection. - Expose a typed interface that does not accept arbitrary payload spreading. - Report rejection without echoing the rejected payload. Implementation constraints - The runtime boundary must handle loosely typed callers as well as normal TypeScript code. Verification - Send a valid completion and inspect the collector payload. - Add token-like headers, nested objects and unknown properties; no event may reach the collector. Deliverables - Telemetry boundary and rejection tests Rollout and recovery: Route events through the boundary before retiring the old sender. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-103 — Use a short-lived workflow correlation ID with a defined scope **Task · Medium priority · Intermediate** noCV practice brief v5 · RTELEMETRY-103 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify minimal measurement. Depends on: RTELEMETRY-101, RTELEMETRY-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy 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. Analytics uses the account email as a permanent join key for all uploads. Acceptance criteria - Use a random operation ID limited to one workflow and its bounded retry window. - Exclude account, document and contact identifiers from the ID. - Document linkability within the operation rather than calling the event anonymous. Implementation constraints - Keep subject mapping outside the generic sink; collect correlation only when required for the stated question. Verification - Retry one operation and verify intended correlation, then start another with a new ID. - Inspect IDs and payloads for subject or document fields. Deliverables - Correlation lifecycle and identifier tests Rollout and recovery: Version the schema and stop emitting direct identifiers before comparing reports. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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 collection limits Reject accidental content, separate diagnostics and bound retention. #### RTELEMETRY-104 — Map upload errors to safe categories before analytics dispatch **Bug · High priority · Advanced** noCV practice brief v5 · RTELEMETRY-104 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce collection limits. Depends on: RTELEMETRY-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. An unfamiliar storage exception contains a signed URL. The fallback serializes it into analytics. Acceptance criteria - Map known failures to bounded categories and unknown failures to a generic category. - Never send raw messages, stacks, headers or signed URLs through generic telemetry. - Route justified detailed diagnostics through a separate restricted interface. Implementation constraints - Do not rely on a regular expression to find every possible secret in an arbitrary object. Verification - Classify known storage, validation and timeout errors. - Inject an unfamiliar nested error with a token-like URL and verify only the generic category is emitted. Deliverables - Safe classifier and nested-error fixtures Rollout and recovery: Deploy the safe fallback before expanding error coverage. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-105 — Keep restricted upload diagnostics out of the analytics transport **Story · Medium priority · Advanced** noCV practice brief v5 · RTELEMETRY-105 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce collection limits. Depends on: RTELEMETRY-103, RTELEMETRY-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Support needs a detailed failure record, but the proposed implementation reuses analytics permissions and transport. Acceptance criteria - Create a separate diagnostic store with tenant-scoped access. - Collect only justified fields with a bounded retention period. - Use safe references for an authorized diagnostic lookup rather than exposing details in counters. Implementation constraints - Use synthetic errors; omit credentials and private upload bytes even from this exercise diagnostic store. Verification - Read a diagnostic as an authorized scoped operator. - Attempt cross-tenant access and inspect analytics requests to verify no diagnostic details pass through them. Deliverables - Restricted diagnostics and transport-separation tests Rollout and recovery: Enable diagnostics independently; analytics must work when diagnostics are disabled. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-106 — Drop telemetry safely when validation or the collector fails **Bug · High priority · Advanced** noCV practice brief v5 · RTELEMETRY-106 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce collection limits. Depends on: RTELEMETRY-102, RTELEMETRY-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. The validation failure handler prints the original event, leaking the content the guard rejected. Acceptance criteria - Never log the rejected event payload. - Keep optional analytics failure independent of upload completion with bounded buffers and retries. - Count dropped events through safe categories so gaps remain visible. Implementation constraints - A collector outage must not block the workflow or grow an unlimited in-memory queue. Verification - Fail validation and inspect captured logs and requests for the rejected marker. - Disconnect the collector under sustained synthetic events and verify bounded buffering and successful uploads. Deliverables - Safe fallback and outage regressions Rollout and recovery: Ship the fallback before stricter validation; drop optional events rather than exposing raw content. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-107 — Expire raw workflow events while preserving only approved aggregates **Chore · Medium priority · Advanced** noCV practice brief v5 · RTELEMETRY-107 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce collection limits. Depends on: RTELEMETRY-103, RTELEMETRY-105, RTELEMETRY-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Data 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. Correlation-bearing raw events remain forever although reporting needs only daily counts. Acceptance criteria - Version fictional raw-event and aggregate retention rules. - Remove expired raw events from the declared sink and replay buffers. - Report unresolved copies and avoid assuming aggregates cannot identify people. Implementation constraints - Use injected time and local adapters; retention values are exercise inputs, not real-world policy advice. Verification - Advance beyond raw expiry and verify sink and replay cleanup while permitted counts remain. - Fail one cleanup adapter and verify its unresolved location appears in the report. Deliverables - Telemetry retention job and copy-reconciliation cases Rollout and recovery: Preview eligibility before removal and version aggregate definitions when collection changes. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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 useful reporting Reconcile aggregates and test disclosure under failures. #### RTELEMETRY-108 — Suppress small-group reports under the exercise disclosure rule **Story · Medium priority · Expert** noCV practice brief v5 · RTELEMETRY-108 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify useful reporting. Depends on: RTELEMETRY-101, RTELEMETRY-103, RTELEMETRY-107. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 70% · Data 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. Filtering a report to a tiny group reveals one person’s workflow even when source events omit email. Acceptance criteria - Apply an exercise threshold of 10 distinct synthetic subjects through a separately restricted aggregation fixture. - Prevent supported filter combinations and complementary totals from releasing a suppressed value. - Document that thresholding addresses a specific disclosure path and does not prove anonymity or differential privacy. Implementation constraints - Do not add permanent subject IDs to the general event sink to support this exercise; define the separate aggregation boundary and tested query family. Verification - Query small, large and overlapping groups and inspect API plus report downloads. - Attempt deduction from a total and complementary group; verify the declared release rule suppresses the relevant results. Deliverables - Report-release rule, disclosure fixtures and limitations Rollout and recovery: Keep fine-grained reports disabled until the rule and tested limits are reviewed. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-109 — Reconcile upload outcome counts without hiding dropped telemetry **Task · Medium priority · Intermediate** noCV practice brief v5 · RTELEMETRY-109 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify useful reporting. Depends on: RTELEMETRY-101, RTELEMETRY-106, RTELEMETRY-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Data engineering 30% · Privacy 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. The success percentage rises during a collector outage because failed uploads lose terminal events. Acceptance criteria - Define denominators and windows from the event contract. - Expose incomplete operations and dropped events instead of treating missing completion as success. - Mark comparisons incomplete when collection gaps prevent a supported result. Implementation constraints - Keep uncertainty visible; never invent missing user behavior with model guesses. Verification - Replay success, failure, duplicate and missing-terminal sequences and reconcile counts. - Simulate asymmetric loss and verify the report is incomplete rather than improved. Deliverables - Outcome aggregation and collection-gap regressions Rollout and recovery: Compare the new calculation with the old one on synthetic traces before changing the report. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. #### RTELEMETRY-110 — Test telemetry collection with planted private-content markers **Task · Medium priority · Expert** noCV practice brief v5 · RTELEMETRY-110 · Measure a workflow without collecting its private content Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Verify useful reporting. Depends on: RTELEMETRY-102, RTELEMETRY-104, RTELEMETRY-105, RTELEMETRY-106, RTELEMETRY-107, RTELEMETRY-108, RTELEMETRY-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Quality 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. The contract looks safe, but errors, retries and report downloads may bypass the sending boundary. Acceptance criteria - Plant unique synthetic markers in filenames, titles, headers, errors and form values. - Exercise success, retry, validation failure, collector outage and report download paths. - Verify markers never reach generic telemetry or logs while required aggregate questions remain answerable. Implementation constraints - Passing supports only inspected conditions and boundaries, not a blanket no-leak guarantee. Verification - Search collector captures, fallback logs and downloaded reports for every marker. - Add a deliberate bypass to the test sender and confirm the regression detects it; verify the guarded implementation passes. Deliverables - Disclosure regression matrix and boundary review Rollout and recovery: Run the matrix when schemas or sending paths change; block the exercise release on a prohibited disclosure. Project prerequisites: Create synthetic upload workflows and a local collector that captures received payloads. Define measurement questions and a separate restricted diagnostic store fixture. Engineer value: Practice minimization, safe failure handling and correct aggregates. Company value: Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite. 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. ## PPOLICY — Untangle partner pricing without changing issued quotes A fictional equipment-rental service supports direct customers and two reseller contracts. Pricing now lives in a long conditional with subclasses left over from a discontinued campaign. Build a local TypeScript quoting module and synthetic fixtures; no starter repository, real charges, tax advice, or payment connection is supplied. Amounts use integer cents and the exercise supports USD only. **Field:** Backend. **Suggested stack:** TypeScript, Node.js, Vitest. **Engineer value:** Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. **Company value:** Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. **Delivery agreement:** Ten linked tickets in three phases. Create the declared local fixtures and module; deliver reproducible quotes, a migration comparison, and a short design decision record. ### Setup prerequisites - Pure functions - Object composition - Integer arithmetic ### Pin down the contract Make quote inputs and current calculations explicit. #### PPOLICY-101 — Capture the reseller examples before splitting the pricing branch **Task · High priority · Foundational** noCV practice brief v5 · PPOLICY-101 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Pin down the contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Quality 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. Pattern topics: Strategy (compare). Strategy — Compare: Compare a small function table with interchangeable pricing strategies before adding an interface to three fixed contract rules. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Support cannot explain why a reseller receives a different total after a harmless-looking cleanup. Recreate a small baseline: direct pricing uses list price; reseller A gets 10% off; reseller B gets 15% off only from ten units. Round the final discount down to whole cents. Acceptance criteria - Record input, contract identity, quantity, list amount, discount, and final amount for each example. - Cover quantities 1, 9, 10, and 11 plus a list amount that produces a fractional-cent discount. - Document whether a function table or Strategy interface would make the current three rules easier to change; either is acceptable with reasons. Implementation constraints - Keep the baseline independent of the replacement implementation; reject non-integer quantities and negative list amounts. Verification - Check manually calculated expected totals against the baseline fixtures. - Introduce an off-by-one tier boundary and confirm the relevant fixture fails. Deliverables - Characterization fixtures and a one-page abstraction decision Rollout and recovery: Use this baseline as the comparison gate for later local changes; retain the original calculations until all differences are explained. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-102 — Stop incomplete quote requests reaching the calculator **Bug · High priority · Foundational** noCV practice brief v5 · PPOLICY-102 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Pin down the contract. Depends on: PPOLICY-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Pattern topics: Builder (compare). Builder — Compare: Assess whether staged construction adds value for quote inputs, or a validated immutable constructor provides the same guarantees more clearly. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The batch caller sometimes omits the pricing revision and the web caller sends quantity as text. Both currently reach calculation through a partially populated options object. Acceptance criteria - A quote request requires tenant, contract revision, nonempty product identity, positive integer quantity, and a nonnegative integer unit price. - Construction fails with field-level errors before any pricing rule runs. - Compare a staged Builder with a validated constructor or factory; select the smallest interface that cannot expose an incomplete request. Implementation constraints - Do not silently fill the contract revision from a mutable global default; runtime input validation remains necessary with TypeScript. Verification - Construct equivalent valid requests from the synthetic batch and web inputs. - Reject missing revision, quantity 'ten', and quantity zero while asserting the calculator was not called. Deliverables - Validated request construction API and invalid-input fixtures Rollout and recovery: Route the two local callers through validation together; keep error mapping compatible with their declared response contracts. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-103 — Add a capped volume contract without editing the existing rules **Story · Medium priority · Intermediate** noCV practice brief v5 · PPOLICY-103 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Pin down the contract. Depends on: PPOLICY-101, PPOLICY-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 70% · System 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. Pattern topics: Strategy (apply). Strategy — Apply: Isolate the capped volume calculation behind the same contract used by existing rules, without adding reseller-specific branches to the caller. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Reseller C needs 20% off from twenty units, capped at 5,000 cents per quote. The current conditional is also used by the other resellers, whose issued quotes must remain reproducible. Acceptance criteria - Select a pricing rule by explicit contract and revision, returning a typed error for an unknown combination. - Implement the threshold and cap while preserving every existing baseline result. - Return a stable rule identity and a breakdown showing the uncapped discount and applied cap. Implementation constraints - Use composition or a function-valued Strategy; adding a class hierarchy is not required. Keep rule evaluation free of I/O. Verification - Exercise quantities 19 and 20 with discounts below, at, and above 5,000 cents. - Request a retired or unknown revision and confirm no fallback contract is used. Deliverables - Capped pricing rule, selector, and regression fixtures Rollout and recovery: Enable reseller C only in the synthetic scenario set; keep the previous selector available for baseline replay. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. ### Support controlled variation Introduce contract differences without mutable rule leakage. #### PPOLICY-104 — Share quote assembly between the portal and nightly import **Chore · Medium priority · Intermediate** noCV practice brief v5 · PPOLICY-104 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support controlled variation. Depends on: PPOLICY-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · System 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. Pattern topics: Factory Method (compare). Factory Method — Compare: Choose between an overridable creation step and an injected factory function for two workflows that must build the same pricing components. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The portal and nightly CSV import each construct their own rule selector. A contract was enabled in the portal but missing from the import, producing different errors for the same customer. Acceptance criteria - Both callers resolve the same contract revisions through one composition boundary. - Caller-specific input parsing stays outside pricing rule creation. - Compare an overridable Factory Method in a shared import workflow with an injected creation function; document the chosen extension boundary. Implementation constraints - Do not introduce dynamic module loading or a dependency-injection container for this local module. Verification - Feed equivalent portal and CSV inputs and compare rule identities, amounts, and unknown-contract errors. - Inject a selector construction failure and confirm neither caller emits a partial quote. Deliverables - Shared assembly boundary and caller contract tests Rollout and recovery: Migrate one local caller at a time with parity tests; revert caller wiring if an unexplained difference appears. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-105 — Keep calculation and explanation revisions in the same contract family **Bug · High priority · Advanced** noCV practice brief v5 · PPOLICY-105 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support controlled variation. Depends on: PPOLICY-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · System 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. Pattern topics: Abstract Factory (compare). Abstract Factory — Compare: Keep the calculator and explainer revision-compatible as a family while evaluating whether a factory interface adds value beyond an immutable record. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A quote calculated with reseller C revision 2 displays revision 1 explanation text, which omits the cap. Separate registries allow a valid calculator to be paired with an incompatible explainer. Acceptance criteria - Resolve calculator and structured explainer as one contract family with a shared revision identity. - Reject a family whose members declare different revisions before serving a quote. - Compare an Abstract Factory with one immutable family record; preserve independent tests for calculation and explanation. Implementation constraints - Explanation output must use the actual calculation breakdown rather than recalculating the discount or parsing a display string. Verification - Generate explanations for capped and uncapped quotes and reconcile every reported amount. - Deliberately pair revision 2 calculation with revision 1 explanation and assert assembly rejection. Deliverables - Contract-family resolver, mismatch fixture, and design comparison Rollout and recovery: Run family validation at local startup; keep the prior complete family available rather than rolling back individual members. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-106 — Remove the rounding hook that bypasses the quote cap **Bug · High priority · Advanced** noCV practice brief v5 · PPOLICY-106 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support controlled variation. Depends on: PPOLICY-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Pattern topics: Template Method (refactor) · Strategy (apply). Template Method — Refactor: Constrain or replace the inherited algorithm hooks so a reseller extension cannot undo a discount cap after validation. Strategy — Apply: Move the variable discount calculation into a narrow composed operation whose result is checked by the common quoting pipeline. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. An inherited calculate method calls a reseller override after the cap check. That override recomputes the discount, so the supposed fixed algorithm no longer enforces its own invariant. Acceptance criteria - Make the order explicit: validate, evaluate the selected rule, apply its declared cap, then derive the final amount and explanation. - No extension point can change the applied amount after the final invariant check. - Replace the unsafe Template Method hook with a narrower composed operation or justify a sealed algorithm with constrained inputs. Implementation constraints - Preserve published rule revision behavior where valid; represent the defective synthetic revision explicitly instead of rewriting issued quote fixtures. Verification - Reproduce the subclass cap bypass and show the corrected pipeline respects the cap. - Supply an extension returning a negative or over-subtotal discount and verify a typed failure. Deliverables - Pipeline refactor and cap-bypass regression Rollout and recovery: Compare old and corrected revision outputs in a local replay; activate a new revision only after listing intentional differences. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-107 — Keep a cloned contract draft from changing the live tier table **Bug · High priority · Intermediate** noCV practice brief v5 · PPOLICY-107 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support controlled variation. Depends on: PPOLICY-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Pattern topics: Prototype (refactor). Prototype — Refactor: Replace a shallow contract clone with a schema-aware draft copy that preserves provenance while preventing shared mutable tier arrays. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A sales-operations preview shallow-copies a contract and changes a nested tier. The original contract shares the array and immediately starts quoting the draft rate. Acceptance criteria - A draft receives its own identity, source revision reference, and independently editable tier values. - Editing, reordering, or deleting a draft tier cannot affect the published contract or another draft. - Reject unsupported values during cloning instead of silently dropping them through JSON serialization. Implementation constraints - Limit the prototype to a declared data-only contract schema; do not clone provider handles, functions, or process state. Verification - Clone two drafts, mutate nested data in one, and compare all three contract snapshots. - Attempt to clone an invalid tier boundary and confirm no partial draft is returned. Deliverables - Schema-aware prototype copy and aliasing regression fixtures Rollout and recovery: Use the new copy path for synthetic previews; existing published fixture revisions remain immutable. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. ### Migrate and simplify Keep version boundaries stable and remove unsupported complexity. #### PPOLICY-108 — Remove the process-wide current-partner setting **Bug · High priority · Advanced** noCV practice brief v5 · PPOLICY-108 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Migrate and simplify. Depends on: PPOLICY-104, PPOLICY-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. Pattern topics: Singleton (remove). Singleton — Remove: Remove a globally mutable partner context that leaks negotiated rules across overlapping requests, while allowing immutable shared definitions. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The quote singleton stores currentPartner before resolving a contract. Two overlapping synthetic requests can change that value between validation and calculation, applying one tenant's negotiated rate to another. Acceptance criteria - Tenant and contract identity travel explicitly through each quote operation. - Remove mutable request state from the Singleton; shared immutable rule definitions may remain cached. - Any remaining cache uses tenant, contract, and revision in its identity and cannot expose another tenant's rule configuration. Implementation constraints - Do not serialize all requests behind a global lock to hide the leak; preserve independent concurrent execution. Verification - Interleave requests for two tenants at a controlled barrier and assert both receive their own rate. - Repeat the test after a failed request and a cache hit to detect stale tenant state. Deliverables - Explicit request context and tenant-isolation concurrency regression Rollout and recovery: Switch the local composition root to stateless quotation; discard the old mutable cache on rollback or restart. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-109 — Pin a quote to one rule family during a revision switch **Story · High priority · Expert** noCV practice brief v5 · PPOLICY-109 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Migrate and simplify. Depends on: PPOLICY-105, PPOLICY-106, PPOLICY-108. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · System design 30% · 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. Pattern topics: Abstract Factory (refactor). Abstract Factory — Refactor: Make family resolution yield a stable snapshot so a revision switch cannot mix products created at different moments in the same operation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A local replay switches a partner from revision 2 to 3 while quotes are in progress. Resolving the calculator at request start and the explainer at response time can produce a mixed-revision quote even after family validation. Acceptance criteria - Resolve and retain one immutable family snapshot for the complete quote operation. - Switches affect only newly started operations; stored quotes retain inputs, family revision, and sufficient breakdown for deterministic replay. - A malformed replacement family is rejected without displacing the last valid selection, and rollback selects a previous complete family. Implementation constraints - Use an in-process deterministic scheduler for the exercise; a distributed configuration service is outside scope. Verification - Pause a quote between calculation and explanation, switch revisions, and verify each concurrent quote is internally consistent. - Reject an incompatible family, perform a rollback, and replay an earlier quote against its pinned revision. Deliverables - Atomic family selection, interleaving tests, and revision-switch runbook Rollout and recovery: Exercise old/new/rollback sequences against synthetic requests; report differences by explicit revision without modifying prior quote records. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. #### PPOLICY-110 — Retire the campaign subclass ladder after the migration **Chore · Medium priority · Advanced** noCV practice brief v5 · PPOLICY-110 · Untangle partner pricing without changing issued quotes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Migrate and simplify. Depends on: PPOLICY-106, PPOLICY-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · System 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. Pattern topics: Factory Method (remove) · Template Method (remove). Factory Method — Remove: Remove unused overridable creation layers once supported rule revisions have one explicit composition path. Template Method — Remove: Collapse campaign inheritance hooks that no longer represent a live variation while preserving archived quote replay. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Five subclass layers still exist for a campaign that ended in the synthetic history. Only one leaf is constructible, but changing an error message requires following overridden methods through every layer. Acceptance criteria - Map reachable construction paths and separate archived-revision replay requirements from unused extension points. - Remove unused Factory Method and Template Method layers while preserving supported quote and error contracts. - Show the before/after change surface for adding a new rule, and retain an abstraction only where it supports a stated variation. Implementation constraints - Keep archived calculations callable through explicit revision lookup; deleting old classes must not make existing fixture quotes unreplayable. Verification - Run the complete quote matrix and replay fixtures after simplifying the hierarchy. - Request an unsupported campaign revision and confirm the same explicit failure, with no fallback to a current rule. Deliverables - Hierarchy simplification, construction-path inventory, and maintenance comparison Rollout and recovery: Remove dead paths in a separate local change after parity is established; revert the simplification if any supported revision becomes inaccessible. Project prerequisites: Pure functions Object composition Integer arithmetic Engineer value: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation. Company value: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design. 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. ## PDOC — Make a document editor predictable as operations grow A fictional support team edits reusable troubleshooting documents with paragraphs, links, and nested sections. The browser prototype has separate toolbar and keyboard handlers, an unreliable undo stack, and mutable shared formatting objects. Create a local editor and synthetic documents; no starter assets, rich-text engine, collaborative backend, or production service is supplied. **Field:** Frontend. **Suggested stack:** TypeScript, React, Vitest, Playwright. **Engineer value:** Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. **Company value:** Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. **Delivery agreement:** Ten tickets across document structure, interaction consistency, and safe evolution. Build the stated local fixtures and return an editor demo, operation tests, and a short design record. ### Setup prerequisites - Browser events - Immutable updates - Accessible form controls ### Establish document operations Make structure and editing commands consistent. #### PDOC-101 — Give nested sections and paragraphs one structural contract **Task · Medium priority · Foundational** noCV practice brief v5 · PDOC-101 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 80% · System 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. Pattern topics: Composite (apply). Composite — Apply: Give leaf paragraphs and nested section containers a consistent traversal contract without coupling the document tree to rendered UI elements. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The outline view handles top-level paragraphs but crashes when a section contains another section. The current arrays do not distinguish leaves from containers or validate imported structure. Acceptance criteria - Represent paragraphs as leaves and sections as containers with stable node identities and explicit discriminated types. - Render and count text nodes consistently through three nested section levels. - Reject duplicate node identities, cycles in programmatic input, and depth above the declared maximum of twenty. Implementation constraints - A Composite may use plain immutable data rather than classes. Keep document structure separate from React elements and DOM nodes. Verification - Render empty, flat, and nested synthetic documents and compare outline counts. - Feed a duplicate identity and a cyclic structure to validation and assert bounded rejection without rendering. Deliverables - Document model, validator, and nested outline example Rollout and recovery: Enable the new model only after validating local sample documents; preserve an untouched input copy when migration rejects a document. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-102 — Make Find next follow document order through collapsed sections **Bug · Medium priority · Foundational** noCV practice brief v5 · PDOC-102 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: PDOC-101. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · Accessibility 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. Pattern topics: Iterator (apply). Iterator — Apply: Traverse the document model in a stable order so search behavior does not change when presentation hides a section. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Find next walks visible DOM elements, so collapsing a section removes its paragraphs from search. Keyboard users cannot tell whether a result was skipped or the query ended. Acceptance criteria - Traverse paragraph text in document preorder, independent of collapsed presentation state. - Find next visits each matching node once, wraps explicitly, and reports position and total through an accessible status message. - An empty query yields no results; a removed node cannot remain the active match after document revision changes. Implementation constraints - Use an Iterator or generator over a stable document snapshot; do not query the DOM to discover content. Verification - Find a match inside a collapsed section and verify the section opens and focus moves to its paragraph control. - Delete the active result and change the query to no matches; confirm stale focus targets and counts are cleared. Deliverables - Snapshot traversal and keyboard search regression Rollout and recovery: Replace local search traversal while retaining the existing search control; fall back to document start when no prior result identity survives. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-103 — Route toolbar and keyboard deletion through one command **Bug · High priority · Intermediate** noCV practice brief v5 · PDOC-103 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish document operations. Depends on: PDOC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Command (apply). Command — Apply: Represent deletion as one validated document operation shared by toolbar, keyboard, and history so entry points cannot diverge. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Toolbar deletion removes an entire selected section, but the keyboard shortcut deletes only its heading and leaves orphaned paragraphs. The two handlers also record different undo entries. Acceptance criteria - Both entry points issue one document command with target identity and expected document revision. - Deleting a section removes its subtree atomically, updates selection to a documented surviving neighbor, and creates one history entry. - Stale, missing, and protected-root targets return explicit failures with no document or history change. Implementation constraints - Command execution belongs outside presentation event handlers; do not store DOM references in history. Verification - Delete the same nested section through toolbar and keyboard and compare document, selection, and history results. - Issue deletion against an old revision and the protected root; assert no partial update. Deliverables - Shared delete command and entry-point parity tests Rollout and recovery: Move both handlers in one local change to prevent mixed semantics; retain saved synthetic documents for replay if the command is reverted. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. ### Coordinate interaction Keep history, controls, and subscriptions tied to one document state. #### PDOC-104 — Restore selection together with content when undoing a deletion **Bug · High priority · Advanced** noCV practice brief v5 · PDOC-104 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Memento (compare). Memento — Compare: Evaluate immutable state snapshots against inverse commands for restoring both document content and logical selection within a bounded undo history. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Undo restores paragraph text but leaves the caret pointing to the deleted node identity. A second edit then modifies the wrong paragraph. History currently keeps an editable reference to the live tree. Acceptance criteria - A history entry captures enough immutable document and selection state to restore one completed command consistently. - Undo and redo restore content and logical selection, and a new edit after undo clears the redo branch. - Retain at most fifty entries and disclose the boundary when older history is discarded; failed commands create no entry. Implementation constraints - Compare a Memento snapshot with inverse commands for this bounded editor; do not serialize focusable elements or browser event objects. Verification - Delete, undo, redo, undo, then type; verify the intended restored paragraph receives the edit. - Mutate the live document after recording history and assert old entries remain unchanged; exercise the fifty-entry limit. Deliverables - Bounded undo/redo history and selection restoration tests Rollout and recovery: Start a new local history session on the upgraded model; existing saved document content remains readable even when transient old history is discarded. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-105 — Stop closed editor tabs from receiving document updates **Bug · Medium priority · Intermediate** noCV practice brief v5 · PDOC-105 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 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. Pattern topics: Observer (refactor). Observer — Refactor: Repair subscription ownership and notification semantics so repeated panel mounts do not retain listeners or multiply document update work. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Opening and closing the preview panel twenty times makes one edit trigger twenty-one outline refreshes. Subscriptions remain in the document store after the panel unmounts. Acceptance criteria - Each subscription has an idempotent unsubscribe operation tied to the subscribing component's lifetime. - One committed document operation sends one versioned notification to each active subscriber, including when callbacks subscribe or unsubscribe during delivery. - A failed subscriber does not stop delivery to other subscribers, and errors are reported without logging document content. Implementation constraints - Keep the Observer surface small and define whether delivery is synchronous; avoid a global application event bus for this document-local need. Verification - Mount and unmount the preview twenty times, edit once, and assert only active listeners run. - Have one listener throw and another unsubscribe during delivery; verify remaining delivery and the next notification set. Deliverables - Subscription lifecycle fix and repeated-mount regression Rollout and recovery: Replace document-local subscriptions together; reset transient listeners on reload without changing saved document data. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-106 — Untangle the toolbar's direct calls into three side panels **Chore · Medium priority · Advanced** noCV practice brief v5 · PDOC-106 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-103, PDOC-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · System 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. Pattern topics: Mediator (compare). Mediator — Compare: Compare a document-scoped coordinator with reducer state to remove circular panel calls without creating a central object that owns every editor feature. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Selecting a link makes the toolbar call the inspector, the inspector call the outline, and the outline call the toolbar again. A new panel added another circular dependency and occasional repeated selection updates. Acceptance criteria - Define one direction for selection intents and one authoritative logical selection state. - Toolbar, inspector, and outline remain consistent without importing or invoking each other's component instances. - Compare a document-scoped Mediator with reducer-driven state and callbacks; retain the simpler option that exposes event flow clearly. Implementation constraints - Do not move every unrelated editor concern into a central god object; keep document commands and formatting rules separately testable. Verification - Select a nested link from each panel and compare selection and enabled toolbar actions. - Send the same selection intent twice and remove the selected node; assert bounded updates and a consistent empty selection. Deliverables - Interaction dependency refactor and selection-flow decision record Rollout and recovery: Migrate the three selection participants together in the local editor; retain command behavior and shortcut bindings during the change. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-107 — Prevent edit actions while a replacement document is importing **Bug · High priority · Intermediate** noCV practice brief v5 · PDOC-107 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate interaction. Depends on: PDOC-104, PDOC-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 70% · Accessibility 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. Pattern topics: State (apply). State — Apply: Represent import lifecycle and command eligibility with explicit states so contradictory loading/editing flags cannot erase user work. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Import sets isLoading but leaves isEditable true. A user types while the asynchronous parser runs, then the parsed document replaces those edits without a warning. Acceptance criteria - Define explicit ready, importing, and import-failed states and legal transitions, including cancel and retry. - Edit commands are rejected during replacement import, and controls expose their disabled reason accessibly. - A failed or cancelled import preserves the prior document and selection; a late result from a cancelled attempt cannot replace them. Implementation constraints - A tagged union and transition function can implement State semantics; separate state representation from parsing work. Verification - Delay parsing, attempt a keyboard edit, and verify no hidden edit or unexpected replacement occurs. - Cancel one import, start another, then resolve results in reverse order; only the current successful attempt may install a document. Deliverables - Import state transitions and delayed-result interaction tests Rollout and recovery: Replace boolean flags with the explicit local state model; keep the last valid document available until a replacement commits. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. ### Exercise larger and changing documents Measure sharing and preserve compatibility under export and restoration. #### PDOC-108 — Measure whether sharing text styles is worth the indirection **Task · Low priority · Advanced** noCV practice brief v5 · PDOC-108 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-101, PDOC-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Frontend 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. Pattern topics: Flyweight (compare). Flyweight — Compare: Measure immutable sharing of repeated formatting against plain values, while excluding mutable per-paragraph state from the shared objects. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A generated 20,000-paragraph fixture repeats twelve formatting combinations. A proposed style pool reduces duplicate objects, but its mutable shared entries can change many paragraphs when one is edited. Acceptance criteria - Compare plain immutable style values with Flyweight style identities using the same declared fixture and measurement procedure. - If pooling is retained, intrinsic styles are immutable and per-paragraph selection or editing state stays outside the pool. - Report memory observations and edit/undo latency across five runs, including environment and variance; retain the simpler representation if benefits are inconclusive. Implementation constraints - Measure the model separately from DOM rendering and keep the fixture size fixed; do not claim production performance from one browser snapshot. Verification - Change one paragraph's style and undo it without changing any other paragraph. - Attempt to mutate an interned style and verify prevention; repeat opening and closing documents to check that unused pools are released. Deliverables - Reproducible comparison, isolation tests, and keep-or-remove decision Rollout and recovery: Keep style pooling behind a local representation switch until correctness and measurements support it; preserve a conversion back to plain values. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-109 — Add text and outline export without teaching nodes about file formats **Story · Medium priority · Advanced** noCV practice brief v5 · PDOC-109 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-101, PDOC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 60% · System 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. Pattern topics: Visitor (compare). Visitor — Compare: Separate growing export operations from relatively stable node types, comparing a Visitor with exhaustive functions and their cost when a new node type arrives. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Every new export format adds another method to paragraph and section objects. The team needs plain text and a structured outline, and expects document node types to change less often than export formats. Acceptance criteria - Both exporters handle every supported node type and preserve documented section order and paragraph boundaries. - Keep export operations outside the document data model using a Visitor or exhaustive discriminated-union functions, with a written choice. - An unknown node type fails with its identity and type instead of silently losing its content. Implementation constraints - Treat link labels as text and serialize structured output through a serializer; exporting must not mutate document state or trigger network requests. Verification - Export a nested fixture containing empty sections and links and compare explicit expected outputs. - Introduce an unsupported node kind and assert both exporters fail visibly while leaving the input unchanged. Deliverables - Two export operations, exhaustive handling tests, and variation tradeoff note Rollout and recovery: Add exports as local downloads after fixture comparison; disable one format independently if its contract changes. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. #### PDOC-110 — Reject stale history after replacing the document **Bug · High priority · Expert** noCV practice brief v5 · PDOC-110 · Make a document editor predictable as operations grow Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise larger and changing documents. Depends on: PDOC-104, PDOC-107, PDOC-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · System design 30% · 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. Pattern topics: Command (refactor) · Memento (refactor). Command — Refactor: Bind queued editor operations to the session that created them so delayed commands cannot operate on a replacement document with reused node IDs. Memento — Refactor: Give history snapshots an explicit document-session boundary and install replacement content together with a coherent history reset. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A delayed keyboard event queues Undo just before a successful import installs another document. The old history entry then restores part of the previous document into the replacement because both documents happen to contain node p1. Acceptance criteria - Bind commands and history entries to a document session identity as well as a revision. - Replacement import commits document, logical selection, session identity, and history reset as one state transition. - Stale queued commands and incompatible snapshots fail without modifying the active document; cancellation preserves the previous session and valid history. Implementation constraints - Build a deterministic event-order harness rather than timing-dependent sleeps; this ticket does not require collaborative editing or remote persistence. Verification - Interleave queued Undo, successful import, and duplicate node identities; assert the replacement never receives previous-session content. - Fail and cancel imports at each transition boundary, then verify undo remains valid only for the preserved session. Deliverables - Session-bound command/history contract and interleaving regression matrix Rollout and recovery: Introduce session identities at the local editor boundary and clear incompatible transient history once; preserve saved content separately for recovery. Project prerequisites: Browser events Immutable updates Accessible form controls Engineer value: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs. Company value: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption. 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. ## PPROVIDER — Evolve a notification boundary with predictable failure behavior A fictional maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied. **Field:** Integrations. **Suggested stack:** TypeScript, Node.js, Vitest, Local HTTP stubs. **Engineer value:** Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. **Company value:** Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. **Delivery agreement:** Ten tickets over three phases. Create local provider doubles and contract fixtures, evolve the integration layer, and supply a fault replay plus an operational handoff. ### Setup prerequisites - HTTP contracts - Asynchronous cancellation - Dependency injection ### Define the provider boundary Separate scheduling intentions from transport details. #### PPROVIDER-101 — Normalize the second provider's acknowledgement without inventing delivery **Story · High priority · Foundational** noCV practice brief v5 · PPROVIDER-101 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Adapter (apply). Adapter — Apply: Translate incompatible acknowledgement payloads into a shared contract without overstating queued or accepted messages as delivered. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Provider A returns accepted plus a request ID; provider B returns queued with a nested reference. The existing mapper calls both delivered, even though neither acknowledgement confirms a recipient received the notice. Acceptance criteria - Define a shared result contract for accepted, rejected, and unknown outcomes with provider identity and an optional provider reference. - Map both declared acknowledgement shapes to accepted while preserving their references; never map acknowledgement alone to delivered. - Malformed success payloads and unknown response codes return a typed integration error without exposing raw recipient data. Implementation constraints - Use an Adapter for each local stub; preserve unsupported semantics explicitly rather than forcing every response into a success boolean. Verification - Map representative A and B acknowledgements and compare the shared contract. - Return a success status with a missing required reference and an undocumented state; assert explicit failure. Deliverables - Provider adapters, shared result contract, and mapping fixtures Rollout and recovery: Run both adapters against local scripted responses before selecting B for synthetic requests; retain A's mapping for regression comparison. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-102 — Keep provider SDK types out of appointment rules **Chore · Medium priority · Intermediate** noCV practice brief v5 · PPROVIDER-102 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: PPROVIDER-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · System design 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. Pattern topics: Ports and Adapters (apply). Ports and Adapters — Apply: Move vendor request types and error codes behind a domain-owned notification port so scheduling rules can run without initializing transport code. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Rescheduling logic imports provider B's request object and recognizes its numeric error codes. A provider SDK change now forces changes in domain tests that never make a network request. Acceptance criteria - Appointment logic depends on a small notification port using domain-owned request and result types. - Place provider-specific mapping, serialization, and error interpretation in adapters selected at the composition boundary. - Run appointment decisions against an in-memory port double with no provider package imports or transport initialization. Implementation constraints - Keep this a module boundary in one process; the exercise does not justify splitting the application into services. Verification - Replace A with B through composition wiring and run the same appointment behavior cases. - Make the port return rejected and unknown outcomes and verify the domain does not treat either as successful acceptance. Deliverables - Domain notification port and provider-free appointment tests Rollout and recovery: Migrate one appointment use case to the port, compare results, then migrate the remaining local caller; revert adapter wiring if parity fails. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-103 — Validate notice inputs before choosing a provider **Bug · High priority · Foundational** noCV practice brief v5 · PPROVIDER-103 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the provider boundary. Depends on: PPROVIDER-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Chain of Responsibility (compare). Chain of Responsibility — Compare: Choose an ordered, short-circuiting validation structure that guarantees notice preferences are checked before any provider side effect. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. An invalid synthetic recipient passes provider selection and fails differently for A and B. Another path checks the notification preference only after the stub has already accepted the request. Acceptance criteria - Validate appointment identity, synthetic recipient format, and declared notice preference before any adapter call. - Define the order and short-circuit behavior of validation stages, returning stable reason codes. - Compare a Chain of Responsibility with an explicit sequence of validation functions; a skipped preference check must be structurally impossible. Implementation constraints - Use only synthetic .invalid addresses; do not contact any external address or interpret this exercise as a compliance certification. Verification - Accept valid synthetic input and assert each required check runs before one provider call. - Reject malformed recipient and disabled preference with a provider-call count of zero; verify the documented first error when both fail. Deliverables - Ordered preflight validation and no-send regression fixtures Rollout and recovery: Apply the shared validation path to both local providers together; leave explicit rejection visible to the scheduler. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. ### Compose cross-cutting behavior Keep orchestration and wrapper ordering visible and testable. #### PPROVIDER-104 — Decouple notice format from the selected transport **Story · Medium priority · Advanced** noCV practice brief v5 · PPROVIDER-104 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-102, PPROVIDER-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · System design 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. Pattern topics: Bridge (compare). Bridge — Compare: Separate independently varying notice content and provider transport so their combinations do not require a growing subclass matrix. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. ReminderEmailProviderA and CancellationEmailProviderA have matching ProviderB subclasses. Adding a third notice type is multiplying classes even though formatting and transport are independent choices. Acceptance criteria - Separate notice-content construction from provider transport, with two notice types runnable through both local providers. - Document required transport capabilities and reject incompatible content before sending; do not silently drop a cancellation reason. - Compare a Bridge between notice abstraction and transport with two composed functions, avoiding one subclass for every combination. Implementation constraints - Use plain text only in the exercise; user-provided content remains data and is never executed as a template or command. Verification - Exercise all four type/provider combinations and compare semantic content after adaptation. - Configure a transport without a required capability and assert rejection before any stub call. Deliverables - Independent content/transport composition and capability matrix tests Rollout and recovery: Replace combination classes after all four fixtures pass; keep the declared provider contract stable while moving formatting code. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-105 — Record one bounded telemetry event around each provider attempt **Story · Medium priority · Intermediate** noCV practice brief v5 · PPROVIDER-105 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Site reliability 30% · Privacy 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. Pattern topics: Decorator (apply). Decorator — Apply: Add consistent attempt instrumentation around interchangeable adapters without embedding logging behavior in each provider mapping. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Adapter A logs full payloads while B logs nothing on exceptions. The team cannot compare local attempt outcomes without exposing synthetic recipient and notice content in generic logs. Acceptance criteria - Wrap provider attempts with a common duration and outcome recorder that emits exactly one completion event per attempt. - Limit event fields to operation identity, provider, outcome category, elapsed duration, and declared adapter version; omit recipient, body, and credentials. - A telemetry sink failure cannot change the provider result or mask an adapter exception. Implementation constraints - Use a Decorator or explicit higher-order function; inject clock and event sink for deterministic tests, and avoid high-cardinality recipient labels. Verification - Run accepted, rejected, thrown-error, and cancellation cases and assert one correctly categorized event each. - Make the sink throw and inspect all event payloads for synthetic secret and recipient markers. Deliverables - Attempt telemetry wrapper and privacy/failure regression fixtures Rollout and recovery: Enable the wrapper on local stubs first; disable the sink independently while preserving attempt behavior and correlation identities. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-106 — Replace the scheduler's six-call notification sequence with one bounded operation **Chore · Medium priority · Advanced** noCV practice brief v5 · PPROVIDER-106 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-103, PPROVIDER-104, PPROVIDER-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 30% · System 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. Pattern topics: Facade (apply). Facade — Apply: Offer scheduling callers one explicit notification operation while preserving distinct validation, content, and transport responsibilities underneath. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Every scheduling handler must validate, format, select an adapter, initialize telemetry, call send, and map the result in the right order. One handler skips validation and another catches all failures as accepted. Acceptance criteria - Expose one application operation that coordinates the declared preflight, content, adapter, and result steps. - Return typed accepted, rejected, and unknown outcomes without concealing which stage failed. - Keep policy and transport modules independently testable; the Facade must not absorb appointment rules, template storage, or unrelated administration. Implementation constraints - This operation makes at most one provider attempt. Automatic failover and retries are excluded until duplicate-acceptance behavior is defined. Verification - Call the operation from reminder and cancellation flows and compare stage order and result handling. - Fail every stage in turn and assert later side effects do not run; preserve an unknown outcome after ambiguous transport completion. Deliverables - Notification Facade and stage-failure test matrix Rollout and recovery: Move the two local scheduling handlers behind the operation with parity fixtures; revert one caller only if its behavior remains explicit. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-107 — Remove the transparent send proxy that retries an ambiguous timeout **Bug · High priority · Advanced** noCV practice brief v5 · PPROVIDER-107 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compose cross-cutting behavior. Depends on: PPROVIDER-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 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. Pattern topics: Proxy (remove). Proxy — Remove: Remove transparent retry behavior that changes send semantics after ambiguous completion, exposing retry decisions and operation identity to the application. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A transparent Proxy automatically repeats any timed-out call. The local stub can accept a notice and drop the response, so the hidden retry records two accepted deliveries while the application sees one success. Acceptance criteria - Remove hidden retry behavior from the send proxy and expose ambiguous completion as unknown. - If a retry is explicitly requested, preserve the original operation identity and require a declared provider deduplication contract; otherwise refuse the retry. - Record attempt identities separately from operation identity so the handoff can explain what was tried without claiming recipient delivery. Implementation constraints - Keep the exercise local and deterministic; a timeout does not prove a provider rejected the operation, and selecting the other provider is not a safe default. Verification - Have the stub accept then lose its response; assert one attempt and an unknown outcome with hidden retries disabled. - Try an explicit retry against a stub lacking deduplication support and confirm it is refused; test convergence on a deduplicating stub. Deliverables - Proxy simplification, explicit retry contract, and ambiguous-timeout reproduction Rollout and recovery: Disable automatic retry in the local composition first; review stored unknown operations before any explicit retry experiment. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. ### Contain provider failure Bound outstanding work and verify recovery without duplicate delivery. #### PPROVIDER-108 — Pause a failing provider and admit one recovery probe **Story · High priority · Advanced** noCV practice brief v5 · PPROVIDER-108 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-105, PPROVIDER-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Integrations 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. Pattern topics: Circuit Breaker (apply). Circuit Breaker — Apply: Stop repeated attempts to a failing provider with explicit failure classification and a single controlled recovery probe. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Provider B returns transport failures for every synthetic request. Callers continue spending the full timeout on each attempt even though the service needs a short recovery window. Acceptance criteria - Open the circuit after three consecutive declared transport failures, reject further attempts locally for thirty simulated seconds, and then admit one recovery probe. - A successful probe closes the circuit; a failed probe reopens it. Validation errors and provider business rejections do not count as transport failures. - Track circuits independently per provider, return a distinct circuit-open outcome, and never report rejected local attempts as provider calls. Implementation constraints - Use an injected monotonic clock and explicit transition logic; no real-time sleeps, external service, or automatic cross-provider failover is required. Verification - Advance the fake clock through closed, open, and half-open states and assert allowed call counts. - Race several requests at the recovery boundary and confirm exactly one probe; verify A remains usable while B is open. Deliverables - Circuit Breaker state transitions and deterministic recovery tests Rollout and recovery: Enable the breaker around B's local stub first, observe transitions, and preserve unknown-operation records when resetting circuit state. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-109 — Keep one slow provider from occupying every notification slot **Story · High priority · Advanced** noCV practice brief v5 · PPROVIDER-109 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Site reliability 40% · Integrations 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. Pattern topics: Bulkhead (apply). Bulkhead — Apply: Partition active and queued capacity by provider so stalled requests cannot exhaust another provider's execution slots or grow an unbounded queue. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Twenty stalled B requests consume the module's shared work pool. A's immediate responses cannot start, and callers keep adding pending requests until memory grows. Acceptance criteria - Give each provider at most three active attempts and five queued operations, with a typed overload result when its queue is full. - Queued cancellations remove work before execution; every completion or failure releases its slot exactly once. - A stalled B provider cannot consume A's admission capacity, and queue wait contributes to the caller's overall deadline. Implementation constraints - Use bounded in-process queues and local promise gates; do not add an external broker or unbounded task buffers. Verification - Saturate B, submit A work, and verify A starts promptly while B's active and queued counts stay within bounds. - Cancel queued work, throw inside an attempt, and resolve an attempt twice through a faulty stub; verify no slot leak or over-release. Deliverables - Per-provider Bulkhead and overload/cancellation regression harness Rollout and recovery: Start with the declared local limits and record saturation behavior; reject new work explicitly while draining queues before a configuration change. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. #### PPROVIDER-110 — Prove wrapper order preserves deadlines, probe limits, and attempt counts **Task · High priority · Expert** noCV practice brief v5 · PPROVIDER-110 · Evolve a notification boundary with predictable failure behavior Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contain provider failure. Depends on: PPROVIDER-108, PPROVIDER-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Site reliability 30% · Integrations 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. Pattern topics: Decorator (refactor) · Circuit Breaker (refactor) · Bulkhead (refactor). Decorator — Refactor: Make wrapper ordering explicit so instrumentation describes real attempts and cancellation is respected across queue, breaker, and adapter boundaries. Circuit Breaker — Refactor: Release unused half-open probe reservations when queued operations expire or are cancelled, preserving a path to later recovery. Bulkhead — Refactor: Coordinate queue admission and slot release with the overall operation deadline without leaking capacity during concurrent completion and cancellation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The breaker, queue, telemetry, and adapter work in isolation, but a half-open probe can expire while queued and leave the circuit stuck. Another wrapper order records circuit-open rejections as actual provider attempts. Acceptance criteria - Document wrapper order and distinguish operation admission, queue wait, probe reservation, and physical provider attempt. - An overall deadline or cancellation releases queue capacity and any unused probe reservation, with no adapter call after cancellation commits. - Telemetry reconciles submitted, locally rejected, cancelled, and actually attempted operations; terminal outcomes and slot release occur once under every tested interleaving. Implementation constraints - Use a deterministic fake scheduler and clock. Change composition boundaries where needed rather than adding retries that could duplicate an accepted notice. Verification - Exercise a half-open probe queued behind slow work, then cancel it and verify a later eligible request can probe. - Race deadline expiry with adapter completion and circuit opening; assert exact attempt counts, bounded slots, and one terminal outcome. Deliverables - Reviewed composition order, interleaving matrix, and local failure-recovery runbook Rollout and recovery: Run the full fault replay against both local providers before selecting the new composition; preserve a configuration switch and unknown-operation list for rollback analysis. Project prerequisites: HTTP contracts Asynchronous cancellation Dependency injection Engineer value: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults. Company value: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion. 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. ## PDSL — Make fulfillment rules understandable without executing scripts A fictional fulfillment product routes parcels using destination zone, weight in grams, and service level. Its next release needs nested eligibility rules, but arbitrary customer scripts are out of scope. Create a local TypeScript baseline and synthetic parcel/rule fixtures; no starter repository or fixtures are supplied. Keep parsing and evaluation in a local practice application with no network, filesystem, or host-code expressions in the language. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Node.js, Vitest, JSON. **Engineer value:** Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. **Company value:** Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. **Delivery agreement:** Ten tickets across language definition, evaluation, and evolution. Author a minimal local baseline for individual tickets or build the complete synthetic rule engine and compatibility report. ### Setup prerequisites - Recursive data structures - Parser error handling - Discriminated unions ### Define the language boundary Give saved rules an explicit grammar, tree shape, and useful diagnostics. #### PDSL-101 — Settle literal and operator precedence before saving warehouse rules **Task · High priority · Foundational** noCV practice brief v5 · PDSL-101 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Pattern topics: Interpreter (apply). Interpreter — Apply: Use an explicit expression grammar as the interpreter boundary so precedence and permitted operations are reviewable before execution. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Operations wrote zone == 'north' OR service == 'express' AND weightGrams < 500. Two engineers read it differently, and there is no grammar to decide which parcels qualify. Acceptance criteria - Define parentheses, AND-before-OR precedence, quoted strings, and nonnegative integer gram literals with unambiguous examples. - Reject unknown operators, decimal weights, and trailing tokens with a stable code and source range. - A parse result carries a language version; invalid input cannot produce a saved rule object. Implementation constraints - Keep the grammar limited to the three documented parcel fields; do not translate input into JavaScript or expose general function calls. Verification - Parse the disputed expression and its parenthesized alternative into different expected trees. - Reject an unterminated string and an extra closing parenthesis without a stack trace in the public diagnostic. Deliverables - Versioned grammar note, parser entry point, and synthetic parsing cases Rollout and recovery: Use the grammar for newly authored local rules first; retain the original text when reverting the parser version. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-102 — Represent nested all-of and any-of rules without special-case depth handling **Story · High priority · Intermediate** noCV practice brief v5 · PDSL-102 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: PDSL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 75% · System design 25%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Composite (compare). Composite — Compare: Compare uniform leaf/group composition with the existing fixed-depth structure, retaining type safety without requiring a class per node. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The current rule model has separate fields for one AND group and one OR group. A warehouse needs (north OR west) AND (express OR under-500g), which cannot be represented without duplicated conditions. Acceptance criteria - Model comparisons and nested all-of/any-of groups through one expression contract while preserving child order. - Reject empty groups and enforce a documented maximum of 16 levels and 1,000 nodes at construction. - Serialize and parse a valid tree without changing its grouping, field types, or language version. Implementation constraints - Compare a discriminated-union tree with a class hierarchy; choose the smaller representation that supports the required operations. Verification - Round-trip a four-level mixed rule and compare every node and child position. - Reject a seventeenth level and a reused mutable child that would change an already constructed rule. Deliverables - Expression model, boundary tests, and a short representation decision Rollout and recovery: Convert only synthetic flat rules first and compare their trees; retain flat input conversion until nested-rule behavior is checked. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-103 — Point rule editors to invalid fields before evaluation starts **Story · Medium priority · Foundational** noCV practice brief v5 · PDSL-103 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: PDSL-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · Developer tooling 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. Pattern topics: Visitor (compare). Visitor — Compare: Keep validation separate from evaluation and compare visitor dispatch with an exhaustive function for adding independent tree operations. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A rule containing weightGrams == 'heavy' parses successfully, then fails when a parcel reaches the evaluator. Support needs all actionable type errors from the saved rule before attempting a run. Acceptance criteria - Validate permitted field/operator/literal combinations in a pass that does not evaluate parcel data. - Return diagnostics in source order with node path and source range, capped at 50 with an omitted count. - Keep the rule tree unchanged and report an unknown node kind as an unsupported-language error. Implementation constraints - Compare a visitor with an exhaustive traversal function; document how adding a node forces the validator to handle it. Verification - Collect distinct string/number mismatch diagnostics from separate branches in stable order. - Pass a synthetic unknown node and a 70-error tree; verify safe rejection and the diagnostic cap. Deliverables - Static rule validator and support-facing diagnostic examples Rollout and recovery: Run validation on synthetic saved rules in report-only mode before blocking new invalid saves. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. ### Evaluate and inspect Make rule behavior deterministic and inspectable without mutable shared state. #### PDSL-104 — Stop treating an absent parcel weight as a zero-weight match **Bug · High priority · Advanced** noCV practice brief v5 · PDSL-104 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Pattern topics: Interpreter (refactor). Interpreter — Refactor: Replace coercion spread across conditions with one explicit interpreter result model and consistent missing-value semantics. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A carrier feed omitted weightGrams and the evaluator coerced it to zero. The parcel passed a weight limit despite having no measurement; OR branches also mask inconsistent missing-value behavior. Acceptance criteria - Define true, false, and unknown outcomes with explicit AND/OR truth tables and no implicit string/number coercion. - Missing referenced inputs produce unknown with the relevant field path; only true authorizes the synthetic routing decision. - Repeated evaluation of the same rule and parcel returns the same outcome and bounded explanation without mutating either input. Implementation constraints - Short-circuit only when the declared three-valued semantics permit it; retain enough information to explain the final outcome. Verification - Exercise every pair in both truth tables, including false AND unknown and true OR unknown. - Evaluate missing, null, zero, and numeric-string weights and assert the distinct documented results. Deliverables - Typed evaluation result, truth-table regression cases, and explanation format Rollout and recovery: Compare decisions against a synthetic parcel corpus; keep unknown outcomes in a review queue and revert the evaluator by version. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-105 — Keep draft rule builders from changing previously saved expressions **Bug · Medium priority · Intermediate** noCV practice brief v5 · PDSL-105 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · Frontend 30% · 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. Pattern topics: Builder (compare). Builder — Compare: Assess whether staged rule construction earns its complexity and make the handoff from a mutable draft to an immutable expression explicit. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The rule editor reuses a builder to produce two templates. Adding a condition to the second template mutates the first because both saved objects reference the builder's child array. Acceptance criteria - A build operation returns an immutable validated expression with no writable references to builder state. - Incomplete drafts identify missing fields without emitting a partially valid saved rule. - Building twice and then editing the draft cannot change either earlier result or its serialized bytes. Implementation constraints - Compare a builder with ordinary validated object construction; retain staged construction only where it improves the editor's incomplete-state handling. Verification - Build two rules from one draft and edit a nested child; verify both saved rule snapshots stay unchanged. - Attempt to build a comparison without a literal and confirm no persisted rule identity is allocated. Deliverables - Draft-to-rule construction API and shared-reference regression reproduction Rollout and recovery: Switch local editor saves behind a construction flag; old saved rules stay readable if the editor construction path is reverted. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-106 — Give the support inspector a stable walk through nested conditions **Task · Medium priority · Intermediate** noCV practice brief v5 · PDSL-106 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 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. Pattern topics: Iterator (apply). Iterator — Apply: Provide a shared traversal contract for independent tree consumers without exposing the representation or coupling their presentation logic. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The support inspector duplicates recursive loops for a tree outline, field usage report, and copyable diagnostics. These loops disagree on child order and sometimes skip a nested condition. Acceptance criteria - Expose a read-only depth-first iterator that yields each node once with a stable path and parent path. - The outline and field usage report consume the same traversal contract while retaining their own presentation rules. - Early termination releases traversal state, and malformed cycles are rejected instead of looping indefinitely. Implementation constraints - Do not expose the mutable traversal stack or allow consumers to rewrite children during iteration. Verification - Walk a mixed tree and compare the complete path order used by both consumers. - Break after the first leaf, then start a fresh iteration; also supply a manually constructed cycle and assert a bounded error. Deliverables - Traversal API, two migrated consumers, and cycle/early-exit checks Rollout and recovery: Compare inspector output before replacing the duplicated traversals; restore the old read path if ordering changes unexpectedly. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-107 — Measure whether interning field symbols actually reduces rule-cache memory **Task · Low priority · Advanced** noCV practice brief v5 · PDSL-107 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Compiler and language 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. Pattern topics: Flyweight (compare). Flyweight — Compare: Test whether sharing intrinsic symbol metadata saves enough memory while keeping source, tenant, and evaluation context out of shared objects. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A heap profile suggests thousands of cached rules repeat the same field and operator metadata. The proposed optimization shares entire nodes, including source locations and tenant rule identifiers. Acceptance criteria - Benchmark an authored 10,000-rule synthetic corpus before and after sharing only immutable context-free symbols. - Keep source spans, rule identities, and parcel evaluation state outside shared symbols, and bound or evict the intern pool. - Report retained heap, parse time, and identical rule outcomes across repeated runs; retain the optimization only if the measured tradeoff justifies it. Implementation constraints - State runtime, corpus seed, warmup, and measurement variability; a decision to remove the pool is an acceptable result. Verification - Compare all evaluation outcomes and source-specific diagnostics with pooling enabled and disabled. - Load many distinct invalid symbols and verify rejection cannot grow the intern pool without bound or reuse another rule's source range. Deliverables - Reproducible heap comparison and an evidence-backed keep-or-remove decision Rollout and recovery: Default pooling off until the local measurements pass review; disabling it must leave serialized rule content unchanged. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. ### Evolve within limits Add syntax safely, bound adversarial inputs, and preserve old rule versions. #### PDSL-108 — Add membership expressions without leaving tree operations behind **Story · Medium priority · Expert** noCV practice brief v5 · PDSL-108 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-104, PDSL-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · System 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. Pattern topics: Visitor (compare) · Composite (refactor). Visitor — Compare: Use a real new-node change to compare operation-oriented visitors with node-local methods and make the extension cost visible in the patch. Composite — Refactor: Integrate the membership leaf into the uniform expression tree without adding special group traversal paths or weakening node validation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Warehouse rules repeat long chains such as zone == 'north' OR zone == 'west'. Adding IN to evaluation alone would leave validation, inspection, and serialization unaware of the new node. Acceptance criteria - Add string-set membership with a 50-item limit, explicit duplicate handling, and no implicit type conversion. - Update parsing, validation, evaluation, inspection, and serialization, with an exhaustive mechanism that exposes unhandled node kinds. - Compare visitor-based operations with node-local methods for this change and explain which extension axis becomes easier or harder. Implementation constraints - New syntax uses a new language version; existing rules retain their old version and behavior, including missing-field outcomes. Verification - Compare membership and equivalent OR rules over present, absent, matching, and nonmatching zones. - Run every tree operation on the new node; reject a 51-item set and an older parser receiving the new version. Deliverables - Membership implementation, operation coverage matrix, and extension tradeoff note Rollout and recovery: Enable authoring for the new version after all operations support it; turn off new authoring without rewriting saved older rules. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-109 — Bound rule parsing and explanation work before expensive allocation **Bug · High priority · Advanced** noCV practice brief v5 · PDSL-109 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-104, PDSL-108. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · Security 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. Pattern topics: Interpreter (refactor). Interpreter — Refactor: Make resource accounting part of the interpreter contract so nested expressions cannot bypass limits through separate parsing or explanation paths. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The editor rejects a deeply nested rule only after parsing its entire text. A pasted megabyte of repeated parentheses stalls the local worker, and explanations allocate one message for every attempted comparison. Acceptance criteria - Reject source text above 64 KiB before tokenization and enforce depth, node, and literal limits as input is consumed. - Bound evaluation steps and explanation entries independently; return distinct stable limit codes without partial routing approval. - After a rejected rule, the same process can evaluate a small valid rule with no retained traversal or explanation state. Implementation constraints - Use deterministic operation budgets rather than relying solely on wall-clock time; no regex features with unbounded backtracking are required by this language. Verification - Exercise just-below and just-above each declared bound with reproducible generated inputs. - Alternate rejected and valid rules for 100 runs; confirm bounded diagnostics and unchanged valid outcomes. Deliverables - Limit enforcement changes, adversarial local cases, and resource-bound report Rollout and recovery: Publish the limit codes in the local editor before enforcing them; revert language authoring if needed while retaining safe evaluator limits. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. #### PDSL-110 — Ship a rule-language upgrade with a reversible authoring boundary **Task · High priority · Expert** noCV practice brief v5 · PDSL-110 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-105, PDSL-108, PDSL-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · System design 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. Pattern topics: Interpreter (apply) · Builder (refactor). Interpreter — Apply: Keep interpreter semantics tied to stored language versions so deploying or reverting authoring code cannot silently change routing behavior. Builder — Refactor: Make version conversion an explicit construction step with a preview instead of rebuilding unknown nodes with guessed defaults. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The membership release introduces version 2 rules, but a rollback plan assumes every stored rule can still be opened by the version 1 editor. Saving an unrecognized node would silently discard a condition. Acceptance criteria - Route evaluation by saved language version and fail closed for unknown versions without rewriting the original rule bytes. - Keep unsupported rules read-only in an older editor and require an explicit conversion preview before creating a new version. - Demonstrate a rollback sequence that stops version 2 authoring while preserving version 2 evaluation or explicitly pausing those rules. Implementation constraints - Record conversion warnings and original version lineage; a builder must not invent defaults for unsupported expression nodes. Verification - Run a mixed-version synthetic corpus before upgrade, after upgrade, and through the documented rollback sequence. - Open a version 2 rule in the old editor and submit an unknown-version rule; verify neither path loses conditions or approves routing. Deliverables - Compatibility matrix, conversion preview, and rehearsed local rollback runbook Rollout and recovery: Stage evaluation support before new authoring, then enable one synthetic warehouse; retain versioned evaluators until all dependent rules are explicitly retired. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. 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. ## PMIGRATE — Replace an account service one tenant at a time A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic. **Field:** System design. **Suggested stack:** TypeScript, Node.js, PostgreSQL, Vitest. **Engineer value:** Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. **Company value:** Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. **Delivery agreement:** Ten tickets in three migration phases. An individual ticket needs a minimal local reproduction of its legacy behavior; the full project ends with a rehearsed synthetic tenant cutover and retirement checklist. ### Setup prerequisites - REST contracts - Tenant authorization - Transactions - Dependency injection ### Establish a stable boundary Capture old behavior and remove hidden tenant state before routing changes. #### PMIGRATE-101 — Put legacy account lookups behind a contract the replacement can keep **Task · High priority · Foundational** noCV practice brief v5 · PMIGRATE-101 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System design 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. Pattern topics: Facade (apply). Facade — Apply: Give callers one stable account-read contract while containing legacy row translation and keeping the boundary deliberately narrow. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Three HTTP handlers each translate a legacy account row differently. One returns an absent timezone as null, another inserts UTC, and a third exposes an internal migration flag. Acceptance criteria - Create a narrow account-read facade with explicit tenant and account identifiers and one documented public response shape. - Capture the intended null, not-found, and permission behavior before routing the three handlers through it. - Keep legacy storage columns and migration flags out of the public response while preserving required client fields. Implementation constraints - Use the facade to bound a specific compatibility surface; do not add a generic wrapper around every repository method. Verification - Exercise all three handlers against synthetic missing, configured, and null-timezone accounts and compare their response contracts. - Request another tenant's account and assert denial with no internal migration metadata in the response. Deliverables - Account-read facade and legacy response characterization cases Rollout and recovery: Move one local handler at a time through the facade and compare response snapshots; revert a handler without changing stored account data. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-102 — Remove the process-wide current-tenant account client **Bug · Urgent priority · Advanced** noCV practice brief v5 · PMIGRATE-102 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: PMIGRATE-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Backend 30% · System 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. Pattern topics: Singleton (remove). Singleton — Remove: Remove singleton-held tenant state while preserving safe shared connection infrastructure, using an interleaved request failure to justify the lifetime change. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The legacy account client is a singleton with a mutable currentTenant field. Two overlapping requests can overwrite that field between authorization and the database query, selecting the wrong tenant's settings. Acceptance criteria - Remove mutable request or tenant context from the process-wide client and pass authorized scope explicitly into the service/repository boundary. - Every account query constrains both tenant and account identity, including background lookups and the not-found path. - Connection pooling may remain shared, but tests and request handlers cannot alter another operation's tenant context. Implementation constraints - Distinguish safe shared infrastructure lifetime from unsafe shared request state; replacing the singleton with a different global container is insufficient. Verification - Interleave two tenant requests with barriers at authorization and lookup; assert each receives only its own settings. - Omit tenant scope and use a cross-tenant account identifier in direct service calls; verify rejection before data is returned. Deliverables - Explicit-scope account access change and deterministic overlap reproduction Rollout and recovery: Block further migration until the scope checks pass; revert optional routing changes if needed while retaining the tenant-isolation fix. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-103 — Separate account policy from legacy SQL and replacement storage **Story · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-103 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: PMIGRATE-102. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 30% · Database 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. Pattern topics: Ports and Adapters (refactor). Ports and Adapters — Refactor: Move account policy above concrete storage and give both adapters the same explicit authorization, revision, and transaction obligations. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The rule that a suspended account cannot enable a new booking channel lives inside a legacy SQL helper. The replacement adapter would bypass that rule if handlers called it directly. Acceptance criteria - Place the account policy in an application operation depending on explicit read/write ports instead of concrete database helpers. - Run the same operation against old and new storage adapters with identical authorization and suspended-account behavior. - Keep transaction and expected-revision requirements explicit in the port contract; adapters cannot report success after a failed commit. Implementation constraints - Introduce ports for the needed use case only; do not create a universal repository abstraction or change the application into microservices. Verification - Run a shared contract suite for both adapters over active, suspended, and missing accounts. - Inject a stale revision and commit failure in each adapter and verify no enabled channel or success response is produced. Deliverables - Account operation, two local adapters, and shared behavior contract Rollout and recovery: Keep the legacy adapter selected while introducing the boundary; enable the replacement only after parity cases pass. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. ### Compare and route deliberately Introduce the replacement without duplicate effects or unexamined abstractions. #### PMIGRATE-104 — Shadow account reads without duplicating booking-channel writes **Task · High priority · Advanced** noCV practice brief v5 · PMIGRATE-104 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. Pattern topics: Strangler Fig (apply). Strangler Fig — Apply: Replace a bounded read surface gradually while keeping command ownership singular and making shadow failures independent of served responses. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The migration proposal mirrors every request to the replacement and compares responses. Some apparent reads update lastSeenAt, and write mirroring would enable a booking channel twice through different storage paths. Acceptance criteria - Define an allowlist of side-effect-free reads that may run against both implementations for synthetic tenant comparison. - Return the active implementation's response without letting shadow timeouts or failures change client behavior. - Record bounded field-level parity differences without account content, and route every command to exactly one active implementation. Implementation constraints - Use the migration boundary to incrementally replace routes; do not call a mutating operation just because its HTTP verb is GET. Verification - Inject a replacement timeout and mismatched timezone; verify the active result remains correct and a bounded mismatch is recorded. - Run an enable-channel command and a last-seen update; assert one write owner and zero shadow side effects. Deliverables - Safe shadow-read routing, mismatch report, and side-effect inventory Rollout and recovery: Enable shadow reads for one synthetic tenant with an independent off switch; disable comparison without changing command ownership. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-105 — Preserve tenant scope and conditional reads through the migration proxy **Bug · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-105 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 40% · System 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. Pattern topics: Proxy (refactor). Proxy — Refactor: Keep access control and delegation transparent to the account contract while ensuring proxy forwarding cannot weaken tenant or cache semantics. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A local migration proxy forwards the account identifier but drops the authorized tenant context and If-None-Match value. The new path both loses cache semantics and trusts a tenant header supplied by the caller. Acceptance criteria - Forward server-derived tenant scope and conditional-read metadata through a typed proxy boundary without trusting caller-supplied scope. - Preserve documented ETag, not-modified, not-found, and error behavior for both active implementations. - Reject missing authorized scope before forwarding and keep proxy diagnostics free of credentials and full account bodies. Implementation constraints - The proxy controls access and delegation; keep storage mapping in adapters rather than accumulating business rules in the proxy. Verification - Send matching and stale ETags through old and new routes and compare their public conditional responses. - Spoof a tenant header, omit authorized context, and force an adapter error; assert denial and sanitized error output. Deliverables - Proxy context contract and conditional-read/tenant regression cases Rollout and recovery: Exercise the proxy with local synthetic clients before enabling tenant routing; route back through the corrected legacy boundary on failure. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-106 — Decide whether a separate account summary read model earns its lag **Task · Medium priority · Expert** noCV practice brief v5 · PMIGRATE-106 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-103, PMIGRATE-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Database engineering 30% · 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. Pattern topics: CQRS (compare). CQRS — Compare: Compare command/query separation with an indexed query using freshness, rebuild, and write-cost requirements rather than assuming a projection is necessary. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The account summary joins five tables and is the slowest synthetic endpoint. A CQRS proposal introduces a projection, but support must see a just-disabled booking channel immediately after issuing the command. Acceptance criteria - Compare an indexed transactional query with a separate projection using a declared synthetic dataset and equivalent authorization boundaries. - For the projection option, expose freshness/version semantics and define a read-after-write path that cannot show a disabled channel as enabled after an acknowledged command. - Document latency, write cost, rebuild behavior, and operational complexity; implement the selected option and justify rejecting the other. Implementation constraints - CQRS does not require separate services or event sourcing here; evaluate command/query separation within the existing local application. Verification - Measure both options with identical account counts and query mix, reporting warmup and repeated-run variability. - Pause projection updates, issue a disable command, and exercise the declared freshness strategy; test an interrupted rebuild without cross-tenant reads. Deliverables - Read-model comparison, selected implementation, and freshness/rebuild contract Rollout and recovery: Canary the selected read path for one synthetic tenant; retain the transactional path until freshness and rebuild failure checks pass. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-107 — Delete account facade layers that only rename the same call **Chore · Low priority · Foundational** noCV practice brief v5 · PMIGRATE-107 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-101, PMIGRATE-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Backend 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. Pattern topics: Facade (remove). Facade — Remove: Remove redundant facade layers with no compatibility or policy responsibility while retaining the one boundary that protects callers from the legacy model. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A timezone field now crosses AccountFacade, AccountGatewayFacade, AccountServiceFacade, and AccountAccessFacade. Three wrappers have one consumer, add no behavior, and make a one-field change touch twelve files. Acceptance criteria - Trace the timezone read and identify which boundary owns compatibility, policy, authorization, and persistence responsibilities. - Remove pass-through facades that add no independent responsibility while retaining the public compatibility boundary and storage port. - The timezone response, authorization behavior, and adapter substitution remain unchanged with fewer forwarding sites to maintain. Implementation constraints - Do not replace deleted facades with a dynamic service locator or merge authorization checks into controllers only. Verification - Run the same response and adapter-substitution cases before and after the simplification. - Exercise cross-tenant denial and a storage failure through the simplified path; verify neither is swallowed by forwarding code. Deliverables - Focused simplification patch and a before/after responsibility map Rollout and recovery: Land the forwarding cleanup separately from routing changes so a regression can be traced and reverted without changing migration state. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. ### Cut over and retire Prove write ownership, compatibility, and recovery before removing legacy paths. #### PMIGRATE-108 — Transfer tenant write ownership without accepting commands on both sides **Story · High priority · Expert** noCV practice brief v5 · PMIGRATE-108 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-105, PMIGRATE-106. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · Database 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. Pattern topics: Strangler Fig (apply). Strangler Fig — Apply: Make incremental replacement include durable write ownership and a data-aware rollback boundary, rather than treating tenant routing as a cosmetic flag. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Two local application instances cache the tenant migration flag at different times. During cutover, one writes the legacy table while another writes the replacement, leaving two conflicting account revisions. Acceptance criteria - Represent write ownership with a durable tenant migration revision and reject commands using a stale ownership revision at the write boundary. - Backfill replacement data and reconcile it through the final legacy revision under the ownership fence; do not open the new writer while any committed legacy change remains unapplied. - Define a cutover sequence that drains or rejects in-flight old-owner commands before the new owner accepts writes. - Document and rehearse how rollback handles writes already accepted by the new owner; switching a read flag alone cannot declare rollback complete. Implementation constraints - Keep the exercise in one local database and explicit transactions; do not claim cross-database atomicity or solve stale ownership with cache TTL alone. Verification - Copy tenant data, commit a later legacy write, then interleave commands from two instances around cutover; assert the new owner includes that write and a single accepted ownership lineage loses no successful writes. - Crash after ownership transfer and attempt rollback after a new-side write; verify the recovery procedure detects and reconciles that write before reopening old ownership. Deliverables - Tenant cutover command, stale-owner rejection checks, and write-aware rollback drill Rollout and recovery: Rehearse with one synthetic tenant and a paused writer; expand only after cutover and rollback counts reconcile. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-109 — Catch replacement-adapter drift before declaring tenant parity **Task · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-109 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-103, PMIGRATE-105, PMIGRATE-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · System design 30% · Database 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. Pattern topics: Ports and Adapters (apply). Ports and Adapters — Apply: Use the shared port as a behavioral contract for interchangeable adapters, testing semantic parity without binding the contract to either storage implementation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Both adapters pass the happy-path tests, but the replacement sorts equal-name accounts differently and rounds stored revision values when decoding a database result. Parity dashboards currently compare only HTTP status codes. Acceptance criteria - Extend the shared port contract to stable sort tie-breakers, null handling, exact revisions, and documented domain error mapping. - Run a fixed synthetic corpus against each adapter and compare normalized semantic results rather than timestamps or implementation-only columns. - A mismatch report identifies the contract case and differing public fields without dumping tenant data or silently accepting expected failures. Implementation constraints - Keep adapter-specific SQL assertions separate from the shared behavior contract so the suite does not require identical internal implementations. Verification - Use equal-name accounts, null settings, and large valid revision values to verify exact contract parity. - Inject a deliberate order reversal and stale-revision acceptance into one local adapter; confirm the comparison fails with an actionable case identifier. Deliverables - Expanded adapter contract suite and sanitized parity report Rollout and recovery: Require a clean contract report before moving the next synthetic tenant; keep mismatched tenants on their current owner until the discrepancy is resolved. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-110 — Retire the legacy account path only after the last caller is accounted for **Chore · Medium priority · Advanced** noCV practice brief v5 · PMIGRATE-110 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-108, PMIGRATE-109. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Site reliability 30% · Database 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. Pattern topics: Strangler Fig (apply) · Proxy (remove). Strangler Fig — Apply: Complete the replacement by accounting for background callers and rollback data, with explicit criteria for retiring the old implementation. Proxy — Remove: Remove migration-only routing branches after the transition ends so temporary delegation machinery does not become a permanent maintenance layer. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. All interactive tenants use the replacement, but a weekly synthetic export still imports the legacy repository directly. Deleting the old table based on request traffic would break that job and erase the only rollback copy. Acceptance criteria - Inventory HTTP, scheduled, and direct module callers and migrate remaining accesses through the supported contract. - Define observable retirement criteria including zero old-owner tenants, a complete job cycle, reconciled data, and an explicit rollback-retention decision. - Separate code-path removal from any destructive schema change and provide a rehearsed restore path for the retained synthetic snapshot. Implementation constraints - Remove obsolete migration facades and proxy branches once their responsibilities end; keep the public account contract independent of temporary migration machinery. Verification - Run the weekly export and interactive contract suite with legacy routing disabled; assert no code path queries the retired repository. - Leave one synthetic old-owner tenant or omit a scheduled caller and confirm retirement validation blocks removal; rehearse restoring the retained data snapshot. Deliverables - Caller inventory, retirement checks, cleanup patch, and synthetic restore report Rollout and recovery: Disable legacy routing, observe one full synthetic job cycle, then remove unused code; schedule schema deletion separately after the retention decision. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. ## PRECOVER — Recover interrupted returns without refunding twice A fictional equipment retailer lets customers choose a refund or replacement after inspection. Its payment and stock providers can time out after accepting an operation, so retrying the whole return is unsafe. Create a local TypeScript application, PostgreSQL state/outbox tables, and synthetic provider doubles with controllable outcomes; no starter code or fixtures are supplied. Use invented orders and integer minor-unit amounts only, with no real payments or external provider calls. **Field:** Distributed systems. **Suggested stack:** TypeScript, Node.js, PostgreSQL, Vitest. **Engineer value:** Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. **Company value:** Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. **Delivery agreement:** Ten tickets over command intake, provider recovery, and operational rehearsal. Build controllable synthetic dependencies for an individual issue or deliver the complete local returns workflow with failure drills. ### Setup prerequisites - SQL transactions - Idempotent commands - Async failure handling - State modeling ### Accept one durable intent Make return decisions, commands, and pending work consistent before calling providers. #### PRECOVER-101 — Reject return decisions that skip inspection or reverse a completed refund **Bug · High priority · Foundational** noCV practice brief v5 · PRECOVER-101 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept one durable intent. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · System design 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. Pattern topics: State (compare). State — Compare: Compare guarded state objects with an explicit transition table for preventing illegal return actions without requiring a class for every status. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The return endpoint accepts a caller-supplied status string. A replacement can be requested before inspection, and a stale browser tab can move a refunded return back to awaiting-inspection. Acceptance criteria - Define explicit commands and permitted transitions for awaiting inspection, approved, rejected, processing, completed, and needs-review states. - Require an expected revision and authorized merchant scope for each decision; terminal outcomes cannot be overwritten by a stale command. - Return stable invalid-transition and revision-conflict errors while preserving an append-only transition history. Implementation constraints - Compare a transition table with state objects; choose the representation that makes allowed transitions and guards easiest to inspect. Verification - Exercise the approved-refund and rejected-inspection paths and compare their recorded transition order. - Attempt a pre-inspection replacement, a post-refund reversal, and a cross-merchant decision; verify no state or history mutation. Deliverables - Return transition contract and invalid-transition regression cases Rollout and recovery: Route local return decisions through the explicit transition API before adding provider effects; retain transition history when reverting the UI. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-102 — Bind a repeated refund request to its original merchant and intent **Bug · High priority · Intermediate** noCV practice brief v5 · PRECOVER-102 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept one durable intent. Depends on: PRECOVER-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Backend 30% · Database 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. Pattern topics: Command (apply). Command — Apply: Capture refund intent as an immutable durable command so retries refer to the same operation and cannot quietly change its merchant, amount, or target. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The browser retries an approved 4,500-minor-unit refund after a lost response. The current deduplication key is global, and changing the amount while reusing the key overwrites the queued request. Acceptance criteria - Persist an immutable refund command with merchant, return, amount, currency, and a canonical intent hash scoped to its request key. - Identical retries return the existing command identity and current status; changed intent under the same scoped key returns a conflict. - Concurrent identical requests create one accepted command, and command history never rewrites the original amount or target return. Implementation constraints - Represent the operation as a durable command rather than relying on an in-memory callback or HTTP response cache; amounts use integer minor units. Verification - Submit the same intent concurrently and retry after a simulated lost response; compare one command identity and one accepted history entry. - Reuse the key with a new amount and from another merchant; assert conflict for changed scoped intent and independent authorized identities across merchants. Deliverables - Durable refund command contract and scoped idempotency reproduction Rollout and recovery: Enable durable command intake before dispatching synthetic refunds; disable new intake without deleting accepted command identities. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-103 — Commit approved return work and its dispatch record together **Bug · High priority · Advanced** noCV practice brief v5 · PRECOVER-103 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept one durable intent. Depends on: PRECOVER-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database 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. Pattern topics: Transactional Outbox (apply). Transactional Outbox — Apply: Bind state and dispatch intent to one commit while accepting repeat delivery and preserving deterministic identities for downstream deduplication. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The application marks a return processing, then publishes a refund job. If it crashes between those steps, the return is stuck forever; publishing first can instead process a refund for a rolled-back decision. Acceptance criteria - Commit the accepted command, return transition, and outbox record in one database transaction with a deterministic dispatch identity. - A bounded dispatcher claims due records safely across two instances and retries using the same operation identity. - Treat dispatch as at-least-once: acknowledgment loss can redeliver, but downstream handling deduplicates the effect and pending records remain observable. Implementation constraints - Do not hold the database transaction open during a provider call; use explicit lease expiry and attempt limits for dispatch recovery. Verification - Crash before and after commit and compare return, command, and outbox records for atomic presence or absence. - Lose a dispatch acknowledgment and run two dispatchers through lease expiry; assert one logical refund intent despite repeat delivery. Deliverables - Transactional outbox write path, dispatcher, and crash-boundary checks Rollout and recovery: Start with dispatch paused and reconcile synthetic pending counts; enable one dispatcher before rehearsing a second instance and restart. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. ### Handle partial and uncertain outcomes Coordinate effects and compensation while containing independent provider failures. #### PRECOVER-104 — Persist replacement progress across stock reservation and shipment creation **Story · High priority · Advanced** noCV practice brief v5 · PRECOVER-104 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial and uncertain outcomes. Depends on: PRECOVER-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 20% · 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. Pattern topics: Saga (apply) · State (apply). Saga — Apply: Coordinate durable replacement steps and fallible compensation so a partial provider success can be resumed or reconciled without repeating earlier effects. State — Apply: Represent uncertain provider outcomes separately from confirmed failures so workflow transitions cannot invent a successful rollback or completed refund. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A replacement reserves the last unit, then shipment creation fails. Retrying from the beginning makes another reservation, while immediately issuing a refund would ignore stock still held for the customer. Acceptance criteria - Persist separate reservation and shipment steps with stable provider operation keys and explicit pending, confirmed, failed, and uncertain outcomes. - Resume from recorded progress after restart; a confirmed reservation is reused instead of repeated when shipment creation is retried. - On a confirmed shipment failure, schedule release of the reservation before offering the declared refund fallback; uncertain effects remain unresolved until checked. Implementation constraints - Use a durable orchestrated workflow in the local application; compensation is another fallible operation, not a database rollback of an external effect. Verification - Reserve stock, crash before shipment confirmation, and resume; assert one reservation lineage and the correct next step. - Return a confirmed shipment rejection and then a reservation-release timeout; verify the workflow remains visible and does not silently refund or reserve again. Deliverables - Replacement step model and reservation/shipment recovery cases Rollout and recovery: Enable the replacement path for one synthetic order type; pause new workflows while allowing existing recorded steps to reconcile on rollback. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-105 — Open the refund circuit without declaring timed-out refunds failed **Bug · High priority · Advanced** noCV practice brief v5 · PRECOVER-105 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial and uncertain outcomes. Depends on: PRECOVER-103, PRECOVER-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Site reliability 30% · Integrations 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. Pattern topics: Circuit Breaker (apply). Circuit Breaker — Apply: Bound attempts during provider failure while keeping circuit health separate from each refund's durable and potentially uncertain business outcome. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The synthetic refund provider begins timing out. The proposed circuit breaker maps every timeout to failed and releases queued retries when it closes, even though some timed-out refunds were accepted by the provider. Acceptance criteria - Define closed, open, and half-open behavior with a controllable clock, a bounded failure window, and a limited number of half-open probes. - Opening the circuit defers new provider attempts without converting existing uncertain refund outcomes into confirmed failures. - Reconcile ambiguous operation identities through the provider's status lookup before resubmission; a reopened circuit preserves pending work and retry timing. Implementation constraints - Use provider idempotency and status lookup contracts in addition to the breaker; a circuit breaker alone cannot prevent duplicate money movement. Verification - Advance a fake clock through the failure threshold, open window, and half-open success/failure paths and assert bounded probe calls. - Simulate provider acceptance followed by timeout, then close the circuit; verify reconciliation finds the original refund and no second refund is created. Deliverables - Refund circuit policy, uncertain-outcome reconciliation, and clock-driven cases Rollout and recovery: Observe the synthetic failure window before enabling deferral; disabling the breaker must not bypass uncertain-outcome reconciliation. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-106 — Keep stalled stock calls from consuming every refund execution slot **Bug · High priority · Intermediate** noCV practice brief v5 · PRECOVER-106 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial and uncertain outcomes. Depends on: PRECOVER-104, PRECOVER-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Distributed systems 40% · 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. Pattern topics: Bulkhead (apply). Bulkhead — Apply: Separate provider execution capacity so a stalled stock dependency cannot consume refund slots, with bounded queues and explicit permit cleanup. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Stock reservations and refunds share a 12-slot provider pool. Twelve hanging stock requests prevent an otherwise healthy refund provider from receiving work, and the pending promise list grows without a limit. Acceptance criteria - Give stock and refund operations independent concurrency limits and bounded waiting queues with explicit admission outcomes. - Timeout, cancellation, and provider rejection each release a slot exactly once while preserving durable work for the declared retry policy. - When stock capacity is saturated, refund work continues within its configured limit and neither queue exceeds its cap. Implementation constraints - Document what is isolated by the pools and what remains shared, including database capacity; do not claim full fault isolation from separate counters alone. Verification - Hold all stock operations behind a barrier and complete a refund batch without exceeding either provider's concurrency limit. - Cancel queued work, time out running calls, and overfill both queues; assert no leaked permits or unbounded pending promises. Deliverables - Provider capacity limits, admission contract, and saturation reproduction Rollout and recovery: Start with conservative synthetic pool limits and expose queue depth/rejection counts; pause intake before lowering limits below active work. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-107 — Stop compensation retries when a replacement has already shipped **Bug · High priority · Expert** noCV practice brief v5 · PRECOVER-107 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial and uncertain outcomes. Depends on: PRECOVER-104, PRECOVER-105, PRECOVER-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System design 20% · 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. Pattern topics: Saga (refactor). Saga — Refactor: Make compensation conditional on current durable and provider-confirmed facts, including irreversible progress and a visible unresolved state. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A shipment-create response was lost, so the return entered compensation. A later status lookup confirms the replacement shipped; the queued compensation still plans to release stock and refund the customer. Acceptance criteria - Revalidate confirmed external progress and the workflow revision before each compensation step; a stale plan cannot execute against newer shipment state. - Represent irreversible shipment completion and conflicting provider facts explicitly, moving unresolved cases to needs-review with a bounded reason trail. - An authorized resolution records its cited synthetic provider references and chosen next action without deleting earlier uncertainty or issuing an unapproved second benefit. Implementation constraints - Compensation must follow the declared return policy and current confirmed facts; never model an external shipment as a reversible local transaction. Verification - Queue compensation, then reveal a confirmed shipment before its next step; assert the stale compensation is stopped and no refund is issued. - Race two resolution attempts and return contradictory provider status responses; verify one revision wins and unresolved contradictions remain visible. Deliverables - Compensation guards, conflict-resolution contract, and late-confirmation race cases Rollout and recovery: Enable automatic compensation only for confirmed reversible states; keep conflict resolution explicit and retain a pause control for all pending compensation. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. ### Rehearse bounded recovery Make operator replay, restart behavior, and overload limits inspectable. #### PRECOVER-108 — Preview the exact return command before an operator requests replay **Story · Medium priority · Foundational** noCV practice brief v5 · PRECOVER-108 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse bounded recovery. Depends on: PRECOVER-102, PRECOVER-107. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Backend 40% · 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. Pattern topics: Command (apply). Command — Apply: Expose durable command intent for safe preview and explicit replay while keeping the original operation immutable and rechecking eligibility at execution. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Support can currently click Retry beside a return without seeing whether it will check a refund status, retry a reservation, or attempt compensation. The button also lets a stale page replay a command that already completed. Acceptance criteria - Show the immutable command identity, target return, intended next operation, current revision, and the reason replay is eligible or blocked. - A preview is read-only; replay requires an explicit authorized command with expected revision and a fresh eligibility check. - Reusing the replay request key returns the existing replay result, while completed or unresolved-ineligible operations cannot be forced through this path. Implementation constraints - Show only synthetic operational identifiers and bounded explanations; replay cannot edit the original refund amount or target operation. Verification - Preview one eligible status-check command and one completed command; confirm the preview performs no provider calls or writes. - Complete a command after preview, then request replay with its stale revision; also try an unauthorized merchant and assert rejection. Deliverables - Replay preview and command endpoint contracts with stale/denied cases Rollout and recovery: Expose preview before enabling the replay action; disable replay writes independently while keeping history and explanations available. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-109 — Rehearse returns recovery at every commit and provider acknowledgment boundary **Task · High priority · Expert** noCV practice brief v5 · PRECOVER-109 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse bounded recovery. Depends on: PRECOVER-103, PRECOVER-107, PRECOVER-108. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Quality engineering 40% · 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. Pattern topics: Transactional Outbox (apply) · Saga (apply). Transactional Outbox — Apply: Verify the outbox's durable intent and repeat-delivery behavior at actual restart boundaries instead of assuming publication and acknowledgment are atomic. Saga — Apply: Exercise workflow resumption and compensation after partial external effects, accepting explicit unresolved states when provider facts cannot be established. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The happy-path demo succeeds, but no one has restarted the application between a provider accepting an operation and the database recording its result. A green HTTP test does not establish whether accepted refunds survive recovery correctly. Acceptance criteria - Create a deterministic crash matrix covering command commit, outbox claim, provider acceptance, acknowledgment persistence, and compensation progress. - After each restart, reconcile durable commands, provider operations, and return state; no confirmed effect disappears and no logical refund is applied twice. - Distinguish eventual completion under a recovered provider from explicit unresolved state when the provider remains unavailable or contradictory. Implementation constraints - Use process restarts and durable local database state, not only thrown exceptions inside one transaction; reset synthetic provider state deliberately between cases. Verification - Run every crash point twice with the same seeded workload and compare final command/effect counts and unresolved reason codes. - Keep status lookup unavailable after an acceptance timeout and verify the drill stops at a visible unresolved state rather than manufacturing completion. Deliverables - Restart harness, crash-boundary matrix, and reconciled synthetic effect report Rollout and recovery: Run the full drill before enabling a new workflow version; pause new intake and drain or reconcile recorded work before reverting code. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. #### PRECOVER-110 — Tune recovery capacity without creating a retry surge when a provider returns **Task · Medium priority · Advanced** noCV practice brief v5 · PRECOVER-110 · Recover interrupted returns without refunding twice Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse bounded recovery. Depends on: PRECOVER-105, PRECOVER-106, PRECOVER-109. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Site reliability 40% · 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. Pattern topics: Bulkhead (refactor) · Circuit Breaker (refactor). Bulkhead — Refactor: Extend dependency capacity isolation with fair new/recovery admission and an explicit shared database budget so bounded pools do not hide another bottleneck. Circuit Breaker — Refactor: Coordinate half-open probes and reopening with durable retry scheduling so a healthy transition does not release the entire outage backlog at once. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A ten-minute synthetic outage leaves 2,000 deferred returns. When the circuit closes, every due retry enters the refund pool together, crowding out new work and exhausting the shared database connection budget. Acceptance criteria - Define bounded admission and fair scheduling between new and recovery work, with retry jitter generated from a reproducible test seed. - Coordinate half-open probes, provider pool limits, and the shared database budget so reopening cannot enqueue or execute the entire backlog at once. - Report backlog age, queue occupancy, rejection/defer counts, and completion time for the declared local load; justify selected limits and remaining shared bottlenecks. Implementation constraints - No universal throughput target is assumed; state machine resources, workload, and acceptable service objectives before comparing capacity settings. Verification - Recover a seeded 2,000-return backlog while submitting new work and verify bounded concurrency, queue sizes, and progress for both classes. - Make the provider fail again during recovery and cancel waiting work; assert permits are released, retries remain durable, and no tight retry loop forms. Deliverables - Recovery scheduling policy, reproducible saturation run, and capacity tradeoff report Rollout and recovery: Enable recovery scheduling with conservative limits and a pause control; reduce admission before shrinking active pools and preserve pending command identities. Project prerequisites: SQL transactions Idempotent commands Async failure handling State modeling Engineer value: Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts. Company value: Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path. 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. ## SMEM — Repair a packet arena before it becomes shared infrastructure A fictional telemetry collector copies decoded packet fields into a small native arena. The prototype misaligns wide values and reuses memory while readers still hold views. Create a local Rust crate or C library with generated byte fixtures; no device traffic or production allocator replacement is supplied. **Field:** Systems programming. **Suggested stack:** Rust or C, Property tests, AddressSanitizer or Miri. **Engineer value:** Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. **Company value:** Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - Pointers and slices - Integer overflow - Memory alignment ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SMEM-101 — Specify aligned arena offsets without relying on host luck **Task · Medium priority · Foundational** noCV practice brief v5 · SMEM-101 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 80% · Embedded and edge 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. Eight-byte fields happen to work on one machine because the backing buffer begins aligned; a sliced buffer starts at an odd address. Acceptance criteria - Round every allocation to its declared power-of-two alignment - Reject zero and unsupported alignments - Report requested size and remaining capacity without exposing addresses Implementation constraints - Use checked integer arithmetic before changing the cursor. Verification - Allocate mixed one-, four-, and eight-byte records and verify every offset. - Start near the numeric limit and confirm overflow leaves the cursor unchanged. Deliverables - Arena layout contract and boundary tests Rollout and recovery: Keep the current copy path until the layout suite passes on two target architectures. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-102 — Return exhaustion without handing out a partial slice **Bug · Medium priority · Foundational** noCV practice brief v5 · SMEM-102 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A capacity miss advances the arena cursor before returning an error, so the following small allocation also fails. Acceptance criteria - An exhausted allocation returns a typed capacity error - Cursor and prior bytes remain unchanged after failure - A later fitting allocation can still succeed Implementation constraints - Do not grow the backing region or panic on caller-controlled sizes. Verification - Fill the arena exactly and inspect the final valid allocation. - Request one byte too many, then allocate a smaller record and verify state. Deliverables - Atomic allocation update and exhaustion regression Rollout and recovery: Treat exhaustion as backpressure in the local collector; never retry without changing capacity or workload. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-103 — Invalidate borrowed packet views when the arena resets **Story · Medium priority · Intermediate** noCV practice brief v5 · SMEM-103 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SMEM-101, SMEM-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Security 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 decoder stores a view into the arena across reset and later reads bytes belonging to a different packet. Acceptance criteria - Views carry the generation in which they were created - Reset advances generation before storage is reused - Stale view access fails deterministically in the safe API Implementation constraints - Keep unsafe reads inside one reviewed boundary; do not claim runtime checks prove arbitrary raw pointers safe. Verification - Read several current-generation views before reset. - Reset, reuse the same offset, and reject the older view. Deliverables - Generation-bound view API and stale-view reproduction Rollout and recovery: Migrate the decoder through the checked view API before enabling reset reuse. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SMEM-104 — Free large spill blocks without double-releasing arena pages **Chore · Medium priority · Intermediate** noCV practice brief v5 · SMEM-104 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Oversized records spill to separate blocks. Error cleanup releases a spill block, then arena teardown releases the same block again. Acceptance criteria - Each spill block has one recorded owner - Cleanup is safe when invoked repeatedly - Arena teardown releases only blocks still attached Implementation constraints - Model ownership explicitly; a boolean freed flag cannot authorize access after release. Verification - Allocate and release several spill blocks in different orders. - Inject a decode error after spill allocation and run teardown twice under a memory checker. Deliverables - Spill ownership model and double-free regression Rollout and recovery: Disable spill allocation if the checker reports any invalid release. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-105 — Coalesce adjacent free spans without corrupting the index **Task · High priority · Advanced** noCV practice brief v5 · SMEM-105 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-101, SMEM-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 75% · Quality engineering 25%. 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 free-span list merges with the previous range but forgets the next range, leaving overlapping entries that can be allocated twice. Acceptance criteria - Free spans remain ordered, nonoverlapping, and maximal - Freeing in any order yields the same canonical span set - Double-free and out-of-range spans are rejected Implementation constraints - Update the span index under one mutation boundary and preserve the arena on validation failure. Verification - Free three adjacent blocks in all six orders and compare the final index. - Attempt an overlapping release and prove no index entry changes. Deliverables - Canonical coalescing algorithm and permutation tests Rollout and recovery: Run shadow invariant checks in the local benchmark before using reclaimed spans. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-106 — Bound fragmentation before adding a more complex allocator **Bug · High priority · Advanced** noCV practice brief v5 · SMEM-106 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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 team proposes size classes after one trace shows poor reuse, but the trace mixes long-lived metadata with short-lived packet records. Acceptance criteria - Measure internal and external fragmentation separately - Replay at least three declared lifetime distributions - Compare reset-only, free-list, and size-class approaches with correctness held constant Implementation constraints - Do not select an allocator from mean throughput alone; retain raw workload seeds and peak memory. Verification - Reproduce each workload and its fragmentation measurements. - Change the seed and show the report identifies noncomparable runs. Deliverables - Allocator comparison with workload manifest Rollout and recovery: Adopt additional complexity only if the declared workload crosses an agreed bound. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-107 — Contain unsafe decoding behind a length-checked cursor **Story · High priority · Expert** noCV practice brief v5 · SMEM-107 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-103. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Security 35%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Several parsers perform pointer arithmetic independently; one reads a declared payload length before confirming those bytes remain. Acceptance criteria - One cursor owns offset advancement and remaining-length checks - Primitive reads define endianness and alignment behavior - A failed read returns no partially initialized value Implementation constraints - Fuzz only the local parser process and cap input length, nesting, and execution time. Verification - Decode a complete packet containing every primitive type. - Truncate at every byte boundary and run the corpus under sanitizer or Miri. Deliverables - Checked decode cursor, fuzz corpus, and unsafe-boundary note Rollout and recovery: Route one packet family at a time through the cursor and retain the prior decoder for comparison. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SMEM-108 — Expose arena pressure without logging packet contents **Chore · High priority · Advanced** noCV practice brief v5 · SMEM-108 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-102, SMEM-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Operators can see allocation failures only in verbose decoder logs that include synthetic payload bytes and unbounded record labels. Acceptance criteria - Publish bounded counters for allocations, spills, resets, and exhaustion - Record capacity and high-water mark without payload content - Reject unbounded caller-provided metric dimensions Implementation constraints - Metrics are diagnostic observations for this component, not proof of production capacity. Verification - Drive allocations and reconcile counters with the deterministic workload. - Supply a unique record label per request and confirm it cannot become a dimension. Deliverables - Bounded arena telemetry and reconciliation test Rollout and recovery: Enable metrics before changing allocation policy; remove verbose payload logging. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-109 — Recover a persisted arena snapshot only when its layout matches **Task · High priority · Expert** noCV practice brief v5 · SMEM-109 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-105, SMEM-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Storage systems 35%. 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 warm-start experiment maps a snapshot written by an older layout and interprets its free-list metadata as current records. Acceptance criteria - Snapshot header binds format version, byte order, size, and checksum - Recovery validates every offset before exposing records - Unknown versions fail closed without modifying the snapshot Implementation constraints - Use generated snapshots only; memory mapping does not make untrusted offsets safe. Verification - Write and restore a current snapshot with identical logical records. - Corrupt each header field and one nested offset, then confirm rejection. Deliverables - Versioned snapshot reader and corruption matrix Rollout and recovery: Keep cold reconstruction as the default until compatible recovery is repeatable. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-110 — Hand off the arena with explicit reasons not to use it **Bug · Medium priority · Intermediate** noCV practice brief v5 · SMEM-110 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-106, SMEM-108, SMEM-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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 second team wants the arena for long-lived session objects even though reset semantics and spill behavior were designed for packet batches. Acceptance criteria - Document supported lifetimes, alignment, capacity, thread-safety, and reset rules - List measured bounds and unresolved risks with reproduction commands - Include rejection examples for workloads better served by standard allocation Implementation constraints - Do not present local benchmark results as universal performance claims. Verification - Have a reviewer reproduce one supported workload from a clean checkout. - Apply the documented long-lived workload and confirm the guide recommends against adoption. Deliverables - Usage contract, decision record, and reproducible handoff Rollout and recovery: Require a separate review before any new workload adopts the component. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. ## SCONCUR — Make a native work queue survive real thread interleavings A fictional image-indexing utility runs CPU-only synthetic jobs through a Rust worker pool. Its prototype loses wakeups, blocks shutdown, and treats cancellation as completion. Build a local library and deterministic concurrency harness; image content, GPU work, and production deployment are excluded. **Field:** Systems programming. **Suggested stack:** Rust, Threads, Loom or deterministic scheduler, Criterion. **Engineer value:** Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. **Company value:** Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - Mutexes and condition variables - Atomics - Thread lifecycle ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SCONCUR-101 — Define queue ownership before starting worker threads **Task · Medium priority · Foundational** noCV practice brief v5 · SCONCUR-101 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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. Workers borrow configuration from a stack-owned builder that disappears after start, while the queue handle can outlive the pool. Acceptance criteria - Pool-owned state outlives every worker - Queue handles cannot submit after terminal shutdown - Dropping the final handle has documented behavior Implementation constraints - Avoid leaked static references and process-wide mutable state. Verification - Create, submit, join, and drop a pool repeatedly under a leak checker. - Drop external handles in different orders and verify workers cannot access released state. Deliverables - Ownership diagram and lifecycle tests Rollout and recovery: Keep the single-thread runner until lifecycle checks pass. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-102 — Reject work when the bounded queue is full **Bug · Medium priority · Foundational** noCV practice brief v5 · SCONCUR-102 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Producers append without limit while workers are paused, and the process consumes all available memory. Acceptance criteria - Capacity is explicit and positive - Submission returns accepted, timed out, or closed - A rejected job remains caller-owned Implementation constraints - Do not hide backpressure behind an unbounded overflow list. Verification - Fill the queue, release one slot, and submit the next job. - Keep workers paused and confirm memory and queue length remain bounded. Deliverables - Bounded submission API and overload tests Rollout and recovery: Start with conservative capacity and surface rejections to the local caller. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-103 — Close the lost-wakeup gap between predicate and sleep **Story · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-103 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SCONCUR-101, SCONCUR-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Quality engineering 35%. 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 producer signals just before a worker begins waiting; queued work then sleeps until another submission arrives. Acceptance criteria - Workers test the queue predicate under the same synchronization boundary as waiting - Spurious wakeups preserve correctness - One job is claimed by one worker Implementation constraints - Document the predicate, mutex, and notification order in code comments beside the wait loop. Verification - Exercise enqueue before, during, and after worker wait. - Force the historical interleaving and prove the queued job completes without a second signal. Deliverables - Correct wait loop and deterministic lost-wakeup test Rollout and recovery: Run the old and new pools against the same scheduler trace before switching. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SCONCUR-104 — Keep cancellation distinct from successful completion **Chore · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-104 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time 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. A cancelled indexing job resolves the same completion channel as a finished job, so callers publish an empty index. Acceptance criteria - Result distinguishes success, cancellation, job failure, and pool shutdown - Cancellation before claim prevents execution - Cancellation after claim is cooperative and observable Implementation constraints - Do not terminate worker threads asynchronously while they own locks or memory. Verification - Cancel queued and running cooperative jobs and inspect distinct outcomes. - Use a job that ignores cancellation and verify shutdown reports the unresolved work. Deliverables - Cancellation state model and race tests Rollout and recovery: Callers must handle cancellation explicitly before adopting the new result type. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-105 — Prevent priority work from starving maintenance forever **Task · High priority · Advanced** noCV practice brief v5 · SCONCUR-105 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-102, SCONCUR-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A continuous stream of interactive jobs keeps cache-maintenance tasks queued indefinitely. Acceptance criteria - Scheduling policy defines a bounded wait for every admitted class - Interactive latency remains measured under mixed load - Class selection is deterministic for a declared seed Implementation constraints - Do not claim fairness from average completion time; report per-class tail wait. Verification - Replay a mixed workload and verify the declared service ratio. - Saturate the interactive class and confirm maintenance still advances. Deliverables - Fair scheduler policy, simulator, and latency report Rollout and recovery: Canary the policy in the synthetic workload and retain FIFO fallback. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-106 — Remove a lock-order inversion in completion reporting **Bug · High priority · Advanced** noCV practice brief v5 · SCONCUR-106 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-103, SCONCUR-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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 worker holds the queue lock while acquiring a result lock; the joining thread holds the result lock while closing the queue. Acceptance criteria - Declare a single lock order or remove nested acquisition - Completion remains visible before join returns - Shutdown cannot wait while holding a lock needed by workers Implementation constraints - Keep callbacks outside internal locks because caller code is untrusted by the synchronization design. Verification - Complete and join jobs from several workers under the deterministic scheduler. - Force the prior opposing acquisition order and verify progress. Deliverables - Lock graph, refactor, and deadlock regression Rollout and recovery: Enable lock-wait diagnostics during the local transition. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-107 — Prove the atomic queue fast path has a safe memory order **Story · High priority · Expert** noCV practice brief v5 · SCONCUR-107 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SCONCUR-102, SCONCUR-103. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Performance engineering 35%. 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 lock-free experiment publishes a slot index before all job fields are visible, producing rare partially initialized reads on a weakly ordered target. Acceptance criteria - Every atomic operation has a stated synchronization role - Publication makes complete job data visible before claim - Wraparound cannot confuse a reused slot with an older generation Implementation constraints - Prefer the mutex implementation unless measured need and model checking justify the atomic path. Verification - Model-check bounded producers, consumers, and slot reuse. - Weaken the publication ordering in a mutation and ensure the model detects an invalid read. Deliverables - Memory-order argument, model, and comparison with mutex path Rollout and recovery: Keep the atomic implementation disabled unless correctness and workload benefit are both demonstrated. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SCONCUR-108 — Drain accepted jobs without hanging process shutdown **Chore · High priority · Advanced** noCV practice brief v5 · SCONCUR-108 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-104, SCONCUR-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Shutdown closes submissions but waits forever for a worker blocked on an external test double that never returns. Acceptance criteria - Shutdown defines stop-accepting, drain, cancel, and terminal states - A deadline reports unfinished job identities without detaching live threads - Repeated shutdown calls return the same terminal outcome Implementation constraints - Use controlled local jobs; do not kill threads or the host process to simulate recovery. Verification - Drain a pool whose jobs complete before the deadline. - Block one job past the deadline and confirm bounded return with an unresolved record. Deliverables - Shutdown protocol and stuck-job test Rollout and recovery: Callers keep the old process exit path until they handle unresolved shutdown results. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-109 — Capture a concurrency failure without megabytes of logs **Task · High priority · Expert** noCV practice brief v5 · SCONCUR-109 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-105, SCONCUR-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Site reliability 35%. 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 rare stall produces per-poll logs from every worker, changing timing and obscuring the last useful state transition. Acceptance criteria - Record a bounded ring of queue and worker transitions - Events use monotonic sequence and synthetic job identity - Snapshot identifies dropped diagnostic events Implementation constraints - Do not record job payloads, thread stack memory, or unbounded labels. Verification - Reconstruct a normal claim-to-completion path from the ring. - Overflow the ring during the forced deadlock trace and retain an explicit loss marker. Deliverables - Bounded trace recorder and stall diagnostic Rollout and recovery: Enable the recorder only for the local harness until overhead is measured. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. #### SCONCUR-110 — Publish the worker-pool contract and benchmark limits **Bug · Medium priority · Intermediate** noCV practice brief v5 · SCONCUR-110 · Make a native work queue survive real thread interleavings Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SCONCUR-105, SCONCUR-108, SCONCUR-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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 build tool and a request server both plan to reuse the pool despite different fairness, blocking, and shutdown requirements. Acceptance criteria - Document supported job behavior and prohibited blocking assumptions - Report throughput, queue wait, memory, and shutdown duration for declared workloads - List cases where a runtime-native executor is preferable Implementation constraints - Do not generalize results beyond the recorded machine and workload profiles. Verification - Reproduce one CPU-bound and one mixed-duration benchmark from a clean checkout. - Run the unsupported permanently blocking job and confirm the guide predicts the outcome. Deliverables - Contract, benchmark manifest, and adoption checklist Rollout and recovery: Require each adopter to select and verify a workload profile. Project prerequisites: Mutexes and condition variables Atomics Thread lifecycle Engineer value: Practice happens-before reasoning, ownership transfer, cancellation and liveness testing. Company value: Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads. 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. ## SIPC — Supervise local worker processes without losing their output A fictional document converter launches local sandbox substitutes as child processes. Its prototype parses newline-delimited output, leaks descriptors, and retries requests after ambiguous worker exits. Create a Rust supervisor and deterministic worker fixtures; no document content or production sandbox is supplied. **Field:** Systems programming. **Suggested stack:** Rust, Child processes, Unix sockets or named pipes, Vitest or cargo test. **Engineer value:** Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. **Company value:** Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - File descriptors - Framing - Process signals ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SIPC-101 — Frame worker messages without treating newlines as boundaries **Task · Medium priority · Foundational** noCV practice brief v5 · SIPC-101 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A diagnostic string contains a newline and splits one response into two apparent messages. Acceptance criteria - Frame declares version, type, request identity, and bounded payload length - Reader handles partial headers and payloads - Unknown versions fail without consuming the next frame Implementation constraints - Cap frame size before allocating its payload buffer. Verification - Read several frames split across every header boundary. - Advertise an oversized or truncated payload and verify bounded rejection. Deliverables - Versioned frame codec and fragmentation tests Rollout and recovery: Keep the line protocol available only for old local fixtures during migration. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-102 — Close inherited descriptors before executing the worker **Bug · Medium priority · Foundational** noCV practice brief v5 · SIPC-102 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Security 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 child inherits the supervisor listener and keeps it open after the parent exits, preventing clean restart. Acceptance criteria - Child receives only declared stdin, stdout, stderr, and control handles - Supervisor closes duplicate ends after spawn - Restart can bind the same local endpoint Implementation constraints - Do not depend on a global close-all scan that races other threads opening handles. Verification - Spawn, complete, and restart a worker while checking descriptor counts. - Add an undeclared inheritable handle and confirm the fixture detects it. Deliverables - Spawn handle policy and leak regression Rollout and recovery: Audit handle inheritance before enabling multiple workers. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-103 — Correlate out-of-order worker replies to the right caller **Story · Medium priority · Intermediate** noCV practice brief v5 · SIPC-103 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SIPC-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · 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. Two conversions finish in reverse order and the supervisor resolves the first waiter with the second result. Acceptance criteria - Every accepted request has a unique operation identity - Replies resolve only the matching pending request - Duplicate and unknown replies are recorded without completing another caller Implementation constraints - Keep the pending map bounded by admission capacity and deadlines. Verification - Complete three requests in reverse order and verify each result. - Send a duplicate and an unknown identity and confirm pending callers remain unchanged. Deliverables - Correlation table and ordering tests Rollout and recovery: Enable concurrent requests only after correlation checks pass. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SIPC-104 — Separate protocol output from worker diagnostics **Chore · Medium priority · Intermediate** noCV practice brief v5 · SIPC-104 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SIPC-101, SIPC-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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 library warning written to stdout is parsed as a reply and closes the worker connection. Acceptance criteria - Protocol frames use one declared channel - Diagnostics use stderr with bounded capture - Malformed protocol bytes fail the request without hiding diagnostics Implementation constraints - Sanitize diagnostics and cap retained bytes per worker. Verification - Return a valid response while writing warnings to stderr. - Write nonprotocol bytes on the protocol channel and verify isolated failure. Deliverables - Channel contract and mixed-output fixtures Rollout and recovery: Treat unexpected stdout as a worker defect during local migration. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-105 — Apply backpressure when a worker stops reading **Task · High priority · Advanced** noCV practice brief v5 · SIPC-105 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SIPC-103, SIPC-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Pattern topics: Bulkhead (apply). Bulkhead — Apply: Isolate each child process buffer and preserve global capacity so one stopped reader cannot consume every supervisor resource. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A stalled child leaves the supervisor buffering every request body until memory is exhausted. Acceptance criteria - Per-worker and global pending byte limits are enforced - Admission reports overload before consuming the body - Healthy workers can continue within their own capacity Implementation constraints - Do not solve the stall with an unbounded retry queue. Verification - Drive balanced workers to their declared capacity. - Pause one reader and prove buffers remain bounded while another worker progresses. Deliverables - IPC admission controller and stalled-reader test Rollout and recovery: Start with small limits and expose overload to callers. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-106 — Classify worker exit before deciding whether to retry **Bug · High priority · Advanced** noCV practice brief v5 · SIPC-106 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SIPC-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Distributed systems 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 worker exits after writing its output but before the acknowledgement frame; automatic retry may produce a second external artifact. Acceptance criteria - Outcome distinguishes not-started, running, acknowledged, failed, and unknown - Unknown completion requires status lookup or explicit review - Retry reuses the stable operation identity Implementation constraints - Do not infer failure solely from pipe closure or process exit code. Verification - Exercise exits before start and after acknowledged completion. - Exit after effect but before acknowledgement and preserve UNKNOWN without blind retry. Deliverables - Exit classification state machine and ambiguity fixtures Rollout and recovery: Disable automatic retry for unknown outcomes until the worker supports reconciliation. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-107 — Terminate a process tree without signaling unrelated work **Story · High priority · Expert** noCV practice brief v5 · SIPC-107 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SIPC-102, SIPC-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A timed-out worker launches a helper. Killing only the parent leaks the helper; reusing a process-group identifier risks signaling a newer process. Acceptance criteria - Each operation owns a fresh supervised process group or platform job object - Termination verifies the group identity before signaling - Cleanup observes all declared descendants or reports unresolved members Implementation constraints - Tests use inert local helpers and never enumerate or signal arbitrary host processes. Verification - Terminate a fixture parent and its two waiting children. - Reuse a synthetic numeric identifier and prove identity validation blocks the stale cleanup. Deliverables - Process-tree lifecycle adapter and safe termination tests Rollout and recovery: Keep worker concurrency at one until descendant cleanup is reliable. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SIPC-108 — Restart crashed workers without retry storms **Chore · High priority · Advanced** noCV practice brief v5 · SIPC-108 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SIPC-105, SIPC-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Pattern topics: Circuit Breaker (apply). Circuit Breaker — Apply: Open a bounded unavailable state after repeated worker crashes so replacement attempts stop until the declared recovery probe. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A corrupt fixture crashes every replacement worker, and immediate restart loops consume the supervisor CPU. Acceptance criteria - Restart budget uses bounded attempts and backoff - Stable runtime resets the failure window - Exhaustion opens a visible unavailable state Implementation constraints - Use injected time and deterministic jitter; do not sleep in tests. Verification - Crash twice, recover, and verify the budget clears after stability. - Crash every replacement and confirm restart attempts stop at the bound. Deliverables - Restart policy and crash-loop test Rollout and recovery: Fail new requests fast while a worker class is unavailable. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-109 — Reconcile pending operations after supervisor restart **Task · High priority · Expert** noCV practice brief v5 · SIPC-109 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SIPC-103, SIPC-106, SIPC-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Storage systems 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 supervisor restarts with requests marked running but no in-memory correlation table and no proof whether workers completed them. Acceptance criteria - Persist stable operation identity and last acknowledged state before dispatch - Recovery queries a deterministic worker ledger when supported - Unresolved operations remain visible and are never silently marked failed Implementation constraints - The local ledger contains synthetic identities and bounded metadata, not document bodies. Verification - Restart after acknowledgement and restore the completed result. - Restart during an unqueryable effect and retain UNKNOWN for review. Deliverables - Pending-operation journal and restart drill Rollout and recovery: Require reconciliation support before enabling autonomous retry. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. #### SIPC-110 — Document the IPC boundary for a future isolated provider **Bug · Medium priority · Intermediate** noCV practice brief v5 · SIPC-110 · Supervise local worker processes without losing their output Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SIPC-107, SIPC-108, SIPC-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Platform 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 local child-process harness is about to be mistaken for a production candidate-code sandbox. Acceptance criteria - Document framing, resource limits, process identity, shutdown, and unresolved outcomes - State which isolation guarantees the local supervisor does not provide - Define the provider contract a hardened external executor must satisfy Implementation constraints - Do not claim namespace, secret, network, or host isolation from ordinary child processes. Verification - Reproduce the local crash and restart drill from the guide. - Attempt to select the local adapter under a production configuration and require fail-closed behavior. Deliverables - IPC contract and explicit production boundary note Rollout and recovery: Keep the local supervisor restricted to synthetic development fixtures. Project prerequisites: File descriptors Framing Process signals Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion. Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider. 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. ## SRUNTIME — Evolve a bounded bytecode runtime without executing host code A fictional rules engine executes a tiny arithmetic bytecode over synthetic integers. Its interpreter trusts jump offsets and can run forever. Build a local Rust runtime; it has no filesystem, network, dynamic loading, host calls, or candidate-source execution. **Field:** Systems programming. **Suggested stack:** Rust, Bytecode fixtures, Property tests, Fuzzing. **Engineer value:** Practice runtime invariants, validation, resource accounting and compatibility. **Company value:** Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - Stacks - Instruction decoding - Control flow ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SRUNTIME-101 — Decode instructions without reading past the bytecode buffer **Task · Medium priority · Foundational** noCV practice brief v5 · SRUNTIME-101 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Compiler and language tooling 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 truncated PUSH instruction reads its operand from bytes beyond the supplied program. Acceptance criteria - Decoder checks opcode and operand length before advancing - Unknown opcodes return a stable offset and code - Failure exposes no partially decoded instruction Implementation constraints - Keep bytecode length bounded before parsing. Verification - Decode a program containing every documented instruction. - Truncate at every byte and confirm deterministic errors without panic. Deliverables - Checked decoder and truncation matrix Rollout and recovery: Reject programs not validated by the new decoder. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-102 — Validate stack depth across both sides of a branch **Bug · Medium priority · Foundational** noCV practice brief v5 · SRUNTIME-102 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SRUNTIME-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Compiler and language 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. One branch pushes a value and the other does not, so the merge point underflows only for certain inputs. Acceptance criteria - Validator computes required and resulting depth per instruction - Control-flow merges require compatible stack shape - Maximum stack depth is bounded before execution Implementation constraints - Validation must terminate on loops through a visited-state worklist. Verification - Validate a diamond control flow with matching stack shapes. - Change one branch to omit a push and reject the merge. Deliverables - Stack-shape validator and branch fixtures Rollout and recovery: Keep runtime stack checks even after static validation. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-103 — Reject jumps that land inside instruction operands **Story · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-103 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SRUNTIME-101, SRUNTIME-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Security 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 crafted jump targets the second byte of a literal and reinterprets it as an opcode. Acceptance criteria - Decoder records every legal instruction boundary - Jump targets must reference a boundary in the same program - Backward jumps remain permitted within the execution budget Implementation constraints - Do not normalize invalid offsets to the nearest instruction. Verification - Execute forward and backward jumps to valid boundaries. - Target each byte inside a multi-byte operand and reject validation. Deliverables - Boundary-indexed control-flow validation Rollout and recovery: Invalidate cached programs when the instruction format version changes. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SRUNTIME-104 — Report integer overflow instead of changing arithmetic by build mode **Chore · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-104 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Debug builds trap on addition overflow while optimized builds wrap, producing different rule outcomes. Acceptance criteria - Arithmetic semantics are identical across build profiles - Overflow returns a typed runtime fault with instruction offset - Division defines zero and minimum-value edge cases Implementation constraints - Use checked operations; do not expose floating-point values in this bytecode revision. Verification - Evaluate boundary-safe addition, subtraction, multiplication, and division. - Exercise every overflow boundary and division by zero in both profiles. Deliverables - Arithmetic contract and profile-parity tests Rollout and recovery: Version any intentional arithmetic semantic change. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-105 — Stop infinite programs with a deterministic instruction budget **Task · High priority · Advanced** noCV practice brief v5 · SRUNTIME-105 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-103, SRUNTIME-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A backward jump with an always-true condition consumes a worker indefinitely. Acceptance criteria - Caller supplies a positive maximum instruction count - Every executed instruction consumes budget - Exhaustion returns current offset and no successful result Implementation constraints - Wall-clock timeout can be defense in depth but is not the deterministic oracle. Verification - Run a terminating loop at exactly the declared budget. - Run an infinite loop and verify failure at the same step in repeated executions. Deliverables - Instruction metering and loop-bound tests Rollout and recovery: Begin with a conservative budget and expose exhaustion separately from invalid bytecode. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-106 — Bound heap-like values without adding a garbage collector **Bug · High priority · Advanced** noCV practice brief v5 · SRUNTIME-106 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-102, SRUNTIME-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A proposed LIST instruction allocates on every loop iteration and the prototype retains all intermediate values. Acceptance criteria - Compare arena reset, reference counting, and no-list alternatives for the bounded language - Chosen design defines maximum live bytes and value count - Budget failure releases all runtime-owned allocations Implementation constraints - Do not introduce tracing collection without a workload and cycle requirement that needs it. Verification - Evaluate a bounded list program and reconcile peak live bytes. - Allocate until the value budget and confirm clean failure without leaks. Deliverables - Memory strategy decision and bounded-value prototype Rollout and recovery: Keep LIST disabled until the memory contract is accepted. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-107 — Cache validated programs without confusing bytecode revisions **Story · High priority · Expert** noCV practice brief v5 · SRUNTIME-107 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-103, SRUNTIME-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Compiler and language 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 cached validation result for version one is reused after an opcode gains a wider operand in version two. Acceptance criteria - Cache identity binds exact bytes, bytecode version, validator version, and limits - Validation failure is not cached across a newer validator - Hash collision handling cannot return another program Implementation constraints - Cache entries contain immutable validated metadata and bounded program bytes only. Verification - Reuse one validated program under identical authority. - Change each identity dimension and require a miss; inject a key collision and compare bytes. Deliverables - Versioned validation cache and collision tests Rollout and recovery: Enable read-through caching after hit/miss telemetry reconciles with validation calls. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SRUNTIME-108 — Make runtime faults useful without leaking input values **Chore · High priority · Advanced** noCV practice brief v5 · SRUNTIME-108 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-104, SRUNTIME-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Privacy 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. Fault logs dump the full operand stack, which may later contain customer-derived values, while omitting the bytecode revision needed for diagnosis. Acceptance criteria - Fault records contain code, instruction offset, runtime version, and bounded trace identity - Operand values and full program bytes are excluded - Repeated identical faults aggregate under bounded dimensions Implementation constraints - Use synthetic values in the exercise and keep generic analytics content-free. Verification - Produce each fault class and reconcile its diagnostic fields. - Push a sentinel value and confirm it appears in no log or metric. Deliverables - Redacted runtime fault schema and tests Rollout and recovery: Replace verbose stack dumps before adding any non-synthetic inputs. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-109 — Load a new runtime revision without changing in-flight programs **Task · High priority · Expert** noCV practice brief v5 · SRUNTIME-109 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-107, SRUNTIME-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Platform 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. Pattern topics: Singleton (remove). Singleton — Remove: Replace the mutable process-wide opcode registry with immutable runtime revision snapshots bound explicitly to each execution. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Reloading the opcode table mutates a global registry while workers execute programs validated under the old table. Acceptance criteria - Each execution binds one immutable runtime revision - New programs select only fully initialized revisions - Retirement waits for in-flight references without blocking unrelated execution Implementation constraints - Avoid a mutable Singleton registry; publish immutable snapshots through explicit ownership. Verification - Run old and new program revisions concurrently and verify their semantics. - Attempt a partial revision load and confirm no execution can select it. Deliverables - Revision registry, concurrent load test, and retirement protocol Rollout and recovery: Publish one synthetic revision behind an explicit selector and retain rollback to the prior snapshot. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. #### SRUNTIME-110 — Fuzz the runtime under fixed memory and step limits **Bug · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-110 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-105, SRUNTIME-106, SRUNTIME-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Random bytecode tests occasionally hang or consume the test host, so the suite is disabled in continuous integration. Acceptance criteria - Harness caps input bytes, instructions, value memory, and wall-clock defense - Every failure records a minimized reproducible seed - Crash, panic, timeout, and semantic disagreement are distinct outcomes Implementation constraints - Run only the capability-free local runtime; never execute generated host code. Verification - Replay the checked-in seed corpus with deterministic results. - Seed malformed loops and oversized allocations and confirm bounded termination. Deliverables - Bounded fuzz harness and minimized regression corpus Rollout and recovery: Start with a short deterministic CI corpus and schedule longer local runs separately. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. 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. ## SFFI — Stabilize a native compression boundary before wider adoption A fictional desktop backup tool calls a small Rust compression library from Node.js. The binding leaks buffers on exceptions and treats ABI mismatches as corrupted input. Build against generated byte arrays and a local native library; no production archive format or user files are supplied. **Field:** Systems programming. **Suggested stack:** Rust, C ABI, Node-API, Sanitizers. **Engineer value:** Practice language-boundary contracts, native resource safety and version negotiation. **Company value:** Review a binding that fails safely and can be rolled back before native code enters additional application paths. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - FFI ownership - Binary compatibility - Error handling ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SFFI-101 — Write the buffer ownership table before exposing the binding **Task · Medium priority · Foundational** noCV practice brief v5 · SFFI-101 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer tooling 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. JavaScript and Rust both believe the other side frees an output buffer when conversion throws. Acceptance criteria - Document owner for every input, output, error, and callback value - Each transfer has one release operation and allowed thread - Borrowed memory cannot outlive its originating call Implementation constraints - Do not infer ownership from constness or language garbage collection. Verification - Trace success and error paths through the ownership table. - Inject failure after native allocation and verify exactly one release. Deliverables - FFI ownership contract and allocation counter test Rollout and recovery: Keep the pure-language fallback until every path has an owner. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-102 — Validate lengths before converting JavaScript buffers **Bug · Medium priority · Foundational** noCV practice brief v5 · SFFI-102 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Security 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 signed length crosses the C boundary and becomes a very large unsigned value. Acceptance criteria - Binding rejects lengths outside the actual buffer and native type range - Zero-length input follows a documented contract - Conversion failure calls no compression function Implementation constraints - Perform validation on the boundary side that has both pointer and buffer length. Verification - Compress empty, small, and maximum-fixture buffers. - Pass negative-equivalent, oversized, and detached buffers and verify rejection. Deliverables - Length checks and boundary corpus Rollout and recovery: Reject unsupported buffers before enabling the native path. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-103 — Map native errors without losing machine-readable causes **Story · Medium priority · Intermediate** noCV practice brief v5 · SFFI-103 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SFFI-101, SFFI-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Every nonzero native status becomes 'compression failed', hiding whether the caller supplied bad input or the allocator exhausted its cap. Acceptance criteria - Stable public codes distinguish input, capacity, version, cancellation, and internal faults - Native diagnostic text is bounded and treated as untrusted - Unknown statuses map to one safe internal category Implementation constraints - Do not include raw input bytes or native addresses in errors. Verification - Trigger and map each declared native status. - Return an unknown status with oversized text and verify bounded safe mapping. Deliverables - Versioned error map and contract tests Rollout and recovery: Callers must stop branching on old free-form messages before migration. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SFFI-104 — Release native output after JavaScript cancellation **Chore · Medium priority · Intermediate** noCV practice brief v5 · SFFI-104 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-101, SFFI-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time 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 caller abandons a promise while native work finishes later; its output buffer has no remaining JavaScript consumer and is leaked. Acceptance criteria - Operation state records whether a result still has a consumer - Late output is released on the native allocation thread or declared safe path - Cancellation and completion races release once Implementation constraints - Cancellation is cooperative; do not unload code while a native call is running. Verification - Cancel before start and after successful delivery. - Race cancellation with native completion across repeated deterministic schedules. Deliverables - Cancellation cleanup protocol and race tests Rollout and recovery: Keep native concurrency at one until release counts reconcile. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-105 — Move blocking compression off the JavaScript event loop **Task · High priority · Advanced** noCV practice brief v5 · SFFI-105 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-102, SFFI-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A 50 MB synthetic buffer blocks timers and health checks because the binding invokes native compression synchronously. Acceptance criteria - Large work runs in a bounded worker pool - Completion returns on the expected runtime thread - Queue saturation rejects before copying the full input Implementation constraints - Measure copy cost separately from compression time and cap fixture size. Verification - Compress concurrent small and large buffers while measuring timer delay. - Saturate the pool and confirm bounded memory with a typed overload result. Deliverables - Asynchronous binding and event-loop latency report Rollout and recovery: Route buffers above a measured threshold first and retain synchronous fallback for small fixtures. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-106 — Negotiate ABI capability before the first compression call **Bug · High priority · Advanced** noCV practice brief v5 · SFFI-106 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Platform 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. A newer binding calls an option function missing from the loaded native library and the process terminates during symbol resolution. Acceptance criteria - Initialization reads ABI version and explicit capability bits - Unsupported required capabilities fail before accepting work - Optional capabilities have documented fallback behavior Implementation constraints - Do not infer ABI compatibility from package version or filename alone. Verification - Load current and compatible older fixture libraries. - Load a library missing a required symbol and fail closed before dispatch. Deliverables - ABI handshake and compatibility matrix Rollout and recovery: Probe in startup readiness while the pure-language provider remains selectable. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-107 — Contain a native panic without pretending the process is safe **Story · High priority · Expert** noCV practice brief v5 · SFFI-107 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-103, SFFI-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Malformed options trigger a Rust panic that crosses the C ABI and aborts the Node process. Acceptance criteria - FFI entry points catch supported unwind cases before the ABI boundary - Panic maps to an internal fault with operation identity - Abort-configured builds are identified and isolated out of process Implementation constraints - Do not claim catch_unwind protects memory after arbitrary native corruption. Verification - Trigger a controlled recoverable panic and map its result. - Select an aborting fixture provider and require process-isolation policy instead of in-process execution. Deliverables - Panic-boundary policy and controlled failure fixtures Rollout and recovery: Keep risky codecs behind an external process provider until their failure mode is qualified. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SFFI-108 — Compare native output against the compatibility oracle **Chore · High priority · Advanced** noCV practice brief v5 · SFFI-108 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-105, SFFI-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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 native path is faster but emits archives the existing decompressor accepts differently around empty blocks. Acceptance criteria - Golden corpus defines byte compatibility or declared semantic compatibility - Both providers round-trip every supported case - Differences are classified before rollout Implementation constraints - Use generated non-sensitive bytes and pin provider versions in the report. Verification - Compare providers across corpus sizes and option combinations. - Inject a one-byte divergence and show the gate blocks promotion. Deliverables - Differential harness and compatibility report Rollout and recovery: Canary only corpus classes with reconciled outputs. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-109 — Unload a retired native revision only after callbacks drain **Task · High priority · Expert** noCV practice brief v5 · SFFI-109 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-104, SFFI-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Hot replacement unloads the old library while an asynchronous completion callback still points into its code. Acceptance criteria - Each operation pins one library revision through callback completion - Retirement blocks new calls and observes active reference count - Deadline reports unresolved references without forced unload Implementation constraints - Prefer process restart for platforms that cannot guarantee safe dynamic unloading. Verification - Run old and new revisions concurrently, then retire the old after drain. - Hold one completion callback and verify unload does not occur at the deadline. Deliverables - Revision lifetime protocol and delayed-callback test Rollout and recovery: Use process replacement as the default until in-process retirement is proven for the target platform. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-110 — Package the native binding with a reversible compatibility gate **Bug · Medium priority · Intermediate** noCV practice brief v5 · SFFI-110 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-107, SFFI-108, SFFI-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · DevOps 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 package publish selects the native binary by platform name but ignores CPU features and libc compatibility. Acceptance criteria - Artifact metadata binds OS, architecture, ABI, runtime, and required CPU features - Installer rejects an incompatible binary before load - Pure-language fallback selection is explicit and observable Implementation constraints - Do not download or execute binaries outside the generated local fixture set. Verification - Select each compatible fixture artifact and report its identity. - Present wrong architecture, ABI, and feature metadata and verify safe fallback. Deliverables - Artifact selector, compatibility cases, and rollback note Rollout and recovery: Publish metadata and fallback behavior before enabling native-by-default selection. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. ## SKERNEL — Build an operating-system boundary that fails predictably A fictional local agent watches generated inbox files and schedules bounded processing. Direct system calls are scattered across the code, mishandle interrupted operations, and make tests platform-dependent. Build a Rust OS adapter with temporary fixture directories; no kernel module, elevated privilege, or production host modification is required. **Field:** Systems programming. **Suggested stack:** Rust, Filesystem APIs, Polling adapter, Temporary directories. **Engineer value:** Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. **Company value:** Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - System calls - File descriptors - Monotonic clocks ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SKERNEL-101 — Read a file completely across short system calls **Task · Medium priority · Foundational** noCV practice brief v5 · SKERNEL-101 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Storage 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 adapter assumes one read fills the requested buffer and silently truncates a generated manifest after an injected short read. Acceptance criteria - Loop until EOF, declared length, or typed error - Return bytes already read only when the contract permits partial results - Zero-progress reads cannot spin forever Implementation constraints - Use a controllable local read adapter; never require privileged system-call interception. Verification - Read the same manifest through one-byte and irregular chunk schedules. - Return zero progress before EOF and confirm bounded failure. Deliverables - Complete-read primitive and short-read tests Rollout and recovery: Route manifest reads through the helper before larger files. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-102 — Write a durable replacement without exposing a half file **Bug · Medium priority · Foundational** noCV practice brief v5 · SKERNEL-102 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Storage systems 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 crash between truncation and write leaves the agent configuration empty. Acceptance criteria - Write to a unique file in the destination directory - Flush file content before atomic replacement where the platform supports it - Document directory durability and unsupported-platform behavior Implementation constraints - Preserve permissions intentionally and reject symlink destination surprises. Verification - Replace an existing fixture and observe either old or complete new content. - Interrupt before rename and confirm the destination remains unchanged. Deliverables - Atomic-replace adapter and interruption cases Rollout and recovery: Retain backups only under an explicit bounded retention policy. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-103 — Retry interrupted calls without hiding cancellation **Story · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-103 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SKERNEL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time 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. Every interrupted call is retried automatically, so a cancelled operation keeps waiting after shutdown begins. Acceptance criteria - Retry only declared interrupt errors - Check cancellation and deadline between attempts - Preserve noninterrupt error identity Implementation constraints - Retry policy belongs beside the operation contract, not in a catch-all error loop. Verification - Inject two interrupts followed by success before deadline. - Cancel between interrupts and verify no further system call is attempted. Deliverables - Interrupt-aware retry helper and cancellation tests Rollout and recovery: Adopt per operation after its retry safety is reviewed. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SKERNEL-104 — Keep wall-clock changes out of elapsed-time deadlines **Chore · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-104 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time 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. An NTP correction moves wall time backwards and extends a file-processing deadline by several minutes. Acceptance criteria - Elapsed deadlines use an injected monotonic clock - User-facing timestamps remain UTC wall time - Conversion between the two clock domains is prohibited Implementation constraints - Tests advance fake clocks; they do not alter the host clock. Verification - Expire a deadline through monotonic advancement. - Move wall time forward and backward and prove elapsed behavior is unchanged. Deliverables - Clock boundary and time-jump tests Rollout and recovery: Migrate deadline call sites before changing displayed timestamps. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-105 — Normalize watcher bursts into a bounded rescan request **Task · High priority · Advanced** noCV practice brief v5 · SKERNEL-105 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-102, SKERNEL-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. One editor save produces create, rename, and modify events; the agent processes the same file three times and misses changes after queue overflow. Acceptance criteria - Events trigger idempotent directory reconciliation rather than direct truth - Burst coalescing has a maximum delay - Overflow schedules a full bounded rescan and remains visible Implementation constraints - Do not promise identical watcher events across operating systems. Verification - Replay create-via-rename and direct-write event sequences with one final reconciliation. - Overflow the event buffer and confirm a rescan restores the fixture state. Deliverables - Watcher reconciliation loop and platform event fixtures Rollout and recovery: Keep periodic scans as a fallback during watcher rollout. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-106 — Bound open descriptors while scanning a deep inbox **Bug · High priority · Advanced** noCV practice brief v5 · SKERNEL-106 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-101, SKERNEL-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. Recursive scanning opens every subdirectory before closing any, exhausting the process descriptor limit. Acceptance criteria - Traversal has an explicit descriptor and work-queue bound - Directory handles close on success, skip, and error - Unreadable entries are reported without aborting unrelated roots Implementation constraints - Use a generated tree and configured low limit; do not change host-wide limits. Verification - Scan a deep and wide tree while measuring peak open handles. - Inject an unreadable directory and repeated short reads, then check cleanup. Deliverables - Bounded scanner and descriptor accounting test Rollout and recovery: Start with one configured root and expose incomplete scans. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-107 — Prevent path traversal through a watched-root handle **Story · High priority · Expert** noCV practice brief v5 · SKERNEL-107 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-102, SKERNEL-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Security 35%. 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 path is validated under the inbox, then a directory is replaced with a symlink before open, escaping the allowed root. Acceptance criteria - Operations resolve relative to an already opened trusted root - Traversal rejects symlinks or verifies each component under declared policy - Validation and use cannot be separated by an attacker-controlled rename Implementation constraints - Use temporary synthetic directories and no elevated privileges. Verification - Open and replace normal nested fixture files through the root handle. - Race a directory-to-symlink swap and confirm no outside file is read or changed. Deliverables - Root-relative filesystem adapter and race regression Rollout and recovery: Fail closed on platforms where the required safe primitive is unavailable. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SKERNEL-108 — Expose platform capability instead of silently changing semantics **Chore · High priority · Advanced** noCV practice brief v5 · SKERNEL-108 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-102, SKERNEL-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Platform 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 Windows fixture cannot provide the same directory-flush guarantee as the Unix adapter, but both report durable replacement. Acceptance criteria - Adapter reports exact supported capabilities - Callers can require a capability and fail before mutation - Fallback semantics have distinct result codes and documentation Implementation constraints - Do not erase platform differences behind a boolean success value. Verification - Run the shared contract against two declared capability fixtures. - Require directory durability from an unsupported fixture and confirm no replacement starts. Deliverables - OS capability model and cross-adapter contract suite Rollout and recovery: Gate each deployment profile on its required capability set. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-109 — Recover an orphaned temporary replacement after restart **Task · High priority · Expert** noCV practice brief v5 · SKERNEL-109 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-102, SKERNEL-107, SKERNEL-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 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. A crash leaves temporary files beside the destination; startup cannot tell whether they are incomplete writes or a replacement ready to finish. Acceptance criteria - Temporary name binds operation identity and expected content hash - Recovery verifies destination and temporary content before action - Ambiguous or foreign files remain untouched and visible Implementation constraints - Cleanup is scoped to the opened trusted root and never follows links. Verification - Recover before-rename and after-rename crash fixtures idempotently. - Place a foreign matching-looking file and confirm the agent records but does not delete it. Deliverables - Replacement journal and startup reconciliation drill Rollout and recovery: Run recovery in report-only mode before enabling scoped cleanup. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-110 — Package the OS adapter without requesting unnecessary privilege **Bug · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-110 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-107, SKERNEL-108, SKERNEL-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · DevOps 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 installer manifest requests administrator access even though the agent operates only inside a user-selected directory. Acceptance criteria - Document required paths, handles, notifications, and permissions - Default installation runs as an unprivileged user - Unavailable optional watcher capability falls back visibly to polling Implementation constraints - Do not install services, modify the registry, or request real privilege in the exercise. Verification - Run the packaged local fixture under a restricted temporary account profile. - Remove watcher capability and verify bounded polling without elevated fallback. Deliverables - Privilege inventory, packaging manifest, and fallback test Rollout and recovery: Keep installation local and reversible until platform review is complete. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. ## DCI — Make pull-request CI trustworthy under load A fictional TypeScript monorepo has twelve packages and a local CI simulator. Pull requests wait for redundant work, stale caches occasionally pass broken changes, and superseded runs continue consuming executors. Create synthetic package graphs and fake check APIs; no hosted CI credentials or production repositories are supplied. **Field:** DevOps. **Suggested stack:** TypeScript, pnpm, Git, CI simulator. **Engineer value:** Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. **Company value:** Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Dependency graphs - Process exit codes - Test isolation ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DCI-101 — Pin the required-check contract before optimizing the pipeline **Task · Medium priority · Foundational** noCV practice brief v5 · DCI-101 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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. Branch protection expects names that differ from the workflow after a recent rename, leaving one required check permanently pending. Acceptance criteria - Declare stable check identities and their owning commands - Map every protected check to exactly one terminal report - Unknown or duplicated check names fail workflow validation Implementation constraints - The local simulator must not call a real repository or modify branch protection. Verification - Complete every declared check and reconcile its final status. - Rename and duplicate a check, then confirm validation blocks the workflow. Deliverables - Required-check manifest and consistency test Rollout and recovery: Publish the manifest before changing job topology. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-102 — Fail the pipeline when a command exits through a hidden pipe **Bug · Medium priority · Foundational** noCV practice brief v5 · DCI-102 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Test output is piped through a formatter; the formatter succeeds after the test process fails, so the job reports green. Acceptance criteria - Job status reflects every command in the pipeline - Original stdout and stderr remain available - Signal termination and ordinary nonzero exit are distinguished Implementation constraints - Do not parse human-readable output to determine success. Verification - Run successful tests through the formatter and retain readable logs. - Fail the upstream process and verify the job reports its exact failure. Deliverables - Exit-status wrapper and pipeline regression Rollout and recovery: Apply first to test jobs, then audit every piped command. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-103 — Compute affected packages from both dependency directions **Story · Medium priority · Intermediate** noCV practice brief v5 · DCI-103 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DCI-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Changing a shared type package runs its own tests but skips three consumers that compile against the changed contract. Acceptance criteria - Changed packages and transitive consumers enter the affected set - Deleted and renamed files map to their owning package - Global configuration changes select the declared full set Implementation constraints - Use the synthetic graph and explicit ownership rules; filename substring guesses are insufficient. Verification - Change a leaf, shared library, and root configuration and compare selected packages. - Create a dependency cycle fixture and fail analysis without silently dropping nodes. Deliverables - Affected-graph selector and graph fixtures Rollout and recovery: Run selection in report-only mode beside the current full pipeline. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DCI-104 — Key build caches from every semantic input **Chore · Medium priority · Intermediate** noCV practice brief v5 · DCI-104 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 cache hit reuses generated clients after the schema changed because only source-directory files contribute to the key. Acceptance criteria - Cache identity includes command, toolchain, environment contract, direct inputs, and dependency outputs - Secrets and absolute workspace paths are excluded - Restore verifies metadata before using outputs Implementation constraints - A cache hit may improve speed but cannot waive required checks. Verification - Repeat an identical build and verify a safe hit. - Change schema, compiler version, and an upstream output independently and require misses. Deliverables - Canonical cache manifest and invalidation tests Rollout and recovery: Enable read-only restore before allowing new cache writes. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-105 — Cancel superseded pull-request runs without erasing evidence **Task · High priority · Advanced** noCV practice brief v5 · DCI-105 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101, DCI-102. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Distributed systems 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 force-push starts a new run while the old run still publishes late check results under the branch name. Acceptance criteria - Concurrency identity binds repository, pull request, and immutable revision - New revision requests cancellation of older active runs - Late results remain tied to their original revision and cannot satisfy the new one Implementation constraints - Cancellation is cooperative and must not mark unfinished checks successful. Verification - Start two revisions and verify only the new one remains eligible. - Deliver a late success from the old run and prove it cannot update the new revision. Deliverables - Revision-scoped concurrency controller and race test Rollout and recovery: Canary on the local simulator while recording saved executor time. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-106 — Quarantine a flaky test without making it optional forever **Bug · High priority · Advanced** noCV practice brief v5 · DCI-106 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Quality 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 timing-sensitive test is retried until it passes, hiding a rising failure rate and extending every pull request. Acceptance criteria - First-attempt and retry outcomes remain separate - Quarantine has owner, reason, expiry, and tracking reference - Expired quarantine fails the policy check Implementation constraints - Do not classify a test as flaky from one failure; use the supplied deterministic failure history. Verification - Quarantine the documented test and keep its outcomes visible. - Expire or omit ownership and confirm the pipeline blocks rather than silently skips. Deliverables - Quarantine registry, policy check, and trend fixture Rollout and recovery: Limit quarantine to named tests and review before expiry. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-107 — Prevent untrusted pull requests from receiving release secrets **Story · High priority · Expert** noCV practice brief v5 · DCI-107 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DCI-101, DCI-103. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The same reusable workflow handles internal branches and external pull requests, and a broad token is present before trust is evaluated. Acceptance criteria - Trust context is resolved before selecting credentials or privileged jobs - Untrusted revisions receive read-only checkout and no protected environment - Privileged continuation binds the reviewed immutable revision Implementation constraints - Use fake secret handles and repository events; never place a credential value in fixtures or logs. Verification - Run trusted and untrusted event fixtures and compare granted capabilities. - Change the revision after approval and confirm privileged jobs refuse to start. Deliverables - CI trust-boundary policy and event matrix Rollout and recovery: Fail closed for ambiguous event provenance. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DCI-108 — Measure queue and execution delay separately **Chore · High priority · Advanced** noCV practice brief v5 · DCI-108 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-103, DCI-104, DCI-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The team calls CI slow from total duration, but most delay occurs before an executor starts during the morning burst. Acceptance criteria - Record created, queued, started, and completed timestamps - Report queue, setup, execution, and artifact phases separately - Percentiles retain workload and executor-class dimensions only Implementation constraints - Use bounded synthetic dimensions and state the observation window. Verification - Reconcile phase durations for a mixed local workload. - Omit a timestamp and confirm the run is marked incomplete rather than assigned zero delay. Deliverables - CI latency model and workload report Rollout and recovery: Use the baseline before changing runner count or job structure. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-109 — Resume reporting after the checks API loses a response **Task · High priority · Expert** noCV practice brief v5 · DCI-109 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-105, DCI-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Integrations 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 fake checks API accepts a final status and drops the response; the reporter retries by creating a second check with conflicting output. Acceptance criteria - One deterministic external-check identity exists per run and check - Retry reconciles remote state before creating anything - Conflicting terminal state becomes visible and stops automation Implementation constraints - Provider calls occur outside database transactions and use the local controllable adapter. Verification - Publish each terminal status once and replay reporting safely. - Drop the response after acceptance and verify reconciliation finds the existing result. Deliverables - Idempotent check reporter and lost-response drill Rollout and recovery: Enable for one check family while retaining the prior reporter for rollback. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. #### DCI-110 — Hand off CI ownership with a safe degraded mode **Bug · Medium priority · Intermediate** noCV practice brief v5 · DCI-110 · Make pull-request CI trustworthy under load Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DCI-106, DCI-107, DCI-108, DCI-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. When the cache or check provider is unavailable, maintainers do not know which failures can fall back and which must block merging. Acceptance criteria - Runbook names owners, dependencies, alerts, and escalation conditions - Cache outage falls back to uncached required checks - Check-reporting uncertainty blocks eligibility while preserving local results Implementation constraints - Do not claim merge protection changes; the exercise documents the intended integration contract. Verification - Rehearse cache loss and complete an uncached run. - Lose final check acknowledgement and follow the block-and-reconcile path. Deliverables - CI runbook and two recovery rehearsals Rollout and recovery: Review the runbook with a second engineer before adopting the workflow. Project prerequisites: Dependency graphs Process exit codes Test isolation Engineer value: Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints. Company value: Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes. 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. ## DREL — Promote one immutable release through every environment A fictional scheduling API is rebuilt separately for test, staging, and production-like local environments. The resulting images differ, release notes list the branch instead of the artifact, and rollback rebuilds old source with new dependencies. Use a local registry simulator and synthetic deployments; no cluster or customer traffic is supplied. **Field:** DevOps. **Suggested stack:** TypeScript, OCI metadata, Git, Deployment simulator. **Engineer value:** Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. **Company value:** Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Artifact digests - Release states - Health checks ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DREL-101 — Bind release identity to an artifact digest **Task · Medium priority · Foundational** noCV practice brief v5 · DREL-101 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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 deployment record stores image:latest and commit branch, so two releases display the same identity after the tag moves. Acceptance criteria - Release stores immutable artifact digest, source revision, and build manifest hash - Mutable tags resolve to a digest before approval - Display distinguishes requested tag from deployed digest Implementation constraints - Use the local registry simulator and never pull public images. Verification - Resolve and deploy one fixture tag while retaining its digest. - Move the tag and confirm the approved release identity does not change. Deliverables - Immutable release record and moved-tag test Rollout and recovery: Require digest resolution before any environment accepts a new release. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-102 — Generate release notes from the promoted revision range **Bug · Medium priority · Foundational** noCV practice brief v5 · DREL-102 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DREL-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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. Notes include commits merged after the artifact was built because they query the current branch head. Acceptance criteria - Notes bind previous and current immutable source revisions - Each change links to its synthetic pull-request identity - Empty, missing, and nonancestor ranges have explicit outcomes Implementation constraints - Do not use current branch state after release creation. Verification - Generate notes for a declared three-change revision range. - Advance the branch and confirm the existing notes remain unchanged. Deliverables - Revision-bound notes generator and history fixtures Rollout and recovery: Publish notes as draft until artifact and range reconciliation pass. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-103 — Promote the built artifact instead of rebuilding it **Story · Medium priority · Intermediate** noCV practice brief v5 · DREL-103 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DREL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Cloud infrastructure 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. Staging and production-like environments run images compiled at different times from the same source label. Acceptance criteria - Build creates one content-addressed artifact - Promotion changes environment references without changing bytes - Environment record retains promotion actor, time, and source environment Implementation constraints - Configuration remains external and versioned; it is not baked differently into each image. Verification - Promote one digest through two fixture environments and compare bytes. - Attempt promotion with a mismatching manifest and block the transition. Deliverables - Promotion command and byte-identity tests Rollout and recovery: Adopt from test to staging before changing the final environment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DREL-104 — Gate promotion on database compatibility **Chore · Medium priority · Intermediate** noCV practice brief v5 · DREL-104 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Database 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 expects a renamed column while rollback still expects the old one, making the nominal rollback artifact unusable. Acceptance criteria - Manifest declares required and provided schema compatibility window - Promotion checks current environment schema before deployment - Rollback target is validated against post-migration schema Implementation constraints - Use fixture schema versions; do not execute migrations against a real database. Verification - Promote an expand-compatible release and validate its rollback target. - Attempt a contract-first release and show the gate identifies the incompatible direction. Deliverables - Schema compatibility gate and rollout matrix Rollout and recovery: Require expand, migrate, contract phases for destructive changes. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-105 — Canary one cohort with a measurable abort rule **Task · High priority · Advanced** noCV practice brief v5 · DREL-105 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103, DREL-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A canary is called healthy because no one watched it for long, despite a synthetic error spike in one endpoint. Acceptance criteria - Canary binds cohort, duration, traffic minimum, and comparison baseline - Abort evaluates declared error and latency thresholds - Insufficient observations remain inconclusive Implementation constraints - Use deterministic synthetic traffic; thresholds apply only to this exercise. Verification - Run a healthy canary through the full observation window. - Inject an endpoint-specific regression and confirm automatic halt before wider rollout. Deliverables - Canary policy, evaluator, and regression fixtures Rollout and recovery: Expand only after a conclusive passing result. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-106 — Pause a release when deployment state drifts **Bug · High priority · Advanced** noCV practice brief v5 · DREL-106 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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. A manual fixture change replaces one replica image, but the release controller continues and records the target digest as complete. Acceptance criteria - Reconciliation compares desired and observed digest per instance - Unexpected drift pauses rollout and identifies affected instances - Repair requires an explicit decision to restore desired state or adopt a new release Implementation constraints - Do not overwrite drift before recording it. Verification - Complete a rollout whose observations match the release. - Change one instance out of band and confirm the controller pauses without erasing evidence. Deliverables - Drift detector and paused-release flow Rollout and recovery: Begin with report-only drift detection in the simulator. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-107 — Authorize release approval for the exact artifact **Story · High priority · Expert** noCV practice brief v5 · DREL-107 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DREL-101, DREL-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. An approval made for one digest remains valid after the release record is edited to point at another artifact. Acceptance criteria - Approval binds artifact digest, environment, policy version, and expiry - Any bound-field change invalidates approval - Requester cannot satisfy a required independent approval role Implementation constraints - Use synthetic identities and permissions; this is workflow authorization, not proof of code authorship. Verification - Approve and promote the exact eligible release. - Change digest and replay the approval token, then verify denial and audit. Deliverables - Release approval boundary and replay tests Rollout and recovery: Require explicit approval for the final simulated environment first. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DREL-108 — Rollback to a known artifact without rebuilding source **Chore · High priority · Advanced** noCV practice brief v5 · DREL-108 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-104, DREL-105, DREL-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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 rollback command checks out an old tag and rebuilds it with current dependencies, producing bytes never previously tested. Acceptance criteria - Rollback selects a previously promoted immutable digest - Compatibility gate evaluates current schema and configuration - Release history records the failed and restored identities Implementation constraints - Rollback does not delete the failed artifact or rewrite its record. Verification - Roll forward, trigger the abort rule, and restore the exact prior digest. - Remove the prior artifact from the registry fixture and block rollback with a recovery instruction. Deliverables - Digest-based rollback command and rehearsal Rollout and recovery: Maintain at least one verified compatible rollback target per environment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-109 — Resume promotion after the registry response disappears **Task · High priority · Expert** noCV practice brief v5 · DREL-109 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-103, DREL-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Integrations 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 registry accepts a promotion tag and drops the response; retry sees the tag but cannot tell whether it was created by this operation. Acceptance criteria - Promotion uses deterministic operation identity - Retry reads digest and operation metadata before mutation - Conflicting existing tag becomes visible and blocks automatic continuation Implementation constraints - The registry adapter is local and provider responses are treated as untrusted input. Verification - Promote and replay one operation with the same result. - Drop the acceptance response and separately precreate a conflicting tag. Deliverables - Idempotent promotion adapter and ambiguity tests Rollout and recovery: Enable one registry namespace while retaining digest-only deployment. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. #### DREL-110 — Publish a release ledger that answers what is running **Bug · Medium priority · Intermediate** noCV practice brief v5 · DREL-110 · Promote one immutable release through every environment Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DREL-102, DREL-106, DREL-108, DREL-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. During a rehearsal, responders compare commit hashes from logs because there is no single view of release, artifact, configuration, and schema identity. Acceptance criteria - Ledger shows desired and observed artifact per environment - Entries include configuration and schema compatibility identities - Failed, paused, rolled-back, and superseded releases remain inspectable Implementation constraints - The ledger is append-oriented planning and operational data; it is not candidate evidence. Verification - Trace a promotion, pause, and rollback from ledger entries. - Remove an observation and confirm the view displays uncertainty rather than inferred state. Deliverables - Release ledger projection and responder guide Rollout and recovery: Use the ledger during a full local rollback rehearsal before handoff. Project prerequisites: Artifact digests Release states Health checks Engineer value: Practice immutable promotion, release authority, compatibility gates, canaries, and rollback. Company value: Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it. 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. ## DENV — Keep environment configuration explicit and recoverable A fictional notification service uses environment files assembled by shell scripts. Defaults differ by machine, secret values appear in diagnostics, and emergency flags have no expiry. Build a typed local configuration compiler with fake secret references and synthetic environments; no real credentials or notification providers are supplied. **Field:** DevOps. **Suggested stack:** TypeScript, JSON Schema, Secret adapter, Vitest. **Engineer value:** Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. **Company value:** Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Configuration precedence - Schema validation - Least privilege ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DENV-101 — Define precedence without depending on process order **Task · Medium priority · Foundational** noCV practice brief v5 · DENV-101 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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. Local, environment, and command-line values are merged in object iteration order, so the same inputs produce different ports in two scripts. Acceptance criteria - Declare precedence for base, environment, and explicit override layers - Each resolved value retains its source layer - Duplicate keys within one layer fail parsing Implementation constraints - Do not read the host process environment directly in domain tests. Verification - Resolve the same layers in shuffled input order and compare output. - Provide duplicate keys and confirm no partial configuration is returned. Deliverables - Layered configuration resolver and precedence tests Rollout and recovery: Generate a report beside the current scripts before switching consumers. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-102 — Reject missing required values before service startup **Bug · Medium priority · Foundational** noCV practice brief v5 · DENV-102 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DENV-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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 service starts with an empty callback base URL and fails only when the first delivery completes. Acceptance criteria - Schema distinguishes required, optional, and defaulted values - Validation reports all safe field errors together - Invalid configuration prevents provider initialization Implementation constraints - Defaults must be explicit in the versioned schema and safe for every environment that uses them. Verification - Validate complete development and production-like fixture configurations. - Remove several required fields and confirm providers are never constructed. Deliverables - Typed configuration schema and startup tests Rollout and recovery: Run validation as a pre-deployment gate before enforcing it at startup. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-103 — Keep secret values out of configuration diffs **Story · Medium priority · Intermediate** noCV practice brief v5 · DENV-103 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DENV-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A deployment preview serializes the fully resolved configuration, including a fake API token value, into the job log. Acceptance criteria - Configuration stores secret references separately from ordinary values - Diffs show reference identity and version without secret content - Errors and snapshots redact values even when resolution fails Implementation constraints - Use sentinel fake secrets and assert they never appear in output. Verification - Diff two configurations with changed secret references. - Make resolution fail with a sentinel value in the provider error and verify redaction. Deliverables - Secret-reference model and log-leak tests Rollout and recovery: Remove full resolved-config logging before connecting any nonfixture provider. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DENV-104 — Validate cross-field configuration invariants **Chore · Medium priority · Intermediate** noCV practice brief v5 · DENV-104 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DENV-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · 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. Retries are enabled while the idempotency store is disabled, creating duplicate notification attempts after timeouts. Acceptance criteria - Cross-field rules run after individual field validation - Retry requires a compatible idempotency mode and positive deadline - Errors identify involved settings without exposing values Implementation constraints - Keep invariants centralized and versioned rather than scattered among service constructors. Verification - Validate supported retry and store combinations. - Enable retry with no store and with a shorter operation deadline than backoff. Deliverables - Configuration invariant set and combination matrix Rollout and recovery: Evaluate current environment fixtures and resolve all violations before enforcement. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-105 — Require expiry and ownership for emergency feature overrides **Task · High priority · Advanced** noCV practice brief v5 · DENV-105 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DENV-101, DENV-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A disable-delivery flag added during a rehearsal remains set for weeks because its reason and owner exist only in chat. Acceptance criteria - Override records owner, reason, scope, creation, and expiry - Expired override fails compilation instead of remaining active - Normal configuration remains visible beneath the override Implementation constraints - Use synthetic operator identities; flags do not bypass authorization or audit. Verification - Apply an active scoped override and show its provenance. - Compile expired and ownerless overrides and confirm blocking errors. Deliverables - Expiring override registry and policy tests Rollout and recovery: Introduce reporting before rejecting legacy unowned fixture flags. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-106 — Promote configuration by immutable revision **Bug · High priority · Advanced** noCV practice brief v5 · DENV-106 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DENV-103, DENV-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Security 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 mutable environment file changes after approval but before deployment, so the applied settings were never reviewed. Acceptance criteria - Compilation produces canonical content and immutable revision hash - Approval and deployment bind the exact revision - Any source-layer change produces a new revision Implementation constraints - Exclude secret values while binding secret reference identities and schema version. Verification - Approve and deploy one unchanged revision. - Edit a source layer after approval and verify deployment refuses the stale authorization. Deliverables - Immutable configuration revision and approval-binding tests Rollout and recovery: Use revision identities in the local deployment simulator before removing mutable file reads. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-107 — Resolve secret rotation without restarting into a mixed revision **Story · High priority · Expert** noCV practice brief v5 · DENV-107 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DENV-103, DENV-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 65% · Security 35%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two secret references rotate independently while workers reload, leaving some requests signed with mismatched key and certificate versions. Acceptance criteria - Dependent secret references resolve as one declared bundle revision - Reload publishes only a fully validated immutable snapshot - In-flight work retains its starting snapshot until completion Implementation constraints - Fake secret material stays inside the local adapter and is never included in generic configuration hashes. Verification - Rotate a complete bundle while old and new operations overlap. - Withhold one member and confirm no worker selects the partial revision. Deliverables - Secret-bundle reload protocol and overlap test Rollout and recovery: Keep restart-based rotation available until snapshot reload is proven. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DENV-108 — Detect environment drift without copying secret data **Chore · High priority · Advanced** noCV practice brief v5 · DENV-108 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DENV-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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. A local environment's retry count is changed outside the compiler, but drift reports are disabled because teams fear dumping secrets. Acceptance criteria - Compare ordinary canonical values and secret reference identities - Report missing, extra, and changed paths with provenance - Secret values and provider error bodies are never serialized Implementation constraints - Observed configuration comes from a bounded fake runtime projection. Verification - Detect changes in an ordinary value and a secret reference version. - Return a sentinel secret in observed input and prove it cannot enter the report. Deliverables - Redacted drift detector and fixture report Rollout and recovery: Begin in read-only mode and resolve unexplained differences before automation. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-109 — Roll back configuration without rolling back application code **Task · High priority · Expert** noCV practice brief v5 · DENV-109 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DENV-106, DENV-107, DENV-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A new timeout revision overloads the fake provider, but the only recovery script redeploys the entire previous application artifact. Acceptance criteria - Rollback selects a prior compatible configuration revision - Compatibility is checked against the current application contract - History retains failed and restored revisions plus observed outcome Implementation constraints - Rollback never mutates a historical revision or reuses its approval for another environment. Verification - Deploy a bad timeout revision and restore the prior compatible configuration. - Choose a revision requiring an older schema and block rollback with an actionable result. Deliverables - Configuration rollback command and recovery rehearsal Rollout and recovery: Maintain one known-compatible revision for each simulated environment. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. #### DENV-110 — Publish the environment contract for service owners **Bug · Medium priority · Intermediate** noCV practice brief v5 · DENV-110 · Keep environment configuration explicit and recoverable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DENV-105, DENV-108, DENV-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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. New owners know variable names but not which settings can change independently, which require restart, or how failure appears. Acceptance criteria - Reference lists type, source, default, sensitivity, reload behavior, and owner - Cross-field invariants and rollback compatibility are linked - Examples use synthetic values and secret references only Implementation constraints - Generated reference comes from the same schema used by validation. Verification - Generate and review documentation for every current field. - Add an undocumented schema field and make the consistency test fail. Deliverables - Generated environment reference and owner runbook Rollout and recovery: Require schema and documentation consistency in CI. Project prerequisites: Configuration precedence Schema validation Least privilege Engineer value: Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback. Company value: Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings. 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. ## DART — Build an artifact path that can defend what it publishes A fictional command-line product publishes local package archives. Builds contain timestamps, checksums are copied without provenance, and cleanup can delete the only rollback artifact. Use generated source trees, ephemeral development signing keys, and local object storage; no public registry or production key is supplied. **Field:** DevOps. **Suggested stack:** TypeScript, Tar, S3-compatible adapter, Ephemeral signing provider. **Engineer value:** Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. **Company value:** Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Content hashing - Archive formats - Release metadata ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DART-101 — Make archive bytes reproducible from the same source manifest **Task · Medium priority · Foundational** noCV practice brief v5 · DART-101 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Security 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. Two builds from identical fixtures differ because archive order, timestamps, ownership, and path separators come from the host. Acceptance criteria - Sort entries by canonical relative path - Normalize declared timestamps, ownership, permissions, and separators - Reject paths escaping or colliding after normalization Implementation constraints - Use generated files only and do not archive the repository working tree. Verification - Build twice in different temporary roots and compare byte digests. - Add traversal and normalization-collision paths and confirm rejection. Deliverables - Deterministic archive writer and reproducibility tests Rollout and recovery: Publish reproducibility metadata before replacing the current archive path. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-102 — Generate a dependency inventory from resolved inputs **Bug · Medium priority · Foundational** noCV practice brief v5 · DART-102 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DART-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The package manifest lists declared ranges, not the exact dependency versions bundled into the archive. Acceptance criteria - Inventory records exact package, version, integrity, and relationship - Generation uses the resolved lock and packaged output - Unknown or duplicate identities fail the release gate Implementation constraints - Do not contact public vulnerability or package services in the exercise. Verification - Generate a stable inventory for the fixture lockfile. - Remove an integrity entry and add a duplicate package identity, then block publication. Deliverables - Dependency inventory generator and malformed-lock tests Rollout and recovery: Attach inventory to local artifacts before enforcing completeness. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-103 — Bind provenance to source, builder, and exact artifact **Story · Medium priority · Intermediate** noCV practice brief v5 · DART-103 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DART-101, DART-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A provenance file names a commit but is copied beside a different archive without detection. Acceptance criteria - Statement binds artifact digest, source revision, build recipe, and builder identity - Verification recomputes the artifact digest - Unknown statement fields are preserved or rejected by version policy Implementation constraints - Builder identity is a synthetic workload identity, not a person or authorship claim. Verification - Verify the matching artifact and statement. - Swap artifact and source identities independently and confirm failure. Deliverables - Versioned provenance statement and verifier Rollout and recovery: Require verified provenance for a single fixture channel first. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DART-104 — Keep signing keys outside the build workspace **Chore · Medium priority · Intermediate** noCV practice brief v5 · DART-104 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Security 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 build job receives an exportable private key file that any build script could read or include in the archive. Acceptance criteria - Build produces an unsigned digest and signing request - Signing provider accepts only authorized artifact metadata - Private key bytes never enter workspace, logs, or artifacts Implementation constraints - Use ephemeral local keys behind a provider interface; production key management remains unprovisioned. Verification - Sign and verify an authorized fixture artifact. - Search outputs for a sentinel key and reject an unauthorized digest request. Deliverables - Signing-provider boundary and leak tests Rollout and recovery: Keep unsigned artifacts nonpromotable while the development signer is enabled. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-105 — Promote only artifacts whose evidence set reconciles **Task · High priority · Advanced** noCV practice brief v5 · DART-105 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-102, DART-103, DART-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A package is promoted after signature verification even though its inventory belongs to an earlier build. Acceptance criteria - Gate binds artifact, provenance, inventory, signature, and policy versions - Every component references the same artifact digest - Missing or conflicting metadata blocks promotion with exact reasons Implementation constraints - This verifies release metadata, not candidate Outcome Evidence or ownership. Verification - Promote one complete matching fixture set. - Mix inventory, signature, and provenance from neighboring builds and reject each case. Deliverables - Artifact evidence-set gate and mismatch matrix Rollout and recovery: Run the gate in report-only mode before making it mandatory. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-106 — Prevent a mutable channel from changing an approved artifact **Bug · High priority · Advanced** noCV practice brief v5 · DART-106 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · 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 beta channel is approved while pointing to one digest, then its mutable object is overwritten before clients resolve it. Acceptance criteria - Approval binds channel, digest, and revision - Channel update uses compare-and-set against observed revision - Clients can resolve historical channel revisions Implementation constraints - Channel is discovery metadata; the artifact remains content addressed and immutable. Verification - Advance beta from one approved digest to another. - Race two channel updates and verify only one wins without overwriting history. Deliverables - Versioned channel pointer and concurrency test Rollout and recovery: Enable one nondefault fixture channel before broader use. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-107 — Revoke a compromised signing identity without deleting history **Story · High priority · Expert** noCV practice brief v5 · DART-107 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DART-104, DART-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 65% · Security 35%. 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 development signing key is declared compromised, and the cleanup proposal deletes every artifact it signed, including investigation records. Acceptance criteria - Revocation records key identity, effective scope, time, and reason - Verification distinguishes signed-before, signed-after, and explicitly revoked artifacts - Historical metadata remains inspectable and immutable Implementation constraints - Use ephemeral fixture keys; do not claim real-world trust without a provisioned signer and policy. Verification - Verify artifacts on both sides of a declared rotation under policy. - Present an artifact signed after compromise and confirm promotion denial without deletion. Deliverables - Signing revocation policy and temporal tests Rollout and recovery: Block new promotion first, then review already promoted fixture artifacts. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DART-108 — Retain rollback artifacts while bounding storage growth **Chore · High priority · Advanced** noCV practice brief v5 · DART-108 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-105, DART-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Storage systems 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. Age-only cleanup removes the last compatible rollback artifact for a supported release line. Acceptance criteria - Retention protects active, rollback, held, and investigation-referenced digests - Deletion plan is deterministic and reviewable before mutation - Partial deletion resumes by immutable digest Implementation constraints - Use local object storage and synthetic artifact bytes; never delete undeclared objects. Verification - Plan and execute cleanup while retaining every protected digest. - Interrupt halfway and replay; add an unknown reference and keep it unresolved. Deliverables - Artifact retention planner and interrupted cleanup drill Rollout and recovery: Run plan-only mode before enabling scoped fixture deletion. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-109 — Recover publication after object storage acknowledges late **Task · High priority · Expert** noCV practice brief v5 · DART-109 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-103, DART-105, DART-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Storage 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 object store commits an archive but the upload times out; retry creates a differently named duplicate and publishes only one metadata set. Acceptance criteria - Object key derives from verified content digest - Retry reconciles size, digest, and metadata before upload - Conflicting existing content is quarantined and never overwritten Implementation constraints - Treat storage metadata as untrusted until content identity is verified. Verification - Upload and replay an identical artifact idempotently. - Lose the response after commit and preplace conflicting bytes under the expected key. Deliverables - Content-addressed publisher and ambiguous-upload tests Rollout and recovery: Enable for one artifact class while retaining the prior publisher for rollback. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. #### DART-110 — Rehearse artifact compromise from block to recovery **Bug · Medium priority · Intermediate** noCV practice brief v5 · DART-110 · Build an artifact path that can defend what it publishes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DART-107, DART-108, DART-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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 response plan says rotate and rebuild but does not identify affected channels, compatible rollback artifacts, or how clients learn the block. Acceptance criteria - Runbook traces key, artifact, channel, environment, and consumer relationships - Rehearsal blocks promotion and selects a verified compatible artifact - Recovery publishes a new identity without rewriting compromised history Implementation constraints - The scenario uses fictional artifacts and ephemeral keys only. Verification - Complete a synthetic compromise and restore a safe channel. - Remove the expected rollback artifact and follow the documented blocked path. Deliverables - Artifact incident runbook and tabletop transcript Rollout and recovery: Review findings before treating the workflow as ready for an external registry. Project prerequisites: Content hashing Archive formats Release metadata Engineer value: Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety. Company value: Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names. 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. ## DDEV — Make local development reproducible without hiding dependencies A fictional support portal requires a database, cache, object store, and mail catcher. Setup lives in personal notes, reset scripts sometimes target shared resources, and offline work fails after package caches are cleared. Build a local-only development contract with synthetic data; no shared staging system or production credentials are supplied. **Field:** DevOps. **Suggested stack:** TypeScript, Containers, PowerShell and POSIX shell, Local services. **Engineer value:** Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. **Company value:** Reduce onboarding and support cost while making local dependencies and destructive operations explicit. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Environment variables - Service health - Database migrations ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DDEV-101 — Turn the setup notes into one preflight report **Task · Medium priority · Foundational** noCV practice brief v5 · DDEV-101 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 new developer follows six documents and reaches application startup before learning that the required runtime version is unsupported. Acceptance criteria - Preflight checks runtime, package manager, container engine, ports, and required files - Each result says detected, required, and remediation - Checks are read-only and return one aggregate status Implementation constraints - Do not install software or change host settings from preflight. Verification - Run against a complete declared fixture environment. - Simulate multiple missing dependencies and report all of them in one pass. Deliverables - Read-only preflight command and environment fixtures Rollout and recovery: Link preflight from the existing setup guide before removing manual checks. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-102 — Start local services only after validating port ownership **Bug · Medium priority · Foundational** noCV practice brief v5 · DDEV-102 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DDEV-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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. Bootstrap sees a port in use and assumes the expected database is running, but the listener belongs to another application. Acceptance criteria - Readiness validates protocol and fixture service identity - Port collision names the port without terminating the owner - Bootstrap records which processes or containers it started Implementation constraints - Never kill an unknown process or bind beyond loopback in this exercise. Verification - Reuse a healthy owned fixture service and start a missing one. - Place an unrelated listener on the port and fail with remediation. Deliverables - Service identity probes and collision tests Rollout and recovery: Require identity checks before automated startup. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-103 — Apply migrations exactly once during concurrent bootstrap **Story · Medium priority · Intermediate** noCV practice brief v5 · DDEV-103 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DDEV-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Database 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. Two local application processes start together and both run the same migration, leaving one failed and the schema state unclear. Acceptance criteria - Migration ownership uses the database-supported lock - Waiters observe the final applied version - Failure leaves the migration retryable and visible Implementation constraints - Use migrations; do not replace the workflow with schema push. Verification - Start two bootstrap processes against an empty fixture database. - Interrupt the migration owner and verify a later run can safely resolve state. Deliverables - Migration coordination and concurrent-start test Rollout and recovery: Keep manual migration available until the bootstrap path is repeatable. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DDEV-104 — Seed deterministic accounts without creating duplicates **Chore · Medium priority · Intermediate** noCV practice brief v5 · DDEV-104 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Database 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. Every bootstrap appends another demo organization and screenshots depend on whichever duplicate is returned first. Acceptance criteria - Seed identities are stable and unique - Repeated seed reconciles declared values idempotently - User-owned local additions remain untouched Implementation constraints - Synthetic fixtures must be clearly labeled and never selected outside local Demo mode. Verification - Seed twice and compare identities, counts, and relations. - Change one fixture revision and verify an intentional update without duplicate rows. Deliverables - Versioned seed reconciler and repeat-run tests Rollout and recovery: Require explicit local Demo mode before seeding. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-105 — Reset only resources created by this workspace **Task · High priority · Advanced** noCV practice brief v5 · DDEV-105 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-102, DDEV-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A cleanup command deletes every container with a generic project label, including another checkout's database. Acceptance criteria - Workspace identity is stable, explicit, and included on owned resources - Reset previews exact absolute targets and service identities - Foreign and ambiguous resources are refused Implementation constraints - The command operates only on generated local fixtures and requires an explicit reset flag. Verification - Preview and reset one isolated fixture workspace. - Add a second workspace and an ambiguous unlabeled resource, then prove both survive. Deliverables - Scoped reset command and cross-workspace safety tests Rollout and recovery: Ship preview-only first and document recovery limits. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-106 — Report readiness by dependency instead of waiting blindly **Bug · High priority · Advanced** noCV practice brief v5 · DDEV-106 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-102, DDEV-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Bootstrap sleeps thirty seconds, then starts the application even if object storage is still initializing or the database failed permanently. Acceptance criteria - Each dependency has a bounded identity-aware readiness probe - Transient and terminal failures have separate retry behavior - Overall report shows ready, waiting, failed, and skipped dependencies Implementation constraints - Use injected time and local probes; fixed sleep is not readiness. Verification - Start dependencies with staggered readiness and complete when all required services pass. - Return a permanent schema error and stop retrying with an actionable report. Deliverables - Dependency readiness graph and timing tests Rollout and recovery: Display reports beside the existing startup path before enforcing them. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-107 — Support an offline bootstrap from a verified local cache **Story · High priority · Expert** noCV practice brief v5 · DDEV-107 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-101, DDEV-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Developers lose network access during an incident rehearsal and bootstrap cannot tell which packages and service images are already available locally. Acceptance criteria - Offline manifest lists exact package and image digests - Bootstrap verifies every cached artifact before use - Missing items produce a complete acquisition list without partial startup Implementation constraints - Do not bypass integrity checks or contact a network when offline mode is selected. Verification - Bootstrap from a complete verified cache with network access denied. - Remove and corrupt separate artifacts and report both before starting services. Deliverables - Offline manifest, verifier, and disconnected tests Rollout and recovery: Treat offline support as explicit mode with a generated cache preparation step. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DDEV-108 — Keep Windows and POSIX commands behaviorally equivalent **Chore · High priority · Advanced** noCV practice brief v5 · DDEV-108 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-101, DDEV-105, DDEV-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 PowerShell reset resolves symlinks differently from the POSIX script and deletes a fixture path the other implementation refuses. Acceptance criteria - Both entry points call one typed cross-platform core - Path, quoting, exit status, and signal differences have contract tests - Unsupported platform behavior fails visibly Implementation constraints - Tests use temporary directories and do not invoke destructive commands through another shell. Verification - Run the shared fixture matrix through both thin entry points. - Use paths with spaces, links, and metacharacters and compare safe outcomes. Deliverables - Cross-platform command core and parity report Rollout and recovery: Keep platform scripts as wrappers and review every behavioral difference. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-109 — Diagnose local startup without collecting source or secrets **Task · High priority · Expert** noCV practice brief v5 · DDEV-109 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-106, DDEV-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A support bundle recursively archives the workspace to explain startup failures, capturing source files and environment secrets. Acceptance criteria - Bundle allowlist contains tool versions, bounded health results, safe config identities, and recent bootstrap events - Source, environment values, tokens, database rows, and payload logs are excluded - User previews exact included files and fields Implementation constraints - Use sentinel secrets and synthetic source fixtures to prove exclusion. Verification - Generate a useful bundle for a failed readiness probe. - Place sentinels in every prohibited source and confirm none appear in archive bytes. Deliverables - Redacted support bundle and leak regression suite Rollout and recovery: Keep bundle generation local and user initiated. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-110 — Prove onboarding from a clean machine profile **Bug · Medium priority · Intermediate** noCV practice brief v5 · DDEV-110 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-104, DDEV-107, DDEV-108, DDEV-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 setup succeeds only on long-lived developer machines that already contain undeclared packages and cached service state. Acceptance criteria - Test starts from a declared clean profile with empty workspace-owned state - Online and prepared-offline paths produce the same fixture application behavior - Duration report separates downloads, builds, migrations, seeds, and readiness Implementation constraints - The profile is a local disposable fixture, not a production host image. Verification - Complete onboarding twice from clean profiles and compare outcomes. - Remove one declared prerequisite and verify preflight fails before mutation. Deliverables - Clean-profile onboarding rehearsal and timing report Rollout and recovery: Use the rehearsal in documentation review before changing team onboarding policy. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. ## DPREVIEW — Create review environments that clean themselves up A fictional product team creates local preview environments for pull requests. Names collide, fixtures copy more data than needed, failed provisioning leaks resources, and merged changes leave previews running. Build an infrastructure simulator with fake DNS, storage, and deployment providers; no cloud account or live domain is supplied. **Field:** DevOps. **Suggested stack:** TypeScript, Infrastructure model, Fake DNS, Queue adapter. **Engineer value:** Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. **Company value:** Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Resource graphs - Idempotency - Tenant isolation ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DPREVIEW-101 — Derive a collision-resistant preview identity **Task · Medium priority · Foundational** noCV practice brief v5 · DPREVIEW-101 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Cloud infrastructure 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. Two repositories both open pull request 42 and receive the same environment name, causing one preview to replace the other. Acceptance criteria - Identity binds repository, immutable revision, and pull-request identity - Human-readable alias maps to one immutable environment ID - Length and character limits are enforced before provider calls Implementation constraints - Do not use branch text as the sole authority or resource identity. Verification - Create previews for same-number requests in two repositories. - Use oversized and normalization-colliding names and confirm no resource mutation. Deliverables - Preview identity contract and collision tests Rollout and recovery: Adopt IDs in state first while retaining old aliases for display. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-102 — Compile a minimal preview configuration **Bug · Medium priority · Foundational** noCV practice brief v5 · DPREVIEW-102 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DPREVIEW-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Preview inherits production-like integrations and tries to send fixture events to undeclared external endpoints. Acceptance criteria - Preview configuration selects only fake or explicitly allowed providers - Network policy defaults to deny and lists required local dependencies - Secrets are references to preview-scoped fixtures Implementation constraints - No production credential, customer data, or public callback is permitted. Verification - Compile a preview using only declared fake providers. - Reference an external endpoint and a production-like secret scope, then block compilation. Deliverables - Preview configuration policy and denial tests Rollout and recovery: Require policy compilation before any resource plan. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-103 — Plan the resource graph before creating anything **Story · Medium priority · Intermediate** noCV practice brief v5 · DPREVIEW-103 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DPREVIEW-101, DPREVIEW-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Cloud infrastructure 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. Provisioning creates storage before discovering the requested database class exceeds the preview quota, leaving an orphan. Acceptance criteria - Plan resolves complete dependency graph and quota cost - Validation lists every blocking reason before mutation - Plan has immutable revision used by apply Implementation constraints - Fake provider discovery is read-only and bounded. Verification - Plan a valid preview and reconcile its declared resource order. - Exceed compute and storage quotas together and confirm zero creates. Deliverables - Preview planner and multi-error quota tests Rollout and recovery: Expose plan-only operation before apply is enabled. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. ### Control change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DPREVIEW-104 — Apply preview resources idempotently after interruption **Chore · Medium priority · Intermediate** noCV practice brief v5 · DPREVIEW-104 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DPREVIEW-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Distributed systems 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. Provisioning stops after database creation. Retry creates a second database because local state was not saved before the provider call. Acceptance criteria - Each resource has deterministic operation identity - Apply reconciles provider state before create - Completed resources resume without recreating or skipping dependencies Implementation constraints - Provider calls execute outside state transactions and return untrusted observations. Verification - Apply a complete plan and replay it without changes. - Interrupt after one accepted create and confirm retry adopts the matching resource. Deliverables - Idempotent preview applier and interruption drill Rollout and recovery: Limit concurrent previews while reconciliation behavior is observed. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-105 — Seed representative data without copying customer records **Task · High priority · Advanced** noCV practice brief v5 · DPREVIEW-105 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DPREVIEW-102, DPREVIEW-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A convenient preview script proposes copying a small slice of the production-like database, including free-text notes. Acceptance criteria - Seed generator produces synthetic entities matching declared schema constraints - Relationships and edge cases are deterministic from a versioned seed - No source connector for customer data exists in preview composition Implementation constraints - Do not claim synthetic distributions reproduce real customer behavior. Verification - Seed two previews with the same revision and compare logical fixtures. - Attempt to configure an undeclared source connector and fail before data access. Deliverables - Synthetic preview seeder and schema-edge fixtures Rollout and recovery: Review fixture usefulness separately from data-safety enforcement. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-106 — Publish the preview URL only after identity-aware readiness **Bug · High priority · Advanced** noCV practice brief v5 · DPREVIEW-106 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DPREVIEW-104, DPREVIEW-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. The bot posts a URL when the load balancer responds, but it points to an older preview that still owns the recycled alias. Acceptance criteria - Readiness proves environment ID, revision, schema, and seed version - URL publication compares alias ownership immediately before update - Failure remains pending or failed with exact dependency status Implementation constraints - Use fake DNS and loopback probes; no public record is created. Verification - Publish a ready matching preview alias. - Return healthy content from an older environment and block publication. Deliverables - Identity-aware readiness gate and stale-alias test Rollout and recovery: Show URLs only after the new gate succeeds. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-107 — Enforce preview quotas across concurrent requests **Story · High priority · Expert** noCV practice brief v5 · DPREVIEW-107 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DPREVIEW-103, DPREVIEW-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Distributed systems 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. Two valid plans each fit the remaining quota, then apply concurrently and exceed the team limit together. Acceptance criteria - Quota reservation and environment admission are atomic - Expired reservations are reclaimed through identity-checked leases - Provider failure releases or reconciles reservation deterministically Implementation constraints - Do not hold a database transaction open across provider operations. Verification - Admit concurrent plans whose combined cost fits exactly. - Race two plans over the limit and verify only one obtains authority to apply. Deliverables - Quota reservation protocol and concurrency tests Rollout and recovery: Start with conservative team quotas and visible denials. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DPREVIEW-108 — Expire previews without deleting an active replacement **Chore · High priority · Advanced** noCV practice brief v5 · DPREVIEW-108 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DPREVIEW-101, DPREVIEW-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Cloud infrastructure 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 delayed cleanup job for an old preview alias deletes storage now owned by a newer environment. Acceptance criteria - Cleanup binds immutable environment and resource identities - Deletion compares current provider ownership before action - Alias reuse cannot transfer cleanup authority Implementation constraints - Use fake providers and delete only resources returned by the scoped plan. Verification - Expire one environment and remove exactly its resource graph. - Reuse its alias for a new environment before delayed cleanup and confirm new resources survive. Deliverables - Fenced expiry job and alias-reuse regression Rollout and recovery: Run cleanup in report-only mode before enabling deletions. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-109 — Resume partial preview deletion without losing unresolved resources **Task · High priority · Expert** noCV practice brief v5 · DPREVIEW-109 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DPREVIEW-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. DNS deletion succeeds, storage deletion times out after acceptance, and the environment is marked deleted despite an unknown storage outcome. Acceptance criteria - Deletion tracks each resource as pending, deleted, absent, failed, or unknown - Retry reconciles unknown provider state before mutation - Environment closes only when every resource reaches a resolved terminal state Implementation constraints - Unknown does not equal absent; provider responses remain untrusted until identity reconciliation. Verification - Delete a full graph and replay the job idempotently. - Lose a storage-delete response and confirm the environment remains visibly unresolved. Deliverables - Deletion state machine and partial-failure drill Rollout and recovery: Alert on aged unresolved cleanup rather than hiding it. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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. #### DPREVIEW-110 — Report preview value and cost without vanity counts **Bug · Medium priority · Intermediate** noCV practice brief v5 · DPREVIEW-110 · Create review environments that clean themselves up Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DPREVIEW-106, DPREVIEW-107, DPREVIEW-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A dashboard celebrates total previews created while ignoring failed readiness, time-to-review, idle duration, and leaked resources. Acceptance criteria - Report creation-to-ready time, ready duration, cleanup latency, failures, and declared resource cost - Metrics use bounded repository and outcome dimensions - Unresolved deletion remains included until reconciled Implementation constraints - Do not infer developer productivity or individual performance from preview usage. Verification - Reconcile a mixed fixture cohort from request through deletion. - Omit cleanup observations and confirm the report shows incomplete cost and lifecycle data. Deliverables - Preview lifecycle report and interpretation guide Rollout and recovery: Use the report to tune lifecycle policy, not rank people. Project prerequisites: Resource graphs Idempotency Tenant isolation Engineer value: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation. Company value: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure. 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.