# Tasks Implementation was requested after the user approved the four summarized review groups. P1–P6, F1–F7 and concrete D1 are approved; see the dated design.md record. Do not request repeated approval for accepted scope. D2 nullable system actor is approved in scheduler-actor-review.md. Application deployment remains separately instructed. ## 1. Review checkpoints - [x] 1.1 Present P1–P6 as the proposed MVP policy package and record accepted/rejected decisions in design.md; verify explicit user responses before dependent behavior is implemented and revise specs if rejected. - [x] 1.2 Present F1–F7 with exact affected components, before/after behavior and rationale; verify individual or explicitly grouped approval before modifying existing frontend files. - [x] 1.3 Prepare concrete D1 schema/migration/ERD review material in planning artifacts, obtain database-design approval or an approved equivalent, and verify the chosen persistence strategy satisfies stale-write and retry scenarios before code changes. ## 2. Persistence and shared API foundation - [x] 2.1 After D1 approval implement only the approved additive persistence changes; verify isolated migration preserves existing WOs, report links and stock history, regenerate client and update schema-design.md. - [x] 2.2 Implement guarded transactional mutations and stored replay for Maintenance; verify duplicate retries, mismatched key payloads, actor isolation and stale writes with isolated tests; document the request contract. - [x] 2.3 Extend explicit shared WO/case/plan/calendar DTOs compatibly; verify old Pilot Plant consumer fields and response-envelope contract tests; document new fields in OpenAPI. ## 3. Work Order API - [x] 3.1 Extend list/detail, filtered summary and target lookups without technician lookup/filter; verify pagination, roles, search, target identity and release-time filters with API tests and document parameters. - [x] 3.2 Implement manual Pilot Plant creation and guarded note/metadata edits without technician assignment; verify actor attribution, shared execution by active technicians, archived targets, inactive actors and retries; update OpenAPI. - [x] 3.3 Implement start/complete/cancel with report synchronization, history and audit; verify allowed/denied transitions, concurrent actions, atomic rollback and unresolved cancellation scenarios; document lifecycle. ## 4. Quarantine review and handoff - [x] 4.1 Extend case queue/detail filters and linked-WO summaries; verify date boundaries, remaining quantities and role visibility; document read contracts. - [x] 4.2 Implement manual case-to-WO creation with part-first locking and approved active-order policy; verify two-reviewer races, replay, closed-case rejection and preserved reporter attribution. - [x] 4.3 Coordinate repair start, release/scrap and reversal paths using the approved disposition policy; verify partial/mixed outcomes and races cannot leave active repair on unavailable quantities; document guards in Inventory behavior docs. - [x] 4.4 Add quarantine.service.ts using existing Inventory operations and the new handoff, plus review page/detail/actions; verify loading/error/empty states, role visibility, reason/quantity validation and replay-safe actions in frontend tests. - [x] 4.5 After F6 approval wire protected route/menu and WO links; verify navigation from Inventory to case to Maintenance with a browser walkthrough. ## 5. Work-order sparepart usage - [x] 5.1 Implement privileged WO issues/returns using shared stock posting and no independent usage total; verify available-stock competition, net return limits, retry and cancellation-with-consumption scenarios; document distinction from public checkout. - [x] 5.2 Add usage read model and movement references with reversal-aware totals; verify corrections refresh consumption and no costs or checkout associations leak into DTOs. - [x] 5.3 After F4 approval integrate notes and usage actions in detail; verify real catalogue, role restrictions and replacement of local deletion by explicit correction, including failed/uncertain requests. ## 6. Plans, calendar and calibration - [x] 6.1 Implement plan create/read/edit/pause with approved edit restrictions and active target checks; verify invalid ranges/cycles and edits after generation; document plan API. - [x] 6.2 Implement recurrence and bounded read-only calendar projection merged with actual WOs; verify month-end/leap-day/timezone cases, independent completion and no writes on GET; document range limits. - [x] 6.3 Add scheduled generator command with transactional occurrence uniqueness and catch-up cursor; verify parallel/restarted runs, ONCE, pause and downtime fixtures; document recurring invocation, batch sizing and failure monitoring. - [x] 6.4 Implement approved structured calibration completion and new form component; verify same-target relation, required result, next-date validation and atomic completion/replay; document certificate-upload exclusion. - [x] 6.5 After F5 approval integrate existing PM form/calendar with service endpoints; verify projected versus actual navigation and independent recurring work in frontend tests. ## 7. Maintenance consumer integration - [x] 7.1 Add maintenance.service.ts matching the API contracts; verify filter serialization, paging, errors, cancellation and stable mutation keys in service tests. - [x] 7.2 After F1/F2 approval connect existing queue/create form with API data and identity selectors while preserving layout; verify persistence after reload and inclusion of accepted Pilot Plant WOs. - [x] 7.3 Remove technician assignment input/display as approved; after F3 approval connect valid status actions and completion/cancellation forms with server state; verify shared technician access, attributed history, derived scheduled/overdue display and terminal restrictions. - [x] 7.4 Preserve existing Pilot Plant read routes; implement only approved F7 navigation changes and verify old deep links still work with expanded DTOs. ## 8. Cross-feature verification and handoff - [x] 8.1 Run API/shared/frontend builds, typechecks, relevant lint, Swagger checks and isolated integration suites; record results and any existing unrelated failures in verification.md. - [x] 8.2 Verify browser journeys for report acceptance→WO completion, hold→review→repair→mixed disposition, usage→return/reversal, and scheduled occurrence→execution; document evidence without touching production data. - [x] 8.3 Deliver deployment instructions covering approved migration, scheduler setup, compatibility and rollback; verify commands against the isolated environment and leave application-database deployment pending explicit instruction. ## Workflow follow-up - Implementation was applied after the user's request and the applicable approvals; verification evidence is recorded in verification.md. - Archive only after implementation and required reviews are complete; do not archive unrelated changes.