Close T02–T06 from live hub evidence, disposition clay-borg product
records as not workplans, lift the task-reset restriction in state-hub,
dump and remove the retired local Postgres instance, and record ADR-010's
work-record divergence as closed.
Repo Manager now owns the State Hub access map and the registrar no longer
fails its own generated-index precondition. Close 0067; 0068 continues with
the remaining recovery tasks.
Keep the UUIDs the registrar minted for CUST-IN-0015, CUST-WP-0068-T09,
and the ad-hoc workplans after the run failed on an unrelated historic
task create.
Close CUST-WP-0064 after the 2026-08-24 unassisted fire ingested
clay-borg, close CUST-WP-0065 now that all 120 active repos project a
classification, and close ADHOC-2026-08-25. Mark CUST-WP-0067 T02/T10
done (reverse relays already gone; work-record recovery lives on 0068).
Park the later no-checkout SBOM regression as CUST-IN-0015. Teach the
classification gate to use this host's checkout path.
The reset now exists and has run fleet-wide, so T09 moves from wait to todo.
Every railiance-wp-* row is retired and its identifier released, meeting the
first acceptance clause.
The recorded 305 stale task rows no longer describes what is there: measured
against what the forge derives, 21 orphaned rows remain under live workplans
(0 open), 557 have no record_id at all (34 open), and 512 sit under workplans
retired today. Most of the 305 left the live surface with their workplans
rather than being repaired.
What remains is one change: reset_repository_projection still skips the tasks
of existing workplans, a restriction adopted when hub tasks had no canonical
identifier. They have one now, so the reason is gone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Discovered before implementation: discard-and-rebuild cannot exist. Progress
events, tasks, decisions and review contracts reference workplans with ON DELETE
RESTRICT, and 1067 of 1075 workplans carry such a reference. Deleting a workplan
would delete the hub-native records attached to it, which ADR-010 decision 4
forbids and the schema refuses.
The database is enforcing this ADR's own boundary one layer down. A progress
event is a fact that happened; destroying it to tidy a derived projection loses
hub-native truth to fix a derived-state problem.
Reset now reconciles: create what is missing, update what differs, retire what no
longer derives — and retirement must be visible rather than silent.
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>
ADR-012 accepted 2026-08-25.
ADR-010 — partially superseded, notes added inline:
decision 1: "a reading of the repositories" never said which copy, and the
answer was neither the forge nor a working copy but whichever checkout last
synced. The hub holds no repository files and never reads one.
decision 5: "central derives, does not accept pushes" was policy while the
workstation pushed everything.
decision 6: "preliminary" was named but never built.
ADR-003 — partially superseded:
decision 2: fingerprints composed from filesystem mtime are invalidated in
part. mtime is a property of one workstation, differs across clones, and
says nothing about content. Evidence: git_fingerprint for the-custodian
held the initial commit while last_state_synced_at was minutes old.
decision 5: the rebuild principle was correct but never exercised, and its
"without data loss" claim holds only while nothing exists solely in the hub
— which was false for 111 records on 2026-08-25.
ADR-001, ADR-005, ADR-007 and ADR-011 reviewed and unaffected; ADR-007 is
reinforced, since derived identifiers let an overlay and a forge-derived
projection compute the same identity.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Refines decision 7. Per-repository rebuild is not a convenience over a
fleet-wide operation: the repository is the unit, and the fleet-wide form is
defined as iteration over it.
It follows from the source — each forge repository has its own history and head,
so its projection is derivable and provable in isolation. It bounds blast radius,
which is what makes "routine" achievable: a rebuild that only runs fleet-wide is
one nobody runs casually and therefore nobody runs, which is how ADR-010's
never-executed reconstruction claim came to be believed.
It is also the only form that composes with the refusals. A repository holding
projection-only records can be held back while healthy ones rebuild; an
all-or-nothing reset is blocked permanently by a single bad repository. The
refusal is therefore evaluated per repository, and a fleet run skips and reports
rather than aborting.
The fleet-wide form must share the per-repository implementation, so the rare
dangerous path is exercised by the common safe one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds decision 7: the projection must be discardable and rebuildable from what
Forgejo holds, per repository and fleet-wide.
This is what makes the other decisions checkable. A read model that cannot be
rebuilt from its source is a database with a projection's reputation, and the
difference only surfaces when someone needs to rebuild it. ADR-010 already
asserts a cache may be reconstructed at any time; that claim has never been
executed.
Three properties keep it real: routine rather than emergency, scoped per
repository, and idempotent enough to verify against the forge — which derived
identifiers make possible.
Two refusals are explicit. Reset cannot restore the preliminary overlay, since
the forge does not hold it. And reset must refuse when records exist only in
the projection: on 2026-08-25 that was 111 work records, which a rebuild would
have erased while reporting success.
Also flags an unresolved boundary: hub-native records are not forge-derived and
must survive a rebuild of forge-derived state.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-001 and ADR-010 both leave unanswered which repository files the hub reads.
Verified 2026-08-25: neither the forge nor a working copy — the projection
derives from whichever checkout most recently ran the sync, which is written
down nowhere.
Proposes the forge as projection source, unpushed local work as a labelled
preliminary overlay rather than a second store, and commit provenance on every
record. Implements ADR-010 decision 6's unbuilt notion of "preliminary" and
sharpens decision 1 rather than reversing it.
Status: proposed — needs review before anything is built on it.
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>
