PROJECT BRAIN VAL BRIDGE PROTOCOL V6

Canonical activation condition: This protocol is authoritative only while the exact production kernel bytes bound below are installed, the current admission-head artifacts match their pinned identities, and fresh production status + verify-chain + verify-claim-graph pass. Any mismatch fails closed before registration or claim.

Activation gate: Protocol V6 no-receipt CHAT_UNPROVEN registration/claim is authorized if and only if canonical task BRAIN-FIRST-SUPERHERO-CHAT-UNPROVEN-PROTOCOL-WRITE-RECONCILIATION-P0-V1-20260908 is COMPLETE, its result_event_id binds to a TASK_RESULT_COMMITTED event for that exact task, and the committing activator is not CHAT_UNPROVEN. Until then, a no-receipt execution may perform only local Val Town artifact/source reads plus bounded read-only verification after the admission bundle passes; it MUST NOT register-agent or claim. A preactivation CHAT_UNPROVEN lease may not renew or self-commit the activation task. This gate does not grant physical execution provenance or P_real.

V6 reconciliation delta: Exact historical comparison shows the Protocol-V5-pinned kernel was 83008 bytes / SHA-256 600ddab6a1591a34a7e22e06a41fb2f5a838267f3b56e33c809d08ac6471f756, while current production is 84299 bytes / SHA-256 087cb4b5a57c16a6f19353357704fe943d7341961690aff11ec36c75ca5d8af9. The four post-V5 drift regions are not accepted wholesale. Protocol V6 restores the V5-pinned claim-selector semantics, including all legacy reviewer/distinctness context fences, and removes the hard <128 active slots => scaling-only claims rule because SUPERHERO_REALIZATION_FOCUS_POLICY_V1 explicitly requires first-superhero completion before staged scaling. Two deliberate hardenings remain: (1) the previously protocol-level CHAT_UNPROVEN activation rule is now structurally enforced in the kernel, including exact activation-task/event binding and anti-self-activation fences; and (2) migrate-task-invariants is removed from the atomically qualified mutation allowlist while remaining recognized/fail-closed. Bound production kernel: 85474 bytes / SHA-256 e38c8bc4b78aed9199ba5e3f4b79b95f5914a508f9069fe10e75fcf8767227c9. Builder static/semantic regression is 38/38 PASS. External model review attempts were non-diagnostic and are not counted as verification.

Normal ChatGPT project work uses Val Town as the only ChatGPT-facing transport to the canonical Project Brain. Direct Sprites connector calls are maintenance-only because they can trigger separate file-materialization approval prompts.

Normal path:

ChatGPT → Val Town → brain_bridge_jobs → authority-selected Brain executor → canonical Brain

Val/project: mosadek/project-brain-live-v1-durable
Queue: brain_bridge_jobs
Control-plane authority: brain_control_plane_authority_v1

Before substantive Project Brain reasoning, planning, claiming, implementation, review, or promotion, every worker MUST load the current constitution-head pointer:

• head pointer: valblob:mosadek/project-brain-live-v1-durable/evidence/user-directives/CURRENT_THINKING_CONSTITUTION_HEAD.json

Then load the exact registry and constitution URIs named by that head and verify the constitution bytes against the head's SHA-256 before relying on it.

Current verified admission-head artifacts for Protocol V6 (still re-read the head pointer; these values are not a substitute for it):

• head: evidence/user-directives/CURRENT_THINKING_CONSTITUTION_HEAD.json, 1824 bytes, SHA-256 ac6be68568b14c54fc4919f00eae51baa6fa5770be8fcd7b3151cdb0d4ecbc83;
• constitution V4: valblob:mosadek/project-brain-live-v1-durable/evidence/user-directives/PROJECT_BRAIN_THINKING_CONSTITUTION_V4.md, 24630 bytes, SHA-256 36034b7e499f7476e2d1ac8558e7203dcc00ae1bea54919543cd3541ce0bde62;
• teaching registry V5: valblob:mosadek/project-brain-live-v1-durable/evidence/user-directives/USER_TEACHING_REGISTRY_V5.json, 4257 bytes, SHA-256 05c85b6a0e98a711263d9042b4ea728ac99d16fe032840eb199b729fb6a7dbde;
• canonical superhero definition V1: 7786 bytes, SHA-256 50fdd99f02b78aff8ba5fb89a98124c176c311ca8a08f7a92777be570f193a29;
• superhero realization focus policy V1: 3433 bytes, SHA-256 a4dfc1a488a50ac8eb2471085a88c3aa9b27a2cdfe455be8d6e235811865fa62.

