# Implementation verification

## Baseline prerequisite

- Core architecture tracked tasks: 17/17 complete.
- API: `npm.cmd test -- --reporter=dot` passed, 41 tests across 10 files.
- API: `npm.cmd run typecheck` passed.
- Shared: `node node_modules/typescript/bin/tsc -p ../../packages/shared/tsconfig.json --noEmit` passed.
- Frontend: `node ../app/node_modules/vitest/vitest.mjs run --root ../app --configLoader runner --no-cache --reporter=dot` passed, 12 tests across 2 files, including auth HTTP compatibility.
- Inspected shared ApiResponse types and frontend auth decoding against the implemented response envelope.
- Use the updated baseline's existing routes/controllers/services/validators layout and config/prisma.ts; do not introduce modules/http/infrastructure folders.

## Migration preflight

- Added `npm run prisma:preflight:pilot-plant`, fixed read-only SELECT checks and operator remediation documentation.
- Focused preflight tests: 3 passed; API typecheck passed.
- Ran against the configured database: all 9 checks returned zero findings, ready=true. No data changes or migration were performed by this check.

## Schema and migration rehearsal

- Prisma schema validation passed; generated Prisma Client 7.2.0 successfully; API typecheck passed after generation.
- Added migration `20261012000100_pilot_plant_api`; the original migration was not edited.
- `npm run test:migration:pilot-plant` passed on a fresh database and a populated database created exclusively for the rehearsal, then removed by the runner.
- Verified equipment/sub-item nameScopeId backfill, same name across different units, case-insensitive duplicate rejection in one scope, nullable report IDs on multiple WOs, unique non-null report linkage, ACCEPTED status and reviewer foreign key, and preservation of complaint text.
- The configured application database has not been migrated. Generated client/schema changes require deployment of the new migration before using the new model fields.

## Documentation and next dependency

- Updated prisma/schema-design.md with backfill, preserved fields/history, version checks, review lifecycle, preflight/rehearsal operations, and non-atomic MySQL DDL handling.
- Original migration SHA256 remains `2D9AE8EB8720934B4A44766D46F507D7A3849D9DAF424EEDB13FA8DE80DE2BA6` before/after this documentation task.
- OpenSpec strict validation passed.
- Next task 2.1 requires writing public DTOs under packages/shared. Current session's writable root is apps/api only; frontend/shared remain outside that scope. Do not create duplicate API-local public contracts or mark companion work complete. Continue from a workspace with monorepo write access.

## Hierarchy implementation (resumed from monorepo root)

- Companion workspace restriction is resolved: this session is rooted at the monorepo. Added public asset, condition, report, and read-only work-order DTOs in packages/shared; report/WO endpoints remain pending.
- Implemented tasks 2.1-2.4 using existing routes/controllers/services/validators/config folders.
- Added authenticated hierarchy create/read/rename routes, role and Origin checks, strict field validation, server-generated codes, transactional audit, database-collation uniqueness, and optimistic version checks.
- Added bounded hierarchy search/pagination, global distinct-equipment counts, active-report projection, archived exclusions, and facility-timezone due-today handling.
- Real isolated MySQL verification: 8/8 tests passed. Includes authenticated HTTP behavior, concurrent case-insensitive duplicate creation, concurrent stale updates, unchanged audit count on failed edit, descendant search, empty categories, ACCEPTED conditions, unreleased WO exclusion, archived children, query count comparison and EXPLAIN.
- Regular API suite: 46 passed, 7 isolated-database cases deliberately skipped. Those 7 cases plus the date-projection test pass under the isolated runner. The guard prevents accidental use of the application database.
- Frontend regression: 12 passed. All workspace typechecks and builds passed; final API typecheck/build/tests and compiled Swagger passed after OpenAPI updates.
- Query evidence and run instructions: prisma/pilot-plant-queries.md. Query plans use fixture cardinalities and do not claim production-scale performance.
- The configured application database remains unmigrated and unchanged. Only randomly created isolated databases were used and removed.
- Task 3.1 is blocked before photo implementation: online installation failed with ERR_PNPM_META_FETCH_FAIL for registry.npmjs.org/multer; offline installation failed with ERR_PNPM_NO_OFFLINE_META. No Multer/Sharp dependency was installed or claimed complete.
- Current Multer and Sharp documentation was reviewed through Context7. Resume by making dependencies available, then implement bounded multipart decoding/storage and the remaining photo, review, consumer, and release tasks.
- Frontend Pilot Plant still uses its existing browser-local implementation; consumer migration is not yet delivered. Do not release this partial slice as the full Pilot Plant feature.

## Photos, report review and consumer implementation

- Multer 2.4.0, Sharp 0.35.5 and @types/multer 2.3.0 are now installed by the user. Sharp decoding/encoding was smoke-tested successfully.
- Completed tasks 3.1-3.3: bounded multipart parsing; actual JPEG/PNG/WebP validation and WebP reencoding; 2 MiB/20-million-pixel limits; private persistent adapter; authenticated reads; versioned replacement/removal and atomic audit; safe orphan cleanup with reference checks, 24-hour grace and persistent staging markers.
- Photo storage tests: 4 passed. Real MySQL photo HTTP/failure tests: 4 passed. Tests cover both unit and asset routes, role/Origin denials, spoofing, size limits, byte headers, stale versions and rollback preserving the previous photo. Adapter reconstruction reads the same durable bytes.
- Completed tasks 4.1-4.5 and 5.1: attributed reports, reviewer filters, transactional Accept/Dismiss with normalized replay, Maintenance-owned WO creation in the caller transaction, safe read-only WO DTOs, per-user limits and OpenAPI.
- Review MySQL tests: 8 passed, including simultaneous Accept, Accept/Dismiss race, changed input, identical replay, one lifetime WO/history/audit, cancellation conflict, and final-audit failure through an isolated MySQL trigger. Failure rolls back report and WO changes.
- Frontend implementation is present for tasks 5.2-5.4: API-backed paginated navigation, server condition chart, stable-ID forms, separate photo mutations, report submission/review, read-only persisted Maintenance routes, explicit demo separation, input-preserving error handling and shared query invalidation.
- Frontend tasks 5.2-5.4 remain unchecked pending browser interaction verification. They are not claimed delivered merely because the code compiles.
- Added consumer-migration.md (task 5.5) describing local-data preservation, read-only handoff, future lifecycle synchronization and verification commands.
- Final workspace typecheck/build passed. API regular suite: 50 passed, 20 guarded cases skipped (19 real-DB cases and 1 browser case). Frontend suite: 16 passed. Isolated MySQL runner: 20 passed (hierarchy 8 including one shared date test, photos 4, reports 8). Compiled Swagger contract passed.
- Browser harness uses an isolated database, temporary Chrome profile, CDP pipe and same-origin frontend build. Chrome cannot initialize its renderer in this session: GPU processes exit with permission-related failures, and Page.enable times out even with in-process GPU. Browser flow did not execute successfully. No browser success is claimed; task 6.1 remains open.
- Read-only application preflight was rerun: ready=true, all 9 checks have zero conflicts. MEDIA_ROOT is not configured. Task 6.2 remains open: persistent storage, paired backups/restore, compatible deployment and release readiness are not verified.
- No application migration or business-data mutation was performed; all mutation verification used randomly created isolated databases. Actual application .env files and browser-local records were not edited.
- Resume: run the documented browser verification where Chrome can initialize normally, address any UI failures, then verify storage/backup/deployment readiness before completing the remaining checkboxes.