The live-file pass missed these: archived ad-hocs carry a YYMMDD- filename
prefix, so the ADHOC-* glob did not match them. They still derive from the
forge, so they are live records rather than dead files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Canon defines six work-record kinds — workplan, task, intake, decision,
engagement, register-entry. These files declared none of them (feature, runbook,
bug-report, extension-workplan, scorecard, session-note, adhoc) while the hub
held each as a workplan.
Selection is by 'type: workplan', so the mismatch made them invisible to any
projection: a forge-derived reset read their correct hub records as no longer
deriving and proposed retiring live work.
Where a file also lacked a canonical identifier, one was assigned continuing the
repository's sequence. Existing hub identifiers are preserved, so no record is
orphaned.
Refs STATE-WP-0083
A missing newline fused the closing delimiter onto the last frontmatter value
(`- KONT-WP-0016---`), or fused a value onto the following key. Either way the
frontmatter never terminates and the whole body is swallowed.
Because workplan files are selected by `type: workplan`, such a file is not
invalid but invisible: it appears in no projection, raises no error, and is
reported as neither a workplan nor a problem. A forge-derived reset would
therefore read its correct hub record as no longer deriving and propose retiring
live work.
Only the missing newline is inserted; no value is altered.
Refs STATE-WP-0083-T08
KONT-WP-0013 renumbered, archived RAILIANCE-WP migrated, unqualified ADHOC
accepted per CUST-WP-0066, OPS-WP-* newly visible and undecided. Forge-side
collisions fell 45 to 16.
Central still reports 35 duplicates because archived workplans are never
registered — the registrar scans only top-level workplans, closed archives being
frozen under ADR-007. The renames re-derived projection UUIDs, so the old rows
are now unclaimed by any file, which is exactly the condition ADR-012 decision
7's reset retires. The duplicates clear when that reset runs, not before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The fleet-wide re-sync took unbacked workplans from 265 to 29. ADR-010's orphan
rules applied to the remainder: all 29 are closed, none is an ADR-001 violation,
and all are retained as provenance under the "closed hub-first records" rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fleet-wide re-sync across 120 repositories: 1075 bindings sent, 1015 written,
workplans recording no backing file fell from 265 to 29. ADR-010 predicted this
as the "broken links" class and it was 89% of the apparent orphans.
The 29 remaining are all closed: 23 finished, 6 archived, none open.
Corrects T09's scope: the prefix migration left 4 orphaned rows, not 26. The
other 22 are still backed by the archived RAILIANCE-WP files that migration
deliberately did not rename. The overstatement came from counting rows by slug
prefix rather than by whether a file backs them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An attempt to purge stale task rows established that the hub has no hard-delete
for work records at all: DELETE /tasks/{id} is cancel_task, DELETE
/workstreams/{id} is 410 Gone, and no session.delete exists for either.
Re-derivation is not one removal option among several, it is the only one
permitted — a deliberate property, since a read model that cannot drop a record
except by re-deriving cannot be quietly edited into disagreeing with its source.
Scope is now 26 workplan rows plus 305 task rows across 44 workplans, of which
only 9 show open. All wait on ADR-012's per-repository reset.
No records were mutated: eight cancel calls hit STATE-WP-0080 tasks that were
already cancel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrating active workplans off the retired family prefix left 26 hub rows with
no backing file. Accepted deliberately: the alternative was one repository
carrying two prefixes indefinitely.
Blocked on ADR-012 decision 7's per-repository reset — C-07 is not fixable and
hand-deleting hub rows is the direct central edit ADR-010 decision 6 forbids.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Central 670 -> 1018 workplans; cache-only gap 426 -> 111.
T06 was scoped as an identifier-migration decision and that framing was wrong.
Two defects did most of the blocking: 50 repositories carried retired
gitea-remote URLs on central so fix-consistency could not match them, and the
registrar was blind to records that had an identifier but were absent from the
hub. Both were masked by a generic error whose real message sat in a child
process's stderr.
Also records the repo-wide re-key that severed eight working identifiers on
kaizen-agentic, and the rule now enforced in code to prevent it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
The file carried an identifier minted by the retired local hub while central
held a different record for the same file — ADR-010's same-filename,
different-UUID duplicate-registration class.
Central is authoritative (ADR-010 decision 1) and decision 6 says to mitigate
by changing the repository file rather than editing central, so the file adopts
central's id. The cache-side id dies with the cache.
Refs CUST-WP-0068
The registrar now binds workplan files in the same pass as minting, verified
end to end. The unbound remainder is explained: those identifiers are the
cache-only records this workplan exists to recover, so the count is a progress
indicator rather than a fault.
Remaining under T07: re-sync fleet-wide, re-measure the 278, then disposition
whatever is genuinely orphaned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backing_filename is written only by the bindings sync, which fix-consistency
runs before the registrar mints the UUID. Newly registered workplans therefore
record no backing file. Reproduced on CUST-WP-0068 itself.
278 of 800 workplans on central record no backing file, which is what ADR-010
predicted as the "broken links" class. The 23 cache-only orphans were counted
with the same field, so that number is an investigation starting point rather
than a work list.
T07 now repairs the ordering and re-measures before dispositioning anything.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Promotes the remainder of CUST-WP-0067-T10. 297 workplans and their tasks
still exist only in the retired local hub, which is why its database cannot be
discarded.
Eight tasks covering the registrar's self-defeating precondition, per-repo
unblocking, six non-conforming identifiers, clay-borg's 50 unparseable
workplans, the 176 with non-empty projections, the identifier ruling that
overlaps RMGR-WP-0005, 23 orphans, and final convergence.
Carries forward a correction: ten of sixteen records flagged as
non-conforming are ADHOC-YYYY-MM-DD, which is the documented convention. The
classifier's pattern was wrong, not the files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Central 670 -> 799. All 403 cache-only workplans with a backing path have that
file on disk, confirming ADR-010's finding that nothing was lost.
Only 57 carry deterministic identifiers, so C-06 refuses most as stale
references. --bootstrap-empty-projection recovers them with identifiers
preserved, verified on one repository before rollout.
Classifies the 297 remaining and lists per-repository blockers from actual
error messages. Corrects this task's own earlier reading of
bootstrap_source_invalid as a single cause: it covers at least two.
Recommends promotion to its own workplan — the mechanical share is done; the
rest needs content fixes, an identifier decision overlapping RMGR-WP-0005, and
owner judgement across ~40 repositories.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
All 44 cache-only repository records resolved: 43 onboarded and classified,
agent-harness dropped by owner decision. Central holds 121 repositories.
Corrects an earlier claim in this workplan that the cache would hold nothing
unique once the repository records were resolved. That generalised a
repository-scoped result: the cache still holds ~400 workplans and ~1,950 tasks
that exist nowhere else, which is ADR-010's original divergence.
The cache database still must not be discarded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Superseded by glas-harness and the rein concept, so there is nothing to
restore. Not onboarded to central; its cache-only record is left to disappear
when the cache database is discarded, rather than preserved as a hub-only
record with no backing file.
Successors verified present and classified on central before dropping.
Ten records remain outstanding.
Refs CUST-WP-0067-T05
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Release 20 carries the canon vocabulary; classification writes succeed against
central for the first time from outside a workstation. All 33 onboarded
repositories re-run and projected: 33 updated, no warnings. Central holds 111
repositories, 100 classified.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
178 AGENTS.md files moved off the 127.0.0.1:18000 reverse tunnel to the
in-cluster address; both machines report zero stale rows. 100 pushed from the
workstation, 74 picked up by pull on the node, 4 handled individually.
binky-control committed but not pushed — it carries 6 pre-existing unpushed
commits that are not this change's to publish. activity-core was already 39
behind with an unrelated dirty file; only AGENTS.md was taken from origin.
state-hub-railiance01 is now unblocked for removal.
Still open: the block has no single source, so this recurs on the next
topology change; and 68 non-AGENTS.md references need individual judgement
rather than substitution.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three dated corrections, following the blockquote convention ADR-007 uses:
- Decision 2's merge/refresh dichotomy is not exhaustive. Repository records
took a third shape — cache-only records whose source exists and is reachable
but was never introduced to central. Refreshing would have destroyed them.
- The Context recorded the shared port but not why it was silent: an unbound
ssh -L binds every loopback family, and ExitOnForwardFailure fires only when
every bind fails.
- A new Outcome section states that the ADR's own remediation never landed and
the condition was still live seven weeks later.
Refs CUST-WP-0067-T06
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rmgr repo-onboard is the missing managed_repos write path. 33 of 44 cache-only
repositories onboarded to central (78 -> 111); the other 11 carry written
dispositions rather than guessed classifications.
T04 uncovered why onboarding only worked from a workstation: the hub resolved
its classification allowed-values file from hardcoded developer checkouts, so
every classification write 500'd in the container. T09 delivers that file.
The local cache database must not be discarded yet — 11 records live only there.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
state-hub-mcp serves SSE on ClusterIP 10.43.110.80:8001, verified from the node
rather than through a tunnel, and reads central's data end-to-end (79 repos).
Remote port map and dev-hub registration repointed off the reverse tunnel.
state-hub-mcp-railiance01 is now safe to remove. state-hub-railiance01 is not:
~120 AGENTS.md files still depend on it until T07.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Remote repointing turned out to be larger than a config change. The port map
is prose copied into ~120 AGENTS.md files with no generator behind it, and the
Helm chart deploys no MCP server on central, so remote dev-hub exists only as
a reverse tunnel to the workstation.
Global agent instructions repointed to the in-cluster ClusterIP; the two
reverse tunnels stay until T07 and T08 remove what depends on them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator decision 2026-08-24: rather than making two hub instances coexist
safely, retire the second one. The local postgres+uvicorn instance is what
impersonates central and is redundant with ADR-010 decision 3 plus Repo
Manager's file-derived index.
With it gone, state-hub-primary binds 127.0.0.1:8000 unchanged and every
existing default becomes correct with no call-site edits.
Adds the cache-only recovery export (44 records) as the T05 source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-010 documented two hub instances sharing port 8000 separated only by IP
family; the condition was never remediated. Repo onboarding from the
workstation has landed in the local cache since 2026-07-08 — 122 cache repos
vs 78 central, a strict subset with 0 central-only records.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>