Phase-5 v1: mutation path is structurally unreachable in a shipped build (no proposal-grant issuance; operator ineligible) + enable-mutations i18n keys unresolved

[JordanTheJet]

From the live end-to-end test of the phase-5 transport on the real release binary (feat/control-trust-genesis @ 11ff761). The core is correct and fully tested in the harness (component test an_operator_approves_via_the_cli_path_and_config_changes_through_the_cas proves park→approve→apply→verify with the fixture isolation seam). But in a SHIPPED build the mutation path is fail-closed at two independent points, so it cannot yet be exercised in production:

1. No CLI issues a proposal grant. register-client grants read domains only (granted_proposal_domains: null on the genesis-registered client, verified live). control.request_apply therefore refuses every real client — verified live: a read-only client with mutations ENABLED calling request_apply with a valid payload gets unknown_operation and writes no journal row. There is no register-client --proposal-domain or grant-widening command. To make the control plane actually mutate anything, v1 needs a grant-widening ceremony (meta-authority) that issues a proposal domain to a registered client.
2. Operator approve fails closed. zeroclaw control approve passes Evidence::unknown() → OperatorIneligible in production (no reachability prover for same-host separation). So even a parked proposal could not be approved in a shipped build.

Both are correct default-closed behavior, not bugs — but together they mean phase 5's user-facing capability is inert until (a) a proposal-grant issuance ceremony and (b) a real reachability prover (or an out-of-process operator backchannel) exist. Flagging so the roadmap is honest: the mutating control plane is BUILT and TESTED but not yet REACHABLE end-to-end in production.

Also (real user-facing bug): the enable-mutations ceremony renders raw unresolved Fluent keys on the release binary — observed live: {cli-control-enable-mutations-confirm}, {cli-control-enable-mutations-operator}, {cli-control-mutations-enabled}. The keys were added to cli.ftl in source but do not resolve in the built binary (likely a generated/embedded catalogue not regenerated, or a missing translation entry). Fix the i18n wiring so the ceremony prompts render.

Minor (cosmetic, fail-closed): control.request_apply appears in a mutations-enabled session's tools/list even for a client lacking the proposal grant, but the handler returns unknown_operation. Visible-but-unusable is the safe direction; consider hiding it unless the proposal grant is held, to match the documented '(c) proposal grant' visibility claim.

Live-verified GOOD behavior: genesis + client registration; enable-mutations writes a sealed management.record; mutations-enabled makes request_apply visible; read-only client is refused with no journal row (fail-closed at the grant gate); no MCP path reaches config apply. Part of #35, relates to #31.

[JordanTheJet]

Lane 1 of #52 landed and verified (feat/control-trust-genesis, commits cc23511 + 71c0282).

• Grant-issuance ceremony: zeroclaw control grant-proposal --client <id> widens a registered client's grant to include the v1 proposal domain, under operator terminal presence. It is permanently meta-authority: refuses without a registered operator, in recovery-only/unmanaged mode, and for an unknown/revoked client; no MCP tool or requester path can trigger it (protocol.rs/control_mcp.rs byte-unchanged). Component test proves a granted client's request_apply is authorized to park where an ungranted one is refused — so the FIRST Phase-5 v1: mutation path is structurally unreachable in a shipped build (no proposal-grant issuance; operator ineligible) + enable-mutations i18n keys unresolved #52 blocker (no way to grant parking rights) is lifted. Verified on the release binary: the subcommand ships.
• i18n fixed: the enable-mutations ceremony rendered raw {cli-control-*} keys because they were absent from the embedded English catalogue; added. Verified live: renders real text now.

314 lib + 35 component + Fluent-coverage architecture gate all green; clippy clean.

Still blocking the full flow — the operator reachability prover (Lane 2). Analysis: the reachability MODEL is already built (reachability.rs enumerates 4 IsolationQuestions, AND-conjoined, unknown=>reachable=>ineligible) and every signal it needs already exists in the repo — peer credentials (zeroclaw-api Credential::Peercred{uid}, SO_PEERCRED) answer DistinctOsAccount; the Seatbelt/Landlock sandbox (zeroclaw-runtime/src/security) answers SandboxExcludesBackchannel. So the prover is INTEGRATION, not research. Three sound deployment shapes: (A) daemon + distinct OS account via peercred; (B) enforced same-machine sandbox attestation (best desktop fit); (C) out-of-process operator backchannel (approve on a phone). Same-user unsandboxed stdio stays fail-closed by design. Lane 2 will wire Path A first (peercred -> DistinctOsAccount), smallest sound step. Part of #35.

[JordanTheJet]

Phase-5 reachability, part 1 of 2: proposal-grant issuance now exists, so the first of this issue's two mutation-path blockers is lifted. The i18n bug is also fixed.

What now works

• zeroclaw control grant-proposal --client <registration-id> — a new host-side ceremony that widens a registered client's grant to include the v1 agent proposal domain. It runs the same terminal user-presence + registered-operator authentication as register-operator/enable-mutations (an anonymous TTY is a requester, not an operator), refuses on an uninitialized or recovery-only instance and on an unknown or revoked registration, is idempotent (re-granting a held domain succeeds and changes nothing), and persists via a sealed re-publish of the client registry. It records the granting operator + assurance class + timestamp on the registration for audit, adds no read domain, mints no credential, and grants no approval authority or tool to any agent.
• control.request_apply is reachable for a real client. Verified end-to-end in the phase-5 component harness (genesis → register read-only client → enable-mutations): before the grant the client is refused grant_required and parks nothing; after grant-proposal the same client sees request_apply and parks a durable journal row while changing no config. This lifts blocker (1): register-client issuing granted_proposal_domains: null is no longer a dead end.
• The invariant holds. Widening an external client grant is the permanently-meta-authority operation the accepted design names. It is host-side only: no MCP tool, argument, env var, or requester action can trigger or satisfy it. No new MCP tool was added; protocol.rs/control_mcp.rs/service.rs are untouched.

