the-custodian/workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md
codex e053b71abd
Some checks are pending
CI Smoke / host-smoke (push) Waiting to run
CI Smoke / container-smoke (push) Waiting to run
CUST-WP-0075-T06: proposals sent, waiting on owner replies
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 04:00:58 +02:00

187 lines
7.8 KiB
Markdown

---
id: CUST-WP-0075
type: workplan
title: "Use the dependency graph to shrink the blocked set and route human gates to decisions"
domain: infotech
repo: the-custodian
status: active
owner: the-custodian
topic_slug: custodian
flavor: planning
created: "2026-10-03"
updated: "2026-10-03"
related:
- CUST-WP-0072
- CUST-WP-0074
- STATE-WP-0092
- COORDINATION-WP-0005
origin: analysis
origin_ref: the-custodian/docs/evidence/2026-10-03-dependency-graph-triage/README.md
state_hub_workstream_id: "6dac666d-b2f8-5d50-b060-272713b6e8a1"
---
# Use the dependency graph to shrink the blocked set
## Why
`CUST-WP-0072` and `CUST-WP-0074` built the facility: `flavor`, workplan
and task `depends_on`, `needs_human`, `blocked_on`, `wait_until`,
`decision_id`, indexed by C-20 and checked by C-39/C-40/C-41. Nobody has
yet *read* the resulting graph. On 2026-10-03 the open set is 108
workplans (100 blocked) with 232 wait tasks. The security concepts
(credential custody, attended OpenBao provisioning, identity, access
engine) are the dominant blockers, and every one of their 69 human gates
is free text: zero carry a `decision_id`, so Bernd has no single list to
resolve and C-40 rule 4 never fires.
This workplan uses the graph in three ways: clear what the graph says is
already satisfied, correct what the graph says is mis-statused, and
collapse the human gates into a handful of hub decisions that one
attended session can resolve. Evidence and scripts:
`docs/evidence/2026-10-03-dependency-graph-triage/`.
Rules: owner repos are edited directly (Bernd's 2026-09-30 direction on
`CUST-WP-0074-T06`), one commit per repo, synced by `fix-consistency`;
no hub writes except recording and resolving decisions; residual-flavor
workplans are left alone except to finish one whose tasks are all done.
## Capture the graph and publish the triage
```task
id: CUST-WP-0075-T01
status: done
priority: high
state_hub_task_id: "9d9e994d-0b48-5945-ab13-f301f3343aae"
```
File-view and hub-view scans committed under
`docs/evidence/2026-10-03-dependency-graph-triage/` with the headline
numbers in its README. Done 2026-10-03.
## Clear satisfied waits and correct mis-statused workplans
```task
id: CUST-WP-0075-T02
status: done
priority: high
state_hub_task_id: "0e524c1f-3fd7-5736-9fb2-883f4e6df70a"
```
Graph says satisfied (every `depends_on` target terminal):
`ACTIVITY-WP-0032-T05`, `COORDINATION-WP-0004-T02`, `TD-WP-0003-T07`,
`USER-WP-0027-T04`, `USER-WP-0028-T03`, `RCLK-WP-0005-T04` (keeps its
`blocked_on`), `RAPPS-WP-0014-T03` and `MARKITECT-WP-0002-T07` (keep
their human gate; drop the satisfied `depends_on`).
Mis-statused: `UPC-WP-0002/0003/0004` blocked without a wait task;
`MARKITECT-WP-0002` and `RBT-WP-0006` active while every open task
waits; `ACTIVITY-WP-0042` proposed with three unqualified waits;
`RAIL-FAB-WP-0031` blocked with all tasks done; `FLUID-WP-0007` carries
the non-canonical status `done`; `NK-WP-0011` depends on
`NK-WP-0003/0004/0006`, which no file carries.
Done when each owner repo is committed and synced and a re-run of the
file scan lists none of the above.
## Route the human gates to decisions
```task
id: CUST-WP-0075-T03
status: done
priority: high
state_hub_task_id: "a363639a-d688-5c72-9224-63d06dec670e"
```
Cluster the 69 `needs_human` waits by the person's actual act (one
attended OpenBao provisioning window, one ArgoCD go-ahead, one Telegram
operator session, Vergabe two-user acceptance, trust-root design, and
so on). For each cluster record one hub decision whose description lists
the task ids, then set `decision_id` on those tasks in the owner files.
Done when every `needs_human` wait in a non-residual open workplan
carries a `decision_id` and Bernd has one ranked decision list.
## Record the security-infrastructure lessons
```task
id: CUST-WP-0075-T04
status: done
priority: medium
state_hub_task_id: "b861e0af-43ad-5052-b224-9bd95762ddfd"
```
Write `history/20261003-security-gate-packets.md`: what the graph shows
about how credential, identity and access work gets blocked, and the
improvements that make it easier to maintain and extend (decision-linked
gates, batched attended windows, delegated-applier scope, catalog lanes
as the unit of provisioning). Proposals only; no canon change here.
## Monitor: keep repo and hub in step
```task
id: CUST-WP-0075-T05
status: progress
priority: medium
state_hub_task_id: "c78b104d-cdf0-5aca-81a4-b5569cc90479"
```
After every slice: commit, `statehub fix-consistency` for each touched
repo, one progress event on this workplan, and the headline numbers
appended below so progress is visible from the hub.
## Hand the infrastructure proposals to their owners
```task
id: CUST-WP-0075-T06
status: wait
priority: high
blocked_on: message-from:state-hub
blocking_reason: "Proposals sent 2026-10-03; waiting for state-hub (b4825539), railiance-platform (f84637fa) and ops-warden (79549660) to reply with their workplan ids or a decline."
state_hub_task_id: "91fd64c1-2dfd-57d1-8930-51477c530202"
```
`history/20261003-security-gate-packets.md` proposes P1 (unrouted human
gate is a WARN), P2 (standing attended provisioning window with a
generated checklist), P3 (decide the dual-control value path), P4 (catalog
lane as the unit of extension), P5 (daily owner-return sweep) and P6a (CLI
qualifier sync gap, already reported to state-hub as message `70d08f35`).
2026-10-03: sent state-hub `b4825539` (P1, P5, P6), railiance-platform
`f84637fa` (P2, P3), ops-warden `79549660` (P4). Send each owner one message with
the proposal and the evidence; record their workplan ids here. Do not
write their workplans for them.
## Progress log
- 2026-10-03 start: 108 open / 100 blocked / 232 wait / 69 human gates /
0 with `decision_id`.
- 2026-10-03 T02: satisfied or mis-statused records fixed in 11 repos.
COORDINATION-WP-0004, RAIL-FAB-WP-0031 and FLUID-WP-0007 finished.
ACTIVITY-WP-0032-T05, COORDINATION-WP-0004-T02 and TD-WP-0003-T07 had
prose-only blockers; the real edge was encoded (or, for the canon
registration, found already delivered and closed).
- 2026-10-03 T03: eleven hub decisions recorded (D1 attended OpenBao window
`62aa95e4` … D11 operator setups `b6a44b55`). 70 human gates carry a
`decision_id` in their owner files across 29 repos. `WARDEN-WP-0037-T03` has
no stated gate and stays with its owner.
- 2026-10-03 T04: `history/20261003-security-gate-packets.md`.
- 2026-10-03 sweep: 17 owner-return waits had an unread reply from the very
agent they wait on. Repo agents dispatched for ops-mason (5) and
gate-house (5); user-engine (3), activity-core, railiance-platform and
rapp-policy-nexus follow.
- 2026-10-03 sweep results: COORDINATION-WP-0004 finished (owner return sat
unread a week). RCLK-WP-0002-T01 done: railiance-master ruled 2026-09-21,
gate-house reviewed today, repo-manager registered `RCLK-WP` (`03869ff`).
GH-WP-0004-T07/T08 and MASON-WP-0007-T03 done; MASON-WP-0005-T02 and
RPF-WP-0043-T02 to todo (the latter broke a mutual wait with
rapp-policy-nexus). Other replies were questions back (answered) or
hand-offs to a founder decision (encoded).
- 2026-10-03 D12 recorded for the company-vessel founder actions; WARDEN-WP-0037-T03
routed to D3. All 83 human-gated waits in open non-residual workplans carry
a `decision_id`. Ranked list: `docs/decision-packets-2026-10-03.md`.
- 2026-10-03 finding: the CLI sync left the hub without the `decision_id` on
57 of 58 routed tasks; a direct checker run with `--fix` is pushing them
(see the assessment, P6a).
- 2026-10-03 close of day: every routed gate verified in the hub (84 of 84
carry the file's `decision_id` after a direct `consistency_check.py --fix`
over 32 repos). File view: 107 open workplans, 232 wait tasks, 83 human
gates in non-residual plans, all routed to 12 decisions; 0 satisfied
waits, 0 unqualified waits, 0 blocked plans without a wait task. Owner-return
waits 62 → 52. T02/T03 done; T05 continues as the monitor; T06 next.