Sales ratifies fenced replay direction and specifies v2 cutover corrections

Assignment ADR-0052/sales/003; participant 01a0ff07-d3d4-7553-bf28-5314810de63e, host local; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. Reviewed canonical second-review publication e09826ffa22aab5ae3e817df9d7c0e9f7ebb1c30, including ADR-0052, Delivery's fenced-bind revision and the Platform/Sales admission/recovery supplements. Sales' published exact-role and service-owned recovery decision is unchanged.

Accepted architecture clauses and approval status

Sales accepts durable Revenue bind fencing, independently scoped canonical evidence read, and separately authorized Delivery committed/noncommit settlement as the architectural direction. An uncertain send cannot clear a fence. A durable tombstone prevents delayed bind, while a competing committed bind yields its original committed evidence. This grants Sales neither bind, evidence-read nor settlement authority and declares no other owner's approval.

Sales ratifies exact authenticated POST soft-create replay under the original normalized command/key and original actor; changed validated business body or protocol identity yields 409 before receipt disclosure. Command/key/fingerprint/receipt associations and settlement tombstones persist permanently, including beyond 24 hours. Current service, Organization and exact resource ownership precede receipt disclosure. Historical success remains historical evidence; it is not current eligibility, an unexpired hold or permission to proceed with binding/financial effects.

Sales accepts scheduling v2.0.0 as the compatibility classification for changed-body rejection and permanent identity; the three other proposed version increments remain their owners' decisions. Sales accepts new Scheduling-Protocol-Version: 2.0 metadata outside unchanged business JSON and keys, with Scheduling-Bind-Intent limited to Revenue's bind path. Headers and fingerprints must be durable per command before send. This is architecture review, not approval of unfinished schemas, implementation or runtime readiness.

Formal ADR acknowledgment remains withheld pending consolidation of the contradictory decision clauses and the new-admission key/cutover decisions below. No conditional blanket acknowledgment is issued. The unresolved schema and runtime evidence gates are listed separately and must not be portrayed as architecture proof.

Concrete corrections required for acceptance

1. Replace the ADR's original two-policy table and "only the two named routes" statement with one authoritative four-policy table matching Delivery's exact paths, callers and scopes. Keep evidence/settlement outside Sales authority. Replace "resends or reads" for Sales recovery with exact authenticated POST replay; no Sales inspection GET is granted. Qualify "revocation prevents a new outbound request" to service/policy/resource authority and the accepted residual JWT window, retaining the unchanged initiating-human service-owned recovery rule. Replace Delivery revision's stale owner/admin-only admission summary with the published exact sales, owner, admin plus app-verdict conjunction. Do not leave superseded normative text beside the new decision.

2. Define a new logical v2 soft-create key as admission-specific, allocated and saved once before sending, distinct from unrelated commands even when their business selections match. Sales' current closeSoftHoldIdempotencyKey is selection-derived and omits admission ID, notes and TTL. Under permanent retention it can collide across separate admissions or changed notes/TTL. Retries and recovery retain the original key; future admissions must not regenerate the old selection-derived key. New v2 keys may use a distinct bounded namespace plus durable admission identity. No historical key is renamed or recalculated, and business re-evaluation cannot silently evade an uncertain old command with a new key.

3. Make fingerprint normalization a schema gate: hash the exact versioned validated wire body after the existing camel-to-snake mapper, not Sales' camelCase journal. Specify missing versus null/default values, notes, timestamp offsets, numeric values, operation names, subject/tenant binding and digest encodings with shared vectors. Sorting keys alone does not settle normalization. Headers, normalized wire identity and versioned fingerprint must remain stable across process restarts and releases. A changed header/protocol binding is not a harmless retry of an old command.

4. Approve historical reconciliation as a separate provenance record referencing the unchanged original request/key/actor/receipt and exact authenticated producer identity evidence. Existing Sales admission rows are not evidence that the newly agreed human predicate was met. Do not attach v2 headers to an uncertain old command and thereby invent a valid v2 admission or permanent retention. Proven historical success may use only the specifically approved reconciled replay path; missing/evicted keys or incomplete association remain quarantined, with no resend, new create/bind, guessed settlement or replacement key. Define that replay path and migrated identity mapping explicitly before enabling legacy recovery.

Sales cutover and rollback position

Sales approves a bounded pause of new scheduling/close admission for the coordinated cutover, with a planned maintenance attempt of at most four hours. The pause must gate every UI, server action, API, cron/background initiator and recovery sender that could create new work; read-only workbench access remains available. Inventory and preparation occur beforehand. After writers are quiesced, classify pending commands by exact identity: supported reconciled recovery, proven historical success, or quarantine. Only specifically authorized recovery/settlement may run during the pause. No existing unresolved admission, fence or quarantine blocker is cleared to reopen the system.

