Skip to content

A staged proposal to let KAHN fleets scaffold, test, verify and harden arno-host


A staged proposal to let KAHN fleets scaffold, test, verify and harden arno-host

Section titled “A staged proposal to let KAHN fleets scaffold, test, verify and harden arno-host”

Date: 2026-09-26 Status: closed Slug: arno-host Supersedes: none Superseded-by: none — current

docs/decisions/2026-09-25-arno-host-final-interfacing-governance-layer.md ratified arno-host as the estate’s human-facing interfacing layer over petrova-codes, and was explicit that it “does not change registry.yaml’s arno-host row (role, fleets_allowed) … if arno-host’s interfacing role implies a registry change, that is a separate, explicit PR.” This is that PR’s proposal.

docs/decisions/2026-08-01-promote-arno-host-experimental.md promoted arno-host to role: experimental and stated plainly: “fleets_allowed stays []. No fleet is wired. AGENTS.xml declares the petrova-act capability status="inert" for exactly this reason. Enabling it is a later registry edit, not an edit in the consumer repo.” Nothing since has enabled it — registry.yaml’s current arno-host row is unchanged from that doc.

Separately: flight@arno.host and four other governance emails were verified on GitHub in this session. That establishes who can act as a human reviewer/merger for arno-host once fleets start opening PRs — it does not by itself authorize anything. Auth (credentials) and identity (the fleet: actor prefix, gated by fleets_allowed) are the two separate gates docs/site/concepts/fleets.md names; verifying five human emails satisfies neither. This doc is the identity-side ruling.

The KAHN fleet trio (kahn-implementer, kahn-reviewer, kahn-diagnostics) has never been enabled outside kahn-hq itself. registry.yaml shows exactly one consumer with any of the three in fleets_allowed: kahn-hq, dogfooding its own fleet. The only other fleet ever admitted to write against a different repo is petrova-probe, and only against petrova-canary — a disposable, purpose-built, publicly-visible repo built for exactly this reason (docs/decisions/2026-08-12-purpose-built-canary-supersedes-pwplz.md, docs/decisions/2026-08-28-ptv-scf-0001-canary-fleet-admission.md), with its own named ratification. Admitting KAHN to arno-host would be the first time a KAHN fleet writes to a repo that carries real, kept work. That fact sets this doc’s caution level, not arno-host’s role: experimental alone.

mary-wiki is out of scope for this doc, on purpose. Its fleets_allowed: [] is not an oversight to close — it is a ratified control-plane lockdown: “fleets_allowed=[]: control-plane lockdown. Humans only, and only with explicit PETROVA_ALLOW_HUMAN_OVERRIDE=1,” encoding FR-009 (“governance of the governors never earns auto-merge”). mary-wiki’s own door-vault additionally authorizes only three read-only intents against it (audit mary-wiki, audit petrova-codes, report registry) — no petrova.act.* write intent and no IRINA-trigger intent are declared, and per mary-wiki’s own DW-APEX-03 an undeclared intent should refuse even through an existing door. Fleet write-automation against mary-wiki has no authorized path today at either layer (registry or door-vault). Opening that path is a mary-wiki-side decision first (a door-vault grant, and — because FR-009 is a named invariant — a decision that would need to name FR-009 and either satisfy or supersede it), not something this doc does by implication. If you want that scoped next, it is a separate doc.

IRINA is likewise out of scope. docs/decisions/2026-09-14-ir-004-write-path-enabled-hermes-pilot.md enabled exactly one write verb (request_review), hermes-only, and named its own non-goal explicitly: “Does not generalize beyond hermes (IR-005’s job).” IR-005 has not been opened. Routing IRINA-triggered writes into arno-host or mary-wiki is IR-005-shaped work this doc does not do.

