state-hub/workplans/STATE-WP-0079-retirement-strangler.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	parent_project	parent_workplan	related	state_hub_workstream_id
STATE-WP-0079	workplan	State Hub retirement strangler and disposition execution	infotech	state-hub	blocked	codex	infotech	2026-08-09	2026-08-31	prj-state-hub-retirement	SHR-WP-0001	STATE-WP-0074 SHR-INV-0001 RMGR-WP-0001 HUB-WP-0004	ed077b62-7048-5752-bf65-f90471f45854

State Hub retirement strangler and disposition execution

Goal

Execute the keep/move/replace/retire dispositions from prj-state-hub-retirement/inventory via strangler adapters and owner handoffs, without adding new permanent authorities here. End state: freeze window with no normal traffic, then archive.

Dual-run handoff (RMGR-WP-0002)

Repo Manager Stage B dual-run is available:

• Flags: RM_WRITEBACK, RM_RECONCILE, RM_PILOT_REPOS (see repo-manager/docs/dual-run.md)
• SH adapter: api/services/repo_manager_dual_run.py (PATCH /tasks + C-15 writeback + reconcile proxy)
• Evidence: repo-manager/docs/evidence/wp0002-completion.md

Expand pilot list here as cutover progresses; do not add new checkout mutators in State Hub.

Freeze policy for new scope

id: STATE-WP-0079-T01
status: done
priority: high
state_hub_task_id: "3e8659a1-54bd-5329-bfee-24fdaca5374d"

Document and enforce: changes during retirement must preserve compatibility, enable extraction, reduce scope, or fix operational risk — not establish new permanent ownership (INTENT retirement status).

Result (2026-08-20): policies/retirement-freeze.md, following the existing policies/ convention. States the four admissible reasons, the inadmissible case (new permanent ownership here), and the operative test — where does this live after cutover? — since most inadmissible changes are otherwise good changes. Uses STATE-WP-0080's retarget as the worked example.

Enforced by review, not by new automation. A freeze-checker built inside State Hub would be new permanent automation in the component being retired, so the policy would violate itself. Gates attach to points where changes are already reviewed: new workplan goal statements, non-trivial task starts, and slice execution. New tables, routes, or MCP tools carry a presumption against and are the one hard stop.

Capability strangler plan

id: STATE-WP-0079-T02
status: done
priority: high
state_hub_task_id: "fcf280dd-cf42-5c41-bd55-69b4b409db3b"

Group SHR-INV-0001 items into cutover slices (repo/work → repo-manager; messages/progress/projections → hub-core; catalogs → owners; retire aliases). Per slice: adapter flag, owner API, rollback.

Result (2026-08-19): docs/retirement-cutover-slice-plan.md. All 425 inventory items assigned to 19 slices in five waves plus Keep, computed against state-hub-disposition.yaml rather than hand-counted. Each slice carries an RM_SLICE_* flag (off/dual/owner), owner API, and rollback; Wave A reuses the RMGR-WP-0002/0003 dual-run adapter rather than adding a mechanism.

Owner readiness verified: only Wave A (repo-manager, 165 items) is executable — RMGR-WP-0001/0002/0003 are finished. Wave B is gated on HUB-WP-0004 (proposed), D1 on OPS-WP-0003 (proposed), D2 on FIN-WP-0003 (proposed). Recommended first cut is A3 (registers), lowest blast radius.

Two findings for T04/T05: the 9 ops_dependency items carry no capability and cannot be strangled behind a flag — they resolve at the T06 freeze window; and the legacy-meter review window is 8 hours despite cadence: weekly, which is not sufficient evidence to retire high-volume /workstreams/ interfaces (E2).

Register CLI and GOAL.md support

id: STATE-WP-0079-T03
status: done
priority: medium
state_hub_task_id: "757bad31-b5d9-5ff7-b33e-d8c1dfb1bcde"

Adapt statehub register / scaffolding so prj- repos with GOAL.md and repo_flavor: project are valid without inventing durable-product INTENT.md (residual from SHR-WP-0001-T01).

