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