The constitution is project-level operating law after system/safety/platform-enforced policy and the user's current explicit instruction.

Boot is cognitively incomplete if the constitution head was not loaded. Memory summaries, old prompts, role descriptions, and historical architecture are discovery pointers only and do not substitute for the current head.

Mandatory reasoning invariants include:

• FASTEST RIGHT WAY: minimize real wall-clock time to the correct independently verified goal;
• first-principles decomposition before accepting architecture assumptions;
• CURRENT IMPLEMENTATION LIMIT != MISSION LIMIT;
• do not label platform/tool/quota/API/UI limitations fundamental without active elimination attempts;
• delete/replace useless or materially suboptimal mechanisms when that improves the mission objective;
• continuously recompute the critical path;
• treat platforms/providers/tools as replaceable tactics;
• prefer structural enforcement over permanent intelligent babysitting when both preserve the invariant;
• preserve exact evidence and fail closed rather than hallucinating success;
• distinguish COMPLETE from PASS, configuration from execution, and logical identity from real execution provenance.

Future durable user teachings are cumulative unless explicitly superseded. Preserve them as immutable user-directive evidence, classify them as EXTENDS / REFINES / SUPERSEDES, create a successor constitution version, update the registry head, and preserve prior versions. Never silently overwrite the user's reasoning doctrine.

At epoch 2 the live canonical writer is currently val_native. The historical host worker identity project-brain-live-v1-worker-v2 remains compatibility evidence, not current writer authority.

The HTTP endpoint being reachable is NOT proof that the authority-selected Brain executor is alive.

brain_bridge_worker.ts /health is the historical host-bridge worker health surface. Its worker_state applies only to that host worker. Read control_plane_authority.writer before interpreting it:

• if writer is host_bridge, HTTP 200/503 and worker_state are relevant to canonical executor liveness;
• if writer is val_native, a stale host heartbeat does NOT mean the canonical control plane is down;
• endpoint_ok:true only proves the Val endpoint itself is executing;
• worker_health_scope:HOST_BRIDGE_WORKER_ONLY is an explicit interpretation fence;
• instance_identity_available:false means the historical host worker has not supplied a distinct process instance ID. Do not overclaim process identity;
• canonical status/chain/claim-graph receipts remain the authoritative proof of Brain state reached through the current writer path.

Current Val-side invariants:

• priority cap: 1_000_000_000;
• selection above the cap: FIFO by created_at,id;
• maximum Brain command timeout: 120 seconds;
• queue lease: 180 seconds;
• atomic single-flight per worker_id;
• an active unexpired lease is not redelivered to another poll sharing that worker ID;
• a pre-existing duplicate active lease for one worker ID fails closed;
• expired queue leases are terminalized FAILED on a worker poll with TRANSPORT_LEASE_EXPIRED_OUTCOME_UNKNOWN; they are not automatically returned to READY;
• an expired/unknown attempt must be reconciled against canonical state before any retry is submitted under a new job ID;
• results are accepted only for the current unexpired lease owner.

These are transport invariants, not Brain authority.

Canonical Brain integrity and independently verified replica durability are separate facts.

The worker health body exposes:

• durability.canonical_generation;
• durability.max_verified_replica_generation;
• durability.verified_replica_count;
• durability.lag_generations;
• durability.state = CURRENT | LAGGING | UNKNOWN.

Interpretation:

• a canonical generation newer than the latest verified replica is valid canonical progress, but it is NOT fully replicated durability;
• never report fully durable while lag_generations > 0;
• durability lag does not by itself invalidate read-only canonical status/verification;
• before destructive cleanup, authority transition, or a claim whose consequence depends on recoverability, explicitly account for the lag and preserve consequential evidence first;
• never hide durability lag by reading an older replica as though it were current canonical state.

The Brain kernel keeps the strict expected-workstream-generation commit guard, and the epoch-2 Val-native executor keeps the authenticated queue payload_json byte-identical for the lifetime of one transport attempt. Production does not transparently rewrite a commit payload to inject a fresher generation.

