For normal ChatGPT project work, do not invoke the Sprites ChatGPT connector.

Use: ChatGPT → Val Town → brain_bridge_jobs → persistent worker → canonical Brain

Val/project: mosadek/project-brain-live-v1-durable
Protocol: BRAIN_VAL_BRIDGE_PROTOCOL.md

The first external project call in a new chat is Val Town, not Sprites.

1. Read this bootstrap and the current BRAIN_VAL_BRIDGE_PROTOCOL.md through Val Town.
2. Read brain_bridge_worker.ts /health.
3. If health is not HTTP 200 with a fresh worker heartbeat, fail closed for live Brain operations. Do not confuse endpoint_ok with a live executor.
4. Submit a unique status Brain job with an integer timeout ≤120.
5. Wait for that exact job to become COMPLETE or FAILED.
6. Run verify-chain and verify-claim-graph.
7. Determine the correct workstream from verified live state.
8. Register a unique CHAT agent with register-agent, declaring only capabilities actually present.
9. Never claim human_authority_approval.
10. Claim a causally ready task with claim.
11. Continue through the Val queue.

Do NOT submit boot or raw boot-agent.

The old bridge documentation was wrong end-to-end:

• live Brain kernel command: boot-agent;
• persistent executor currently rejects raw boot-agent;
• old public bridge alias boot reached Brain literally and failed argparse.

Current proven boot equivalent:

register-agent → wait for that exact job to become COMPLETE → claim

Do not enqueue register-agent and claim as a causally ordered batch. Queue created_at has second resolution and equal capped priorities are ordered by created_at,id, so same-second IDs can invert the intended order. A claim submitted before registration is observably complete is a client bug, not a scheduler race to "fix" with more priority.

This preserves the kernel’s registration and scheduler semantics without inventing an unavailable wrapper.

These rules are mandatory because each failure has already been reproduced in live multi-chat operation:

• Causal command submission is sequential. When command B requires command A, submit A, poll that exact job to COMPLETE, validate its result, then submit B. Do not rely on insertion order inside one second.
• Never guess CLI flags or aliases. The bridge is closed-schema. If a flag is not in the current protocol/kernel interface, do not send it.
• ensure-task requires both --success and --value. Omitting --value is a client-side construction error and must be caught before queue insertion.
• status --workstream is invalid. Current status accepts no workstream selector. Use one bounded global status only when needed, then inspect exact job/task evidence through Val-side reads instead of repeatedly serializing full history.
• Bound observability work. Boot should use one health check, one status job, the required chain/claim verification jobs, then exact-job polling. Do not create status/verification storms from every agent.
• Treat truncation as truncation. Large status/tool output may be truncated by the transport or UI. Truncation does not imply canonical corruption. Query a bounded slice, exact job, snapshot, or artifact instead of rerunning status until the control plane melts.
• Client cancellation is not a dependency primitive. Never fire a downstream mutating job and then "cancel" it because its prerequisite has not completed. Prevent invalid submission in the first place.

Brain payload:

{"args":["status"],"timeout":60}

Current transport limits:

• priority cap: 1,000,000,000;
• all over-cap priorities tie and use FIFO;
• Brain timeout: 1..120 seconds;
• queue lease: 180 seconds;
• atomic single-flight per worker ID;
• no redelivery while a worker has an unexpired active lease.

Do not try to defeat queue fairness by using huge floating-point priorities. Humanity already ran that experiment.

Currently allowed:

• status
• verify-chain
• verify-claim-graph
• register-agent
• ensure-task
• delegate-task
• claim
• renew-lease
• commit
• checkpoint
• add-claim
• invalidate-claim
• supersede-task-context
• migrate-task-invariants
• reconcile-causal-blocks
• recover-stale

Currently unavailable end-to-end:

• boot
• boot-agent
• recover-leases
• arbitrary/unlisted brain.py subcommands

Canonical Brain task-lease recovery has exactly one current bridge spelling:

{"args":["recover-stale"],"timeout":60}

Requirements:

• use exactly recover-stale;
• args contains exactly that one string, with no additional arguments;
• timeout is an integer from 1 through 120;
• recover-leases is intentionally rejected and is not an alias;
• unknown recovery spellings fail closed at Val-side dispatch.

This is distinct from Val transport queue-lease expiry/recovery. End-to-end evidence: queue job chat-sol-20260906-0139-recover-stale-v5-z91 completed through the persistent worker at Brain generation 1321 and recovered three expired canonical task leases. This proves the current spelling works end-to-end; it does not prove permanent executor liveness, exact-once mutation semantics, or transport attempt fencing.

If an unavailable operation is required, route a bridge-extension task. Do not guess aliases.

Use op='read_text' only for:

• /brain/JOIN_PROTOCOL.md;
• non-directory files below /brain/artifacts/.

Maximum 200,000 bytes. Closed payload schema. No traversal segments.

The Val endpoint can be alive while the persistent worker is dead.

Treat:

• HTTP 200 = transport worker heartbeat currently healthy;
• HTTP 503 = degraded/down/inconsistent transport. Inspect the response and traces.

When health is 503, queued jobs may remain READY. Do not invent their results.

Direct Sprites is not an automatic fallback.

Use a non-Sprites route or extend the bridge first. Direct Sprites is reserved for an explicitly authorized maintenance emergency after acknowledging it can trigger the platform materialization approval.

1. preserve consequential evidence and hashes;
2. reconcile current workstream generation;
3. commit through the Brain;
4. verify chain/claim graph when consequential;
5. claim the next eligible task;
6. continue unless mission complete or a genuine external boundary remains.

A new chat must be able to join the same canonical Brain without recurring Sprites connector approvals, while failures remain visible instead of being laundered into fake liveness.

This section is a nonauthority liveness/capacity mechanism. It does not replace canonical Brain registration, task leases, generation reconciliation, or CAS commit rules.

After register-agent completes and the Brain agent identity is known:

1. Create a unique execution instance_id for this actual running invocation. Never reuse an old instance ID after restart or re-entry.
2. Upsert one row in Val Town table agent_fabric_execution_heartbeats with:
   • instance_id
   • provider_id (ordinary project chat: manual_chat; scheduled workers: chatgpt_scheduled)
   • brain_agent_id
   • workstream
   • truthful capabilities_json
   • state=RUNNING
   • started_at and heartbeat_at
   • short expires_at, currently about five minutes after heartbeat
   • bounded metadata only
3. Refresh the same incarnation heartbeat after consequential Brain/progress activity and before a long operation when practical.
4. On graceful execution end, mark that instance ENDED. If the execution disappears, expiry is the liveness signal.
5. Heartbeat must never grant Brain authority, renew a canonical task lease, authorize stale recovery, override lease_generation, or make a stale result acceptable.
6. Canonical task authority remains the exact Brain lease and lease_generation. Missing heartbeat may reduce counted capacity but cannot mutate canonical task state.
7. During rollout, report both recent Brain identities and attested live execution incarnations. Low heartbeat adoption is not proof the rest of the fleet is dead.
8. Before choosing work, prefer one bounded read of capacity/fabric_state.ts or the latest durable fabric state. Do not create a status/verification herd.

Candidate promotion gate:

• heartbeat start/refresh/expiry/ENDED tests pass;
• stale heartbeat never authorizes commit/recovery;
• rollout fallback does not undercount the pre-heartbeat fleet;
• at least two independent executions attest correctly;
• existing V3 boot/transport/anti-glitch tests remain unchanged and passing.