Record the 2026-09-14 open-workplan chokepoint assessment and CUST-WP-0072.

Store the campaign analysis under history/ and add the fleet backfill
workplan for flavor plus depends_on, sequenced after STATE-WP-0092.

history/20260914-open-workplan-chokepoints.md

@@ -0,0 +1,189 @@
+---
+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.
+)

workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md

@@ -0,0 +1,109 @@
+---
+id: CUST-WP-0072
+type: workplan
+title: "Backfill workplan flavor and depends_on across the fleet"
+domain: infotech
+repo: the-custodian
+status: proposed
+owner: grok
+topic_slug: custodian
+flavor: planning
+depends_on:
+  - STATE-WP-0092
+created: "2026-09-14"
+updated: "2026-09-14"
+related:
+  - STATE-WP-0092
+  - RAIL-FAB-WP-0030
+  - COORDINATION-WP-0005
+  - CUST-WP-0060
+origin: residual-policy
+origin_ref: the-custodian/history/20260914-open-workplan-chokepoints.md
+---
+
+# Backfill workplan flavor and depends_on across the fleet
+
+Workplan 2 of 3 after `STATE-WP-0092`. Do not classify the fleet until
+the canon and hub default-exclusion exist; otherwise flavor is
+undocumented YAML.
+
+This plan updates **existing** workplans, conventions, and agent-facing
+templates. It does not implement hub schema. It does not promote
+residuals into implementation just to shrink a count.
+
+## Wait for schema and policy
+
+```task
+id: CUST-WP-0072-T01
+status: wait
+priority: high
+depends_on: [STATE-WP-0092]
+```
+
+Start backfill only after `STATE-WP-0092` has flavor and `depends_on`
+indexed and default views omitting residuals. Until then this task stays
+`wait`. Record the hub revision / workplan statuses that satisfy the
+gate.
+
+## Classify open workplans (and their open tasks)
+
+```task
+id: CUST-WP-0072-T02
+status: wait
+priority: high
+depends_on: [CUST-WP-0072-T01]
+```
+
+For every non-finished workplan in registered repos, set `flavor:` to
+one of `planning`, `implementation`, `refactoring`, `extension`,
+`residual`. Default: keep current functional/NFR work as
+`implementation` or `planning`; mark spawned leftovers and
+`origin: residual` children as `residual` unless founder demand or a
+named risk already applies.
+
+Do not auto-promote. If demand or risk is already documented, change
+flavor **away from residual** and record the reason in the file. Fill
+workplan-frontmatter `depends_on` where the prose already names a
+blocker workplan; do not invent edges. Per-repo edits stay in the owning
+repos (ADR-001). This workplan coordinates and tracks coverage.
+
+Done when a coverage table (repo, workplan id, flavor, depends_on
+filled or none) is committed under `the-custodian/docs/evidence/` and
+default hub open views drop the residual cohort.
+
+## Update conventions and templates
+
+```task
+id: CUST-WP-0072-T03
+status: wait
+priority: medium
+depends_on: [CUST-WP-0072-T01]
+```
+
+Update `AGENTS.md`, `.claude/rules/workplan-convention.md`, session
+protocol, and any repo-seed workplan template so new files include
+`flavor` and workplan-level `depends_on`. State the agent rule: do not
+implement residuals unless promoted. Point at `STATE-WP-0092` for hub
+behaviour and `COORDINATION-WP-0005` for the later cross-repo mode.
+Do not duplicate coordination-engine instructions here.
+
+Done when a newly scaffolded workplan in this repo validates and the
+convention text matches canon.
+
+## Intakes: provenance vs flavor
+
+```task
+id: CUST-WP-0072-T04
+status: wait
+priority: medium
+depends_on: [CUST-WP-0072-T02]
+```
+
+Keep `origin: residual` on intakes as provenance. Where an open intake
+has already been promoted to a workplan, set that workplan’s flavor
+consistently. Do not close intakes from this plan. Do not create a
+parallel residuals queue.
+
+Done when the residual intake list and residual workplan list can be
+joined by `origin_ref` without double-counting them as two implementation
+backlogs.