Phase 206

Workbench Submit-State + API Error Contract QA

This phase turns the Phase 205 boundary audit into testable submit states, safe API error mapping, and stable DOM metadata for every role workbench.

Core rule

The button is not authority

Every workbench action must reveal its action class, submit state, payload preview, safe result state, and safe error code. Backend permission remains final authority.

Action class

backend-guarded

Allowed to call an approved backend API after auth. Still only draft/profile/offer/RFQ/quote/evidence truth.

Action class

preview-only

Allowed to prepare a packet locally. Must not create backend records, payment, stock, invoice, order, or ledger truth.

Action class

partner-gated

Allowed to create licensed partner execution draft only. Payment outcome still depends on partner callback and reconciliation.

Submit-state ladder

11 states

UI

idle

state

No active submit attempt is running. Operator can inspect payload and edit fields.

Fail if

Button looks ready but payload preview is missing.

UI

editing

state

Operator changes form data. Result panel must clear so stale success is not trusted.

Fail if

Old success or error remains visible after the payload changes.

UI

payload preview

state

Operator can see exactly what will be submitted or prepared before pressing the button.

Fail if

A submit button exists without a visible payload preview.

Workbench

preview-ready

state

Preview-only action can prepare a safe packet but must not call a backend mutation.

Fail if

Preview-only action sends an API request or claims operational completion.

Backend

backend-ready

state

Guarded action is ready to call an approved FAEDA API with auth and backend permissions.

Fail if

Anonymous mutation, UI-only permission, or hidden endpoint call.

Payment Ops

partner-draft-ready

state

Licensed partner payment draft can be created, but payout execution is still blocked.

Fail if

Partner draft wording claims paid, settled, wallet credited, or ledger posted.

Workbench

submitting

state

Button is disabled, spinner is visible, and duplicate submit must be blocked.

Fail if

Double-click can create repeated records or duplicate partner drafts.

Backend

BACKEND_ACCEPTED

state

API accepted a draft/profile/offer/RFQ/quote/evidence record only.

Fail if

Success copy says payment, inventory, invoice, ledger, or final order was created.

Partner Gate

PARTNER_DRAFT_ACCEPTED

state

Payment instruction draft was accepted for licensed partner processing review only.

Fail if

Draft is treated like successful payout before callback, reconciliation, and ledger gates.

Workbench

PREVIEW_ONLY_PREPARED

state

Packet is prepared locally and returned to the operator as evidence for the next gate.

Fail if

Packet is stored, paid, posted, or treated as committed business truth.

Safety

ACTION_BLOCKED

state

Submit failed safely and must expose a safe error code without raw backend details.

Fail if

Raw stack trace, provider credential, token, or cross-customer data is shown.

API error contract

safe display

AUTH_REQUIRED

No signed-in token exists for a backend guarded action.

Sign in required. No anonymous mutation was submitted.

PERMISSION_DENIED

Backend rejects the current actor, role, tenant, or permission.

You do not have permission for this action.

VALIDATION_ERROR

Backend rejects required fields, format, quantity, price, or scope.

Fix the highlighted data and submit again.

CONFLICT

Duplicate record, stale approval, same-user maker-checker conflict, or already processed item.

This item conflicts with an existing record or state.

NETWORK_UNAVAILABLE

API connection fails or backend is unavailable.

Connection failed. The action was not completed.

UNMAPPED_ACTION

The UI action has no approved backend mutation.

This action is not wired for backend submission yet.

API_ERROR

Unexpected safe backend error after sanitization.

Something went wrong. Review the safe error and retry later.

QA metadata contract

Stable hooks now exist in the shared workbench

1`data-workbench-role` on the page root, submit button, tabs, and payload preview.
2`data-workbench-action` on tabs, submit button, and payload preview.
3`data-action-class` with backend-guarded, preview-only, or partner-gated.
4`data-submit-state` with backend-ready, preview-ready, partner-draft-ready, or submitting.
5`data-testid=workbench-submit-role-action` for submit buttons.
6`data-testid=workbench-payload-role-action` for payload previews.
7`data-testid=workbench-result-role` for submit result panels.
8`data-result-state` and `data-error-code` on result panels.

Role expectations

registry bound

Role QA contract

Raw Material Supplier

A supplier registers material and answers manufacturer RFQs without creating payment or inventory truth.

Backend guarded

3

Preview-only

0

Open workbench

Role QA contract

Manufacturer

A manufacturer declares what it needs, what it can make, and which market channel should receive output.

Backend guarded

3

Preview-only

0

Open workbench

Role QA contract

Wholesaler / Distributor

A wholesaler bridges factory output into retailer-ready bulk supply without pretending stock is already posted.

Backend guarded

2

Preview-only

1

Open workbench

Role QA contract

Retailer / Shopkeeper

A shop publishes source-linked local offers and receives customer demand without bypassing order/payment gates.

Backend guarded

2

Preview-only

1

Open workbench

Role QA contract

Customer / Family

A family expresses demand and builds a basket while FAEDA protects privacy and regulated finance boundaries.

Backend guarded

1

Preview-only

1

Open workbench

Role QA contract

Rider / Logistics Provider

A rider offers movement capacity and proof packets while finance remains partner-gated.

Backend guarded

1

Preview-only

1

Open workbench

Role QA contract

Founder / Admin Ops

Founder sees the full FAEDA Business Pro web ERP without weakening backend authority.

Backend guarded

1

Preview-only

2

Open workbench

Fail conditions

Any one of these blocks public readiness

1A backend guarded action submits without auth.
2A preview-only action calls any API mutation.
3A partner payment draft claims payout, settlement, wallet credit, or ledger posting.
4A result panel appears without data-result-state or data-action-class.
5A submit button appears without data-testid, data-workbench-role, data-workbench-action, and data-submit-state.
6An error displays raw backend stack trace, provider secrets, tokens, or internal finance details.
7A customer role surface reveals supplier cost, internal payment calculations, or another customer's data.
8A success message skips the next gate and implies final business completion.

Next phase

Phase 207: Role Workbench Automated Smoke Test Matrix

Next we should use these stable hooks to define automated smoke checks for all seven role workbenches without relying on fragile UI copy.

Phase 205 Phase 207