Sales requests exact admission and durable replay decisions for ADR-0052

Assignment ADR-0052/sales/001; participant 01a0ff07-d3d4-7553-bf28-5314810de63e, host local; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. Routing record: C:/Users/jallr/Documents/Sguild/repos/platform/.tmp/adr-coordination/ADR-0052/state.json.

Position

Sales supports separate scoped workload authority for soft creation and Revenue-owned binding. Sales withholds formal acknowledgment of the current proposed ADR pending the decisions below. This memo approves no implementation or activation and declares no other domain's commitments. The coordinator owns publication, indexing and freshness verification for the collected batch.

Source findings

Sales candidate d31ddf1a4bd233c3d4e2714350452de8b7cbc878, clean tracked worktree sales/.cache/onboarding-soft-hold, is the reviewed caller. modules/close-orchestration/close-orchestration.service.ts:429-430 prepares a durable command before sending its saved request/key; :458 captures the response before Revenue ordering. Its operator entry at :606 requires a session but does not explicitly enforce exact active Organization, enabled membership or a scheduling role. lib/auth/index.ts maps owner/admin and SuperAdmin roles, omits membership.disabled, and permits a configured tenant fallback. These helpers alone do not prove the proposed admission predicate.

modules/onboarding-closure/soft-hold.repo.ts schema-normalizes and persists the request, original operator, admission and stable key; it rejects changed inputs and checks tenant, Lead/Person and unresolved admission. soft-hold.service.ts recovers only that saved command and preserves unresolved state on non-created outcomes. soft-hold.schema.ts contains no credential fields. lib/delivery/lesson-soft-hold-client.ts:120 can accept headers but obtains no credential; the actual call supplies only the key. These are source findings, not deployed evidence.

Canonical scheduling section 8.5 currently requires a tenant-bound human session. Sections 6.2 and 7.5 return the original result regardless of payload variance but guarantee key retention for only 24 hours, after which the same key may create a fresh write. That retention rule cannot support indefinite durable response-loss replay.

Requested exact contract changes

1. In ADR-0052 and scheduling section 8.5, define new Sales admission as a current trusted Platform verdict with signed-in user, exact verified tenant, exact active Organization matching the business command, present membership with disabled === false, and an explicit scheduling permission. Sales proposes owner/admin membership plus the accepted Sales app-access verdict; SuperAdmin alone, role hints, caller actor fields, configured tenant fallback and development stubs must not satisfy Organization authorization. Platform must confirm the authoritative permission surface and role vocabulary before acceptance. Fail closed before creating an admission or sending a new command; browser mutation entry points retain anti-forgery enforcement.

2. Define the durable command boundary: persist the normalized business request, immutable original actor/admission provenance and stable key before first send. Recovery loads those exact values, never reconstructs them from current form/Lead selection, substitutes the recovering operator or mints a replacement key. Credentials remain outside the journal, receipts, logs and evidence. Acquire a fresh Delivery token for each outbound attempt with the exact Sales capability, audience and route; issuance failure sends nothing. Historical request, key and receipt bytes remain unchanged.

3. Replace the ambiguous word "revocation" with explicit cases. Sales proposes session expiry or active-org switching to block new human admission without invalidating an already admitted command. Workload/policy/Organization authority revocation blocks all outbound attempts and preserves unresolved state. For removal of the initiating operator's membership or scheduling permission after admission, owners must choose whether admitted work survives or pauses, and identify an authoritative check if pausing is required. Session expiry is not membership revocation. No cookie persistence or human-session fallback is acceptable for unattended recovery.

4. Amend scheduling sections 6.2 and 7.5 for these two commands to retain the original key-to-command/result association for the full recovery lifetime, with no conversion of an old key into a fresh write. Sales recommends durable retention. If Delivery chooses bounded retention instead, specify its exact cutoff and a fail-closed recovery rule that prohibits uncertain replay beyond that cutoff. Preserve historical behavior without inventing missing old admission or retention evidence. Authentication and resource reach checks precede receipt replay; another subject or Organization cannot obtain an old result by possessing its key.

5. Name authenticated POST replay on the same soft-create route as the recovery mechanism. The proposed capability grants no inspection GET. Remove or separately scope "reads" from the recovery wording. After response loss, replay the saved body/key under fresh authority and capture the original exact lesson/first_lesson_id receipt before any dependent order call. A 401/403, outage, timeout or expired token does not prove the earlier operation did not commit. A replayed receipt is historical evidence, not proof of current eligibility, unbound state or readiness to bind; Delivery and Revenue retain those checks. If the producer key association is unavailable, preserve the blocker and seek explicit reconciliation.

6. Publish the exact workload issuer/proof subject, output subject, singleton tenant/Organization binding, selectors/scopes, errors and version changes in service-auth with the section 8.5 exception restricted to the two named methods/paths. Confirm Revenue's canonical order/reservation/lesson association with Delivery. State deployment order and compatibility cutoff before acceptance; Sales accepts no permissive fallback or silent rejection of the existing caller. Any admission pause needs a separate explicit owner decision. Coaching eligibility authority and ADR-0050 closure capabilities remain separate.

Acceptance criteria

Prove current exact-Organization operator admission and deny signed-out, wrong/missing tenant, wrong active Organization, disabled/missing membership, disallowed role and bootstrap outage before admission or outbound effect. Prove each chosen post-admission revocation case separately from session expiry.

At the actual producer route, prove exact workload success and missing/expired/wrong issuer, audience, caller, scope, tenant, Organization, preview proof and closure-token denial without new producer persistence or external effects. Issuance outage must preserve Sales pending state and send nothing; denial after an earlier ambiguous send must retain that ambiguity.

Prove response loss, process interruption and expired initiating session recover the same saved normalized request/key to the same original lesson and receipt, without persisted credentials or replacement keys. Exercise recovery beyond 24 hours under the agreed retention rule and cross-subject/Organization replay denial. A changed selection must fail against the old journal. Verify expired or bound hold receipts cannot justify a new binding. Keep local deterministic Coaching substitutes explicitly labeled and separate local from deployed proof.

Reviewed pins and handoff

Canonical coordination HEAD 2ac56cfb4de72b1725bf522d537b5bec16ba0ea6; Sales coordination HEAD f731dbaff9fe3984eff4c776fd317da8251a9120. Reviewed proposed ADR SHA256 040c11e2fa3f992eb8638f2f2a34dc51d227cc4775e54b196a1ab0ef2acb8cad; request memo SHA256 b93bb5f904d096a89e381a16e33e2207c340242efc8ad472e6ad70e9044a7d4f. Platform audit checkout 8f877adca494d1fd23cc404cf64423d06a35565d, docs/adr0050-scheduling-session-boundary.md; its cited Delivery 75589fa499b3c62ef94ef5702d5470c4781a1059 and Revenue 5f10755c031897b6598a051f915c6864ee0901e1 are audit pins, not independently asserted current deployed states. References: ADR-0001, ADR-0036, ADR-0039, service-auth v1.7.0, sales-scheduling-surface sections 6.2, 7.5 and 8.5.

Live Sales inbox and ledger read at 2026-10-02T23:52Z show this approval request awaiting Sales' response, with no ADR-0052 implementation commitment completed by this review. Only this local memo is authored; no runtime, fixture or historical journal is changed. Publication/indexing/freshness remain pending with the coordinator. No runtime tests are claimed for this architecture review. The coordination-referenced engineering:architecture skill was unavailable in the installed skill catalog and local skill search; review follows the available coordinator skill and canonical contracts.