Stage 0 (ratified by this doc, once countersigned): admit kahn-diagnostics to arno-host, read-only.

  • registry.yaml > repos[arno-host].fleets_allowed: [] → [kahn-diagnostics].
  • kahn-diagnostics is the fleet identity used for petrova diagnose and its own local plan/draft step — per docs/integrations/kahn-fleet.md, the fleet’s “diagnose, plan, draft fixes” phase writes nothing; only propose_fix/request_review/request_merge_when_green touch GitHub. Admitting only this fleet ID lets KAHN run its full diagnose/plan loop against arno-host — surfacing what scaffolding, tests, or hardening gaps exist — with zero write capability, closing the “arno-host has never actually been diagnosed by KAHN” gap before any PR-opening capability is considered.
  • This is deliberately the same shape as IR-004’s own discipline: one named capability, lowest available blast radius, existing preconditions cited rather than invented.

Stage 1 (named here, NOT ratified by this doc — needs its own countersign after Stage 0 has run and produced real diagnose output): admit kahn-implementer, restricted to propose_fix → request_review only (never request_merge_when_green). Concretely:

  • fleets_allowed: [kahn-diagnostics, kahn-implementer].
  • Every propose_fix call still passes through NO_PRIVILEGED_PATHS (no .github/workflows/, *.env, secrets/, deploy/credentials/) and the seam-tier/WIP-cap machinery IR-004 already burned in fleet-wide.
  • request_merge_when_green stays refused. profile: standard on arno-host does not, by itself, make that verb safe to reach — arno-host is private on a GitHub Free plan, so branches/main/protection 403s (“Upgrade to GitHub Pro”): there is no GitHub-enforced required-reviewer rule backing standard today. That gap is why the newly-verified governance emails matter here: until a Pro upgrade makes a real branch-protection rule expressible, a CODEOWNERS file naming those five emails is the only compensating control arno-host can carry, and it should exist before Stage 1 admits any PR-opening fleet, not after.

Stage 2 (named here, NOT ratified by this doc): admit kahn-reviewer so KAHN can review its own Stage-1 PRs (and, eventually, human-authored ones) against arno-host’s MILESTONES.md/AGENTS.xml acceptance gates — this is the “verification” and “hardening” half of the ask. kahn-reviewer does not merge; a human (one of the five verified emails) still closes every PR, per the same profile: standard / no-branch-protection gap named in Stage 1.

Not proposed, at any stage: kahn-planner (referenced in docs/site/concepts/fleets.md’s example but never defined or admitted anywhere in this repo — it would need its own scoping doc before use); any fleet write against mary-wiki; any IRINA-triggered write against either repo.

  • Does not admit any fleet to mary-wiki. See Context above.
  • Does not admit kahn-implementer or kahn-reviewer today — only kahn-diagnostics, read-only. Stages 1 and 2 are named for sequencing, not ratified.
  • Does not enable request_merge_when_green for arno-host at any stage named here — that needs its own doc, after the GitHub Pro / branch- protection gap is closed or an explicit alternative control is named.
  • Does not change arno-host’s role (experimental) or profile (standard).
  • Does not open IR-005 (generalizing IRINA past hermes).
  • Does not touch mary-wiki’s door-vault or FR-009.
  • For code: a one-line registry.yaml diff (fleets_allowed: [] → [kahn-diagnostics]), landing as its own PR per this repo’s “registry edits are PR-only” convention.
  • For arno-host: AGENTS.xml’s petrova-act capability can flip from status="inert" to a diagnose-only status once Stage 0 merges — that edit belongs in arno-host’s own repo, not here.
  • For the five verified governance emails: they become the intended reviewer/merge authority referenced in Stage 1/2 — no registry field encodes that yet (profile is a repo-level scalar, not a reviewer list); the compensating control is a CODEOWNERS file in arno-host itself, follow-up work, not scoped further here.
  • For mary-wiki and IRINA: no change; both stay exactly as their own most recent decision docs left them.
  • docs/decisions/2026-09-25-arno-host-final-interfacing-governance-layer.md
  • docs/decisions/2026-08-01-promote-arno-host-experimental.md
  • docs/decisions/2026-09-26-mary-wiki-registry-notes-correction.md
  • docs/decisions/2026-09-14-ir-004-write-path-enabled-hermes-pilot.md
  • docs/decisions/2026-08-28-ptv-scf-0001-canary-fleet-admission.md
  • docs/integrations/kahn-fleet.md, docs/site/concepts/fleets.md
  • registry.yaml (arno-host, mary-wiki, kahn-hq, petrova-canary rows)
  • Subagent: claude-sonnet-5 (session_01488gmoyur1UAMfpNMgUAhC)
  • Human: alex@devarno.com — approves Stage 0 (kahn-diagnostics admitted to arno-host, read-only) as the immediate registry edit, and the Stage 1/2 sequencing (and mary-wiki/IRINA exclusions) as the intended direction, not yet ratified further than named here.

