[F167] Scheduler wake origin blocks session handoff approval

[TERRYYYC]

Summary

Long-running sessions resumed by a scheduler wake cannot call propose_session_handoff. The callback returns:

500 Approval origin message owner mismatch

This is deterministic for scheduler-driven turns, while the same handoff from an A2A-triggered turn succeeds.

Reproduction

A timer-woken invocation uses its scheduler wake row as the exact origin message. The persisted row has the shape:

{ "userId": "scheduler", "catId": null, "threadId": "<owner thread>" }

ApprovalIngress.validateOrigin verifies that the stored message belongs to originRef.threadId, then rejects it because origin.userId (scheduler) differs from the proposal owner user.

Root cause

The approval origin has two separate properties:

1. The callback producer must bind originRef.threadId, originRef.messageId, and ownerUserId to the authenticated invocation record.
2. The ingress must verify that the stored origin message is internally consistent with that bound originRef.

A system pseudo-user speaking in the already-bound owner thread is not a cross-tenant origin. The existing isSystemUserMessage predicate already requires both a system user ID (scheduler or system) and catId null/system.

The defect is therefore that the owner comparison is applied as if property 1 did not exist, on a path where it does — but, as the fix below spells out, property 1 holds per producer and not for the shared ingress as a whole. That distinction is what the original proposal got wrong.

Proposed fix

Revised 2026-08-13 (reporter). The original proposal — a global isSystemUserMessage bypass inside the ingress — is superseded and preserved verbatim at the bottom of this issue for provenance. It was rejected at PR #1347 gate 2: ApprovalIngress serves nine producers, so an ingress-level bypass is as wide as the shared ingress, while the safety argument only covered one caller (F225). Maintainer direction on PR #1349 (2026-08-12T14:57Z) accepted the catalog-scoped design below instead. This section now describes that design; the acceptance criteria were re-derived against it.

Cross-tenant isolation on this path is a conjunction of two properties, and neither is sufficient alone:

1. Caller-side binding — the producer derives originRef.threadId, originRef.messageId and ownerUserId from an authenticated InvocationRecord that a request body cannot rewrite.
2. Ingress-side consistency — validateOrigin verifies the stored origin message really does live in the thread the draft names.

Property 2 is trivially satisfiable by a draft that names a thread of its own choosing; it carries weight only because property 1 fixes which thread may be named. And property 1 is a property of a path, never of the shared ingress class. So the exemption must be gated per producer, not granted at the ingress.

Add a required field to the producer catalog:

systemOriginExemption: 'server_attested' | 'forbidden';

and make the ingress a conjunction of that capability gate with the existing store-layer predicate:

const systemOriginExempt =
  approvalProducerMeta(draft.producerId).systemOriginExemption === 'server_attested';
if (origin.userId !== draft.ownerUserId && !(systemOriginExempt && isSystemUserMessage(origin))) {
  throw new Error('Approval origin message owner mismatch');
}

What this buys over the global bypass:

• Omission is a compile error, not an inherited exemption. The field is required, so a producer added later cannot silently acquire the bypass by saying nothing.
• forbidden is the honest default, and each current forbidden value carries its own recorded reason rather than one blanket sentence: F139 and F292 never reach this predicate at all (event origin / signal admission), F221 is genuinely unbound because sourceMessageId may be supplied by the request body, and F276 needs deferred/scheduler route coverage before it could be attested.
• isSystemUserMessage is reused, not re-derived. It already requires both a system userId and a system/null catId, so a cat-authored row wearing a system userId stays rejected. A second, private definition of "is this the system" is how the two drift apart.

Scope limit, stated explicitly. systemOriginExemption is a capability gate over a declaration. It records which producers claim property 1; it is not a runtime proof that the named adapter actually binds, and a wrong server_attested value would not be caught at the ingress. It narrows the blast radius from "every message-origin producer" to "the ones someone audited and signed for" — a real reduction, not a verification. The proof has to come from the per-entry creation-site audit trail plus route-level coverage.

Acceptance criteria

• A scheduler/system-authored origin inside the authenticated owner thread is accepted for a producer whose systemOriginExemption is server_attested (F225, the reported case).
• The same origin is rejected for a producer whose value is forbidden.
• An origin authored by another human owner remains rejected, for every producer.
• userId=scheduler/system carried by a message with a real cat catId remains rejected — the exemption must not be reachable by a cat wearing a system user ID.
• systemOriginExemption is a required catalog field: adding a producer without deciding its value fails to compile.
• Each server_attested entry records an audit note naming who walked the creation site and whether the binding is DIRECT (the body may not name a different message) or TRANSITIVE (the row the originRef is built from was itself written from the record).
• Existing Approval Hub and session-handoff tests remain green.
• No schema or wire-contract change is required.

Follow-up with durable custody

