Verify the two-owner A-only idle-host response pilot #24

Parent-Issue: #1
Blocked-By: #21, #22, #23

Owner-approved acceptance change — 2026-11-12

The owner selected A = OpenAI ChatGPT and B = Claude Chat, then explicitly changed the acceptance condition: only A must act after receiving an event. B may be manually prompted to make the authenticated synthetic seed posts. The required causal path is B post → idle A receives the committed peer event → new A run → authenticated read → committed A reply, including a fresh B post after retained-state restart. B's event subscription, idle wake-up and autonomous reply are not requirements. This supersedes the earlier bidirectional wording; independent identities/consents and the other correlation, cancellation, retry, restart, isolation and disclosure requirements remain.

Objective

Demonstrate that a real, independently authorized Claude Chat B post causes idle OpenAI ChatGPT A to authenticate, read and reply through an incoming peer event without a human wake-up prompt to A. Publish this as A-only autonomous response evidence, without claiming bidirectional host autonomy.

Context

Preflight stage Y. Baseline c087e39d2b2688c1c6654957215467d1c6e1abb0 contains no runtime or host evidence. Sources: notifications.md, product.md and implementation-plan.md. #21 supplies bounded durable webhook delivery; #22 supplies isolated test/release controls and safe operations; #23 supplies measured real-host guest OAuth. Their closure supplies browser consent, separate guest memberships, transcript/lifecycle and notification authority.

Current producer of autonomous-host evidence: none. This child observes and joins actual owner-authorized host runs with the same committed events and transcript; it does not build a hosted agent or treat a provider feature description as execution evidence. Two eligible independently controlled owner accounts and a reachable approved test endpoint are external prerequisites. No private household conversation or imported personal memory is required; use synthetic content.

Requirements

REQ-001: Provide a reproducible two-owner pilot with independently authorized guest identities, connections and real target-host agents, bounded standing instructions approved separately by each owner, one shared private table, A's verified subscription and synthetic discussion content; record host/version or exposed build identity, account/workspace eligibility, protocol/profile, test date and the deployed build/configuration evidence for each participant.
REQ-002: After A's subscription is active and host A has no active run, demonstrate that an actual authenticated post by Claude Chat B causes the corresponding committed peer event to be accepted by ChatGPT A's host, starts a new A run, and leads A to authenticate, read the same table and commit a reply without a human wake-up prompt, message copy/paste, scheduled polling substitute or scripted host replacement. Manual prompting of B's seed post is allowed. B's event subscription, idle wake-up or autonomous return turn is not required.
REQ-003: Correlate each observed turn's committed message/event identity, safe delivery observation, actual host-run evidence, authenticated read and committed reply with its distinct sender membership and ordered sequence; receiver HTTP 2xx, a connector badge, background process activity or a model's claim of completion alone cannot satisfy the run/reply predicate, and an exact mutation-key retry must not create another accepted transcript message.
REQ-004: Exercise closure or unsubscribe while further work is pending and verify no newly authorized delivery starts after the terminal decision, with already-dispatched traffic reported separately; demonstrate a retained-state service restart followed by a fresh authenticated B post continuing through the real A event/run/read/reply path without resetting server retry state or resurrecting a closed/deleted/expired conversation.
REQ-005: Verify that a third unaffiliated guest cannot read private metadata/transcript/inbox or maintain A's subscription (or any other subscription present), and that only deliberately posted synthetic content crosses the relay; preserve bounded instructions to stop, request owner input beyond delegated authority and avoid repeated acknowledgments without claiming the service controls private reasoning or can authorize agreements for the owners.
REQ-006: Publish a redacted reproducible compatibility record with separate tools-verified, notification-receipt-verified and autonomous-reply-verified results for the exact tested hosts/profile/build and explicit A-only acceptance mode, including B's tools-only role and host-specific restrictions, actual duplicate-delivery behavior and explicit not-run/failed/blocked cases; do not generalize to untested hosts, claim exactly-once reasoning or treat the manual fallback as successful completion of this autonomous gate.
REQ-007: Add an executable test/probe procedure that gathers safe server and host observations and validates their same-run/event/transcript association, retain deterministic server regressions separately from the real-host pilot, and require the positive B-to-idle-A event/read/reply turn plus the scoped cancellation/restart/isolation evidence before reporting this gate complete; unavailable accounts, missing A run observability or unsupported required A event execution remain explicit blockers rather than fabricated results or silently weakened requirements.

Acceptance Scenarios

• Given two eligible owners with independently approved instructions, A's active subscription and idle A, when Claude Chat B is instructed to make the initial authenticated synthetic post, then ChatGPT A starts because of the peer event, reads and replies without a human prompt to A; B does not need event execution capability (REQ-001–REQ-003).
• Given receiver acceptance but no observable host run or committed reply, when evidence is classified, then notification receipt may be verified while autonomy remains unverified; a person clicking continue cannot fill the missing causal step (REQ-002, REQ-003, REQ-006).
• Given a pending later turn, when the table is closed or the relevant subscription is unsubscribed before a new dispatch is authorized, then no forbidden new attempt starts; a pre-existing dispatched request is recorded honestly rather than claimed recalled (REQ-004).
• Given A's retained live subscription and an allowed table, when the service is restarted while retaining storage and a fresh eligible B message is posted, then the real event/host-A/read/reply path continues; a later terminal table does not revive on the same recovery path (REQ-004).
• Given a third guest who knows the table/inbox identifiers, when private reads or subscription maintenance are attempted, then access is denied without leaking the transcript or private callback metadata (REQ-005).
• Given only mocked host responses or missing eligible accounts, when the pilot is evaluated, then it remains blocked/not-run rather than being labeled autonomous (REQ-006, REQ-007).

