0002 — Rename SS-08 FLEET → HEARTH; commit Phase-3 RALPH to KAHN's transitions schema
- Date: 2026-05-02
- Status: Accepted
- Partially supersedes: 0001-redesign-bootstrap.md (the naming choice "FLEET" only; the rest of 0001 stands)
Context
docs/decisions/0001-redesign-bootstrap.md and docs/specs/2026-05-02-rocky-system-redesign.md named Rocky's per-workspace CAIRNET+LORE provisioner subsystem SS-08 FLEET. A scan of ~/code/workspace/kahn-hq (KAHN — the operator's agent-fleet observability product) surfaced two collisions and one synergy:
- Namespace collision on "fleet". KAHN's
PRODUCT.mddeclares it "an agent-fleet observability tool"; KAHN shipsbackend/kahn/fleet.py. Two products in the same workspace using the same word for different things would create permanent operator confusion (which "Rocky FLEET" — the provisioner, or the KAHN observability surface Rocky reports into?). - RALPH conceptual collision. KAHN's
docs/KAHNxKILN.mddescribes RALPH as "the iterative refinement loop in KAHN" that "retries convergence-failed nodes". Rocky's SS-07 RALPH is a sequential prompt-queue with plan/judge/execute/audit/merge per prompt. Same name, adjacent problems, different architectures. Not addressed by this decision — flagged for post-Phase-3 evaluation; the architectures are different enough that premature unification would be over-engineering. - Schema duplication risk. KAHN already ships a vendored producer→consumer contract at
kahn-hq/contracts/:transitions.schema.json,graph.schema.json, and a stdlib-onlykahn_emit.py(additive-compatible; sister repos vendor it percontracts/README.md). Rocky's RALPH was designing a bespokerun.jsonlevent format that would have been a strictly-coarser duplicate of KAHN'sStatus × Outcomesemantics.
Decision
Two coupled changes:
Rename SS-08 from FLEET to HEARTH across all governance documents (spec, plan, CLAUDE.md, MILESTONES, README, registry schema/yaml, conventions, decisions index). HEARTH pairs metaphorically with CAIRNET (stone marker) and LORE (campfire knowledge): HEARTH is where the per-workspace knowledge stack lives. Functionally identical to the previously specced FLEET — tiered driver-based provisioner of 1×CAIRNET + 1×LORE per workspace. Decision 0001's body is preserved (append-only convention, MR-7); this decision records the supersession.
Commit Phase 3 (lift-ralph) to KAHN's transitions schema as Rocky RALPH's on-disk event format. Vendor
kahn-hq/contracts/kahn_emit.pyintoralph/per KAHN's recommended consumption path. Each Rocky run becomes one KAHN run; each prompt becomes a KAHN node; plan/execute/audit are node attempts; Rocky's deviation severity maps onto KAHN'sOutcomeenum (clean | clean_with_flake | partial | stuck | catastrophic). Rocky's deviation-detection metadata rides as KAHN's documented "unknown fields pass through" extension.
Consequences
- Operator UX wins immediately: Rocky runs surface in KAHN Scope alongside Choco/STRATT/Traceo runs. KAHN Scope is the canonical fleet dashboard for an operator running multiple Rocky workspaces. Rocky's console SS-02 DASHBOARDS keeps owning ops-and-modelling views that KAHN intentionally does not cover (workbench history, plugin registry, vault audit).
- Naming hygiene: Rocky and KAHN can both use the word "fleet" without collision — KAHN owns it; Rocky doesn't claim it.
- One less schema to design and maintain: RALPH's event format is no longer a Rocky-internal concern. Schema bumps follow KAHN's additive-compatibility rule.
- Phase-3 plan must vendor
kahn_emit.pyand pin its schema SHA in CI per KAHN's contract README ("pin the schema SHA in CI so a Scope-side schema bump does not silently break producers"). This is a hard requirement forlift-ralph, not an aspiration. - What this decision does NOT do: unify Rocky RALPH and KAHN RALPH. They remain distinct loops solving adjacent problems. Re-evaluate post-Phase-3 with real telemetry; do not pre-unify on speculation.
- What this decision does NOT do: consolidate KAHN's billing/auth/api_keys/rate_limit modules with Rocky's SS-06 VAULT and Polar.sh adapter. They serve different products (KAHN cloud vs. Rocky cloud) and stay separate. A shared
@devarno/polar-entitlementspackage is a Phase-7+ concern, not now.
References
- KAHN PRODUCT brief:
~/code/workspace/kahn-hq/PRODUCT.md - KAHN contracts README:
~/code/workspace/kahn-hq/contracts/README.md - KAHN emitter:
~/code/workspace/kahn-hq/contracts/kahn_emit.py - KAHN Status × Outcome enums:
~/code/workspace/kahn-hq/contracts/schemas/transitions.schema.json - KAHN's own RALPH framing:
~/code/workspace/kahn-hq/docs/KAHNxKILN.md§2.1 - Rocky redesign spec (post-rename):
docs/specs/2026-05-02-rocky-system-redesign.md— see new "KAHN integration" section - Rocky decision 0001 (partially superseded):
docs/decisions/0001-redesign-bootstrap.md