Mímir reconciliation: scoping, not ratifying — what has to be decided before it grows further

Date: 2026-09-22 Status: closed Supersedes: none Superseded-by: none — current

Context

An ecosystem realignment pass this session (surveying devarno-cloud, rocky-hq, asgard-codes, panto-cloud, kahn-hq, stratt-hq, grace-hq, traceo-cat, smo1-io against petrova-codes) surfaced a structural question petrova-codes cannot resolve unilaterally and had no visibility into until now: asgard-codes/mimir/README.md charters an agent “responsible for defining, maintaining, and keeping honest every PETROVA-governed Claude Code routine across the fleet” — governance-of- governance, one level above what petrova-codes itself does today.

Two independent facts make this load-bearing rather than speculative:

1. Mímir is already depended upon elsewhere. grace-hq’s DEC-0009 states cross-repo phase coordination is “Mímir’s chartered seam” — grace-hq has already deferred a real governance responsibility to a system that does not yet exist in a ratified or wired form.
2. The two systems already disagree on the shape of the law they both cite. Mímir’s charter references MR-1..MR-17 (asgard-codes’ mimir/README.md). petrova-codes’ own CLAUDE.md claimed MR-1..MR-12 until corrected in this same session (4bba6444) — the vendored core/templates/META-RULES.md was already at MR-17; only the doc line was stale. Mímir was citing the true corpus correctly while petrova-codes’ own summary of itself was wrong. That is not a reason to defer to Mímir; it is a reason neither system’s self-description can be trusted uncorroborated right now.

asgard-codes’s own decision log shows Mímir’s founding acts (DEC-ECO-0001, DEC-ECO-0002) as “authored and pending ratification” — explicitly not yet ratified there either. asgard-codes is registered in registry.yaml as an ordinary consumer (role: scaffold, fleets_allowed: []); petrova-codes’ registry has no concept of a governed repo also being a governor of the fleet, and nothing here treats asgard-codes as anything other than an ordinary row.

What this doc explicitly does NOT do: rule on whether Mímir supersedes petrova-codes, is absorbed by it, or coexists as a distinct layer. That is the human decision this doc scopes toward, not one an agent survey can make for you — same discipline as 2026-09-11-irina-scope-mis-scoped.md’s own re-scope: name the real questions, do not answer the one only a human can rule on.

Decision

Ratify the questions that must be answered, and the evidence needed to answer each one, before Mímir is wired into anything or petrova-codes changes its own charter in response to it. No code, no schema, no registry change follows from this doc.

Q1 — Identity: does Mímir replace, extend, or sit above petrova-codes? Three live candidates, not yet distinguished by any doc on either side:

• Mímir supersedes petrova-codes — asgard-codes becomes the fleet’s real governance root; petrova-codes’ registry/verb/seam-class machinery becomes a subsystem Mímir calls, the way IRINA calls petrova-codes today.
• Mímir is absorbed into petrova-codes — its G0-G5 routine set (fleet reconcile, MR-audit scoring, seam-integrity gating, traceability audit, drift/realign, onboarding) becomes new petrova-codes capability, and asgard-codes/mimir/ is deprecated in favour of it.
• Mímir is a distinct, coordinate layer — petrova-codes stays the registry/verb/seam-class control plane; Mímir becomes a consumer of petrova-codes’ MCP surface the way IRINA is, scoped to governance-audit read/report work only, never mutating petrova-codes’ own state. Evidence needed: a direct conversation between whoever authored asgard-codes/mimir/ (or you, if that was you) and this session/repo’s maintainers about intent — this is not discoverable from either repo’s files alone; both are silent on which of the three was meant.

Q2 — Which MR corpus is authoritative, and how does drift between them get caught mechanically (not by an ecosystem survey happening to notice)? Both sides currently claim to cite eva-hq’s canonical prompts/_shared/petrova/META-RULES.md, but this session found petrova-codes’ own vendored copy already 1 version behind (1.2 vs eva-hq’s 1.3) with real behavioural drift (pre-2026-05-16 MCP prompt-resolution description), not just a doc-line undercounting. If Mímir vendors or re-derives its own MR corpus rather than reading eva-hq live, the same drift risk exists on a second surface. Evidence needed: does asgard-codes/mimir/ read MR text from eva-hq live (via Fleet MCP petrova.prompts.get, once/if Mímir is wired to it) or from its own vendored copy? If vendored, drift is structural and recurring until it reads live from the one canonical source, same fix petrova-codes itself still owes its own core/templates copy.