Result (2026-08-19): Implemented by STATE-WP-0080-T01/T02. Project flavor is detected from classification, GOAL.md, or the prj- slug; a repo with an existing GOAL.md is registered without durable scaffolding, while a fresh project delegates scaffolding to rmgr scaffold. The focused State Hub registration suite passes (20 passed).

Execute move/replace slices

id: STATE-WP-0079-T04
status: wait
priority: high
state_hub_task_id: "3a454438-1955-547f-a491-8eab7cd25710"

Implement strangler handoffs coordinated with RMGR-WP-0001 and HUB-WP-0004. Compatibility tests for each dispositioned route family.

Owner-readiness correction (2026-08-20): T02's slice plan marked all 167 repo-manager items receivable because RMGR-WP-0001/0002/0003 are finished. That reads readiness off workplan status, which is too coarse. Verified against repo-manager/src/repo_manager/: those workplans delivered work-record dual-run, repository observation, and scaffolding. parse/ holds only workplan.py, and the source tree has no reference to sbom, repo_goal, contribution, technical_debt, or extension_point.

So only A1 (partial) and A2 are receivable — 86 items, not 165. A3 (registers, 49), A4 (UI, 22) and A5 (topic spine, 8) have no owner-side surface at all, and RMGR-WP-0004/0005 do not cover them.

Critical path is now repo-manager-side, not here: a repo-manager workplan must build the register, UI, and topic surfaces before 79 Wave A items can move. Building them in State Hub is inadmissible under policies/retirement-freeze.md — it would be new permanent ownership in the component being retired.

A2 checked the same way (2026-08-20): the State Hub adapter exposes exactly three operations — rm_update_task_status, rm_reconcile, rm_scaffold. There is no adapter for workplan CRUD, intake, decision, dependency, or human-flag records, and no repo-manager parser for them either. A2 therefore splits into A2a (task status + reconcile, ~6 items, receivable) and A2b–A2e (~32 items, not receivable).

A2a is the only slice in the whole plan executable today. Its next step is operational rather than code: rmgr dual-run-status shows dual-run entirely off (config_exists: false, writeback/reconcile false, no pilot repos; the 23 metered mutations are RMGR-WP-0002/0003 pilot residue). Moving A2a from off to dual means creating ~/.repo-manager/dual-run.yaml, enabling RM_WRITEBACK and RM_RECONCILE for one pilot repo, and watching the mutation meter for divergence. Reversible by clearing the flags; needs an operator decision because it changes how live task writes flow.

Net: of 425 inventory items, roughly 6 can move today. The retirement is gated almost entirely on owner-side capability in repo-manager and hub-core.

Readiness update (2026-08-21): RMGR-WP-0008 is finished, HUB-WP-0004 is finished, and the cutover slice plan now records the corrected receiving/UI boundaries. Workplan/register/classification adapters and compatibility tests exist; execute them by slice rather than relying on this earlier readiness snapshot.

Deterministic-identifier compatibility sub-slice (2026-08-21): fleet owner declared namespace helixforge. Repo Manager's sealed plan covers 242 live records across 42/42 eligible repositories with zero collisions, but apply is not yet authorized. State Hub uses workplan/task UUIDs as primary keys referenced by progress, decisions, dependencies, token events, launches, and other tables; those foreign keys do not use ON UPDATE CASCADE. This task owns the temporary transactional projection migration, durable old-id aliases, rollback rehearsal, and compatibility evidence needed by RMGR-WP-0005-T04. Do not rewrite repository UUID fields until that sub-slice passes in isolated PostgreSQL.

Identifier projection gate implemented and rehearsed (2026-08-22): Alembic revision b8d4f0a2c6e1 adds durable old→new alias provenance and converts all 20 foreign keys into workplans.id / tasks.id to ON UPDATE CASCADE, while retaining their existing delete behavior. The internal executor verifies the Repo Manager plan seal, helixforge namespace, UUIDv5 derivation, repository membership, source presence, target absence, and alias consistency before a repository-atomic apply. Reverse runs task-first/workplan-second and retains the aliases as reversed; plan entries with action: assign are deferred to normal file reconciliation because there is no old projection row to rewrite.