The end-to-end proof that an authenticated F225 callback reaches ApprovalIngress with a scheduler-authored origin and is accepted is not in the reference PR. It is tracked in #1350 so the caller-side attestation does not rest on the catalog declaration alone — required stops an omission, it cannot stop a wrong declaration. The five ingress-level tests in PR #1349 prove the gate decides correctly; #1350 covers the premise that the F225 route actually binds.

Reference implementation

• Current: PR fix(F167): scheduler wake row is a valid approval origin only for producers that declare authenticated binding #1349 (supersedes fix(F167): a scheduler wake row was not a valid approval origin, so timer-woken sessions could never hand off #1347).
• Withdrawn: PR fix(F167): a scheduler wake row was not a valid approval origin, so timer-woken sessions could never hand off #1347 — implemented the global exemption described below.

Superseded original proposal (verbatim, kept for provenance)

Allow the owner mismatch only when the stored origin satisfies isSystemUserMessage:

if (origin.userId !== draft.ownerUserId && !isSystemUserMessage(origin)) {
  throw new Error('Approval origin message owner mismatch');
}

Keep the authenticated origin binding in each producer path; do not treat the ingress consistency check as a substitute for that binding.

Original acceptance criteria:

• Scheduler/system origin messages in the authenticated owner thread are accepted.
• An origin authored by another human owner remains rejected.
• userId=scheduler or system with a real cat catId remains rejected.
• Existing Approval Hub and session-handoff tests remain green.
• No schema or wire-contract change is required.

Why it was rejected: the exemption was granted at the shared ingress, so it applied to every message-origin producer, while the argument for it (an authenticated InvocationRecord fixing thread + owner) had only been walked for one of them. The last bullet of the original criteria is the tell — it lists no per-producer distinction at all.

[zts212653]

Thanks for separating the bug report from the implementation PR. The failure is valid and the problem direction is WELCOME, but the proposed fix and acceptance criteria still need one architectural correction before this issue can become the accepted merge anchor.

ApprovalIngress.validateOrigin() is shared by all Approval Hub producers. A global isSystemUserMessage() exemption would rely on authenticated caller-binding that is proven for the F225 callback path but is not an invariant enforced by the ingress itself. That would silently relax the owner boundary for unrelated message-origin producers such as thread, profile, and person-memory proposals.

The narrower direction is already supported by the approval-origin contract:

1. Keep the shared ApprovalIngress message-owner check unchanged.
2. Change F225's source policy from message-required to message-or-event.
3. For a real user/cat trigger, F225 continues publishing a message origin with the existing owner validation.
4. For a scheduler/system wake derived from the authenticated InvocationRecord, F225 publishes a server-attested event origin. The producer owns that distinction; the shared ingress does not learn to trust system-authored messages globally.
5. Add an integration test from the authenticated F225 callback path through ApprovalIngress for both scheduler-wake and normal message origins. Keep the generic cross-owner rejection coverage.

This uses the existing ApprovalOriginRef event variant, so it does not require a new schema or wire shape.

Please update the Proposed fix and Acceptance criteria accordingly. You can amend #1347 rather than opening another PR; implementation custody remains with you. Once the issue and branch reflect this producer-scoped boundary, we can mark the issue accepted and enter exact-HEAD formal review.

[小太阳·砚砚/GPT-5.6 Sol🐾]

[zts212653]

Architecture update after reviewing the replacement PR #1349 at exact HEAD 82086f3ec64e312aa7478baec3cb465288d12758:

We are revising the earlier implementation recommendation. The catalog-scoped systemOriginExemption design is an acceptable—and preferable—replacement for the proposed F225 event-origin path:

• the trust decision is explicit and required for every Approval Hub producer;
• only F225 currently declares server_attested;
• every other producer remains forbidden;
• the ingress still requires a real system-authored row, so cross-owner human messages and cat-authored rows carrying a system user ID remain rejected;
• a newly added producer cannot inherit this behavior by omission, because the catalog field is required.

The bug direction and the revised architecture are therefore WELCOME. Two preconditions remain before this issue becomes the accepted merge anchor:

1. Please update this issue's Proposed fix and Acceptance criteria to describe the per-producer catalog declaration instead of the current global isSystemUserMessage() exemption.
2. Please either add the authenticated F225 callback → ApprovalIngress integration test to fix(F167): scheduler wake row is a valid approval origin only for producers that declare authenticated binding #1349, or open and link a tracked follow-up issue for that caller-side proof. This proof is deferrable, but it must not disappear as an untracked note.

needs-info remains until those two items are visible. Once they are satisfied, we can mark #1348 accepted and route #1349 for exact-HEAD formal review. This is an architectural direction verdict, not a code-review approval or merge authorization.

[小太阳·砚砚/GPT-5.6 Sol🐾]