# Maintenance verification

Verified on 2026-10-14 for the approved P1–P6, F1–F7, D1 and D2 scope. Database integration and browser fixtures use randomly named disposable databases. Application migration and scheduler activation were not performed.

## Build and contract checks

- API build, typecheck and compiled Swagger contract: passed.
- Shared package build and typecheck: passed.
- Frontend build (TypeScript and Vite): passed. Vite reports the existing large document-export/ExcelJS chunk warning; it does not fail the build.
- Relevant ESLint checks for Maintenance API/services/validators/tests and Maintenance/Quarantine frontend/services: passed. Checks were scoped to the feature, not an autofix of unrelated repository files.
- Prisma schema validation and client generation: passed. DTO/OpenAPI tests preserve Pilot Plant fields, response envelopes, nullable system history and absence of cost/checkout fields.
- API `npm.cmd test`: 19 files, 70 tests passed. Eight database suites are intentionally skipped by this command; isolated runners below execute guarded database suites.
- Frontend `npm.cmd test`: 8 files, 39 tests passed, including 4 Maintenance/Quarantine service tests for filters, paging, AbortSignal, structured writes, errors and stable request keys.

## Isolated API and migration evidence

`npm.cmd run test:maintenance`: 13 tests passed across maintenance.mysql.test.ts and maintenance-flows.mysql.test.ts. Coverage includes:

- Concurrent stored replay, changed payload/operation/actor, inactive account, stale version, required audit rollback and safe retry.
- Role restrictions, target identity/archive checks, list filters, release visibility, paging and summary counts.
- Shared technician execution, completion/cancellation races, report attribution/transitions, terminal restrictions and no automatic disposition.
- Concurrent quarantine handoff, remaining quantities, closed-case rejection, repair/disposition and reversal guards, partial and mixed outcomes.
- Stock competition, net returns, corrections, retry and retained consumption after cancellation.
- Same-target calibration, required results/dates, atomic completion/replay and audit-failure rollback.
- Plan restrictions/pause, bounded read-only calendar, independent occurrences, scheduler concurrency/restart/catch-up, archived targets, ONCE and system history.

The harness applies preceding migrations before inserting legacy fixtures. D1 preserves WorkOrder, MaintenancePlan, DamageReport, StockMovement and StockBalance values, initializes versions to zero and enforces request uniqueness/actor FK. D2 preserves human actor IDs, accepts null system actors and rejects invalid non-null actors. Disposable databases are removed in finally.

`node --env-file=.env prisma/verify-maintenance-regressions.cjs`: 45 tests passed (Inventory 22, reports 8, Pilot Plant 8, photos 4, seeder 3). Each suite receives a separate disposable database to avoid cross-suite count contamination.

`node --env-file=.env prisma/verify-maintenance-api.cjs --deploy-check`: actual Prisma CLI migrate deploy, migrate status, repeat migrate deploy, and scheduler CLI passed in an empty disposable database. All eight migrations applied, status was up to date, and repeat deploy found no pending migration. This verifies deployment commands without deploying the application database.

## Browser acceptance evidence

Build the browser fixture using `node test/build-pilot-browser.mjs` from apps/app, then run `node --env-file=.env prisma/verify-maintenance-api.cjs --browser` from apps/api. Chrome runs headless with a temporary profile and a local server connected only to the generated database. Windows requires permission to launch Chrome outside the restricted sandbox.

Seven journeys in maintenance-browser.mysql.test.ts cover:

1. Submit and accept a Pilot Plant report, follow its direct link to unified Maintenance, verify legacy queue/detail URLs redirect to that same page, execute as a technician, complete and reload persisted history/report state.
2. Hold inventory, review the case, create repair WO, complete, explicitly release three units and scrap two to CLOSED_MIXED. A lost handoff response retries the same request; quantity/reason validation remains enforced.
3. Post usage and return in WO detail, recover a lost return response without duplication, reverse the return through Stock Movement detail, then reload corrected net usage.
4. Open projected PM plan, generate its occurrence, display “Sistem” history and independently complete the actual WO.
5. Create a recurring plan through the form, edit/pause it, reopen it from the inactive list and resume without generating work on reads.
6. Create calibration work, reject invalid next-date completion without changing status, then complete with structured results and reload the saved certificate reference.
7. Simulate a lost creation response after commit, retry without duplicate WO, verify empty/error states and VIEWER controls for Maintenance and Quarantine.

Navigation waits use specific page/form readiness checks. An earlier broad quarantine-search input selector was corrected because it could target the previous document during navigation.

## Handoff

Navigation consolidation follow-up (2026-10-14): the user approved removing server-page.tsx and the read-only banner. Both Pilot Plant report links now open the unified detail, and protected legacy queue/detail URLs redirect with history replacement. Frontend typecheck, scoped lint, browser bundle build and test-file lint passed. The browser suite ran with 5 passed / 2 failed: the updated report/direct-link/legacy-redirect/execution journey passed, as did usage, scheduled work, PM editing and calibration. The two remaining tests timed out waiting for the old “Review Karantina” title; the independently updated Quarantine page now displays “Quarantine”. That page and those unrelated selectors were not changed by this navigation task. The earlier seven-journey record describes the prior implementation verification.

API behavior/request contract: src/services/maintenance.md. Deployment, scheduler frequency/batching/monitoring and non-destructive rollback: prisma/maintenance-deployment.md.

Follow-up deployment (2026-10-14): the user explicitly requested migration after checking the Prisma models and ERD. The models already contained D1/D2; schema-design.md was expanded to clarify the implemented Maintenance relations and policies. Prisma CLI applied `20261014000200_maintenance_work_orders` and `20261014000300_maintenance_system_actor` to `preventive_maintenance` at `localhost:3306`. Migration status is up to date, database-to-schema diff reports no difference, and Prisma Client was regenerated. The earlier isolated-test record above describes the pre-deployment verification.

Scheduler activation remains pending explicit instruction. The change has not been archived. No checkout, finance, location input or technician assignment has been added.