Ignore generated WORK-RECORDS.md/.custodian-brief.md in the registrar git
precondition, commit identifier writebacks even when registration is
incomplete, and name the remaining records in the error. Add
config/state-hub-access.yaml as the single source for the AGENTS.md port
map, rendered by rmgr scaffold and refreshed with --refresh-hub-access.
Assistant: grok
Assistant-Session: 01a04996-76e8-7f53-b971-1885cfbed436
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
I retired OPS-WP on the reasoning that it names an ops family rather than a
repository, without checking whether a repo owns it. ops-hub does: all 14 of
its workplans use it. The anomaly is the reverse of what I wrote - the 16
OPS-WP ids in ops-bridge are the strays, against its 73 BRIDGE-WP ids.
Recorded as debt rather than fixed here: re-keying those 16 to BRIDGE-WP is a
separate migration with its own hub retirements, and today's pass is scoped to
ad-hoc identifiers.
WHYNOT-WP stays with whynot-design (26 ids vs whynot-control's 6), ruled by
Bernd. whynot-control's 6 are the same class of stray.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Both needed for the archived ad-hoc pass; each used consistently in its repo
(160 and 26 ids) with no collision against an existing owner or retired prefix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Qualifying ad-hoc identifiers requires every repo to own a registered prefix,
and 13 of the 17 affected repos were absent from the registry despite using a
prefix consistently across dozens of files. None collided with an existing
owner or a retired prefix.
net-kingdom and ops-bridge each used two forms. NK-WP (229 ids vs NET-WP's 49)
and BRIDGE-WP (73 vs OPS-WP's 16) are the owners, ruled by Bernd. OPS-WP is
additionally retired for naming an ops family rather than a repository - the
same defect ADR-007 retired RAILIANCE-WP and PRJ-WP for. Existing NET-WP and
OPS-WP ids stay as they are; only their prefixes are closed to new work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for repo-manager
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
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
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for repo-manager
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Two blockers kept 268 work records unrecoverable.
1. The registrar only looked for *missing* identifiers, so a record whose
derived identifier was already in the file but absent from central was
invisible to it and the run short-circuited to noop. C-06 handles exactly
that case and marks it fixable; only the early return stood in the way.
Records the hub holds under a *different* identifier are deliberately not
touched — that is a duplicate-registration identity decision.
2. repo-onboard now corrects a stale remote_url from the working copy's origin.
The forge migration moved every repository from Gitea to Forgejo but never
updated the hub, leaving 50 records pointing at a retired forge. State Hub
matches a checkout to its record by remote_url, so it could not find those
repositories and refused to register any of their work records — the error
surfaced only in a child process's stderr.
Verified on kaizen-agentic: 8 records on central before, 15 after.
Refs CUST-WP-0068-T06
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
backing_filename is what lets the read model tell a file-backed workplan from
a hub-only orphan. It is written by PUT /workplans/index/bindings, which
fix-consistency calls for workplans that already carry a UUID — but the
registrar mints the UUID afterwards, so a freshly registered workplan stayed
unbound until someone happened to run fix-consistency a second time.
Nobody did: 278 of 800 workplans on central recorded no backing file,
including four active and four ready. ADR-010 predicted this as the
"broken links" class.
The registrar now syncs bindings after minting, and on the noop path too —
otherwise a record whose earlier bind failed stays unbound forever, because
every later run returns early.
Binding never fails the registration: the identifiers are already minted and
committed, and a bind can be retried.
Status is sent only when already canonical. The binding schema validates
against the enum without normalising, so one legacy value 422s the whole
batch; omitting beats guessing a mapping that could drift from canon.
Refs CUST-WP-0068-T07
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
_check_primary accepted any instance reporting status=ok and db=connected.
A local cache and the central hub both satisfied that for seven weeks while
every registration went to the cache — a liveness check wearing an authority
check's name.
It now requires the hub to declare instance_role=primary. An instance that
declares nothing is refused with a message naming what to set; proceeding
anyway requires an explicit --allow-unverified-primary rather than a silent
default.
Four tests cover the logic directly; the existing suite stubbed _check_primary
and never exercised it.
Refs CUST-WP-0067-T03
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The remote row pointed at 127.0.0.1:18000, a reverse tunnel back to the
workstation. On railiance01 the State Hub runs in the cluster on that same
machine, so the request left the box and came back to reach a local service.
Refs CUST-WP-0067-T07
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
hub-record-authority.yaml assigns managed_repos to repo-manager as
file-derived, but repo-manager exposed no command for it. The only working
path lived in the State Hub repo and defaulted to 127.0.0.1:8000, which is how
seven weeks of onboarding landed in a local cache instead of central.
Order follows ADR-010 decision 5: make the source file correct and reachable
first, then project it. Refuses to onboard when the classification file is
missing or invalid, has uncommitted changes, has no upstream, or has unpushed
commits — a hub record whose backing file is only local cannot be re-derived
by anyone else.
--api-base has no default on purpose. A silent localhost default is the
original defect, not a convenience.
A failed classification PATCH degrades to a warning rather than failing the
run: the authoritative record existing is what stops a repository from being
recoverable only through a discardable cache, and classification is a
projection of a committed file that can be re-derived later.
Refs CUST-WP-0067-T04
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