Isolated PostgreSQL evidence: migration upgrade produced 20/20 update-cascade constraints plus the alias table; downgrade restored 20/20 no-action update constraints and removed the table. Service tests cover cascades through task parentage, progress, token accounting and dependency edges, forward/reverse alias state, and all-or-nothing failure (3 passed). Full State Hub regression: 622 passed. No live database migration or repository UUID rewrite was run. The remaining gate is an operator-approved pilot ordering the central database transaction and authoritative file rewrite/reconciliation as one recoverable cutover unit.

Repo Manager pilot executed (2026-08-22): the workstation projection was the only instance holding RMGR-WP-0005; the production/registrar projection had no matching row. A verified 4.4 MiB preapply PostgreSQL dump was retained at /tmp/state-hub-rmgr-wp-0005-pilot-preapply.dump. The live schema advanced to b8d4f0a2c6e1, then six workplan/task primary keys migrated in one transaction. All 12 child-task links, 12 workplan progress links, one decision link, and three task progress links followed. Six aliases are applied; all old rows are absent and all new rows present. Repo Manager committed the matching file rewrite in 5de754a; two consistency runs produced a fresh, non-stale index and the new workplan API lookup returns 200 while the old lookup returns 404.

The absent registrar row exposed the final rebuild gap before remote ingestion: create schemas did not accept authoritative UUIDs and consistency classified a missing derived row as an unfixable stale reference. The projection rebuild path now accepts file UUIDs, derives IDs when a live file has none, and registers a missing derived workplan/task without rewriting the authoritative identifier. Focused rebuild/API tests and the full State Hub suite pass (624 passed).

Empty-projection rebuild proof (2026-08-22): consistency now has an explicit, registrar-only --bootstrap-empty-projection mode. It is limited to one local repository, proves the target has zero projected workplans before mutation, and preserves authoritative UUIDs for workplans, tasks, intakes, and decisions. Repo Manager's governed wrapper additionally verifies every expected UUID and fails on authoritative checkout mutation. A fresh disposable database rebuilt all 9 Repo Manager workplans, 62 tasks, and 2 intakes; a second read-only pass reported zero issues and 9/9 bindings. State Hub commits 03c7924 and 059de93; evidence is recorded in Repo Manager under docs/evidence/RMGR-WP-0005-isolated-rebuild-2026-08-22.md. Hub-native history remains a separate, unresolved centralization gate and was not copied.

Production registrar pilot completed (2026-08-22): a verified 4.6 MiB custom-format dump was retained at /tmp/state-hub-registrar-rmgr-wp-0005-preapply.dump (SHA-256 01753744bc844b154900ead916f122946c5414e77f888c3e18016cae6d3d8929). Helm revision 10 atomically promoted image main-697dd49; the dry-run and live pod both confirmed sweep.enabled: false with no host or SSH mounts. The production schema advanced from f0a1b2c3d4e5 to b8d4f0a2c6e1; health remained green, all 20 relevant foreign keys use ON UPDATE CASCADE, and the alias table exists.

The registrar did not previously contain the logical repo-manager repository or its workplans. After registering that repository, governed projection repair created only deterministic RMGR-WP-0005 UUID 6dcf854e-9229-569d-90f0-2d9df235a61d and its 12 authoritative task UUIDs. File and production task-ID sets match exactly; the new workplan lookup returns 200, the former random UUID returns 404, and a second read-only consistency pass has no RMGR-WP-0005 issue. The eight other random-ID Repo Manager workplans remain explicit non-fixable stale references in this formerly empty projection and were not ingested. Production aliases remain empty as expected for a rebuild rather than an in-place rewrite. Widening beyond this one-repository pilot still requires a separate fleet cutover decision.

