Acceptance report

Flows

• J-01 Fulfil a client order across creator, PM, floor and client

  Failed

  Follow one two-SKU, 150-unit order from creation to completion. The production manager starts work, floor staff log production on mobile, staff prepare QC and shipment paperwork, and the client reviews the delivered order. Every role works on the same records.

  2 passed · 3 failed · 3 not exercised

• J-02 Client and factory resolve an order question

  Failed

  An administrator links a client login. The client asks about an existing 150-unit order. The production manager receives the question and replies; the client reopens the saved conversation. Staff share an internal update and configure notification preferences; API checks verify ownership and viewer restrictions.

  4 passed · 2 failed

• J-03 Deliver one order in two separately documented consignments

  Failed

  Starting with 150 ready units, the manager books shipments of 100 and 50 with separate packing lists and invoices. The client follows each shipment. Dispatch, delivery, quantity guards and order closure are checked against the adopted policy.

  3 passed · 2 failed

• J-04 Reuse a SKU and preserve submitted order specifications

  Failed

  A creator builds and duplicates a product specification, submits an order, then revises the library. Active, shipped and completed orders must retain their snapshots; a future submission must use the revised specification.

  2 passed · 2 failed

What this report does not cover

• Runs use an isolated local Base44 backend with synthetic users and data.
• Hosted login, real email delivery and deployed access rules are not verified.
• A checkpoint marked “not exercised” did not run. It is not a pass.

J-01

• Missing explicit QC pass blocks dependent packing/shipping milestones. J-03 independently exercises shipping from ready prerequisites. Real email and unresolved Q-02/Q-05/Q-06/Q-07 remain unverified.
• Admin edit dialog places the status control outside the viewport even after scrolling. UI correction/history is unexercised; the independent reason guard is checked through the API.

J-02

• Existing local identities and orders are prerequisites. Hosted login/invitations, real email delivery and Q-02 approval semantics remain unverified.

J-03

• Ready production is a prerequisite. Negative API guard checks use separate local orders to preserve the main handoffs. Returns, cancellations, delayed-before-dispatch ambiguity and real email remain outside this example.

J-04

• Shipped/completed orders are historical prerequisites. The explicit order-amendment workflow and exhaustive specification fields are not certified. Missing packaging controls remain failures.
• SKU propagation did not complete (500); retained snapshots do not certify D-03. The local CLI lacks the bulk-update route used by this function. Source audit F05 remains unresolved.

Technical evidence

• Native Playwright report: every step, attachment and error
• Full debugging traces stay with the original local report.