One-Minute Explanation
We tested the prototype as one operating cycle rather than reviewing screens in isolation. A synthetic order moved from intake through readiness, scheduling, floor handoff, completion, reporting, and recovery. Every procedural role had a trigger, a job, visible evidence, and a handoff.
Roles And Operating Flow
Select a role to see the work that was exercised and the observable handoff. These are procedural roles in the prototype; the application does not yet authenticate or authorize them.
DEMO-WEB-3001 stayed identifiable as Clear Tite 32 oz, 48 cans, assigned to Will on PS-2 for Thursday, carried by candidate PC-000001, completed once, reported consistently, and restored with its supporting Tank 6 mix batch.Executed Evidence
| Scenario | Role and proof | Result |
|---|---|---|
| HP-00 | Technical reviewer established the safe origin, baseline, persistence check, and rollback posture. | EXECUTED |
| HP-01 | B2B preparer created and handed off unique direct and Website orders without changing B2C. | RERUN PASS |
| HP-02 | B2C owner reviewed the product grid and prepared one prioritized Amazon demand row. | EXECUTED |
| HP-03 | Administrator reviewed inputs, routes, calendar, inventory, and seven readiness confirmations. | EXECUTED |
| HP-04 | Scheduler set capacity, optimized, created the plan, booked actuals, shipped, and closed the target. | RERUN PASS |
| HP-05 | Floor/operator views agreed on product, date, station, operator, quantity, and time. | EXECUTED |
| HP-06 | Reporting reconciled summary, plan versus actual, customer status, performance, and CSV. | RERUN PASS |
| HP-07 | Technical reviewer restored the post-run backup on an isolated origin and verified reload custody. | RERUN PASS |
| HP-08 | All roles and WF-01 through WF-10 reconciled as one connected operating cycle. | INTEGRATED PASS |
Defects the integrated walkthrough exposed
Demand stayed in its lane
Website demand no longer contaminates the B2C summary.
The mix plan retained its batch
The supporting Clear Tite batch now survives save, reload, backup, and restore.
Completion meant the same thing
Customer Summary, B2B history, actuals, and CSV now agree.
The Full Test Suite
The suite advances in dependency order. Happy paths establish a coherent operating baseline. The next packs deliberately stress state transitions, constraints, recovery, under-covered capabilities, and production-readiness boundaries.
Priority 1 · Operational State Transitions 10 scenarios · not yet executed
| ST-01 | Confirmation invalidation matrix | Only affected readiness state becomes stale. |
| ST-02 | B2B/B2C replay and add/replace matrix | Replay is idempotent; collisions are visible. |
| ST-03 | Empty and fully infeasible optimizer | No fabricated work; impossible demand stays visible. |
| ST-04 | Priority versus grouping conflict | Changeover reduction cannot silently override priority. |
| ST-05 | Repeated partial actuals | Cumulative partials remain partial until exact completion. |
| ST-06 | Duplicate, zero, and excessive actual | Invalid completion fails without partial mutation. |
| ST-07 | Completion correction or reopen | Approved policy is consistent or explicitly blocked. |
| ST-08 | Cross-view actual reconciliation | Queues, inventory, reports, and performance agree. |
| ST-09 | Order mutation after optimization | Candidate and readiness state become visibly stale. |
| ST-10 | Interrupted daily cycle | Reload preserves valid custody without false confirmation. |
Priority 2 · Constraints And Calendar Boundaries 8 scenarios · not yet executed
| CX-01 | Qualified operator unavailable | Work remains visible with a staffing warning. |
| CX-02 | Operator assigned to delivery or non-production | Capacity is deducted once; no conflict is created. |
| CX-03 | Material-component matrix | Adhesive, solvent, FG, polybag, and kit shortages differ. |
| CX-04 | Invalid tank, route, or station path | Incompatible work is visibly infeasible. |
| CX-05 | Zero labor and all staff absent | No production is fabricated; demand remains accountable. |
| CX-06 | Demand exceeds five-day horizon | Scheduled plus unscheduled reconciles to total demand. |
| CX-07 | Holiday, week, month, and year boundary | Dates and closures calculate correctly. |
| CX-08 | Overnight and multiple shifts | First shift works; multi-shift limits remain visible. |
Priority 3 · Recovery And Destructive-Action Safety 8 scenarios · not yet executed
| RC-01 | Malformed, older, and newer-schema backups | Unsafe restore is rejected before mutation. |
| RC-02 | Duplicate or conflicting restored identities | Restore and rendering fail closed. |
| RC-03 | Storage write or readback failure | Prior state returns or integrity failure blocks acceptance. |
| RC-04 | Semantic restore reconciliation | Orders through reports agree after reload. |
| RC-05 | Clear Queue cancel and confirm | Cancel is inert; confirm affects only the named queue. |
| RC-06 | Delete, factory restore, and reset | Each destructive action has bounded confirmation. |
| RC-07 | Wrong origin or port recovery attempt | Primary state cannot be overwritten accidentally. |
| RC-08 | Storage unavailable, cleared, full, or partial | Failure cannot masquerade as success. |
Priority 4 · Under-Covered User Capabilities 8 scenarios · not yet executed
| FX-01 | B2B and B2C order libraries | Templates remain reusable without cross-lane corruption. |
| FX-02 | Pin, unpin, and post-confirmation edit | Date constraints and staleness remain visible. |
| FX-03 | Proposed B2C replenishment | One click creates one correctly classified order. |
| FX-04 | Daily Plan generation | Mixers, worker cards, and supporting sections reconcile. |
| FX-05 | Booking, unbooking, and correction | Actual and performance state changes exactly once. |
| FX-06 | Filters, sorts, CSV, and print | Display actions are inert; outputs preserve safe identity. |
| FX-07 | Calendar, custom closure, and work schedule | Changes are bounded and reversible. |
| FX-08 | Products, recipes, tanks, routes, and modules | Dependency impact and rollback remain visible. |
Priority 5 · Production-Readiness Characterization 8 scenarios · not yet executed
| PR-01 | Reporting user attempts protected mutation | NOT EXECUTABLE until authorization exists. |
| PR-02 | Operator attempts unapproved completion | NOT EXECUTABLE until ownership is decided. |
| PR-03 | Two tabs or users edit one planning window | Characterize stale overwrite and concurrency gap. |
| PR-04 | Two schedulers confirm or optimize concurrently | Characterize plan authority and concurrency limits. |
| PR-05 | Keyboard cycle, focus, errors, and 200% zoom | Accessibility smoke; no full WCAG claim. |
| PR-06 | 100, 500, and 1,000-order workloads | Record timing and failure threshold. |
| PR-07 | Candidate-history and storage growth | Record capacity, failure, and recovery behavior. |
| PR-08 | Hostile CSV text and print overflow | Output remains inert, complete, and attributable. |
Product Review Package
The feature guides explain five specific capabilities. This validation guide explains how the broader prototype and its handoffs were exercised as an operational whole.
Questions for Mike
- Do the role responsibilities and handoffs match how RH actually works?
- Does the end-to-end order journey represent a useful planning and execution cycle?
- Which boundary should be resolved first: authority, recovery, reporting, or workflow depth?
Deliberate Limits
- The happy-path run does not substitute for the 42 pending scenarios.
- A scenario title is not proof; every future scenario needs an exact fixture, deterministic assertions, persistence check, cleanup rule, and evidence reference.
- PR-01 and PR-02 remain specified but not executable until role authority is implemented or decided.
- Synthetic data remains the only authorized test data unless a separate real-data rehearsal is approved.