From 6d14339f240a8602ae69bdf5c66fb293fa20d2b9 Mon Sep 17 00:00:00 2001 From: codex Date: Sun, 1 Nov 2026 23:37:27 +0100 Subject: [PATCH] docs: preserve reviewed NetKingdom session artifacts --- ...N-WP-0043-platform-supplier-credentials.md | 113 +++++ ...EN-WP-0044-security-case-follow-through.md | 356 +++++++++++++++ ...5-WARDEN-WP-0001-initial-implementation.md | 335 ++++++++++++++ ...EN-WP-0002-correctness-and-completeness.md | 178 ++++++++ ...ARDEN-WP-0003-test-coverage-and-quality.md | 211 +++++++++ ...ARDEN-WP-0004-repo-hygiene-and-hub-sync.md | 95 ++++ ...17-WARDEN-WP-0005-openbao-doc-alignment.md | 65 +++ ...ingdom-alignment-and-access-stewardship.md | 140 ++++++ ...-0007-policy-gate-and-production-verify.md | 88 ++++ ...ction-ssh-path-and-stewardship-closeout.md | 153 +++++++ ...P-0009-flex-auth-policy-gate-production.md | 97 ++++ ...4-WARDEN-WP-0010-access-routing-charter.md | 178 ++++++++ ...260624-WARDEN-WP-0011-routing-guide-cli.md | 163 +++++++ ...on-integration-and-stewardship-closeout.md | 204 +++++++++ ...RDEN-WP-0012-routing-scenario-playbooks.md | 147 ++++++ ...7-WARDEN-WP-0014-operator-access-assist.md | 215 +++++++++ ...WARDEN-WP-0015-secret-lifecycle-tiering.md | 247 ++++++++++ .../archived/260707-ADHOC-2026-07-07.md | 52 +++ .../.custodian-brief.md.backup | 60 +++ .../WORK-RECORDS.md.backup | 188 ++++++++ .../.custodian-brief.md.worktree | 60 +++ .../WORK-RECORDS.md.worktree | 188 ++++++++ .../publication-backup/originals.json | 10 + .../synthetic-parent-home/.vault-token | 1 + .../backup/.custodian-brief.md | 60 +++ .../backup/WORK-RECORDS.md | 188 ++++++++ .../backup/workplans/ADHOC-2026-06-27.md | 41 ++ .../backup/workplans/ADHOC-2026-06-29.md | 40 ++ .../backup/workplans/ADHOC-2026-08-11.md | 145 ++++++ .../backup/workplans/ADHOC-2026-08-17.md | 129 ++++++ .../backup/workplans/ADHOC-2026-09-08.md | 179 ++++++++ .../backup/workplans/ADHOC-2026-10-03.md | 31 ++ ...EN-WP-0016-ops-bridge-tunnel-cert-pilot.md | 124 +++++ ...-0017-access-front-door-discoverability.md | 120 +++++ ...-0018-whynot-design-npm-lane-activation.md | 103 +++++ .../WARDEN-WP-0019-route-to-secrets-engine.md | 89 ++++ .../WARDEN-WP-0020-ops-warden-worker.md | 176 +++++++ ...EN-WP-0021-enable-scheduled-worker-tick.md | 142 ++++++ ...WARDEN-WP-0022-audit-trail-and-activity.md | 119 +++++ ...WP-0023-intent-scope-alignment-closeout.md | 222 +++++++++ ...-experiential-memory-and-agent-sessions.md | 269 +++++++++++ ...EN-WP-0025-forgejo-admin-api-token-lane.md | 118 +++++ ...N-WP-0026-credential-disclosure-hygiene.md | 261 +++++++++++ ...-WP-0027-credential-governance-lockdown.md | 303 +++++++++++++ .../WARDEN-WP-0028-tenant-secret-custody.md | 421 +++++++++++++++++ ...9-policy-front-door-and-founder-surface.md | 159 +++++++ .../WARDEN-WP-0030-delegation-register.md | 270 +++++++++++ .../WARDEN-WP-0031-policy-caller-identity.md | 170 +++++++ .../WARDEN-WP-0032-security-zones.md | 429 ++++++++++++++++++ .../WARDEN-WP-0033-native-lane-handoff.md | 344 ++++++++++++++ 50 files changed, 8196 insertions(+) create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0043-platform-supplier-credentials.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0044-security-case-follow-through.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0001-initial-implementation.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0002-correctness-and-completeness.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0003-test-coverage-and-quality.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0004-repo-hygiene-and-hub-sync.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0005-openbao-doc-alignment.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0006-netkingdom-alignment-and-access-stewardship.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0007-policy-gate-and-production-verify.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260618-WARDEN-WP-0008-production-ssh-path-and-stewardship-closeout.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260623-WARDEN-WP-0009-flex-auth-policy-gate-production.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0010-access-routing-charter.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0011-routing-guide-cli.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0013-production-integration-and-stewardship-closeout.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0012-routing-scenario-playbooks.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0014-operator-access-assist.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0015-secret-lifecycle-tiering.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260707-ADHOC-2026-07-07.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/.custodian-brief.md.backup create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/WORK-RECORDS.md.backup create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/.custodian-brief.md.worktree create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/WORK-RECORDS.md.worktree create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/originals.json create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/synthetic-parent-home/.vault-token create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/.custodian-brief.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/WORK-RECORDS.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-27.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-29.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-11.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-17.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-09-08.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-10-03.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0017-access-front-door-discoverability.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0019-route-to-secrets-engine.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0020-ops-warden-worker.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0022-audit-trail-and-activity.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0027-credential-governance-lockdown.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0028-tenant-secret-custody.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0030-delegation-register.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0031-policy-caller-identity.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0032-security-zones.md create mode 100644 docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0033-native-lane-handoff.md diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0043-platform-supplier-credentials.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0043-platform-supplier-credentials.md new file mode 100644 index 00000000..d3593282 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0043-platform-supplier-credentials.md @@ -0,0 +1,113 @@ +--- +id: WARDEN-WP-0043 +type: workplan +title: "Route supplier credentials under platform/suppliers" +domain: infotech +repo: ops-warden +status: finished +flavor: implementation +owner: grok +topic_slug: platform-suppliers +created: "2026-10-08" +updated: "2026-10-09" +depends_on: [] +related: + - repo:railiance-platform + - repo:llm-connect +state_hub_workstream_id: "16aac061-977a-536b-a074-aba059f2475f" +--- + +# WARDEN-WP-0043 — Supplier credentials under platform/suppliers + +Founder decision 2026-10-08: account credentials we hold with a supplier +live at `platform/suppliers//` on the existing `platform` +KV mount. ops-warden routes that shape. It does not store the values and it +does not apply OpenBao. The KV write and the credential-change allowlist +belong to railiance-platform. Tenant commercial secrets stay on `tenants/`. + +Workload and rein paths that already have a reader stay where they are +until that reader is retargeted: + +| Account | Path today | +| --- | --- | +| OpenRouter, llm-connect | `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets` | +| OpenRouter, rein-openweights | `reins/rein-openweights/openrouter` | +| Scaleway bootstrap | `platform/workloads/railiance/scaleway/bootstrap` | +| Scaleway backup space | `platform/workloads/railiance/backup/object-storage` | +| IONOS transactional mailbox | `platform/workloads/email-connect/transactional` | +| IONOS library mailbox | `platform/workloads/inbound-library/imap` | + +The future homes are `platform/suppliers/openrouter/llm-connect`, +`platform/suppliers/openrouter/rein-openweights`, +`platform/suppliers/scaleway/bootstrap`, `platform/suppliers/scaleway/backup`, +`platform/suppliers/ionos/email-connect-smtp`, and +`platform/suppliers/ionos/library-imap`. Further suppliers use the same +two-level shape. llm-connect already tries the llm-connect supplier path +and then the live workload path before `OPENROUTER_API_KEY`. + +## Catalog pointer + +```task +id: WARDEN-WP-0043-T01 +status: done +priority: high +state_hub_task_id: "7a86d91a-fcbd-5dc8-b3cf-4c28ad963474" +``` + +Add a pointer catalog entry and a short playbook for +`platform/suppliers//`. `warden_executes: false`. The +owner of the KV write is railiance-platform. No secret values, no fetch +of a live field, and no new `warden` verb. + +Done 2026-10-08: catalog `platform-supplier-credentials` plus +`wiki/playbooks/platform-supplier-credentials.md`. + +## Allow the path in credential changes + +```task +id: WARDEN-WP-0043-T02 +status: done +priority: high +state_hub_task_id: "c384b228-e710-580d-a3de-a3046a86e666" +``` + +`railiance-platform/scripts/credential-change.py` accepts `platform/workloads/` +and `tenants/` for a delegated change. `platform/suppliers/` needs that +allowlist widened before a CCR can create these paths. ops-warden does not +apply the change. + +Done 2026-10-09: railiance-platform `b77cb41` maps mount `platform` to +`platform/workloads/` and `platform/suppliers/`. Under `suppliers/` it requires +exactly two non-empty segments, and tests cover `platform/suppliers/ionos/main`. +The IONOS CCR can now be drafted against this shape. + +## Provision supplier accounts + +```task +id: WARDEN-WP-0043-T03 +status: done +priority: medium +needs_human: true +state_hub_task_id: "87996bc7-2f7a-578d-9f7c-8bd876605a47" +``` + +New supplier material is written from a mode-0600 file on a trusted +terminal, into `platform/suppliers//`. IONOS is the +first account that still needs that home. Existing workload and rein +readers keep their current paths until each one is retargeted. Values do +not go into git, State Hub, workplans, logs, or chat. + +2026-10-09: the IONOS stub exists. The founder ran the write through the +contained `openbao-platform-admin-login` envelope: +`bao kv put -cas=0 platform/suppliers/ionos/main` as version 1, with keys +`CUSTOMER_NUMBER`, `LOGIN`, `PASSWORD`, `API_KEY_PREFIX` and `API_KEY_SECRET`, +each set to the placeholder `FILL_ME`. A metadata-only check through the same +envelope exited 0. The founder fills the real values as version 2 in the +OpenBao UI. This task closes once that is done. No reader policy exists for the +path; a reader is requested through a railiance-platform CCR when a workload +needs it. + +2026-10-09: done. The founder filled in the real values as version 2 through +the OpenBao UI. ops-warden did not read or verify any value. Further supplier +accounts follow the same playbook; existing workload and rein readers move only +when each reader is retargeted. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0044-security-case-follow-through.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0044-security-case-follow-through.md new file mode 100644 index 00000000..aa9f798b --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/WARDEN-WP-0044-security-case-follow-through.md @@ -0,0 +1,356 @@ +--- +id: WARDEN-WP-0044 +type: workplan +title: "Follow through on KnownSecurityCases along their type's route" +domain: infotech +repo: ops-warden +status: active +flavor: implementation +owner: claude-code +topic_slug: netkingdom +created: "2026-10-08" +updated: "2026-10-11" +depends_on: [] +related_repos: + - net-kingdom + - ops-mason + - key-cape + - railiance-platform +state_hub_workstream_id: "f7e81013-6868-5d99-8528-ba75a442eca9" +--- + +# WARDEN-WP-0044 — Follow through on KnownSecurityCases along their type's route + +## Why + +NetKingdom is introducing SecurityCaseTypes (net-kingdom `NK-WP-0048`, canon +`security-case-types_v0.1`, proposed). Once a case of an implemented type is +accepted and ops-mason has materialized its structure (`MASON-WP-0010`), +ops-warden carries out the remaining steps. These are the owners' declared entry +points, run on the authentication path the type defines, followed by the type's +verification. + +Today ops-warden routes needs and, for `exec_capable` lanes, proxies fetches as +the caller. It does not yet know about cases, and each new integration ends with +a founder running a hand-written script (for example the proposed KEY-WP-0038-T02 +rollout). This plan gives ops-warden the follow-through role, without widening +what it may do: each step still runs under its owner's entry point and the +caller's identity. + +## Tasks + +```task +id: WARDEN-WP-0044-T01 +status: done +depends_on: [NK-WP-0048-T03] +priority: high +state_hub_task_id: "ef0920fc-418e-52cb-acff-9a5c0c728bf5" +``` + +### T01 — Define the type's follow-through section + +Propose the `follow_through` part of the SecurityCaseType schema together with +net-kingdom. For each step it names the owner entry point, `warden_executes`, +the auth method and lane, whether an attended human login is unavoidable (with +the type's justification), and the verification command. Write it for the first +type, `oidc-browser-relying-party`, covering key-cape client registration, +custody minting and LLDAP group membership. + +2026-10-08: NK-WP-0048-T03/T04 landed with a drafted section. Review is in +`history/2026-10-08-oidc-rp-follow-through-review.md`. It requires three +changes before T02: a per-step `lane`, a narrow `warden_executes`, and +`value_handling`. It also lists four refinements. This task is done when +net-kingdom acknowledges the review (NK-WP-0048-T05). + +2026-10-09: R4 was withdrawn in favour of ops-mason's per-case +`{consuming_service}-keycape-client`, with the entry body templated in the type +(R4′, see the addendum in the review). + +2026-10-09: the revised 1.0 type and canon now carry R1–R3, R4′, R5–R7. +`warden case check-type ` (`src/warden/case_type.py`, tests in +`tests/test_case_type.py`) checks a type's follow-through mechanically: the +live type is schema-conformant, with one attended session +(`key-cape-oidc-login`). It is not yet plannable, because two lanes are not +in the catalog: `identity-provisioner-groups` (net-kingdom) and +`keycape-client-secret-generate` (railiance-platform). These gate T02, not +T01. T01 still closes on net-kingdom's acknowledgement (NK-WP-0048-T05). + +2026-10-09: ops-warden cannot add `identity-provisioner-groups` as the type +declares it. The provisioner accepts only user-engine's runtime token and +admits only user-engine pods, so no caller-identity path exists. R8 (review +addendum) asks net-kingdom either to move `ensure-groups` into the existing +attended session (recommended) or to give the provisioner an operator +credential. `keycape-client-secret-generate` needs a generate-in-custody entry +point from railiance-platform, and the broker does not have one yet. Both were +sent to their owners. + +2026-10-09: done. net-kingdom took R8 option 1, so `ensure-groups` runs attended +in the `register-client` session and `identity-provisioner-groups` is dropped +(net-kingdom `0e86f95`). The founder acknowledged the type with memo r4 (hub +decision `e418263e`, NK-WP-0048-T05 done). + +```task +id: WARDEN-WP-0044-T02 +status: done +depends_on: [WARDEN-WP-0044-T01] +priority: high +state_hub_task_id: "5f68c991-f490-58f8-a121-92f74073d272" +``` + +### T02 — Plan a case run + +`warden case plan ` checks that the case is accepted and materialized, +resolves each step to its catalog entry and entry point, and prints the run: +which steps warden executes, which run as the attended caller, what the +verification is. No secret values; no execution. + +Tests: refuse an unaccepted or unmaterialized case; refuse a step whose catalog +entry is missing or not reviewed; show attended steps explicitly. + +2026-10-09: done. `warden case plan [--type] [--json]` +(`src/warden/case_plan.py`, 14 tests in `tests/test_case_plan.py`). It refuses: +- a case that is not `materialized`, or has no acceptance record +- a type that is mismatched or not acknowledged +- any `case check-type` finding, including a missing or unreviewed lane +- undeclared, type-fixed or secret-sensitivity parameters +- a placeholder the case does not set, or an unsupported `when` + +It fills type defaults (`issuer`), evaluates ` == ` conditions, +renders owner, entry point, auth and ready_check, groups attended steps per +lane, and lists the applicable verification. + +The live Forgejo case is correctly refused: it is `accepted`, not +materialized. A materialized copy, with a stand-in lane for +`keycape-client-secret-generate`, renders six steps: two attended steps plus +`register-client` in one `key-cape-oidc-login` session, one warden step +(`mint-secret`), and two owner steps. Seven checks follow. + +Observation for net-kingdom (not blocking): `bind-env` runs before +`register-client`, in type order. Its entry carries a literal +`KEYCAPE__CLIENT_SECRET`, which is not a `{param}` placeholder, so it +reaches the plan unrendered. + +2026-10-09 follow-up: +- **Format specs.** `_render` supports net-kingdom's `{param:env}` spec (upper + case, `-` as `_`, the same as `keycape-client.py env_name`) and refuses any + other spec or `!conversion`. +- **Case reference.** The plan prints `case-ref: @sha256:` over the + case file's exact bytes. This is the reference proposed to railiance-platform + for `credential.py generate --case-ref` (RPF-WP-0054-T01); the broker + re-derives it from the file. +- 18 tests now. + +```task +id: WARDEN-WP-0044-T03 +status: progress +depends_on: [WARDEN-WP-0044-T02, MASON-WP-0010-T03] +blocking_reason: "Local durable execution kernel and injected failure harness implemented. Native acceptance still requires authenticated owner machine descriptors/adapters, actual Forgejo materialization receipt, contained session integration, ordered verification and first native run." +priority: high +state_hub_task_id: "bcbf6c91-2c04-5c16-ae8c-5d6c06fd6b89" +``` + +### T03 — Run and verify a case + +`warden case run ` executes the plan. Owner entry points run through +the existing proxy as the caller; steps that need an attended login use the +existing contained login envelope (silent command, session revoked afterwards), +grouped into as few attended sessions as possible. Then it runs the type's +verification and writes a receipt without values. `warden case rollback` +reverses exactly this case's steps. + +Acceptance: the Forgejo reference case (NK-WP-0048-T06) reaches `live` through +this path, with no case-specific script. + +2026-10-17: original-intent lookup/context interface for NK-WP-0048-T15, source +and synthetic tests only. `src/warden/case_run.py`: `Executor.run` writes an +`OriginalIntent` (schema `warden.case.original-intent.v1`: the dispatched run +Invocation — attempt, step, owner, target, actor, principal, lane, all six pins, +tenant, realm — plus admitted adapter source) in the same SQLite transaction as +the pre-dispatch journal row. `Journal.original_intent(binding, current, source)` +returns it after restart and refuses on a missing record or any +pins/source/step/owner/target/actor/principal/lane/tenant/realm mismatch, before any +journal write, so the step stays uncertain. An adapter's +`reconcile_original(ReconcileContext(original, attempt))` receives the original +intent separately from the new reconcile attempt. This is Warden's record of what +it dispatched, not owner created-only provenance. Current Executor.admit leaves +tenant/realm empty; the reserved coordinates establish no admitted provenance. +Owner descriptors/adapters, contained session integration, Forgejo +materialization and the native run remain open. + +2026-10-17 source consistency follow-through: retained the additive intents table +and reconcile_original callback and fixed four reproduced local defects: original +actor mismatch, payload/SQL attempt-ID mismatch, orphan intent without its +matching original running receipt, and arbitrary nonmetadata values accepted by +the original-intent serializer. Exact bounded field validation, duplicate-free +bounded decode and save-time intent/invocation/running-state equality now preserve +the original receipt linkage before owner lookup. No new context store, native +verifier, trust root, adapter activation or authority migration was introduced. + +The actual canonical focused kernel and new consistency suite passes 54 checks; +owner-installed Ruff check/format passes. The existing generated-data/synthetic +owner fixture and a distinct interpreter prove source correspondence/refusal, +not independent native custody or creation. Earlier comparison probes and failed +preparation are retained. Current caller and fresh session/grant revocation checks +remain required; original owner payload/revocation, exact native readback and +created-only provenance still need independent authenticated owner admission. +No JSON/SQL context, unknown tenant/realm, changed run-sheet or legacy missing +intent supplies recovery, replay or undo authority. T03 remains progress and all +native acceptance gates/statuses/dependencies/UUIDs remain unchanged. Evidence: +Custodian original-context-compare-r2 and original-context-owner-followthrough-r3 +under docs/changes/netkingdom-target-2026-10-17/; publication/projection is separate. + +Agreed with railiance-platform (RPF-WP-0054-T01, 2026-10-09): +- `mint-secret` runs `credential.py generate --grant keycape/client-secret-generate + --client-id --case-ref --case-file ` as the caller's + child process. The broker re-derives the case-ref and checks status and + client_id. +- warden refuses that step when `WARDEN_AGENT_ID` is set. + +2026-10-10: railiance-platform implemented the command (RPF-WP-0054-T03). It is +catalogued as draft `keycape-client-secret-generate`, with `exec_owner` +railiance-platform and `exec_capable: false`. `warden case check-type` now +reports the lane as LANE-UNREVIEWED rather than LANE-MISSING. Before it can be +activated: +- the founder binds the issuer policy to the operator OIDC role +- key-cape confirms the secret format +- the RPF-WP-0054-T05 probe passes + +2026-10-10 (later): +- **Broker lane.** The issuer role is bound (CCR-2026-0043) and the T05 probe + passed (railiance-platform `21b8af3`). Only key-cape's format confirmation is + left. The playbook now includes the issuer-role login, a 15m token with + unlimited uses that `warden case run` must group with the attended session. +- **Env spec.** net-kingdom adopted `{client_id:env}` as a 1.0 patch + (`9a9b8e3`). The plan renders `KEYCAPE_FORGEJO_CLIENT_SECRET`. +- **Forgejo case.** Rendered and built by ops-mason. It is not yet + `materialized`: MASON-WP-0010-T03 waits on the railiance-platform CCRs and + their founder apply. + +2026-10-10: `keycape-client-secret-generate` activated on railiance-platform's +go-ahead (message 20973a9c) after key-cape confirmed the format (4e0213b3). +`warden case check-type` on the live type now reports `plannable=True`. The +only thing T03 still waits on is the Forgejo case reaching `materialized` +(MASON-WP-0010-T03). + +2026-10-10: net-kingdom moved the type to 1.1 (`e2174ce`) and re-pinned the +Forgejo case. 1.1 adds the verification `consumer-enforces-groups` and requires +the hand-over to enforce `access_groups`. `check-type` on 1.1 reports +`plannable=True`, and a materialized copy renders six steps and the new check. +The case-ref digest covers the whole case file, including `status`, so it +changes when the case becomes `materialized`. `warden case run` therefore takes +it from the file at run time, and the broker re-derives it from the same file. + +```task +id: WARDEN-WP-0044-T04 +status: wait +depends_on: [WARDEN-WP-0044-T03] +blocking_reason: "Catalog integration follows a proven run." +priority: medium +state_hub_task_id: "4a0fa4a7-5ca9-518a-ab92-a79a5e2cf93e" +``` + +### T04 — Catalog entries from types + +Let a type contribute reviewed catalog entries once, so that every case of that +type routes without a new catalog edit. Cases add parameter values, not routes. +`warden route find` should be able to answer "which SecurityCaseType covers this +need?" before anyone builds by hand. + + +2026-10-10 consolidation source prototype (not an accepted owner adapter API): +`src/warden/case_receipt_state.py` provides a pure immutable receipt reducer, +with exact case/type/adapter/catalog/acceptance/run-sheet pins, running intent +before dispatch, uncertain recovery after a lost result, no success replay, +explicit retry-safe failed-before-change retry and created-only reverse undo. +It executes nothing and accepts no command output. The caller must durably +persist running before any future side effect; storage/authenticated owner +receipts/live adapters are not implemented. Focused offline tests cover changed +pins, lost receipts, retry/refusal, uncertain rollback and shared-object +preservation. Source proposal: `docs/security-case-execution-proposal.md`. + +T03 remains open: typed owner execution/receipt contracts require review, the +Forgejo structural materialization needs owner receipts, and CLI dispatch, +contained sessions, native verification and provenance remain unimplemented. +There is a circularity to resolve with net-kingdom/ops-mason: materialization +cannot require mint-secret if mint-secret is itself a follow-through step whose +planning requires materialized. No case status is changed by this prototype. + + +2026-10-11: the exact execution-design memo version1 has confirmed native human +acceptance (approval e46b149b-ec3c-4b3b-98a7-dcb4934448ca). The approved proposal +bytes remain unchanged. `src/warden/case_run.py` now implements a closed v1 local +execution seam, independent admission/evidence callbacks, private transactional +SQLite receipt storage, process locking, running-before-dispatch, crash recovery +to uncertainty, explicit safe retry, separately required broker-grant and parent-session revocation +proofs, native owner reconciliation and created-only +reverse rollback. Thirty-seven kernel tests and fourteen reducer tests pass; +ruff checks pass. See `docs/security-case-execution-kernel-v1.md` for exact scope +and receipt provenance. No installed native adapter or live CLI execution is +claimed. Current prose types stay plan-only; acknowledged descriptor/type machine +seams and authenticated owner/caller receipts are still required. T03 progresses +for implementation but cannot finish before ordered native Forgejo acceptance. + +2026-10-16 source preparation (isolated checkout; no native acceptance): +T03's browser parameter mismatch now has a producer-validator-backed projection +in `case_inputs.py`, explicitly configured on the real Executor. Exact 1.1/1.2 +parameter definitions and all four reviewed producer modules are pinned; full case +validation admits reviewed security-sensitive metadata while unknown/fixed/secret +inputs and type/producer drift refuse. Only the reviewed descriptor target +reaches the owner callback; no parameter journal payload is added. Actual +Executor/producer tests cover positive versions and refusal/containment paths. +Acknowledged machine descriptors, authenticated owner evidence, real Forgejo +materialization and contained native sessions remain mandatory and unimplemented; +T03 stays progress, T04 stays wait. No type or case status changed. + +2026-10-16 producer source refresh: independently reviewed NetKingdom +`015694ee414c802dc2ef1fa0120dfed610086e69` optional descriptor-map repair. +Only the validator/evidence source pins change; exact parameter and transitive +source identity remain enforced. Actual canonical producer, Executor and reducer +suite passes 87 checks, including 14 new malformed-map integration cases; all +four missing/changed modules still refuse. Review: +`docs/reviews/2026-10-16-browser-producer-pin-refresh.md`. No adapter attestation, +native acceptance, credential use or privileged dispatch. T03 remains progress. + + +## T03 source correction and safe-test follow-through — 2026-10-17 + +The reviewed KERNEL-2/3 source now authenticates and parses the actual catalog +snapshot, checks lane owner/risk/delegation, and resolves each type step's Warden, +attended or owner dispatch mode. Four proposed attended-change lanes remain +DRAFT; no lane is promoted and PARAMETER_PINS still contains only 1.1/1.2. + +Independent review KR1-F1/F2 found cached attended run/rollback/reconcile could +lose the human/runtime boundary, and actual admission lacked the planner's +establishing-login checks. The exact successor retains the mode and authenticated +catalog bytes and repeats caller/session, agent marker and attended-lane checks +before any journal write or callback on all three operations. Planner and executor +share active/reviewed login/session-lane validation. Two unresolved Apps session +lanes correctly remain refused. Integration tests now explicitly disclose all +fixture authority substitutions; they establish no owner or native authority. + +The new 19-test regression matrix reproduces 13 failures on its predecessor and +passes on the candidate. A fresh independent reviewer adds changed-authority and +catalog-snapshot probes: 90 focused checks and six guarded integration checks +pass; the combined predecessor comparison has 22 expected failures. Author's +isolated full suite passes 765 with four integration-marked tests deselected. +Evidence: Custodian warden-1.3-kernel-fixes-r1 and warden-1.3-kernel-review-r2 +under docs/changes/netkingdom-target-2026-10-17. Original unsuccessful review, +invalid setup attempts and unknown ambient-lookup outcome are retained. + +A separate reviewed test-only fix stubs ambient OpenBao identity in access CLI +unit tests and adds a synthetic sentinel regression which fails before any +subprocess can launch on the predecessor; 26 access/helper checks pass. The real +production helper is unchanged. The first old review's unisolated launches may +have invoked ambient `bao token lookup`; remote reach/success remain unknown, +with no secret displayed. This patch does not erase that adverse outcome. + +Explicit remaining safe-test work is retained in this live T03 scope, owned by +ops-warden: replace or wrap the ordinary unit-test entry path with allowlisted +environment/empty synthetic HOME and guarded subprocess/network execution, +including nested validator children. Completion requires representative access +and case tests to refuse token-file/environment and live provider access under +synthetic negative controls while permitted local fixtures remain usable. Until +then use the preserved isolated review runner, not the ambient `make test` path. +No credential lookup, live investigation or rotation is authorized by this note. +T03 remains progress; contained sessions, authenticated owner provenance, +materialization, exact type acknowledgment/pin and first native case remain open. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0001-initial-implementation.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0001-initial-implementation.md new file mode 100644 index 00000000..5425cbd8 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0001-initial-implementation.md @@ -0,0 +1,335 @@ +--- +id: WARDEN-WP-0001 +type: workplan +title: "OpsWarden Initial Implementation" +domain: custodian +repo: ops-warden +status: archived +owner: Bernd +topic_slug: custodian +created: "2026-03-28" +updated: "2026-03-28" +state_hub_workstream_id: "c3118cc6-adfb-428c-a9c6-edd0ee152ae6" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0001 — OpsWarden Initial Implementation + +> **Note:** This workplan is authored in `ops-bridge` because `ops-warden` does not yet exist. +> Move it to `workplans/WARDEN-WP-0001-initial-implementation.md` in the new repo as the +> first commit action. + +**Scope:** Bootstrap the `ops-warden` repository and deliver a working `warden` CLI that +implements the SSH CA and certificate lifecycle defined in `wiki/AccessManagementDirective.md`. + +**Out of scope:** Vault HA/cluster setup, Ansible playbooks for host principal deployment +(those live in `railiance-infra`), session recording, and SSO integration (trigger §6.2 of +the directive when scale requires it). + +--- + +## Goal + +Create a new `ops-warden` repository that owns **credential issuance only** — the CA, +certificate signing, actor identity registry, and scorecard tooling. Its sole public surface +to sibling repos is a well-defined `cert_command` interface that any tool (principally +`ops-bridge`) can call to obtain a short-lived, CA-signed SSH certificate for a named actor. + +--- + +## Reference Documents + +| Document | Location | +|---|---| +| AccessManagementDirective | `ops-bridge/wiki/AccessManagementDirective.md` | +| ops-bridge SCOPE.md | `ops-bridge/SCOPE.md` | + +--- + +## Architecture + +``` +ops-warden/ +├── SCOPE.md +├── CLAUDE.md +├── pyproject.toml +├── src/warden/ +│ ├── cli.py # Typer CLI: sign / issue / status / inventory / scorecard +│ ├── models.py # ActorType enum, CertSpec, CertRecord, PrincipalsInventory +│ ├── ca.py # LocalCA backend (file-based, for dev / non-Vault) +│ ├── vault.py # VaultCA backend (Vault SSH engine, for production) +│ ├── inventory.py # YAML principals inventory read/write +│ ├── scorecard.py # §5 compliance checks +│ └── config.py # ~/.config/warden/warden.yaml loader +├── tests/ +└── wiki/ # (symlink or copy of AccessManagementDirective.md) +``` + +**Backends are swappable.** Config key `backend: local | vault` selects which CA +implementation is used. This means the tool is fully functional without Vault for local lab +use, and production-grade with Vault — the same CLI surface, the same `cert_command` +interface, the same principals inventory format. + +**cert_command interface contract:** +``` +warden sign --pubkey +``` +Writes the signed certificate to stdout (the cert text). Exits non-zero on failure. +`ops-bridge` calls this verbatim via `cert_command` in `tunnels.yaml`. + +--- + +## Stack + +- **Language:** Python 3.11+ +- **CLI framework:** Typer +- **Dependencies:** typer, pyyaml, httpx, cryptography (for cert parsing / TTL reading) +- **Vault SDK:** `hvac` (optional; only required for vault backend) +- **Packaging:** `uv tool install` + +--- + +## Tasks + +### T1 — Repository bootstrap + +```task +id: WARDEN-WP-0001-T1 +state_hub_task_id: 6d643e9d-5e97-4224-9d82-87267b5ba6bc +status: done +priority: high +``` + +- [x] Create `ops-warden` repo; copy CLAUDE.md template from `ops-bridge`; add + `workplans/WARDEN-WP-0001-initial-implementation.md` (this file) +- [x] Write `SCOPE.md` (see template in §SCOPE below) +- [x] `pyproject.toml`: `[project.scripts] warden = "warden.cli:app"` +- [x] Register repo with state-hub (`register_repo`) +- [x] Create state-hub workstream for this workplan + +### T2 — Models and config + +```task +id: WARDEN-WP-0001-T2 +state_hub_task_id: c66fc65a-0b16-4ba2-9e70-a83d875572ec +status: done +priority: high +``` + +- [x] `models.py`: `ActorType` enum (`adm | agt | atm`); `CertSpec` (actor_name, pubkey_path, + ttl_hours, principals); `CertRecord` (identity, valid_before, cert_path, signed_at) +- [x] `config.py`: load `~/.config/warden/warden.yaml`; required fields: `backend`, + `ca_key` (local) or `vault_addr` + `vault_role_map` (vault); optional: + `inventory_path`, `state_dir` +- [x] Validate actor name prefix matches `ActorType` (`adm-*`, `agt-*`, `atm-*`) + +### T3 — LocalCA backend + +```task +id: WARDEN-WP-0001-T3 +state_hub_task_id: a5a41e58-1c6d-42a9-9b11-2088f17c29b5 +status: done +priority: high +``` + +- [x] `ca.py`: `LocalCA.sign(spec: CertSpec) -> CertRecord` + - Calls `ssh-keygen -s -I -n -V +h ` + - Parses `ssh-keygen -L -f ` output to extract `Valid before`, `Key ID`, + `Principals` + - Returns `CertRecord`; writes cert to `~/.local/state/warden/.cert.pub` +- [x] Default TTLs enforced per `ActorType`: adm → 48 h, agt → 24 h, atm → 8 h + (overridable per actor in inventory) +- [x] `LocalCA.generate_keypair(actor_name) -> (privkey_path, pubkey_path)` — for agt/atm + actors that do not bring their own key + +### T4 — VaultCA backend + +```task +id: WARDEN-WP-0001-T4 +state_hub_task_id: b2067ee6-c9ce-423b-9d60-0d28069fb304 +status: done +priority: medium +``` + +- [x] `vault.py`: `VaultCA.sign(spec: CertSpec) -> CertRecord` + - `POST /v1/ssh/sign/` with `public_key`, `valid_principals`, `ttl` + - Parse response `signed_key` field; write to state dir; extract metadata via + `ssh-keygen -L` +- [x] Role map in config: `vault_role_map: {adm: adm-role, agt: agt-role, atm: atm-role}` +- [x] Graceful error message when Vault is unreachable (with `--backend local` fallback hint) + +### T5 — Principals inventory + +```task +id: WARDEN-WP-0001-T5 +state_hub_task_id: 6d13f8cd-1850-44c9-b769-b21250348319 +status: done +priority: high +``` + +- [x] `inventory.py`: load/save `inventory.yaml` (format mirrors §4.1 of directive): + ```yaml + actors: + agt-state-hub-bridge: + type: agt + principals: [agt-task-bridge] + ttl_hours: 24 + description: "ops-bridge tunnel actor" + hosts: + coulombcore: + allowed_principals: + agt: [agt-task-bridge] + atm: [atm-backup-daily] + ``` +- [x] `warden inventory list` — print table +- [x] `warden inventory add --type --principals <...>` +- [x] `warden inventory remove ` + +### T6 — CLI commands + +```task +id: WARDEN-WP-0001-T6 +state_hub_task_id: 656a4615-92bb-4b5d-9406-e86d24fa15d0 +status: done +priority: high +``` + +- [x] `warden sign --pubkey ` — sign existing pubkey; write cert to + stdout (the `cert_command` interface for ops-bridge) +- [x] `warden issue ` — generate keypair + sign; output JSON with + `privkey`, `cert`, `valid_before`, `identity` +- [x] `warden status [actor-name]` — show cert validity, identity, principals, TTL + remaining; `--all` flag to show all actors in state dir +- [x] `warden scorecard` — run §5 checks (see T7) +- [x] `warden inventory ` (list / add / remove) + +### T7 — Scorecard runner + +```task +id: WARDEN-WP-0001-T7 +state_hub_task_id: 7818bcc5-f40e-4793-b117-d36f653ffeed +status: done +priority: medium +``` + +- [x] `scorecard.py`: implement each §5 row as a named check function returning + `CheckResult(name, passed, detail)` +- [x] Checks in scope for `ops-warden` (local checks, not host-side): + - All certs in state dir respect TTL policy for their `ActorType` + - No actor in inventory lacks a `principals` entry + - Actor name prefix matches declared type + - No cert expired by more than 5 min still present in state dir (stale cleanup) +- [x] Host-side checks (password auth disabled, root login disabled, etc.) are out of scope + — those live in the Ansible `ssh-access-audit.yml` playbook in `railiance-infra` +- [x] `warden scorecard --json` for machine-readable output + +### T8 — ops-ssh-wrapper script + +```task +id: WARDEN-WP-0001-T8 +state_hub_task_id: e9c28152-5785-4995-83a5-439985ed3db9 +status: done +priority: medium +``` + +- [x] Ship `scripts/ops-ssh-wrapper` (the Python snippet from §4.1, hardened): + - Reads `WARDEN_ACTOR` and `SSH_PUBKEY` env vars + - Calls `warden sign $WARDEN_ACTOR --pubkey $SSH_PUBKEY` + - Loads cert via `ssh-add`; execs the given command +- [x] Install as part of `uv tool install` entry points + +### T9 — Tests + +```task +id: WARDEN-WP-0001-T9 +state_hub_task_id: 950139ab-cc17-4f1d-9a17-d5744e402ddf +status: done +priority: high +``` + +- [x] Unit tests for `LocalCA` (mock `ssh-keygen` subprocess) +- [x] Unit tests for inventory YAML round-trip +- [x] Unit tests for actor name prefix validation +- [x] Integration test: `LocalCA.sign` on a real test keypair (requires `ssh-keygen` in PATH) +- [x] Scorecard unit tests (mock cert records) + +### T10 — Documentation + +```task +id: WARDEN-WP-0001-T10 +state_hub_task_id: 271d6759-e359-41ce-80e4-76c574634a87 +status: done +priority: medium +``` + +- [x] `SCOPE.md` (see below) +- [x] `wiki/AccessManagementDirective.md` — copy from `ops-bridge/wiki/` +- [x] `wiki/OpsWardenConfig.md` — annotated `warden.yaml` reference +- [x] `wiki/CertCommandInterface.md` — contract for `cert_command` callers (ops-bridge etc.) + +--- + +## SCOPE.md Template + +``` +# SCOPE + +## One-liner +SSH Certificate Authority and credential issuance for the ops fleet — +signs short-lived certs for adm/agt/atm actors; provides the cert_command +interface consumed by ops-bridge and other tooling. + +## Core Idea +Implements AccessManagementDirective §§1–5. Owns the CA key, actor inventory, +signing logic, and scorecard. Does not own tunnel lifecycle, host provisioning, +or SSH key generation for humans. + +## In Scope +- Local CA backend (ssh-keygen -s) for lab / non-Vault use +- Vault SSH engine backend for production +- Actor identity registry (inventory.yaml) +- cert_command CLI interface: `warden sign --pubkey ` +- TTL policy enforcement per ActorType (adm/agt/atm) +- Certificate status and stale-cert cleanup +- Scorecard checks (local / cert-side only) +- ops-ssh-wrapper script for agt/atm startup automation + +## Out of Scope +- Host-side principal deployment (railiance-infra Ansible) +- SSH key generation for human admins (self-service: ssh-keygen) +- Vault cluster setup / HA +- Session recording, audit forwarding to SIEM (host-side) +- Tunnel lifecycle (ops-bridge) +- SSO / Teleport (trigger when §6.2 scale thresholds are hit) + +## Relevant When +- Issuing or refreshing a cert for any adm/agt/atm actor +- Checking cert validity / scorecard compliance +- ops-bridge needs cert_command to be defined +- Adding a new actor to the principals inventory + +## Not Relevant When +- Managing tunnel lifecycle (ops-bridge) +- Deploying SSH config to hosts (railiance-infra) +- All access is via static keys with no TTL (legacy mode) + +## Current State +Status: planned (WARDEN-WP-0001 not yet started) + +## Related Repositories +- ops-bridge — primary consumer of cert_command interface +- railiance-infra — owns host-side principal deployment +- the-custodian/state-hub — registers domain/workstreams +``` + +--- + +## Acceptance Criteria + +- [x] `warden sign agt-test-actor --pubkey /tmp/test.pub` outputs a valid cert (local backend) +- [x] `warden status agt-test-actor` shows correct identity, principals, and time-to-expiry +- [x] `warden scorecard` returns 5/5 on a clean test inventory +- [x] `warden sign` called from ops-bridge `cert_command` in an integration test tunnel +- [x] All tests pass: `uv run pytest` +- [x] All lints pass: `uv run ruff check .` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0002-correctness-and-completeness.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0002-correctness-and-completeness.md new file mode 100644 index 00000000..0b6044f9 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0002-correctness-and-completeness.md @@ -0,0 +1,178 @@ +--- +id: WARDEN-WP-0002 +type: workplan +title: "OpsWarden Correctness and Operational Completeness" +domain: custodian +repo: ops-warden +status: archived +owner: Bernd +topic_slug: custodian +planning_priority: high +planning_order: 2 +created: "2026-05-15" +updated: "2026-05-15" +state_hub_workstream_id: "5a9fba2c-6161-49a4-a231-e750fa4ab572" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0002 — Correctness and Operational Completeness + +**Scope:** Fix three functional gaps identified after WARDEN-WP-0001: TTL max +enforcement (directive compliance), stale cert cleanup (SCOPE.md promises it), +and an outgoing signatures log (audit traceability for every signing operation). + +**Out of scope:** Test coverage improvements (WARDEN-WP-0003), Vault cluster +setup, host-side principal deployment. + +--- + +## Goal + +After this workplan: + +1. `warden sign` and `warden issue` reject TTLs that exceed the type maximum + defined in the AccessManagementDirective — no cert can be silently issued + with a longer-than-allowed validity window. +2. Stale/expired certs do not accumulate in the state dir. `warden cleanup` + provides an on-demand sweep; `LocalCA.sign()` auto-evicts the previous cert + for the same actor before writing the new one. +3. Every successful signing operation is recorded in an append-only + `signatures.log` in the state dir. `warden log` provides a human-readable + and machine-readable view of the signing history. + +--- + +## Reference Documents + +| Document | Location | +|---|---| +| AccessManagementDirective | `wiki/AccessManagementDirective.md` | +| WARDEN-WP-0001 | `workplans/WARDEN-WP-0001-initial-implementation.md` | +| SCOPE.md | `SCOPE.md` | + +--- + +## Design Decisions + +### TTL enforcement: reject, don't clamp + +When `spec.ttl_hours > DEFAULT_TTL_HOURS[actor_type]`, raise `CAError` rather +than silently clamping. A silent clamp would mask configuration errors and hide +directive violations from operators. An explicit error forces a deliberate +decision. + +The check lives in `CABackend.sign()` before the subprocess call so it applies +to both `LocalCA` and `VaultCA`. Vault's own role `max_ttl` provides a second +layer; this check is the warden-side gate. + +### Cleanup: proactive (on sign) + reactive (on demand) + +`LocalCA.sign()` removes the previous cert for the same actor before writing the +new one — this keeps state_dir from growing unboundedly under normal operation. +`warden cleanup` handles the edge cases: certs whose actor is no longer in the +inventory, certs from aborted sessions, certs left by actors that were renamed. + +`VaultCA.sign()` also evicts before writing (same logic, same helper function). + +### Signatures log: JSONL, append-only, in state_dir + +One line per signing event, written after a successful `CertRecord` is produced. +Format: `{"timestamp": ..., "actor": ..., "actor_type": ..., "identity": ..., +"principals": [...], "ttl_hours": ..., "valid_before": ..., "backend": ...}`. + +The log lives alongside certs in `state_dir` so a single directory backup +captures the full operational history. No rotation at this scope — add rotation +in a follow-up if the file grows beyond a few MB in practice. + +`warden log` is read-only. No deletion via CLI — the log is an audit artefact. + +--- + +## Tasks + +### T1 — TTL max enforcement per ActorType + +```task +id: WARDEN-WP-0002-T1 +state_hub_task_id: b0d0b5f7-a181-4590-be26-c48ae28cd964 +status: done +priority: high +``` + +- [x] `models.py`: add `MAX_TTL_HOURS = DEFAULT_TTL_HOURS` alias (same values, + explicit name signals policy intent); add helper + `enforce_ttl(spec: CertSpec) -> None` that raises `CAError` when + `spec.ttl_hours > MAX_TTL_HOURS[spec.actor_type]` +- [x] `ca.py`: call `enforce_ttl(spec)` at the top of `CABackend.sign()` base + (or in both `LocalCA.sign()` and `VaultCA.sign()` if no shared base call) +- [x] `scorecard.py`: add `check_ttl_policy(state_dir, inventory)` — parse each + cert in state_dir via `ssh-keygen -L`; compare cert validity window + duration against `MAX_TTL_HOURS[actor_type]`; flag if exceeded +- [x] Add `check_ttl_policy` to `run_scorecard()` +- [x] Update tests: `test_ca.py` — assert `CAError` raised when `ttl_hours` + exceeds max for each type; assert no error at exactly the max + +### T2 — Stale cert cleanup command + +```task +id: WARDEN-WP-0002-T2 +state_hub_task_id: aeeefbad-c0bd-4ae8-a3fe-9f72321b4caa +status: done +priority: medium +``` + +- [x] `ca.py`: extract `_evict_cert(actor_name, state_dir)` — removes + `state_dir/-cert.pub` if it exists; call at the top of + `LocalCA.sign()` and `VaultCA.sign()` before writing the new cert +- [x] `cli.py`: add `warden cleanup [actor-name]` command + - No actor-name: iterate `state_dir/*.cert.pub`, remove any whose + `valid_before < now - 5 min` + - With actor-name: remove only that actor's cert if stale + - `--dry-run`: print what would be removed without deleting + - Exit 0 always (cleanup is idempotent; nothing to clean is not an error) +- [x] Update `check_no_stale_certs` scorecard check detail message to suggest + running `warden cleanup` +- [x] Update tests: verify `_evict_cert` is called during sign; verify cleanup + command removes stale file; verify `--dry-run` does not delete + +### T3 — Outgoing signatures log + +```task +id: WARDEN-WP-0002-T3 +state_hub_task_id: 0194d24f-a8fe-4f6d-88e6-addea3542c0e +status: done +priority: medium +``` + +- [x] `ca.py`: after a successful `CertRecord` is produced in `LocalCA.sign()` + and `VaultCA.sign()`, call `_append_signature_log(record, spec, state_dir, + backend)` which appends a JSONL line to + `state_dir/signatures.log` + Fields: `timestamp` (ISO 8601 UTC), `actor`, `actor_type`, `identity`, + `principals`, `ttl_hours`, `valid_before`, `cert_path`, `backend` +- [x] `cli.py`: add `warden log [actor-name]` command + - Reads `state_dir/signatures.log` (empty list if absent) + - `--last N` (default 20): show last N entries + - `--actor `: filter by actor + - `--json`: output newline-delimited JSON; default: Rich table + - Exit 0 always +- [x] Update tests: verify log entry written after sign; verify log not written + on CAError; verify `warden log` filters correctly + +--- + +## Acceptance Criteria + +- [x] `warden sign agt-test --pubkey /tmp/k.pub --ttl 100` raises `CAError` + (agt max is 24h) +- [x] `warden sign agt-test --pubkey /tmp/k.pub --ttl 24` succeeds +- [x] `warden scorecard` includes TTL policy check; fails when a cert exceeds type max +- [x] After `warden sign`, `state_dir/signatures.log` has one new line; valid JSON +- [x] `warden log` renders a table; `warden log --json` is parseable +- [x] `warden log --actor agt-test` returns only entries for that actor +- [x] `warden cleanup --dry-run` lists stale certs without deleting +- [x] `warden cleanup` removes stale certs; scorecard `no_stale_certs` passes after +- [x] Re-signing an actor replaces its cert file (no accumulation) +- [x] All tests pass: `uv run pytest` +- [x] All lints pass: `uv run ruff check .` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0003-test-coverage-and-quality.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0003-test-coverage-and-quality.md new file mode 100644 index 00000000..d544f950 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260515-WARDEN-WP-0003-test-coverage-and-quality.md @@ -0,0 +1,211 @@ +--- +id: WARDEN-WP-0003 +type: workplan +title: "OpsWarden Test Coverage and Code Quality" +domain: custodian +repo: ops-warden +status: archived +owner: Bernd +topic_slug: custodian +planning_priority: medium +planning_order: 3 +created: "2026-05-15" +updated: "2026-05-15" +state_hub_workstream_id: "cb2bbf3c-848a-4af6-ba64-8361e64cd4d7" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0003 — Test Coverage and Code Quality + +**Scope:** Close the test coverage gaps left after WARDEN-WP-0001: VaultCA has +zero tests, `generate_keypair` is untested, no CLI tests exist, and no real +`ssh-keygen` integration test was written. Also fix file permission enforcement +(security) and add `--state-dir` override to `warden status` (usability). + +**Out of scope:** Functional behaviour changes (WARDEN-WP-0002), Vault cluster +setup, host-side tooling. + +--- + +## Goal + +After this workplan: + +1. VaultCA has a full unit test suite covering success, auth failure, network + failure, and role-map misconfiguration. +2. `generate_keypair` has direct unit tests alongside the existing `sign` tests. +3. A `tests/test_cli.py` covers every command's exit codes and output shape. +4. A `tests/test_integration.py` marked `@pytest.mark.integration` exercises + `LocalCA.sign()` against a real `ssh-keygen` without any mocking. +5. Cert and key files written by warden are always mode 600; a scorecard check + flags world-readable files. +6. `warden status --state-dir ` works without a `warden.yaml`. + +--- + +## Reference Documents + +| Document | Location | +|---|---| +| WARDEN-WP-0001 | `workplans/WARDEN-WP-0001-initial-implementation.md` | +| WARDEN-WP-0002 | `workplans/WARDEN-WP-0002-correctness-and-completeness.md` | +| CertCommandInterface | `wiki/CertCommandInterface.md` | + +--- + +## Design Decisions + +### Integration tests: separate marker, not separate directory + +Use `@pytest.mark.integration` and skip when `ssh-keygen` is not in PATH. Tests +live in `tests/test_integration.py`. The unit suite (`uv run pytest`) excludes +integration tests via `pytest.ini_options addopts = "-m 'not integration'"`; +`uv run pytest -m integration` runs them explicitly. This keeps CI fast while +making the real-ssh-keygen path easy to invoke manually. + +### File permissions: at write time, not at read time + +`os.chmod(path, 0o600)` is called immediately after each `path.write_text()` or +`shutil.copy2()` that writes a key or cert. No deferred or scheduled chmod. The +scorecard check catches files that were written by older versions of warden or by +external tools. + +### `warden status --state-dir`: config bypass, not config optional + +When `--state-dir` is provided, skip `load_config()` entirely — don't try to +load a partial config. This makes the flag useful on remote machines that have +received a cert via ops-bridge but have no warden installation. + +--- + +## Tasks + +### T1 — VaultCA tests + +```task +id: WARDEN-WP-0003-T1 +state_hub_task_id: eff074ce-c027-4df5-8006-0990296592ac +status: done +priority: high +``` + +- [x] Create `tests/test_vault.py` +- [x] Test `VaultCA.sign()` success: mock `httpx.post` returning a valid + `signed_key`; assert `CertRecord` fields; assert cert file written to + state_dir +- [x] Test HTTP 403: `httpx.HTTPStatusError` → `CAError` with status code in message +- [x] Test unreachable Vault: `httpx.RequestError` → `CAError` with fallback hint +- [x] Test missing `VAULT_TOKEN`: `_token()` raises `CAError` before HTTP call +- [x] Test missing role in `role_map`: `CAError` before HTTP call +- [x] Test missing pubkey file: `CAError` before HTTP call + +### T2 — LocalCA.generate_keypair tests + +```task +id: WARDEN-WP-0003-T2 +state_hub_task_id: ddfe5331-0a3b-4783-bdf4-f5ebcdf7965c +status: done +priority: medium +``` + +- [x] Add `TestGenerateKeypair` class to `tests/test_ca.py` +- [x] Test success: mock `subprocess.run`; assert privkey and pubkey paths returned +- [x] Test ssh-keygen called with `-t ed25519`, `-N ""`, `-C actor_name` +- [x] Test existing files are unlinked before generation (write dummy files first) +- [x] Test `CAError` raised on non-zero ssh-keygen exit code +- [x] Test output files land in `state_dir/keys/` + +### T3 — CLI tests + +```task +id: WARDEN-WP-0003-T3 +state_hub_task_id: 040ce3a1-0efb-4816-a2d9-357162dd1612 +status: done +priority: high +``` + +- [x] Create `tests/test_cli.py` using `typer.testing.CliRunner` +- [x] `warden sign`: exits 0 and stdout is cert text (mock CA); exits 1 on + unknown actor; exits 1 on config error +- [x] `warden issue`: exits 1 on vault backend; exits 0 on local backend (mock CA) +- [x] `warden status`: exits 0 and prints "no cert" message when state_dir empty; + exits 1 when cert is expired (mock `parse_cert_metadata`) +- [x] `warden scorecard`: exits 0 on clean inventory + empty state_dir; + exits 1 when a check fails +- [x] `warden inventory add / list / remove`: round-trip via tmp inventory file +- [x] `warden log`: exits 0 with empty output when no log; `--json` is valid JSON + (after WARDEN-WP-0002 T3 adds the log command) +- [x] `warden cleanup --dry-run`: exits 0, no files deleted + (after WARDEN-WP-0002 T2 adds cleanup) + +### T4 — Real ssh-keygen integration test + +```task +id: WARDEN-WP-0003-T4 +state_hub_task_id: 434fb008-103f-410c-85fd-e77b33e61fe4 +status: done +priority: medium +``` + +- [x] Create `tests/test_integration.py` +- [x] Mark all tests `@pytest.mark.integration` +- [x] Add `pytest.ini_options` to `pyproject.toml`: + `addopts = "-m 'not integration'"` so unit suite skips them by default +- [x] Test `LocalCA.sign()` end-to-end: generate a real CA keypair and actor + keypair via subprocess ssh-keygen in tmp_path; call `LocalCA.sign()`; + assert `CertRecord.valid_before > datetime.now(utc)`; assert cert file + exists; assert `parse_cert_metadata()` succeeds on it without mocking +- [x] Skip test if `shutil.which("ssh-keygen") is None` +- [x] Document in README: `uv run pytest -m integration` to run real-CA tests + +### T5 — File permissions enforcement (mode 600) + +```task +id: WARDEN-WP-0003-T5 +state_hub_task_id: ac146fe6-d1fd-4186-91bd-6f098de72449 +status: done +priority: medium +``` + +- [x] `ca.py` `LocalCA.sign()`: call `os.chmod(dest, 0o600)` after `shutil.copy2` +- [x] `ca.py` `LocalCA.generate_keypair()`: call `os.chmod(privkey, 0o600)` and + `os.chmod(pubkey, 0o644)` after generation +- [x] `vault.py` `VaultCA.sign()`: call `os.chmod(dest, 0o600)` after `dest.write_text` +- [x] `scorecard.py`: add `check_file_permissions(state_dir)` — flag any + `*-cert.pub` or `keys/*` file where `stat().st_mode & 0o044 != 0` +- [x] Add `check_file_permissions` to `run_scorecard()` +- [x] Update `test_ca.py`: assert `os.chmod` called with correct mode after sign + and generate_keypair (patch os.chmod or check stat on actual files in + tmp_path) + +### T6 — warden status --state-dir override + +```task +id: WARDEN-WP-0003-T6 +state_hub_task_id: 1c9f1987-7b11-43c1-a5e3-c2fd8d1c1589 +status: done +priority: low +``` + +- [x] `cli.py` `status()`: add + `state_dir_override: Annotated[Optional[Path], typer.Option("--state-dir")] = None` +- [x] When `--state-dir` is provided: use it directly, skip `_load_cfg()` entirely +- [x] When absent: load config as today +- [x] Add test in `test_cli.py`: invoke `warden status --state-dir ` + without a config file; assert exit 0 + +--- + +## Acceptance Criteria + +- [x] `uv run pytest` runs unit suite only; all pass; VaultCA and generate_keypair + covered +- [x] `uv run pytest -m integration` succeeds (requires ssh-keygen in PATH) +- [x] `test_cli.py` covers all commands; no mocked subprocess in CLI tests where + avoidable (use tmp inventory files and mocked CA) +- [x] `ls -la ~/.local/state/warden/*.pub` shows mode 600 for newly signed certs +- [x] Scorecard `file_permissions` check passes on a clean state dir; fails on a + world-readable cert +- [x] `warden status --state-dir /tmp/some-dir` runs without a `warden.yaml` +- [x] All lints pass: `uv run ruff check .` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0004-repo-hygiene-and-hub-sync.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0004-repo-hygiene-and-hub-sync.md new file mode 100644 index 00000000..31330938 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0004-repo-hygiene-and-hub-sync.md @@ -0,0 +1,95 @@ +--- +id: WARDEN-WP-0004 +type: workplan +title: "OpsWarden Repo Hygiene and Hub Sync" +domain: custodian +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +created: "2026-06-17" +updated: "2026-06-17" +state_hub_workstream_id: "3c4b6e68-550a-4fc6-a804-95f1f68936c3" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0004 — Repo Hygiene and Hub Sync + +**Scope:** Bring repo orientation docs and agent rules in line with the shipped +`warden` CLI (WARDEN-WP-0001 through 0003 complete). Archive finished workplans +and sync State Hub. + +**Out of scope:** OpenBao doc alignment (WARDEN-WP-0005), capability registry +publish, task-status canon migration in AGENTS.md. + +--- + +## Goal + +After this workplan, a new agent session can orient from accurate local files +without reading stale "planned / scaffolding only" language, and State Hub +reflects archived workplan status. + +--- + +## Tasks + +### T1 — Update orientation docs + +```task +id: WARDEN-WP-0004-T01 +status: done +priority: high +state_hub_task_id: "f9d3926c-8637-411c-a477-2960b754704c" +``` + +- [x] `SCOPE.md` Current State reflects shipped CLI (v0.1.0, workplans 0001–0003 done) +- [x] `README.md` replaces repo-seed template with install, config, and dev commands + +### T2 — Fill agent rules + +```task +id: WARDEN-WP-0004-T02 +status: done +priority: medium +state_hub_task_id: "86c764a5-62fc-45fe-a8d2-332d6554a976" +``` + +- [x] `.claude/rules/stack-and-commands.md` — stack and `uv` dev commands +- [x] `.claude/rules/architecture.md` — module layout and data flow +- [x] `.claude/rules/repo-boundary.md` — adjacent repo ownership + +### T3 — Archive finished workplans + +```task +id: WARDEN-WP-0004-T03 +status: done +priority: medium +state_hub_task_id: "d3e54e63-ce98-4632-bc08-0e2667f19f12" +``` + +- [x] Move WARDEN-WP-0001/0002/0003 to `workplans/archived/` with date prefix +- [x] Set frontmatter `status: archived` on moved files + +### T4 — Sync State Hub + +```task +id: WARDEN-WP-0004-T04 +status: done +priority: medium +state_hub_task_id: "51729695-262f-4fe4-9c38-f99ee046d32a" +``` + +- [x] Run `make fix-consistency REPO=ops-warden` from state-hub +- [x] Verify `.custodian-brief.md` reflects archived workstreams + +--- + +## Acceptance Criteria + +- [x] `SCOPE.md` no longer says "planned" or "scaffolding only" +- [x] `README.md` documents `uv sync`, `uv run pytest`, and `warden --help` +- [x] Agent rules have no empty TODO blocks for stack, architecture, or boundary +- [x] Only WARDEN-WP-0004 remains in `workplans/` root (archived plans moved) +- [x] `make fix-consistency REPO=ops-warden` completes without error \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0005-openbao-doc-alignment.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0005-openbao-doc-alignment.md new file mode 100644 index 00000000..9969260d --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0005-openbao-doc-alignment.md @@ -0,0 +1,65 @@ +--- +id: WARDEN-WP-0005 +type: workplan +title: "OpsWarden OpenBao-First Documentation Alignment" +domain: custodian +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +created: "2026-06-17" +updated: "2026-06-17" +state_hub_workstream_id: "57f6ebf8-0ef3-4686-9a73-3f9d38288be9" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0005 — OpenBao-First Documentation Alignment + +**Scope:** Update ops-warden documentation so production guidance names OpenBao +as the platform secrets service while preserving the existing `backend: vault` +config surface (Vault-compatible SSH secrets engine API). No code changes. + +**Out of scope:** VaultCA backend rewrite, OpenBao SSH engine deployment in +`railiance-platform`, AccessManagementDirective canon updates. + +**Reference:** `RAIL-PL-WP-0002` — Railiance standardizes on OpenBao; ops-warden +follow-up noted 2026-05-17. + +--- + +## Tasks + +### T1 — OpsWardenConfig.md + +```task +id: WARDEN-WP-0005-T01 +status: done +priority: high +state_hub_task_id: "bbbc4dda-9634-4c04-86e5-94b96c021b43" +``` + +- [x] OpenBao-first production section with Railiance URLs and `bao` CLI examples +- [x] Explain `backend: vault` / `vault:` keys as Vault-compatible API abstraction +- [x] Link to `railiance-platform/docs/openbao.md` + +### T2 — Cross-reference updates + +```task +id: WARDEN-WP-0005-T02 +status: done +priority: medium +state_hub_task_id: "6391cb82-896e-405a-a59b-36640e6480ba" +``` + +- [x] `SCOPE.md` Core Idea and In Scope — OpenBao-first, Vault-compatible +- [x] `wiki/CertCommandInterface.md` — caller-agnostic wording includes OpenBao + +--- + +## Acceptance Criteria + +- [x] Production config example uses OpenBao (`bao.coulomb.social` or in-cluster URL) +- [x] No reader is told HashiCorp Vault is the platform standard +- [x] `backend: vault` config shape unchanged (code compatibility preserved) +- [x] `uv run pytest` still passes (docs-only change) \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0006-netkingdom-alignment-and-access-stewardship.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0006-netkingdom-alignment-and-access-stewardship.md new file mode 100644 index 00000000..8a7cc2f6 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0006-netkingdom-alignment-and-access-stewardship.md @@ -0,0 +1,140 @@ +--- +id: WARDEN-WP-0006 +type: workplan +title: "NetKingdom Alignment and Operational Access Stewardship" +domain: custodian +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 6 +created: "2026-06-17" +updated: "2026-06-17" +state_hub_workstream_id: "a5c9f24b-1ad4-46da-bc8e-b99897f8e302" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0006 — NetKingdom Alignment and Operational Access Stewardship + +**Scope:** Close gaps identified in `history/2026-06-17-intent-scope-assessment.md` +between INTENT (operational access steward for NetKingdom security) and SCOPE +(shipped SSH CLI only). Documentation and alignment first; code changes limited +to optional CLI ergonomics. + +**Out of scope:** flex-auth integration implementation, OpenBao cluster deploy, +universal credential broker, net-kingdom INTENT.md rewrite. + +--- + +## Goal + +After this workplan, a development worker or agent can: + +1. Read ops-warden material and know **which NetKingdom subsystem** handles each + credential type. +2. Obtain **SSH certs** via documented actor patterns and production OpenBao path. +3. Find ops-warden recognized in **NetKingdom responsibility/platform** docs as + the operational SSH credential authority. + +--- + +## Tasks + +### T1 — Credential routing runbook + +```task +id: WARDEN-WP-0006-T01 +status: done +priority: high +state_hub_task_id: "ffc6a0c2-4312-4584-be7a-c8411cb01899" +``` + +- [x] `wiki/CredentialRouting.md` with decision tree and anti-examples +- [x] Linked from SCOPE, INTENT, README + +### T2 — Actor inventory patterns + +```task +id: WARDEN-WP-0006-T02 +status: done +priority: high +state_hub_task_id: "3816463d-7dfd-469d-9324-fd7880b50608" +``` + +- [x] `wiki/ActorInventoryPatterns.md` +- [x] `examples/inventory.seed.yaml` + +### T3 — NetKingdom cross-links (ops-warden side) + +```task +id: WARDEN-WP-0006-T03 +status: done +priority: high +state_hub_task_id: "f158366a-5746-48b8-acce-472dce8f925e" +``` + +- [x] `wiki/NetKingdomSecurityMap.md` +- [x] Registry capability stewardship summary +- [x] `.claude/rules/repo-boundary.md` routing table + +### T4 — NetKingdom canon patch (coordination) + +```task +id: WARDEN-WP-0006-T04 +status: done +priority: medium +state_hub_task_id: "e40e4395-8f01-4f79-a539-d0de8e427321" +``` + +- [x] `net-kingdom/docs/responsibility-map.md` — Operational SSH dependency +- [x] `net-kingdom/docs/platform-identity-security-architecture.md` — Operational SSH Path + +### T5 — OpenBao SSH engine operational checklist + +```task +id: WARDEN-WP-0006-T05 +status: done +priority: medium +state_hub_task_id: "a94e20a2-970b-4a0c-bd23-8510b841b938" +``` + +- [x] `wiki/OpenBaoSshEngineChecklist.md` + +### T6 — Policy-gated signing design (design only) + +```task +id: WARDEN-WP-0006-T06 +status: done +priority: low +state_hub_task_id: "b10a4b4d-bfa1-4f49-b6a5-f339f1e6a2e1" +``` + +- [x] `wiki/PolicyGatedSigning.md` + +### T7 — Re-assess INTENT ↔ SCOPE + +```task +id: WARDEN-WP-0006-T07 +status: done +priority: medium +state_hub_task_id: "ef8b5c57-2343-4cfc-9fee-48db1e56f69a" +``` + +- [x] `history/2026-06-17-intent-scope-reassessment.md` +- [x] SCOPE.md Current State updated +- [x] `make fix-consistency REPO=ops-warden` + +--- + +## Acceptance Criteria + +- [x] `wiki/CredentialRouting.md` exists and is linked from README/SCOPE +- [x] `wiki/ActorInventoryPatterns.md` exists +- [x] `wiki/NetKingdomSecurityMap.md` exists +- [x] NetKingdom responsibility-map recognizes ops-warden SSH lane (T4) +- [x] OpenBao SSH checklist documented (T5) +- [x] Policy-gated signing design drafted (T6) +- [x] INTENT ↔ SCOPE re-assessment recorded (T7) +- [x] `reuse-surface validate --root .` passes \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0007-policy-gate-and-production-verify.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0007-policy-gate-and-production-verify.md new file mode 100644 index 00000000..f49eea27 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260617-WARDEN-WP-0007-policy-gate-and-production-verify.md @@ -0,0 +1,88 @@ +--- +id: WARDEN-WP-0007 +type: workplan +title: "Policy Gate and Production OpenBao Verification" +domain: custodian +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 7 +created: "2026-06-17" +updated: "2026-06-17" +state_hub_workstream_id: "3718ac07-2fa2-47d0-a02a-c9a7b83a5ba9" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0007 — Policy Gate and Production OpenBao Verification + +**Scope:** Record production OpenBao reachability evidence; implement opt-in +flex-auth policy gate before `warden sign` / `warden issue` per +`wiki/PolicyGatedSigning.md`. + +**Out of scope:** flex-auth policy package authoring, OpenBao SSH engine mount +on Railiance (operator), identity claim requirement (v2.1). + +--- + +## Tasks + +### T1 — Production OpenBao verification evidence + +```task +id: WARDEN-WP-0007-T01 +status: done +priority: high +state_hub_task_id: "344540ad-5912-4118-b406-450b96e13c40" +``` + +- [x] Probe `https://bao.coulomb.social/v1/sys/health` +- [x] Document results in `history/2026-06-17-openbao-production-verify.md` +- [x] Note blockers for full `warden sign` (scoped token, SSH engine roles) + +### T2 — Policy config and flex-auth client + +```task +id: WARDEN-WP-0007-T02 +status: done +priority: high +state_hub_task_id: "05424ddf-5fe9-43a1-a2f8-c47235a012c8" +``` + +- [x] `PolicyConfig` in `config.py` (`policy.enabled`, `flex_auth_url`, `fail_closed`) +- [x] `policy.py` — POST `/v1/check`, pubkey fingerprint, CAError on deny + +### T3 — Wire policy gate into sign/issue + +```task +id: WARDEN-WP-0007-T03 +status: done +priority: high +state_hub_task_id: "f5ae8e6e-8cce-4526-b18c-0452a135af49" +``` + +- [x] Call policy check before `ca.sign()` when enabled +- [x] Store `policy_decision_id` in `signatures.log` + +### T4 — Tests and docs + +```task +id: WARDEN-WP-0007-T04 +status: done +priority: medium +state_hub_task_id: "ea921d56-033b-4619-8032-61af7992e610" +``` + +- [x] `tests/test_policy.py` +- [x] Update `wiki/OpsWardenConfig.md`, `wiki/PolicyGatedSigning.md` + +--- + +## Acceptance Criteria + +- [x] Production health evidence recorded (non-secret) +- [x] `policy.enabled: false` default — no behavior change +- [x] `policy.enabled: true` calls flex-auth; deny blocks sign +- [x] All unit tests pass \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260618-WARDEN-WP-0008-production-ssh-path-and-stewardship-closeout.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260618-WARDEN-WP-0008-production-ssh-path-and-stewardship-closeout.md new file mode 100644 index 00000000..f3827285 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260618-WARDEN-WP-0008-production-ssh-path-and-stewardship-closeout.md @@ -0,0 +1,153 @@ +--- +id: WARDEN-WP-0008 +type: workplan +title: "Production SSH Path and Stewardship Closeout" +domain: custodian +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 8 +created: "2026-06-17" +updated: "2026-06-18" +state_hub_workstream_id: "a174963a-4ff1-4565-b19f-896cd4ff14a0" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0008 — Production SSH Path and Stewardship Closeout + +**Scope:** Close the reliability gap left after WARDEN-WP-0007 — prove the +production OpenBao SSH signing path end-to-end, refresh INTENT/SCOPE canon for +the shipped flex-auth policy gate, adapt repo docs to State Hub task-status +canon, and archive finished workplans. + +**Out of scope:** OpenBao cluster deploy or SSH engine bootstrap (operator / +`railiance-platform`), flex-auth policy package authoring, NK-WP-0009 joint +tutorial (coordinate separately), populating non-SSH secrets (e.g. OpenRouter +API keys — route to OpenBao per `wiki/CredentialRouting.md`). + +--- + +## Goal + +Move ops-warden from **documented + code-shipped** (WP-0006/0007) to +**production-verified SSH issuance** with up-to-date stewardship canon: + +1. A scoped operator can run `warden sign` against `https://bao.coulomb.social` + and record non-secret evidence. +2. `SCOPE.md` and reassessment history reflect WP-0007 policy gate as implemented. +3. Agent/workplan docs use State Hub task lifecycle (`wait` / `todo` / `progress` + / `done` / `cancel`). +4. Finished workplans WP-0004–0007 are archived under `workplans/archived/`. + +--- + +## Tasks + +### T1 — Post-WP-0007 INTENT/SCOPE reassessment + +```task +id: WARDEN-WP-0008-T01 +status: done +priority: high +state_hub_task_id: "05379da4-79d0-4742-8638-9e9565cccf72" +``` + +- [x] Write `history/2026-06-17-post-wp0007-reassessment.md` (vector D5/A3/C4/R2) +- [x] Update `SCOPE.md` — policy gate implemented, WP-0008 active +- [x] Resolve remaining `PolicyGatedSigning.md (not implemented)` references in SCOPE/README + +### T2 — Production OpenBao end-to-end sign verification + +```task +id: WARDEN-WP-0008-T02 +status: done +priority: high +state_hub_task_id: "b1a1831d-b2b3-4204-95f6-04dc7f29f67c" +``` + +- [x] Operator provides scoped `VAULT_TOKEN` (warden-sign policy token) +- [x] Confirm SSH engine mounted and roles per `wiki/OpenBaoSshEngineChecklist.md` +- [x] Run `warden sign` + `warden status` + `warden log` against production OpenBao +- [x] Append pass/fail evidence to `history/2026-06-17-openbao-production-verify.md` +- [ ] Optional: cert_command smoke via ops-bridge tunnel — deferred; tunnels still + static-key mode (`agt-claude-*`); wire when ops-bridge adopts `cert_command` for + `agt-state-hub-bridge` + +### T3 — State Hub task status canon migration + +```task +id: WARDEN-WP-0008-T03 +status: done +priority: medium +state_hub_task_id: "876827c4-4a86-4e58-9a1f-ac87045dc903" +``` + +- [x] Update `AGENTS.md` task status values and examples (`progress`, `wait`, `cancel`) +- [x] Update `.claude/rules/workplan-convention.md` task block examples +- [x] Mark state-hub interface change `649102a2-4373-4621-9848-cc257e67c262` resolved +- [x] Reply to inbox message `c4072e5a-2afb-44ba-bfa2-7d4cb9979c6e` (read + note adaptation) + +### T4 — Production config example and archive hygiene + +```task +id: WARDEN-WP-0008-T04 +status: done +priority: medium +state_hub_task_id: "75b9f366-3d7a-419d-98ad-bc10ab90a697" +``` + +- [x] Add `examples/warden.production.example.yaml` (no secrets; OpenBao addr + policy off) +- [x] Archive finished workplans → `workplans/archived/260617-WARDEN-WP-000{4,5,6,7}-*.md` +- [x] `make fix-consistency REPO=ops-warden` after archive + +### T5 — flex-auth policy gate production readiness (coordination) + +```task +id: WARDEN-WP-0008-T05 +status: cancel +priority: low +state_hub_task_id: "03b412a5-5b99-42df-a154-733dd4156000" +``` + +Spun out to **WARDEN-WP-0009** (flex-auth owner dependency). ops-warden gate code +and docs shipped in WP-0007; production enablement waits on flex-auth policies. + +--- + +## Acceptance Criteria + +- [x] Post-WP-0007 reassessment on file; SCOPE current +- [x] Production `warden sign` evidence recorded (`history/2026-06-17-openbao-production-verify.md`) +- [x] AGENTS.md uses canonical task statuses +- [x] WP-0004–0007 archived; hub consistency pass +- [x] Production example config committed (no secrets) + +--- + +## Closeout (2026-06-18) + +T1–T4 and T2 complete. T5 cancelled — continued in WARDEN-WP-0009. Optional +ops-bridge `cert_command` smoke deferred until tunnel configs adopt warden signing. + +--- + +## Dependencies + +| Dependency | Owner | Blocks | +| --- | --- | --- | +| OpenBao SSH engine + host CA automation | NET-WP-0020 / railiance-* | T2 | +| flex-auth ssh-certificate policies | flex-auth | T5 | +| NK-WP-0009 SSH tutorial | net-kingdom + ops-warden | — (parallel track) | + +--- + +## See also + +- `history/2026-06-17-openbao-production-verify.md` — health probe (WP-0007) +- `history/2026-06-17-post-wp0007-reassessment.md` — latest assessment +- `examples/warden.production.example.yaml` — operator config template +- `wiki/OpenBaoSshEngineChecklist.md` +- `wiki/PolicyGatedSigning.md` — opt-in gate (implemented WP-0007) \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260623-WARDEN-WP-0009-flex-auth-policy-gate-production.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260623-WARDEN-WP-0009-flex-auth-policy-gate-production.md new file mode 100644 index 00000000..7f87d0ed --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260623-WARDEN-WP-0009-flex-auth-policy-gate-production.md @@ -0,0 +1,97 @@ +--- +id: WARDEN-WP-0009 +type: workplan +title: "flex-auth Policy Gate Production Readiness" +domain: infotech +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: low +planning_order: 9 +created: "2026-06-18" +updated: "2026-06-23" +state_hub_workstream_id: "9213b262-e2f5-480e-a5bc-56635d5eb4c9" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0009 — flex-auth Policy Gate Production Readiness + +**Scope:** Enable and verify the opt-in flex-auth pre-sign gate (`policy.enabled`) +in production after flex-auth publishes `ssh-certificate` resource policies. + +**Out of scope:** flex-auth policy package authoring (flex-auth owner — delivered +FLEX-WP-0006 2026-06-23); OpenBao SSH engine and host CA (complete — NET-WP-0020 +T5 / WP-0008 T2); in-cluster flex-auth deployment (continued in flex-auth +`FLEX-WP-0007`). + +**Spun out from:** WARDEN-WP-0008 T5 (2026-06-18 closeout). + +--- + +## Tasks + +### T1 — flex-auth policy package confirmation + +```task +id: WARDEN-WP-0009-T01 +status: done +priority: medium +state_hub_task_id: "f988ed2e-0f63-4e89-abc4-183a7f23ddc2" +``` + +- [x] Confirm flex-auth policies for resource type `ssh-certificate` exist +- [x] Document tenant/subject bindings for `adm` / `agt` / `atm` sign paths +- [x] Coordinate with flex-auth owner on deny/allow test fixtures + +### T2 — Production enablement and smoke + +```task +id: WARDEN-WP-0009-T02 +status: done +priority: medium +state_hub_task_id: "9d0fabc2-10ef-426d-a3d2-d4970d377029" +``` + +- [x] Document operator steps to set `policy.enabled: true` (see `wiki/PolicyGatedSigning.md`) +- [x] Local smoke — allow/deny paths with `policy_decision_id` / `ttl_out_of_bounds` +- [x] Production registry slice from inventory (`registry/flex-auth/production_registry_snapshot.json`) +- [x] Production registry smoke — allow `agt-state-hub-bridge` (`decision:032b096c433ad80c`) +- [x] Production registry smoke — deny `--ttl 999` (`ttl_out_of_bounds`) + +--- + +## Deliverables + +| Artifact | Path | +| --- | --- | +| Registry builder | `scripts/build_flex_auth_registry.py` | +| Production registry | `registry/flex-auth/production_registry_snapshot.json` | +| Smoke runner | `scripts/policy_gate_production_smoke.sh` | +| Local smoke evidence | `history/2026-06-23-flex-auth-policy-gate-local-smoke.md` | +| Production smoke evidence | `history/2026-06-23-flex-auth-policy-gate-production-smoke.md` | +| flex-auth pickup brief | `history/2026-06-23-flex-auth-production-pickup-suggestion.md` | + +--- + +## Closeout (2026-06-23) + +T1–T2 complete. ops-warden caller side and production-registry smoke verified. +Production `policy.enabled: true` flip deferred until flex-auth runtime is +reachable — tracked in flex-auth `FLEX-WP-0007`, not this workplan. + +**Operator follow-up (FLEX-WP-0007):** + +- Deploy registry + policy package to in-cluster flex-auth; set `policy.flex_auth_url` +- Refresh scoped `VAULT_TOKEN` and run `SMOKE_VAULT=1 ./scripts/policy_gate_production_smoke.sh` +- Set `policy.enabled: true` in `~/.config/warden/warden.yaml` when flex-auth is reachable + +--- + +## See also + +- `wiki/PolicyGatedSigning.md` +- `~/flex-auth/docs/ops-warden-policy-gate-handoff.md` +- `~/flex-auth/workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md` +- `examples/warden.production.example.yaml` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0010-access-routing-charter.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0010-access-routing-charter.md new file mode 100644 index 00000000..12357da7 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0010-access-routing-charter.md @@ -0,0 +1,178 @@ +--- +id: WARDEN-WP-0010 +type: workplan +title: "Access Routing — Charter and Pointer Catalog" +domain: infotech +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 10 +created: "2026-06-18" +updated: "2026-06-24" +state_hub_workstream_id: "e93de9fd-0192-4d02-bb7c-5e859fb76b9b" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0010 — Access Routing — Charter and Pointer Catalog + +**Scope:** Sharpen the existing steward framing so it cannot be misread as a desk +API that wraps every subsystem. ops-warden **issues SSH certificates** and +**points workers to the owning subsystem** for everything else. This workplan +updates INTENT/SCOPE wording and adds a machine-readable routing catalog that is +a **pointer layer**, not a second copy of NetKingdom canon. + +**Not a new security lane.** This is wording + a thin lookup surface. SSH issuance +remains the only thing ops-warden executes. Maturity moves Availability A3 → A4 +(structured lookup for agents); Completeness and Reliability for SSH are unchanged. + +**Out of scope:** Secret-vending, OIDC, policy PDP, tunnel, or host-hardening code +in this repo; flex-auth policy packages (WARDEN-WP-0009); any universal broker. + +**Depends on:** WARDEN-WP-0006 stewardship canon (routing wiki, security map) — shipped. + +**Feeds:** WARDEN-WP-0011 (routing CLI over the catalog). + +--- + +## Principles (target) + +1. **Point, don't proxy** — Name the owner and the doc; do not wrap a foreign API + unless the answer is an SSH certificate. +2. **Direct interaction** — Workers (humans, agents, CI, operators) call OpenBao, + key-cape, flex-auth, ops-bridge, and railiance repos themselves. +3. **One source of truth** — Routing procedure for non-SSH needs lives in the wiki + (aligned to net-kingdom canon) and upstream canon, **not** restated in the + catalog. The catalog carries identifiers and pointers only. ops-warden authors + procedure for exactly one lane: SSH certificate issuance, which it owns. +4. **Same truth, two shapes** — Humans read the wiki; agents read the catalog. The + catalog references wiki sections by anchor so they cannot drift apart. + +--- + +## No-double-source rule (binding on T3) + +The catalog must not contain step-by-step procedure for any subsystem ops-warden +does not own. For non-SSH scenarios an entry carries: + +- `owner_repo`, `subsystem` — who to talk to +- `wiki_ref` — anchor into an in-repo wiki section (the authoritative restatement) +- `canon_ref` — upstream net-kingdom doc the wiki section tracks +- `need_keywords`, `title`, `id` — lookup metadata +- `warden_executes: false` + +Only `warden_executes: true` (SSH) entries may carry an authored `steps` block and +the `cert_command` pattern — because that is the lane ops-warden owns. A CI test +(WP-0011 T5) enforces this structurally: non-SSH entries with a `steps` block fail. + +--- + +## Tasks + +### T1 — INTENT wording + +```task +id: WARDEN-WP-0010-T01 +status: done +priority: high +state_hub_task_id: "589081a6-d1f5-47b4-bec0-e82d9c3444f4" +``` + +- [x] `INTENT.md` — keep "operational access steward"; replaced the "operational + access **desk**" phrasing with plain "issues SSH certs and routes everything + else to its owner." Removed metaphors implying a wrapping service. +- [x] Non-goals: added "duplicating or restating another subsystem's procedure." +- [x] Cross-linked this workplan from the assessment note. + +> SCOPE.md (A3 → A4 plain statement + "issue vs route" table) is handled as a +> deliberate manual step **after** the loop retires, not as a ralph task. + +### T2 — Routing-role wiki page + +```task +id: WARDEN-WP-0010-T02 +status: done +priority: high +state_hub_task_id: "9ac333f7-5fc4-4fa2-82f3-d5ece8ff0d92" +``` + +- [x] Create `wiki/AccessRouting.md` — what ops-warden answers (where + who owns + it), what it executes (SSH only), anti-patterns (no `warden secret`, + `warden login`, `warden policy`), and audience notes. +- [x] Include the **issue-vs-route** matrix (subsystem × ops-warden role × who acts). +- [x] Link from README, `CredentialRouting.md`, `NetKingdomSecurityMap.md`. + +### T3 — Pointer catalog schema + seed + +```task +id: WARDEN-WP-0010-T03 +status: done +priority: high +state_hub_task_id: "59e0f480-694a-482a-b35e-b7bc4930aa41" +``` + +- [x] Define `registry/routing/catalog.yaml` per the **No-double-source rule** above: + `id`, `title`, `need_keywords`, `owner_repo`, `subsystem`, `warden_executes`, + `wiki_ref`, `canon_ref`, `reviewed` (date), `status` (active|draft); plus + `steps` + `cert_command` **only** when `warden_executes: true`. +- [x] Seed from existing WP-0006 scenarios: SSH cert (executes), OpenBao API key, + flex-auth policy, key-cape OIDC, ops-bridge tunnel, railiance-infra principals. +- [x] Add `issue-core-ingestion-api-key` as `status: draft` (owner path TBD by + railiance-platform) — draft entries are not surfaced by default lookup. +- [x] Validated: 6 active + 1 draft, no non-SSH `steps`, every `wiki_ref` anchor resolves. + +### T4 — Routing index in CredentialRouting.md + +```task +id: WARDEN-WP-0010-T04 +status: done +priority: medium +state_hub_task_id: "aabd28c0-db2d-4267-be98-95be272c687d" +``` + +- [x] Add a playbook index table to `wiki/CredentialRouting.md` keyed to catalog `id`. +- [x] Add "what ops-warden answers vs what the worker does next on the owner system" + examples — without restating the owner's procedure. +- [x] Refresh the duplicate-interface anti-examples section (points at canonical + anti-pattern table; not restated). + +### T5 — Registry and repo-boundary alignment + +```task +id: WARDEN-WP-0010-T05 +status: done +priority: medium +state_hub_task_id: "3335a689-922c-4319-98d0-4263ab13790b" +``` + +- [x] Update `registry/capabilities/capability.security.ssh-certificate-issuance.md` + — note routing lookup in discovery; target availability notes the routing CLI. +- [x] Update `.claude/rules/repo-boundary.md` and `AGENTS.md` one-liner (no new + metaphor — "issues SSH certs; routes other credential needs to their owner"). +- [x] Extend the existing capability entry rather than minting a second capability. + +--- + +## Acceptance + +- A reader of INTENT + `wiki/AccessRouting.md` understands ops-warden **issues** SSH + certs and **routes** everything else, with no implication it proxies any API. +- `registry/routing/catalog.yaml` exists with ≥6 active scenarios; every non-SSH + entry has `wiki_ref` + `canon_ref` and **no** authored `steps`. +- No new secret-storage or foreign-API code. + +--- + +## See also + +- `INTENT.md` · `SCOPE.md` +- `history/2026-06-18-access-routing-intent-shift-assessment.md` — decision record +- `WARDEN-WP-0011` — routing CLI +- `WARDEN-WP-0012` — scenario playbook expansion (backlog) +--- + +## Closeout (2026-06-24) + +Archived during WARDEN-WP-0013 T2. All tasks complete. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0011-routing-guide-cli.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0011-routing-guide-cli.md new file mode 100644 index 00000000..3fe363e9 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0011-routing-guide-cli.md @@ -0,0 +1,163 @@ +--- +id: WARDEN-WP-0011 +type: workplan +title: "Routing Lookup CLI" +domain: infotech +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 11 +created: "2026-06-18" +updated: "2026-06-24" +state_hub_workstream_id: "0a520f8e-01b4-48f1-9af3-2f3f69fd0672" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0011 — Routing Lookup CLI + +**Scope:** A `warden route` command group that reads the pointer catalog and tells +a worker which subsystem owns a need, what the prerequisites are, and which +wiki/canon doc to follow **on that system**. ops-warden does not call OpenBao, +flex-auth, or key-cape on the worker's behalf. + +**Out of scope:** HTTP API; live probes against any subsystem; secret generation or +retrieval; a separate health/precondition command (see "Dropped" below); replacing +subsystem CLIs. + +**Depends on:** WARDEN-WP-0010 T3 (catalog schema + seed). + +**Unlocks:** Agents run `warden route show --json` instead of re-deriving +routing from wiki prose each session. + +--- + +## Target CLI + +```text +warden route list [--json] [--tag ] +warden route show [--json] +warden route find [--json] # keyword match against need_keywords +``` + +`list`/`find` show only `status: active` entries by default (`--all` includes draft). + +### Behaviour + +| Command | Does | Does not | +| --- | --- | --- | +| `list` / `show` | Return owner, wiki/canon pointers, `warden_executes`, anti-patterns | Return secret material | +| `find` | Rank scenarios by keyword overlap | Invoke any external API | + +When `warden_executes: true` (SSH), `show` appends the catalog's authored `steps` +and the `warden sign` / `cert_command` pattern, plus a local precondition hint +("actor in inventory? backend configured? run `warden status`"). For all other +scenarios `show` ends with **"next action on `` — see ``"** +and never implies warden performed anything. + +### Dropped: separate `check` command + +The earlier draft had `warden coach check`. Cut. For SSH, `warden status` already +covers local preconditions; duplicating it invites scope creep toward probing +foreign subsystems. SSH precondition hints live inside `show` instead. + +--- + +## Tasks + +### T1 — Catalog loader and models + +```task +id: WARDEN-WP-0011-T01 +status: done +priority: high +state_hub_task_id: "55b8422c-ad3c-4084-9e00-acaa4c360906" +``` + +- [x] Add `src/warden/routing/` package: `models.py`, `catalog.py`. +- [x] Load and validate `registry/routing/catalog.yaml`. +- [x] Enforce the no-double-source rule: non-SSH entries with a `steps` block are a + validation error. Clear errors for missing file, schema violations, dup `id`. + +### T2 — `warden route list` and `show` + +```task +id: WARDEN-WP-0011-T02 +status: done +priority: high +state_hub_task_id: "60b679c5-79bd-4186-b5a6-ac576931f06c" +``` + +- [x] Register `route` Typer sub-app on the main CLI. +- [x] `list` — Rich table + `--json` array of summaries; active-only unless `--all`. +- [x] `show` — owner, prerequisites, pointers (`wiki_ref`, `canon_ref`), + `warden_executes`, anti-patterns; SSH entries also append `steps` + cert pattern. +- [x] Exit 1 with a `find` hint when `show` id is unknown. + +### T3 — `warden route find` + +```task +id: WARDEN-WP-0011-T03 +status: done +priority: high +state_hub_task_id: "d307701f-0117-44f0-80fd-ca6f7ae06f42" +``` + +- [x] Tokenize query; match against `need_keywords`, `title`, `id`. +- [x] Rank, show top matches (default 5); `--json` for agents. +- [x] Fixtures: "issue core api key", "ssh tunnel", "openrouter key". + +### T4 — Tests + +```task +id: WARDEN-WP-0011-T04 +status: done +priority: high +state_hub_task_id: "00a76e0f-8ab6-4f9a-ac6a-00eae633342c" +``` + +- [x] `tests/test_routing.py` — catalog load, no-double-source validation rejects a + non-SSH `steps` block, find ranking, show JSON shape, SSH `show` includes cert + pattern. +- [x] No integration test requires a live subsystem. + +### T5 — Doc consistency + drift guard + +```task +id: WARDEN-WP-0011-T05 +status: done +priority: high +state_hub_task_id: "bf848375-eca7-4116-bb1d-fb7df6395c70" +``` + +- [x] CI/test: every `wiki_ref` anchor resolves to an existing in-repo wiki section; + every entry has a `reviewed` date. +- [x] `wiki/AccessRouting.md` — CLI section with agent-oriented examples. +- [x] README — `warden route --help` quick reference. +- [x] Bump SCOPE availability note A3 → A4 on ship. + +--- + +## Acceptance + +- `uv run warden route find "issue core api key"` returns the draft scenario only + with `--all`, and never a generated key. +- `uv run warden route show ssh-cert-host-access --json` includes + `warden_executes: true` and the cert_command pattern. +- A non-SSH catalog entry carrying a `steps` block fails `test_routing.py`. +- `uv run pytest tests/test_routing.py` passes with no live-subsystem dependency. + +--- + +## See also + +- `WARDEN-WP-0010` — charter and catalog schema +- `WARDEN-WP-0012` — expanded per-scenario playbooks +- `history/2026-06-17-intent-scope-assessment.md` — prior `warden guide` proposal (P4) +--- + +## Closeout (2026-06-24) + +Archived during WARDEN-WP-0013 T2. All tasks complete. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0013-production-integration-and-stewardship-closeout.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0013-production-integration-and-stewardship-closeout.md new file mode 100644 index 00000000..9812e11e --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260624-WARDEN-WP-0013-production-integration-and-stewardship-closeout.md @@ -0,0 +1,204 @@ +--- +id: WARDEN-WP-0013 +type: workplan +title: "Production Integration & Stewardship Closeout" +domain: infotech +repo: ops-warden +status: archived +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 13 +depends_on_workplans: + - WARDEN-WP-0008 + - WARDEN-WP-0009 + - WARDEN-WP-0010 + - WARDEN-WP-0011 +related_workplans: + - WARDEN-WP-0012 + - FLEX-WP-0007 +created: "2026-06-24" +updated: "2026-06-24" +state_hub_workstream_id: "4678c41a-c1d0-48cd-9988-4ea0380e8258" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0013 — Production Integration & Stewardship Closeout + +## Purpose + +Close the remaining **ops-warden-owned** gaps after policy gate and routing shipped: +refresh INTENT/SCOPE canon, archive finished workplans, document ops-bridge +`cert_command` migration, operator OpenBao token hygiene, principals drift checks, +and the policy-gate production flip checklist. + +This workplan addresses the deferred **Production SSH Integration Closeout** strand +from `history/2026-06-18-post-wp0008-intent-scope-reassessment.md` §6, updated for +post-WP-0009 state. + +**Gap analysis:** `history/2026-06-24-intent-scope-gap-analysis.md` + +## Scope + +- Post-WP-0009 reassessment and SCOPE alignment +- Archive hygiene for WP-0010 and WP-0011 +- ops-bridge `cert_command` migration documentation (pilot `agt-state-hub-bridge`) +- Operator runbook for scoped OpenBao tokens (no root in `VAULT_TOKEN`) +- Principals drift check between warden inventory and railiance-infra +- Policy gate production enablement checklist (coordinate FLEX-WP-0007) + +## Out of scope + +- flex-auth runtime deployment (flex-auth **FLEX-WP-0007**) +- ops-bridge tunnel config changes in the ops-bridge repo (coordinate only) +- Routing scenario playbook expansion (**WARDEN-WP-0012** — parallel track) +- OpenBao cluster deploy, flex-auth policy authoring, NK-WP-0009 tutorial +- Implementing secret vending or foreign API proxies + +## Ownership boundary + +| Concern | Owner | +| --- | --- | +| cert_command migration playbook | ops-warden (doc); ops-bridge (tunnel config) | +| OpenBao token hygiene runbook | ops-warden (doc); operator (execution) | +| Principals drift | ops-warden (check doc/script); railiance-infra (host deploy) | +| `policy.enabled: true` flip | operator (after FLEX-WP-0007) | + +--- + +## T1 — Post-gap reassessment and SCOPE refresh + +```task +id: WARDEN-WP-0013-T01 +status: done +priority: high +state_hub_task_id: "de46f9a2-bf11-4651-a23c-430c63f396c8" +``` + +- [x] Write `history/2026-06-24-intent-scope-gap-analysis.md` +- [x] Update `SCOPE.md` active workplan table (WP-0013, WP-0012 ready) +- [x] Note maturity vector and partial INTENT criterion (ops-bridge) in SCOPE + +**Acceptance:** Gap analysis on file; SCOPE reflects 2026-06-24 repo state. + +--- + +## T2 — Archive hygiene (WP-0010, WP-0011) + +```task +id: WARDEN-WP-0013-T02 +status: done +priority: medium +state_hub_task_id: "1b35321d-63ad-40da-a1aa-0b66190a0733" +``` + +- [x] Move `WARDEN-WP-0010-access-routing-charter.md` to + `workplans/archived/260624-WARDEN-WP-0010-access-routing-charter.md` +- [x] Move `WARDEN-WP-0011-routing-guide-cli.md` to + `workplans/archived/260624-WARDEN-WP-0011-routing-guide-cli.md` +- [x] Set frontmatter `status: archived` on both; add closeout notes +- [x] Operator runs `make fix-consistency REPO=ops-warden` from `~/state-hub` + +**Acceptance:** Only WP-0012 (ready) and WP-0013 (active when started) remain in +`workplans/` root; hub synced. + +--- + +## T3 — ops-bridge cert_command migration playbook + +```task +id: WARDEN-WP-0013-T03 +status: done +priority: high +state_hub_task_id: "ad8588b2-9ae9-4f94-bd77-8025851a38f5" +``` + +- [x] Write `wiki/playbooks/ops-bridge-tunnel-cert.md` — static-key → `cert_command` + migration checklist for tunnel configs +- [x] Document pilot tunnel `agt-state-hub-bridge`: actor, pubkey path, cert_command + string, inventory prerequisites +- [x] Upgrade catalog entry `ops-bridge-tunnel` `wiki_ref` to the new playbook +- [x] Coordinate with ops-bridge owner for pilot tunnel config change (State Hub message) +- [ ] Record non-secret smoke evidence when pilot completes (`history/` entry — pending ops-bridge) + +**Acceptance:** Playbook exists; catalog points at it; pilot steps documented even +if ops-bridge execution is pending. + +**Unlocks:** INTENT success criterion #3 moves from partial toward met. + +--- + +## T4 — Operator OpenBao token hygiene runbook + +```task +id: WARDEN-WP-0013-T04 +status: done +priority: medium +state_hub_task_id: "5cb35829-32eb-4d59-97a1-f4d92ce8e239" +``` + +- [x] Add `wiki/playbooks/operator-openbao-token-hygiene.md` covering scoped tokens, + `VAULT_TOKEN` session pattern, OIDC route, HTTP 403 recovery +- [x] Cross-link from `wiki/OpsWardenConfig.md` and production example yaml + +**Acceptance:** Operator can follow runbook without asking ops-warden for token values. + +--- + +## T5 — Principals inventory drift check + +```task +id: WARDEN-WP-0013-T05 +status: done +priority: medium +state_hub_task_id: "4025cd32-89f8-42c3-b1e8-eaf78497d91f" +``` + +- [x] `scripts/check_principals_drift.py` compares inventory `hosts` vs + `railiance-infra/ansible/inventory/ssh_principals.yaml` +- [x] Script notes flex-auth registry regeneration via `build_flex_auth_registry.py` +- [x] Tests in `tests/test_principals_drift.py` + +**Acceptance:** Drift check runnable or documented; no secret material in script output. + +--- + +## T6 — Policy gate production enablement checklist + +```task +id: WARDEN-WP-0013-T06 +status: done +priority: medium +state_hub_task_id: "51663f65-79cb-4108-87c8-9721f9476259" +``` + +- [x] Operator checklist in `wiki/PolicyGatedSigning.md` § Production rollout +- [x] Cross-link FLEX-WP-0007 and pickup brief +- [x] Explicit: keep `policy.enabled: false` until flex-auth reachable + +**Acceptance:** Operator checklist is sequential and references cross-repo owners; +no ops-warden code changes required for flex-auth deploy. + +--- + +## Exit criteria + +- Gap analysis and SCOPE current +- WP-0010 and WP-0011 archived +- ops-bridge cert_command playbook + catalog upgrade +- Operator token hygiene runbook +- Principals drift procedure +- Policy gate production flip checklist (coordinate FLEX-WP-0007) + +## Parallel track + +**WARDEN-WP-0012** (routing scenario playbooks) — promoted to `ready`; start when +P1 integration doc bandwidth allows or in parallel if staffed. + +## See also + +- `history/2026-06-24-intent-scope-gap-analysis.md` +- `history/2026-06-18-post-wp0008-intent-scope-reassessment.md` +- `wiki/CertCommandInterface.md` +- `~/flex-auth/workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0012-routing-scenario-playbooks.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0012-routing-scenario-playbooks.md new file mode 100644 index 00000000..acf9cce9 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0012-routing-scenario-playbooks.md @@ -0,0 +1,147 @@ +--- +id: WARDEN-WP-0012 +type: workplan +title: "Routing Scenario Playbooks" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: medium +planning_order: 12 +created: "2026-06-18" +updated: "2026-06-24" +state_hub_workstream_id: "a7e712a0-02f8-4f83-944e-6b207e77bc4c" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0012 — Routing Scenario Playbooks + +**Scope:** Grow the routing catalog and wiki playbooks for high-frequency NetKingdom +access scenarios. Each wiki playbook restates **what the worker does on the owning +system** and tracks an upstream canon doc; the catalog only points at it. ops-warden +authors procedure only for the SSH lane. + +**Out of scope:** Implementing custody in ops-warden; creating OpenBao paths in +railiance-platform (coordinate only); authoring flex-auth policy; restating an +owner's procedure inside the catalog. + +**Depends on:** WARDEN-WP-0010 (charter + catalog schema), WARDEN-WP-0011 (routing CLI). + +**Status:** `finished` — playbooks shipped; draft entries await owner path promotion. + +--- + +## Anti-stale rule + +A scenario is added to the catalog as `status: active` **only when its owning repo's +path actually exists** and a `wiki_ref` is written. Until then it stays `status: +draft` and is hidden from default `warden route find`/`list`. We do not seed +agent-visible entries for paths that owners have not shipped — a confident-looking +pointer to a non-existent path is worse than no entry. + +--- + +## Scenario backlog + +| Catalog id | Routing focus | Executing owner | Gate | +| --- | --- | --- | --- | +| `issue-core-ingestion-api-key` | OpenBao KV path, K8s injection, rotation | railiance-platform + issue-core | path exists | +| `activity-core-issue-sink` | `ISSUE_CORE_URL` + consumer key custody | activity-core + issue-core | path exists | +| `inter-hub-bootstrap-ssh` | SSH envelope + on-host wrapper reads OpenBao | ops-warden SSH + railiance-infra | ready (SSH lane) | +| `openrouter-llm-connect` | OpenBao → K8s Secret in activity-core | railiance-platform | path exists | +| `object-storage-sts` | NK-WP-0007 vending path | net-kingdom + flex-auth + OpenBao | canon exists | +| `ops-bridge-tunnel-cert` | cert_command vs static-key migration | ops-bridge | done (WP-0013) | +| `human-oidc-login` | key-cape / Keycloak IAM Profile | key-cape | canon exists | +| `flex-auth-resource-check` | Policy decision before sensitive action | flex-auth | canon exists | +| `host-principal-deploy` | auth_principals sync | railiance-infra | canon exists | + +--- + +## Tasks + +### T1 — issue-core ingestion key playbook + +```task +id: WARDEN-WP-0012-T01 +status: done +priority: high +state_hub_task_id: "830bb512-0288-4dba-9dd4-ccfd28a4921f" +``` + +- [x] Coordinate with railiance-platform to canonicalize the OpenBao path first. + (Documented expected path from `railiance-platform/docs/argocd-gitops.md`; + live KV path not yet shipped — promotion blocked per anti-stale rule.) +- [x] Then write `wiki/playbooks/issue-core-ingestion-api-key.md` (prerequisites, + ESO pattern, rotation, privileged-read policy) and promote the catalog entry + from `draft` to `active` with a `wiki_ref`. (Playbook + `wiki_ref` done; + stays `draft` until path ships.) + +### T2 — Inter-Hub and bootstrap lanes + +```task +id: WARDEN-WP-0012-T02 +status: done +priority: medium +state_hub_task_id: "7726a703-6e00-4e49-9380-ed3fb3268827" +``` + +- [x] Align `wiki/InterHubBootstrapAccessLane.md` with catalog id `inter-hub-bootstrap-ssh` +- [x] Document attended vs unattended bootstrap branches +- [x] Cross-link flex-auth and OpenBao expectations (pointers, not restated steps) +- [x] Promote catalog entry to `active` with `wiki_ref` + +### T3 — ops-bridge tunnel migration + +```task +id: WARDEN-WP-0012-T03 +status: done +priority: medium +state_hub_task_id: "9fb397f0-0abb-48f5-bb62-7e77edae93bb" +``` + +- [x] Playbook: `wiki/playbooks/ops-bridge-tunnel-cert.md` (WARDEN-WP-0013) +- [x] Pilot tunnel `agt-state-hub-bridge` documented; ops-bridge coordination sent + +### T4 — Platform secret scenarios (LLM, STS, DB) + +```task +id: WARDEN-WP-0012-T04 +status: done +priority: low +state_hub_task_id: "edcf4ed7-f18d-4a92-a42d-8cc7ca0ab792" +``` + +- [x] Playbooks for OpenRouter, object-storage STS, DB dynamic creds. +- [x] Each ends with an owner-repo action; no warden secret code; pointers to canon. + +### T5 — Drift review cadence + +```task +id: WARDEN-WP-0012-T05 +status: done +priority: low +state_hub_task_id: "db98d655-8551-487b-9413-41bf97fc06e1" +``` + +- [x] Document a review cadence against net-kingdom canon. +- [x] `warden route list --stale` keyed off the `reviewed:` date field. +- [x] Process note in `wiki/AccessRouting.md`. + +--- + +## Acceptance + +- Every active catalog entry has a `wiki_ref` to an existing section; no active entry + points at a path its owner has not shipped (those stay `draft`). +- `warden route find` resolves common agent queries without wiki grep. +- Playbooks and catalog contain no secret material — only owners, pointers, checklists. + +--- + +## See also + +- `WARDEN-WP-0010`, `WARDEN-WP-0011` +- `wiki/CredentialRouting.md` +- `history/2026-06-18-post-wp0008-intent-scope-reassessment.md` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0014-operator-access-assist.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0014-operator-access-assist.md new file mode 100644 index 00000000..01240484 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0014-operator-access-assist.md @@ -0,0 +1,215 @@ +--- +id: WARDEN-WP-0014 +type: workplan +title: "Operator Access Assist — warden access front door" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 14 +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "3c30b2ed-6ede-4b95-a438-fde6da6f6633" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0014 — Operator Access Assist (`warden access`) + +**Scope:** Make ops-warden the consistent operator-facing front door for **every** +NetKingdom security/access need — not just the SSH lane. Add a `warden access` +command surface that (a) advises: emits the auth method, path, policy context, and +exact command skeleton for any credential need, and (b) **proxies**: transparently +fetches the value from the owning subsystem *as the caller* and streams it to the +operator's destination, **without ops-warden ever persisting, caching, or logging +the secret, and without ops-warden holding any standing privileged credential.** + +Centralize **knowledge and policy** in ops-warden; leave **custody and execution +detail** in the owning subsystems (OpenBao, key-cape, flex-auth). ops-warden becomes +a transparent, policy-gated, audited conduit — `vault exec` / `op run` shaped — never +a standing secret broker. + +**Charter note:** This extends the WP-0010 routing charter from a *pointer layer* +("who owns it") to an *assist layer* ("here is exactly how to get it, gated and +audited"). It does **not** move custody into ops-warden. See the three non-negotiable +guardrails below — they are the line between a transparent conduit (sanctioned) and a +standing broker/honeypot (forbidden). + +**Out of scope:** +- ops-warden holding a long-lived OpenBao/secret-read token of its own. +- Persisting, caching, or logging any secret **value** anywhere (disk, log, hub, git). +- Creating OpenBao paths or policies (coordinate with railiance-platform / flex-auth). +- Restating an owner's procedure as prose in the catalog (reference canon, don't copy). +- Identity/MFA implementation (key-cape owns it; we orchestrate its CLI only). + +**Depends on:** WP-0010 (charter + catalog schema), WP-0011 (`warden route` CLI), +WP-0007/0009 (flex-auth policy gate — reused as the fetch-path gate). + +**Status:** `proposed` — awaiting Bernd's review before implementation. + +--- + +## Three non-negotiable guardrails (acceptance-blocking) + +These are the design invariants that keep proxy mode safe. Any task that violates one +is rejected regardless of convenience. + +1. **Operator identity, never warden's.** `--fetch`/`--exec` authenticate as the + *caller* (their OIDC/OpenBao token, the agent's own auth). ops-warden carries **no** + standing secret-read credential. If the caller has no valid auth, the command fails + with a routing pointer to the auth step — it does not fall back to a warden token. + +2. **Transit only — no persistence, no logging of values.** The secret flows + subsystem → caller destination (env of a child process, or stdout) via a streamed + `exec`. ops-warden must not buffer it to disk, cache it, echo it to logs, or write + it to the State Hub. Audit records **metadata only** (who, need id, owner path, time, + policy decision id) — never the value. + +3. **Policy gate on the fetch path.** `--fetch`/`--exec` run the flex-auth check + **before** proxying (reusing the WP-0007 gate). When `policy.enabled: false`, fetch + is **advisory-only** by default and requires an explicit `--no-policy` acknowledgement + to proxy ungated — surfaced loudly in output and audit. + +--- + +## Phasing decision (default — adjust in review) + +OpenBao lane **first** (covers the immediate npm/API/DB need), key-cape/login lane in +a later task within the same WP. Rationale: OpenBao KV is the highest-frequency operator +need and the one this conversation surfaced; login flows are a thinner orchestration of +an interactive tool and lower risk to defer. + +--- + +## Tasks + +### T1 — Catalog schema: structured handoff fields + +```task +id: WARDEN-WP-0014-T01 +status: done +priority: high +state_hub_task_id: "abb0e722-6524-4224-8638-6ee1573ed3e0" +``` + +- [x] Extend `registry/routing/catalog.yaml` entry schema with optional structured + handoff fields for non-SSH lanes: `auth_method`, `path_template`, + `fetch_command`, `exec_capable` (bool), `policy_ref`. (`RouteEntry` + + `_parse_entry`; `has_handoff` helper.) +- [x] Fields are **structured pointers/templates**, not prose restatements — each + sits alongside the owner's `canon_ref` for the authoritative procedure (no drift). +- [x] Populate for `openbao-api-key` (covers the coulomb_social npm shape: keyword + `npm_auth_token` added) as the reference example; `draft` entries untouched. +- [x] Validation: `_assert_no_secret_material` rejects known token prefixes and + high-entropy runs in any handoff field; `exec_capable` requires `fetch_command`. + Tests in `tests/test_routing.py` (handoff parse, real-catalog, secret-leak + matrix, placeholder-accepted). + +### T2 — `warden access` advisory surface + +```task +id: WARDEN-WP-0014-T02 +status: done +priority: high +state_hub_task_id: "c1497263-7124-459f-b63a-d0c0c7005c86" +``` + +- [x] `warden access [--domain X] [--json]` — resolves via the same matcher as + `warden route find` and renders the **structured handoff**: owner, auth method, + path template, command skeleton, policy ref + gate status, proxy hint, and the + `<…>` owner-confirmed-name note. (`warden/access.py` pure module + `access` + command in `cli.py`.) +- [x] Advisory is the **default** behavior (no value fetched); SSH lane points at + `warden sign`; routed lanes end with "warden advises, the owner vends". +- [x] `--json` output for agentic operators — stable, secret-free shape + (`handoff` block + `next_action`); `--domain` substitutes `` only. +- [x] Tests: `tests/test_access.py` (expansion, gate status, advisory/SSH/JSON/no-match). + +### T3 — OpenBao proxy lane (`--fetch` / `--exec`) + +```task +id: WARDEN-WP-0014-T03 +status: done +priority: high +state_hub_task_id: "6d3eb0e4-309c-4065-893e-6c4053fb0db2" +``` + +- [x] `warden access --fetch` — policy-gate (G3) → run the owning tool + (`bao kv get ...`) **as the caller** with **inherited stdout** → value streams to + stdout and never enters warden's memory (`proxy_fetch`). No buffering, no log. +- [x] `warden access --exec -- ` — runs the child with the secret injected + into *its* env only (`proxy_exec`); value never lands in the caller's shell env; + `--field` names the env var (e.g. `NPM_AUTH_TOKEN`). +- [x] Guardrails G1–G3 in code (`warden/proxy.py`, `_access_proxy` in `cli.py`): + G1 caller token only (no warden credential; `caller_auth_present`); G2 transit-only + (inherit-stdout fetch; no disk/log write); G3 `check_fetch_policy` before any exec, + `--no-policy` required to proxy ungated. `tests/test_proxy.py` asserts all three, + plus `resolve_fetch_command` refuses unresolved `<…>` placeholders. Live smoke + against a fake `bao` confirmed gate-refusal, stream, exec-inject, and a + secret-free audit log. +- [x] Metadata-only audit per call (`write_audit` → `state_dir/access-audit.log`). + +### T4 — key-cape / login orchestration lane + +```task +id: WARDEN-WP-0014-T04 +status: done +priority: medium +state_hub_task_id: "481997e4-193d-4724-84a6-61cbc2940153" +``` + +- [x] Extend `warden access` to orchestrate the key-cape/Keycloak OIDC login flow + under the same advisory/proxy split. New `lane: secret|login` field on + `RouteEntry`; `key-cape-oidc-login` populated as a `login` lane entry. +- [x] Login lane semantics: no caller-auth precheck (you have no token yet) and no + secret-read gate (it bootstraps the identity the gate needs); runs interactively + as the caller via inherited stdio; `--exec` rejected. Token stays in the caller's + own store — warden never captures it (G2 holds). Audited as `action: login`. +- [x] Tests in `tests/test_proxy.py` (runs without token/ack, rejects --exec, real + catalog lane, invalid-lane rejection). Live fake-`bao login` smoke confirmed. + +### T5 — Docs, security model, and INTENT/SCOPE alignment + +```task +id: WARDEN-WP-0014-T05 +status: done +priority: medium +state_hub_task_id: "a5eb616e-4edf-42db-a4fb-bf296cdb92bc" +``` + +- [x] `wiki/OperatorAccessAssist.md` — the `warden access` contract, the conduit-vs-broker + boundary, and the three guardrails (+ the catalog secret-material guard) as a + security-model statement; lanes documented. +- [x] Updated `wiki/AccessRouting.md` (issue/route/**assist** roles + reconciled the + anti-patterns table so the conduit doesn't contradict it) and the + `.claude/rules/credential-routing.md` agent rule (added `warden access` + the + "standing broker forbidden, transparent `--fetch` sanctioned" anti-pattern). +- [x] SCOPE/INTENT: recorded the pointer→assist charter extension; SCOPE implemented + list + Getting Oriented updated; maturity vector A4 → **A5** on Availability. +- [x] `history/2026-06-27-operator-access-assist-charter.md` — decision record. + +--- + +## Acceptance + +- `warden access ` advises for any catalog need; `--fetch`/`--exec` proxy the + OpenBao lane end to end against a real KV path. +- All three guardrails hold under test: **no** secret value touches disk/log/hub/git; + ops-warden holds **no** standing secret-read credential; the policy gate runs **before** + every fetch. +- Catalog carries structured handoff fields that reference (never restate) owner canon. +- Docs state the conduit-vs-broker boundary explicitly; the agent rule forbids the + broker pattern. +- No secret material anywhere in code, catalog, docs, logs, or tests. + +--- + +## See also + +- `WARDEN-WP-0010` (routing charter), `WARDEN-WP-0011` (`warden route` CLI) +- `WARDEN-WP-0007` / `WARDEN-WP-0009` (flex-auth policy gate — reused as fetch gate) +- `wiki/AccessRouting.md`, `wiki/CredentialRouting.md`, `wiki/PolicyGatedSigning.md` +- `.claude/rules/credential-routing.md` +- `history/2026-06-24-intent-scope-gap-analysis.md` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0015-secret-lifecycle-tiering.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0015-secret-lifecycle-tiering.md new file mode 100644 index 00000000..c5920789 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260627-WARDEN-WP-0015-secret-lifecycle-tiering.md @@ -0,0 +1,247 @@ +--- +id: WARDEN-WP-0015 +type: workplan +title: "Workload Security Posture — env posture × maturity + conformance" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 15 +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "99f4a0e1-853c-456f-8aa7-8ff0f318ea65" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# WARDEN-WP-0015 — Workload Security Posture (two-axis) + conformance + +**Scope:** Establish a NetKingdom standard for IT-security posture across **two +orthogonal axes**, and make ops-warden the **conformance steward** for it: + +- **Axis A — Environment posture** (`dev → test → prod`): how the *secret store* is + secured (mock / OpenBao `-dev` / sealed). Identical contracts, divergent posture. +- **Axis B — Workload maturity** (`M0 → M3`): how *trusted* a workload is to receive + secrets and handle classified data (PoC → alpha/early-access → beta/GA → critical). + +The axes combine in a **secret-flow lattice**: a secret may be delivered to a workload +only if the workload's posture *and* maturity meet the secret's requirements. ops-warden +authors the ops-security slice, ships machine-readable descriptors + a conformance +checker (incl. the lattice check), and the dev-tier **contract-double** fixture library +(the "fake bao" pattern generalized). + +**Decisions locked (2026-06-27):** +- Two-axis model folded into this WP (was "Secret Lifecycle Tiering", env posture only). +- Authoritative **NetKingdom requirements** (M0–M3 table, secret-flow gates, env-posture + ceremonies) live in **net-kingdom canon**; the **generic `WorkloadMaturityLevel` + concept + lattice** is contributed to **info-tech-canon** (DevSecOps/Landscape), + reusing its governed `DataClassification`. ops-warden authors the ops-security slice + + conformance tooling. +- ops-warden role = **author + conformance checks**, **not** runtime enforcement. + +**Reuse, don't reinvent (info-tech-canon already defines the primitives):** +`DataClassification` (`confidential`/`restricted`…) in the Data Model; promotion / +quality gates / policy gates / `DeploymentVerification` + progressive delivery in the +DevSecOps Model; asset/business **criticality** in the Security Model; access semantics +in the CARING Access Governance Standard. This WP **assembles** these into a named +maturity ladder + flow rule; it does not fork them. + +**Hard boundary (responsibility-map, ~line 154):** ops-warden "must not become a +universal secret broker — runtime secrets remain OpenBao; authorization remains +flex-auth." ops-warden = policy author + conformance verifier only. OpenBao holds the +secrets; flex-auth makes allow/deny decisions; CARING governs access semantics. + +**Cross-repo note:** T1/T5 author content destined for **net-kingdom** and +**info-tech-canon**. ops-warden drafts; landing it is coordinated through each repo's +own process (inbox/PR), not a unilateral write from here. + +**Depends on / relates to:** WARDEN-WP-0014 (the `warden access` proxy is the +posture-aware fetch surface; its caller-identity/transit guardrails are prod-compatible). + +**Status:** `finished` — all five tasks done. T1 authored the standard, T2 shipped the +descriptors + `warden policy`, T3 the read-only conformance checker, T4 the dev-double +library, T5 the INTENT/SCOPE alignment. Canon landing in net-kingdom / info-tech-canon +is owner-driven and tracked via the open coordination messages (not closed here). + +--- + +## The model (to be encoded by this WP) + +### Axis A — Environment posture (the secret store) + +**R1 — Contract parity, posture divergence.** Identical interface at every tier; only +the backend's security posture changes. Automation written once runs at all tiers +unchanged (this is why contract doubles work). +**R2 — Promote topology, regenerate material.** Secret *values* are never promoted up +the ladder; only *structure* (paths, policy shape, names). Values are generated fresh +per tier. Test conveniences (reuse, single-unseal) are quarantined in test. +**R3 — Dev touches no real data, ever.** Insecure personal mock store is sanctioned +*iff* dev uses only synthetic data. Absolute. +**R4 — Phase-changes are ceremonies, not copies.** test→prod is a gated checklist +referencing net-kingdom `security-bootstrap-*` / unseal-custody docs. + +| | dev | test | prod | +| --- | --- | --- | --- | +| backend | mock / contract double | OpenBao `-dev` (single-unseal) | OpenBao sealed (Shamir 3-of-5) | +| real values | forbidden (synthetic) | generated, reuse allowed | generated fresh, reuse forbidden | +| unseal | n/a | single key / auto | 3-of-5 + break-glass | +| real user/business data | never | never | allowed | +| audit | optional | on | full, tamper-evident | + +### Axis B — Workload maturity (the trust to receive secrets/data) + +**Production is a posture, not a maturity.** A workload can be prod-posture yet low +maturity (alpha with friendly customers). Maturity gates *which secrets and data +classes* a prod workload may touch. + +| Level | Phase | Max DataClassification | Promotion gate (reuses DevSecOps gates) | +| --- | --- | --- | --- | +| **M0** | Experimental / PoC | synthetic only | — | +| **M1** | Alpha / early-access | low-criticality, loss-acceptable; no confidential/restricted | friendly-customer scope, basic SLO, data-handling note | +| **M2** | Beta / GA | up to `confidential`; SLOs; audited | security review, SLO history, on-call, incident runbooks | +| **M3** | Critical / regulated | `restricted`; break-glass; compliance | pen-test, 3-of-5 custody, human-in-loop, compliance audit | + +### The combined rule (secret-flow lattice) + +``` +deliver(secret → workload) permitted only if + workload.env_posture == prod # Axis A +AND workload.maturity >= secret.required_maturity # Axis B (no-write-down) +AND workload.maturity >= required_maturity(dataclass(secret)) +``` + +"Critical secrets must not be transferred to workloads below maturity M" is exactly +this no-write-down constraint. Checkable by ops-warden; enforceable by flex-auth. + +--- + +## Tasks + +### T1 — Author the two-axis Workload Security Posture standard (canon-bound) + +```task +id: WARDEN-WP-0015-T01 +status: done +priority: high +state_hub_task_id: "85aeb676-a593-4056-986a-db14d4c5209f" +``` + +- [x] Drafted the standard: Axis A (R1–R4 + env-posture matrix + phase-change ceremonies) + and Axis B (M0–M3 ladder + promotion gates) unified by the secret-flow lattice — + `wiki/WorkloadSecurityPosture.md`. +- [x] Layered it: doc marks the generic `WorkloadMaturityLevel` + lattice → **info-tech-canon** + (reusing `DataClassification`) and the NetKingdom M0–M3 requirements + env-posture + ceremonies → **net-kingdom canon**, with a canon-layering table. +- [x] Cross-linked the unseal/bootstrap/responsibility canon + info-tech-canon + Security/DevSecOps/Data/CARING models. Staged in ops-warden; **coordination + opened** to net-kingdom (msg 8d6f8d83) and info-tech-canon (msg ca07b085). +- [x] Encoded ops-warden's role: author + conformance, not enforcement/custody. +- Note: canon **landing** in the two repos is owner-driven; tracked to closure in T5. + +### T2 — Machine-readable posture descriptors (both axes) + +```task +id: WARDEN-WP-0015-T02 +status: done +priority: high +state_hub_task_id: "011fb0af-154d-40f4-a03e-3172c325321a" +``` + +- [x] `registry/policy/security-posture.yaml` — env-posture tiers (backend, value-policy, + unseal, data-class, audit) **and** maturity levels (M0–M3, max DataClassification, + promotion gates), `dataclass_floor` mapping, and the lattice rule. No secret material. +- [x] Loader + validation in `src/warden/posture.py` (mirrors `routing/catalog.py`): + unique/contiguous ranks, dataclass_floor references known levels, lattice env + posture exists. Includes the pure `can_deliver` lattice helper (reused by T3). +- [x] `warden policy list|show` lookup (mirrors `warden route`; `--json`). +- [x] Tests: `tests/test_posture.py` (load, lattice allow/deny matrix, validation + rejections, CLI). 184 pass, lint clean. + +### T3 — Conformance checker (incl. secret-flow lattice) + +```task +id: WARDEN-WP-0015-T03 +status: done +priority: high +state_hub_task_id: "c1a0e987-19d0-478e-ac08-2dbe98e64e09" +``` + +- [x] `scripts/check_secret_posture_conformance.py` — asserts env-posture matches the + standard (`backend`/`unseal`/`real_values` per tier) **and** evaluates the lattice + via `posture.can_deliver`: flags any secret whose `required_maturity` or data-class + floor exceeds a target workload's maturity, or that targets a non-prod workload. + Drift-style report, like `check_principals_drift.py`. Read-only; exit 0/1/2. +- [x] Surfaces conformance + lattice violations; never reads or prints a secret value + (manifest is metadata-only). Example: `examples/posture-conformance.example.yaml`. +- [x] Tests: `tests/test_posture_conformance.py` (env mismatch, unknown env, lattice + deny/allow, missing workload, exit codes). 8 cases, lint clean. + +### T4 — Dev-tier contract-double fixture library + +```task +id: WARDEN-WP-0015-T04 +status: done +priority: medium +state_hub_task_id: "e556fd2e-4e39-4c7d-bd94-b4330e4bef45" +``` + +- [x] Generalized "fake bao" into `src/warden/doubles.py`: `materialize_doubles()` + writes hermetic dev-tier doubles for routed subsystems (`bao`, `key-cape`) + honoring each contract (argv/stdout/exit), emitting **synthetic values only** + (`synthetic-` prefix, asserted in tests). `doubles_path_prepended()` puts them + ahead on PATH for fully offline dev/test of access flows. +- [x] Documented the pattern in the standard (R1) as the sanctioned `dev` backend. +- [x] Tests: `tests/test_doubles.py` (contract honoring, synthetic-only, unknown + contract → exit 2, end-to-end proxy fetch offline against the double). 9 cases. + +### T5 — INTENT/SCOPE alignment + canon contributions + +```task +id: WARDEN-WP-0015-T05 +status: done +priority: medium +state_hub_task_id: "298c9b09-4a5a-41bf-a3bd-6c572385236b" +``` + +- [x] `INTENT.md`: ops-warden stewards **security-policy conformance** of the + infrastructure (authoring the two-axis posture standard + conformance checks + dev + doubles), scoped to author+check — **not** enforcement or custody. +- [x] SCOPE: add the posture policy + conformance surface; note the net-kingdom / + info-tech-canon homes; bump the maturity vector where warranted. +- [x] Canon landing tracked to a documented hand-off. The contributions are **drafted + and offered**: info-tech-canon (generic `WorkloadMaturityLevel` + lattice, msg + `ca07b085`) and net-kingdom (M0–M3 requirements + env-posture ceremonies, msg + `8d6f8d83`). **Landing is owner-driven and out of ops-warden's control** — it is + tracked through each repo's own inbox/PR process, not closed unilaterally here. + ops-warden's authored slice + conformance tooling are complete. +- [x] `history/2026-06-27-workload-security-posture-charter.md` — decision record. + +2026-06-27 progress: shipped the T3 conformance checker and T4 dev-double library +with tests (200 passing, lint clean); updated `INTENT.md` / `SCOPE.md` / +`wiki/WorkloadSecurityPosture.md` for the author+conformance role. Canon landing in +net-kingdom / info-tech-canon remains owner-driven via the open coordination messages. + +--- + +## Acceptance + +- A coherent two-axis standard exists: generic concept in info-tech-canon, NetKingdom + M0–M3 + env-posture requirements in net-kingdom canon, authored by ops-warden. +- ops-warden ships posture descriptors + a read-only conformance checker (incl. the + secret-flow lattice) + dev-tier doubles. +- No secret material in any descriptor, checker, fixture, doc, or log. +- ops-warden's role is documented as author+conformance; OpenBao custody, flex-auth + authorization, and CARING access boundaries are explicitly preserved. +- INTENT/SCOPE reflect the conformance-steward role without overclaiming enforcement. + +--- + +## See also + +- `WARDEN-WP-0014` (operator access assist; the posture-aware fetch surface) +- `net-kingdom/docs/openbao-unseal-custody-models.md`, `responsibility-map.md`, + `platform-root-custody.md`, `security-bootstrap-*` +- `info-tech-canon` Security / DevSecOps / Data Models + CARING Access Governance +- `flex-auth` (runtime enforcement of the lattice, as a follow-up) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260707-ADHOC-2026-07-07.md b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260707-ADHOC-2026-07-07.md new file mode 100644 index 00000000..31e9d27f --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-kernel-source-integration-r1/consistency-backup/workplans/archived/260707-ADHOC-2026-07-07.md @@ -0,0 +1,52 @@ +--- +id: WARDEN-WP-ADHOC-2026-07-07 +type: workplan +title: "Ad Hoc Tasks — 2026-07-07" +domain: infotech +repo: ops-warden +status: finished +owner: grok +topic_slug: custodian +created: "2026-07-07" +updated: "2026-07-07" +state_hub_workstream_id: "90568b1e-8395-5c67-9c69-851ed08ff3d3" +--- + +> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`). + +# Ad Hoc Tasks — 2026-07-07 + +### T01 — Roll out proxy pipe fix (be3b4a2) + +```task +id: WARDEN-WP-ADHOC-2026-07-07-T01 +status: done +priority: high +state_hub_task_id: "bf985c95-bea6-5057-94f9-9cfa7e1c9dd8" +``` + +`warden access` failed on `reuse-surface-hub-write-token` because `shlex.split` +treated `kubectl … | base64 -d` as literal argv. Fixed in `be3b4a2`; rollout +requires refreshing the installed CLI (cached `0.1.0` wheel does not pick up +source changes). + +- [x] Code fix merged and pushed (`be3b4a2`) +- [x] Version bumped `0.1.0` → `0.1.1` so `uv tool install` invalidates stale wheels +- [x] Workstation rollout: `git pull && make install-all` (after cache clean if needed) +- [x] Smoke: `warden access reuse-surface-hub-write-token --no-policy --fetch` — no + `unknown shorthand flag: 'd'`; token fetched via shell pipeline + +**Operator upgrade on any machine using `warden access`:** + +```bash +cd ~/ops-warden && git pull --ff-only +make install-all +warden route show reuse-surface-hub-write-token --json +``` + +If `warden` still lacks `ResolvedFetch` / pipe handling after install: + +```bash +uv cache clean ops-warden +uv tool install . --with-editable ../phase-memory --reinstall --force +``` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/.custodian-brief.md.backup b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/.custodian-brief.md.backup new file mode 100644 index 00000000..34573d26 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/.custodian-brief.md.backup @@ -0,0 +1,60 @@ + +# Custodian Brief — ops-warden + +**Domain:** infotech +**Last synced:** 2026-10-16 00:05 UTC +**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)* + +## Active Workstreams + +### Adopt unknown -> fail_closed behind signing-target classification coverage +Progress: 1/4 done | workplan_id: `c8ee441e-1be1-5219-910c-e79ff23cc9ec` + +**Open tasks:** +- ! Tasks `611f0901` + *(wait: Warden's own declaration cannot classify the repair-path target workloads; the owner must declare the continuity actor/target and its z2-continuity resolution (see 2026-09-28 review).)* +- ! Tasks `54ad4864` + *(wait: Owners of agt-codex-interhub-bootstrap (ops-hub) and agt-state-hub-bridge (ops-bridge) must publish authoritative workload identity declarations; atm-backup-daily declared by activity-core and compiled 2026-10-09 (z2-protected, admission unsatisfied: M1 below M2 floor).)* +- ! Tasks `93eaf1f2` + *(wait: Gated on T01 and on layer model v0.8 (or successor) reaching accepted; never convert against a proposed standard.)* + +### Layer model v0.7 conformance — state the deadline, bind the agent boundary, steward the estate's newest rule +Progress: 5/6 done | workplan_id: `ae3ff76f-883d-5e2f-b6aa-144d61e8fdef` + +**Open tasks:** +- ! Tasks `7d1b3c82` + *(wait: Two items to route, not absorb: ops-mason has published no stance map; the second is another repository's to own.)* + +### Follow through on KnownSecurityCases along their type's route +Progress: 2/4 done | workplan_id: `f7e81013-6868-5d99-8528-ba75a442eca9` + +**Open tasks:** +- ! T03 — Run and verify a case `4a0fa4a7` + *(wait: Catalog integration follows a proven run.)* +- ► T02 — Plan a case run `bcbf6c91` + +### Tamper-resistant credential governance + mass rotation/lockdown (Strand B) +Progress: 2/3 done | workplan_id: `21528e8d-a049-523d-9ae1-da7a27cb8bbf` + +**Open tasks:** +- · Task: Graded lockdown / break-glass with explicit trust-root `cae498ee` + +### Repoint the whynot-design npm lane to Forgejo +Progress: 2/3 done | workplan_id: `42a097db-1c24-558e-a724-030bb2b4443e` + +**Open tasks:** +- ! Prove routing and publication `a8b1b855` + *(wait: Hold kept by D3 until SECRETS-WP-0006-T06 moves publishing off the legacy whynot-design npm path; then rotate and prove a fresh publish.)* + +## Inbox Hygiene + +**Stale unread:** 2 message(s) older than 3 day(s) — triage at session start. +**Missing thread_id:** 3 unread message(s) lack supersession chains. + +--- +## MCP Orientation (when available) + +If the state-hub MCP server is reachable, call: +`get_domain_summary("infotech")` +This provides richer cross-domain context. +If the MCP call fails, use this file as your orientation source. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/WORK-RECORDS.md.backup b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/WORK-RECORDS.md.backup new file mode 100644 index 00000000..8b5226ae --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/WORK-RECORDS.md.backup @@ -0,0 +1,188 @@ +# Work Records — ops-warden + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | WARDEN-WP-ADHOC-2026-06-27 | finished | — | workplans/ADHOC-2026-06-27.md | +| workplan | WARDEN-WP-ADHOC-2026-06-29 | finished | — | workplans/ADHOC-2026-06-29.md | +| workplan | WARDEN-WP-ADHOC-2026-08-11 | finished | — | workplans/ADHOC-2026-08-11.md | +| workplan | WARDEN-WP-ADHOC-2026-08-17 | finished | — | workplans/ADHOC-2026-08-17.md | +| workplan | WARDEN-WP-ADHOC-2026-09-08 | finished | — | workplans/ADHOC-2026-09-08.md | +| workplan | WARDEN-WP-ADHOC-2026-10-03 | finished | — | workplans/ADHOC-2026-10-03.md | +| workplan | WARDEN-WP-0016 | finished | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| workplan | WARDEN-WP-0017 | finished | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| workplan | WARDEN-WP-0018 | finished | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| workplan | WARDEN-WP-0019 | finished | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| workplan | WARDEN-WP-0020 | finished | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| workplan | WARDEN-WP-0021 | finished | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| workplan | WARDEN-WP-0022 | finished | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| workplan | WARDEN-WP-0023 | finished | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| workplan | WARDEN-WP-0024 | finished | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| workplan | WARDEN-WP-0025 | finished | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| workplan | WARDEN-WP-0026 | finished | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| workplan | WARDEN-WP-0027 | blocked | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| workplan | WARDEN-WP-0028 | finished | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| workplan | WARDEN-WP-0029 | finished | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| workplan | WARDEN-WP-0030 | finished | — | workplans/WARDEN-WP-0030-delegation-register.md | +| workplan | WARDEN-WP-0031 | finished | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| workplan | WARDEN-WP-0032 | finished | — | workplans/WARDEN-WP-0032-security-zones.md | +| workplan | WARDEN-WP-0033 | finished | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| workplan | WARDEN-WP-0034 | active | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| workplan | WARDEN-WP-0035 | finished | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| workplan | WARDEN-WP-0036 | finished | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| workplan | WARDEN-WP-0037 | blocked | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| workplan | WARDEN-WP-0038 | finished | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| workplan | WARDEN-WP-0039 | finished | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| workplan | WARDEN-WP-0040 | active | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| workplan | WARDEN-WP-0041 | finished | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| workplan | WARDEN-WP-0042 | finished | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| workplan | WARDEN-WP-0043 | finished | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| workplan | WARDEN-WP-0044 | active | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-ADHOC-2026-06-27-T01 | done | — | workplans/ADHOC-2026-06-27.md | +| task | WARDEN-WP-ADHOC-2026-06-29-T01 | done | — | workplans/ADHOC-2026-06-29.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T01 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T02 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T03 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T01 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T02 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T03 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T04 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T01 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T02 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T03 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T04 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T05 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T06 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-10-03-T01 | done | — | workplans/ADHOC-2026-10-03.md | +| task | WARDEN-WP-0016-T01 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T02 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T03 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T04 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0017-T01 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T02 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T03 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0018-T01 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T02 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T03 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0019-T01 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0019-T02 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0020-T01 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T02 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T03 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T04 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T05 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0021-T01 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T02 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T03 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T04 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T05 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0022-T01 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T02 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T03 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T04 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0023-T01 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T02 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T03 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T04 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T05 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T06 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T07 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0024-T01 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T02 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T03 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T04 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T05 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T06 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T07 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0025-T01 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T02 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T03 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T04 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T05 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0026-T01 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T02 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T03 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T04 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T05 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T06 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T07 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0027-T01 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T02 | todo | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T03 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0028-T01 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T02 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T03 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T04 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T05 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T06 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T07 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0029-T01 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T02 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T03 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T04 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T05 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0030-T01 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T02 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T03 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T04 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T05 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0031-T01 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T02 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T03 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T04 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T05 | cancel | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0032-T01 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T02 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T03 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T04 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T05 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T06 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T07 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0033-T01 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T02 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T03 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T04 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T05 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T06 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0034-T01 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T02 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T03 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T04 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T05 | wait | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T06 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0035-T01 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0035-T02 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0036-T01 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0036-T02 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0037-T01 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T02 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T03 | wait | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0038-T01 | done | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| task | WARDEN-WP-0039-T01 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T02 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T03 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0040-T01 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T02 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T03 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T04 | done | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0041-T01 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T02 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T03 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T04 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0042-T01 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0042-T02 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0043-T01 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T02 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T03 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0044-T01 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T02 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T03 | progress | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T04 | wait | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| intake | WARDEN-IN-0001 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0002 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0003 | closed | — | intakes/intakes.md | diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/.custodian-brief.md.worktree b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/.custodian-brief.md.worktree new file mode 100644 index 00000000..34573d26 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/.custodian-brief.md.worktree @@ -0,0 +1,60 @@ + +# Custodian Brief — ops-warden + +**Domain:** infotech +**Last synced:** 2026-10-16 00:05 UTC +**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)* + +## Active Workstreams + +### Adopt unknown -> fail_closed behind signing-target classification coverage +Progress: 1/4 done | workplan_id: `c8ee441e-1be1-5219-910c-e79ff23cc9ec` + +**Open tasks:** +- ! Tasks `611f0901` + *(wait: Warden's own declaration cannot classify the repair-path target workloads; the owner must declare the continuity actor/target and its z2-continuity resolution (see 2026-09-28 review).)* +- ! Tasks `54ad4864` + *(wait: Owners of agt-codex-interhub-bootstrap (ops-hub) and agt-state-hub-bridge (ops-bridge) must publish authoritative workload identity declarations; atm-backup-daily declared by activity-core and compiled 2026-10-09 (z2-protected, admission unsatisfied: M1 below M2 floor).)* +- ! Tasks `93eaf1f2` + *(wait: Gated on T01 and on layer model v0.8 (or successor) reaching accepted; never convert against a proposed standard.)* + +### Layer model v0.7 conformance — state the deadline, bind the agent boundary, steward the estate's newest rule +Progress: 5/6 done | workplan_id: `ae3ff76f-883d-5e2f-b6aa-144d61e8fdef` + +**Open tasks:** +- ! Tasks `7d1b3c82` + *(wait: Two items to route, not absorb: ops-mason has published no stance map; the second is another repository's to own.)* + +### Follow through on KnownSecurityCases along their type's route +Progress: 2/4 done | workplan_id: `f7e81013-6868-5d99-8528-ba75a442eca9` + +**Open tasks:** +- ! T03 — Run and verify a case `4a0fa4a7` + *(wait: Catalog integration follows a proven run.)* +- ► T02 — Plan a case run `bcbf6c91` + +### Tamper-resistant credential governance + mass rotation/lockdown (Strand B) +Progress: 2/3 done | workplan_id: `21528e8d-a049-523d-9ae1-da7a27cb8bbf` + +**Open tasks:** +- · Task: Graded lockdown / break-glass with explicit trust-root `cae498ee` + +### Repoint the whynot-design npm lane to Forgejo +Progress: 2/3 done | workplan_id: `42a097db-1c24-558e-a724-030bb2b4443e` + +**Open tasks:** +- ! Prove routing and publication `a8b1b855` + *(wait: Hold kept by D3 until SECRETS-WP-0006-T06 moves publishing off the legacy whynot-design npm path; then rotate and prove a fresh publish.)* + +## Inbox Hygiene + +**Stale unread:** 2 message(s) older than 3 day(s) — triage at session start. +**Missing thread_id:** 3 unread message(s) lack supersession chains. + +--- +## MCP Orientation (when available) + +If the state-hub MCP server is reachable, call: +`get_domain_summary("infotech")` +This provides richer cross-domain context. +If the MCP call fails, use this file as your orientation source. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/WORK-RECORDS.md.worktree b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/WORK-RECORDS.md.worktree new file mode 100644 index 00000000..8b5226ae --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/WORK-RECORDS.md.worktree @@ -0,0 +1,188 @@ +# Work Records — ops-warden + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | WARDEN-WP-ADHOC-2026-06-27 | finished | — | workplans/ADHOC-2026-06-27.md | +| workplan | WARDEN-WP-ADHOC-2026-06-29 | finished | — | workplans/ADHOC-2026-06-29.md | +| workplan | WARDEN-WP-ADHOC-2026-08-11 | finished | — | workplans/ADHOC-2026-08-11.md | +| workplan | WARDEN-WP-ADHOC-2026-08-17 | finished | — | workplans/ADHOC-2026-08-17.md | +| workplan | WARDEN-WP-ADHOC-2026-09-08 | finished | — | workplans/ADHOC-2026-09-08.md | +| workplan | WARDEN-WP-ADHOC-2026-10-03 | finished | — | workplans/ADHOC-2026-10-03.md | +| workplan | WARDEN-WP-0016 | finished | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| workplan | WARDEN-WP-0017 | finished | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| workplan | WARDEN-WP-0018 | finished | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| workplan | WARDEN-WP-0019 | finished | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| workplan | WARDEN-WP-0020 | finished | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| workplan | WARDEN-WP-0021 | finished | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| workplan | WARDEN-WP-0022 | finished | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| workplan | WARDEN-WP-0023 | finished | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| workplan | WARDEN-WP-0024 | finished | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| workplan | WARDEN-WP-0025 | finished | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| workplan | WARDEN-WP-0026 | finished | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| workplan | WARDEN-WP-0027 | blocked | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| workplan | WARDEN-WP-0028 | finished | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| workplan | WARDEN-WP-0029 | finished | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| workplan | WARDEN-WP-0030 | finished | — | workplans/WARDEN-WP-0030-delegation-register.md | +| workplan | WARDEN-WP-0031 | finished | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| workplan | WARDEN-WP-0032 | finished | — | workplans/WARDEN-WP-0032-security-zones.md | +| workplan | WARDEN-WP-0033 | finished | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| workplan | WARDEN-WP-0034 | active | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| workplan | WARDEN-WP-0035 | finished | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| workplan | WARDEN-WP-0036 | finished | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| workplan | WARDEN-WP-0037 | blocked | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| workplan | WARDEN-WP-0038 | finished | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| workplan | WARDEN-WP-0039 | finished | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| workplan | WARDEN-WP-0040 | active | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| workplan | WARDEN-WP-0041 | finished | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| workplan | WARDEN-WP-0042 | finished | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| workplan | WARDEN-WP-0043 | finished | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| workplan | WARDEN-WP-0044 | active | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-ADHOC-2026-06-27-T01 | done | — | workplans/ADHOC-2026-06-27.md | +| task | WARDEN-WP-ADHOC-2026-06-29-T01 | done | — | workplans/ADHOC-2026-06-29.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T01 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T02 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T03 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T01 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T02 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T03 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T04 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T01 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T02 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T03 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T04 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T05 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T06 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-10-03-T01 | done | — | workplans/ADHOC-2026-10-03.md | +| task | WARDEN-WP-0016-T01 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T02 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T03 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T04 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0017-T01 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T02 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T03 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0018-T01 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T02 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T03 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0019-T01 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0019-T02 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0020-T01 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T02 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T03 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T04 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T05 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0021-T01 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T02 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T03 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T04 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T05 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0022-T01 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T02 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T03 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T04 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0023-T01 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T02 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T03 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T04 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T05 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T06 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T07 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0024-T01 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T02 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T03 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T04 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T05 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T06 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T07 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0025-T01 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T02 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T03 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T04 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T05 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0026-T01 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T02 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T03 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T04 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T05 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T06 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T07 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0027-T01 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T02 | todo | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T03 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0028-T01 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T02 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T03 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T04 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T05 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T06 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T07 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0029-T01 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T02 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T03 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T04 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T05 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0030-T01 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T02 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T03 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T04 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T05 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0031-T01 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T02 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T03 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T04 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T05 | cancel | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0032-T01 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T02 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T03 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T04 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T05 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T06 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T07 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0033-T01 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T02 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T03 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T04 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T05 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T06 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0034-T01 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T02 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T03 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T04 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T05 | wait | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T06 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0035-T01 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0035-T02 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0036-T01 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0036-T02 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0037-T01 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T02 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T03 | wait | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0038-T01 | done | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| task | WARDEN-WP-0039-T01 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T02 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T03 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0040-T01 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T02 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T03 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T04 | done | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0041-T01 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T02 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T03 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T04 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0042-T01 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0042-T02 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0043-T01 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T02 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T03 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0044-T01 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T02 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T03 | progress | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T04 | wait | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| intake | WARDEN-IN-0001 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0002 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0003 | closed | — | intakes/intakes.md | diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/originals.json b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/originals.json new file mode 100644 index 00000000..21406cf6 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/publication-backup/originals.json @@ -0,0 +1,10 @@ +[ + { + "path": ".custodian-brief.md", + "index": "100644 34573d262327057c11628ce8a7ca78292968545b 0\t.custodian-brief.md" + }, + { + "path": "WORK-RECORDS.md", + "index": "100644 34cf268862326a5832a7d0be9e84eb296e5601bb 0\tWORK-RECORDS.md" + } +] diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/synthetic-parent-home/.vault-token b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/synthetic-parent-home/.vault-token new file mode 100644 index 00000000..65a0232b --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-safe-unit-integration-r1/synthetic-parent-home/.vault-token @@ -0,0 +1 @@ +synthetic-never-a-real-token \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/.custodian-brief.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/.custodian-brief.md new file mode 100644 index 00000000..34573d26 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/.custodian-brief.md @@ -0,0 +1,60 @@ + +# Custodian Brief — ops-warden + +**Domain:** infotech +**Last synced:** 2026-10-16 00:05 UTC +**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)* + +## Active Workstreams + +### Adopt unknown -> fail_closed behind signing-target classification coverage +Progress: 1/4 done | workplan_id: `c8ee441e-1be1-5219-910c-e79ff23cc9ec` + +**Open tasks:** +- ! Tasks `611f0901` + *(wait: Warden's own declaration cannot classify the repair-path target workloads; the owner must declare the continuity actor/target and its z2-continuity resolution (see 2026-09-28 review).)* +- ! Tasks `54ad4864` + *(wait: Owners of agt-codex-interhub-bootstrap (ops-hub) and agt-state-hub-bridge (ops-bridge) must publish authoritative workload identity declarations; atm-backup-daily declared by activity-core and compiled 2026-10-09 (z2-protected, admission unsatisfied: M1 below M2 floor).)* +- ! Tasks `93eaf1f2` + *(wait: Gated on T01 and on layer model v0.8 (or successor) reaching accepted; never convert against a proposed standard.)* + +### Layer model v0.7 conformance — state the deadline, bind the agent boundary, steward the estate's newest rule +Progress: 5/6 done | workplan_id: `ae3ff76f-883d-5e2f-b6aa-144d61e8fdef` + +**Open tasks:** +- ! Tasks `7d1b3c82` + *(wait: Two items to route, not absorb: ops-mason has published no stance map; the second is another repository's to own.)* + +### Follow through on KnownSecurityCases along their type's route +Progress: 2/4 done | workplan_id: `f7e81013-6868-5d99-8528-ba75a442eca9` + +**Open tasks:** +- ! T03 — Run and verify a case `4a0fa4a7` + *(wait: Catalog integration follows a proven run.)* +- ► T02 — Plan a case run `bcbf6c91` + +### Tamper-resistant credential governance + mass rotation/lockdown (Strand B) +Progress: 2/3 done | workplan_id: `21528e8d-a049-523d-9ae1-da7a27cb8bbf` + +**Open tasks:** +- · Task: Graded lockdown / break-glass with explicit trust-root `cae498ee` + +### Repoint the whynot-design npm lane to Forgejo +Progress: 2/3 done | workplan_id: `42a097db-1c24-558e-a724-030bb2b4443e` + +**Open tasks:** +- ! Prove routing and publication `a8b1b855` + *(wait: Hold kept by D3 until SECRETS-WP-0006-T06 moves publishing off the legacy whynot-design npm path; then rotate and prove a fresh publish.)* + +## Inbox Hygiene + +**Stale unread:** 2 message(s) older than 3 day(s) — triage at session start. +**Missing thread_id:** 3 unread message(s) lack supersession chains. + +--- +## MCP Orientation (when available) + +If the state-hub MCP server is reachable, call: +`get_domain_summary("infotech")` +This provides richer cross-domain context. +If the MCP call fails, use this file as your orientation source. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/WORK-RECORDS.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/WORK-RECORDS.md new file mode 100644 index 00000000..8b5226ae --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/WORK-RECORDS.md @@ -0,0 +1,188 @@ +# Work Records — ops-warden + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | WARDEN-WP-ADHOC-2026-06-27 | finished | — | workplans/ADHOC-2026-06-27.md | +| workplan | WARDEN-WP-ADHOC-2026-06-29 | finished | — | workplans/ADHOC-2026-06-29.md | +| workplan | WARDEN-WP-ADHOC-2026-08-11 | finished | — | workplans/ADHOC-2026-08-11.md | +| workplan | WARDEN-WP-ADHOC-2026-08-17 | finished | — | workplans/ADHOC-2026-08-17.md | +| workplan | WARDEN-WP-ADHOC-2026-09-08 | finished | — | workplans/ADHOC-2026-09-08.md | +| workplan | WARDEN-WP-ADHOC-2026-10-03 | finished | — | workplans/ADHOC-2026-10-03.md | +| workplan | WARDEN-WP-0016 | finished | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| workplan | WARDEN-WP-0017 | finished | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| workplan | WARDEN-WP-0018 | finished | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| workplan | WARDEN-WP-0019 | finished | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| workplan | WARDEN-WP-0020 | finished | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| workplan | WARDEN-WP-0021 | finished | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| workplan | WARDEN-WP-0022 | finished | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| workplan | WARDEN-WP-0023 | finished | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| workplan | WARDEN-WP-0024 | finished | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| workplan | WARDEN-WP-0025 | finished | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| workplan | WARDEN-WP-0026 | finished | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| workplan | WARDEN-WP-0027 | blocked | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| workplan | WARDEN-WP-0028 | finished | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| workplan | WARDEN-WP-0029 | finished | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| workplan | WARDEN-WP-0030 | finished | — | workplans/WARDEN-WP-0030-delegation-register.md | +| workplan | WARDEN-WP-0031 | finished | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| workplan | WARDEN-WP-0032 | finished | — | workplans/WARDEN-WP-0032-security-zones.md | +| workplan | WARDEN-WP-0033 | finished | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| workplan | WARDEN-WP-0034 | active | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| workplan | WARDEN-WP-0035 | finished | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| workplan | WARDEN-WP-0036 | finished | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| workplan | WARDEN-WP-0037 | blocked | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| workplan | WARDEN-WP-0038 | finished | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| workplan | WARDEN-WP-0039 | finished | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| workplan | WARDEN-WP-0040 | active | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| workplan | WARDEN-WP-0041 | finished | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| workplan | WARDEN-WP-0042 | finished | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| workplan | WARDEN-WP-0043 | finished | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| workplan | WARDEN-WP-0044 | active | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-ADHOC-2026-06-27-T01 | done | — | workplans/ADHOC-2026-06-27.md | +| task | WARDEN-WP-ADHOC-2026-06-29-T01 | done | — | workplans/ADHOC-2026-06-29.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T01 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T02 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-11-T03 | done | — | workplans/ADHOC-2026-08-11.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T01 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T02 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T03 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-08-17-T04 | done | — | workplans/ADHOC-2026-08-17.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T01 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T02 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T03 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T04 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T05 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-09-08-T06 | done | — | workplans/ADHOC-2026-09-08.md | +| task | WARDEN-WP-ADHOC-2026-10-03-T01 | done | — | workplans/ADHOC-2026-10-03.md | +| task | WARDEN-WP-0016-T01 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T02 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T03 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0016-T04 | done | — | workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md | +| task | WARDEN-WP-0017-T01 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T02 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0017-T03 | done | — | workplans/WARDEN-WP-0017-access-front-door-discoverability.md | +| task | WARDEN-WP-0018-T01 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T02 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0018-T03 | done | — | workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md | +| task | WARDEN-WP-0019-T01 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0019-T02 | done | — | workplans/WARDEN-WP-0019-route-to-secrets-engine.md | +| task | WARDEN-WP-0020-T01 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T02 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T03 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T04 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0020-T05 | done | — | workplans/WARDEN-WP-0020-ops-warden-worker.md | +| task | WARDEN-WP-0021-T01 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T02 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T03 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T04 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0021-T05 | done | — | workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md | +| task | WARDEN-WP-0022-T01 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T02 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T03 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0022-T04 | done | — | workplans/WARDEN-WP-0022-audit-trail-and-activity.md | +| task | WARDEN-WP-0023-T01 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T02 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T03 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T04 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T05 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T06 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0023-T07 | done | — | workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md | +| task | WARDEN-WP-0024-T01 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T02 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T03 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T04 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T05 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T06 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0024-T07 | done | — | workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md | +| task | WARDEN-WP-0025-T01 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T02 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T03 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T04 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0025-T05 | done | — | workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md | +| task | WARDEN-WP-0026-T01 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T02 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T03 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T04 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T05 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T06 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0026-T07 | done | — | workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md | +| task | WARDEN-WP-0027-T01 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T02 | todo | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0027-T03 | cancel | — | workplans/WARDEN-WP-0027-credential-governance-lockdown.md | +| task | WARDEN-WP-0028-T01 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T02 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T03 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T04 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T05 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T06 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0028-T07 | done | — | workplans/WARDEN-WP-0028-tenant-secret-custody.md | +| task | WARDEN-WP-0029-T01 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T02 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T03 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T04 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0029-T05 | done | — | workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md | +| task | WARDEN-WP-0030-T01 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T02 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T03 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T04 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0030-T05 | done | — | workplans/WARDEN-WP-0030-delegation-register.md | +| task | WARDEN-WP-0031-T01 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T02 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T03 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T04 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0031-T05 | cancel | — | workplans/WARDEN-WP-0031-policy-caller-identity.md | +| task | WARDEN-WP-0032-T01 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T02 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T03 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T04 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T05 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T06 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0032-T07 | done | — | workplans/WARDEN-WP-0032-security-zones.md | +| task | WARDEN-WP-0033-T01 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T02 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T03 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T04 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T05 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0033-T06 | done | — | workplans/WARDEN-WP-0033-native-lane-handoff.md | +| task | WARDEN-WP-0034-T01 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T02 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T03 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T04 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T05 | wait | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0034-T06 | done | — | workplans/WARDEN-WP-0034-layer-model-v07-conformance.md | +| task | WARDEN-WP-0035-T01 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0035-T02 | done | — | workplans/WARDEN-WP-0035-policy-nexus-forgejo-source-read-route.md | +| task | WARDEN-WP-0036-T01 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0036-T02 | done | — | workplans/WARDEN-WP-0036-attended-login-openbao-output.md | +| task | WARDEN-WP-0037-T01 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T02 | done | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0037-T03 | wait | — | workplans/WARDEN-WP-0037-whynot-design-forgejo-npm-lane.md | +| task | WARDEN-WP-0038-T01 | done | — | workplans/WARDEN-WP-0038-plan-mutation-intent.md | +| task | WARDEN-WP-0039-T01 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T02 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0039-T03 | done | — | workplans/WARDEN-WP-0039-explicit-policy-refusal.md | +| task | WARDEN-WP-0040-T01 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T02 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T03 | wait | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0040-T04 | done | — | workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md | +| task | WARDEN-WP-0041-T01 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T02 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T03 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0041-T04 | done | — | workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md | +| task | WARDEN-WP-0042-T01 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0042-T02 | done | — | workplans/WARDEN-WP-0042-openbao-structure-survey-route.md | +| task | WARDEN-WP-0043-T01 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T02 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0043-T03 | done | — | workplans/WARDEN-WP-0043-platform-supplier-credentials.md | +| task | WARDEN-WP-0044-T01 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T02 | done | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T03 | progress | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| task | WARDEN-WP-0044-T04 | wait | — | workplans/WARDEN-WP-0044-security-case-follow-through.md | +| intake | WARDEN-IN-0001 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0002 | closed | — | intakes/intakes.md | +| intake | WARDEN-IN-0003 | closed | — | intakes/intakes.md | diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-27.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-27.md new file mode 100644 index 00000000..d75908fb --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-27.md @@ -0,0 +1,41 @@ +--- +id: WARDEN-WP-ADHOC-2026-06-27 +type: workplan +title: "Ad Hoc Tasks — 2026-06-27" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "a222c91f-3bb5-58a4-b6b2-f0fb18cdd5c3" +--- + +# Ad Hoc Tasks — 2026-06-27 + +Low-risk opportunistic fixes completed directly during the consolidation session. + +### T01 — Fix stale `warden` CLI install + make it usable outside the repo + +```task +id: WARDEN-WP-ADHOC-2026-06-27-T01 +status: done +priority: medium +state_hub_task_id: "9176b560-8ca5-5143-888d-479857fe60f0" +``` + +issue-core reported (msg `70bcf238`) that the `warden` CLI on `~/.local/bin` lacked +the `route` subcommand, forcing a `uv run warden` fallback. + +- [x] Root cause: `uv tool install` had reused a **cached wheel** (version stayed + `0.1.0`), so the installed `warden.cli` predated the `route`/`access`/`policy` + subcommands. `uv cache clean ops-warden` + `uv tool install . --reinstall` fixed it. +- [x] Deeper cause: even rebuilt, `warden route`/`policy` failed outside a checkout + because the catalog + posture descriptors live in `registry/` at repo root, + outside the package. Bundled `registry/` into the wheel via hatch + `force-include` → `warden/_registry`, and added a packaged-data fallback in + `find_catalog_path` / `find_posture_path` (after the repo walk, so source runs + still prefer the repo's `registry/` as the single source of truth). +- [x] Verified `warden route list` / `warden policy list` work from `/tmp`; 200 tests + pass, lint clean. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-29.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-29.md new file mode 100644 index 00000000..b46be0fd --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-06-29.md @@ -0,0 +1,40 @@ +--- +id: WARDEN-WP-ADHOC-2026-06-29 +type: workplan +title: "Ad Hoc Tasks — 2026-06-29" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +created: "2026-06-29" +updated: "2026-06-29" +state_hub_workstream_id: "13fa845f-852e-55ec-a2a5-2296996e0216" +--- + +# Ad Hoc Tasks — 2026-06-29 + +### T01 — Joint-smoke mode for the deployed flex-auth (assist FLEX-WP-0007 T4) + +```task +id: WARDEN-WP-ADHOC-2026-06-29-T01 +status: done +priority: medium +state_hub_task_id: "62540533-f4ca-5176-9237-32adbeb292ee" +``` + +flex-auth (msg `ea00620b`) asked ops-warden to help close FLEX-WP-0007 T4 (joint OpenBao ++ policy-gate production smoke). Their deployed runtime is reachable on CoulombCore via +the flex-auth-coulombcore tunnel at `127.0.0.1:18090`, but `policy_gate_production_smoke.sh` +spawned its **own** local flex-auth binary — so it never exercised the deployed runtime. + +- [x] Added `FLEX_AUTH_EXTERNAL=1` mode to `scripts/policy_gate_production_smoke.sh`: skips + the local `serve`/`load-registry` and runs the allow/deny/vault paths against the + already-running deployed flex-auth, with a `/healthz` precheck that fails fast with a + "is the flex-auth-coulombcore tunnel up?" hint (verified: clean exit 2 when down). +- [x] Verified the committed `production_registry_snapshot.json` is **current** (rebuilt + from `~/.config/warden/inventory.yaml`, diff-clean; 4 actors). +- [x] Answered flex-auth's three questions and handed the operator the exact CoulombCore + runbook (see reply). Remaining T4 steps are operator-gated and cannot run from the + workstation: mint a scoped `VAULT_TOKEN` (ops-warden holds no standing token by + design), run the joint smoke on CoulombCore, then flip `policy.enabled: true`. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-11.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-11.md new file mode 100644 index 00000000..3d858fe8 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-11.md @@ -0,0 +1,145 @@ +--- +id: WARDEN-WP-ADHOC-2026-08-11 +type: workplan +title: "Ad Hoc Tasks — 2026-08-11" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +created: "2026-08-11" +updated: "2026-08-15" +state_hub_workstream_id: "9f99cc64-4682-5f20-b13e-89af2b6f7c70" +--- + +# Ad Hoc Tasks — 2026-08-11 + +### T01 — Repair stale `rapp-qonto-keycape-client` wiki anchor (restore green routing suite) + +```task +id: WARDEN-WP-ADHOC-2026-08-11-T01 +status: done +priority: medium +state_hub_task_id: "0771d121-278c-556e-9509-841cf6e657c3" +``` + +rapp-postgres (msg `96907986`, residual from RAPP-POSTGRES-WP-0002-T04) reported the +focused routing suite at 60/61: `test_every_wiki_ref_anchor_resolves` failed because +`rapp-qonto-keycape-client` pointed at `wiki/CredentialRouting.md#credential-routing-catalog`, +an anchor that does not exist. The intended heading is `## Routing catalog index`. + +- [x] Repointed `rapp-qonto-keycape-client.wiki_ref` to + `wiki/CredentialRouting.md#routing-catalog-index` (the live heading). No other + entry used the stale anchor. +- [x] `uv run pytest tests/test_routing.py -q` → **61 passed**. +- [x] `warden route find "database credential"` still returns the active + `database-dynamic-credentials` rapp-postgres entry; that T04 route is untouched — + still `warden_executes: false` with no `steps:` block (pointer, not procedure). + +### T02 — Triage the stale ops-warden inbox (11 unread, C-28/C-29) + +```task +id: WARDEN-WP-ADHOC-2026-08-11-T02 +status: done +priority: medium +state_hub_task_id: "0ed58145-732f-5102-b6a8-b931d9b6ba08" +``` + +`fix-consistency` flagged 11 unread messages older than 3 days, two of them as possible +work requests (C-29). All eleven triaged, answered where an answer was owed, and marked +read. Inbox is now empty. + +- [x] **railiance-platform front-door thread** (`72d3ee84`, `cb50ea3c`, `6b058584`, + `5d47caaa`, `78c1c075`) — confirmed both lanes active and placeholder-free + (`issue-core-ingestion-api-key` catalog.yaml:219, `openrouter-llm-connect` + catalog.yaml:283, promoted in 364eb7d), closing RAILIANCE-WP-0009-T06 and + RAILIANCE-WP-0010-T06. Answered their open question: the stable ops-warden + selector is **`openrouter-llm-connect`**, not `llm-connect-openrouter-api-key`; + asked them to cross-reference the id in CCR-2026-0003 rather than have ops-warden + rename an active, test-referenced lane. +- [x] **railiance01 / activity-core** (`467153f3`, `3b9c6a77`, `fe796249`, `674f02e0`) — + superseded. STATE-WP-0071 finished; the `.git/FETCH_HEAD` blocker was filesystem + ownership, not SSH, and no `warden sign` was needed. Nothing was ever open for + ops-warden. Pointed activity-core at `warden plan` / `warden route find` instead of + hub round-trips for access questions. +- [x] **llm-connect LLM-WP-0006** (`f5975211`) — superseded: `OPENROUTER_API_KEY` was + provisioned through OpenBao custody 2026-07-02 (CCR-2026-0003), ES synced, + llm-connect rolled out. Restated the boundary — ops-warden does not populate + Secrets — and pointed at the now-active catalog lane. `LLM_CONNECT_URL` wiring + remains activity-core's. +- [x] **secrets-engine warden-sign** (`80456912`) — see T03; replied with status and + referred the live-apply question to the owner. + +### T03 — warden-sign AppRole: PARKED pending WP-0027 break-glass + ops-bridge cutover + +```task +id: WARDEN-WP-ADHOC-2026-08-11-T03 +status: done +priority: medium +state_hub_task_id: "337ae793-c6b0-59e9-8a07-3a7ccba237aa" +``` + +secrets-engine (msg `80456912`, 2026-06-29) is holding a validated non-mutating dry-run +for policy + AppRole `warden-sign` (exact `update` grants on `ssh/sign/{agt,adm,atm}-role`). +It is blocked on two **operator** actions: recording/approving the SECRETS-WP-0004 +decision, and providing the mode-0600 lane bootstrap token +(`~/.secrets-engine/bootstrap/prod-warden-sign.token`). secrets-engine correctly refused +to substitute the broader platform-admin token. + +**The request has been overtaken by events.** Since 2026-07-01 the scoped `VAULT_TOKEN` +need is served by the railiance-platform credential broker +(`ops-warden-warden-sign-token`, active; `credential.py exec --grant ops-warden/warden-sign`, +proven via `make credential-exec-ops-warden-smoke`) — no AppRole involved. + +**Resolved 2026-08-11: parked** — neither withdrawn nor proceeding. Founder decision +after reviewing the mechanics. Communicated to secrets-engine (msg `863c7b57`) with an +explicit instruction to stop holding apply readiness. + +An initial recommendation to **withdraw** was revised on inspection: + +- `warden sign` reads `VAULT_TOKEN` from the environment and has no AppRole login path + (`src/warden/vault.py:24-27`). The AppRole is a way for a *host* to obtain a token, + not an ops-warden code path — withdrawing costs no code and removes no working + capability. For the workstation, the broker plus attended operator OIDC is sufficient. +- The uncovered case is **unattended signing on a remote host** — the pending ops-bridge + cert_command cutover. `wiki/playbooks/ops-bridge-tunnel-cert.md:61` still falls back to + a manually exported `VAULT_TOKEN` there. +- Running the broker on that host means placing the railiance-platform checkout *and its + issuer token* (`credential-broker-warden-sign-issuer` — authority to mint warden-sign + tokens repeatedly) on it. The AppRole exchanges for a `warden-sign`-only token + (`update` on `ssh/sign/{agt,adm,atm}-role`). Both are standing credentials on a remote + host; **the AppRole is the narrower one**, and is the established NetKingdom pattern + for this shape (`rein-openweights-openrouter-approle`, + `agent-harness-binky-mail-approle`). + +No circular dependency exists today: OpenBao is a public endpoint +(`https://bao.coulomb.social`), so obtaining a cert never requires already holding one. + +**Un-park triggers** (either one re-opens the question): + +1. **WARDEN-WP-0027** (backlog) designs the graded lockdown / break-glass path and its + explicit trust-root — a second autonomous path to signing is an input to that design, + not an isolated decision. +2. **ops-bridge cert_command live cutover** reaches unattended signing on a remote host. + +Cheap to reverse: the secrets-engine dry-run plan is validated, re-runnable, and correct +as drafted. The two operator gates (SECRETS-WP-0004 decision, mode-0600 lane bootstrap +token) are deliberately *not* being satisfied while parked. + +**Closed 2026-08-15.** Neither un-park trigger has fired: + +1. `WARDEN-WP-0027` is still `backlog`; T02 (graded lockdown / break-glass) stays + `cancel` with the workplan. The parked AppRole remains an input on that task. +2. ops-bridge live cert_command cutover has not reached unattended signing on a + remote host. WP-0016 is finished as *pilot-ready and handed off*, not migrated. + +This ad-hoc's job was the operator question (withdraw vs keep). The 2026-08-11 +answer stands: **neither — park and hand off**. Applying or withdrawing the +AppRole is out of scope here and would re-open the operator gates that were +deliberately left unsatisfied. Long-term ownership is `WARDEN-WP-0027-T02` +(and the ops-bridge cutover if that arrives first). secrets-engine already has +the park instruction (msg `863c7b57`); no new apply/withdraw ask. + +- [x] Park decision recorded and communicated (2026-08-11) +- [x] Ownership transferred to `WARDEN-WP-0027` T02; playbook pointer updated +- [x] Ad-hoc closed so a `wait` item does not linger past the handoff diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-17.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-17.md new file mode 100644 index 00000000..65d75959 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-08-17.md @@ -0,0 +1,129 @@ +--- +id: WARDEN-WP-ADHOC-2026-08-17 +type: workplan +title: "Ad Hoc Tasks — 2026-08-17" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +created: "2026-08-17" +updated: "2026-08-17" +state_hub_workstream_id: "5c6c2bbb-b944-5afd-b89c-20d865518849" +--- + +# Ad Hoc Tasks — 2026-08-17 + +Inbox triage session. Three unread messages, all follow-on from the WP-0030 delegation +register plus one new design question that lands on ops-warden as the estate's +workload-identity owner. + +### T01 — Answer flex-auth: how should `/v1/check` authenticate its callers? + +```task +id: WARDEN-WP-ADHOC-2026-08-17-T01 +status: done +priority: high +state_hub_task_id: "04a2f8f9-e70b-5eed-ad87-343c8f9ef501" +``` + +flex-auth (msg `130a148c`, FLEX-WP-0015 T02) reported that `POST /v1/check` and +`/v1/batch_check` authenticate no caller — any workload with cluster network reach can +assert any subject/tenant and receive an authoritative allow. It lands on ops-warden +because ops-warden owns how workloads prove identity in this estate, and because the +ops-warden pre-sign gate is a flex-auth PEP that would implement the calling side. + +Their four questions answered in `wiki/NetKingdomSecurityMap.md` +§ *Service-to-service caller authentication (in-cluster)*: + +- [x] **Q1 — is there an existing estate pattern to adopt?** No. Surveyed what exists: + ops-warden SSH certs (host reachability, not pod→pod HTTP), KeyCape + `client_credentials` (`rapp-qonto-keycape-client` — a custodied client secret per + caller), OpenBao AppRole (host-standing; the WP-0030 register already flags it as + having no owner front door). None covers in-cluster service→service HTTP, so + flex-auth is not growing a parallel mechanism by adopting one. +- [x] **Q2 — which mechanism?** Confirmed their instinct: **(a) Kubernetes + ServiceAccount TokenReview**, with a *projected* token carrying an explicit + `audience`, keeping `automountServiceAccountToken: false` and adding the volume + per Deployment. Rejected (c) shared-secret header — it manufactures a `risk: high` + credential lane with a rotation owner per caller, on the authorization path, which + is exactly the interim-proxy debt WP-0030 exists to stop growing, and ops-warden + would end up fronting it. Deferred (b) mTLS as the stronger end state that first + needs an answer to *who owns the workload X.509 CA* — nobody does; ops-warden + issues SSH certs, not workload X.509. +- [x] **Q3 — authenticate only, or also constrain?** Both, but split: bind the asserted + `system` to the authenticated ServiceAccount and reject a mismatch (identity + binding, no per-consumer operational cost). Keep the *resource-type* allowlist + ("only ops-warden may ask about `ssh-certificate`") in the policy package, not in + the auth middleware — flex-auth is the policy engine, and encoding it in its own + admission layer puts authorization in two places where only one is versioned. +- [x] **Q4 — rollout shape?** Warn-only first, as they proposed; ops-warden adopts the + calling side on its own schedule. Binding condition is sequencing, not a date: + `policy.enabled` must not flip anywhere while `/v1/check` still answers + unauthenticated callers. +- [x] Recorded as a **pattern**, not a catalog entry — `registry/routing/catalog.yaml` + indexes credential needs and their owners; caller authentication is neither. +- [x] Noted the division of the call: mechanism is ops-warden's/architectural; accepting + the pod-spec change and rollout timing are the operator's. + +### T02 — user-engine: USER_ENGINE_PROXY_SECRET stays railiance-apps; record consumer-only + +```task +id: WARDEN-WP-ADHOC-2026-08-17-T02 +status: done +priority: medium +state_hub_task_id: "0e815282-2fad-5c8d-be34-398e492737d0" +``` + +user-engine (msg `2af4a124`) answered the open confirm question on +`coulomb-social-runtime-env`. Decided by Bernd 2026-08-16, State Hub decision +`8fe22037-5bbb-4487-bb86-e4beccee454b` against USER-WP-0021: the secret is +infrastructure trust between ingress and workload, not a user-domain fact; user-engine +consumes it and has no authority over custody, rotation, or issuance. + +- [x] `intended_owner` stays `railiance-apps`; dropped the now-answered + "confirm whether user-engine should front USER_ENGINE_PROXY_SECRET" clause from + `blocked_on`, which now names only the real remaining blocker (CCR not applied). +- [x] Recorded the positive signal they asked for: `consumers: [user-engine]` on the + lane, with the decision id in a comment. +- [x] Their second point — `USER_ENGINE_EVENT_TOKEN`, `USER_ENGINE_MAIL_TOKEN`, and the + transactional SMTP lane gating public registration — checked against the catalog: + `audit-core-senders` (native → ops-mason) and `email-connect-transactional` + (interim → secrets-engine) already cover the event and mail token custody. No new + lane opened; told them which ids to watch. + +### T03 — key-cape: `rapp-qonto-keycape-client` interim accepted; refresh the blocker + +```task +id: WARDEN-WP-ADHOC-2026-08-17-T03 +status: done +priority: medium +state_hub_task_id: "e21781d9-a35d-5916-b335-d12131f97a22" +``` + +key-cape (msg `099b7cba`) acknowledged the lane staying interim on ops-warden. +KEY-WP-0008 is finished and its closeout does **not** include a key-cape-native +`client_secret_basic` exchange/rotation command; that is a separate, not-yet-opened +workplan. + +- [x] Refreshed `blocked_on` so it names the current reality rather than implying an + in-flight KEY-WP-0008 dependency: the native command is unopened work, and + key-cape has acked the interim hold. +- [x] `key-cape-oidc-login` left pointing at `secrets-engine` — key-cape explicitly did + not claim the generic-vs-per-lane custody split, and that lane's blocker is the + same unanswered secrets-engine question as the other six. +- [x] `reviewed` bumped to 2026-08-17 on both touched lanes so `warden route gaps` + staleness reflects a real re-check. + +### T04 — Session hygiene + +```task +id: WARDEN-WP-ADHOC-2026-08-17-T04 +status: done +priority: low +state_hub_task_id: "b15724e0-c27a-5260-a810-4dd25bff2228" +``` + +- [x] `uv run pytest -q` → 338 passed, 4 deselected (routing anchor + no-double-source + checks green after the catalog edits). +- [x] All three messages replied to and marked read; inbox empty. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-09-08.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-09-08.md new file mode 100644 index 00000000..c1ae7c3e --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-09-08.md @@ -0,0 +1,179 @@ +--- +id: WARDEN-WP-ADHOC-2026-09-08 +type: workplan +title: "Ad Hoc Tasks — 2026-09-08" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: netkingdom +created: "2026-09-08" +updated: "2026-09-08" +state_hub_workstream_id: "182f3aff-8c8a-5766-8a68-5fe35f423f7a" +--- + +# Ad Hoc Tasks — 2026-09-08 + +Four key-cape messages, all follow-on from `WARDEN-WP-0033`. Two carry answers +ops-warden's catalog was waiting for; both make a recorded blocker less true than +it reads. This is the T05 mechanism paying out — and this time the owner ran it +against us rather than us running it against them. + +### T01 — Narrow the `rapp-qonto-keycape-client` blocker (msg `08d42f47`) + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T01 +status: done +priority: high +state_hub_task_id: "29cef28a-d93b-5318-bfdb-69dbe11fa3ba" +``` + +The blocker recorded "still no key-cape-native exchange/rotation command", +`verified: source-read` against key-cape source on 2026-08-28. Accurate then; +two things landed after that read: + +- `keycape service-token` (2026-09-05, KEY-WP-0014-T03) — the client_secret_basic + exchange the blocker records as absent. +- `keycape verify-client` (2026-09-08) — rotation step 3 as one command, + including predecessor rejection and identical-secret detection. + +**Narrowed, not cleared**, as key-cape asked. What remains genuinely blocked is +steps 1-2: successor generation and the CAS write to both custodians. Those are +custody and deployment acts, key-cape deliberately ships no command for them, and +no admitted ops-warden lane authorizes them either (T03). + +`verified` moved to `owner-confirmed` — the correction came from the owner. + +`rotation.automatable` flipped `true` → `false`, which key-cape explicitly asked +us not to do "either way" without precision. Done with the precision they wanted, +in the only place the schema has room for it: the flag is a single hint consumed +by a future executable driver (`WARDEN-WP-0027` Strand B), and a driver told +`true` would attempt custody acts with no admitted transport — the dangerous +direction. So the flag fails safe and the *steps* now carry the per-step truth, +each naming whether it is automatable and why. Offered them a schema change if a +per-step field would serve better; not built on speculation. + +### T02 — Record key-cape's acceptance of `key-cape-oidc-login` (msg `12f1bdfa`) + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T02 +status: done +priority: high +state_hub_task_id: "8efb8013-7b90-52ef-a17c-d63f5ce3752c" +``` + +key-cape **accepted** ownership: interactive login, OIDC identity-token issuance +and MFA. This confirms the 2026-08-28 correction of `intended_owner` from +secrets-engine to key-cape, and confirms secrets-engine's 2026-08-21 refusal was +right. `verified: asked-and-waiting` → `owner-confirmed`. + +**The lane stays `interim`.** Acceptance covers the identity half only. The +`fetch_command` yields an *OpenBao* token — the `netkingdom` mount, the +`role=` mapping, the token store and its enforcement are OpenBao's, with +role and policy definition railiance-platform's. `keycape login` yields a +key-cape issuer JWT to a private file: different credential type, different +verifier, different enforcement owner. Accepting an owner is not the same as the +owner fronting the lane, and `ADR-0003` says the interim cover is retired when +the front door exists, not when ownership is agreed. Retirement condition is now +recorded on the entry. + +Their reading of the risk is right and we confirmed it: `warden_executes: false` +with a `wiki_ref` pointer, so per `ADR-0001` this is a pointer layer, not a code +path with programmatic consumers. `risk: standard` and +`workload_ref: not-applicable` are correct — a human identity act with no KV +path, consistent with how `ADR-0008` treats the other non-KV lanes. + +### T03 — Answer "who executes Qonto rotation steps 1-2" (msg `0a6c9d88`) + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T03 +status: done +priority: high +state_hub_task_id: "bd621821-2116-51c9-a09a-a3660b5e5557" +``` + +Answer: **nobody, admittedly, today** — and ops-warden must not invent one. + +Steps 1-2 mutate custody on `platform/workloads/rapp-qonto/keycape-client` and +`sso/keycape-rapp-qonto-client`. Custody of platform workload paths is +railiance-platform's; the admitted execution front door for provisioned +secret-exec is `secrets-engine exec`. ops-warden owns neither and absorbing it +would be `ADR-0002` and `ADR-0005` violated in one act. Routed to +railiance-platform, with secrets-engine named as the transport owner — and +secrets-engine independently confirmed the same boundary three days earlier +(msg `15f0c0ca`): they will not rewrite a production lane's custody state from a +coordination message without owner confirmation. + +key-cape was right not to treat a generic `warden route` match as authorization. +See T04 for what our own tool did when asked. + +### T04 — `warden plan` returned `autonomous` for a custody *write* (defect) + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T04 +status: done +priority: high +state_hub_task_id: "9ada01d2-b14b-579e-921c-275820f255db" +``` + +Verifying T03 against our own front door: + +``` +warden plan "generate a successor client secret ... and CAS-write it to + OpenBao platform/workloads/... and sso/..." --json + verdict: autonomous + lane_id: rapp-qonto-keycape-client + commands: warden access ... --exec / --out / --wrap +``` + +A need that says *generate* and *CAS-write* resolved to `autonomous` and was +answered with three **read** transports. This is the `WARDEN-WP-0033-T06` shape +recurring — a generic keyword match producing a confident wrong act — except T06 +fixed one route by adding an exact lane, and the defect is in the classifier. +`warden plan` has no notion of read versus mutate intent, so every write need +matches the lane that *reads* the same path and comes back `autonomous`. + +Not fixed here: a classifier is design work with an approval-semantics blast +radius, which the convention says is a workplan, not an adhoc. +Promoted to **`WARDEN-WP-0038`** (`proposed`). + +Worth stating plainly: key-cape distrusted this output on principle and was right +to. Had they trusted it, our tool would have told them to proceed autonomously on +an unadmitted custody mutation. + +### T05 — Acknowledge the KEY-WP-0009 handoff (msg `5bc58847`) + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T05 +status: done +priority: low +state_hub_task_id: "06bf8508-d1a2-51b4-b951-02539524ebb9" +``` + +Informational; no route retired or changed. Their routing note matches ours: +"login / OIDC / MFA" → key-cape means **issuance only**, and secret *values* +route to OpenBao custody. Nothing to change in `wiki/CredentialRouting.md`. + +Also records that the KEY-WP-0009 reply ops-warden reported never arriving indeed +never existed (KEY-WP-0014-T02, audited 2026-09-05). Our 2026-08-28 finding was +right, and the correction is theirs, recorded. + +### T06 — Unpin two tests from a transient catalog state + +```task +id: WARDEN-WP-ADHOC-2026-09-08-T06 +status: done +priority: medium +state_hub_task_id: "a0b88db9-2886-54dd-a925-9e0521044aa0" +``` + +`test_stale_gaps_flags_unverified_even_when_the_date_is_today` and +`test_cli_route_gaps_fail_on_stale_exits_3` both asserted that +`key-cape-oidc-login` specifically sat `asked-and-waiting`. T02 answering that +question broke them — **the tests failed on good news**, not on a defect, and a +test that fails when a counterparty replies will get suppressed rather than read. + +Both now assert the property they were always about: any lane whose blocker was +never re-established is stale regardless of its date, over whatever lanes are in +that state. The named-lane version of the claim already exists as a unit test on +`Delegation.is_verified`, which is where a fixture belongs. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-10-03.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-10-03.md new file mode 100644 index 00000000..e76cd016 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/ADHOC-2026-10-03.md @@ -0,0 +1,31 @@ +--- +id: WARDEN-WP-ADHOC-2026-10-03 +type: workplan +title: "Documentary feedback on Emergent Security repository pilot" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: ops-warden +created: "2026-10-03" +updated: "2026-10-03" +state_hub_workstream_id: "246dc069-0f9b-516b-9db4-9914323da16f" +--- + +## Review retained pilot evidence against owner boundaries + +```task +id: WARDEN-WP-ADHOC-2026-10-03-T01 +status: done +priority: medium +state_hub_task_id: "c532cd72-88c4-543b-b6db-caf1bcb74a3d" +``` + +Evidence: docs/evidence/2026-10-03-emergent-pilot-owner-feedback.md. +Completed authorized documentary feedback on the retained read-only 0.2.0 +Claude scenario; preserved original version and evidence limits, qualified +owner boundary wording and identified bounded 0.2.2 follow-up scenarios. +No provider session, runtime control, deployment, credential or institutional +adoption was performed. Next pilot/adoption gates remain existing +EMERGENT-WP-0002-T08/T09 and decision d20a9750-2b29-534e-8227-fb866581a6ca. +No new operational residual was created. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md new file mode 100644 index 00000000..a787f1da --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0016-ops-bridge-tunnel-cert-pilot.md @@ -0,0 +1,124 @@ +--- +id: WARDEN-WP-0016 +type: workplan +title: "ops-bridge cert_command pilot — readiness gate + handoff" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 16 +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "a56da8db-38bc-4bbe-8671-823360ec9245" +--- + +# WARDEN-WP-0016 — ops-bridge cert_command pilot (readiness gate + handoff) + +**Scope:** Close ops-warden's side of the last **Partial** INTENT criterion — *"ops-bridge +integrates via a stable `cert_command`"*. The migration playbook +(`wiki/playbooks/ops-bridge-tunnel-cert.md`, WP-0013) and the `cert_command` contract +(`wiki/CertCommandInterface.md`) already exist, but the pilot has never been run because +the readiness checks are scattered manual checkboxes across three owners (ops-warden, +ops-bridge, railiance-infra). This WP ships the **automated readiness gate** an operator +runs *before* touching tunnel config, plus an offline `cert_command` contract smoke, and +hands the verified pilot to ops-bridge. + +**Boundary (unchanged):** ops-warden issues certs and verifies its own side is ready. +The **live tunnel cutover is ops-bridge's to execute** — this WP does not (cannot) flip a +running tunnel. "Done" here means *pilot-ready and handed off*, not *tunnel migrated*. + +**Out of scope:** editing `~/.config/bridge/tunnels.yaml` (ops-bridge owns it); deploying +host principals (railiance-infra); requiring a live OpenBao token for the contract smoke +(use the local backend). + +**Depends on:** WP-0013 (playbook + contract), the SSH lane (prod-verified). + +--- + +## Tasks + +### T1 — Read-only `cert_command` readiness preflight + +```task +id: WARDEN-WP-0016-T01 +status: done +priority: high +state_hub_task_id: "fea84495-dbec-480a-b42b-90e39f414b78" +``` + +- [x] `scripts/check_tunnel_cert_readiness.py` — given `--actor`, `--pubkey`, `--config` + (warden.yaml) and optional `--infra` (ssh_principals.yaml), asserts the cert_command + path is ready **without signing anything**: config loads + backend known; actor in + inventory with a valid type + TTL within the type max; pubkey file exists, parses, + and is not a private key; actor principals present; (optional) principals deployed + in the infra file (mirrors `check_principals_drift._infra_principals`). Exit 0/1/2. +- [x] Checklist-style report (✓/✗/·); never prints a private key or token. +- [x] Tests: `tests/test_tunnel_cert_readiness.py` (ready, unknown actor, missing/private + pubkey, infra present/missing, TTL-over-max, cert_command string). 9 unit cases. + +### T2 — Offline cert_command contract smoke + +```task +id: WARDEN-WP-0016-T02 +status: done +priority: medium +state_hub_task_id: "e34ae1a8-2ba9-4324-8d1a-005d61dae478" +``` + +- [x] Opt-in `--sign-smoke` mode runs the actual `cert_command` against the **local** + backend and validates the emitted cert: identity matches the actor, principals match + inventory, validity window within the type's max TTL. Refuses a vault backend (must + be offline). Proves the contract end to end with no live OpenBao. +- [x] Window measured from the cert's own `valid_from`→`valid_before` (via + `parse_cert_metadata`) so it is timezone-robust — fixes a CEST off-by-2h artifact + where local-time ssh-keygen output was read as UTC. +- [x] `integration`-marked test (needs `ssh-keygen`, skipped in the default suite) plus a + non-integration test that `--sign-smoke` refuses a vault backend. + +### T3 — Playbook gate + ops-bridge handoff + +```task +id: WARDEN-WP-0016-T03 +status: done +priority: medium +state_hub_task_id: "330e01f4-4927-4280-b0e0-49d35b4416d6" +``` + +- [x] `wiki/playbooks/ops-bridge-tunnel-cert.md` now leads with **Step 0 — Readiness gate** + (the exact `check_tunnel_cert_readiness.py` invocation + `--sign-smoke` note); the + manual checklist remains as the human-readable backing. +- [x] Sent ops-bridge the coordination handoff (pilot `agt-state-hub-bridge`, the + readiness-gate command, and the cutover steps ops-bridge owns). + +### T4 — INTENT/SCOPE alignment + +```task +id: WARDEN-WP-0016-T04 +status: done +priority: low +state_hub_task_id: "4726f5bb-4ffd-484f-8674-91ee5658434f" +``` + +- [x] SCOPE: INTENT gap row moved from "Partial — tunnels still static-key" to + "Pilot-ready — readiness gate shipped; live cutover handed to ops-bridge"; known-gaps + row updated; readiness script added to the implemented SSH-lane list. + +--- + +## Acceptance + +- `scripts/check_tunnel_cert_readiness.py` gates the pilot read-only and is tested. +- The offline contract smoke validates a real cert against the local backend. +- The playbook leads with the automated gate; ops-bridge has the handoff with exact steps. +- No secret material in any script, test, doc, or log. ops-warden's boundary is intact: + it verifies and hands off; ops-bridge executes the cutover. + +--- + +## See also + +- `wiki/playbooks/ops-bridge-tunnel-cert.md`, `wiki/CertCommandInterface.md` +- `scripts/check_principals_drift.py` (reused helpers) +- `history/2026-06-24-intent-scope-gap-analysis.md` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0017-access-front-door-discoverability.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0017-access-front-door-discoverability.md new file mode 100644 index 00000000..fe9c5b15 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0017-access-front-door-discoverability.md @@ -0,0 +1,120 @@ +--- +id: WARDEN-WP-0017 +type: workplan +title: "Access front-door discoverability — stop reading as SSH-only" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 17 +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "cf8b392e-7624-4585-8935-a85e29202935" +--- + +# WARDEN-WP-0017 — Access front-door discoverability + +**Problem:** WP-0014 made ops-warden the operator **access front door** — for +`exec_capable` lanes (OpenBao reads, key-cape login) `warden access --fetch/--exec` +proxies the fetch **as the caller** and streams the value to them (ops-warden holds +nothing). But every *discovery* surface still tells the pre-WP-0014 story, so agents +(e.g. whynot-design needing `NPM_AUTH_TOKEN`) conclude "ops-warden only issues SSH certs +and replies with a pointer, not a token" and never find the proxy. + +**Fix:** propagate the WP-0014 conduit charter to the surfaces agents actually read. This +is a *messaging/discoverability* change — **no** change to the security model: the conduit +stays a conduit (no custody, no standing broker; the responsibility-map boundary holds). + +**Out of scope:** ops-warden holding/brokering token values (that would override the +WP-0014 charter); shipping the concrete OpenBao npm KV path (railiance-platform infra — +tracked separately); any new fetch capability (the proxy already exists). + +**Depends on:** WP-0014 (the proxy lane being described). + +--- + +## Surfaces that mislead today + +| Surface | Says now | Should say | +| --- | --- | --- | +| `warden route` table `warden` column | binary `issue` / `route` | `issue` / **`assist`** (exec_capable) / `route` | +| `warden route` `--json` | no proxyability field | add `warden_role` + `exec_capable` | +| `warden access` closing line | "warden advises, the owner vends" | for exec_capable: "ops-warden can fetch this for you as the caller…" | +| `.claude/rules/credential-routing.md` | "issues SSH certs **only**… reply is a pointer, not a key" | issues SSH certs **and** is the access front door; exec_capable lanes proxy as you | +| Federated capability registry | only "SSH certificate issuance" | also "Operator access front door / caller-identity fetch proxy" | +| SCOPE one-liner + capability block | SSH + routing + posture | add the access-assist/proxy front door | + +--- + +## Tasks + +### T1 — CLI discoverability: route role + access framing + +```task +id: WARDEN-WP-0017-T01 +status: done +priority: high +state_hub_task_id: "6e98df42-b5b4-49f8-a444-3c6346c8abd7" +``` + +- [x] `warden route` table: three-valued `warden` column — `issue` / `assist` + (exec_capable) / `route`. `_entry_summary` JSON gains `warden_role` + `exec_capable`; + `route show` JSON `next_action` surfaces the proxy for exec_capable lanes. +- [x] `warden access` closing line: for `exec_capable` lanes leads with "ops-warden can + fetch this for you as the caller (`--fetch`/`--exec`); runs the owner's tool with + your identity, value never held/cached/logged." Non-exec lanes keep "advises, owner + vends." `_access_json` `next_action` mirrors it. +- [x] Tests in `tests/test_routing.py` (warden_role issue/assist) and `tests/test_access.py` + (front-door framing for exec lane, owner-vends for route-only lane). 210 pass. + +### T2 — Agent rule + SCOPE reframe + +```task +id: WARDEN-WP-0017-T02 +status: done +priority: high +state_hub_task_id: "6e2a7067-1afc-4f38-8d99-4d5c36a4661c" +``` + +- [x] `.claude/rules/credential-routing.md`: reframed the lead ("issues SSH certs **and** + is the operator access front door…") and the quick routing table (`ops-warden role` + column: Issue / Assist / Route). Kept the true anti-pattern: don't POST a State Hub + message for a secret *value* — it comes from the CLI front door run as you. +- [x] SCOPE one-liner reframed to "steward **and front door**"; added a second `capability` + block "Operator access front door (caller-identity fetch proxy)". + +### T3 — Federated capability registration + +```task +id: WARDEN-WP-0017-T03 +status: done +priority: medium +state_hub_task_id: "7199625b-e78e-4495-8ca0-076100ae9f08" +``` + +- [x] Registered the State Hub capability "Operator access front door (caller-identity + fetch proxy)" (id `708e46f6`, repo ops-warden) — the hub had **no** ops-warden + security capability before, so the front door was undiscoverable cross-domain. +- [x] Sent whynot-design (msg `83a3bb2e`) the corrected path: `warden access "npm auth + token" --fetch/--exec`, the CLI refresh, the OpenBao-auth prereq, and the + railiance-platform path caveat. + +--- + +## Acceptance + +- An agent doing the first-line `warden route find` / `--json` lookup can see ops-warden + *assists* (proxies) the OpenBao lane, not merely points. +- The credential-routing rule and federated capability registry describe the access + front door; none of them say "SSH certificates only". +- The conduit boundary is unchanged and explicit: ops-warden fetches *as the caller* and + holds nothing — no custody, no broker. + +--- + +## See also + +- `WARDEN-WP-0014` (the proxy lane), `wiki/OperatorAccessAssist.md` +- `.claude/rules/credential-routing.md`, `registry/routing/catalog.yaml` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md new file mode 100644 index 00000000..f923be53 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0018-whynot-design-npm-lane-activation.md @@ -0,0 +1,103 @@ +--- +id: WARDEN-WP-0018 +type: workplan +title: "Activate whynot-design npm publish lane + resolvable readiness flag" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 18 +created: "2026-06-29" +updated: "2026-06-29" +state_hub_workstream_id: "1256aca2-5979-4d21-818e-0de42c5d811b" +--- + +# WARDEN-WP-0018 — whynot-design npm lane activation + `resolvable` flag + +**Trigger:** railiance-platform completed provisioning the whynot-design npm publish lane +(CCR-2026-0001, commit 8f617fc): `status=active`, `access_frontdoor.readiness=ready`, +`resolvable=true`, positive fetch passed + negative (non-whynot) login denied. They asked +ops-warden to activate the dedicated catalog selector and notify whynot-design. This is the +first concrete `warden access --fetch`-resolvable non-SSH lane — the end-to-end proof of the +WP-0014 conduit + WP-0017 discoverability work. + +**whynot-design's spec** (msg 2687dc31) drove the shape: zero-placeholder command keyed by a +stable id, owner-confirmed concrete path/field/role, a machine-readable readiness flag, and a +publish-vs-read scope split. + +**Boundary unchanged:** ops-warden holds no token; the lane proxies the read as the caller. + +--- + +## Tasks + +### T1 — Concrete catalog entry + playbook + +```task +id: WARDEN-WP-0018-T01 +status: done +priority: high +state_hub_task_id: "189d0883-22b9-42dc-bda0-89460509a87d" +``` + +- [x] Added `whynot-design-npm-publish` to `registry/routing/catalog.yaml` (`status: active`, + `exec_capable`, `lane: secret`) with the **owner-confirmed, zero-placeholder** handoff: + path `platform/workloads/coulomb/whynot-design/npm-publish` (the superseded + `whynot-design/whynot-design/…` form is **not** used), field `NPM_AUTH_TOKEN`, OIDC + `bao login -method=oidc -path=netkingdom role=whynot-design-workload-kv-read`, policy + `workload-kv-read-whynot-design-npm-publish`, flex-auth `secret.read:whynot-design`. +- [x] `wiki/playbooks/whynot-design-npm-publish.md` — worker checklist, scopes, operator + go-ahead note (publish is immutable + outward-facing). Catalog `wiki_ref` points to it. +- [x] Passes the `_assert_no_secret_material` guard (templates/identifiers only, no value). + +### T2 — `resolvable` readiness flag + stable-id resolution + +```task +id: WARDEN-WP-0018-T02 +status: done +priority: high +state_hub_task_id: "b5dc1013-5334-43ff-afd6-1f99d521358f" +``` + +- [x] `RouteEntry.resolvable` — true when a lane is active, exec_capable, and its fetch + command/path carry **no** unresolved `<…>` placeholder. Surfaced in the route/access + `--json` (`_entry_summary`). Generic `openbao-api-key` and the `` login lane + report `false`; `whynot-design-npm-publish` reports `true`. +- [x] `Catalog.find` now resolves an **exact catalog-id** match first, so + `warden access whynot-design-npm-publish …` is deterministic regardless of keyword + collisions (whynot-design's "stable keyed command"). +- [x] Tests: `tests/test_routing.py` (concrete+resolvable lane, template lanes not + resolvable, exact-id wins); fixed a `test_access` no-match query that incidentally + substring-collided (`no` ⊂ `whynot`). 213 pass, lint clean. + +### T3 — Close the loop + +```task +id: WARDEN-WP-0018-T03 +status: done +priority: medium +state_hub_task_id: "95b00ef8-477a-4f0d-bd71-6154fba401f5" +``` + +- [x] Notified whynot-design (reply 744977ae) with the zero-placeholder command + `warden access whynot-design-npm-publish --exec -- npm publish`, the `resolvable` gate, + the coulomb-tenant path correction, and the operator-go-ahead reminder. +- [x] Confirmed activation to railiance-platform (reply f76d3a9e). Sibling lanes + (`issue-core-ingestion-api-key`, `openrouter-llm-connect`) stay `draft` per their + deferral, pending CCR-2026-0002/0003 provisioning. + +--- + +## Acceptance + +- `warden access whynot-design-npm-publish` resolves to a concrete, owner-confirmed, + zero-placeholder lane; `--json` reports `resolvable: true`. +- Template/generic lanes report `resolvable: false`; exact-id lookup is deterministic. +- No secret value in catalog, playbook, tests, or logs; ops-warden holds nothing. + +## See also + +- `WARDEN-WP-0014` (proxy lane), `WARDEN-WP-0017` (discoverability) +- railiance-platform CCR-2026-0001, `docs/workload-kv-access-lanes.md` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0019-route-to-secrets-engine.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0019-route-to-secrets-engine.md new file mode 100644 index 00000000..602fad1b --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0019-route-to-secrets-engine.md @@ -0,0 +1,89 @@ +--- +id: WARDEN-WP-0019 +type: workplan +title: "Route secret-exec lanes to secrets-engine (route-primary, proxy fallback)" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 19 +created: "2026-06-29" +updated: "2026-06-29" +state_hub_workstream_id: "5e49abb6-497f-4640-a484-2da5f39a7c4e" +--- + +# WARDEN-WP-0019 — Route secret-exec lanes to secrets-engine + +**Trigger:** secrets-engine (SECRETS-WP-0003, msg 765a03f0) shipped a native secret-exec +front door — `secrets-engine route --json` and `secrets-engine exec --catalog -- +` with canonical decision ids — and asked ops-warden to **route to it**. This is the +owner-native execution lane that ops-warden's `warden access --exec` proxy was filling as a +stopgap (WP-0014). whynot-design already published `@whynot/design@0.4.0` through the proxy +on this same lane, so both paths resolve today. + +**Decision (Bernd, 2026-06-29): route-primary, proxy-fallback.** For lanes secrets-engine +owns, ops-warden surfaces `secrets-engine exec/route` as the **primary** path and keeps its +own `warden access --exec` as a documented **transparent fallback**. ops-warden stays the +discovery front door; secrets-engine is the exec owner. Boundary unchanged: ops-warden holds +or stores no token on either path. + +**Out of scope:** ops-warden invoking `secrets-engine exec` itself (it routes/points, the +caller runs it); changing the proxy's security model; the production policy-gate flip. + +--- + +## Tasks + +### T1 — Catalog + CLI: surface the owner-native exec front door + +```task +id: WARDEN-WP-0019-T01 +status: done +priority: high +state_hub_task_id: "ea153605-7a14-4db7-8bce-d780ea143f8a" +``` + +- [x] `RouteEntry` gains `exec_owner` / `exec_command` / `pointer_command` (pointers only, + screened by `_assert_no_secret_material`) and a `has_native_exec` property. +- [x] `whynot-design-npm-publish` entry: `exec_owner: secrets-engine`, + `exec_command: secrets-engine exec --catalog whynot-design-npm-publish -- `, + `pointer_command: secrets-engine route whynot-design-npm-publish --json`. Keep the + existing `fetch_command`/`exec_capable` (the proxy fallback). +- [x] `warden access`: when `exec_owner` is set, render the secrets-engine exec as the + **primary** line and the `warden access --exec` proxy as the **fallback**; JSON gains + `exec_owner`/`exec_command`/`pointer_command`. `route find/show` JSON too. +- [x] Tests in `tests/test_routing.py` / `tests/test_access.py`. + +### T2 — Agent rule, SCOPE, playbook + +```task +id: WARDEN-WP-0019-T02 +status: done +priority: medium +state_hub_task_id: "96059b8a-8938-4763-b3d0-cc5a0eb2465c" +``` + +- [x] `.claude/rules/credential-routing.md`: add secrets-engine as the secret-exec owner; + for OpenBao-backed secret lanes the route is "secrets-engine `exec` (primary), + ops-warden `warden access --exec` (transparent fallback)". +- [x] SCOPE: add secrets-engine to Related Repos + the routing model; note the + whynot-design lane is **production-exercised** (real 0.4.0 publish), not just resolvable. +- [x] `wiki/playbooks/whynot-design-npm-publish.md`: lead with the secrets-engine exec + command; fix the fallback one-liner per whynot-design's field notes + (`--field NPM_AUTH_TOKEN`, and `--no-policy` while `policy.enabled=false`). + +--- + +## Acceptance + +- `warden access whynot-design-npm-publish` shows the secrets-engine exec as primary and the + warden proxy as fallback; `--json` carries `exec_owner`/`exec_command`. +- The credential-routing rule names secrets-engine as the secret-exec owner. +- No secret material anywhere; ops-warden holds no token on either path. + +## See also + +- secrets-engine SECRETS-WP-0003, decision e6381a56, `docs/whynot-design-real-publish-closeout.md` +- `WARDEN-WP-0014` (proxy), `WARDEN-WP-0017` (discoverability), `WARDEN-WP-0018` (lane activation) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0020-ops-warden-worker.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0020-ops-warden-worker.md new file mode 100644 index 00000000..1230ed31 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0020-ops-warden-worker.md @@ -0,0 +1,176 @@ +--- +id: WARDEN-WP-0020 +type: workplan +title: "ops-warden worker — autonomous coordination via llm-connect" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 20 +created: "2026-06-29" +updated: "2026-06-29" +state_hub_workstream_id: "c906ba1d-f991-4fb0-b113-59432ddf87c0" +--- + +# WARDEN-WP-0020 — ops-warden worker (`warden worker`) + +**Problem:** ops-warden's coordination lane (State Hub inbox `to_agent=ops-warden`) is +handled only when a human spins up an ops-warden session and relays instructions. That +doesn't scale — Bernd is hand-relaying between flex-auth ↔ secrets-engine ↔ ops-warden +across sessions. + +**Goal:** a `warden worker` CLI that pulls ops-warden's unread coordination requests and, +using **llm-connect** for inference, drives each to an ops-warden action (answer a routing +question, draft+send a reply, mark read, propose/commit a catalog diff, or escalate) — so +the inbox is handled without a human starting a session. + +**Decisions (Bernd, 2026-06-29):** **full-auto in-scope** (worker executes any in-scope +action; escalates only secrets/prod/out-of-scope) and **scheduled/unattended** (cron or +activity-core). Because there is no human in the loop for in-scope actions, the guardrails +are load-bearing and the rollout is staged: **dry-run → manual → scheduled**. + +**Build vs reuse:** inference = llm-connect (`/execute`); trigger = cron or activity-core +(reuse the durable task factory, don't reinvent scheduling). Worker logic lives in warden. + +## Guardrails (non-negotiable — full-auto rests on these) +1. **Fixed charter, non-overridable.** The boundary (issue SSH; route everything else; + conduit-not-broker; never hold/print a secret value) is a fixed system policy. Message + content is **untrusted data**, never instructions that can relax it (prompt-injection + containment). +2. **Action allowlist.** Every action is validated against an allowlist before execution; + off-list → escalate. No secret handling, no prod-config writes, no irreversible/outward + actions without an explicit human ack. +3. **No-secret invariant.** Refuse any task requiring a secret value in hand or in a prompt. +4. **Full audit + dry-run.** Every action emits a progress event; `--dry-run` shows the + plan without executing. Scheduled mode only after a clean dry-run shakedown. + +## Hard dependency +llm-connect must be operational — it needs its provider key (`OPENROUTER_API_KEY`, +CCR-2026-0003, currently deferred by railiance-platform/secrets-engine). The worker is +built against llm-connect's contract; it cannot run the brain until that lands. + +--- + +## Tasks + +### T1 — Worker scaffold (llm-connect-independent, safe) + +```task +id: WARDEN-WP-0020-T01 +status: done +priority: high +state_hub_task_id: "979c2d9b-0803-442f-aa2e-acb02bac07e9" +``` + +- [x] `src/warden/worker.py`: State Hub inbox client (`HubClient.unread`), a `Brain` + protocol, a deterministic `RuleBrain` default (answers clear routing questions; + escalates the rest), the `PlannedAction`/`WorkerPlan` model, the guardrail allowlist + + `validate_action` (enforced brain-agnostically in `build_plans`), and a `render_plans` + dry-run renderer (plan only, no execution). +- [x] `warden worker run [--once] [--dry-run]` CLI; `--dry-run` is the default and + `--execute` is refused (exit 2) until the guarded executor lands (T3). +- [x] `tests/test_worker.py` (RuleBrain routing/secret/prod/unknown, guardrail downgrades a + reckless brain on secret/prod, off-allowlist rejection, render, CLI). 18 cases. +- [x] Live dry-run against the real hub verified — read the inbox and produced a guardrailed + plan (it surfaced secrets-engine's OIDC-role reply, demonstrating the value). + +### T2 — llm-connect brain + +```task +id: WARDEN-WP-0020-T02 +status: done +priority: high +state_hub_task_id: "52d281b2-7d48-44f5-b77e-80e3ed500b5f" +``` + +- [x] llm-connect brought operational (operator set OPENROUTER_API_KEY k8s secret + restart). + Contract discovered empirically from the running service: `POST /execute {"prompt":...}` + → `{"content": "", ...}` (no OpenAPI; custom JSON API). End-to-end verified (pong). +- [x] `LlmConnectBrain` (src/warden/worker.py): embeds the fixed charter + the message as + untrusted data into the prompt, calls `/execute`, parses a JSON action plan + (`_extract_json` tolerates fences/prose), and defensively escalates on malformed/empty/ + transport-error. Configurable `LLM_CONNECT_URL`. The guardrail pass still enforces the + allowlist + no-secret invariant on whatever the model returns. +- [x] `warden worker run --brain rule|llm` selector (dry-run default). Tests: + `tests/test_worker.py` (extract_json, parse, escalate-on-flag/malformed/transport, + guardrail-catches-unsafe-LLM-action). **Live verified** against the real inbox: the LLM + brain produced a sensible reply+mark_read for the secrets-engine message and correctly + escalated the llm-connect secret-custody request. 236 tests, lint clean. + +### T3 — Action dispatch + guardrails (full-auto in-scope) + +```task +id: WARDEN-WP-0020-T03 +status: done +priority: high +state_hub_task_id: "3a71965e-42d5-4258-9761-aced804c88e7" +``` + +- [x] `HubClient` gained writes (`mark_read`, `send_reply`, `add_progress`); `execute_plan` + / `execute_plans` run the **safe, allowlisted** actions — route_answer (reply with the + computed answer + auto mark-read), reply (with an LLM-drafted body), progress_note, + mark_read. Escalated plans and non-auto-executable kinds are left for a human. +- [x] **Deliberate guardrail:** `propose_catalog_diff` (and any code/routing change) is NOT + auto-executed even under full-auto — a bad catalog commit could misroute credentials, + so it goes to human review (recoverability over convenience). AUTO_EXECUTABLE is the + messaging/hub tier only. No secret value is ever read, sent, or logged. +- [x] `warden worker run --execute` runs the guarded executor (dry-run still the default); + per-message audit summary. Tests in `tests/test_worker.py` (route_answer reply+mark, + reply-with/without-body, escalated skip, catalog-diff left-for-human, progress_note, + failure-without-crash). 243 pass, lint clean. +- [x] **Conservative tier is now the `--execute` default (Bernd's Option A, 2026-06-30):** + `run_conservative` triages NEW messages into a reviewed digest (`worker-digest.md`) + with drafted replies, posts ONE progress note, tracks seen ids (schedule-safe dedup), + and sends **nothing** to other agents / marks nothing read. `--full-auto` opts into the + auto-send path. Live-verified with the LLM brain: produced a high-quality draft reply + to secrets-engine and flagged the llm-connect request as NEEDS YOU. 244 tests. + Rationale: the guardrails prevent *security* harm but not LLM *content* errors, so replies + stay drafts-for-approval until quality is proven — matches the build-stage/recoverability + posture. Conservative mode is safe to schedule (T4). + +### T4 — Scheduled trigger + +```task +id: WARDEN-WP-0020-T04 +status: done +priority: medium +state_hub_task_id: "7f77ea6d-c281-42c5-ad25-2a0bb9fd68de" +``` + +- [x] `scripts/worker-tick.sh` — scheduled tick for the conservative worker. `flock` + concurrency guard (no overlapping runs); brings up a short-lived kubectl port-forward + to llm-connect (or honors `LLM_CONNECT_URL`, or falls back to the rule brain offline). + Ships **disabled**; the header documents the cron entry to enable it (every 15 min). + Dry-shakedown done (the conservative live run + the rule-brain tick both verified). + Schedules the **conservative** tier only — never the auto-send path. + +### T5 — Docs / SCOPE / INTENT + +```task +id: WARDEN-WP-0020-T05 +status: done +priority: medium +state_hub_task_id: "6e7ae317-7f8b-468a-bb5c-b08093ed43a0" +``` + +- [x] SCOPE: recorded the coordination worker (`warden worker`) as an implemented + capability — conservative triage default, full-auto opt-in, llm-connect brain, the + four guardrails, schedulable tick. The guardrails + the conservative-by-default + posture are documented as the worker's security-model statement (here + in the + build-stage decision 813899f9). + +--- + +## Acceptance + +- `warden worker run --dry-run` reads the real inbox and prints a guardrailed plan. +- Full-auto execution runs only in-scope, allowlisted actions; secrets/prod/out-of-scope + escalate; every action is audited. No secret value ever enters a prompt, log, or commit. +- Scheduled mode is enabled only after a dry-run shakedown. + +## See also + +- llm-connect (inference), activity-core (durable trigger), kaizen-agentic (personas) +- `.claude/rules/credential-routing.md` (the boundary the worker enforces) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md new file mode 100644 index 00000000..2500d4b3 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0021-enable-scheduled-worker-tick.md @@ -0,0 +1,142 @@ +--- +id: WARDEN-WP-0021 +type: workplan +title: "Enable the scheduled worker tick — conservative inbox triage, unattended" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 21 +created: "2026-06-30" +updated: "2026-06-30" +state_hub_workstream_id: "8c487014-b630-4016-a4f0-31b971a473d2" +--- + +# WARDEN-WP-0021 — Enable the scheduled worker tick + +**Goal:** turn the WP-0020 conservative worker from *built-but-disabled* into a reliable, +unattended schedule — so ops-warden's State Hub inbox is auto-triaged into a digest of +**drafted replies** the operator reviews and approves, without anyone starting a session. +This is the payoff of WP-0020: it ends the cross-session relay toil. + +**Posture (unchanged):** schedule the **conservative** tier only — triage + draft, never +auto-send (Option A / build-stage decision `813899f9`). The four guardrails hold. Easy +kill switch is a requirement, not an afterthought (recoverability). + +**What "enabled" means here:** (1) the tick runs on a schedule and survives the failure +modes (hub/llm-connect down → graceful degrade), (2) the operator actually *sees* new +drafts, (3) the operator can *act* on a draft with one command, (4) it's trivial to stop. + +**Out of scope:** the full-auto (auto-send) path; flipping `policy.enabled`; moving the +worker off the workstation. + +**Depends on / relates to:** WP-0020 (the worker + `scripts/worker-tick.sh`); the State +Hub migration to railiance01 (`cust-wp-0011`/`0038`) may change `WARDEN_HUB_URL` later — +the tick already honors that env var. + +--- + +## Decisions to settle (first) + +- **Scheduler:** `systemd --user` timer (recommended — clean logs via `journalctl`, + `systemctl --user status`, built-in scheduling) vs. plain cron (simplest) vs. + activity-core (ecosystem-native durable trigger; heavier for build stage). Recommend the + systemd user timer; cron documented as the one-liner fallback. +- **Cadence:** every 15 min (default) — adjustable. +- **llm-connect reachability:** per-tick short-lived port-forward (current behaviour) with + rule-brain fallback, vs. a persistent forward. Recommend keeping the per-tick forward + + fallback for build stage (no standing process). + +--- + +## Tasks + +### T1 — Scheduler install + enablement + kill switch + +```task +id: WARDEN-WP-0021-T01 +status: done +priority: high +state_hub_task_id: "10451fe6-7fab-4ae0-8494-e6cfdfbcf8cf" +``` + +- [ ] `systemd --user` timer + service units (`ops-warden-worker.{service,timer}`) that run + `scripts/worker-tick.sh` on the chosen cadence, with `WARDEN_HUB_URL` / `WORKER_BRAIN` + from an env file. Install script + documented cron fallback one-liner. +- [ ] Concurrency is already guarded by the tick's `flock`; verify under the timer. +- [ ] **Kill switch:** `systemctl --user disable --now ops-warden-worker.timer` (and the + env-file `WORKER_ENABLED=0` short-circuit) — one command to stop, documented. + +### T2 — Scheduled-run robustness (graceful degradation) + +```task +id: WARDEN-WP-0021-T02 +status: done +priority: high +state_hub_task_id: "1f35f816-1af5-46ff-b48c-1715f3ae5784" +``` + +- [ ] Harden `worker-tick.sh` for unattended runs: bounded timeouts, hub-unreachable → + clean skip + log (no crash loop), llm-connect-unreachable → rule-brain fallback + (already present; verify), non-zero exit only on real faults. +- [ ] End-to-end verify a real timer-fired tick: new message → digest + progress note; + no new message → no-op; hub down → graceful skip. + +### T3 — Operator visibility (see new drafts) + +```task +id: WARDEN-WP-0021-T03 +status: done +priority: medium +state_hub_task_id: "3c7f6423-8db0-4bc6-b67d-078d9d929c6d" +``` + +- [ ] Surface new drafts beyond the file: desktop `notify-send` on new digest (when a + display is present) and/or keep the hub progress note as the durable signal. +- [ ] `warden worker status` — last run time, pending-draft count, digest path, timer state. + +### T4 — Review→send loop (`warden worker approve`) + +```task +id: WARDEN-WP-0021-T04 +status: done +priority: high +state_hub_task_id: "dabc9fc0-abb1-4e9d-b87e-5f0c5950693c" +``` + +- [ ] Persist structured drafts during the tick (`state_dir/worker-drafts.json`: + message_id → to_agent, subject, drafted body, thread_id — no secret material). +- [ ] `warden worker approve [--edit]` — send the reviewed draft as the + caller's reply + mark read; `warden worker drafts` to list pending. This is what makes + the scheduled digest *actionable* in one command instead of hand-composing. + +### T5 — Runbook + SCOPE + +```task +id: WARDEN-WP-0021-T05 +status: done +priority: medium +state_hub_task_id: "9915da96-1b33-4d0f-b752-408ea8d43333" +``` + +- [ ] `wiki/playbooks/scheduled-worker.md` — enable/disable, cadence, the approve workflow, + failure modes, and the build-stage posture (conservative only). SCOPE note. + +--- + +## Acceptance + +- A `systemd --user` timer (or cron) runs the conservative tick unattended; one command + disables it. +- A timer-fired tick triages new messages into a digest + progress note and degrades + gracefully when the hub or llm-connect is down. +- The operator is notified of new drafts and can send a reviewed draft with + `warden worker approve `. +- Still conservative: nothing is auto-sent; no secret value is read, sent, or logged. + +## See also + +- `WARDEN-WP-0020` (the worker + `scripts/worker-tick.sh`), build-stage decision `813899f9` +- `cust-wp-0011`/`cust-wp-0038` (State Hub → railiance01; future `WARDEN_HUB_URL`) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0022-audit-trail-and-activity.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0022-audit-trail-and-activity.md new file mode 100644 index 00000000..63171f58 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0022-audit-trail-and-activity.md @@ -0,0 +1,119 @@ +--- +id: WARDEN-WP-0022 +type: workplan +title: "Audit trail + `warden activity` — one place to see what ops-warden did" +domain: infotech +repo: ops-warden +status: finished +owner: claude +topic_slug: custodian +planning_priority: high +planning_order: 22 +created: "2026-07-01" +updated: "2026-07-01" +state_hub_workstream_id: "fc8afa28-68a7-4250-a19e-9754829f0cd5" +--- + +# WARDEN-WP-0022 — Audit trail + `warden activity` + +**Problem:** ops-warden's actions are recorded in scattered places — `signatures.log` +`access-audit.log`, the systemd journal (worker ticks), and +State Hub progress notes (the narrative). There is **no single, structured audit trail** +and no one command to answer *"what did ops-warden do in the last N days?"*. For a security +steward, a coherent, metadata-only audit record is table stakes. + +**Goal:** a unified, append-only audit log that captures **every** ops-warden action with a +common shape (never a secret value), and a single `warden activity` command to read it. + +**Non-negotiable (this is a security tool's audit):** the audit record holds **metadata +only** — actor/subject, action, target/path id, decision id, TTL, outcome, timestamp — and +**never** a token, key, cert body, or other secret. A secret-material guard rejects any +event field that looks like a value (mirrors the catalog `_assert_no_secret_material`). + +**Posture:** read/append-only, in-boundary (local logs + optional hub read). Tamper-evident +hash-chaining is noted as an optional hardening for when the ecosystem reaches testing. + +**Relates to:** WP-0014 (`access-audit.log`), the SSH lane (`signatures.log`), WP-0020/0021 +(the worker). Linger is now enabled (worker survives logout); full logged-out value also +needs the State Hub + tunnels to be login-independent (State Hub → railiance01, +`cust-wp-0011`). + +--- + +## Tasks + +### T1 — Unified audit event log + +```task +id: WARDEN-WP-0022-T01 +status: done +priority: high +state_hub_task_id: "7f8f768a-4c62-4096-bad8-912cea0f35a7" +``` + +- [x] `src/warden/audit.py`: append-only JSONL at `state_dir/audit.jsonl`. Common event + schema — `ts`, `kind` (`sign`|`access`|`worker`), `action`, `subject`, `target`, + `decision_id`, `outcome`, `source`. `record_event(**meta)` with a secret-material + guard (reject token prefixes / high-entropy runs) so no value can ever land here. + `read_events(*, since, kinds)` for the reader. +- [x] Log rotation / bound (size or age) so it stays manageable. + +### T2 — Instrument the actions + +```task +id: WARDEN-WP-0022-T02 +status: done +priority: high +state_hub_task_id: "e7ae4037-ca79-4557-81f0-bfb8478ff647" +``` + +- [x] Emit an audit event from each ops-warden action: `warden sign` (cert issued — + actor, type, ttl, backend, policy_decision_id), `warden access --fetch/--exec` + (proxy — need id, owner, decision id), and the worker (`approve` → reply sent to X; + tick → triage summary N/drafted/escalated). Fold the existing `signatures.log` / + `access-audit.log` in as sources (keep back-compat; don't drop a record). +- [x] Assert no secret value reaches the audit in any path (tests). + +### T3 — `warden activity` command + +```task +id: WARDEN-WP-0022-T03 +status: done +priority: high +state_hub_task_id: "4439bdd8-1461-47df-8b0b-048df7384a68" +``` + +- [x] `warden activity [--days N] [--kind sign|access|worker] [--json] [--hub]` — a single + chronological view merging the audit log (and, for back-compat, `signatures.log` / + `access-audit.log`); `--hub` also pulls recent ops-warden State Hub progress notes for + the narrative. Human table by default; stable `--json` for agents. + +### T4 — Tests, runbook, SCOPE + +```task +id: WARDEN-WP-0022-T04 +status: done +priority: medium +state_hub_task_id: "bdfb8703-7a79-43e7-913b-19d61722f164" +``` + +- [x] Tests: audit append/read/rotation, the secret-material guard rejects values, the + instrumented actions emit events, `warden activity` filtering + `--json` shape. +- [x] `wiki/AuditTrail.md` (what's recorded, the no-secret guarantee, how to query, the + linger + login-independence note). SCOPE entry. + +--- + +## Acceptance + +- Every ops-warden action (sign, access proxy, worker send/tick) appends a metadata-only + audit event; the secret-material guard is proven to reject values. +- `warden activity --days 3` answers "what did ops-warden do" in one command; `--json` + gives agents a stable shape. +- No secret value appears in the audit log, ever. + +## See also + +- `WARDEN-WP-0014` (`access-audit.log`), `WARDEN-WP-0020`/`0021` (the worker) +- `wiki/OperatorAccessAssist.md` (the metadata-only audit principle) +- `wiki/AuditTrail.md` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md new file mode 100644 index 00000000..99278d60 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0023-intent-scope-alignment-closeout.md @@ -0,0 +1,222 @@ +--- +id: WARDEN-WP-0023 +type: workplan +title: "INTENT–SCOPE Alignment Closeout" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 23 +created: "2026-07-01" +updated: "2026-07-01" +depends_on_workplans: + - WARDEN-WP-0022 +state_hub_workstream_id: "7bad1ec4-a7c2-4980-b8f9-49a7f5408574" +--- + +# WARDEN-WP-0023 — INTENT–SCOPE Alignment Closeout + +## Goal + +Close the July 2026 INTENT↔SCOPE gaps that ops-warden can address directly: sync +aspirational docs with shipped capabilities, coordinate the remaining production +integration blockers (flex-auth flip, ops-bridge cutover), improve daily operator +UX for broker-backed signing, and establish a repeatable catalog promotion cadence. + +Audit implementation stays in **WARDEN-WP-0022**; this workplan sequences and +surrounds it. + +**Assessment:** `history/2026-07-01-intent-scope-gap-analysis.md` + +## Boundary + +- ops-warden does **not** deploy flex-auth, flip ops-bridge tunnels, or implement + the credential broker — it documents, coordinates, and routes. +- Production cutover evidence is captured here; execution remains with owning repos. + +--- + +## Tasks + +### T01 — Persist gap analysis + +```task +id: WARDEN-WP-0023-T01 +status: done +priority: high +state_hub_task_id: "52485c90-87fe-40b1-9db5-a51ebb957dd5" +``` + +Write and link `history/2026-07-01-intent-scope-gap-analysis.md` with success +criteria matrix, mission pillars, prioritized gaps, and workplan recommendation. + +Acceptance: + +- History file exists and is referenced from SCOPE and this workplan. +- State Hub progress note logged for the assessment. + +**2026-07-01:** Assessment written at +`history/2026-07-01-intent-scope-gap-analysis.md`. + +### T02 — Refresh INTENT.md + +```task +id: WARDEN-WP-0023-T02 +status: done +priority: high +state_hub_task_id: "9a9b3631-8948-45af-ace1-c19ee74ace4d" +``` + +Update `INTENT.md` so the aspirational doc reflects shipped reality without +becoming a second SCOPE: + +- Mission pillar #2: assist layer (`warden access`) and owner-native exec routing + (secrets-engine, railiance-platform credential broker). +- NetKingdom literacy table: add secrets-engine and credential broker rows. +- Credential flow diagram: broker vs secrets-engine vs OpenBao proxy vs SSH issue. +- flex-auth: caller-side policy gate shipped; production flip external (FLEX-WP-0007). +- Workload posture stewardship and coordination worker as steward capabilities. +- Evolution notes pointer to July gap analysis. + +Acceptance: + +- INTENT still describes direction, not implementation inventory. +- No contradiction with SCOPE 2026-07-01 boundary (ops-warden does not mint tokens). + +**2026-07-01:** INTENT.md updated. + +### T03 — Production integration coordination pack + +```task +id: WARDEN-WP-0023-T03 +status: done +priority: high +state_hub_task_id: "26f23798-494b-45fc-baa8-af27bdffa038" +``` + +Prepare operator/coordination artifacts for the two P1 external gaps: + +1. **flex-auth production flip** — checklist in `wiki/PolicyGatedSigning.md` or a + short playbook section: prerequisites, `policy.enabled: true` steps, rollback, + joint smoke with `credential-exec-ops-warden-smoke`, FLEX-WP-0007 cross-link. +2. **ops-bridge live cutover** — evidence template (non-secret): tunnel id, readiness + gate output, first warden-signed connection timestamp, pointer to + `wiki/playbooks/ops-bridge-tunnel-cert.md`. + +Optionally post State Hub coordination messages to `flex-auth` and `ops-bridge` +agents with pointers only (no secrets). + +Acceptance: + +- A human operator can run the flip/cutover checklists without re-deriving steps. +- Evidence fields are defined; completion is recorded via State Hub progress when done. + +**2026-07-01:** Rollback section added to `wiki/PolicyGatedSigning.md`; live cutover +evidence template added to `wiki/playbooks/ops-bridge-tunnel-cert.md`. + +### T04 — `warden sign` broker hint when `VAULT_TOKEN` unset + +```task +id: WARDEN-WP-0023-T04 +status: done +priority: medium +state_hub_task_id: "85e324f9-273d-4740-a202-9c4e8fb122ae" +``` + +When `backend: vault` and `VAULT_TOKEN` (or configured `token_env`) is missing, +emit a structured hint pointing at `ops-warden-warden-sign-token` and the +`railiance-platform` `credential exec` command — not a generic error only. + +Acceptance: + +- Unit test covers the hint text (catalog id + exec shape, no secret placeholders). +- Manual `export VAULT_TOKEN` remains documented as fallback in playbooks. + +**2026-07-01:** `src/warden/vault_hints.py` + `tests/test_vault.py`. + +### T05 — Catalog draft-lane promotion checklist + +```task +id: WARDEN-WP-0023-T05 +status: done +priority: medium +state_hub_task_id: "82608692-2845-41e1-a498-90ed53780748" +``` + +Document the promotion criteria for `registry/routing/catalog.yaml` entries from +`draft` → `active` (concrete path, owner confirmation, `resolvable` or +`exec_owner` native exec, playbook with `#worker-checklist`, tests). Add to +`wiki/CredentialRouting.md` or a short `wiki/playbooks/catalog-lane-promotion.md`. + +If any draft lane has owner-confirmed concrete paths during this WP, promote one +as a worked example (issue-core, OpenRouter, STS, or database — whichever is ready). + +Acceptance: + +- Checklist is reviewable by humans and agents. +- At least one promotion example or explicit “none ready yet” note in the workplan. + +**2026-07-01:** `wiki/playbooks/catalog-lane-promotion.md` — worked example +`ops-warden-warden-sign-token`; four draft lanes explicitly not ready. + +### T06 — SCOPE and workplan consistency + +```task +id: WARDEN-WP-0023-T06 +status: done +priority: medium +state_hub_task_id: "79ca7b9a-554e-4952-9393-a29b100f6190" +``` + +Fix SCOPE inconsistencies noted in the July assessment: + +- “All workplans finished” → acknowledge WP-0022/0023 as active/ready. +- Latest gap analysis pointer → `history/2026-07-01-intent-scope-gap-analysis.md`. +- Link WP-0023 from Getting Oriented. + +Acceptance: + +- SCOPE and gap analysis cross-link correctly. +- Uncommitted SCOPE edits from 2026-07-01 broker routing are committed with this WP. + +**2026-07-01:** SCOPE.md updated. + +### T07 — Sequence WP-0022 audit implementation + +```task +id: WARDEN-WP-0023-T07 +status: done +priority: high +state_hub_task_id: "1f3b3b33-974e-49bf-be4a-9d50b702c2a4" +``` + +Promote `WARDEN-WP-0022` from `proposed` to `ready` (or `active` when T02–T06 allow +bandwidth). Ensure dependency is explicit; log State Hub note that WP-0022 is the +implementation vehicle for INTENT pillar 6 (observable gatekeeping). + +Acceptance: + +- WP-0022 frontmatter status updated. +- WP-0023 `depends_on_workplans` includes WP-0022. +- Hub consistency run syncs both workplans. + +**2026-07-01:** WP-0022 implemented and both workplans marked `finished`. + +--- + +## Exit criteria + +- July gap analysis is the canonical reassessment (linked from SCOPE). +- INTENT.md no longer understates assist, posture, worker, or owner-native exec. +- Production integration checklists exist for flex-auth flip and ops-bridge cutover. +- `warden sign` surfaces the broker path when vault backend lacks a token. +- Catalog promotion cadence is documented; WP-0022 is queued for implementation. + +## See also + +- `history/2026-07-01-intent-scope-gap-analysis.md` +- `WARDEN-WP-0022-audit-trail-and-activity.md` +- `wiki/playbooks/ops-warden-warden-sign-token.md` +- `~/flex-auth/workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md new file mode 100644 index 00000000..3ebac662 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0024-experiential-memory-and-agent-sessions.md @@ -0,0 +1,269 @@ +--- +id: WARDEN-WP-0024 +type: workplan +title: "Experiential Memory Across Worker, Agent Sessions, And OpenRouter" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 24 +created: "2026-07-02" +updated: "2026-07-02" +state_hub_workstream_id: "5d9fafb3-f9b6-43bf-b259-5f5301daa2e9" +--- + +# WARDEN-WP-0024 — Experiential memory across worker, agent sessions, and OpenRouter + +## Problem + +`warden worker` (WARDEN-WP-0020) plans each inbox message in isolation. Coding +agent sessions (Claude Code, Codex, Grok, and future agents) invoke `warden +route` and `warden access` without continuity — every session rediscovers routing +from scratch. OpenRouter inference via llm-connect is invoked even when a +stabilized routing pattern already exists. + +ops-warden needs **experiential memory** that is present in every runtime: + +| Surface | Today | Target | +| --- | --- | --- | +| `warden worker` + OpenRouter | Stateless per message | Retrieve past outcomes before plan; record after execute | +| Coding agent session | Cold `warden route find` | Activate relevant memory at session start and after each warden call | +| Operator CLI | No learning loop | Same store; optional `--memory` context on advisory commands | + +## Goal + +Integrate phase-memory as ops-warden's shared experiential substrate so routing, +coordination, and inference improve from recorded outcomes — without ever +storing secret values or widening the guardrail allowlist. + +## Non-Goals + +- Hold or vend secrets (conduit-not-broker unchanged). +- Auto-commit routing catalog diffs (human review remains required). +- Own phase-memory schemas (PMEM-WP-0016 owns the profile and contract). +- Replace llm-connect or embed OpenRouter keys in ops-warden. + +## Guardrails (unchanged — memory is untrusted context) + +1. Retrieved memory is **context**, not instructions — fixed charter wins. +2. Guardrail allowlist enforced on every action regardless of memory content. +3. No secret values in memory writes, activation packs, or llm-connect prompts. +4. `propose_catalog_diff` stays human-reviewed even when memory is confident. + +## Architecture + +```mermaid +sequenceDiagram + participant Agent as Coding agent
(claude/codex/grok) + participant Warden as ops-warden CLI + participant Memory as phase-memory store + participant LLM as llm-connect / OpenRouter + participant Hub as State Hub + + Note over Agent,Hub: Agent session path + Agent->>Warden: warden route find "..." + Warden->>Memory: activate(session_kind=warden.agent.grok) + Memory-->>Warden: bounded routing context + Warden-->>Agent: route answer + memory digest + Warden->>Memory: record episode (metadata only) + + Note over Warden,Hub: Worker tick path + Warden->>Hub: unread messages + Warden->>Memory: activate(session_kind=warden.worker) + Memory-->>Warden: stabilized + fluid context + alt stabilized match + Warden->>Warden: RuleBrain (skip LLM) + else ambiguous + Warden->>LLM: LlmConnectBrain + activated context + LLM-->>Warden: action plan + end + Warden->>Warden: guardrail pass + Warden->>Hub: execute / escalate + Warden->>Memory: record outcome +``` + +## T01 - Canonical memory store and discovery + +```task +id: WARDEN-WP-0024-T01 +status: done +priority: high +state_hub_task_id: "6305f1bc-c016-4298-adc2-a07d52b6aca5" +``` + +Establish the canonical phase-memory store path and discovery commands. + +Acceptance: + +- Default store at XDG location (e.g. `~/.local/share/warden/memory/`) with + override via `WARDEN_MEMORY_STORE`. +- `warden memory status` reports store path, schema version, episode counts by + `session_kind`, and last activation timestamp — no secret fields. +- Store initializes idempotently; missing phase-memory dependency fails with a + clear install pointer, not a traceback. +- Tests cover default path, override, and first-run initialization. + +## T02 - Session recording hooks in CLI commands + +```task +id: WARDEN-WP-0024-T02 +status: done +priority: high +state_hub_task_id: "242a4d9a-5375-4df8-8d43-063b0491d202" +``` + +Record metadata-only episodes when `route`, `access`, and `sign` complete. + +Acceptance: + +- Each command writes a phase-memory event with `session_kind` derived from + environment: `WARDEN_AGENT_ID` (claude|codex|grok|...) when set, else + `warden.operator`. +- Recorded fields match `PMEM-WP-0016-T03` schema; secret patterns are rejected. +- Recording is opt-out via `WARDEN_MEMORY=0` for air-gapped/debug use. +- `warden activity` and phase-memory audit export remain consistent (no + duplicate secret-bearing logs). + +## T03 - Memory-aware worker tick + +```task +id: WARDEN-WP-0024-T03 +status: done +priority: high +state_hub_task_id: "176fcae1-e4e5-481f-9a83-e9a7000fac1a" +``` + +Retrieve coordination memory before `Brain.plan` and record outcomes after execute. + +Acceptance: + +- `warden worker run` activates memory with `session_kind=warden.worker` before + planning each message. +- Activated context is passed to `LlmConnectBrain` as bounded, redacted context + — never replacing the fixed charter. +- Post-execute hook records: message id, proposed actions, guardrail outcome, + escalation reason, and route ids referenced. +- Worker tick with empty store degrades gracefully (current behavior). + +## T04 - Agent session activation helper + +```task +id: WARDEN-WP-0024-T04 +status: done +priority: high +state_hub_task_id: "16501557-6cde-44ea-bc6f-1726cb7ec070" +``` + +Expose memory activation for coding agent sessions across Claude, Codex, Grok, and +future agents. + +Acceptance: + +- `warden memory activate [--agent ] [--json]` returns a bounded activation + package for session orientation. +- Agent instructions (AGENTS.md template in consuming repos) document setting + `WARDEN_AGENT_ID` and calling `warden memory activate` at session start. +- Activation works without OpenRouter (local retrieval only). +- Tests cover agent ids: `claude`, `codex`, `grok`, and an unknown future id. + +## T05 - Cross-runtime continuity + +```task +id: WARDEN-WP-0024-T05 +status: done +priority: high +state_hub_task_id: "55ae679c-c08f-4afd-8646-9f5f3019f86e" +``` + +Ensure worker ticks see agent session episodes and vice versa. + +Acceptance: + +- Agent session routing outcomes appear in worker activation within the same + store without manual export/import. +- Worker escalation outcomes are visible to subsequent agent session activations. +- Continuity is verified by an integration test: agent session write → worker + read → agent session read round-trip. +- Episode retention follows the ops-warden profile compaction rules from + PMEM-WP-0016. + +## T06 - OpenRouter efficiency layer + +```task +id: WARDEN-WP-0024-T06 +status: done +priority: medium +state_hub_task_id: "fc2dffcf-7184-4f3d-8653-d26dc18a9afc" +``` + +Skip or downgrade OpenRouter calls when stabilized memory provides a verified match. + +Acceptance: + +- When stabilized memory contains a verified route match for the message need, + `RuleBrain` handles the plan and llm-connect is not called. +- Ambiguous cases still use `LlmConnectBrain`; memory context is additive only. +- Efficiency metrics (llm_calls_avoided, rule_brain_resolution_rate) are + recorded for evaluation scenarios in PMEM-WP-0016. +- Dry-run mode reports whether LLM would have been skipped and why. + +## T07 - Operator and agent documentation + +```task +id: WARDEN-WP-0024-T07 +status: done +priority: medium +state_hub_task_id: "ca2aaf23-833f-49a6-a49b-a0b659208f5f" +``` + +Document the memory workflow for operators and coding agents. + +Acceptance: + +- Wiki page covers: store location, session kinds, agent env vars, memory + activation at session start, and interaction with OpenRouter inference. +- ops-warden AGENTS.md and the state-hub agent template include memory + orientation steps for Claude, Codex, and Grok sessions. +- Credential routing doc cross-links PMEM-WP-0016 contract; anti-patterns + updated (no secret values in memory store). +- Scheduled worker playbook notes memory retention and evaluation gate checks. + +## Acceptance Criteria + +- phase-memory is present and useful in all three runtime surfaces (worker, + agent session, operator CLI) through one canonical store. +- OpenRouter inference cost decreases when stabilized routing memory matches. +- Cross-runtime continuity is tested and regression-gated. +- Security invariants (no-secret, allowlist, conduit-not-broker) are unchanged. + +## Dependencies + +- `PMEM-WP-0016` (phase-memory) — profile, event schema, activation pack, + evaluation scenarios. **Implement contract (T01–T03) before WARDEN T03–T05.** +- `WARDEN-WP-0020` — worker brain and guardrails (finished). +- `WARDEN-WP-0022` — audit trail for correlation (finished). +- llm-connect / OpenRouter — required only for T06 live efficiency measurement; + T01–T05 work offline. + +## Suggested Implementation Order + +1. PMEM-WP-0016 T01–T03 (profile + contract + event schema) +2. WARDEN-WP-0024 T01–T02 (store + CLI recording) +3. PMEM-WP-0016 T04 (activation pack) +4. WARDEN-WP-0024 T03–T05 (worker + agent activation + continuity) +5. PMEM-WP-0016 T05–T06 + WARDEN-WP-0024 T06–T07 (evaluation + docs) + +## Closure Review + +Integrated phase-memory across all ops-warden runtime surfaces: + +- `warden memory status` and `warden memory activate` with canonical XDG store. +- CLI recording hooks on `route find`, `access`, and `sign` (opt-out via + `WARDEN_MEMORY=0`). +- Memory-aware worker planning with stabilized-route RuleBrain short-circuit + and LlmConnectBrain context injection. +- Cross-runtime continuity verified in tests (agent session → worker activation). +- `wiki/OpsWardenMemory.md` and AGENTS.md session orientation for Claude, + Codex, Grok, and future agents. \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md new file mode 100644 index 00000000..5c4e7724 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0025-forgejo-admin-api-token-lane.md @@ -0,0 +1,118 @@ +--- +id: WARDEN-WP-0025 +type: workplan +title: "Forgejo admin PAT OpenBao lane (CCR-2026-0006)" +domain: infotech +repo: ops-warden +status: finished +owner: grok +topic_slug: custodian +planning_priority: high +planning_order: 25 +created: "2026-07-12" +updated: "2026-07-13" +state_hub_workstream_id: "70c11222-d8e7-5936-99f7-7d626a4a5deb" +--- + +# WARDEN-WP-0025 — Forgejo admin PAT OpenBao lane + +**Trigger:** the-custodian CCR request (msg `54125f84`) — establish OpenBao custody +for the Forgejo site-admin PAT at `platform/workloads/forgejo/forgejo-admin`. +Drivers: `ACTIVITY-WP-0020` weekly package prune and railiance-apps/platform tools +still using `/tmp/forgejo-tegwick-api-token` or `FORGEJO_ADMIN_TOKEN`. + +**Boundary:** ops-warden holds no PAT; workstation OIDC fetch mirrors +`railiance-backup-offsite-lane` (CCR-2026-0004). Distinct from `forgejo-mailer` +(SMTP via ESO). Phase 1: no cluster ExternalSecret. + +**Depends on:** platform-operator approval of CCR-2026-0006; attended PAT mint. + +--- + +## Tasks + +### T1 — Draft CCR + policy metadata + +```task +id: WARDEN-WP-0025-T01 +status: done +priority: high +state_hub_task_id: "2c288bf0-b39c-5f5b-ad25-eed3da826dc3" +``` + +- [x] `CCR-2026-0006-forgejo-admin-api-token-lane.yaml` (`status: proposed`) +- [x] `openbao/policies/workload-kv-read-forgejo-admin.hcl` +- [x] `docs/workload-kv-access-lanes.md` section + +### T2 — ops-warden catalog + playbook + +```task +id: WARDEN-WP-0025-T02 +status: done +priority: high +state_hub_task_id: "01b81595-f9e5-5746-b0dd-2075189cb00e" +``` + +- [x] Catalog entry `forgejo-admin-api-token` (`status: draft`) +- [x] `wiki/playbooks/forgejo-admin-api-token.md` + +### T3 — Platform-operator approval + metadata apply + +```task +id: WARDEN-WP-0025-T03 +status: done +priority: high +state_hub_task_id: "279b74d7-3240-5ca0-897d-b1ddffd23c4e" +``` + +- [x] CCR approved by platform-operator (bernd.worsch, 2026-07-12) +- [x] `scripts/credential-change.py applier-dry-run CCR-2026-0006` +- [x] Policy `workload-kv-read-forgejo-admin` + OIDC role `forgejo-admin-workload-kv-read` applied on `bao.coulomb.social` +- [x] Non-secret `delegated_metadata_apply` evidence on CCR + +### T4 — Attended PAT provision + verification + +```task +id: WARDEN-WP-0025-T04 +status: done +priority: high +state_hub_task_id: "4e21232c-62a1-5115-acce-edfbcfa84e48" +``` + +- [x] Mint PAT as Forgejo user `tegwick` (attended, 2026-07-12) +- [x] Stored at `platform/workloads/forgejo/forgejo-admin`, field `API_TOKEN` + (initial provision used field `Token`; re-stored as `API_TOKEN` 2026-07-13 to + match CCR/catalog/playbook `fetch_command`) +- [x] Positive fetch verified 2026-07-13 — `bao kv get -field=API_TOKEN …` returns + non-empty; PAT valid against `forgejo.coulomb.social` (`/api/v1/user` → + `login=tegwick`, `is_admin=true`) +- [x] Negative default-policy denial recorded on CCR +- [x] Promoted catalog `forgejo-admin-api-token` to `active` (`resolvable: true`) + +### T5 — Notify downstream consumers + +```task +id: WARDEN-WP-0025-T05 +status: done +priority: medium +state_hub_task_id: "f8c7c70b-b9b6-5980-a25b-7f11033b81a2" +``` + +- [x] Ack the-custodian with CCR id + catalog id (no secret values) — msg 949e8ed1, 2026-07-13 +- [x] Signal railiance-platform / activity-core / railiance-apps to wire `load_token()` + OpenBao paths — msgs 5be8e500 / 9ed1af98 / 2e47b6e5, 2026-07-13 + +--- + +## Acceptance + +- CCR-2026-0006 approved, policy + OIDC role live, PAT in OpenBao +- `warden route find "forgejo admin pat"` → `forgejo-admin-api-token` +- No PAT in Git, State Hub, workplans, logs, or chat +- Workstation file drop retired as steady-state path after downstream wiring + +## See also + +- `railiance-platform/credential-change-requests/CCR-2026-0006-forgejo-admin-api-token-lane.yaml` +- `activity-core/workplans/ACTIVITY-WP-0020-weekly-forgejo-package-prune.md` +- Custodian message `54125f84-e9df-4fa0-9309-7370633a20d3` \ No newline at end of file diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md new file mode 100644 index 00000000..309f7718 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0026-credential-disclosure-hygiene.md @@ -0,0 +1,261 @@ +--- +id: WARDEN-WP-0026 +type: workplan +title: "Credential disclosure hygiene + rotation guidance (Strand A)" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 26 +created: "2026-07-16" +updated: "2026-07-16" +state_hub_workstream_id: "331c7620-bd34-5acd-9135-591985b568e5" +--- + +# Credential disclosure hygiene + rotation guidance (Strand A) + +## Origin + +Follow-up to a credential-disclosure incident on 2026-07-16 while verifying +`CCR-2026-0004` (railiance offsite backup lane). A negative policy test was run +as `BAO_TOKEN=$(bao token create -policy=default -field=token) bao kv get `. +The `token create` was denied (workload role lacks it), `BAO_TOKEN` fell back to +the caller's privileged login token, and `bao kv get` printed all three field +values (`NC_WEBDAV_TOKEN`, `NC_WEBDAV_URL`, `AGE_PRIVATE_KEY`) into an agent +session transcript. Buildup mode — exposure accepted, learnings captured. + +**Root causes:** (1) a deny-test that read the secret *data* path at all; +(2) a silent privileged-token fallback; (3) the read landed in a logged context. + +This is **Strand A** (disclosure hygiene). Tamper-resistant policy governance and +one-command mass rotation/lockdown (Strand B) are deliberately **deferred** — see +"Out of scope" below. + +## Goal + +Make accidental secret disclosure structurally hard, and make ops-warden the +authoritative source for **how each secret is rotated or re-established** — +advisory knowledge held next to the routing catalog, not in OpenBao. + +## Design guardrails (binding on acceptance) + +- **Verification never reads secret data.** Use `bao token capabilities` (allow/deny) + instead of `kv get` for positive/negative lane tests. +- **Masking is defense-in-depth, not a boundary.** Any display filter is a wrapper + convenience; raw `bao kv get ` remains the documented anti-pattern. +- **Rotation guidance covers both `rotate` (provider re-mint) and `re-establish` + (regenerate from source, e.g. a new age keypair).** +- **Coverage gate:** every `active` (and newly promoted) catalog lane must carry + rotation guidance, enforced by a scorecard check. + +## Out of scope (Strand B — deferred, not built here) + +- Executable one-command rotation of all tainted secrets. +- Graded lockdown / break-glass seal + re-key with a designed trust-root. +- Policy time-travel / policy-as-code reconcile-to-past-commit. (Drift *detection* + may be revisited separately; the reconcile machinery is out.) + +## Task: Capabilities-based lane verification + +```task +id: WARDEN-WP-0026-T01 +status: done +priority: high +state_hub_task_id: "1cb22a40-b7c6-560a-a805-7766a5786dcc" +``` + +Done 2026-07-16: canonical capabilities-safe verification pattern added to +`wiki/playbooks/catalog-lane-promotion.md` (fleet promotion checklist criterion 8 ++ dedicated section), and applied to the `railiance-backup-offsite-lane` and +`forgejo-admin-api-token` playbook verify sections. Positive/negative proven via +`bao token capabilities` against the KV v2 data path — never `bao kv get`; the +denied `default` token-create is documented as a pass, not a fallback trigger. +Live CCR-2026-0004 re-verify carried under T07. + +Replace secret-reading verify flows with capability checks. Positive test: +approved identity has `read` on the KV data path. Negative test: a `default`-only +identity is `deny`. Both via `bao token capabilities ` (or the +self endpoint) — **never** `bao kv get`. Update +`wiki/playbooks/*lane*.md` verify sections and any lane-verify helper. + +**Done when:** the documented and tooled verify path for any lane proves +allow/deny without reading a secret value, and the CCR-2026-0004 re-verify uses +it (see T07). + +## Task: Safe access transport (no stdout values) + +```task +id: WARDEN-WP-0026-T02 +status: done +priority: high +state_hub_task_id: "bcb7da96-0a28-5484-bf3e-06e97acf5873" +``` + +Done 2026-07-16: sanctioned transports added to `warden access` so a value never +lands on stdout — `--out FILE` (mode-0600 file), `--exec` (child env, pre-existing), +and `--wrap` (single-use OpenBao response-wrapping token via `bao kv get -wrap-ttl`, +caller `bao unwrap`s in their own context). Raw `--fetch` to a non-TTY stdout is now +refused (exit 6) unless `--unsafe-stdout` is passed (interactive human only). +`proxy_fetch_to_file`/`proxy_fetch_wrapped`/`build_wrapped_fetch` in `proxy.py`; tests +in `tests/test_proxy.py`. Anti-pattern + transports documented fleet-wide in +`.claude/rules/credential-routing.md` and `wiki/OperatorAccessAssist.md` (G2). + +`warden access` / fetch paths must emit values only into an env var, a file, or +a **response-wrapping token** (`bao … -wrap-ttl`), never a stdout table. Add a +wrapping-token transport for values that must move between processes. Record in +canon (`credential-routing` rules) that raw `bao kv get ` (full table) is +the anti-pattern; the sanctioned path is `warden access … --field ` into env. + +**Done when:** the sanctioned fetch path cannot print a value to a terminal, and +the anti-pattern is documented fleet-wide. + +## Task: Masking display filter (defense-in-depth) + +```task +id: WARDEN-WP-0026-T03 +status: done +priority: medium +state_hub_task_id: "d90b0628-fa1d-527d-99c3-28a7ed933e52" +``` + +Done 2026-07-16: `warden/mask.py` (`fingerprint`/`mask_value` — presence, length, +8-char sha256 prefix; never the value) + `proxy_fetch_fingerprint` and a +`warden access … --fingerprint` masked status view (bypasses the stdout guard +because it emits no value). Lets two parties compare sha256 prefixes to confirm a +shared value (e.g. rotation landed) without disclosure. Explicitly labelled +defense-in-depth — raw `bao kv get` bypasses it — in `wiki/OperatorAccessAssist.md` +and the module docstring. Tests in `tests/test_mask.py` + a CLI test in +`tests/test_proxy.py`. + +In the warden wrapper, mask KV data values by default when any listing/status is +shown — display presence, length, and a short non-reversible hash instead of the +value. Explicitly labelled as defense-in-depth (raw bao bypasses it). + +**Done when:** wrapper-mediated output never shows a raw KV value, with the +limitation documented. + +## Task: Agent read-boundary on high-risk lanes + +```task +id: WARDEN-WP-0026-T04 +status: done +priority: high +state_hub_task_id: "827fa67d-5f69-5fac-bdce-9903b1b909fb" +``` + +Done 2026-07-16: Catalog `risk: high|standard` (default standard). High-risk: +`railiance-backup-offsite-lane`, `forgejo-admin-api-token`, `openrouter-llm-connect`. +OpenBao policy `agent-high-risk-boundary` (railiance-platform + live write) grants +metadata/capabilities only and **denies** data-read on those paths — verified with +minted agent token (data=deny, metadata=read). `warden access` with +`WARDEN_AGENT_ID` set refuses raw value stream on high-risk lanes (exit 7); +`--out`/`--exec`/`--wrap`/`--fingerprint` remain. Playbook: +`wiki/playbooks/agent-read-boundary.md`. Tests in `tests/test_routing.py` + +`tests/test_proxy.py`. + +**Repo: railiance-platform (OpenBao policy/roles).** Agent identities receive +`capabilities`/metadata and wrapping tokens on high-risk lanes, not raw data +reads. Align with the existing credential-routing rule ("ops-warden proxies reads +as the caller and must not retain values"). Classify which lanes are high-risk +(recovery escrow like `AGE_PRIVATE_KEY`, upload tokens). + +**Done when:** at least the high-risk lanes deny raw data reads to agent roles +while still allowing wrapped/proxied access, verified via capabilities checks. + +## Task: EXPOSED taint convention + +```task +id: WARDEN-WP-0026-T05 +status: done +priority: medium +state_hub_task_id: "09ef8727-31da-59ac-aac7-2d47924569fe" +``` + +Done 2026-07-16: Convention documented in `wiki/playbooks/exposed-taint.md` +(`exposed_at`, `exposed_version`, `exposed_reason`, `exposed_ref` on KV v2 +custom_metadata). First worked mark applied to +`platform/workloads/railiance/backup/offsite-lane` version 2 (disclosure +incident). `warden taint ` (+ `--json`) reports taint via metadata-only +`bao kv metadata get` — never secret data (`src/warden/taint.py`). Tests in +`tests/test_taint.py`. + +**Repo: railiance-platform (OpenBao) + ops-warden surface.** Establish a KV v2 +`custom_metadata` convention to mark a tainted secret: `exposed_at=` +and the affected `version`. Identify semi-automatic candidates from the OpenBao +audit log (reads from agent/shared contexts). `warden` surfaces taint status for +a lane (advisory; no auto-rotation here). + +**Done when:** a secret can be marked EXPOSED via a documented convention and +`warden` reports whether a lane is currently tainted. + +## Task: Rotation / re-establishment guidance registry + +```task +id: WARDEN-WP-0026-T06 +status: done +priority: high +state_hub_task_id: "a2e1544e-e501-57eb-a40e-9a2147cef12a" +``` + +Done 2026-07-16: `rotation:` block (method rotate|re-establish, ordered steps, +owner, automatable) added to the routing model/parser (`RotationGuide`, +`RouteEntry.rotation`, `vends_secret`), screened for secret material in a prose-safe +mode. `warden rotate-guide ` (human + `--json`) surfaces the guidance; `warden +route show --json` carries `has_rotation` + `rotation`. Coverage enforced by the new +`catalog_rotation_coverage` scorecard check (every active secret-vending lane must +have a block) and promotion checklist criterion 9. Rotation blocks authored for all +7 active vending lanes + the draft railiance-backup lane (re-establish example: age +keypair regen + re-encrypt). Tests in `tests/test_routing.py`. Also fixed a +pre-existing keyword collision (bare `npm` on the forgejo-admin lane → `forgejo-npm`) +so "npm token" routes to the generic lane again. + +Give every catalog lane **structured-but-advisory** renewal guidance, held in the +ops-warden registry (not in OpenBao). Add a `rotation:` block per catalog entry +capturing: `method` (rotate | re-establish), ordered `steps` (provider re-mint / +keygen / OpenBao write / re-encrypt-and-reupload where relevant), `owner`, and +`automatable` (bool, for future Strand-B). Surface via `warden rotate-guide ` +(and/or `warden route … --rotate`). Add a **scorecard coverage check**: every +`active` lane must have a `rotation:` block; flag any that don't. + +**Done when:** `warden rotate-guide ` returns actionable renewal steps for +every active lane, and the scorecard fails if any active lane lacks guidance. + +## Task: Incident lessons + first worked lane (CCR-2026-0004) + +```task +id: WARDEN-WP-0026-T07 +status: done +priority: medium +state_hub_task_id: "62d8286f-7954-52a8-bce6-6a16072e5246" +``` + +Done 2026-07-16: Lessons note present. Capabilities-safe live re-verify on +`bao.coulomb.social`: lane-policy token → `read` on data path; default + agent +boundary → `deny`; field keys present (no values printed). Catalog promoted +`draft`→`active`, `fetch_command` pinned to `NC_WEBDAV_TOKEN` (no placeholders) +so `resolvable: true`; `risk: high`; rotation guidance + EXPOSED taint on v2. +CCR-2026-0004 evidence + `access_frontdoor.resolvable: true` / `readiness: ready`. +Playbook + `wiki/CredentialRouting.md` updated. Operator may still rotate the +exposed values optionally (buildup) — not a promotion blocker. + +Write a short lessons-learned note (buildup context; exposure accepted; the three +root causes). Apply T01 + T06 to `CCR-2026-0004` as the first worked lane: +re-verify it the capabilities-safe way so it can finally promote to +`resolvable: true` (unblocking `RAILIANCE-WP-0015`), and ensure its `rotation:` +block (rotate Nextcloud token; re-establish age keypair + re-encrypt artifacts) +is present. **Rotation of the exposed values is the operator's optional call, not +a blocker** (buildup). + +**Done when:** the lessons note exists, CCR-2026-0004 has capabilities-based +verify + rotation guidance, and its promotion path is unblocked. + +## References + +- `CCR-2026-0004-railiance-backup-offsite-lane.yaml` (railiance-platform) +- `wiki/playbooks/railiance-backup-offsite-lane.md` +- `.claude/rules/credential-routing.md` (the-custodian, fleet-inlined) +- `RAILIANCE-WP-0015` (railiance-apps) — cnpg backup coverage, gated on CCR-2026-0004 +- Strand B (deferred): tamper-resistant governance, one-command rotation/lockdown, + policy time-travel — capture separately if/when justified. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0027-credential-governance-lockdown.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0027-credential-governance-lockdown.md new file mode 100644 index 00000000..c14e9c30 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0027-credential-governance-lockdown.md @@ -0,0 +1,303 @@ +--- +id: WARDEN-WP-0027 +type: workplan +title: "Tamper-resistant credential governance + mass rotation/lockdown (Strand B)" +domain: infotech +repo: ops-warden +status: blocked +flavor: implementation +owner: codex +topic_slug: custodian +planning_priority: medium +planning_order: 27 +created: "2026-07-16" +updated: "2026-10-03" +state_hub_workstream_id: "21528e8d-a049-523d-9ae1-da7a27cb8bbf" +--- + +# Tamper-resistant credential governance + mass rotation/lockdown (Strand B) + +## Origin + +Explicitly deferred from `WARDEN-WP-0026` (credential disclosure hygiene, Strand A). +WP-0026 "Out of scope" carves out the heavyweight governance machinery and directs +that it be "capture[d] separately if/when justified." This workplan is that capture. + +Strand A makes accidental disclosure structurally hard and gives every lane +**advisory** rotation guidance. Strand B is the **executable, tamper-resistant** +layer: turning that advisory guidance into one-command action and hardening policy +governance against silent drift or malicious change. + +## Status: blocked on T02 (reviewed 2026-09-28) + +Activated by the operator on 2026-08-22 after the second activation gate became +concrete. `RAILIANCE-WP-0024-T03` now requires an approved recovery window, +fresh encrypted Raft snapshot evidence, provider-console access, named abort +authority, and the live **2-of-3 Shamir quorum** before a coordinated reboot. +That is fleet policy requiring a designed break-glass path, not speculative +heavyweight machinery. + +Activation is deliberately narrow. No mass-disclosure incident triggers T01, +and no fleet policy currently mandates T03's signed policy-manifest reconcile. +Those tasks remain `cancel`; cancellation here continues to mean deferred, not +abandoned. T02 alone was activated; it now waits on a fresh attended drill. + +## Activation gate (promote to `ready` only when ≥1 holds) + +- A real disclosure incident requires rotating **more than a couple** of secrets at + once, making manual per-lane rotation (Strand A) too slow. +- Fleet policy for OpenBao mandates tamper-evident policy governance or a designed + break-glass path. +- Audit/compliance requires provable "reconcile policy to a known-good commit." + +## Goal + +Make credential response **executable and trustworthy at fleet scale**: one command +rotates or re-establishes a set of tainted secrets; policy changes are tamper-evident +and reconcilable to a known-good state; a graded lockdown / break-glass path exists +with an explicit trust-root. + +## Scope boundary (unchanged from Strand A) + +ops-warden still **custodies no secret values**. Strand B orchestrates the owner's +tools (OpenBao, provider re-mint, railiance-platform credential broker) as the +caller — it does not hold or vend secrets. Rotation execution runs the owner-native +path; ops-warden sequences and verifies it. + +## Task: Executable mass rotation driver + +```task +id: WARDEN-WP-0027-T01 +status: cancel +priority: high +state_hub_task_id: "b5691939-9d84-5115-9618-0f8839010d14" +``` + +Turn Strand A's per-lane `rotation:` guidance (WP-0026 T06) into an executable +driver: `warden rotate ` (single lane) and `warden rotate --tainted` (all lanes +marked EXPOSED per WP-0026 T05). Each step runs the owner-native command +(provider re-mint, `bao kv put`, re-encrypt+reupload for re-establish lanes) as the +caller, verifies via capabilities (never reads the value), and clears the +`exposed_at` taint on success. Dry-run first; idempotent; per-lane failure isolates. + +**Done when:** a tainted set of lanes can be rotated/re-established with one command, +each verified capabilities-safe, taint cleared only on success. + +**Depends on:** WP-0026 T05 (taint convention), T06 (rotation registry). + +## Task: Graded lockdown / break-glass with explicit trust-root + +```task +id: WARDEN-WP-0027-T02 +status: todo +decision_id: 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa +priority: medium +state_hub_task_id: "cae498ee-6307-5d32-9f1b-a471cfcc2536" +``` + +2026-10-11: requalified after founder decision D3 (trust root, build-mode default) resolved — see the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md. + +Design and document a graded lockdown: (a) soft — deny agent roles read on all +high-risk lanes; (b) hard — seal + re-key with a pre-designed trust-root and quorum. +Define the trust-root (who holds unseal shares, recovery keys), the break-glass +invocation, and the re-entry path. **Design + runbook first**; any executable seal +step is opt-in and attended. + +**Done when:** a documented, rehearsed break-glass path exists with a named +trust-root and quorum, and soft-lockdown is executable via capabilities-based +policy toggles. + +**Parked input — the warden-sign AppRole (2026-08-11).** secrets-engine holds a +validated dry-run for a `warden-sign` AppRole (policy + role, `update` on +`ssh/sign/{agt,adm,atm}-role` only). It was **parked** rather than withdrawn +specifically because it is an input to this task: today the credential broker is the +only *autonomous* path to a signing token, so if its issuer lapses, recovery is a +founder OIDC act. Whether a second autonomous path should exist — and whether it is +the AppRole or something this trust-root design supersedes — is a break-glass +question, not a routing one. Resolve it here. Context and the counter-argument +(AppRole is narrower in capability than placing the broker's issuer token on a remote +host) are in `workplans/ADHOC-2026-08-11.md` T03 (ad-hoc **finished** 2026-08-15; +question lives here now); secrets-engine was told to stop holding apply +readiness until this task or the ops-bridge cutover fires (msg `863c7b57`). + +**Rebaselined 2026-08-22.** The July description predates the authoritative +OpenBao migration. The current barrier is a rotated **2-of-3**, not the +aspirational 3-of-5 value still present in ops-warden's legacy posture +descriptor. `RMASTER-WP-0020` records two attended restart/unseal cycles on +2026-08-03 with shares supplied through hidden prompts, matching inventory, +audit continuity, exact-path read, and sibling denial. That is valid rehearsal +evidence for re-entry, but it is not misreported as a current production +emergency-seal drill. + +The soft half is also already live: `RAILIANCE-WP-0022` reports total concrete +high-risk path coverage and a dedicated coding-agent AppRole proving deny-wins +without reading a secret value. ops-warden consumes that owner control through +`scripts/check_agent_read_boundary.py`; it does not take ownership of the live +OpenBao policy. + +The consumer contract and remaining acceptance gate are now documented in +`docs/credential-governance-break-glass.md`. One attended production emergency +seal/unseal drill remains. It must use railiance-platform's evidence template +and validator, have snapshot/quorum/console/driver/abort receipts before the +seal hold point, and be executed by the platform owner—not by a coding agent. + +**Parked AppRole disposition:** do not unpark the standalone `warden-sign` +AppRole for T02 break-glass. The normal broker remains autonomous; an issuer +failure deliberately crosses into attended OIDC and, below that, the 2-of-3 +platform trust-root. A standing AppRole placed outside the broker would weaken +that boundary and still would not recover a sealed OpenBao. A separately +approved ops-bridge unattended-signing design may re-evaluate the narrow +AppRole under its own workplan; that is service access, not recovery authority. + +**Read-only readiness 2026-08-22.** The owner `node-reboot` preflight passed +every automated check without observing a secret value: node/k3s, platform-pg +and continuous archiving, a 16.37-hour successful backup, initialized/unsealed +OpenBao with `shares=3` and `threshold=2`, ESO stores/projections, and the +reviewed audit-core digest were healthy. `ready_for_live_execution` correctly +remained false because no approved window, current encrypted off-host snapshot +receipt, provider-console attestation, quorum attestation, owner-ack flag, or +named abort operator was supplied. + +That preflight also exposed a Warden safety defect: the ceremony request matched +the generic `openbao-api-key` template and proposed paste-once provisioning. +`openbao-shamir-recovery-ceremony` now distinguishes the owner-operated approval +ceremony from secret retrieval. It is a non-value-bearing pointer and can never +offer `--fetch`, `--exec`, `--out`, `--wrap`, or paste-once share transport. + +**Scenario established 2026-08-22.** The operator delegated preparation to the +agent and reserved their involvement for the final GO/NO-GO. The bounded, +non-secret scenario is +`docs/evidence/WARDEN-WP-0027-T02-drill-scenario-2026-08-22.md`: ops-warden +coordinates and enforces the hold point; railiance-platform is the proposed +OpenBao driver; railiance-infra is the proposed independent console/abort owner; +and railiance-master is asked only for a metadata-only 2-of-3 availability +attestation. All three owner receipts and a green fully parameterized preflight +are required before the final operator question. + +The railiance-infra role is scoped by the authoritative review contract +`WARDEN-WP-0027-T02-DRILL-20260822-01-INFRA` in +`interfaces/reviews/WARDEN-WP-0027-T02-DRILL-20260822-01-railiance-infra.json`. +It binds the exact scenario artifact and expiry, requires explicit independent +provider-console and distinct-abort attestations, permits metadata-only evidence, +and states `authorizes_execution: false`. + +**Preparation approved 2026-08-22.** Decision +`9da57559-712a-4521-b46e-a4c69729f9d2` authorizes preparation only and narrows +the possible live scope to one intentional OpenBao seal followed by the existing +2-of-3 unseal ceremony. It excludes a host reboot, re-key, restore, policy +change, PVC mutation, credential disclosure, and general workload restart. +Railiance-infra satisfied its direct contract with receipt +`01a02b4b-7295-7836-b288-f29407008524`. The revisioned, non-authorizing gate +matrix is in +`docs/evidence/WARDEN-WP-0027-T02-drill-preparation-checklist-2026-08-22.md`; +platform snapshot/driver and master quorum contracts remain required before the +fully parameterized read-only preflight. + +**Live attempt terminal NO-GO 2026-08-23.** All owner receipts and the final +read-only preflight became green, and the operator opened the exact bounded +window with decision `449a697a-5303-4582-aa9e-b0bc8b35ab2d`. The platform +driver stopped before seal when attended OIDC succeeded but the read-only agent +home prevented token-helper persistence and the underlying client emitted the +short-lived credential into captured output despite `-no-print`. The credential +was immediately self-revoked. Independent metadata confirmed OpenBao remained +initialized and unsealed with zero unseal progress; no seal, unseal, reboot, +restore, policy, PVC, or workload mutation occurred. NO-GO decision +`85724c0c-e70f-4e2f-a8c6-a9cb1ea6331b` supersedes and consumes the GO; the +scenario and its receipts cannot be reused. + +The direct remediation interface is `RAILIANCE-WP-0026-T01`. Ops-warden commit +`0fae0904ce8d8694338dd53a8a79abec5fec788d` replaces the persistent login-only +handoff with a contained login-plus-reviewed-command envelope. It proves a +private writable helper before OIDC, captures login/child/revocation stdout and +stderr, fails closed on any output or persistence defect, self-revokes, and +removes the helper. No live OIDC was used for verification. The value-safe +owner receipt is +`docs/evidence/RAILIANCE-WP-0026-T01-ops-warden-receipt.json`; a future drill +requires owner acceptance, fresh receipts, a new scenario id, and a new human +decision. + +**Containment review status 2026-08-23.** `railiance-infra` independently +accepted the exact implementation revision at its commit `186b030` and State +Hub message `7b2846dd-4b7c-4933-b61f-921e8ccf9ff2`, after rerunning the 42 +focused tests and lint. Direct platform review request +`9a5f8973-0e74-4df2-8089-5a5bdc42295b` now carries the exact revision, receipt, +test results, and infra acceptance. T02 remains `progress` until +`railiance-platform` accepts or requests changes. No human GO is relevant while +that owner gate is open; acceptance will permit preparation of a new scenario, +not execution or reuse of the terminal one. + +**Owner gate CLOSED — accepted 2026-08-23, found 2026-08-28.** +`railiance-platform` accepted the exact revision `0fae0904`. Recorded in their +`RPF-WP-0017-attended-login-output-containment.md` (`status: finished`), which +also records railiance-infra's independent approval at `186b030` and marks all +five acceptance criteria met. The receipt digest was verified here rather than +taken on trust: `docs/evidence/RAILIANCE-WP-0026-T01-ops-warden-receipt.json` at +ops-warden `bc1966da` hashes to +`d2ba444ed16989590325697e69d25283dc75a9432c29a72e627e80bf9fd987e4`, matching +their record exactly. + +Note the identifier: the remediation interface recorded above as +`RAILIANCE-WP-0026-T01` is `RPF-WP-0017-T01` in the owner's repo. Searching for +the cited id finds an unrelated workplan, which is part of why this sat unnoticed. + +**Their acceptance is source acceptance only and authorizes no live OIDC or +drill** — their words, and the boundary holds. So T02's state changes but its +`Done when` does not: what was blocked was *preparing a new scenario*, and that +is now permitted. The terminal NO-GO scenario and its receipts remain unusable. + +**Third instance of the same failure this session.** The acceptance existed for +five days; no message reached ops-warden. Identically, `key-cape` accepted the +WP-0033-T04 question on 2026-08-23 with no message, and nine unread messages +were sitting on already-superseded threads. The `verified:` field added by +WP-0033-T05 was built for exactly this and it works — what does not work is +waiting for a counterparty to tell you. Re-checking a blocker means reading the +owner's repository. + +**Remaining to close T02:** one attended production emergency seal/unseal drill, +requiring a new scenario id, fresh owner receipts from platform/infra/master, a +fully parameterized green preflight, and a new human GO. It is executed by the +platform owner, never by a coding agent. That is an operator decision, not an +agent one, so T02 stays `progress` and the decision is surfaced rather than taken. + +2026-10-03: human gate routed to hub decision 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa (D3: Trust root and secret custody: unseal/recovery holders, break-glass, and the deferred rotation of exposed material) by CUST-WP-0075; resolving that decision raises C-40 here. + +## Task: Tamper-evident policy governance + reconcile + +```task +id: WARDEN-WP-0027-T03 +status: cancel +priority: medium +state_hub_task_id: "7dbedcdc-dd5a-551c-bff1-0702fea0a9cf" +``` + +Policy-as-code for OpenBao policies/roles with tamper-evidence: a signed/hashed +manifest of the intended policy set, drift **detection** against live OpenBao, and a +reconcile-to-known-good-commit path. (Drift detection may land independently even if +full reconcile stays gated.) Coordinate ownership with railiance-platform (OpenBao +deployment) — ops-warden contributes the ops-access policy surface, not the cluster. + +**Done when:** live OpenBao policy state is diffable against a signed known-good +manifest, and an attended reconcile can restore it. + +**Cross-repo:** railiance-platform (OpenBao cluster + policy custody). + +## References + +- `WARDEN-WP-0026` — Strand A (disclosure hygiene, advisory rotation) — prerequisite +- `.claude/rules/credential-routing.md` — ops-warden custodies no secret values +- `railiance-platform` — OpenBao cluster, policy custody, credential broker +- `wiki/AccessRouting.md` — issue vs route vs assist boundary +- `workplans/ADHOC-2026-08-11.md` T03 — parked warden-sign AppRole (ad-hoc finished + 2026-08-15); T02 resolves it as unsuitable for break-glass, while a separately + approved ops-bridge unattended-signing design may still re-evaluate it + cert_command cutover +- `secrets-engine` `SECRETS-WP-0004` — the parked AppRole apply/handoff + +### 2026-09-28 loose-end review + +T02 now waits and the workplan is blocked. Source containment acceptance is +already complete in railiance-platform's archived RPF-WP-0017; it is not a live +drill receipt. The terminal August scenario remains consumed. Completion still +requires a fresh platform-driven attended emergency seal/unseal scenario, fresh +platform/infra/master receipts and a new founder GO. The cancelled T01/T03 stay +cancelled. No ceremony, rotation or production mutation was performed. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0028-tenant-secret-custody.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0028-tenant-secret-custody.md new file mode 100644 index 00000000..fe819834 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0028-tenant-secret-custody.md @@ -0,0 +1,421 @@ +--- +id: WARDEN-WP-0028 +type: workplan +title: "Tenant secret custody — NetKingdom pattern for client/tenant secrets" +domain: infotech +repo: ops-warden +status: finished +owner: grok +topic_slug: custodian +planning_priority: high +planning_order: 28 +created: "2026-07-16" +updated: "2026-07-17" +state_hub_workstream_id: "6b66228a-199a-5b85-b5e2-a7afeaab903b" +--- + +# WARDEN-WP-0028 — Tenant secret custody (NetKingdom pattern) + +## Origin + +Founder establishing **binky-control** as the control-plane repo for a Coulomb +client/tenant (Binky-Hedgehog GmbH). Immediate need: store **tenant-specific** +secrets in OpenBao (e.g. company mailbox usernames/passwords for IMAP scan) and +consume them safely via email-connect / agents **without** putting values in +git, State Hub, chat, or workplans. + +BINKY-WP-0003-T01 prepared a draft plan +(`binky-control/integrations/company-email-openbao.md`) that targeted +`secret/prod/binky/...` via secrets-engine. That draft is directionally right on +*workflow*, but it does not match a production-ready custody layout on +`bao.coulomb.social`. This workplan resolves the NetKingdom layout and makes +**tenant** secrets first-class — **separate from** platform workload lanes +(`platform/workloads/...`). + +## Goal + +Define and land a **repeatable, multi-tenant-safe** pattern for: + +1. Where tenant secrets live in OpenBao (path + mount convention) +2. Who owns policy, CCR, catalog, and front door +3. How agents and workloads obtain values (sanctioned transports only) +4. First concrete lane: **binky company email IMAP** (unblocks real-world event + intake for binky-control) + +## Architectural facts (as of 2026-07-16) + +### Planes (ADR-0006) + +| Plane | Role | Example | +| --- | --- | --- | +| Bootstrap | First trust / recovery | unseal, platform-root | +| Platform control | Shared identity, secrets, authz | OpenBao, key-cape, flex-auth, railiance-platform | +| Tenant | Scoped client/workload authority | coulomb products, **binky**, future clients | + +**Binky is a tenant**, not platform-root. Tenant secrets must not require +platform-admin for day-to-day read, and tenant operators must not gain +platform-root grants. + +### OpenBao mounts (live + planned) + +| Mount | Type | Role | +| --- | --- | --- | +| **`platform/`** | KV v2 | **Platform control-plane** secrets: `platform/workloads/...` (fleet CCRs, ESO) and `platform/operators/...` — *not* client/tenant commercial secrets | +| **`secret/`** | KV v2 | secrets-engine stage / pilot paths (`secret/coulomb/...`) — not the tenant home | +| **`tenants/`** | KV v2 (**new**) | **Client/tenant commercial secrets** — explicit multi-tenant namespace | + +Live under `platform/workloads/` today: `activity-core/`, `coulomb/`, `forgejo/`, +`issue-core/`, `railiance/`, `reuse/`. Those stay where they are; we do **not** +migrate them into `tenants/` in this workplan. + +### Dual front-door systems (both real; don't invent a third) + +| Layer | Owns | Entry | +| --- | --- | --- | +| **OpenBao** | Custody, ACL, audit | `bao` CLI / API | +| **railiance-platform CCR** | Approved metadata apply (policy + OIDC role + evidence) | `credential-change-requests/CCR-*.yaml` | +| **ops-warden catalog** | Routing + `warden access` proxy (no custody) | `registry/routing/catalog.yaml` | +| **secrets-engine catalog** | Workflow: decision → plan → provision → exec delivery | `secrets-engine/catalog/*.yaml` | + +**Binding rule (ops-warden):** never vend secret values; only route/proxy as the +caller. **Binding rule (WP-0026):** capabilities-safe verify; agents on +`risk: high` use `--out` / `--exec` / `--wrap` only. + +### Why not bury tenants under `platform/workloads/` + +Earlier draft of this workplan used `platform/workloads//...`. Founder +prefer a **shallower, explicit** namespace. That is sound: + +- **No conflict with Vault/OpenBao best practice.** Separate mounts (or + top-level prefixes) for different security *domains* are common and good. + `platform/workloads` is an *internal fleet convention* for platform services, + not an industry mandate for every secret. +- **Clearer mental model:** platform plane vs tenant plane (ADR-0006) maps to + mount/prefix names operators can see at a glance. +- **Isolation:** ACLs, list boundaries, and future audit queries stay simpler + when tenant material is not mixed under the same path tree as forgejo/ESO + lanes. + +### Decision (2026-07-17) — use dedicated mount `tenants/` + +```text +mount: tenants # KV v2, enable once (platform-admin) +logical path: // +CLI: tenants/// +API data path: tenants/data/// +``` + +**Rejected alternatives (kept for archaeology only):** + +| Option | Why not | +| --- | --- | +| `secret/prod/binky/...` | `secret/prod/` does not exist; stage model not ready as sole production path | +| `platform/workloads/binky/...` | Too deep; conflates tenant clients with platform workloads | +| `platform/tenants/binky/...` | Acceptable fallback if enabling a new mount is blocked; prefer full `tenants/` mount | + +### Tooling debt to clear (not a reason to keep the deep path) + +`railiance-platform/scripts/credential-change.py` currently hard-fails unless: + +- `openbao.mount == "platform"` +- `openbao.kv_path` starts with `platform/workloads/` + +That guard must be **extended** to allow `mount: tenants` and +`kv_path` under `tenants/` (T03). It is an implementation constraint, not a +security reason to force the deep path. + +## Recommended path convention (tenant secrets) + +```text +tenants/// +``` + +| Segment | Rules | Binky email example | +| --- | --- | --- | +| `tenant_slug` | Stable kebab slug; company/client id | `binky` | +| `workload` | Capability or system using the secret | `company-email` | +| `bundle` | Single purpose unit (one CCR / one policy) | `imap` | + +Full CLI path: + +```text +tenants/binky/company-email/imap +``` + +Suggested fields (names only — never values in git): + +| Field | Purpose | +| --- | --- | +| `IMAP_USERNAME` | mailbox login (often the address) | +| `IMAP_PASSWORD` | app password / mailbox password | +| `IMAP_HOST` | optional if not fixed in consumer config | +| `IMAP_PORT` | optional (default 993 in config) | + +Non-secret connection facts (provider host if stable) may live in +`binky-control` config / email-connect yaml as **env names + host**, not +passwords. + +### Future multi-mailbox / multi-tenant + +```text +tenants//mailbox/ +# e.g. tenants/binky/mailbox/founder-primary +# tenants/acme/mailbox/billing +``` + +One CCR + one least-privilege policy **per bundle** (or per mailbox). Do not +grant `tenants/binky/*` list/read to agents — exact-path policies only. + +### Risk class + +Mailbox credentials and similar client secrets are **`risk: high`** (WP-0026 +T04): agent identities get metadata/capabilities only; raw stream refused when +`WARDEN_AGENT_ID` is set. + +## Ownership split + +| Concern | Owner repo | Artifact | +| --- | --- | --- | +| Tenant business need, IMAP host facts, scan config, queues | **binky-control** | `integrations/*`, mailmeta (metadata only), activity defs | +| OpenBao path, policy HCL, OIDC role, CCR lifecycle | **railiance-platform** | `CCR-YYYY-NNNN-…yaml`, `openbao/policies/…` | +| Routing front door + rotation guidance | **ops-warden** | catalog entry, playbook, `warden access` / `rotate-guide` | +| Exec-time delivery workflow (optional same path) | **secrets-engine** | catalog entry pointing at `tenants/...` (same path; no second copy) | +| Identity groups for tenant operators | **net-kingdom / key-cape** | group e.g. `tenant-binky-operators` (near-term may use `net-kingdom-admins` for founder-only) | +| Mailbox scan consumer | **email-connect** | config with `username_env` / `password_env` only | + +## Auth model (near-term vs target) + +**Near-term (founder dogfood):** OIDC `netkingdom` role bound to +`groups=net-kingdom-admins` (same pattern as backup/forgejo lanes). Acceptable +while binky is founder-operated only. + +**Target (real multi-tenant):** + +- IAM group `tenant-binky-operators` (and later per-tenant groups) +- OpenBao OIDC role `binky-company-email-imap-workload-kv-read` bound only to + that group +- flex-auth check `secret.read:binky-company-email` if pre-approval required +- Agents **never** hold the workload-kv-read policy; use operator wrap / exec + injection / AppRole for email-connect scanner only + +## First worked lane (deliverable sketch) + +| Item | Value | +| --- | --- | +| Catalog id | `binky-company-email-imap` | +| CCR | `CCR-2026-0007` (next free) — title: Binky company email IMAP | +| Mount | `tenants` | +| KV path | `tenants/binky/company-email/imap` | +| Policy | `workload-kv-read-binky-company-email-imap` | +| OIDC role | `binky-company-email-imap-workload-kv-read` | +| Consumer | email-connect `scan-mailbox` via env inject | +| Front door | `warden access binky-company-email-imap --out FILE` or `--exec -- …` | +| Provision | **Red lane, founder once** — value via `bao kv put … @file` or secrets-engine provision; never chat | + +## Out of scope + +- Mass rotation / lockdown machinery (WARDEN-WP-0027 Strand B) +- Sending mail / SMTP from company address (separate lane if needed) +- Migrating all `secret/` mount lanes onto `platform/` (separate secrets-engine + / railiance work) +- Full key-cape tenant group productization (may be a net-kingdom follow-on) + +## Tasks + +### T01 — Canon note: tenant secret path + ownership + +```task +id: WARDEN-WP-0028-T01 +status: done +priority: high +state_hub_task_id: "9982a884-7a50-593e-861e-cc8d2343a0ba" +``` + +Done 2026-07-17: `wiki/playbooks/tenant-secret-onboarding.md` + CredentialRouting +tenant paragraph; catalog-lane-promotion draft table updated. + +Land a short ops-warden wiki page (and one paragraph in +`wiki/CredentialRouting.md`) that freezes: + +- mount **`tenants`** + path `tenants///` +- ownership table (binky-control / railiance-platform / ops-warden / secrets-engine) +- link to WP-0026 hygiene (capabilities verify, high-risk, taint) +- **do not** put new client/tenant commercial secrets under + `platform/workloads/` or invent `secret/prod/...` as the production home + +**Done when:** wiki + CredentialRouting pointer exist; binky integration doc +updated to match (or superseded with link). + +### T02 — Align binky-control integration plan to production path + +```task +id: WARDEN-WP-0028-T02 +status: done +priority: high +state_hub_task_id: "d7d7ee9d-2ecf-5492-8a13-0b747d899456" +``` + +Done 2026-07-17: `binky-control/integrations/company-email-openbao.md` rewritten +to `tenants/binky/company-email/imap` + checklist (host confirm + Red provision +still open). + +**Cross-repo: binky-control.** Rewrite +`integrations/company-email-openbao.md` to use +`tenants/binky/company-email/imap`, CCR + ops-warden front door as primary, +secrets-engine as optional exec wrapper on the same path. Confirm non-secret +IMAP host/port with founder (Blue). Keep Red-lane value provision as the last +step. + +**Done when:** binky doc matches this workplan; checklist items re-opened for +implementation (T01 in BINKY was "prepared only"). + +### T03 — Enable `tenants` mount + extend CCR tooling + policy/role + +```task +id: WARDEN-WP-0028-T03 +status: done +priority: high +state_hub_task_id: "e0b675ef-9c08-5f89-8f13-ef4249ca2364" +``` + +Done 2026-07-17: `tenants/` KV v2 mount live; CCR applier allowlist extended; +CCR-2026-0007 + policy + OIDC role applied; lane-policy `read` / default +`deny` / agent boundary on tenants path; `docs/workload-kv-access-lanes.md` +tenant section. + +**Cross-repo: railiance-platform (+ OpenBao admin once).** + +1. **Enable KV v2 mount** `tenants/` on `bao.coulomb.social` (platform-admin / + attended; record non-secret evidence). Versioning + max versions policy + aligned with `platform` if practical. +2. **Extend** `scripts/credential-change.py` allowlist: `mount: tenants` and + `kv_path` under `tenants/` (keep existing `platform/workloads/` rules + intact for fleet lanes). Update dry-run docs and tests. +3. Author `CCR-2026-0007` (or next id) for the binky IMAP path; policy HCL on + exact data/metadata paths under `tenants/…`; OIDC role (founder group + near-term). Dry-run; founder approves; apply metadata only. +4. Document fields without values; add a **tenant lanes** section to + `docs/workload-kv-access-lanes.md` (or sibling doc). + +**Done when:** mount exists; CCR tool accepts tenant paths; CCR approved + +policy/role applied; capabilities-safe positive/negative evidence (no value +reads for verify). + +### T04 — ops-warden catalog + playbook + rotation + +```task +id: WARDEN-WP-0028-T04 +status: done +priority: high +state_hub_task_id: "9405b13d-4045-519b-8e3f-79a891323397" +``` + +Done 2026-07-17: catalog draft `binky-company-email-imap` (`risk: high`, +rotation, path `tenants/binky/...`); playbooks +`binky-company-email-imap.md` + onboarding. Promote to active after T05. + +Add `binky-company-email-imap` to `registry/routing/catalog.yaml`: +`status: draft` until verify, then promote; `risk: high`; `exec_capable: true`; +concrete `fetch_command` for primary field; `rotation:` block (re-establish or +rotate mailbox app-password). Playbook under `wiki/playbooks/`. Scorecard +rotation coverage satisfied on promote. + +**Done when:** `warden route show binky-company-email-imap --json` shows +expected pointers; after T03+T05, `resolvable: true`. + +### T05 — Founder provision (Red) + first scan evidence + +```task +id: WARDEN-WP-0028-T05 +status: done +priority: high +state_hub_task_id: "f17bba95-bc53-5c2a-8b44-7df9e42b2341" +``` + +Done 2026-07-17: Founder provisioned via OpenBao UI (KV version 2; not +placeholder). Capabilities-safe verify pass; catalog + CCR promoted +active/resolvable. Optional follow-up: first email-connect read-only scan into +`binky-control/mailmeta/` (OperatingRhythm), not a custody blocker. + +**Human-only value path.** Founder provisions IMAP username/password into +OpenBao via approved tool (`bao kv put … @file` or secrets-engine provision). +Agents never see the value. Run email-connect read-only scan with +`warden access … --exec` or secrets-engine exec; store **metadata-only** +evidence under `binky-control/mailmeta/`. + +**Done when:** one successful read-only scan evidence note exists; lane +promoted active/resolvable; CCR verification evidence complete. + +### T06 — Generalize "tenant secret onboarding" playbook + +```task +id: WARDEN-WP-0028-T06 +status: done +priority: medium +state_hub_task_id: "76bd01a0-1d03-5ff9-8f59-a1b44763979d" +``` + +Done 2026-07-17 with T01: `wiki/playbooks/tenant-secret-onboarding.md` + +CredentialRouting link. + +From the binky lane, write a reusable playbook: +`wiki/playbooks/tenant-secret-onboarding.md` — steps for any new tenant: +slug, CCR template fields, policy naming, catalog entry, agent boundary, +rotation block, promotion checklist. Intended for the next Coulomb client +without redesign. + +**Done when:** playbook exists and is linked from CredentialRouting + first +session notes for tenant repos. + +### T07 — secrets-engine alignment decision (record only) + +```task +id: WARDEN-WP-0028-T07 +status: done +priority: low +state_hub_task_id: "46c8f8a9-3bbe-568f-8a45-07b690874273" +``` + +Done 2026-07-17: **Decision** — tenant production lanes use `mount: tenants` +and the CCR path only; secrets-engine may wrap exec delivery against that same +path later but must not store a second copy under `secret/`. Until stage roles +gain an approved `tenants/` grant, production path is CCR + ops-warden + +caller `bao`. + +Record a short decision: secrets-engine catalog entries for **tenant** +production lanes **must** use `mount: tenants` and the same path as the CCR +(no second copy under `secret/`). Stage roles may need a later extension to +touch `tenants/` under an approved plan — until then, ops-warden + CCR + +`bao` as caller are the production path. + +**Done when:** decision note in this workplan or `POST /decisions/` + wiki +pointer; no dual-value storage for the IMAP password. + +## Suggested implementation order + +1. T01 canon (unblocks everyone) +2. T02 binky doc alignment +3. T03 mount + CCR tooling + CCR apply (metadata) +4. T04 catalog draft +5. T05 founder provision + verify + promote +6. T06 generalize playbook +7. T07 secrets-engine alignment (can parallel after T01) + +## Acceptance + +- [ ] Documented path convention `tenants//…` used for ≥1 live lane (`binky`) +- [ ] CCR applier accepts `tenants/` without weakening `platform/workloads/` rules +- [ ] No secret values in any git/State Hub artifact +- [ ] Lane is capabilities-verified and agent high-risk safe +- [ ] email-connect can scan with env injection without printing password +- [ ] Next tenant can copy the onboarding playbook without redesign + +## References + +- ADR-0006 recursive multi-tenant identity (`net-kingdom/docs/adr/…`) +- `net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md` +- `railiance-platform/docs/workload-kv-access-lanes.md` +- `railiance-platform/docs/credential-change-approval.md` +- `binky-control/integrations/company-email-openbao.md` (draft to align) +- WARDEN-WP-0026 disclosure hygiene (capabilities, high-risk, taint, rotation) +- WARDEN-WP-0027 Strand B (out of scope here) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md new file mode 100644 index 00000000..4008d825 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md @@ -0,0 +1,159 @@ +--- +id: WARDEN-WP-0029 +type: workplan +title: "Policy front door: posture-aware access planning + founder interaction surface" +domain: infotech +repo: ops-warden +status: finished +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 29 +created: "2026-07-18" +updated: "2026-07-18" +state_hub_workstream_id: "bbb3d9ec-d88d-5088-b4c0-55bfba0a10cf" +--- + +# WARDEN-WP-0029 — Policy front door + founder interaction surface + +## Origin + +Founder directive 2026-07-18 (binky-control cutover prep): agents proposed +raw credential mechanics to the founder ("attach the deploy key in the +forgejo UI", "save the PAT to /tmp/...") although a catalogued lane +(`forgejo-admin-api-token`, WARDEN-WP-0025) already covered the need — the +installed CLI's catalog was stale, and nothing forced the ask-warden-first +step. Directive: **ops-warden is the service to ask what can and needs to be +done** per NetKingdom policy; the founder is bothered only when policy makes +it absolutely necessary, and then preferably via a purpose-built interaction +surface, not CLI/file handoffs. The organization is in **build phase** and +ops-warden must know that posture. INTENT.md principles 7 and 8 (added with +this workplan) capture the direction. + +## Goal + +1. `warden plan ""` — a policy decision front door: given a need, answer + *autonomous / founder-act-required / unroutable*, with the exact commands + or the exact founder act, posture-stated. +2. Declared **organization posture** (`build`) as a **third axis** beside env + posture (dev/test/prod) and workload maturity (M0–M3). +3. A **founder interaction surface**: local web page for the rare founder + acts (approve, OIDC-login prompt, paste-once secret capture straight into + OpenBao) — no values through CLI history or files. +4. Catalog freshness + agent guidance so ask-warden-first is the enforced + default. + +## Design constraints (optimized 2026-07-18) + +- **Compose, do not fork:** `warden plan` must call the routing catalog + + `expand_handoff` / `resolvable`; it must not re-implement keyword matching + or invent a second catalog. +- **Org posture is a third axis:** do not overload env posture or maturity. +- **Desk MVP is build-phase only:** localhost, OS-session trust, stdlib HTTP + server (pattern: net-kingdom `security-bootstrap-console`). No core-hub / + whynot dependency for v1. +- **Reuse map (reuse.coulomb.social):** flex-auth (policy-evaluate), key-cape + (OIDC act), net-kingdom bootstrap console (localhost desk shape), + railiance-platform (OpenBao custody). Do not rebuild those owners. + +## Delivery sequence + +```text +T02 (org posture) ─┐ +T05 (catalog freshness) ─┼─→ T01 (warden plan composes both) +T04 (playbook sweep) ───┘ (parallel once plan shape known) +T03 (desk) ← after T01 can emit founder_required with a typed act +``` + +T05 is high priority: catalog staleness was the incident root cause. + +## Tasks + +### T02 — Declared organization posture (build phase) + +```task +id: WARDEN-WP-0029-T02 +status: done +priority: high +state_hub_task_id: "6c213024-6601-5116-b52f-d6711dc0587d" +``` + +Added `organization_posture: build` as axis C in +`registry/policy/security-posture.yaml` (relaxations + graduation triggers). +Surfaced in `warden policy list/show`, scorecard, and `warden plan` output. + +### T05 — Catalog freshness + agent guidance + +```task +id: WARDEN-WP-0029-T05 +status: done +priority: high +state_hub_task_id: "c82d8745-4af4-5b89-ab49-06d8a902e592" +``` + +`Catalog.freshness()` reports source (repo/bundled/override), content hash, +mtime, package version, stale entry count, and warnings for bundled fallback. +Human `warden route list` prints catalog line; plan JSON embeds `catalog`. +Scorecard check `catalog_freshness`. AGENTS.md + credential-routing rules +require `warden plan` before founder credential steps. + +### T01 — `warden plan` decision front door + +```task +id: WARDEN-WP-0029-T01 +status: done +priority: high +state_hub_task_id: "34db38fa-cb99-5ced-9a12-85176a7f2b44" +``` + +`warden plan "" [--actor] [--domain] [--json]` composes catalog find + +handoff + org posture + policy gate. Verdicts: `autonomous` / +`founder_required` (`oidc_login` | `approve` | `paste_once_provision`) / +`unroutable` (CCR stub). Metadata-only audit. Module: `src/warden/plan.py`. + +### T04 — Retire file-drop patterns from playbooks + +```task +id: WARDEN-WP-0029-T04 +status: done +priority: medium +state_hub_task_id: "717f57da-fbc4-5a4d-9f8c-c1c3fa75e0ee" +``` + +`wiki/playbooks/forgejo-admin-api-token.md` rewritten: plan-first, sanctioned +transports (`--exec`/`--out`/`--wrap`), desk paste-once for provision; `/tmp` +file drops marked retired. Consumer follow-ups noted for railiance-platform +and binky-control docs. + +### T03 — Founder interaction surface (local web approval page) + +```task +id: WARDEN-WP-0029-T03 +status: done +priority: medium +state_hub_task_id: "47c781d2-768b-5777-b971-b5227fe41f5c" +``` + +`warden desk` — loopback `ThreadingHTTPServer`, short-lived token URL, acts +approve / oidc_login / paste_once_provision (bao kv put via stdin, dry-run +supported). Metadata-only audit open/close. Module: `src/warden/desk.py`. + +## Acceptance + +- [x] `warden plan "forgejo deploy key for binky-control"` → `autonomous` / + `agent-harness-forgejo-deploy` with access commands +- [x] Provision-style needs → `founder_required` with typed founder act +- [x] Posture `build` in plan + policy + scorecard +- [x] Desk approve flow (unit) with zero secrets in audit +- [x] No in-repo playbook instructs founder file drop as steady state +- [x] Catalog freshness on `warden route list` / plan JSON + +## See also + +- INTENT.md §7 (founder escalated, never tasked) and §8 (build-phase posture) +- WARDEN-WP-0025 (forgejo admin token lane), WARDEN-WP-0026/0027 (disclosure + hygiene, governance lockdown) +- reuse.coulomb.social: `capability.authorization.policy-evaluate`, + `capability.iam.key-cape`, `capability.security.iam-tooling-suite` +- binky-control DEC-2026-003 (first consumer: cutover without founder + mechanics) diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0030-delegation-register.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0030-delegation-register.md new file mode 100644 index 00000000..49612d07 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0030-delegation-register.md @@ -0,0 +1,270 @@ +--- +id: WARDEN-WP-0030 +type: workplan +title: "Delegation register — make gap-covering interim, visible, and retirable" +domain: infotech +repo: ops-warden +status: finished +owner: grok +topic_slug: custodian +planning_priority: high +planning_order: 30 +created: "2026-08-11" +updated: "2026-08-15" +state_hub_workstream_id: "da3367d5-890c-52c6-aa54-1bdd0f277342" +--- + +# WARDEN-WP-0030 — Delegation register + +## Origin + +Founder directive 2026-08-11: **ops-warden should work with, but never replace or +duplicate, secrets-engine, tenant-engine, user-engine and other NetKingdom +components.** It is acceptable for ops-warden to cover a gap where needed security +functionality is not yet systematically provided — *provided* the gap is kept in +mind, filled, and given proper governance, after which ops-warden delegates to the +improved component. + +The directive is already half-lived and nowhere written. Survey of +`registry/routing/catalog.yaml` on 2026-08-11 (24 entries): + +| Execution mode | Count | Meaning | +| --- | --- | --- | +| `warden_executes: true` | 1 | ops-warden's own lane (`ssh-cert-host-access`) | +| `exec_owner:` set | 2 | Delegated — route-primary, proxy-fallback | +| `exec_capable` proxy, no `exec_owner` | 11 | **ops-warden is the de facto front door** | +| route-only | 10 | Pointer, nothing to delegate | + +The delegation primitive already exists and works: `exec_owner` / `exec_command` / +`pointer_command` (`whynot-design-npm-publish` → secrets-engine, WP-0019; +`ops-warden-warden-sign-token` → railiance-platform credential broker, +RAILIANCE-WP-0005 T08). It is used by 2 of 24 lanes. + +Nothing distinguishes the other eleven — "ops-warden proxies because that is the +right end state" reads identically to "ops-warden proxies because no owner front +door was ever built." Supporting evidence of the doctrine gap: + +- `wiki/AccessRouting.md` does not mention secrets-engine at all and has no section + on interim positions. +- `wiki/playbooks/catalog-lane-promotion.md` gates draft→active on the lane + *working*, never on whether ops-warden should be the one running it. + +## Goal + +Make every ops-warden execution position **explicitly interim or explicitly +permanent**, with the intended owner and blocking condition recorded in the +machine-readable layer — so gap-covering is a tracked, retirable state rather than +silent ownership drift. + +Success is not removing proxies. Success is that no proxy exists without an answer +to *"who should own this front door, and what is missing?"* + +## Non-goals + +- Removing or degrading any working lane. Proxies keep working until the owner's + front door exists and is proven. +- Building the missing front doors. That work belongs to secrets-engine, + tenant-engine, user-engine, and railiance-platform — this workplan produces the + register they need, not their implementations. +- A second catalog or a parallel schema. `delegation:` extends the existing entry + shape; `warden route gaps` composes the existing loader. + +## Design constraints + +- **Interim is the default.** A lane without a `delegation:` block is treated as + `interim` with an unknown owner, not as settled. Absence must read as a question. +- **Founder classifies, agent drafts.** Which of the eleven are legitimately + permanent is an architecture judgement (`key-cape-oidc-login` plausibly is; the + tenant/workload secret lanes plausibly are not). T02 lands a *drafted* + classification for review; the founder's answer is authoritative. +- **No restating owner procedure.** The register names the intended owner and the + blocker; it does not describe how that owner will implement their front door. + Same pointer-layer discipline as the rest of the catalog. + +## Tasks + +### T01 — Interim custodianship doctrine + +```task +id: WARDEN-WP-0030-T01 +status: done +priority: high +state_hub_task_id: "6f88876e-434c-5718-9c8d-ec6bf64ae4aa" +``` + +Add a doctrine section to `wiki/AccessRouting.md` stating the boundary: the only +lane ops-warden executes with its own authority is SSH issuance; every other +execution position is interim, held because the owning component does not yet cover +the need, and retired to that owner once it does. Name secrets-engine, +tenant-engine, user-engine, railiance-platform and flex-auth as the delegation +targets. Cross-link INTENT.md §9. + +### T02 — `delegation:` metadata + backfill + +```task +id: WARDEN-WP-0030-T02 +status: done +priority: high +state_hub_task_id: "b02e8da6-57ca-5f9f-9405-9b0624498e3a" +``` + +Extend the catalog entry schema with: + +```yaml +delegation: + mode: native | interim | permanent # native = owner already fronts it + intended_owner: # required unless mode: permanent + blocked_on: # required when mode: interim + reviewed: "YYYY-MM-DD" +``` + +Backfill all 24 entries. `exec_owner` lanes become `mode: native`. +`ssh-cert-host-access` becomes `mode: permanent` (ops-warden's own lane). The +eleven undelegated proxies are classified per the founder review below — five +`interim` now, six held pending secrets-engine's answer. + +**Landed 2026-08-15.** Catalog is now 27 entries. All 27 carry `delegation:`. + +- `permanent` (1): `ssh-cert-host-access` +- `native` (10): both `exec_owner` lanes plus the route-only pointers +- `interim` (16): the five founder-classified now; the six held pending + secrets-engine (still unanswered as of 2026-08-15, msg `7d55d332`) recorded as + `interim` / `intended_owner: secrets-engine` / `blocked_on` the generic-vs-per-lane + question — **not** `permanent`; plus five new-since-survey lanes drafted the same + way (`email-connect-transactional` same held question; two AppRoles; + `coulomb-social-runtime-env`; draft `scaleway-bootstrap`) + +The six are not guessed permanent. Interim is the default until secrets-engine +answers. Reclassify to `permanent` only if they confirm `exec --catalog` stays +per-lane. + +### T03 — `warden route gaps` + conformance test + +```task +id: WARDEN-WP-0030-T03 +status: done +priority: medium +state_hub_task_id: "f5e0f5af-45d8-5c82-9de2-d640d7d0a1f7" +``` + +`warden route gaps [--json]` lists interim lanes with intended owner, blocker, and +age since review — the queryable register. Add a routing test asserting every +`exec_capable` non-`warden_executes` entry declares `delegation`, so a new proxy +cannot be added without answering the ownership question. Surface stale interim +entries in the existing drift/stale review cadence. + +### T04 — Promotion gate + +```task +id: WARDEN-WP-0030-T04 +status: done +priority: medium +state_hub_task_id: "b808a749-e1d7-5708-aabf-91732dd76abd" +``` + +Update `wiki/playbooks/catalog-lane-promotion.md`: draft→active requires a +`delegation` block. If `mode: interim`, the promotion note must state the intended +owner and the retirement condition. Add the matching question to the lane-review +checklist. + +### T05 — Publish the register to the owners + +```task +id: WARDEN-WP-0030-T05 +status: done +priority: medium +state_hub_task_id: "b0188ec4-4860-57c8-8030-45904a132190" +``` + +Once T02 is reviewed, send the interim register to secrets-engine, tenant-engine, +user-engine, railiance-platform and net-kingdom as a coordination message: here is +what ops-warden currently fronts on your behalf, here is what would let us step +back. This is the artefact that converts a private ops-warden position into a +fleet-visible capability gap. + +**Landed 2026-08-15.** Register sent (no secret values): + +| To | Message | +| --- | --- | +| secrets-engine | `9c1d753f` — 1 native + 7 interim pending generic-exec answer | +| tenant-engine | `17c851b1` — 2 Binky tenant lanes | +| user-engine | `38aeccd5` — confirm USER_ENGINE_PROXY_SECRET ownership | +| railiance-platform | `e75793e3` — 1 native + 4 interim | +| net-kingdom | `3fea09df` — object-storage-sts remains native/draft | +| key-cape | `28ded56c` — rapp-qonto-keycape-client (founder-classified interim) | + +## Acceptance + +- [x] `wiki/AccessRouting.md` states the interim-custodianship boundary and names + the delegation targets +- [x] All catalog entries carry `delegation`; `warden route gaps` returns the + interim set with owner + blocker (27 entries; 15 active interim) +- [x] Routing test fails when a proxy lane omits `delegation` +- [x] Promotion playbook gates draft→active on the ownership question +- [x] Founder has reviewed the interim/permanent classification of the eleven + (2026-08-11); the six held lanes stay interim pending secrets-engine, not + marked permanent +- [x] Register delivered to the named owner repos (T05) + +## Classification of the eleven (founder review, 2026-08-11) + +### The test + +An initial draft sorted by *subsystem* (tenant lanes → tenant-engine, workload lanes → +secrets-engine). Inspecting the entries showed that is the wrong axis. Nine of the +eleven share one `auth_method` — "caller's own OpenBao token" (operator OIDC via +key-cape, or a `workload-kv-read-*` policy) — and one `fetch_command` shape, +`bao kv get -field=X `. No owner procedure is duplicated there. Contrast +`whynot-design-npm-publish`, which needs npm config and token injection into a specific +tool; that is a *procedure*, which is why WP-0019 handed it to secrets-engine. + +**Test: owner-specific procedure or lifecycle → `interim`. Generic KV read → +ops-warden's thin wrapper is arguably `permanent`.** + +### Interim — classify now (5) + +| Lane | `intended_owner` | `blocked_on` | +| --- | --- | --- | +| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape protocol procedure, not a KV read; rotation already `automatable: true`, so key-cape could front it today | +| `binky-company-email-imap` | tenant-engine | Custody at `tenants/binky/...` but rotation owner is `binky-control` — split lifecycle, no front door reconciling it | +| `binky-qonto-api` | tenant-engine | Same split, same tenant | +| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a multi-step procedure ops-warden only describes | +| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` plus an alternative host-local key path; two ways in, neither owner-fronted | + +### Held pending secrets-engine (6) + +`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`, +`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`. + +These pass the test as `permanent` **only if `secrets-engine exec` stays per-lane and +provisioned.** If secrets-engine intends `exec --catalog ` to generalize over +arbitrary OpenBao lanes, the thin-wrapper argument collapses and all six become +`interim` with `intended_owner: secrets-engine` — ops-warden would then be duplicating +a front door the owner provides. + +Asked directly (msg `7d55d332`, 2026-08-11): generic or per-lane; if generic, is it +near-term enough to mark now; and are there lanes they would decline, so those can be +marked permanent with the owner's position on record rather than ops-warden's inference. + +Supporting detail: for `issue-core-ingestion-api-key`, `reuse-surface-hub-write-token` +and `openrouter-llm-connect`, **production never touches the proxy** — External Secrets +syncs the value into the cluster and the proxy exists for operator verification and +debugging. That weakens the case that they represent a missing front door at all. + +**Do not backfill these six until the answer arrives.** A lane wrongly marked +`permanent` bakes in exactly the ownership drift this register exists to catch. + +### user-engine + +No lane names **user-engine** as owner — it appears only as a consumer inside +`coulomb-social-runtime-env` (`USER_ENGINE_PROXY_SECRET`, rotated at +`user-engine/user-engine-runtime`). Whether user-engine should front that lane itself +is worth confirming. + +## See also + +- INTENT.md §9 (cover gaps, never silently own them) +- WARDEN-WP-0019 (route to secrets-engine — the pattern this generalizes) +- WARDEN-WP-0028 (tenant secret custody pattern; front door still ops-warden's proxy) +- `history/2026-08-11-delegation-surface-assessment.md` +- `registry/routing/catalog.yaml`, `wiki/playbooks/catalog-lane-promotion.md` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0031-policy-caller-identity.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0031-policy-caller-identity.md new file mode 100644 index 00000000..c4c600c4 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0031-policy-caller-identity.md @@ -0,0 +1,170 @@ +--- +id: WARDEN-WP-0031 +type: workplan +title: "Calling-side identity for flex-auth, so policy.enabled can flip" +domain: infotech +repo: ops-warden +status: finished +owner: ops-warden +topic_slug: netkingdom +planning_priority: P1 +depends_on_workplans: + - WARDEN-WP-0007 +related_workplans: + - WARDEN-WP-0009 +created: "2026-08-19" +updated: "2026-08-19" +state_hub_workstream_id: "739bad25-2345-5f4f-aaa3-cc4cd8c71f6c" +--- + +# WARDEN-WP-0031 — Calling-side identity for flex-auth + +flex-auth shipped `flex-auth-ops-warden` (FLEX-WP-0016 T01/T02): an +independently rollable in-cluster pin carrying ops-warden's production registry +and policy package, on digest `sha256:138aa347…`, at +`flex-auth-ops-warden.flex-auth.svc.cluster.local:8080`. + +It runs `callerAuth.mode: warn`, and it says why in its own logs: + +``` +caller authentication warning: caller is not authenticated +``` + +`src/warden/policy.py` posted `/v1/check` with **no `Authorization` header**. +flex-auth authenticates the caller with a Kubernetes TokenReview and binds +`resource.system: ops-warden` to `system:serviceaccount:ops-warden:ops-warden`; +an unauthenticated caller can only be served in `warn`. So the pin cannot +enforce, and per ADHOC-2026-08-17-T01 — `policy.enabled` must not flip anywhere +while `/v1/check` still answers unauthenticated callers — `policy.enabled` stays +false. The gap is ours, not flex-auth's, and this workplan closes it. + +Warn is also not A2 evidence: a request that succeeds because failures are +downgraded proves nothing about the enforcing path. + +## Ownership + +| Concern | Owner | +| --- | --- | +| The pin, its digest, `callerAuth.mode` | flex-auth | +| Sending a caller identity on `/v1/check` | **ops-warden** (this workplan) | +| Choosing the token source on a given host | ops-warden operator | +| `policy.enabled: true` in `warden.yaml` | ops-warden operator | + +## Design note — fail closed on identity too + +When a caller token is configured but cannot be obtained, `check_sign_policy` +raises under `fail_closed` rather than retrying unauthenticated. Falling back to +an anonymous call is precisely the behaviour that keeps the pin in `warn`; a +gate that silently degrades to the ungated path is not a gate (ADR-0004's choke +point argument, applied to ops-warden as a caller). + +## Tasks + +```task +id: WARDEN-WP-0031-T01 +status: done +priority: high +state_hub_task_id: "d3b7c701-bcdd-53f9-aa72-6f289bf5909b" +``` + +**Caller identity on the outbound policy call.** `policy.caller_auth` in +`warden.yaml` (`mode: none | file | env | command`, `token_path`, `token_env`, +`command`, `audience`); `src/warden/caller_identity.py` resolves the token at +call time and never caches, logs, or echoes it (ADR-0002); both +`check_sign_policy` and `check_fetch_policy` attach `Authorization: Bearer …`. +Whitespace-bearing and empty tokens are rejected before the call, because +flex-auth rejects them outright. + +Done 2026-08-19. `mode: none` remains the default, so behaviour is unchanged +until an operator opts in. Tests in `tests/test_policy.py`. + +```task +id: WARDEN-WP-0031-T02 +status: done +priority: high +state_hub_task_id: "b77b3c80-a168-564a-9b7f-3063aefc3c2e" +``` + +**Readiness gate.** `scripts/check_policy_caller_identity.py` — read-only: +config loads, mode is not `none`, a token is actually obtainable, and with +`--url` a live `/v1/check` against a port-forward of the warn pin. Prints the +token's length and a truncated SHA-256 fingerprint only, so its output is safe +to paste into a handoff. Exit 0 ready / 1 not ready / 2 bad input. Distinguishes +401 (token not accepted — audience or binding) from 403 (authenticated but not +allowed to represent `system: ops-warden`). + +Done 2026-08-19. + +```task +id: WARDEN-WP-0031-T03 +status: done +priority: medium +state_hub_task_id: "4245155e-6c71-5425-b574-11f61e1d4461" +``` + +**Docs.** `examples/warden.production.example.yaml` gains the `caller_auth` +block with both realistic sources, and its `flex_auth_url` is corrected — the +example pointed at `flex-auth.flex-auth.svc.cluster.local`, a Service that does +not exist. `wiki/PolicyGatedSigning.md` gains the caller-identity section and +the flip sequence. + +Done 2026-08-19. + +```task +id: WARDEN-WP-0031-T04 +status: done +priority: high +state_hub_task_id: "f3834af7-2a08-51dd-bf31-8ce8550de699" +``` + +**Pick the token source and prove it against the warn pin.** Operator work on +the real host: `kubectl create token` (workstation) or a projected token +(in-cluster PEP), then +`python scripts/check_policy_caller_identity.py --url http://127.0.0.1:19090` +against a port-forward. Expect `effect=allow` for `agt-state-hub-bridge` while +the warn log stops printing `caller authentication warning` — the absence of +that line, not the allow, is the evidence. + +Done 2026-08-19. Source is `mode: command` — `kubectl create token ops-warden +-n ops-warden --audience flex-auth --duration 10m` against the railiance01 +cluster (tunnel `k3s-api-railiance01`, local `16444`; `16443` was CoulombCore's +k3s, a different cluster, which is why a `system:masters` cert 401s there — +not a port collision, as first reported). +`deploy/kubernetes/caller-identity.yaml` creates the Namespace and +ServiceAccount the binding names — no RBAC, `automountServiceAccountToken: +false`; it exists only to be TokenReviewed. Gate exits 0 live: +`HTTP 200, effect=allow, decision:f3f7c88f9585582a`, and the pin's +`caller authentication warning` count held at 4 across two authenticated runs. +Evidence: `history/2026-08-19-flex-auth-caller-identity-evidence.md`. + +```task +id: WARDEN-WP-0031-T05 +status: cancel +priority: high +state_hub_task_id: "3f6dc609-89db-52eb-a6f9-d2fd271be821" +``` + +**Sequence the flip.** Only after T04: tell flex-auth to set +`callerAuth.mode: enforce` on `flex-auth-ops-warden` (their FLEX-WP-0016 T03), +re-run the gate against the enforcing pin, and only then set +`policy.enabled: true` with `fail_closed: true`. Flipping before enforce buys +nothing; flipping before T04 401s every `warden sign`. + +**Deferred 2026-08-19 under `ADR-0006`** — not blocked, decided against for now. + +flex-auth did enforce (FLEX-WP-0016 T03, Helm rev 2): the pin runs +`--caller-auth-mode enforce`, the gate exits 0 against it +(`HTTP 200, effect=allow, decision:f3f7c88f9585582a`), and an anonymous +`/v1/check` is 401. Everything needed to flip was in place. + +It was not flipped. `policy.enabled` is a single repo-wide boolean, and with +`fail_closed: true` it makes flex-auth a hard dependency of every `warden sign` +— including the certs the ops-bridge tunnels depend on, one of which carries +the policy call itself. Uniform enforcement across an estate being actively +rebuilt would harden the access needed to perform the rebuild. Enforcement +belongs to a zone, not to the repo; that is `ADR-0006`, and the model is +`WARDEN-WP-0032`. This task resumes as WARDEN-WP-0032-T05. + +Also shipped while proving the flip: the gate URL is now a managed ops-bridge +tunnel `flex-auth-ops-warden-railiance01` (`-L 19090:10.43.1.165:8080`) instead +of a hand-run `kubectl port-forward`. diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0032-security-zones.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0032-security-zones.md new file mode 100644 index 00000000..6c8000ad --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0032-security-zones.md @@ -0,0 +1,429 @@ +--- +id: WARDEN-WP-0032 +type: workplan +title: "Adopt security zones as a consumer — retire the global policy.enabled" +domain: infotech +repo: ops-warden +status: finished +owner: ops-warden +topic_slug: netkingdom +planning_priority: P1 +depends_on_workplans: + - WARDEN-WP-0031 +created: "2026-08-19" +updated: "2026-08-22" +state_hub_workstream_id: "38c6a5f3-fb0d-5230-be85-f9e3ffc850f6" +quality_dod: DoD-Ok +quality_dod_at: "2026-08-22" +quality_dod_by: codex +quality_dod_note: "All tasks are done; the global switches and trust-zone source are retired, workload references are explicit, the owner policy is total, declarations validate, live caller identity is re-proven, and the full suite passes." +--- + +# WARDEN-WP-0032 — Adopt security zones as a consumer + +`ADR-0006` defers `policy.enabled: true` until enforcement can be scoped to a +zone. **The zone model itself is no longer ops-warden's work.** It moved to +`zone-engine` as `ZONE-WP-0001` on 2026-08-19, where it belongs under `ADR-0005` +— ops-warden implements one lane narrowly and routes the rest, and an +estate-wide enforcement model is not a lane it should absorb. + +What stays here is the consumer side: ops-warden was the repo whose deferred +flip exposed the gap, it holds the controls the model must be able to express, +and it is the first consumer the model has to satisfy. + +## What ops-warden owes zone-engine + +Inputs, not designs. `ZONE-WP-0001-T02` derives the model from the real estate, +and most of that estate is ops-warden's: + +- **27 routing catalog lanes** (`registry/routing/catalog.yaml`) with `risk`, + `status`, and `delegation` already on each — the likeliest membership inputs. +- **The actor inventory** (`adm` / `agt` / `atm`) and its TTL policy. +- **The three posture axes already shipped** — environment and maturity + (WP-0015), `organization_posture` (WP-0029) — including the honest answer to + whether `organization_posture` should be folded into zones rather than run + beside them. +- **Three controls the model must be able to express**: the flex-auth pre-sign + gate (`policy.enabled` + `fail_closed`), the agent read-boundary on + `risk: high` lanes (`ADR-0004`), and the `warden plan` escalation verdicts. +- **The compiled-registry path** (`scripts/build_flex_auth_registry.py`) — how + membership can reach flex-auth without a lookup in a latency-critical decision + path. + +## Tasks + +```task +id: WARDEN-WP-0032-T01 +status: done +priority: high +state_hub_task_id: "b03a5caa-0bb5-5cdd-bb99-32c694b0da29" +``` + +**Hand the estate inputs to `ZONE-WP-0001-T02`.** Not a design proposal — the +lanes, actors, axes, and controls above, with the exceptions ops-warden already +knows do not fit cleanly (the interim delegation lanes from WP-0030 are the +obvious candidates: a lane covered on someone else's behalf may not sit in the +same zone as one ops-warden owns outright). + +Include the `organization_posture` fold-in question honestly, including the case +against keeping it. + +**Answered by net-kingdom 2026-08-19** (canon owner of `tenancy-posture_v0.1`, +answering `ZONE-WP-0001-T01`): **do not fold it in, and do not put it in a +per-repo declaration under any key.** `organization_posture` is a fleet-wide, +time-varying scalar describing the *estate*, not a property of a declaring +service; a per-repo copy of a global goes stale in as many places as there are +repos. It stays what WP-0029 made it — an input to stance selection that the +zone model reads. Hand it over as an input, not as a candidate axis. Environment +posture and `M0`–`M3` are per-workload and remain genuinely composable; those two +are still open for `ZONE-WP-0001-T02`. + +**Done 2026-08-21.** Every input listed above is now carried in `ZONE-WP-0001`, +and `T02` there is `done` — which is the acceptance condition for this task, since +what was owed was inputs rather than a design. + +What actually reached them: the 27 graded lanes with `risk`/`status`/`delegation` +(T05), the `M0`–`M3` ladder in `registry/policy/security-posture.yaml` — which +`ZONE-WP-0001-T02` adopted as the maturity ladder rather than +`.repo-classification.yaml` `category`, on the evidence that the latter grades a +production SSH CA below a documentation repo — the three controls, and the +compiled-registry path including the dormant `trust_zone` constant at +`scripts/build_flex_auth_registry.py:77`. + +Two inputs were handed over as corrections to ops-warden's own earlier claims, +which is the part worth recording. `organization_posture` was offered as a +candidate axis and net-kingdom refused it (above); and ops-warden asserted no +registry carried a workload join key, which was true of its own catalog and false +of the estate — `rapp-*/declarations/rapp.yaml` carries eight +`workload_identity` declarations. `scripts/report_workload_join.py` then measured +the join rather than asserting it: **1 of 27 lanes** matches a declared workload. +That number is `ZONE-WP-0001-T03`'s critical path, and it came out of correcting +this repo's own input rather than out of supplying a new one. + +```task +id: WARDEN-WP-0032-T02 +status: done +priority: high +state_hub_task_id: "b3f41c85-a293-58ad-ac27-9f8110c51266" +``` + +**Replace `policy.enabled` with a zone-aware control.** Waits on +`ZONE-WP-0001-T03` and `T05`. Reads the zone of the actor being signed for and +that zone's failure mode. Ship deprecation and migration in the same change — +leaving both is the second-source-of-truth failure `ADR-0001` exists to prevent. + +Re-run `scripts/check_policy_caller_identity.py` before enabling anything: the +WP-0031 evidence (`decision:f3f7c88f9585582a`, 2026-08-19) will be stale, and +re-establishing it is cheap precisely so this is a re-check rather than a re-do. + +This closes `WARDEN-WP-0031-T05`. + +**Amended by flex-auth 2026-08-19, reviewing `ZONE-WP-0001` as the PDP.** Two +constraints that change what this task can build, both argued in full at +`ZONE-WP-0001-T03` and `T04`: + +1. **The zone-aware control splits across the boundary, it does not move.** + flex-auth will read compiled zone *membership* from the registry and apply the + per-zone *stance* from its policy package, returning an effect plus an + advisory annotation. What stays on the ops-warden side is the axis flex-auth + structurally cannot carry: **`fail_closed` is not expressible by a PDP.** + Fail-open describes what `warden sign` does when flex-auth is *unreachable* — + no decision is rendered, so no compiled data and no policy rule can reach it. + So the replacement for `policy.enabled` is not one zone-derived boolean + either; it is (a) stance, which arrives *in the decision*, and (b) failure + mode, which stays a local ops-warden setting declared per zone. Plan for two, + or T02 will be built expecting flex-auth to answer something it cannot. + +2. **The membership compiler is ops-warden's to change, and it has a name + collision to resolve first.** `scripts/build_flex_auth_registry.py:77` already + emits `"trust_zone": "platform"` as a hardcoded constant on every + ssh-certificate resource. It is a first-class field on flex-auth's `Resource`, + it is surfaced into rego input, and **no policy package reads it**. Before + compiling zone membership, either retire that constant or deliberately + repurpose it — do not add `security_zone` beside a dormant `trust_zone` and + leave the next reader to guess which is real. That is the `ADR-0001` + second-source-of-truth failure in miniature, inside a generated artifact. + +Good news for T03's cost: **no flex-auth registry schema change is required.** +`metadata`, `labels` and `attributes` already flatten into the rego input, so the +compiler can emit membership today. + +**Consumer implementation landed in the working tree 2026-08-22.** The config +loader rejects the retired `policy.enabled` and global `policy.fail_closed` +keys. `scripts/build_flex_auth_registry.py` now emits the normative +`workload_id`, `security_zone`, `security_zone_declared`, +`security_zone_admission`, `security_zone_reason`, and +`security_zone_revision` attributes; the dormant `trust_zone` field is gone. +The PEP reads compiled resource membership and applies its local per-zone +failure mode. Sign and audit records retain the zone, selected failure mode, +outcome, and decision id. + +The legacy `--no-policy` proxy switch remains only as a rejected compatibility +flag. It can no longer bypass the gate: unresolved credential targets take the +explicit `unknown` profile and its configured failure mode. + +**Done 2026-08-22.** flex-auth package v2 (commit `e521e7b`) supplies total +stance over every v0.1 zone plus `unknown`, preserves native enforcement for +`not-applicable`, and returns `audit_only` for advisory decisions. The required +live caller check passed through the existing tunnel with command-mode caller +identity and decision `decision:f3f7c88f9585582a`. The operator config was then +migrated from the two rejected global keys to `zone_registry_path`, and the +same live check passed against that real config. Full repo tests pass and +sign/audit evidence records zone, failure mode, outcome, and decision id. + +```task +id: WARDEN-WP-0032-T03 +status: done +priority: medium +state_hub_task_id: "d04a737b-ecdf-5747-ba25-20dadd99d3bc" +``` + +**Declare ops-warden's zones** in the format `ZONE-WP-0001-T05` settles, +alongside the existing posture descriptors. + +**Amended by net-kingdom 2026-08-19 — the carrier file is already settled, only +its contents are open.** Canon Decision 5.6 (`tenancy-posture_v0.1` draft-9) +rules that zone membership is declared in **`tenancy.yaml` under a reserved +top-level `zones:` key**, sibling to `tenancy:` and `provider:` and never inside +`tenancy.current`. §5.4 makes that file the repo's single posture declaration +surface, and a second root file would be the second-source-of-truth failure +`ADR-0001` exists to prevent — in ops-warden's own idiom. The key is reserved and +deliberately unconstrained in `net-kingdom/canon/schemas/tenancy-posture_v0.1.schema.json`, +so a combined declaration validates today. + +Note the consequence for this repo: **ops-warden does not currently have a +`tenancy.yaml`.** Declaring zones means writing one, which means declaring the +six-axis posture vector too. That is a real and probably overdue cost, not an +accident of this amendment — canon would rather ops-warden declare both +accurately than declare a zone with no posture beside it. + +Note also *why* stance is not something this declaration may set: canon Decision +5.6 rules that a declarer must not be the party that sets the stance, or an +accurately declared `exempt` becomes conformant *and* exempt. ops-warden declares +which zone a lane or actor is in. The stance of the pre-sign gate in that zone is +flex-auth's policy package; the failure mode is ops-warden's own setting, per +flex-auth's T03 amendment. Per flex-auth's T05 amendment, this +declaration must also say whether a zone rides the **actor** (a flex-auth +subject) or the **lane** (a flex-auth per-actor resource) — in the compiled +registry an actor is both, and the compiler needs to be told which record +carries membership. Carry the conformance rule: +*accuracy, not altitude*. Declaring a stricter zone than can be evidenced is the +failure mode that looks like progress. + +**Done 2026-08-22.** `tenancy.yaml` now declares ops-warden as an independently +governed operational execution unit with its Kubernetes service-account +binding, and admits it to `z1-operational` at `M1`, `medium`, `internal`. +`docs/evidence/security-zone-admission-2026-08-22.md` records why this is the +highest evidenced admission rather than an aspirational `M2`. The declaration +passes net-kingdom's current `tenancy-posture_v0.1` validator. + +```task +id: WARDEN-WP-0032-T04 +status: done +priority: medium +state_hub_task_id: "c7879127-3dba-55c0-853c-a10775736873" +``` + +**Amend `ADR-0006`.** Once zones exist and enforcement scoping is owned by +`zone-engine`, ADR-0006 must say that ops-warden *follows* the model rather than +owning it — a superseding record, never an in-place edit. Update `SCOPE.md`, +`wiki/WorkloadSecurityPosture.md`, and `wiki/PolicyGatedSigning.md` with it. + +**Done 2026-08-22.** ADR-0006 is marked superseded without rewriting its +decision. ADR-0009 accepts `security-zones_v0.1` as a consumer, records the +PDP/PEP split and unknown handling, and is indexed as its successor. `SCOPE.md`, +`wiki/WorkloadSecurityPosture.md`, `wiki/PolicyGatedSigning.md`, configuration +guidance, access guidance, and affected playbooks now describe the zone-aware +control and do not instruct operators to use a global bypass. + +```task +id: WARDEN-WP-0032-T05 +status: done +priority: high +state_hub_task_id: "1d968627-83f4-59cd-84ca-0f9f35e435ff" +``` + +**Grade the five exposed lanes now — do not wait for the model.** +`RISK-F-0003`: `is_high_risk` is `risk == "high"` and `risk` is optional, so the +14 ungraded lanes never reach the agent read-boundary. Five are `exec_capable` +and can therefore stream a value to an agent session: `openbao-api-key`, +`whynot-design-npm-publish`, `key-cape-oidc-login`, +`issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`. + +The durable answer is a maturity-derived default (`ZONE-WP-0001-T03`), and it is +the right answer. It is also months away, and this is a live control gap in a +shipped ADR. Grade these five explicitly, then the remaining nine. + +Grading is judgement, not backfill — each lane's grade should be justified in the +entry, and the operator should sanction the high/standard calls rather than +having them inferred. Verify separately whether OpenBao's +`agent-high-risk-boundary` policy covers these paths; `RISK-F-0003` deliberately +does not assume it does, because those paths were graded by the same omission. + +**Done 2026-08-19, operator-sanctioned.** All 14 ungraded lanes graded on merit, +each with its justification in the entry: 17 `high`, 10 `standard`, **0 +ungraded**. `warden access --fetch` with `WARDEN_AGENT_ID` set now exits 7 +on lanes that were silently outside the control an hour earlier. + +Graded on merit, not defensively. A first pass marked +`issue-core-ingestion-api-key` and `reuse-surface-hub-write-token` `high`; the +existing test `test_high_risk_lanes_classified` asserted the opposite and was +right — ordinary internal workload secrets are `standard`. Both were regraded +down. `high` means disclosure into a logged context is damaging beyond what +rotation recovers: provider keys with spend, admin PATs, tenant commercial data, +supply-chain publish rights. `inter-hub-bootstrap-ssh` is `high` **conservatively** +— ops-warden could not establish that no key material moves in the envelope, and +that is recorded in the entry so it is regraded with evidence rather than assumed +down. + +The rule is now `ADR-0007`: build-stage permissiveness stops at credential +disclosure. Not yet verified: whether OpenBao's `agent-high-risk-boundary` +policy covers these paths (T06). + +```task +id: WARDEN-WP-0032-T06 +status: done +priority: medium +state_hub_task_id: "4294084c-bf3f-5aa6-b84d-5173121882ff" +``` + +**Make absence impossible, once the model says what absence means.** Waits on +`ZONE-WP-0001-T03`. Either invert the default (absent `risk` resolves through the +lane owner's maturity, per the operator direction) or require `risk` at catalog +load and in CI. Whichever lands, the failure mode to kill is the current one: +adding a lane without a grade silently places it outside a control, with nothing +at load or in CI noticing. + +Feed back to `ZONE-WP-0001-T03` whether ops-warden can supply the join it needs — +today no lane references a workload or an environment, so the `M0`–`M3` ladder +has nothing to attach to from this side. + +**Enforcement half done 2026-08-20.** It did not need the zone model: `ADR-0007` +already decided absence is a defect, which is enough to make the code fail safe +and to gate CI. + +The real mechanism turned out to be sharper than `RISK-F-0003` described. +`is_high_risk` was `risk == "high"`, but `risk` was **not** absent at the model +layer — `RouteEntry.risk` carried a dataclass default of `"standard"`. So an +omitted grade was not unhandled; it was actively resolved to the permissive +value. Fail-open by construction, which is why nothing warned. + +Now: the default is `"ungraded"`, and `is_high_risk` returns true for anything +not in an explicit low-risk vocabulary (`standard` / `low` / `accepted`). An +omitted grade **and** a grade from a newer catalog both resolve to high, so the +boundary fails safe in both directions. `is_graded` exposes the distinction, and +`test_every_repo_catalog_lane_is_explicitly_graded` is the CI gate that stops an +ungraded lane being committed. Four regression tests cover it. + +`accepted` is in the low-risk vocabulary deliberately, ready for the +maturity-derived default: an experimental-context lane may be explicitly +accepted, which is a graded decision rather than an omission. + +**Second layer checked 2026-08-20 — it does not cover them.** The OpenBao side +was compared statically (policy file vs catalog): `agent-high-risk-boundary` +denies 5 data paths covering **6** of the **17** high-risk lanes. Eight +high-risk lanes with concrete KV paths are not denied — and **four of those were +already graded `high` before the regrade**, so the divergence is pre-existing +rather than something the grading introduced. It had simply never been +comparable before. + +This matters more than the ops-warden half: `warden access` exits 7 for all 17, +but that only protects the ops-warden path. The OpenBao policy is what protects a +direct `bao kv get`, which is the actual 2026-07-16 vector. + +Routed to `risk-nexus` as **`RISK-F-0004`**, `fix_owner: railiance-platform` — +the policy is theirs, and ops-warden does not amend another repo's control. + +**Live confirmation done 2026-08-21 — and the blocker was not real.** The +token was not expired: `bao token lookup` returned a valid `platform-admin` +token from an OIDC login, and `bao policy read agent-high-risk-boundary` +succeeded. No `bao login` was needed. Worth recording as a small instance of the +lesson `.claude/rules/finding-routing.md` already states — *re-read a blocker +before trusting it*. This one was a stale claim about the world, carried for a +day in both this workplan and `RISK-F-0009`. + +The verification script also did not exist. It was described here as "ready", +and nothing was committed. `scripts/check_agent_read_boundary.py` now exists, +with tests, and is the invariant `RISK-F-0009` asked for rather than a one-off +audit: exit 1 when any high-risk lane has no corresponding deny. It prefers the +deployed policy and falls back to the file only with a loud warning, because +deployment drift is the thing it exists to catch. Capabilities-only by +construction — it reads the policy document and lane metadata, never a secret +value, and never mints a token. + +Three results, one against ourselves: + +1. **Coverage confirmed at 6 of 17** against the live policy — the headline was + right and is no longer inferred from a checkout. +2. **Six lanes uncovered, not eight.** `RISK-F-0009` counted `openbao-api-key` + (a `//` pattern) and `ops-warden-warden-sign-token` + (a broker grant, not KV) among the concrete uncovered paths, while its own + prose said the first was a pattern. Neither can be expressed as a deny. + Corrected: 6 covered, 6 uncovered, 5 with no address. +3. **The deployed policy has drifted from the file.** The file denies + `platform/workloads/core-hub/runtime`; the server does not. No ops-warden + lane maps there, so our numbers are unchanged — it matters as evidence, since + `RISK-F-0009` named exactly this divergence as its unconfirmed risk. + +Still not established, and not ops-warden's to establish: whether any agent +token carries `agent-high-risk-boundary`, and whether any carries it together +with a `workload-kv-read-*` policy. Confirming that means minting or inspecting +tokens — a write against railiance-platform's OpenBao. Exposure stays theoretical +to the same degree as before. + +**Platform half closed 2026-08-22.** `RAILIANCE-WP-0022` consumed the generated +high-risk path input and deployed the completed deny policy. The platform-owned +invariants report **19 high-risk lanes, 14 concrete entries, 0 uncovered**. A +dedicated `coding-agent-railiance-platform` AppRole then proved deny-wins with +exactly `agent-high-risk-boundary` plus one workload read policy: data access was +denied while metadata remained readable; its single-use test identity was +self-revoked and no test tokens remained. Decision `f0955252` records the +operational identity. No KV value was read. + +The local invariant agrees against the platform policy file: 19 high-risk lanes, +14 concrete entries covered, 5 without a concrete address, 0 uncovered. This +session could not independently read the deployed policy, so live-state evidence +is the platform-owned readback above rather than a claim inferred from the local +file. + +**Done 2026-08-22.** The settled model makes the two layers complementary: +catalog CI continues to require an explicit `risk` field so omission cannot +silently weaken the agent boundary, while `RouteEntry.risk_for_zone` implements +the normative maturity-derived fallback for consumers evaluating unresolved or +future inputs (`z0` + satisfied + synthetic-only → `standard`; satisfied `z3` +→ `critical`; everything else → `high`). An explicit catalog grade always wins. +The platform deny policy and its live proof above close the direct-OpenBao half. + +```task +id: WARDEN-WP-0032-T07 +status: done +priority: medium +state_hub_task_id: "6b4bbbed-2864-5fe9-82be-22ff9543f6f4" +``` + +**Adopt Repo Manager's workload-reference owner interface.** Accepted with one +documented amendment against repo-manager revision `890f3b0`: managed +deployables use the exact `(rapp_id, workload_identity.name)` pair and optional +deployable name; an independently governed operational execution unit may use +an exact local `tenancy.yaml` declaration. Native actions, actors, grants, +patterns, and non-workload resources are explicitly `not-applicable`; unresolved +workload-applicable references remain `unknown`. No path, owner name, or +repository-name inference is allowed. + +Every one of the 27 catalog lanes now carries an explicit `workload_ref`: 3 +resolved (2 exact managed RAPP references and ops-warden's direct operational +declaration), 17 unknown with reasons, and 7 not-applicable with reasons. +`scripts/report_workload_join.py` resolves only those explicit references, +Repo Manager validates the interface and resolves both managed tuples exactly, +and regression tests reject malformed or inferred joins. This incorporates +net-kingdom's draft-12 correction received 2026-08-22: local tenancy declaration +is not an escape hatch for a managed running deployable. + +## Related + +- `zone-engine` `ZONE-WP-0001` — the model, and where this work is led from +- `ADR-0006` — enforcement is zone-scoped, never a global flag +- `WARDEN-WP-0031` — the deferred flip and its readiness evidence +- `net-kingdom` `tenancy-posture_v0.1` draft-9 Decisions 5.6, 8.4.1, 8.4.2 — canon's + answer to `ZONE-WP-0001-T01`; enforcement stance is a sibling standard, not a + seventh axis, and the declaration surface is `tenancy.yaml` diff --git a/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0033-native-lane-handoff.md b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0033-native-lane-handoff.md new file mode 100644 index 00000000..55cd0150 --- /dev/null +++ b/docs/changes/netkingdom-target-2026-10-17/warden-source-projection-r4/backup/workplans/WARDEN-WP-0033-native-lane-handoff.md @@ -0,0 +1,344 @@ +--- +id: WARDEN-WP-0033 +type: workplan +title: "Native lane handoff — review secrets-engine's catalog admission, and fix what it exposed" +domain: infotech +repo: ops-warden +status: finished +owner: ops-warden +topic_slug: netkingdom +planning_priority: P1 +depends_on_workplans: + - WARDEN-WP-0030 +created: "2026-08-21" +updated: "2026-08-28" +state_hub_workstream_id: "4627d89b-4b00-562a-81e9-76e96f90fa7e" +--- + +# WARDEN-WP-0033 — Native lane handoff + +On 2026-08-20 `secrets-engine` accepted five of ops-warden's seven interim +proxy lanes for catalog admission (`SECRETS-WP-0006`, decision +`ae676382-1826-4e04-aa4e-bb77990c7a0d`), rejected two with reasons ops-warden +agrees with, drafted the five entries itself rather than waiting for the offered +contribution, and asked for a line-by-line review of the non-secret metadata. + +In the same hour `railiance-platform` closed the `RISK-F-0009` coverage gap and +asked ops-warden for two things back. + +This workplan is the response to both, plus the defect the review turned up in +ops-warden's own grading model — which is the most consequential item here and +would not have been found without the second pair of eyes. + +## Why a workplan and not an adhoc + +Four counterparties are waiting, one deliverable is a **cross-repo interface** +another repo will consume on a schedule, and the review carries approval +semantics — `secrets-engine` holds interim proxy ownership open until each lane +has approved native verification. The convention reserves adhocs for low-risk +work completed directly; this is none of those. + +## Tasks + +```task +id: WARDEN-WP-0033-T01 +status: done +priority: high +state_hub_task_id: "154f2f03-387d-5fe6-a0f5-1929c46a2bd8" +``` + +**Review the five drafted catalog entries and reply.** +`issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`, +`openrouter-llm-connect`, `forgejo-admin-api-token`, +`email-connect-transactional` at `secrets-engine@784be97`. + +Review the axes they asked for: owner-repo coordinates, field grouping, workload +consumers, rotation/deactivation owners, delivery intent. Verify claims against +the authoritative `railiance-platform` CCRs — **never against a secret read**; +`bao kv get` on any of these paths is the 2026-07-16 vector and three of the five +are `risk: high`. + +Accept their two rejections. `openbao-api-key` is a routing template rather than +one lane and `key-cape-oidc-login` belongs to key-cape — that is `ADR-0005` +applied to ops-warden by someone else, correctly. + +```task +id: WARDEN-WP-0033-T02 +status: done +priority: high +state_hub_task_id: "6996d07f-63bb-5708-a171-68c4b1bbddde" +``` + +**Correct ops-warden's per-path risk grading — the defect T01 exposed.** + +`secrets-engine` graded `issue-core-ingestion-api-key` **high**; ops-warden grades +it **standard**, and deliberately: WP-0032-T05 regraded it *down* on 2026-08-19, +operator-sanctioned, because `test_high_risk_lanes_classified` asserted standard +and was judged right — "ordinary internal workload secrets are standard". + +That reasoning was incomplete, and CCR-2026-0002 says so explicitly: the path +carries **both** `ISSUE_CORE_API_KEY` **and** `GITEA_BACKEND_TOKEN`, a Forgejo +backend token, and the CCR records keeping both as a deliberate field-set +decision. + +**The root cause is structural, not a single bad call.** ops-warden grades a +*lane* by its headline field — the catalog carries one `fetch_command` naming one +field and no `fields` list at all — but the disclosure unit is the **path**: a +`bao kv get` returns every field stored there. So a lane can be graded on its +least dangerous contents. `ADR-0007` says every lane carries an explicit grade; +it does not say the grade must cover everything a read of that path would +disclose, and it should. + +Fix the grade, then fix the model that produced it: record `fields` per lane and +grade on the union. Check the other 25 lanes for the same shape. + +**Done 2026-08-21 — and it was two lanes, not one.** While verifying +`reuse-surface-hub-write-token` I told secrets-engine their second field was +unevidenced and asked them to confirm it. It was evidenced: `CCR-2026-0005`'s +`kv_path` block lists both fields and its notes describe the HMAC's alignment +with Forgejo org webhook id=1. A truncated grep, and a retraction sent within +twenty minutes so they would not spend time on it. That lane was under-graded on +exactly the same reasoning, and both had been regraded *down* in the same T05 +pass — which is what makes this a systematic flaw rather than one bad call. + +Blast radius checked and bounded: of the 8 remaining `standard` lanes, 6 have no +KV path at all (SSH, policy check, tunnel, principals, issue-sink, key-cape +login) so nothing is disclosed by a read. Two do have paths and no CCR field +evidence — `rein-openweights-openrouter-approle` and `coulomb-social-runtime-env` +(a whole k8s env Secret, which by shape almost certainly holds several fields). +Deliberately **not** regraded: `ADR-0008` §3 says an unknown field set is stated +rather than assumed, and grading is operator-sanctioned judgement, not backfill. +They are the open item on this task. + +Shipped: both regrades with their evidence and the superseded reasoning kept +inline, `fields` recorded with its CCR source, the test that had been holding the +wrong answer inverted with an explanation of why it was wrong to trust it, and +**`ADR-0008`** — a lane's grade covers every field its path discloses. That is a +new binding rule, so it is a record rather than a wiki note. + +```task +id: WARDEN-WP-0033-T03 +status: done +priority: high +state_hub_task_id: "a736f983-94da-5a4a-aaf9-5114485518a6" +``` + +**Emit the generated high-risk data-path artifact for `railiance-platform`.** + +They asked for a versioned artifact of concrete high-risk data paths +(`id` + `data_path` + catalog revision) to consume instead of hand-maintaining +the deny list — the half of the `RISK-F-0009` fix ops-warden explicitly declined +to build *for* them. Emitting the artifact is not the same as amending their +policy: they still own what to deny. That boundary is the point of `ADR-0002` +and must survive this task. + +Must be generated, never hand-edited, and must carry the catalog revision so a +consumer can tell what it was derived from. Depends on T02 — publishing the deny +set before fixing the grades would ship the wrong list to a consumer who will +apply it. + +**Done 2026-08-21.** `scripts/emit_high_risk_paths.py` → +`registry/generated/high-risk-data-paths.yaml`: 19 high-risk lanes, 14 concrete +data paths, 5 with no single KV address listed separately so a consumer does not +read the absence as an omission. Carries `catalog_revision`, its date, and a +`catalog_dirty` flag — a revision that does not describe the file it came from is +worse than none. + +The T02 dependency was not theoretical. The two regrades land in this artifact, +and `check_agent_read_boundary.py` now reports **2 uncovered** against a policy +railiance-platform closed to 0 yesterday. Emitting before regrading would have +handed them a list that confirmed a coverage claim that had just stopped being +true. + +`fields` is emitted as `null` where no CCR declares the set, never as a +single-element guess — `ADR-0008` §3. Two CI tests: the artifact must be current, +and every high-risk lane must appear in it, so a lane graded high after the last +emit cannot silently fail to reach the consumer. + +Boundary held: the header states this is an input and not a policy, and that +railiance-platform may deny more, deny less, or dispute a grade (`ADR-0002`). + +```task +id: WARDEN-WP-0033-T04 +status: done +priority: medium +state_hub_task_id: "5acac140-a586-5db3-b231-bbf236710786" +``` + +**Route the coding-agent issuance identity question.** + +`RAILIANCE-WP-0017` is blocked on defining a distinct coding-agent issuance +identity and proving deny-wins when that identity is combined with workload read. +They asked ops-warden to route ownership. + +Route it; do not absorb it (`ADR-0005`, `ADR-0003`). ops-warden owns actor +identity for `adm`/`agt`/`atm` **SSH certificates** and nothing else — a coding +agent's OpenBao issuance identity is an IAM question. The likely owner is +`key-cape`, with `user-engine` and `zone-engine` both plausibly involved. Say so +with reasoning rather than guessing, and record the answer either way. + +Note the interaction with `ADR-0004`: the agent read-boundary already depends on +`WARDEN_AGENT_ID` being set, which is an honour-system marker on the ops-warden +side. A real issuance identity is what would make that boundary hold on the +OpenBao side too, so ops-warden is an interested consumer, not a bystander. + +**Routed 2026-08-21 to `key-cape` (msg 903b2223); waiting on accept or refuse.** +Reasoning given: it is an identity and issuance question about a principal +authenticating to OpenBao, which is key-cape/Keycloak's. The precedent is an hour +old and runs the same direction — `secrets-engine` declined `key-cape-oidc-login` +as ops-warden's to hand them, on the grounds that login and identity-token +issuance stay with key-cape. Absorbing this would contradict agreeing with them. + +Named the adjacent parties explicitly rather than leaving them to inference: +`zone-engine` has an interest (a coding-agent identity is a strong candidate zone +subject) and `user-engine` is **not** involved — this is a machine principal, not +an end-user account. Stated so nobody concludes it by elimination. + +Asked for a refusal-with-pointer as an equally good answer. The failure mode to +avoid is the 2026-08-17 one recorded in `.claude/rules/finding-routing.md`: +ops-warden answered a question well and never routed it, and another repo ended +up filing it. + +**Followed up 2026-08-23 after the immediate enforcement gap closed.** +`RAILIANCE-WP-0022` no longer waits for this ownership decision: the platform +owner deployed a dedicated coding-agent AppRole, proved deny-wins when it is +combined with workload read, and identified an exact-bound KeyCape JWT role as +the migration target. That makes the remaining question narrower and more +important rather than obsolete: who owns issuance of the durable +KeyCape/Keycloak-backed machine identity? + +Direct follow-up `d25d4604-5713-42a8-8e3a-1ea31b5a5cc7` asks `key-cape` to +accept that target identity with an authoritative workplan/interface, or refuse +and name the actual owner. T04 remains `wait` until one of those two answers is +recorded; the live AppRole is operational evidence, not an ownership answer. + +**Answered — accepted. Closed 2026-08-28.** `key-cape` accepted issuance +ownership in `KEY-WP-0009-T03` (`status: done`, 2026-08-23): the non-secret static +registration `codex-railiance-platform` is published in +`key-cape/config/service-clients.example.yaml` — subject +`service:codex:railiance-platform`, tenant `tenant:coulomb`, role `coding-agent`, +scope `openbao:login`, `client_credentials`, 15-minute lifetime — with the +service-auth claims, renewal, expiry and failure semantics in +`key-cape/docs/openbao-service-auth-contract.md` (`T02`). The split is exactly the +one the routing asked for: KeyCape owns JWT issuance and client disablement, +railiance-platform owns the exact-bound OpenBao role and policy, OpenBao owns +enforcement, and no secret value enters either repository. + +**The answer was found by reading their repo, not by receiving it.** +`KEY-WP-0009-T04` records replying to ops-warden; no such message exists in the +ops-warden inbox — 0 messages from `key-cape`, read or unread. The acceptance had +been sitting done for five days while this task sat `wait` on it. + +That is the T05 lesson landing on T04: a blocker is a claim about the world at a +date, and this one had stopped being true. `verified: source-read` is doing real +work here — it is the difference between "we asked" and "we checked". The +mechanism is right; what it needs is for someone to run it, which is why the +lanes below were re-verified in the same pass rather than date-bumped. + +Consequence for `ADR-0004`: the honour-system `WARDEN_AGENT_ID` marker now has a +real issuance identity behind it on the OpenBao side. ops-warden remains a +consumer of that identity and does not own it. + +```task +id: WARDEN-WP-0033-T05 +status: done +priority: medium +state_hub_task_id: "75051d17-399b-5129-860b-ae00dae91c47" +``` + +**Make blocker staleness a mechanism instead of an intention.** + +Four stale blockers surfaced in twelve hours: an OpenBao token recorded expired +that was valid, a verification script recorded ready that had never been written, +a ten-day `secrets-engine` question answerable from their source, and +`FLEX-WP-0007` cited as blocking `policy.enabled` seven weeks after it read +`finished`. `.claude/rules/finding-routing.md` has said *re-read a blocker before +trusting it* since `RISK-F-0001`. Saying it has not worked. + +`warden route gaps` had a `--stale-days` threshold defaulting to 90, which was +not loose but **inert** — the register was created 2026-08-15, so it could not +fire before November. + +**Done 2026-08-21.** Two changes, and the second matters more: + +1. **Split the cadences.** `DEFAULT_STALE_DAYS` (90) still governs pointer + freshness — "is this the right owner and page" genuinely is quarterly. New + `DEFAULT_BLOCKER_STALE_DAYS` (14) governs interim blockers, calibrated on the + cases that cost something: ten days for the secrets-engine lanes, one day for + `RISK-F-0001`, ~50 for `FLEX-WP-0007`. At ~15 lanes it surfaces about one a + day rather than a wall, and it fires on zero lanes on age today. + + **Then scaled by risk, after risk-nexus answered.** They accepted the offer to + converge and published their convention: 14 days critical/high, 30 medium, 60 + low, with fix state *read* from the owning repo rather than remembered. Their + framing — "point `warden route gaps` at those windows and the two will agree + without either of us building a shared mechanism" — is better than a joint + tool, so `blocker_stale_days()` now maps lane `risk` onto exactly those + windows. `ungraded` takes the *shortest*, not the longest: `ADR-0007` makes an + absent grade a defect, so its blocker is the least trustworthy of all. + +2. **`verified:` distinguishes re-checking from re-editing.** `reviewed` records + when someone touched the entry; nothing recorded whether the claim was + re-established. `owner-confirmed` and `source-read` count; + **`asked-and-waiting` and `unverified` do not**, and a lane in those states is + stale regardless of its date. `key-cape-oidc-login` is the proof: asked today, + zero days old, correctly flagged. + +Current state: 14 non-draft interim lanes — 5 `owner-confirmed`, 1 +`asked-and-waiting`, 8 `unverified`. The 8 are honest; they were carried forward +this session without a check and now say so instead of hiding behind a fresh date. + +`--fail-on-stale` exits 3 so a cron job or gate can act. **Deliberately not a CI +test on age**: a date-triggered failure breaks the build on a calendar day with +no code change, punishing whoever commits next rather than whoever owns the +blocker. The CI test is structural instead — every interim lane must record +*how* it was verified, which fails on the commit that introduces the omission. + +```task +id: WARDEN-WP-0033-T06 +status: done +priority: high +state_hub_task_id: "94f77f5a-f919-5328-832c-ba1d24c6431b" +``` + +**Correct first-time OpenBao administration routing.** `rapp-postgres` reported +on 2026-08-22 that `warden plan` mapped first-time +`database/config/platform-pg-2` administration to the generic +`openbao-api-key` template. It consequently proposed paste-once KV provisioning +and a workload OIDC role, neither of which can configure database connections, +policies, auth roles, or token roles. Their Desk session stopped without an +approval or secret action. + +The authoritative platform runbook and rapp-postgres's live T04 evidence agree +on the missing distinction: this is one attended KeyCape-backed OpenBao identity +act at auth mount `netkingdom`, role `platform-admin`. It is not a credential +value handoff. Root stays offline break-glass authority and a workload role must +never be widened to make the operation pass. + +Add an exact `openbao-platform-admin-login` lane, an operator playbook, and a +regression that makes the reported request resolve to `founder_required` with +`oidc_login` — never `paste_once_provision`. Verify the route, then return the +corrected non-secret command to rapp-postgres. + +**Done 2026-08-22.** The new active lane resolves the exact reported request at +score 20, ahead of the generic KV template at 11, and returns one +`founder_required` act: +`bao login -no-print -method=oidc -path=netkingdom role=platform-admin`. +Planner output offers only `warden access openbao-platform-admin-login --fetch` +and the exact owner command; login lanes no longer inherit secret-value +transports (`--exec`, `--out`, `--wrap`). The lane is explicitly a high-risk, +non-workload human identity act, so the generated boundary artifact lists it as +having no KV address rather than inventing one. + +Verification: 384 tests pass, Ruff passes, workload accounting resolves all 28 +lanes (3 resolved, 17 unknown, 8 not-applicable), and the boundary invariant +reports 20 high-risk lanes, 14 concrete paths covered, 6 non-KV/pattern lanes, +0 uncovered. No login or credential action was performed. + +## Related + +- `secrets-engine` `SECRETS-WP-0006` — catalog admission, decision `ae676382` +- `RISK-F-0009` — closed by railiance-platform 2026-08-21; 0 uncovered +- `railiance-platform` `RAILIANCE-WP-0022` (boundary coverage), `RAILIANCE-WP-0017` +- `ADR-0002`, `ADR-0003`, `ADR-0004`, `ADR-0005`, `ADR-0007` +- `WARDEN-WP-0030` — the delegation register these five lanes retire from