Non-goals

Hosting a model, importing personal chat histories, making purchases or binding agreements, guaranteeing exactly-once reasoning or external effects, forcing unsupported hosts to run, public plugin-directory submission, or substituting manual/scheduled message relaying for event-driven execution.

Initial Implementation Prompt

Guidance only; Requirements are the sole merge-blocking contract.

Verified baseline and integration boundary

Reinspect #21's actual delivery/status behavior, #22's test environment/profile gates and #23's measured host record. At the inspected revision no agent run, deployment, probe, class or helper demonstrates this objective. The new output is a joined real-world compatibility trace, not another producer of message, authorization or delivery state.

An external host owns its run lifecycle and may expose different observation surfaces. Establish in advance how a genuinely new run and its initiating event can be observed for the selected product; do not use a model-written sentence as that evidence. If the host offers no sufficient observation, mark the scenario unverified and identify the exact missing signal. Do not invent access to provider internals.

Proposed files and ordered procedure

1. Add docs/compatibility/autonomous-pilot.md with two-owner prerequisites, synthetic scenario, separate owner-consent steps, exact stop/closure instructions, evidence fields and not-run defaults. Extend test/e2e/host/ with safe correlation/evidence validation utilities, adapting to the actual scaffold (REQ-001, REQ-007).
2. Use an explicitly approved isolated candidate deployment. Verify the build SHA, guest-OAuth evidence for each host and A's real active subscription record. Keep public support flags distinct from this private verification run; account eligibility and endpoints are not guessed (REQ-001).
3. Have each owner approve bounded table-only instructions: disclose only the synthetic supplied information, read before replying, use original mutation keys on uncertain retries, avoid repeated acknowledgments, stop at closure/limits, and ask the owner before exceeding delegation. Do not install one participant's text as another agent's privileged instructions (REQ-001, REQ-005).
4. Establish A's idle/no-active-run state through the host's supported observation surface. Manually initiate B's authenticated seed post, then capture the same committed event, A receiver acceptance, new A run, authenticated table read and committed A reply without human wake-up or relay to A. A return event to B is not required (REQ-002, REQ-003).
5. Reuse safe correlation fields from server telemetry and minimal host observations. Match event/message IDs, membership, ordering, timestamps and endpoint build. Store no tokens, cookies, callback URLs, invitation secrets or unrelated personal chats in the evidence artifact (REQ-003, REQ-006).
6. Perform the scoped cancellation and storage-preserving service restart exercises in separate synthetic runs so stopping one table does not implicitly reopen it. Observe pending versus already-dispatched attempts, and make a new eligible message on a still-live table prove post-restart progress. Preserve server budgets and terminal state (REQ-004).
7. Attempt third-guest reads/subscription maintenance through real authenticated entry points. Check the known identifiers cannot replace membership/ownership, and record bounded traffic versus private host reasoning without equating them (REQ-005).
8. Add a small validator/report generator for the collected safe evidence and keep controlled-receiver/SDK server regressions separate. Update docs/notifications.md, docs/references.md and release-readiness documentation only for exactly observed host/profile/build combinations (REQ-006, REQ-007).

Interfaces and verification oracles

Proposed observation record: scenario ID, tested build/profile, pseudonymous owner/membership, event/message IDs, delivery result, independently observed host run identifier or supported trace reference, authenticated read evidence, reply receipt and stop/restart outcome. A missing stage stays unknown, never inferred from the next prose claim. Preserve the distinction between an event being received and a host choosing to execute.

REQ-001 -> independent consent/account/profile record; REQ-002 -> B post joined to A's idle-to-new-run-to-read-to-reply trace; REQ-003 -> same-event correlation and unique accepted operation receipts; REQ-004 -> cancellation and storage-preserving restart observations; REQ-005 -> third-guest denial and synthetic-only disclosure; REQ-006 -> exact-target layered compatibility report; REQ-007 -> runnable evidence collection/validation procedure plus actual positive and boundary evidence.

Verification commands and limitations

Run the existing npm typecheck/lint/test/test:integration/test:e2e suites relevant to the server before the live pilot. Document actual host-probe commands once introduced; provider account setup and B's seed posts may be manual, but manually initiating A's responding run is not an autonomous pass. Record remote host evidence separately from local CI. No host test, server test or deployment ran during authoring.

Do not replace the hosts with SDK scripts, trigger hidden polling, send A a human continue prompt to initiate its responding run, infer a new run from HTTP acceptance, or declare a restored/closed conversation recovered by creating a replacement table. These shortcuts would fail REQ-002–REQ-007. Minor test-layout changes are allowed; genuine provider limitations or missing prerequisite evidence must be surfaced without changing the fixed Objective. Completion requires every REQ mapped to its actual observed boundary and redacted verification record. Controller Git/publication instructions take precedence.