§1 — Purpose and fleet boundary

Once the model-neutral capability schema, typed artifact roots, distributed sprint state, and readable MCP resource contract are stable, every repository registered with the host Reckon server must be migrated. Leaving a mixed fleet indefinitely would force the server, skills, and agents to support contradictory state models and would make host-wide discovery unreliable.

The implementation must discover the authoritative mount registry at runtime. Project names and paths must never be embedded in Reckon source code. As of 2026-07-29, the host registry contains the following inventory snapshot:

Registered projectMounted docs root
helix/home/ITER/mcintos/Code/helix/docs
imas-ambix/home/ITER/mcintos/Code/imas-ambix/docs
imas-efit/home/ITER/mcintos/Code/imas-efit/docs
reckon/home/ITER/mcintos/Code/reckon/docs
vv/home/ITER/mcintos/Code/vv/docs

This table is evidence of present scope, not a fixed allow-list. Repositories added or removed before execution must be reflected by discovery and the migration ledger.

The host mount registry feeds a preflight, per-repository migration, verification, and evidence pipeline.
Every registered repository moves independently through the same resumable migration contract.

§2 — Preflight and inventory tooling landed

Landed: runtime registry hashing, per-mount Git/worktree/dirty-path inspection, content-bearing snapshots, atomic incremental ledger writes, and exact terminal deferrals are implemented in f39a4cb. Read the tooling record.

Legacy normalization landed: commit 997ff67 adds collision-safe flattening for nested typed resources, reserved identity repair, missing semantic-type stamping, and unique archive-record identities. Fresh previews now accept 144 imas-codex moves and 484 imas-efit moves or repairs; the full suite passed 1,384 tests. Read the normalization evidence.

The migration begins with a read-only inventory of the mount registry and each resolved repository root. For every project it records the mounted checkout, current branch and commit, dirty-tree state, existing artifact layout, sprint and milestone stores, plan schema versions, unresolved decisions and followups, server audit result, and whether alternate worktrees exist.

Preflight must refuse ambiguous or unsafe targets. A missing repository root, unresolved mount symlink, dirty overlap with migration paths, detached mounted checkout, duplicate project identity, or unreadable state produces a deferred row with a concrete next action. Unrelated user changes are preserved. The mounted checkout must never be switched to another branch as a migration shortcut.

§3 — Per-repository transaction external waves next

Transaction engine and normalization canary verified: selected repositories migrate in an isolated staging copy and must pass capability, typed-layout, distributed-state, document, schema, relationship, progressive-read, and static-build gates before exact-path installation. Injected installation failure restores the snapshot byte-for-byte. The re-run Reckon canary passed with zero further working-tree changes, 17/17 schema resources conformant, zero document or audit errors, and 36 progressive resources readable.

Each repository migrates as an independent, resumable transaction. The transaction writes a before snapshot, applies the canonical typed-directory and distributed-state migration, rewrites internal references through the shared resolver, converts legacy provider tiers, and validates the new MCP response contract. It then runs document audit, schema audit, static build, targeted tests, and relationship checks before declaring that repository migrated.

State writes in alternate worktrees must pair read_plan and edit_plan with the same checkout_path. The coordinator owns shared sprint and migration-ledger updates. No fleet worker may stage broad paths, sweep another worker’s edits, change the mount registry, or publish externally.

§4 — Rollout waves and rollback canary passed

Reckon canary verified: 26 legacy resources moved into typed roots, 16 internal reference rewrites landed, 33 legacy capability records became neutral capability objects, and an existing distributed-state store remained parity-valid. The post-install suite passed 1,378 tests. Read the canary evidence.

Reckon itself is the canary because it owns the parser, migration code, schemas, and audit tools. Remaining repositories are ordered from least coupled to most coupled using preflight evidence rather than a hard-coded project order. A failure stops promotion to the next wave but does not roll back repositories that have already passed their independent transaction.

Rollback restores the recorded pre-migration files for one repository and re-runs its old-format audit. Destructive removal of compatibility files is deferred until every registered repository has passed and a separate compatibility-retirement decision is locked. Server and MCP processes must be restarted or reconnected when parser, renderer, or schema code changes so verification never uses stale in-memory code.

§5 — Migration ledger and evidence 12/12 terminal

The registry snapshot contains 12 projects and every row now has a content-bearing snapshot plus a terminal state: one verified, five deferred only for explicit external write authority, and six deferred for exact preflight blockers. Read the fleet ledger evidence.

A fresh post-normalization ledger keeps all 12 rows terminal and raises the preflight-clean set to seven repositories. imas-efit is now clean; imas-codex is blocked only by its three active worktrees. No external repository was modified, and the clean wave remains gated by explicit cross-repository write authority.

The coordinator maintains one fleet ledger with the states discovered, preflight-passed, deferred, migrated, verified, and rolled-back. Each row records the project-qualified resource, source commit, migration version, output commit or working-tree path, verification results, evidence location, and any operator action required.

Each successful repository produces typed evidence containing before/after counts, migrated paths, reference rewrites, schema and build results, and the exact migration version. A fleet-level evidence record summarizes coverage and names every deferred or failed project. No repository is silently omitted.

§6 — Done-when

  1. Runtime discovery accounts for every current mount with no hard-coded project names in Reckon source.
  2. Each registered repository has a recoverable before snapshot and a terminal ledger state.
  3. Every migrated repository passes fresh-process document, schema, relationship, and static-build validation.
  4. Typed directories, distributed sprint resources, neutral capability values, and concise MCP reads are present consistently across the verified fleet.
  5. Per-repository and fleet-level evidence records identify commits, paths, migration version, and remaining deferrals.
  6. Compatibility retirement remains blocked until all registered repositories are verified and the retirement decision is explicitly locked.

§ Decisions

How should the fleet migration handle a repository with overlapping uncommitted changes?

A repository with overlapping uncommitted migration paths is preserved and receives a terminal deferred ledger row with exact paths and a concrete next action.

What should happen to a verified repository migration?

Verified migrations follow repository policy: commit explicit paths and push each primary branch immediately after tests, while deferred repositories remain untouched.

When may legacy flat layout and monolithic-index compatibility be removed?

Compatibility removal is destructive and cross-repository; it requires a separate explicit retirement plan after fleet verification rather than happening inside migration.

§ Followups

Migrate and verify every registered repository

Run only after the four state-contract prerequisites ship. Discover the live registry, produce a dry-run ledger, and migrate repositories in verified waves with per-repository evidence.

Project: reckon
Plan:    registered-repo-state-migration (http://localhost:8765/reckon/registered-repo-state-migration.html)
Section: full plan
Capability: orchestrator
Requirements: deep reasoning, extended context, autonomous tools, strict verification, elevated risk

Context
  The new state contracts must be applied consistently across every host-registered repository.
  Execute a resumable fleet migration with explicit deferrals, rollback and evidence.

State to read
  host Reckon mounts registry and every resolved repository AGENTS.md
  migration commands, schemas, resolver, audit and static-build implementations

Scope locks / constraints
  Discover mounts at runtime; never hardcode project names in Reckon source.
  Preserve unrelated changes, never switch mounted checkouts, and do not publish externally.

Done-when
  1. every discovered repository has a terminal ledger state and recoverable snapshot
  2. all migrated repositories pass fresh-process audits and builds
  3. per-repository evidence and fleet summary land
  4. followup written into plan + this followup marked resolved