Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
T14 · Editing after review prevents stale approved send
| Field | Value |
|---|---|
| Status | Not executed |
| Type | Balanced software |
| Layer / kind | API · database · race injection |
| Priority | P0 |
| Gates | A04, A05, A08 |
| Build step | Step-04-Opportunities-Versions-Approvals |
| Decisions | Q02, Q06 |
Given
V1/E1 is approved while another user edits to V2/E2.
When
Interleave approval, edit and publish/formal-send transactions in both orders.
Then / oracle
Proposed rule: an edit invalidates approval for the edited candidate and requires approval of its exact new revision. Stale publish/send is rejected without event. If publication committed first, its historical approved version remains immutable; a later edit cannot undo that fact. Never substitute unapproved content.
Evidence required
Controlled transaction barriers; revision IDs and invariant assertions after both interleavings.
Decision dependency (verbatim)
Q02/Q06: confirm reject-stale-current-candidate rule and distinguish pending revision approval from historical publication.
Source: TDD rev 1.3 (PDF); machine-readable in 10-Sources/tdd-bundle/. Back to Scenario-Index · Traceability-Matrix · integration dependencies in Dependency-and-Regression-Table.