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

60 lines
2.8 KiB
Markdown

---
id: RMGR-EVIDENCE-0005-HELIXFORGE-MIGRATION-20260821
type: evidence
workplan_task: RMGR-WP-0005-T04
created: "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.