Existing reservation-first and atomic hold flows retain current-human authority and require real producer enforcement

Assignment ADR-0053/platform/008 compatibility dependency, coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc/local. Source-pinned read-only disposition, no new policy, contract amendment, foreign code change or production readiness claim. Root alone publishes this memo.

Accepted Scheduling 3.0 section 8.5 expressly limits exact new workload-only authorization to NEW v2 soft-create, bind, bind-settlement and separate fenced evidence reads. Its next paragraph keeps the existing rule for every OTHER operation: authenticated Platform tenant-bound session; 401 without tenant binding and 403 without named Organization access. Sections 4.1 and 4.5 retain reservation-first hold-create and all-or-none atomic-multi-create. Section 7.5 confines permanent v2 command retention to the named new operations and explicitly preserves the separate unrelated-operation rule. The accepted original-close slice section 8 does not create new composite/rebook/reschedule/existing-invoice capabilities or remove their existing supported product motions. The fixed ADR-0052 deadline cannot reclassify other supported endpoints as new service-policy execution or authorize bypassing original blockers.

Therefore new current-human reservation-first/composite operations can retain the existing accepted session authority, while every originally protected/compensating or unresolved competing original remains blocked under compatible common admission/writer serialization. They must not acquire ssh2/sclose3/new bind eligibility by relabeling old commands. Uncertain original results remain pending/reconciliation until separately authoritative resolution. The six new policies grant no reservation-first/atomic-multi-create or reschedule mutation, and a Revenue token does not authorize Delivery.

Revenue source 7c7f2bbf8762664fc38c7674b7c974389959ce7f, modules/credit-reservation/routes/sales-create.routes.ts and sales-multi-create.routes.ts, authenticates both reservation endpoints as reservations.create. lib/auth/platform-jwt.ts requires subject sales (or system:delivery) and exact scope revenue.reservations.create, with token/auth and owning service Organization/resource checks. Platform's existing sales-production-to-revenue-v1 policy, capability revenue.sales-operations, already includes revenue.reservations.create within its seven accepted business scopes. The literal reservations:write is not that required scope and must not be forwarded as a substitute. Using the already approved fresh Sales-to-Revenue business policy for these existing reservation routes does not widen ADR-0052/0053. Sales must still enforce current trusted human new-action admission and original blockers; issued bearer scope is not that human provenance.

Delivery source b53b08832582dea43fba0832be5eea2a480133d3, modules/lesson-hold/routes/hold-create.routes.ts and app/api/v1/delivery/v1/lesson-holds/atomic-multi-create/route.ts, validates JSON/idempotency and hardcodes sales originator. Inspected ingress mounts are thin; no current session/tenant/Organization verification is present in these handlers. This agrees with Delivery007's source survey. Forwarding a Cookie or a reservations token alone is not producer enforcement, so this source is not authenticated compatibility proof.

The minimal required Delivery boundary is implementation of its EXISTING section 8.5 authority: verify the actual current Platform session through trusted fixed-origin Auth bootstrap semantics, establish current tenant and named Organization access before lookup/cache disclosure or mutation, deny missing/foreign reach uniformly, and retain local resource/slot/eligibility checks. Do not trust caller actor/tenant/role headers or copied Sales verdicts. Existing Sales current-human admission still needs its trusted bootstrap/app verdict and serialized original blocker checks. Preserve all-or-none local batch writes and every original protection/financial writer guard; no cross-domain HTTP under business locks. Delivery owns the concrete session adapter and all-writer/batch proof, Sales owns current-human orchestration, and Revenue owns its reservation bearer/resource/transaction proof. No new cross-domain authority design is needed merely to enforce the existing rule.

A genuine new design would be required for sessionless service-owned execution/replay of these unrelated legacy mutations, arbitrary reschedule/repoint of protected originals, or a new Sales-to-Delivery mutation JWT scope. None is approved here. Root must route such a separately requested capability for exact owning-domain approval rather than infer it from the six policies, broad business token, deadline or old unauthenticated implementation. This disposition preserves supported current-human flows; it does not claim durable autonomous recovery or installed producer authorization for them.

The concrete supported remote adapter is GET https://platform.sguildswim.com/api/bootstrap (app/api/bootstrap/route.ts mounts modules/bootstrap/routes/routes.ts) together with GET https://platform.sguildswim.com/api/auth/operator-session?app=sales (modules/auth/routes/operator-session.routes.ts), using the actual incoming human Cookie only against that fixed trusted origin. Fetch fresh with no-store and redirects disabled, bound the entire authority request, parse the closed success envelope, and require signedIn=true with a nonempty user identity. Bootstrap must establish tenant_id=tnt_sguild, activeOrg.id equal to the named command Organization, and a present non-disabled membership. The operator-session app verdict must be authorized=true and identify the SAME user. The app verdict alone is not named Organization reach: authorizeOperatorAppUser may grant app access from a SuperAdmin record or a membership in another Organization. Bootstrap tenant_id alone is also not session authority: resolveBootstrapTenantId emits the configured tenant even for signedIn=false. A copied verdict, debug bootstrap response, transport failure, signed-out response, missing membership or mismatched identity is not admission. Producer must reject these before lookup or effects and preserve the accepted 401/403 distinction. This adapter is only the existing current-human path for OTHER operations. It is not a cookie fallback on the new workload-only v2 operations.

Sales lib/platform/service-token-client.ts uses capability revenue.sales-operations and its seven explicit Revenue business scopes including revenue.reservations.create. It contains a cache/refresh promise for that existing business policy; it is not the fresh per-attempt scheduling-policy adapter and must not be cited as proof for the new ADR-0052/0053 scopes. Its nonproduction static bearer option is not Vercel production workload identity or current-human admission. Delivery must not consume this Revenue-audience bearer as Delivery authorization. Platform's new scheduling helper instead supplies skipCache=true, expirationBufferMs=0 and a fresh UUID jti to the workload-proof callback on each attempt; actual Vercel consumers must forward those fields to their installed SDK.