coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat(workplan): widen CUST-WP-0068-T09 to every stale hub row
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
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>
This commit is contained in:
codex 2026-08-25 23:08:04 +02:00
parent 6629212985
commit 2edde0edf9
1 changed files with 31 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

34
workplans/CUST-WP-0068-cache-only-work-record-recovery.md
View file

@ -298,7 +298,7 @@ verified only by the person who caused the damage.
By status the remainder is overwhelmingly closed history — 96 `finished`, 10
`archived` — with only 2 `active`, 2 `blocked` and 1 `proposed` still live.
## Clear the orphaned RAILIANCE-WP rows
## Clear the stale hub rows that no longer derive from any file
```task
id: CUST-WP-0068-T09
@ -330,8 +330,36 @@ Three repositories used one number space for unrelated work — `RAILIANCE-WP-00
was an openbao extraction, a cnpg backup, and a deploy-verify simultaneously —
and `railiance-platform` carried two files both numbered `0016`.
Acceptance: no `railiance-wp-*` record remains on central; the 26 are gone
through re-derivation rather than deletion.
### The same blocker covers every stale row, not just these 26
Widened 2026-08-25 by owner decision after an attempt to purge stale task rows
established that **the hub has no hard-delete for work records at all**.
`DELETE /tasks/{id}` is implemented as `cancel_task` — it sets status to `cancel`
and keeps the row. `DELETE /workstreams/{id}` returns `410 Gone`. No
`session.delete` exists for either. Removal by re-derivation is not one option
among several; it is the only one the hub permits.
That is a deliberate property worth respecting rather than routing around: a read
model that cannot drop a record except by re-deriving cannot be quietly edited
into disagreeing with its source.
Full scope of rows that no longer derive from any file:
| Count | What | Origin |
|---|---|---|
| 26 | `railiance-wp-*` workplan rows | the prefix migration above |
| 305 | task rows across 44 workplans | superseded task sets, drafts registered before a workplan was retargeted |
Of the 305, only **9 currently show open**; the rest are already `finished` or
`cancel`, so the misleading surface is small. `kaizen-agentic` (8 workplans),
`the-custodian` (5), `ops-warden` (4) and `state-hub` (4) hold the largest shares.
**Nothing was mutated.** Eight cancel calls were issued against `STATE-WP-0080`
before the endpoint's real behaviour was understood; all eight tasks were already
`cancel`, so the calls were no-ops. No other workplan was touched.
Acceptance: no `railiance-wp-*` workplan row and no orphaned task row remains on
central, all removed through re-derivation rather than deletion.
## Converge and retire the cache database