tegwick
5e14d09bdf
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
77 lines
2.9 KiB
Markdown
77 lines
2.9 KiB
Markdown
# RMGR-WP-0005 batch 0002 readiness
|
|
|
|
**Observed at:** `2026-08-22T12:48:35Z`
|
|
|
|
**Scope:** `whynot-design` only
|
|
|
|
**Decision:** `RMGR-DEC-2026-001`
|
|
|
|
## Outcome
|
|
|
|
The next deterministic-identifier batch is fully specified and ready for an
|
|
explicit approval decision. No database or repository identifier was changed.
|
|
|
|
The earlier fleet seal correctly rejects 15 repositories whose authoritative
|
|
sources changed after it was generated. A refreshed plan now covers 41 eligible
|
|
repositories and 230 records with zero collisions:
|
|
|
|
- 180 replacements;
|
|
- 32 assignments;
|
|
- 18 already deterministic;
|
|
- 0 skipped repositories.
|
|
|
|
Source plan:
|
|
`RMGR-WP-0005-helixforge-uuid-migration-plan-2026-08-22-v2.json`, SHA-256 seal
|
|
`ac97f6e4f0b35db63a0dc1b4a439f0a39738d13c1407f18419f706d780d4eea0`.
|
|
|
|
## Batch 0002
|
|
|
|
The proposed batch deliberately stays at one repository and one replacement:
|
|
|
|
| Repository | Record | Current UUID | Derived UUID |
|
|
| --- | --- | --- | --- |
|
|
| `whynot-design` | `WHYNOT-WP-0003` | `41fed928-f44a-48f4-9870-120310fbf071` | `d3a6ec16-ac40-5ffb-99e7-07f997e59a4a` |
|
|
|
|
Batch manifest:
|
|
`RMGR-WP-0005-batch-0002-whynot-design.json`, SHA-256 seal
|
|
`4039224352c6590fdc6b41e739539f1f9c92d098b43ed6e30b3cd9a87b53da65`.
|
|
|
|
The manifest reports `ready_for_approval: true`, `apply_authorized: false`.
|
|
`whynot-design` is clean, exactly synchronized with `origin/main`, and its
|
|
origin is the Forgejo lineage. The plan pins HEAD
|
|
`4b62cffc86496d587ac8d48a8e199624bc4a5c1f` and source fingerprint
|
|
`55ea5e6884be2c5a0a7b8e9e19326f381c2b86afecbc28adc00252ce56793a7f`.
|
|
|
|
## Projection preflight
|
|
|
|
Read-only checks against the workstation and production projections agree:
|
|
|
|
| Check | Workstation | Production |
|
|
| --- | ---: | ---: |
|
|
| Current workplan UUID lookup | 200 | 200 |
|
|
| Derived workplan UUID lookup | 404 | 404 |
|
|
| Tasks linked to current workplan | 9 | 9 |
|
|
| Progress events linked to current workplan | 11 | 11 |
|
|
| Decisions linked to current workplan | 1 | 1 |
|
|
|
|
This is a useful second pilot: unlike the Repo Manager pilot, the same old row
|
|
exists in both projections and has matching dependent-record counts. The
|
|
database cascade must preserve those links while the task UUIDs remain
|
|
unchanged.
|
|
|
|
## Approved execution interface
|
|
|
|
If `RMGR-DEC-2026-001` is approved against the exact batch hash:
|
|
|
|
1. Re-run batch/source/Git preflight and stop on any drift.
|
|
2. Retain fresh per-database restore points and hashes.
|
|
3. Apply the repository transaction to workstation and production projections.
|
|
4. Apply the sealed authoritative file transaction for `whynot-design`.
|
|
5. Commit and push only the mapped workplan file.
|
|
6. Run consistency twice and require the derived lookup to return 200, the old
|
|
lookup to return 404, and all dependent counts to remain 9/11/1.
|
|
7. On any failure after database apply, reverse written files if necessary and
|
|
then reverse both database transactions from durable aliases.
|
|
|
|
The decision does not authorize any other repository or restoration of the
|
|
disabled production sweep.
|