To prevent admission churn from starving an already-READY commit, the transport selector applies a bounded commit-position barrier. A valid READY status, verify-chain, verify-claim-graph, register-agent, or claim job may not leapfrog a valid READY commit that is older by created_at, with rowid breaking same-timestamp ties. recover-stale remains recovery-first. Admission/read jobs genuinely older than the commit retain their existing place, and the same-second register-before-claim invariant remains unchanged.

This barrier does not declare unrelated canonical mutations semantically harmless. If an earlier mutation legitimately advances the workstream before a commit executes, the strict kernel may still return STALE_WORKSTREAM_WRITE; the caller must reconcile canonical state and submit a new job ID with a fresh expected generation. The bounded guarantee is narrower and auditable: later boot/read admission traffic cannot indefinitely leapfrog an older READY commit. Exact job, lease instance, lease attempt, transport generation, authority epoch, payload identity, task lease, dependency/guard/write semantics, and duplicate-terminal fences remain unchanged.

Historical evidence for the earlier task-local stable-retry design remains at valblob:mosadek/project-brain-live-v1-durable/evidence/control_plane/val_native_stable_commit_retry_v1.json, including its independent artifact_present falsification and repair. That mechanism is historical evidence, not the current production dispatch behavior.

A fresh ChatGPT context is not proof of a physically distinct or superhero-qualified execution merely because it can choose a new agent_id, write a queue row, or read this protocol. Logical identity is not physical execution provenance.

Before a normal worker emits any boot-cohort queue traffic (status, verify-chain, verify-claim-graph, register-agent, or claim), the current cognitive-constitution head and every current registry/definition/focus-policy artifact it relies on for admission MUST be loaded from the connected Val Town project surfaces and byte/hash-verified. Missing, stale, ambiguous, or mismatched hashes fail closed before registration or claim.

For Protocol V6, the exact admission bundle is:

• head: evidence/user-directives/CURRENT_THINKING_CONSTITUTION_HEAD.json, 1824 bytes, SHA-256 ac6be68568b14c54fc4919f00eae51baa6fa5770be8fcd7b3151cdb0d4ecbc83;
• constitution V4: 24630 bytes, SHA-256 36034b7e499f7476e2d1ac8558e7203dcc00ae1bea54919543cd3541ce0bde62;
• teaching registry V5: 4257 bytes, SHA-256 05c85b6a0e98a711263d9042b4ea728ac99d16fe032840eb199b729fb6a7dbde;
• canonical superhero definition V1: 7786 bytes, SHA-256 50fdd99f02b78aff8ba5fb89a98124c176c311ca8a08f7a92777be570f193a29;
• superhero realization focus policy V1: 3433 bytes, SHA-256 a4dfc1a488a50ac8eb2471085a88c3aa9b27a2cdfe455be8d6e235811865fa62;
• production val_native_kernel_v1.ts: 85474 bytes, SHA-256 e38c8bc4b78aed9199ba5e3f4b79b95f5914a508f9069fe10e75fcf8767227c9.

The head's referenced URIs are authoritative for the four directive artifacts above. Protocol V6 is active only while canonical production matches the bound kernel identity and the activation gate above is satisfied. Any later head, referenced-artifact, or production-kernel mismatch makes Protocol V6 no-receipt admission stale and fail-closed until a successor explicitly reconciles the new bytes. Never treat historical candidate identity, comments, or builder tests as production activation evidence.

After that verification there are exactly two ChatGPT admission classes:

1. Positively admitted execution. If this execution is given a current project-controlled fabric/admission execution-incarnation receipt, validate the receipt exactly as before: it must be positively exposed rather than invented in model text, indicate BOOTING or RUNNING, carry an unexpired liveness signal, bind the intended logical identity/workstream/capability declaration, and contain no unresolved duplicate-incarnation ambiguity.
2. Ordinary unproven contribution. If no positive execution-incarnation receipt is exposed, the execution MAY enter only as agent type=CHAT_UNPROVEN. This is a useful-contribution lane, not execution provenance. It proves neither physical distinctness, independent-review eligibility, autonomous proven supply, superhero capacity, nor any P_real increment.

Caller-authored payload fields, a registry row, a queue row, a chat transcript, memory, a different agent_id, schedule ownership, heartbeat ownership, or a candidate-only attestation never upgrade CHAT_UNPROVEN into a proven execution.

The production kernel is the trust boundary for the unproven lane. Before using that lane, callers MUST verify that the current authority-selected kernel still enforces all of the following machine semantics:

• execution_distinct is fail-closed unless a separately accepted positive ingress exists;
• CHAT_UNPROVEN is categorically rejected for execution_distinct, even if a later positive ingress exists;
• legacy machine-readable independence markers, including independent_verification and the current reviewer/distinctness context flags, are skipped by CHAT_UNPROVEN;
• a CHAT_UNPROVEN TASK_RESULT_COMMITTED event receives kernel-injected contributor_trust_class=CHAT_UNPROVEN, contributor_agent_type=CHAT_UNPROVEN, independence_eligible=false, and p_real_eligible=false;
• caller-controlled trust metadata cannot upgrade the result;
• ordinary claim, lease, CAS, write-conflict, dependency, guard, and authority fences remain unchanged.

If those kernel semantics cannot be positively verified, the no-receipt lane fails closed and MUST NOT register or claim.

For either admission class, consume a current shared/coalesced status + chain + claim-graph receipt when one is available and correctly bound to the current authority/head. A CHAT_UNPROVEN execution may refresh missing/stale read-only verification through the normal Val-native queue only after the local hash prerequisites above pass; avoid one redundant verification trio per execution whenever a valid shared receipt exists.

Current verified ChatGPT-specific boundary at this revision remains:

• BRAIN-CHAT-MCP-SESSION-EXECUTION-PROVENANCE-P0-V1-20260908 concluded EXTERNAL_PRODUCT_CONNECTION_BOUNDARY;
• positive physical ChatGPT-session provenance is not proven;
• P_real increment from that candidate is 0;
• a different logical agent_id alone is not evidence of a distinct ChatGPT execution.

Therefore lack of a positive execution-incarnation receipt no longer blocks all useful work. It restricts the execution to CHAT_UNPROVEN ordinary contribution, with independence-sensitive work and proven-capacity accounting structurally unavailable.

The repaired cohort fast path is also not production-qualified at this revision. Current reconciled V3R1 candidate SHA-256 is 4031e62868abc9d7562f33e3986f0f5a29ec71c0a19b8e75ee4520071ef6e7ee; its builder/self-falsification evidence is candidate-only, its genuinely distinct second-party gate remains required, and production integration is forbidden until that gate and any later promotion/integration gates pass. Do not route normal boot through it merely because it is faster in tests.

Both the positively admitted path and the CHAT_UNPROVEN fallback use the individual compatibility sequence described below when no qualified cohort path is available. That sequence creates a logical Brain identity and task lease; it does not retroactively prove the physical execution that invoked it.

Protected UI creation is not a boot mechanism. Normal boot MUST NOT require or automate ChatGPT New Chat, prompt pasting, Got it/modal dismissal, browser clicking, rate-limit evasion, fake identities, or one Val branch per agent. Manual New Chat is emergency fallback only, not normal capacity provisioning.

Insert a unique job:

INSERT INTO brain_bridge_jobs
(id, priority, op, payload_json, state, lease_owner, lease_expires_at,
 result_json, error_json, created_at, updated_at)
VALUES (?, ?, 'brain', ?, 'READY', NULL, NULL, NULL, NULL,
        datetime('now'), datetime('now'))

Brain payload is closed-schema:

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

Requirements:

• exact top-level keys: args, timeout;
• args is a non-empty string array;
• timeout is an integer from 1 through 120;
• status, verify-chain, and verify-claim-graph take no additional Brain arguments;
• renew-lease uses canonical --seconds; stale --lease-seconds is rejected fail-closed;
• boot, boot-agent, recover-leases, unsupported artifact commands, and payloads with extra top-level fields are not compatibility aliases.

Recognized Brain subcommands at the bridge syntax layer:

• 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

Do not confuse recognized with currently executable.

While control-plane authority is epoch-2 val_native, the current atomically qualified execution surface is exactly:

• read-only: status, verify-chain, verify-claim-graph;
• mutation: register-agent, ensure-task, claim, renew-lease, commit, recover-stale, supersede-task-context.

The remaining recognized mutators other than the explicitly qualified set above are implemented but deliberately fail closed with VAL_NATIVE_MUTATOR_NOT_YET_ATOMICALLY_QUALIFIED until an independently verified reactivation changes the canonical Val-native allowlist. Clients MUST NOT enqueue them merely because the syntax layer recognizes their names. Re-read the current authority-selected executor before relying on a newly reactivated mutator.

Anything outside the recognized syntax surface fails at Val-side dispatch rather than being sent onward.