Sealed pre-derivation repair interface approved with safeguards (2026-08-23): Repo Manager interface helixforge.identifiers.state-hub-sealed-projection-repair.v1 is accepted as a temporary T04 compatibility sub-slice. The owner implementation adds POST /identifier-migrations/sealed-projection-repairs and keeps ordinary C-03 refusal unchanged. Repair is limited to one explicitly named workplan and all of its sealed replace task mappings; it requires the exact plan seal, clean synchronized Git revision and source fingerprint, explicit primary confirmation, existing repository/topic projection, and complete absence of both the old unit and derived targets. Creation is one database transaction; an exact retry returns a verified no-op receipt, while partial presence, source drift, aliases, target rows, or content mismatch fail closed. Operational and removal contract: docs/sealed-prederivation-projection-repair.md.

Verification: focused identifier-migration coverage passes (13 passed), the ordinary consistency suite passes (129 passed), and the full API plus dashboard build passes (650 passed). The full run retained one pre-existing SQLAlchemy resource warning and one pre-existing dashboard link warning.

A2a executed (2026-08-20) — first live cutover slice. Dual-run is on for the pilot repo:

• ~/.repo-manager/dual-run.yaml installed from repo-manager/config/dual-run.pilot.example.yaml — writeback: true, reconcile: true, writeback_push: false, pilot_repos: [repo-manager]
• State Hub API reloaded via its own --reload watcher (no service restart, the operator's foreground make api was left alone)
• statehub fix-consistency --repo repo-manager reported RM dual-run reconcile ok: index=/home/worsch/repo-manager/.repo-manager/index.json
• mutation meter grew 23 → 24 with {"kind": "reconcile", "repo_slug": "repo-manager", "workplan_count": 8, "task_count": 53, "record_count": 61}

Divergence check: rmgr's index holds 8 workplans; the hub has rmgr-wp-0001–0007 registered. The single-item delta is RMGR-WP-0008, whose C-06 registration was skipped because this instance is not the identifier registrar (ADR-007 interim). That is a known registrar limitation, not dual-run divergence — rmgr correctly indexed the file that exists on disk.

Slice state: A2a is dual, not owner — the hub remains authoritative and rmgr executes checkout mutation alongside it. Promotion to owner needs a full consistency-sweep cycle at dual with zero divergence, per this plan's adapter rules. Rollback is rm ~/.repo-manager/dual-run.yaml.

Registrar bottleneck — status check 2026-08-21

The registrar is reachable, and was all along. bridge status shows all seven tunnels connected and LIVE, including state-hub-primary. It binds [::1]:8000 — IPv6 localhost — while the workstation API listens on 127.0.0.1:8000 (IPv4). Same port number, different stacks, so a 127.0.0.1 probe silently hits the local hub and looks like the tunnel is down. Anything checking registrar reachability must use the bracketed IPv6 form.

But the two databases have diverged badly:

	workstation (127.0.0.1:8000)	registrar ([::1]:8000)
workplans	987	649
tasks	5 710	4 037
decisions	119	80

The registrar is 338 workplans and 1 673 tasks behind. It also runs older code — its /state/summary still returns open_workstreams where the workstation returns open_workplans, so it predates the terminology rename.

This is exactly the ADR-007 defect RMGR-WP-0005 describes, at fleet scale: two instances over two databases, each minting database-local primary keys into shared git artifacts.

A queue has formed. Ten unread messages to state-hub, nine of them registrar sync requests from three agents (agentic-resources, glas-harness, kaizen-agentic), all dated 2026-08-20 — plus this repo's own RMGR-WP-0008. Agents fleet-wide are now blocked on identifier registration.

The dependency chain, re-checked:

• RMGR-WP-0004-T08 (prefix uniqueness enforcement) — done 2026-08-18
• RMGR-WP-0004-T09 (assign shared prefixes) — executed 2026-08-17 as an authorized exception, still wait, with one stated residual: "Not yet reconciled — the workstation is not the registrar"
• RMGR-WP-0005-T03 (deterministic UUIDv5 derivation) — still wait, but its stated blocker RMGR-WP-0004-T08 has closed

T03 is the permanent fix: derived identifiers make writeback idempotent, so any number of hubs write identical bytes and the queue disappears. Its formal gate is clear. Its substantive gate is not — ADR-007 § Migration option 2 lets historical files keep colliding identifiers (CUST-WP, RAILIANCE-WP, and PRJ-WP in prj-forgejo-org-refactor all still present in the 2026-08-18 scan), and deriving UUIDv5 from a non-unique identifier manufactures collisions rather than removing them. That tension needs a ruling before T03 can start.

Inherited (2026-08-19) from STATE-WP-0080-T04: this slice now also owns deletion of the templating path in statehub_register.py — INTENT.md generation, the AGENTS.md / CLAUDE.md / .custodian-brief.md templates, project_rules/, and bootstrap-workplan generation. The code is dead-but-present: project repos are already routed to rmgr scaffold. Gate the deletion on RMGR-WP-0004-T06 proving byte-identical durable output and idempotent re-scaffolding.

Brief compatibility repair (2026-08-23): the surviving consistency generator degraded the-custodian to Domain: (unknown) and emitted get_domain_summary("") even though GET /repos/the-custodian correctly projected domain_slug: infotech. Active workplans can legitimately have no topic, so topic inference is not authoritative. The generator now prefers the repository projection and retains topic lookup only for legacy API responses that omit domain_slug. Two regression tests cover both paths; all 131 consistency-check tests pass. This is a compatibility fix until the generator moves or retires, not new permanent State Hub authority.

Ad-hoc identity compatibility repair (2026-08-23): the surviving project instruction templates prescribed fleet-wide ADHOC-YYYY-MM-DD identifiers. Activity Core and Net Kingdom used that form on the same day, and deterministic derivation correctly refused the second record. Templates and the legacy ADR validator now accept and prescribe {WP_PREFIX}-ADHOC-YYYY-MM-DD while keeping the daily filename unchanged. A regression test covers the filename/id pairing. This prevents new collisions without making State Hub the long-term convention owner.

Owner-gate reconciliation 2026-08-31. The previously open receiving-side gates have advanced materially: RMGR-WP-0005 finished the deterministic identifier migration, HUB-WP-0005 put all hub-core route and writer groups into production ownership with exercised rollback, and ACTIVITY-WP-0029 finished the schedule, consistency-sweep, interaction-event, and execution-boundary handoffs. Those are durable owner records and no longer block this task.

They establish receiving-side readiness only. They do not, by themselves, prove that State Hub callers and route families have switched or that the required parity, rollback, and production receipts exist.

D1 receiving contract completed 2026-08-31. OPS-WP-0003 is finished with all three tasks done. Ops Hub now publishes the reviewed capability.operations.ops-hub and capability.operations.service-catalog owner package, passes hub-core's schemas/catalog and all eight implemented conformance checks, and passes the post-cutover public /api/v2 gate. Framework checks absent from contract 0.1.0 are live owner residual HUB-WP-0009 / State Hub UUID 0d6e94f3-fd15-5f57-af41-60f0b862da5e; they do not return D1 ownership here.

D2 receiving contract completed 2026-08-31. FIN-WP-0003 is finished with all three tasks done. railiance-fabric revision 113445d now publishes the direct financial-fabric-v1 authority export, deterministic accepted-snapshot revision provenance, graph edge/summary reads, and regression coverage. Fin-hub revisions debe67e / 5fe943d publish the consumer contract and executable schema/content-hash/count/provenance gate. Retirement-project revision 1812170 corrects all ten Fabric items from fin-hub/move to railiance-fabric/replace; hub-core projection is explicitly deferred.

The receiving contract is ready, but the production cutover is not. The first gate run correctly returned no-go: the authority has 131 nodes / 117 edges, while State Hub has 49 / 58, with a different content hash and null source revision/path/export time. T04 therefore remains wait on selecting and refreshing one authority snapshot into the dual-read window, obtaining a green finhub fabric-cutover-check, recording route-switch/rollback receipts for the remaining repo-manager/hub-core/activity-core/ops-hub families, and explicit authorization for production writer changes. It must resume from a fresh caller scan, not from the obsolete 2026-08-20 snapshot.

D2 dual-read evidence completed 2026-08-31. The deterministic authority snapshot is now the active railiance01 read model at import 47e5358e-d04b-4969-99a2-ca88423ad054: 131 nodes, 117 edges, 2 actors, 1 fabric, 0 unresolved, content hash caae6679…, snapshot-set revision 991bca29…. finhub fabric-cutover-check is green on every schema, content, count, and provenance check; exact re-ingest is idempotent. A receiver contract drift/column-width defect was fixed in cf40c7b and deployed with migration b5e6f7a8c9d0 as Helm revision 56. Immutable-import activation was added in cdff3b7 and deployed as revision 57. Production rollback to retained import f844733d… (49/58) and roll-forward to 47e5358e… (131/117) were both exercised, followed by another green gate.

The fresh named-repo caller scan found no runtime consumers of /fabric/graph*; only contracts, docs, and retirement inventory matched. The owner service is still workstation-local and its accepted-snapshot freshness is not automated, so hosted runtime/persistence/auth/freshness and the eventual direct route are live owner residual RAIL-FAB-WP-0028. Evidence: docs/evidence/STATE-WP-0079-d2-dual-read-20260831.md. T04 remains wait on the non-D2 repo-manager/hub-core/activity-core/ops-hub route receipts and the explicit writer-change authorization already stated above.

Retire legacy surfaces

id: STATE-WP-0079-T05
status: wait
priority: medium
state_hub_task_id: "f6cf8c01-eb59-5ca8-a541-23928d4a000c"

Complete retirement of suggestions, workstream aliases, and other retire inventory items once meters/callers allow. Keep historical rows archive-readable.

Blocker identified (2026-08-20): the legacy-meter evidence this task gates on was being captured over an 8-hour band, not a week — capture_legacy_meter_evidence.py fell back to hours=8 whenever --days was omitted, so 39 of 40 captures sampled only 06:00Z–14:00Z. Interfaces called outside that band read as unused. Three candidates on the 2026-08-19 capture had live callers, including GET /tasks/?workstream_id (seen 2026-08-18).

Script default corrected to days=7; corrected capture docs/evidence/legacy-meter-weekly-review-20260820.json.

Candidate rule tightened (2026-08-20): _retirement_state now requires a quiet period scaled to all-time call volume (RETIREMENT_QUIET_LADDER: 7d under 100 calls, 30d under 10 000, 60d above). On the 2026-08-20 capture this makes 15 of 19 legacy interfaces retirable — all workstream MCP tools, the state:// resource, and the low-volume REST aliases — while holding the three six-figure read paths (GET /workstreams/, GET /workstreams/{id}, GET /workstreams/{id}/dependencies/) and GET /tasks/?workstream_id, which still has live traffic. Covered by 7 new tests in tests/test_legacy_meter.py.

Slice E2 executed (2026-08-20): the 15 evidenced interfaces are retired in the legacy meter — all four workstream MCP tools, the state:// resource, and the low-volume REST aliases including PATCH /workstreams/{id} (571 calls), POST /workstreams/ (824) and POST /workstreams/{id}/dependencies/ (4 971). Meter now reads 16 retired / 4 legacy, 0 outstanding candidates. Evidence: docs/evidence/legacy-meter-weekly-review-20260820.json.

Retirements are journalled fleet-side at the-custodian/docs/retired-legacy-interfaces.md — deliberately outside this repo, since State Hub is being archived and the record must outlive it.

Remaining work for this task: the 4 held interfaces (GET /workstreams/, GET /workstreams/{id}, GET /workstreams/{id}/dependencies/, GET /tasks/?workstream_id) clear as their quiet counters run; earliest is 18 more silent days. Re-capture before deciding — the ladder evaluates at review time. Slice E1 part-executed (2026-08-20): suggestion-backlog history archived to the-custodian/docs/archived-suggestion-backlog.md — 10 suggestions, 10 notes, 5 bumps, all declined in the 2026-07-21 intake migration, none promoted. Mutations already 410 since CUST-WP-0061-T06; reads were open only to keep that history reachable, which the archive now replaces.

E1 removal executed the same day: the 8 read routes 410 with a pointer to intake and the archive, the 6 MCP tools are removed outright, the 5 /suggestions write-idempotency rules are dropped, and the dashboard page is deleted with nav, reference.md and wsjf-triage.md updated; dashboard/src/docs/suggestions.md is now the archive pointer. Tables remain for the T06 dump. Two tests that pinned the old read-live behaviour were rewritten to pin the retirement contract.

Naming trap for cutover: ui-feedback.md / todo.md "suggestions" are Shift+click dashboard feedback backed by technical_debt, not this capability. Untouched.

E3 (dashboard-meta) is /ui-feedback — that same feedback surface. Owner is state-hub-until-cutover and it is still in use, so it retires at the T06 freeze window, not now.

Then dashboard-meta (E3, 1); legacy-meter itself (E4, 9) retires last, being the instrument.

Execution launch-request defect closed (2026-08-23): the surviving POST /execution/launch-requests route claimed Activity Core pickup after that mapping was explicitly retired by ACTIVITY-WP-0029-T04. New submissions now return 410 with the repository-file / ActivityDefinition+ops_run replacement; GET /execution/semantics explicitly says launch requests are not accepted, that Activity Core does not consume them, and that legacy launching does not prove pickup. Historical launch rows remain readable. The two reported requests (7052b20f…, 5628fe55…) were cancelled as never consumed and their workplans restored from launching/immediate to manual/manual. Focused execution coverage passes (4 passed); the combined full regression and dashboard build remains green (650 passed).

Central meter review 2026-08-31. The corrected seven-day review found six replacement-verified interfaces past their volume-scaled quiet period. They were marked retired on the sole railliance01 primary: the old workstream completion event subject, DELETE /workstreams/{id}, two low-volume SBOM compatibility reads, GET /workstreams/workplan-index, and POST /workstreams/{id}/dependencies/. The recapture now reports 6 retired, 9 legacy, and zero currently eligible candidates. The remaining nine include live SBOM callers, live GET /tasks/?workstream_id, the three high-volume workstream reads still inside their 60-day quiet window, and two workstream mutations still inside 30 days. Evidence: docs/evidence/legacy-meter-weekly-review-20260831.json. T05 remains wait; T06 must not start.

The nine held interfaces are explicitly owned by this task until the meter allows retirement; they are not untracked prose residuals. Three SBOM reads and GET /tasks/?workstream_id still had calls in the seven-day review window. Three high-volume workstream reads have only 9 of 60 required quiet days, while the two workstream mutations have 14/30 and 15/30 quiet days. A future review must recapture central-primary evidence and apply the existing volume ladder; calendar passage alone is not retirement evidence.

Stabilization window and archive prep

id: STATE-WP-0079-T06
status: wait
priority: high
state_hub_task_id: "9230c99b-af58-5794-9291-452e619a30fa"

With T06 gates: zero normal read/write window, final dump, backup/restore evidence, stop service, archive repo read-only. Residuals → live owners.

Blocked 2026-08-31. The sole railiance01 primary is healthy and remains the active coordination service, the legacy meter has live callers, and T04 still has owner-side cutovers. A freeze, final dump/restore rehearsal, service stop, or repository archive would therefore interrupt normal work and destroy the evidence needed by T05. T06 remains wait until T04 and T05 are done and a fresh central meter demonstrates the required zero normal read/write window.

Acceptance

• Freeze policy documented
• Strangler plan covers all inventory capabilities
• prj-/GOAL.md register path works
• Move/replace slices evidenced with tests/counts
• Retire list closed or residual-owned
• Stabilization + archive prep ready for project retirement