Q3 — Does Mímir get write access, and if so, governed by whose seam-class ceiling? Mímir’s charter language (“keeping honest,” “MR-audit scoring”) implies at minimum read/report work across the fleet — closer to IRINA’s shape than to a passive dashboard. If any Mímir act is a mutation, it needs an entry in some registry, a seam tier, and to observe some WIP cap — either petrova-codes’ existing machinery (if Q1 resolves toward “coordinate consumer”) or a new, parallel mechanism (if Q1 resolves toward “supersedes” or “absorbed”). This doc does not choose; it names the dependency explicitly so Q1 is answered before any Mímir write path is built, not discovered as a gap after one already exists (the same class of mistake 2026-09-11-irina-scope-mis-scoped.md caught for IRINA’s own original “autopilot” framing).

Q4 — Does grace-hq’s DEC-0009 dependency get satisfied, deferred, or retracted? grace-hq has already committed a real governance responsibility (cross-repo phase coordination) to Mímir in a ratified, closed decision. If Q1 resolves toward Mímir not existing as a wired system for a long period, grace-hq is carrying a dependency on vaporware, not by grace-hq’s fault — it inherited that risk the moment Mímir’s charter was written and cited. Evidence needed: whoever owns grace-hq’s roadmap should know this doc exists and that Q1-Q3 are open, so DEC-0009 isn’t silently assumed satisfied by a system that isn’t ratified yet.

Alternatives considered

• Ratify Mímir’s charter now, on the strength of it being well-written and already depended upon — rejected: “already depended upon” is a reason to resolve the ambiguity urgently, not a reason to skip resolving it. Ratifying a governance-of-governance layer without first settling whether it supersedes, is absorbed by, or coexists with petrova-codes would be adopting a fact by default, the exact failure mode docs/decisions/2026-09-05-ratified-status-mapped-to-closed.md and this repo’s own MR-7 discipline exist to prevent.
• Ignore it — asgard-codes is fleets_allowed: [], ordinary consumer, not petrova-codes’ problem — rejected: grace-hq’s DEC-0009 already makes it petrova-codes’ problem by proxy; a governance claim made about the fleet doesn’t stay contained to the repo that made it.
• Have petrova-codes unilaterally declare itself the fleet’s permanent governance root, closing the question by assertion — rejected: no more legitimate than Mímir unilaterally declaring the reverse; this is exactly the kind of fact only a human ruling settles, per MR-9 (no invented invariants) as both sides already independently cite.

Consequences

For code: none. This is a question-scoping doc.

For docs: docs/decisions/2026-09-22-profile-tier-ceiling-mapping.md and other petrova-codes governance docs stay authoritative for petrova-codes’ own scope until Q1 resolves; nothing here supersedes them.

For in-flight phases: none in petrova-codes. Flags a real, unacknowledged dependency risk on grace-hq’s DEC-0009 (Q4) — worth that repo’s maintainer knowing, not actionable from here.

For invariants: none added or repealed. Names MR-9 (no invented invariants) as the reason this doc stops at scoping rather than ruling.

References

• asgard-codes/mimir/README.md
• asgard-codes’ decision log (DEC-ECO-0001, DEC-ECO-0002 — pending ratification)
• grace-hq DEC-0009 (“cross-repo phase coordination is Mímir’s chartered seam”)
• docs/decisions/2026-09-11-irina-scope-mis-scoped.md (same scoping discipline)
• CLAUDE.md (MR-1..17 correction, commit 4bba6444)
• core/templates/META-RULES.md
• registry.yaml (asgard entry)

Sign-off

• Subagent: claude-sonnet-5 (session_01488gmoyur1UAMfpNMgUAhC)
• Human: alex@devarno.com — approves Q1-Q4 as the right questions to resolve before any Mímir wiring or petrova-codes charter change, and confirms no other repo currently depends on Mímir the way grace-hq’s DEC-0009 does.

Countersigned by human:alex@devarno.com on 2026-09-22. Box ticked by the human directly, in-file; this line recorded by the agent as scribe.