There is currently NO valid atomic boot bridge command.

The public bridge previously advertised boot, but the live kernel accepts boot-agent while the persistent executor rejects raw boot-agent. Therefore neither spelling is a valid end-to-end bridge operation.

Normal fresh-chat boot is the live-fabric admission gate above, not blind register-agent → claim. A fresh context must first verify the current constitution/registry/definition/focus-policy hashes and the current authority-selected kernel semantics.

After those checks:

• if a valid positive execution-incarnation receipt is exposed, use the admitted execution class and preserve its exact receipt-bound type/capability semantics;
• if no positive receipt is exposed, use only type=CHAT_UNPROVEN;
• if the required hashes, chain/claim-graph state, or CHAT_UNPROVEN kernel fences cannot be verified, stop before registration/claim.

The individual compatibility sequence for either allowed class is:

1. consume or refresh bounded status + verify-chain + verify-claim-graph evidence as required by the live-fabric rules;
2. register-agent;
3. claim.

This sequence establishes only the logical Brain identity and task lease. For CHAT_UNPROVEN, it explicitly does not prove private model cognition, distinct physical ChatGPT execution, independent-review eligibility, superhero capacity, autonomous proven supply, or P_real.

The transport selector preserves a same-second paired compatibility invariant: when READY register-agent and claim jobs have the same created_at and exact agent identity, the registration is selected before its claim even if the claim has a higher submitted priority. Clients must not depend on priority to reverse that order.

Register only capabilities actually present in the execution. Never claim human_authority_approval. A no-receipt execution MUST register with --type CHAT_UNPROVEN; using CHAT, PROVEN_EXECUTION, or another stronger label without the corresponding positive admission evidence is forbidden.

No-receipt ordinary contribution example:

register-agent <new-logical-agent-id> --workstream <ws> --role <role>
  --type CHAT_UNPROVEN --capabilities <json-array>

claim --agent <new-logical-agent-id> --mode INTERACTIVE --lease-seconds 1800
  --constitution-version <current-head-version>
  --constitution-sha256 <current-head-sha256>
  --registry-version <current-registry-version>

A positively admitted execution may use the same sequence with its exact receipt-authorized type instead of CHAT_UNPROVEN.

Do not submit boot or boot-agent until a later verified bridge/executor revision explicitly restores an atomic wrapper. Do not promote the candidate cohort path until its required distinct second-party and production-integration gates actually pass.

Canonical Brain task-lease recovery is exposed through exactly one bridge spelling:

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

Requirements:

• the Brain subcommand is exactly recover-stale;
• args contains exactly that one string and no additional arguments;
• timeout remains 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.

Val transport queue-lease expiry remains a separate transport mechanism. The worker detects expired transport attempts on poll and terminalizes them FAILED with unknown canonical outcome; it does not treat transport expiry as proof that the Brain command had no effect.

End-to-end evidence: queue job chat-sol-20260906-0139-recover-stale-v5-z91 completed through the persistent V5 worker at Brain generation 1321 and recovered three expired canonical task leases. This establishes the current recovery path; it does not prove permanent executor liveness or transport attempt-fencing.

SELECT id,state,lease_owner,lease_expires_at,result_json,error_json,updated_at
FROM brain_bridge_jobs
WHERE id=?

Terminal states:

• COMPLETE
• FAILED

A READY job means it has not been executed. A LEASED job is not complete. Do not infer canonical mutation from queue state alone.

The currently authoritative epoch-2 val_native executor accepts only op='brain'. It rejects queue op='read_text' with VAL_NATIVE_UNSUPPORTED_TRANSPORT_OP.

Therefore while brain_control_plane_authority_v1.writer='val_native':

• DO NOT enqueue read_text jobs for /brain/JOIN_PROTOCOL.md or artifacts;
• read Val-hosted project source/protocol files through the connected Val Town file tools;
• obtain canonical Brain state through the allowed brain commands and bounded project-controlled read-only canonical views;
• do not convert a missing transport read operation into a reason to call Sprites.

The historical host bridge still contains a bounded read_text implementation for compatibility. It is eligible only if host_bridge is again the authoritative writer and the exact current executor path is independently shown to support it. Historical successful reads do not establish epoch-2 support.

Routine ChatGPT work:

• DO NOT call Sprites;
• DO NOT call Sprites.exec;
• DO NOT call Sprites.file_read/file_write/file_copy/file_delete;
• DO NOT call Sprites service/checkpoint/file/blob operations.

