the-custodian/history/20260914-open-workplan-chokepoints.md

id	type	title	date	assessor	audience	status	related_workplans	origin
20260914-open-workplan-chokepoints	assessment	Why the open-workplan count will not fall by agent closure alone	2026-09-14	grok	founder	recorded	STATE-WP-0092 CUST-WP-0072 RAIL-FAB-WP-0030 COORDINATION-WP-0005 INFD-WP-0002 RAIL-FAB-WP-0029	Founder request after an agent-finishable close campaign: store the chokepoint analysis, then tackle the problem space rather than more ad-hoc closures.

Why the open-workplan count will not fall by agent closure alone

Date: 2026-09-14. Assessor: Grok acting as the-custodian. This is an assessment and a programme outline. It does not authorize credential minting, live admission, or finishing any existing workplan.

Question

A campaign of agent-finishable closures (code, docs, catalog, evidence) moved several workplans to finished and still left well over a hundred open plans. The question is not “which leftover can an agent close next?” It is why the ready/active/proposed/blocked set stays large, and which already-started subsystems should absorb that load instead of more parallel strands.

Snapshot

Two captures on the same day, both against primary railiance01 (http://127.0.0.1:8000).

Capture	Open workplans	Mix	Open tasks	needs_human
Campaign analysis (earlier 2026-09-14)	114	17 proposed, 3 ready, 61 active, 28 blocked, 5 backlog	299 (122 todo, 44 progress, 133 wait)	12
Refresh after this programme was requested	116	19 proposed, 3 ready, 61 active, 28 blocked, 5 backlog	320 (137 todo, 44 progress, 139 wait)	12

GET /state/summary open_workplans is 92 (active + blocked + ready only). Proposed and backlog are already dropped from that default list; residuals are not. Finishing work therefore still inflates the number an operator or agent treats as “open demand.”

Live Fabric coordination export from the campaign: 115 workplans, 303 open tasks, 75 waits_on citation edges, 796 graph elements. That view is a read of State Hub (RAIL-FAB-WP-0029), not a second authoring surface.

Intakes (refresh): 74 records, 42 origin: residual, 61 still open. Residuals are already the dominant intake origin.

Workplan-level depends_on in the summary: 2 edges (WARDEN-WP-0034 → WARDEN-WP-0030, RCLK-WP-0002 → RCLK-WP-0001). GET /workplans/ does not even return the field. fix-consistency C-20 indexes depends_on_workplans / depends_on_tasks, which almost nobody authors. Task-block depends_on is common; workplan-frontmatter depends_on is not engaged.

Themes that actually hold the count up

Campaign wait/human multi-count (one task may hit several themes):

Rank	Theme	Count	What it is
1	Cross-owner coordination	84	Wait on another repo, owner return, agent handoff, “not this repo”
2	Secrets / OpenBao / credential infrastructure	74	Keys, seals, OIDC, vault paths, issuer/registration, warden route
3	Live deploy / invited pilot / production journey	61	Real cluster, real tenant, real onboarding
4	Review / assent	51	Founder or owner sign-off, explicit approval
5	Operator-only acts	43	Login, BotFather, DNS, corpus, attended seal
6	Weekly measurement	25	Recurring allocation / demand review

Refresh keyword overlap on 145 wait-or-human tasks is the same shape (secrets 73, live deploy 61, review/assent 79, operator 50, cross-owner 32 under a stricter regex). Rank order of the first two themes is stable enough to plan against.

Founder confirmation (this session): ranks 1 and 2 confirm the impression that introducing but not having stabilized the security infrastructure is a major driver. Cross-owner waits are often waits on that incomplete estate (flex-auth, key-cape, OpenBao, approval-engine, informed-decision, ops-warden routing). Residuals are the other structural driver: finishing a plan is allowed to spawn live leftovers, and those leftovers currently count as equal open work.

Agents close code and docs. They do not close authentication, founder assent, or real customer journeys. A closure campaign that ignores that will keep finding “one more finishable file” while the headline count barely moves — and can rise, because residuals are minted on the way out.

What is already true in canon, and what is missing

Canon today (work-record-types_v0.1.md § Residuals): a residual is a role, not a kind. Leftovers must be live records (origin: residual). That rule did its job: leftovers are no longer parked only in SCOPE.md. It did not say they are less valuable than the main functional and non-functional requirements, and it did not hide them from the default open-workplan view.

depends_on exists in dashboard KPI math and in a handful of files. It is not the fleet’s coordination graph. Fabric recovered waits from task prose (waits_on citations) because the frontmatter field is empty.

prj- project repositories (ADR-005, project-repository-flavor_v0.1.md) are the declared home of complex cross-repo work. coordination-engine has no awareness of that flavor. Agent instructions still treat cross-repo work as inbox messages and wait notes.

informed-decision already exists as the Umlaufmappe / informed sign-off surface (Stage 1 still gated on a deployed approval-engine, INFD-WP-0001-T08). Credential and decision work is not yet arriving there as compact batches.

Programme (founder direction, 2026-09-14)

Do not open another ad-hoc closure campaign. Use the early-stage systems that already exist, and drive toward fewer concurrent open strands.

1. Flavor, depends_on, and residual default-exclusion

Workplans and tasks gain a flavor bucket, orthogonal to kind:

planning | implementation | refactoring | extension | residual

Residuals remain residuals because they are not deemed as valuable as the main functional and non-functional requirements. The default view of open workplans in State Hub, and the default “should we implement this?”, must not consider residuals unless demand or risk meets them. That meeting promotes them into another flavor; they are then no longer residual.

Engage depends_on in workplan frontmatter as the indexed edge, not a dead alias of depends_on_workplans.

Sequenced workplans:

1. STATE-WP-0092 — schema and policy in state-hub (and the canon it consumes).
2. CUST-WP-0072 — update existing workplans and conventions.
3. RAIL-FAB-WP-0030 — adapt the Fabric coordination perspective (depends on STATE-WP-0092 and RAIL-FAB-WP-0029).

2. Cross-owner coordination via coordination-engine

COORDINATION-WP-0005: the engine becomes aware of prj- workplans as drivers of cross-repository work, and the handling mode for cross-owner waits improves. Agent instructions for Codex, Claude, Grok and others are updated from that improved mode, so cross-repo work can be tackled or coordinated without minting another stranded wait.

3. Credentials and decisions as informed-decision batches

INFD-WP-0002: utilize the informed-decision framework by providing batches that can be signed off in a compact timeframe. One question per memo stays; a batch is a review-group of memos, not a forked schema. This is demand against Stage 1, not a revival of the residual “full L3 product” from INFD-WP-0001.

Success condition for this programme

Not “open workplan count = 0.” That count includes residuals, proposed explorations, and person-gated journeys.

Success is:

• default operator/agent views show relevant open work (non-residual);
• residuals are listed on demand, and promote when demand or risk appears;
• workplan depends_on is populated enough that Fabric and State Hub show a real graph instead of recovered citations;
• cross-owner waits are coordination-engine cases (especially prj- drivers), not silent wait forever;
• credential and decision chokepoints arrive as signable batches rather than twelve needs_human tasks with no packet.

What this assessment does not do

• It does not finish HOH-WP-0002-T04, NK-WP-0036, WARDEN-WP-0027-T02, RAPP-QONTO-WP-0002, CUST-WP-0071 T02–T05, RAPPS-WP-0014 bind, FLUID-WP-0008 BotFather, or any other person-gated task.
• It does not mint credentials or treat warden as a secret vendor.
• It does not create a new prj- repository for this programme. The five workplans below live in the owning repos and sequence with depends_on. A project repo remains available later if the cross-repo surface outgrows that. )