## 1. Boundary summary A web enquiry produces a pending quote-email draft. Approval by an authenticated office reviewer authorizes dispatch of the approved body and recipient for the exact enquiry_id + revision. Pending and rejected drafts cannot dispatch; edits increment revision and clear approval. Uncertain delivery blocks automatic retry pending reviewer confirmation of provider acceptance. Available observations are the event journal, test mail sink and durable-claim admin view. These describe observable surfaces, not successful execution. Approval persistence, authentication evidence, stale-action handling and post-reconciliation transitions are not fully specified. ## 2. Requirement map | ID | Supplied rule | Evidence location | |---|---|---| | R1 | Enquiry contains four named fields; draft is stored pending. | WORKFLOW_SPEC, R1 | | R2 | Dispatch uses approved body and recipient for the exact enquiry/revision. | WORKFLOW_SPEC, R2 | | R3 | One successful send per enquiry/revision; simultaneous dispatches share a durable claim. | WORKFLOW_SPEC, R3 | | R4 | Editing body or recipient increments revision and clears approval. | WORKFLOW_SPEC, R4 | | R5 | Only authenticated office reviewers approve/reject; pending/rejected drafts cannot dispatch. | APPROVAL_AND_SIDE_EFFECT_RULES, R5 | | R6 | Confirmed send records provider_message_id and sent; uncertainty records needs_reconciliation and blocks automatic retry until reviewer confirmation. | APPROVAL_AND_SIDE_EFFECT_RULES, R6 | No explicit conflicting rules were supplied. Observability descriptions are inspection capabilities, not additional requirements. ## 3. Test cards All fixtures are synthetic. Each card starts independently with enquiry `{enquiry_id:"Q-041", revision:2, customer_email:"owner@example.com", service:"gutter inspection"}` and stored pending draft body “We can quote for a gutter inspection.” `body` is a test-harness label; its storage field is unspecified. Actor labels and injection barriers below are test-harness placeholders. ### T1 — Ordinary approved dispatch **Requirements/status:** R1, R2, R5, R6 — SPECIFIED. **Initial state/fixture:** Common fixture; actor `reviewer-A`, authenticated office reviewer. **Sequence:** 1. Inspect the pending draft. 2. Approve using `{enquiry_id:"Q-041", revision:2}`. 3. Dispatch; sink accepts and returns synthetic provider ID `msg-test-041`. **Expected/prohibited:** SPECIFIED: accepted body and recipient match approval; journal records sent state and provider_message_id. Dispatch before approval or to another recipient is prohibited. **Evidence:** Pending storage, journal, sink. Missing instrumentation: durable approved-content snapshot and authentication evidence; actor_role alone cannot prove authentication. **Recovery:** None injected. R6 defines confirmed-send recording. ### T2 — Pending, rejected and unauthorized actions **Requirements/status:** R5 — SPECIFIED; unauthorized-action response — OWNER DECISION REQUIRED. **Initial state/fixture:** Common fixture; actors `visitor-A` (unauthenticated) and `reviewer-A` (authenticated office reviewer). **Sequence:** 1. Attempt dispatch while pending. 2. Submit approval as visitor-A, then attempt dispatch. 3. Reject as reviewer-A, then attempt dispatch again. **Expected/prohibited:** SPECIFIED: visitor-A cannot approve; no sink acceptance while pending or rejected. PROPOSED: unauthorized attempts receive an explicit denial response; its form is not an oracle. **Evidence:** Sink, journal actor_role and transitions; authentication-decision evidence is missing. **Recovery:** Owner must define unauthorized-action response and whether/how rejected drafts can be reopened. ### T3 — Double approval click **Requirements/status:** R2, R3, R5 — SPECIFIED; duplicate-action response — OWNER DECISION REQUIRED. **Initial state/fixture:** Common fixture; reviewer-A; identical approval actions `{enquiry_id:"Q-041", revision:2}`. **Sequence:** 1. Submit the first approval. 2. Inject the identical second click before the first response returns. 3. Allow resulting dispatch work to complete with confirmed sink acceptance. **Expected/prohibited:** SPECIFIED: at most one successful send for Q-041/revision 2; any accepted message matches approved content. If dispatches overlap, they share the durable claim. A second successful send is prohibited. Exact duplicate-click UI response is unspecified. **Evidence:** Journal dispatch_attempt_id values, sink acceptance count, durable-claim view. **Recovery:** No automatic recovery policy supplied for duplicate actions; owner must choose duplicate response and terminal UI presentation. ### T4 — Two simultaneous dispatches **Requirements/status:** R2, R3, R6 — SPECIFIED. **Initial state/fixture:** Common fixture approved by reviewer-A; attempts `attempt-A` and `attempt-B` are harness labels, not assigned system IDs. **Sequence:** 1. Hold both attempts at a harness barrier immediately before durable-claim acquisition. 2. Release both together. 3. Hold the winning attempt before provider completion; inspect claim status. 4. Return confirmed acceptance, then release remaining work. **Expected/prohibited:** SPECIFIED: both attempts share the same durable claim; one successful send maximum; confirmed send records provider ID and sent state. Separate successful sends are prohibited. **Evidence:** Sink, journal attempt IDs, claim view. If the view exposes only status, missing instrumentation is attempt-to-claim identity linkage; status alone cannot prove a shared claim. **Recovery:** Loser response and later eligibility are unspecified; owner decision needed. No invented lease or retry timing. ### T5 — Edit, then deliver stale approval **Requirements/status:** R2, R4, R5 — SPECIFIED; stale-action response — OWNER DECISION REQUIRED. **Initial state/fixture:** Common fixture approved at revision 2; delayed approval action still carries revision 2. **Sequence:** 1. Edit body to “Please confirm access for inspection” and recipient to `quotes@example.com`. 2. Verify revision increment and cleared approval. 3. Deliver the delayed revision-2 approval. 4. Attempt dispatch of the edited draft without fresh approval. **Expected/prohibited:** SPECIFIED: edit increments revision and clears approval; stale revision-2 approval cannot authorize edited content. Sending the edited body or recipient without its approval is prohibited. PROPOSED: explicit stale-action rejection. **Evidence:** Journal revisions/transitions and sink; approved-version snapshot and edit-history visibility are missing. **Recovery:** Owner must define stale-action response and whether superseded revision 2 remains independently dispatchable. ### T6 — Provider accepts, acknowledgement is lost **Requirements/status:** R3, R6 — SPECIFIED; reconciliation outcome — OWNER DECISION REQUIRED. **Initial state/fixture:** Common fixture approved; sink acceptance ID `msg-test-uncertain-041`. **Sequence:** 1. Dispatch and let the sink accept the message. 2. Inject acknowledgement loss before the workflow receives confirmation. 3. Observe uncertainty handling. 4. Exercise the automatic-retry entry point before reviewer confirmation. 5. Reviewer confirms that the sink accepted the original. **Expected/prohibited:** SPECIFIED: state becomes needs_reconciliation; no automatic resend before confirmation; no second successful send for this revision. Post-confirmation state and provider-ID recovery are unspecified. **Evidence:** Sink acceptance, journal transitions/attempts, claim view. Inspect retry initiation; if unavailable, missing instrumentation is the retry entry-point trace. **Recovery:** Reviewer confirmation is required. Owner must define transitions for accepted, not accepted and still unknown outcomes. ## 4. Decision queue 1. **T1–T2:** What evidence proves authentication and approved content? Full authority/content assertions lack direct evidence. 2. **T2:** What response and reopening rules apply to unauthorized actions and rejection? Response/recovery assertions are blocked. 3. **T3–T4:** What are duplicate/loser outcomes, and how are attempts linked to claims? Response and shared-claim verification are blocked. 4. **T5:** How are stale approvals and superseded revisions handled? Exact stale-response and old-version dispatch assertions are blocked. 5. **T6:** What transitions follow each reconciliation outcome? Post-confirmation recovery assertions are blocked. ## 5. Run sheet | Test | Execution status | Actual result | Evidence | |---|---|---|---| | T1 | NOT RUN | | | | T2 | NOT RUN | | | | T3 | NOT RUN | | | | T4 | NOT RUN | | | | T5 | NOT RUN | | | | T6 | NOT RUN | | | - Confirm all mail routes exclusively to the test sink. - Reset draft, claim and sink fixtures between cards. - Confirm injection controls and evidence access; resolve blocked oracles before judging those assertions.