From cdc86961ce6cfd6da3561ac45b40979105151270 Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 14 Sep 2026 13:48:17 +0200 Subject: [PATCH] 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 | 189 ++++++++++++++++++ ...72-fleet-flavor-and-depends-on-backfill.md | 109 ++++++++++ 2 files changed, 298 insertions(+) create mode 100644 history/20260914-open-workplan-chokepoints.md create mode 100644 workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md diff --git a/history/20260914-open-workplan-chokepoints.md b/history/20260914-open-workplan-chokepoints.md new file mode 100644 index 0000000..e4caab1 --- /dev/null +++ b/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. +) diff --git a/workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md b/workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md new file mode 100644 index 0000000..36460b8 --- /dev/null +++ b/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.