Grok connector integrity: proof-of-write verification (Ring 1)

[templetwo]

Why

Closes the diagnosed root cause of the Grok stack-write hallucination (open thread thread_20260524_141309). Grok narrates performing a Ring 2 write but nothing lands in pending_writes.

Root cause (verified from code): the gap is xAI-side, not ours. The Grok Ring 2 path is correct end to end, and the OpenAI bridge uses the same bridge_core pipeline and creates proposals fine. xAI's connector dispatches Ring 1 reads to our SSE handler but never dispatches Ring 2 write-class calls. The membrane is blind by design to a dispatch that never arrives.

The fix is integrity, not coercion: a model's narrated write-claim is never evidence. The only trustworthy proof of a write is a bridge-issued, queryable artifact (a real proposal_id in pending_writes with a valid audit hash). Reads do dispatch, so verification rides Ring 1.

What's in this PR (3 commits)

1. Proof-of-write primitive (bridge_core, additive):

• get_proposal_by_id() / verify_proposal() — recompute a proposal's creation-time audit hash; return found / chain_valid. found=False = "this write never landed."
• Audit variants: NARRATED_BUT_NOT_EXECUTED, RING2_CAPABILITY_FAILED, RING2_CAPABILITY_VERIFIED.
• First grok_bridge smoke test (hermetic).

2. Ring 1 exposure (LIVE — needs restart to take effect):

• verify_proposal + list_bridge_proposals as Ring 1 tools so Grok / a relay can self-verify against the real queue.

3. Connect-time capability probe (generic, detector-mode default):

• bridge_core/probe.py — pure arm/resolve/await primitive, per-connection keyed, cleans up in finally.
• probe_ring2_dispatch sentinel (Ring 2, intercepted before proposal creation as a dry-run that writes zero proposals and resolves the probe). Detects whether the connector dispatches writes at handshake.
• Detector mode by default. BridgeContext.require_ring2_probe defaults False: a timeout records RING2_CAPABILITY_FAILED but never disables Ring 2. Only require_ring2_probe=True (opt-in, e.g. Gemini from birth) hard-gates, and only for that connection. Global RING_2_ENABLED is never mutated. OpenAI is byte-for-byte unchanged (smoke 25/28 on this branch == on main).
• Live connect-await wired in handle_grok_sse behind PROBE_ON_CONNECT (env, default off), as a background task so the connection never blocks. grok_welcome instructs the model to call the probe first.

Tests

• grok smoke 62/62 (incl. real-proposal chain_valid=True, fabricated-UUID found=False, arm/resolve/timeout + cleanup, detector-vs-hard-gate invariant, dry-run writes zero proposals).
• pytest -k "bridge or pending or interceptor or audit": 9/9. Full suite: 968/968.
• OpenAI smoke unchanged from main baseline (25/28, pre-existing failures, untouched by this PR).

Operator steps (intentionally NOT done here)

This PR does not restart the running bridge and leaves the live probe off. To activate against a real Grok session: merge → restart the grok bridge → set PROBE_ON_CONNECT=true → verify the sentinel arrives (or times out, which is itself the diagnosis).

Test-depth honesty

The live SSE connect-await and the handle_bridge_tool dispatch branches are tested at the primitive/interceptor level, not through a full MCP SSE handshake (no mock for connect_sse; handle_bridge_tool reads the global _CONTEXTS registry only populated at startup). The decision logic, sentinel classification, dry-run zero-proposal guarantee, and audit events are all directly exercised.

Generalize to Gemini

Bake in from day one: write-confirmation depends on a bridge-issued queryable artifact (never response text); mandatory consumer-side verify_proposal; require_ring2_probe=True; session-level narrated-vs-landed tripwire.

🤖 Generated with Claude Code