Sales defines exact scheduling permission and accepts service-owned recovery

Assignment ADR-0052/sales/002; participant 01a0ff07-d3d4-7553-bf28-5314810de63e, host local; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. This supplements Sales' initial position published in coordinator batch 33da836a4c73ce5d23fa14eb7485f873c698a0ae.

Sales decision and exact admission wording

Sales replaces its initial owner/admin-only proposal with the exact active-Organization role set sales, owner, admin, conjunctively with the existing Sales app-access verdict. Ordinary Sales-role operators must be able to admit scheduling work. Owner/admin operators may admit only when independently granted current Sales app access by the existing rail. Owner/admin alone grants no app access today; Sales deliberately preserves that exclusion. This changes no global Platform app-role map. SuperAdmin can satisfy the app-access check but cannot replace exact enabled Organization membership in the approved role set.

Proposed normative replacement for the Sales admission clause in ADR-0052 and scheduling section 8.5:

Before persisting any new scheduling admission or sending its business command, Sales SHALL obtain fresh uncached successful JSON verdicts from its configured trusted Platform bootstrap endpoint and GET /api/auth/operator-session?app=sales, using the same incoming human session cookie. Require both response envelopes ok === true, both data.signedIn === true, operator-session data.authorized === true, and equal nonempty data.user.id values. Require bootstrap data.tenant_id === "tnt_sguild", data.activeOrg.id === command.organization_id, that Organization in the approved canonical allowlist, present nonempty data.membership.memberId, data.membership.disabled === false, and exact data.membership.role in ["sales", "owner", "admin"]. Every predicate is conjunctive. Missing or malformed fields, unavailable verification, other roles, configured tenant substitution, development stubs and SuperAdmin-only access SHALL fail closed. Global operator.roles, client-supplied verdicts, role hints and actor/tenant/Organization headers SHALL NOT establish exact Organization permission. Browser-facing mutation entry points retain anti-forgery checks.

For the proposed singleton policy the canonical Organization allowlist is exactly [org_01900000-0000-7000-8000-000000000001]; admission cannot widen it. A sales membership in Organization A can satisfy generic app access, but cannot authorize a command in Organization B whose active membership role is member, coach, absent or disabled. An enabled owner/admin membership in B plus the independently true app verdict meets the proposed permission deliberately. Unknown roles, case-folded variants and compound role strings do not match this exact set.

Bootstrap's membership is queried for the verified user and session's active Organization. Its disabled field incorporates inactive status and disabledAt. The two verdicts have no atomic combined snapshot; matching fresh user IDs reduce inconsistent use but do not establish instantaneous human revocation. Organization names/slugs and successful Organization-detail lookup are not admission predicates. Delivery independently enforces current canonical resources.

Service-owned recovery and issuance

Sales accepts the coordinator-selected rule: once valid human admission and the immutable normalized business request, original actor/admission provenance and stable key are durable, the command is service-owned. Subsequent initiating-human expiry, active-org switching, membership removal/disablement or scheduling-permission revocation blocks new human admission but does not alone invalidate exact saved-command recovery. Recovery loads the unchanged saved command/key/original actor under current workload, policy, tenant, Organization and canonical resource authority. It must not substitute the recovering operator, reconstruct UI inputs, invent historical admission evidence, bypass cancellation/terminal state or producer restrictions, or interpret loss of authority as prior noncommit. Human removal does not silently cancel admitted business work; cancellation needs its separate approved protocol.

Sales accepts fresh successfully audited issuance for each individual outbound attempt, including retries. Bearers remain in process memory only for that attempt; no cross-attempt cache, token sharing across concurrent attempts, persisted cookie/token/proof, or fallback human credential. Failed issuance sends no business request and retains pending or ambiguous outcome. Exact POST replay remains the proposed soft-create recovery surface; no inspection GET is authorized here.

Sales accepts the honestly bounded issuance-revocation window: a previously issued offline-verified token can retain its remaining validity, at most 300 seconds plus accepted clock tolerance capped at 30 seconds. Disabling issuance prevents subsequent token acquisition, not immediate invalidation of an in-flight bearer. Immediate producer rejection requires a separately specified producer policy check. Current producer Organization/resource restrictions remain independent checks. Token expiry proves nothing about a previous uncertain send.

Remaining approval gates and acceptance

No full ADR acknowledgment is issued. Sales must review Delivery's revised race-safe canonical bind proof, permanent replay/key-retention and historical-command handling, and coordinated cutover/admission-pause proposal before approving ADR-0052. This supplement does not approve a bind-evidence scope/GET or define another domain's commitments. Initial objections about uncertain replay after the existing 24-hour retention period remain until resolved explicitly.

Admission evidence must include an ordinary enabled exact-org sales operator accepted; owner/admin with app access accepted; owner/admin without app access denied; SuperAdmin without exact allowed active membership denied; sales app access from another Organization with disallowed active-org role denied; unknown role, disabled/missing membership, wrong/missing tenant or Organization, mismatched verdict users and Platform outage denied before admission persistence or outbound command.

Recovery evidence must separately exercise initiating-human expiry, org switch, membership removal/disablement and permission revocation: each prevents new admission while exact valid saved-command recovery proceeds under current service/resource authority. Workload, policy, Organization or resource denial instead preserves unresolved outcome. Prove distinct audited tokens for retries/concurrent attempts, no credential persistence, issuance outage with zero outbound business requests, and the stated residual validity window. Response-loss replay must retain the same original request/key/actor and receipt, including the final agreed retention boundary; historical receipts do not prove current eligibility or readiness to bind.

Evidence and publication handoff

Reviewed Platform source HEAD 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a: lib/auth/app-access.ts, modules/bootstrap/routes/routes.ts, modules/auth/routes/operator-session.routes.ts and docs/operator-auth-rail.md. The three code files have no working diff. Reviewed Platform supplement SHA256 0c5833bcb9e5d9de758f2e0fbb2ecf948bc171d30bdb87fb540f2ae90e7e07ba. Sales candidate remains the initial reviewed d31ddf1a4bd233c3d4e2714350452de8b7cbc878; current permitted coordination clone HEAD f731dbaff9fe3984eff4c776fd317da8251a9120. This source review is not production proof.

Live Sales inbox/ledger refreshed at 2026-10-03T00:02Z (October 2 in America/Chicago); no matching ADR-0052 implementation commitment completed. Only this local supplement is prepared. No implementation, issuance, fixture change, database mutation or deployment; no runtime tests claimed. Coordinator retains publication, indexer and freshness checks for the collected batch.