i18n bug fixed

The enable-mutations ceremony (and approve/reject) rendered raw {cli-control-*} keys on the release binary because 9 referenced keys were never added to the embedded English catalogue (crates/zeroclaw-runtime/locales/en/cli.ftl). The English fallback arg in t()/ta() is only used when the agent-runtime feature is off, so shipped builds showed the {key} sentinel — it was a missing source key, not a stale generated catalogue. Added the 9 missing keys plus the 3 new grant-proposal keys, with a regression test asserting they resolve and substitute their arguments.

What still blocks the full flow (unchanged — a separate piece)

• Blocker (2) is untouched. zeroclaw control approve still passes Evidence::unknown() → OperatorIneligible in a shipped build, because there is no reachability prover / out-of-process operator backchannel. A parked proposal still cannot be approved in production. The operator-reachability prover is the remaining Phase-5 reachability piece and is not built here.
• The terminal presence adapter's known same-UID PTY spoofability is a pre-existing property of every operator ceremony (genesis/register-operator/enable-mutations); grant-proposal mirrors that adapter rather than weakening it. When a higher-assurance adapter lands, this ceremony inherits it without a contract change.

Once the reachability prover exists, park → approve → apply → verify is reachable end-to-end for a shipped build.

[JordanTheJet]

Lane 2 (LOGIC) landed — reachability prover from discharged proofs (feat/control-trust-genesis @ ff09e3e, constructor + tests only).

Evidence::from_local_daemon_proofs(&LocalDaemonProofs) answers each of the four isolation questions only from a genuine host-derived proof, None (fail-closed) otherwise: DistinctOsAccount (both uids known & different), OutsideHostProcess (a real local-socket peer), NoShellOrFilesystemGrant (an allowlist over the v1 read+proposal vocabulary), and the crux, SandboxExcludesBackchannel.

Crux: Some(true) only when a distinct, non-root requester uid meets an operator-owned, uid-restricted backchannel attestation — argued sound from OS-account separation (TIOCSTI needs an fd to another uid's tty = DAC-denied; ptrace attach needs matching uid or CAP_SYS_PTRACE; the 0600 control socket denies another uid) under documented assumptions (no privileged requester — an added != ROOT_UID gate catches root, which is uid-distinct yet bypasses DAC; no shared/inherited TTY fd; socket mode 0600 owned by the operator). Absent attestation or a root/same-uid requester → None.

No shipped eligibility changed: production still passes Evidence::unknown() at the approve site (main.rs:1661/1699), nothing constructs LocalDaemonProofs in production (grep-confirmed), and the all-true seams stay cfg-gated (release fixture-absence gate passes). 328 control lib tests (314+14), 3 mutation checks load-bearing. Real peercred/socket plumbing = a later lane (2b).

Adversarial gate on the crux soundness to follow before 2b makes it live. Coordinating with the conversation-first-setup pane, which layers the D1(a) reach-path-foreclosure semantics on top (same-account desktop shape B); this shape-A prover is the first per-shape constructor. Note: 3 zeroclaw-runtime delegate background-task tests fail environmentally on this branch (control-independent; runtime does not depend on control) — tracking separately.

[JordanTheJet]

Reachability crux hardened: UNSOUND → sound (feat/control-trust-genesis @ ca941f7). The adversarial gate on ff09e3e found the SandboxExcludesBackchannel attestation over-collapsed OS facts into one bool + uid!=0; all five findings now fixed with fails-closed tests:

1. Socket parent-dir/namespace: SocketFacts carries kind (pathname/abstract) + owner + mode + parent-chain; abstract → None, writable-ancestor → None (closes the unlink/rebind MITM).
2. Non-root ≠ unprivileged: RequesterPrivilege (eff/prm/amb capsets) must be empty of DacOverride/SysPtrace/Kill/SysAdmin; unknown → None.
3. Pre-collapsed bool removed: TtyFacts/SocketFacts carry raw stat facts, verdict computed in-module; TTY perms evaluated against the requester's supplementary groups (pts 0620 group-tty).
4. Platform gate: Some(true) only on Linux; non-Linux → None (macOS needs its own proof).
5. TTY-only backchannel kind; other → None.

340 control lib tests (+12), 3 mutation checks load-bearing, fixture-absence gate green, approve site still Evidence::unknown (grep-confirmed) — zero shipped eligibility change.

Known over-conservatism to refine in the plumbing lane (2b): the parent-chain rule currently requires every ancestor operator-owned, so it answers None on realistic root-owned paths (/run, /). Safe but won't fire on a real socket path until relaxed to 'non-writable-by-the-requester'. Recorded in the crux doc. macOS/desktop (shape B) is the conversation-first-setup pane's ceremony-constructed-isolation track; the Darwin proof there is a separate hard problem, and desktop mutation is honestly fail-closed until it exists (interim: recorded terminal-presence-only assurance [D1(b), Jordan's policy call] or second-device backchannel [shape C]).