# 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. ## 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.