jason
29 lines
1.8 KiB
Markdown
29 lines
1.8 KiB
Markdown
# Build Plan
|
|
|
|
The roadmap agreed at project kickoff. Each step is committed separately so the app can be deployed and used at any point in the sequence.
|
|
|
|
| # | Step | Status |
|
|
| - | ---- | ------ |
|
|
| 1 | Repo scaffold, Dockerfile, Prisma schema, auth (admin email/password, operator PIN, 12h session) | **In progress** |
|
|
| 2 | Admin CRUD: Machines, Operation Templates, Projects → Assemblies → Parts, file uploads | planned |
|
|
| 3 | Operation authoring (template or ad-hoc) + QR token generation | planned |
|
|
| 4 | Operator scan flow: claim → start → units/notes → QC prompt → close | planned |
|
|
| 5 | PDF generation: per-operation card + per-part cover sheet | planned |
|
|
| 6 | Fasteners + PO (PDF + lifecycle: draft → sent → partial → received) | planned |
|
|
| 7 | Admin dashboard (WIP, overdue, plan-vs-actual) + audit log viewer | planned |
|
|
| 8 | In-browser STEP viewer + server-side thumbnails | planned |
|
|
| 9 | QC records (inline checkboxes + dedicated QC operation type) | planned |
|
|
| 10 | OpenAPI docs at `/api/docs`, nightly SQLite backup script | planned |
|
|
|
|
## Locked design decisions
|
|
|
|
- **Hierarchy:** Project → Assembly → Part → Operation.
|
|
- **QR granularity:** one QR per Operation; each step prints its own card.
|
|
- **Claim model:** an Operation locks to one operator on Start; other scans of an in-progress operation show a read-only view noting who holds it.
|
|
- **Operators can hold multiple operations at once** (across different parts).
|
|
- **Purchase orders:** PDF generation + lifecycle states (`draft → sent → partial → received → cancelled`).
|
|
- **No offline mode.** The app assumes the shop LAN is up.
|
|
- **Language:** English only in the UI.
|
|
- **Persistence:** SQLite in a single mounted `/data` volume; migrations via Prisma.
|
|
- **Integrations:** none for now; REST API is versioned (`/api/v1/*`) and fully documented for future use.
|