Set the cutover timestamp and a four-hour decision checkpoint in the release record before execution. If checks fail by that checkpoint, keep admission/sends safely paused, retain all evidence and obtain an explicit owner-approved extension or recovery plan; the checkpoint is not automatic permission to reopen insecure writers. This approves the bounded attempt, not indefinite downtime. Rollback restores only a reviewed compatible build that keeps authentication, permanent keys, fences and tombstones enforced. Otherwise remain paused. No rollback to unauthenticated/unfenced execution, legacy payload-variance replay, or forgotten key identity is acceptable.

Sales proposes a maximum 14-calendar-day deprecation interval beginning with published scheduling v2.0.0, in line with the two-week contract standard. Schedule publication only with the prepared coordinated cutover inside that interval. The interval is migration time, not permission for unauthenticated execution. At the recorded cutover, disable legacy new execution and payload-variance replay together; retain separately authorized exact reconciled receipt recovery and quarantine thereafter. Do not promise all historical ambiguity resolves within 14 days. No running consumer remains on deprecated v1 execution after the deadline. Platform, Delivery and Revenue must approve the same pause, timestamp, coverage and rollback rule before architecture acceptance.

Resume v2 admission only after exact policies/guards, fence writers, caller metadata, producer denial/replay/settlement, current booking readiness and existing separately authorized post-bind compensation are proven in the intended release environment. A cached soft-create success must not bypass those dependent checks.

Source-backed Sales compatibility and missing obligations

Reviewed clean tracked Sales candidate d31ddf1a4bd233c3d4e2714350452de8b7cbc878 in sales/.cache/onboarding-soft-hold. modules/onboarding-closure/soft-hold.repo.ts saves the parsed command before send, rejects altered request/key/operator and preserves original receipts; soft-hold.service.ts loads the exact saved command and retains unresolved non-created outcomes. These support immutable replay structurally. Its strict schema v1 contains no protocol headers, fingerprint or authoritative human-admission verdict. Adding fields in-place would break strict parsing and rewrite history. Use a separately versioned new-command record/provenance envelope, preserve the v1 reader and do not upgrade rows implicitly.

lib/delivery/lesson-soft-hold-client.ts:120 supports extra headers and preserves the saved business mapper; modules/close-orchestration/close-orchestration.service.ts:429-430 currently passes only the key. Its key builder at :787 is selection-derived as described above. Existing capture stores producer fields and original timestamps, not raw HTTP bytes, so the migration must not claim byte-for-byte legacy wire evidence where none was recorded. Future required exact wire/receipt evidence must have an explicitly versioned storage definition.

Sales-owned implementation obligations to scope after acceptance are: strict trusted human admission; admission-specific durable command identity; protocol/fingerprint journaling without credentials; fresh issuance per attempt; explicit legacy classification/quarantine; compatible readers; distinct auth, conflict, unavailable and ambiguous outcomes; and complete initiator/pause coverage. Existing 409 mapping must preserve changed-body/historical reconciliation reasons as operator blockers, not instruct automatic replacement selection/key. These are required future deliverables, not completed work or new execution commitments.

Separate schema and runtime gates

Schema review must settle wire normalization/digests, versioned headers/journals, 409 identity/reconciliation reasons, nondisclosing denial behavior, original receipt versus current booking evidence and approved legacy replay. Producer owners must settle all invalidating writers and exact ADR-0050 conflict integration without modifying old contracts/requests/proofs. Formal architecture approval cannot stand in for those contract reviews.

Later runtime proof must cover exact saved POST replay after lost response/process exit/human revocation, changed body or header 409, distinct new-admission keys, retained original receipt beyond 24 hours, no credentials in durable state, historical eviction/quarantine, current-resource denial before disclosure, release/bind/settlement/cancellation races, crash recovery without duplicate financial work, pause coverage and failed-cutover rollback. Preserve ADR-0050 fixtures and distinguish local substitutes from deployed evidence.

ADR SHA256 e87a4fb4a19ab23994ec2de78ebb0233274214c7e54d42f0460d7d2b494ad97d; Delivery revision SHA256 2492ac8850c0078da278b55b85b2be6cf306c72af49ad67b55f461ada3389bc6. Canonical and Sales coordination HEADs both e09826ffa22aab5ae3e817df9d7c0e9f7ebb1c30. Live Sales inbox/ledger checked at 2026-10-03T00:07Z (October 2 America/Chicago), with no matching implementation commitment completed. This memo alone is prepared locally; coordinator owns publication/indexing/freshness. No implementation, issuance, fixtures, database mutation, deployment or runtime test occurred.