# Workshop handover, reviewed by an orchestrator

Real model outputs from a bounded cookbook-only orchestration. All scenario inputs are synthetic.

## Product scope and validation · gpt-5-mini-2025-08-07

- Problem-and-scope brief (short): Two-shift small workshop suffers ambiguous ownership/next-action at handover. The minimal proposal is a single-device local handover log (six fields: equipment_label, issue_short, current_owner, next_action, status, timestamp) accessed on a shared tablet/browser, with an acknowledge action that records receipt (initials + timestamp) but does not change ownership, and JSON/CSV export for supervisor review. Software work is conditional on first validating a structured paper checklist process in a supervised pilot. Sample handover notes are SYNTHETIC and cannot substitute for field research.
- Key constraints preserved from the three source cards: single-device, local-origin only (no backend/cloud/auth/notifications/integrations/AI/machine control), minimal six-field model, acknowledgement must only record receipt, and exports are local files. All pilot numbers and performance targets are PROPOSED, UNVALIDATED targets.
- Noted contradictions in the supplied draft that must be resolved before work: the draft text lists Wave 1 as 'parallel' while agentConcurrency limits to one builder; the draft adds a pilot comparison view and 'local telemetry' in Module 3 even though scope instructions ask to remove telemetry and to separate paper-process validation from software-vs-paper comparison; the requirements mention JSON export and at times treat import/restore as optional — this is an explicit acceptance conflict (export does not imply a restore/restore promise unless chosen and acceptance criteria updated).

### Recommendations

- Decision gate A — Paper-process checklist validation (required before any software build): Run a supervised paper pilot to verify that a structured six-field laminated checklist can produce usable, consistent handover records.
-   - Proposed/unvalidated pilot design: 2-week supervised pilot OR at least 10 handovers (whichever reaches target first); map each paper entry to the six fields; supervisor-led mapping sessions daily during pilot.
-   - Proposed/unvalidated success criteria (labelled PROPOSED, UNVALIDATED): >=90% field completeness (all six fields filled), <=10% ambiguous owner/next-action cases, >=80% acknowledgements recorded within 15 minutes of shift start, supervisor confirms 1:1 map for >=90% sampled entries. These targets are draft and must be treated as unvalidated.
-   - If Gate A passes, proceed to a tightly scoped software prototype decision gate. If Gate A fails, iterate the paper checklist (UX, field wording, placement) before considering software.
- Decision gate B — Does software add measurable value over validated paper checklist?: Only considered after Gate A passes. Run a small software pilot on the same device using a local prototype and compare measured outcomes vs the validated paper baseline.
-   - Proposed/unvalidated comparison metrics: completeness, owner/next-action ambiguity rate, acknowledgement latency, supervisor review time per handover, and error/merge incidents during handover. Define measurement method and sample size before the comparison. All numeric thresholds are proposed and unvalidated.
-   - Software decision acceptance requires a pre-agreed improvement margin over paper (e.g., relative improvement in completeness or reduction in ambiguity) and evidence that single-device constraints (availability, origin stability) do not negate benefits.
- Operational design choices to lock before any build: (1) Acknowledgement is explicitly defined as a receipt record only — it must never reassign ownership. (2) Export (JSON/CSV) is provided for backup and supervisor review; export does NOT imply automatic restore/import capability unless the team explicitly adds import with matching acceptance criteria. (3) Keep all development waves strictly sequential under one builder (no parallel builds touching shared schema/storage files). (4) Remove telemetry and the pilot comparison view from the first software iteration; comparison view can be a separate later module only after Gate A.

### Concerns retained

