repo-manager/docs/evidence/RMGR-WP-0005-helixforge-migration-readiness-2026-08-21.md
tegwick 887943108e fix(identifier): verify migration per repository unit
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
2026-08-22 00:02:48 +02:00

2.8 KiB

id type workplan_task created
RMGR-EVIDENCE-0005-HELIXFORGE-MIGRATION-20260821 evidence RMGR-WP-0005-T04 2026-08-21

HelixForge deterministic-identifier migration readiness

Fleet owner Bernd Worsch declared helixforge as the authoritative current namespace. Repo Manager records it in config/fleet-namespace.yaml; omitting --namespace now resolves to that checked-in declaration.

Source preflight

  • 114 repository workplan roots scanned under /home/worsch;
  • 242 live workplan/task identifiers;
  • zero live identifier collisions;
  • one initial ineligible repository (net-kingdom) due to 14 legacy task ids written as -T1-T8;
  • those ids and their four documentation references were normalized to -T01-T08 in NetKingdom commit 25ed928;
  • regenerated plan: 42/42 repositories eligible, 242 records, 209 replacements, 33 assignments, zero skipped;
  • plan SHA-256: 122ce72b27c2df50fb5604f3b324b68fbf7d2ec392c041370bfba7e0850a0e26.

The full old-to-derived mapping is docs/evidence/RMGR-WP-0005-helixforge-uuid-migration-plan-2026-08-21.json. It carries canonical UTC generation time plus per-repository Git HEAD and authoritative-source fingerprints. Source drift is a hard failure; HEAD drift with identical authoritative bytes is reported but remains eligible, avoiding self-invalidation when the plan itself is committed. rmgr identifier migration-verify validates the seal and source preconditions, either fleet-wide or for one repository atomic unit. Concurrent changes observed after the first seal were correctly rejected; --repo prevents unrelated fleet churn from invalidating a stable unit while still refusing the changed repository.

Central-projection gate

No UUID was rewritten. State Hub uses these UUIDs as primary keys, with references from tasks, progress and token events, decisions, dependencies, launch requests, intakes, capability requests, contributions, technical debt, extension points, and legacy suggestions. The checked-in foreign keys specify delete behavior but no ON UPDATE CASCADE behavior.

Consequently, changing the repository fields first would detach the central projection, while directly updating database primary keys would fail or leave references split. Apply remains unauthorized until State Hub has:

  1. a transactional old→derived projection migration covering every referencing table;
  2. durable alias/provenance for old ids used by saved links and events;
  3. per-repository prepare/apply/rollback behavior coordinated with the Git commit and push seal; and
  4. an isolated PostgreSQL rehearsal proving forward and reverse mappings.

This is a discovered compatibility requirement, not a source-data blocker. The sealed plan remains evidence; source or HEAD drift requires regeneration for the affected repository before its apply.