Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQ6oF1DtVDKcD1FCpvRVLx
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272883@bnt-lap001
Assistant-Session: f40c8f53-fb65-4980-9d29-bcdb3dd946f7
Implements CUST-WP-0070-T02. publication joins DURABLE_FLAVORS, so CATEGORIES
picks it up automatically; classification.py and the cli --category choices are
updated to match canon v1.1.
A published corpus of authored records previously had to be filed as project —
the only non-durable category — implying eventual retirement of something meant
to be kept. Repos with no classification file at all fell through to
flavor=tooling.
Full suite: 161 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQ6oF1DtVDKcD1FCpvRVLx
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272883@bnt-lap001
Assistant-Session: f40c8f53-fb65-4980-9d29-bcdb3dd946f7
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