- Unresolved assumptions (preserve these as unresolved): exact tablet model and browser (affects IndexedDB behavior and touch layout); who will enter initials for acknowledgement and how identity ambiguity is resolved (initials vs full name); availability policy for the single shared device and human process for device unavailability; whether JSON import/restore is required (conflict in current drafts); supervisor acceptance criteria for a successful paper pilot and what sample size/timeframe stakeholders consider sufficient; real ergonomic needs of operators (no real user interviews have been done).
- Scope exclusions (explicit, preserved): No backend/cloud/auth, no notifications, no integrations, no AI features, no machine control or safety sign-off within the app, no automated operational decisions; first software version excludes telemetry and the supervisor comparison view. These exclusions must remain unless stakeholders explicitly vote to expand scope after Gate A.
- Export/restore concern: current materials mix export and optional import. Recommendation: treat export as outbound-only (no implied restore) for the prototype unless a separate explicit decision and acceptance tests add import/restore. If import is added later, add acceptance tests that explicitly verify restore correctness and document provenance/consent.
- Process/organizational concern: single-device approach depends on device origin stability (same file/URL/origin). If browser origin changes (e.g., file:// vs http://, different base path), IndexedDB data may be siloed or lost; pick and freeze the device + origin before testing persistence.
- Sequencing concern: ensure development waves are sequential and managed by one builder; current draft conflicting language (parallel vs single-builder) must be corrected before any development work starts.

## Technical specification and consistency · gpt-5-mini-2025-08-07

- Observations (synthetic inputs preserved): three source cards define a single-device local handover log, six core fields (equipment_label, issue_short, current_owner, next_action, status, timestamp) plus acknowledge metadata and exports; original draft added telemetry, an optional JSON import, a paper-comparison view and a parallel first wave—these conflict with steering constraints.
- Design choices (explicit): use vanilla JavaScript, direct IndexedDB (no libraries), serve bundled static files at stable origin http://localhost:4173, single-device only, no external/network calls, unresolved-first ordering in UI, acknowledgement records receipt only (does NOT change current_owner), provide JSON and human-readable CSV export, explicitly exclude JSON import/restore from the product and remove all import acceptance checks, two sequential build waves under one builder, exclude telemetry and the paper-comparison view from delivered scope.
- Untested assumptions (preserved unresolved): which tablet/browser will be used for the pilot (affects touch layout and IndexedDB behaviour); who exactly will enter initials for acknowledge and whether initials are sufficient to avoid ambiguity; device-availability policy and recovery process expectations; whether supervisor requires in-app restore (explicitly excluded) or will accept export-only backup.
- Key explicit constraint: export-only does NOT imply in-app recovery. Exported files are backups for external/archive use; the app will not provide an import/restore acceptance path in this specification.
- Deployment note: the app is a static SPA served from http://localhost:4173 on the shared device; all feature behaviour must be verifiable with devtools network panel showing zero outbound network requests during normal use.

### Recommendations

- Acceptance checks (testable, before pilot):
- 1) Persistence: create three sample items (using UI), close and restart the browser on the device served from http://localhost:4173, verify all items persist and created_at/updated_at remain unchanged. (Manual)
- 2) Unresolved-first ordering: with mixed-status items present, UI lists items with status open and awaiting_review before closed; within each status sort by updated_at descending. (Manual/automated UI check)
- 3) Acknowledge behaviour: activating acknowledge prompts for initials, sets acknowledged_by and acknowledged_at, and does NOT modify current_owner or status fields. Verify stored record fields after acknowledge. (Manual/automated check against IndexedDB record)
- 4) Export correctness: JSON export produces a single syntactically valid JSON file containing every handover_item record including created_at, updated_at and acknowledged_* fields; CSV export produces a human-readable file with a header row mapping the six core fields plus acknowledge metadata. Validate JSON.parse succeeds and CSV has expected column count. (Automated unit test + manual open)
- 5) No import/restore acceptance: explicitly do NOT include any import or restore acceptance checks. Document that the app does not offer in-app JSON restore and that exports are archival only. (Documentation check)
- 6) No-network rule: exercising full CRUD and export flows produces zero outbound network requests (devtools network panel shows none). (Manual check)
- 7) Single-device deployment check: app served from http://localhost:4173 on the target device works offline (no network) and preserves data across browser restart and device power cycle. (Manual)
- 8) Developer process: enforce single-builder rule and sequential waves: verify only one builder works at a time on sharedFiles (human review of Git history / gated merges). (Process check)
- 9) Accessibility/ergonomics smoke: tablet-layout form fields are touch-sized, input validation enforces required fields and issue_short max length 140 characters. (Manual review)
- 
- Operational recommendations:
- - Keep paper-process pilot and its gate separate from any later software-vs-paper value comparison; run the supervised paper checklist pilot first (instructions documented) before committing to software changes.
- - Document export-only recovery clearly in user guidance and supervisor instructions; provide procedures for manual reconstruction if required.
- - Preserve unresolved assumptions; capture them in the pilot checklist as explicit questions to answer.

### Concerns retained

- Resolved draft conflicts (explicit):
- 1) Wave sequencing conflict: original draft listed Wave 1 as 'parallel' while agentConcurrency allowed one builder. Resolved: two waves defined and strictly sequential; only one builder permitted at all times.
- 2) Acknowledge semantics conflict: earlier text implied acknowledge might 'claim' ownership. Resolved: acknowledge records receipt only (acknowledged_by, acknowledged_at) and MUST NOT change current_owner or status; acceptance checks reflect this.
- 3) Telemetry and paper-comparison conflict: module 3 previously added telemetry and a paper comparison view. Resolved: telemetry and the paper-comparison view are removed from the delivered scope and from acceptance criteria for both waves.
- 4) JSON import/restore conflict: earlier stories alternately required and made import optional. Resolved: JSON import/restore is explicitly excluded; all import-related acceptance checks removed. Export remains available but is not a restore mechanism.
- 
- Remaining concerns / risks (untested):
- - Tablet/browser choice unknown: IndexedDB quirks vary by browser and platform; pilot must choose and record exact device and browser. (untested assumption)
- - Identity ambiguity: initials may be ambiguous; responsibility for resolving identity outside the app must be documented. (untested assumption)
- - Single-device failure mode: if the tablet is unavailable or origin changes (different hostname/port), data may be inaccessible; produce administrative recovery guidance. (operational risk)
- - Export-only limitation: excluding import makes in-app recovery impossible; supervisors must accept manual restore procedures or keep exported snapshots. This may affect willingness to adopt software.
- - Do not claim the app makes safety decisions; supervisors retain all operational authority outside the app.

## Orchestrator conclusion

Integrated the workers into a conditional, unbuilt software draft. The three canvas cards are the only cited inputs; the handover notes are synthetic.

Agree the paper gate and operational policies before authorizing a prototype; no files were generated, code compiled or tests executed.