Countersigned by human:alex@devarno.com on 2026-09-26 — box ticked directly in the working tree, not by the agent. Only Stage 0 is ratified by this countersign; Stages 1/2 stay named direction, each needing its own.

Amendment — 2026-09-26, Stage 1 readiness

Section titled “Amendment — 2026-09-26, Stage 1 readiness”

Directed in-session (“GO STAGE 1”) to proceed. This amendment records what that unlocked and what it did not:

  • CODEOWNERS landed: arno-host PR #123 adds a root CODEOWNERS naming all five verified governance mailboxes (flight@arno.host, mary@arno.host, ops@arno.host, skuld@arno.host, toll@arno.host), satisfying Stage 1’s precondition that the compensating control exist before kahn-implementer is admitted. Note honestly: CODEOWNERS auto-requests review — it does not block merge, because the same Free-plan branch-protection 403 named in Stage 1 means “Require review from Code Owners” cannot be turned on either. It is a signal, not a gate. Stage 1’s registry edit still refuses request_merge_when_green for exactly this reason.
  • Stage 1 registry edit itself is NOT ratified by an in-session directive. docs/decisions/2026-09-05-proxy-countersign-retired.md retired exactly this pattern — a spoken/typed instruction standing in for a human-authored commit. Per that doc, “a human countersign is a commit authored by the human.” The box below stays unticked until a human ticks it directly, the same way Stage 0’s was ticked in this doc’s history. “GO STAGE 1” authorized preparing the PRs; it does not itself countersign admitting kahn-implementer.

Stage 1 sign-off (separate from Stage 0’s, above)

Section titled “Stage 1 sign-off (separate from Stage 0’s, above)”
  • Subagent: claude-sonnet-5 (session_01488gmoyur1UAMfpNMgUAhC)
  • Human: alex@devarno.com — approves Stage 1 (kahn-implementer admitted to arno-host, restricted to propose_fix→request_review, request_merge_when_green refused) as the immediate registry edit, contingent on arno-host PR #123 (CODEOWNERS) being merged first.

Countersigned 2026-09-27 (registry-edit-arno-host-kahn-implementer, petrova-codes PR #478, merged). arno-host.fleets_allowed is now [kahn-diagnostics, kahn-implementer].

Amendment — 2026-09-27, Stage 2 readiness

Section titled “Amendment — 2026-09-27, Stage 2 readiness”

Directed in-session (“GO STAGE 2”) to proceed. Stage 2 has no additional precondition beyond what’s already true: CODEOWNERS (Stage 1’s gate) is live in arno-host, and kahn-reviewer is a review-only identity — per docs/integrations/kahn-fleet.md it reads PRs and their diffs against MILESTONES.md/AGENTS.xml acceptance gates; it does not call propose_fix, request_review, or any writing verb itself. Same retired-proxy-countersign discipline as Stage 1: the box below stays unticked until a human ticks it directly.

Stage 2 sign-off (separate from Stage 0/1’s, above)

Section titled “Stage 2 sign-off (separate from Stage 0/1’s, above)”
  • Subagent: claude-sonnet-5 (session_01488gmoyur1UAMfpNMgUAhC)
  • Human: alex@devarno.com — approves Stage 2 (kahn-reviewer admitted to arno-host, review-only — no write verb reachable under this fleet identity) as the immediate registry edit.

Countersigned by human:alex@devarno.com on 2026-09-27 — box ticked in commit bf820056, authored by the human. Status flipped open→closed on 2026-09-30 by an agent as scribe (MR-7).