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

---
id: 20260914-open-workplan-chokepoints
type: assessment
title: "Why the open-workplan count will not fall by agent closure alone"
date: "2026-09-14"
assessor: grok
audience: founder
status: recorded
related_workplans:
  - STATE-WP-0092
  - CUST-WP-0072
  - RAIL-FAB-WP-0030
  - COORDINATION-WP-0005
  - INFD-WP-0002
  - RAIL-FAB-WP-0029
origin: "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.
)