Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
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…-T08in NetKingdom commit25ed928; - 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:
- a transactional old→derived projection migration covering every referencing table;
- durable alias/provenance for old ids used by saved links and events;
- per-repository prepare/apply/rollback behavior coordinated with the Git commit and push seal; and
- 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.