If a required operation is missing:

1. use an existing valid non-Sprites substrate when possible;
2. route or build a bridge extension;
3. fail closed if the missing operation is necessary;
4. direct Sprites remains an explicit maintenance emergency, not an automatic fallback.

If a fresh context lacks a valid positive execution incarnation:

• verify the current constitution/registry/definition/focus-policy hashes and the current authority-selected CHAT_UNPROVEN kernel fences;
• if those checks pass, enter only through the bounded CHAT_UNPROVEN ordinary-contribution path;
• if any prerequisite is missing, stale, ambiguous, mismatched, or the kernel no longer enforces the unproven trust boundary, enqueue no registration/claim and return the exact failing prerequisite;
• never reinterpret absence of a positive receipt as physical-session proof, independent-review eligibility, proven autonomous supply, superhero capacity, or P_real.

For already-admitted work, if jobs stay READY:

1. inspect /health;
2. inspect worker endpoint traces;
3. inspect the current active/expired queue leases;
4. do not raise transport priorities above the cap to win a queue arms race;
5. do not interpret the Val endpoint being online as the Brain worker being online.

If worker health is DOWN:

• queued commands remain pending;
• no live Brain registration, claim, commit, status, or verification should be invented;
• Val-side code/evidence work may continue when it does not pretend to mutate canonical Brain;
• repair/restore the persistent executor through an authorized route, then resume queue processing.

The reverse bridge has successfully:

• read Brain status;
• created canonical Brain tasks;
• registered CHAT agents;
• claimed tasks;
• committed task results;
• run verify-chain and verify-claim-graph.

The Val-side worker has independently reproduced and repaired the same-worker concurrent lease race in isolated queue tests. This does NOT prove the persistent Sprite-side executor is permanently supervised or continuously alive.

Normal ChatGPT/Brain work MUST NOT create one Val Town branch per agent.

Use task-scoped project blobs for scratch/evidence first. Use task-namespaced files on main only when shared executable/source bytes are necessary and the Brain task's declared write-resource lease permits them. Use a bounded reusable scratch branch only when branch isolation is causally required. A net-new branch requires an explicit task need, a branch-headroom check, and a preservation/cleanup plan.

Do not delete a branch merely because it is old, low-version, or apparently merged. Before deletion apply VAL_BRANCH_LIFECYCLE_POLICY_V1.md; any unresolved dependency or unique-evidence question means KEEP.

The scaling invariant is:

d(live_branch_count) / d(agent_count) = 0

This keeps the reproduced Val Town branch ceiling out of the normal agent-admission path.

Normal project work must stay materialization-free from ChatGPT while remaining fail-closed:

verified local project state → {positive admitted execution | CHAT_UNPROVEN ordinary contributor} → Val Town → durable queue → authority-selected live executor → verified Brain

A fresh ChatGPT context with no positively exposed project-controlled execution incarnation may now contribute ordinary work only as CHAT_UNPROVEN after the required hash/kernel/Brain checks pass. It remains excluded from independence-sensitive acceptance and proven-capacity accounting. If the live executor disappears, the system must say so rather than smiling with HTTP 200 like a malfunctioning status page.

record-external-artifact is implemented in val_native_kernel_v1.ts as a candidate-only current-epoch port. It is intentionally absent from REACTIVATION_MUTATION_ALLOWLIST, so production dispatch must return VAL_NATIVE_MUTATOR_NOT_YET_ATOMICALLY_QUALIFIED and perform no canonical artifact/event mutation.

The candidate:

• accepts only the closed {args, timeout} envelope and a closed artifact flag grammar;
• forbids human_authority_approval escalation;
• accepts only project-scoped valblob:mosadek/project-brain-live-v1-durable/… evidence and verifies exact blob size + SHA-256;
• makes an exact repeated registration a semantic no-op at artifact/event/generation/workstream-head level;
• fails closed on conflicting metadata or duplicate canonical rows for the same SHA-256;
• inherits epoch-2 exact-attempt mutation receipts, transport fencing, chain/claim-graph circuit breaking, and unknown-outcome terminalization.

Do not add this command to the live mutation allowlist, advertise it as qualified capacity, or execute the preserved 137-byte canonical probe until a genuinely distinct second-party review returns PASS under the current CHAT-execution distinctness rules. A different agent_id alone is not proof of a different physical ChatGPT execution.