coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions
ops-warden/workplans/ADHOC-2026-08-11.md
tegwick 9d42dd5abd
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
Add WP-0030 delegation register; refresh INTENT and SCOPE 
Founder directive: ops-warden works with, never replaces or duplicates,
secrets-engine / tenant-engine / user-engine. Covering an unfilled gap is
acceptable only as a tracked interim with a named intended owner.

- INTENT §9 "Cover gaps, but never silently own them"; success criterion 7;
  tenant-engine and user-engine added to the literacy table; non-goal on
  permanently owning another component's lane
- WP-0030 (proposed): delegation: metadata, backfill, warden route gaps,
  promotion gate, publish the register to owner repos
- history/2026-08-11-delegation-surface-assessment.md: 2 of 24 lanes carry
  exec_owner; 11 proxies record no intended owner
- SCOPE refreshed to 2026-08-11 (was 6 workplans behind); completeness C5 -> C4

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:11:01 +02:00

4.6 KiB
Raw Blame History

id type title domain repo status owner topic_slug created updated state_hub_workstream_id
ADHOC-2026-08-11 workplan Ad Hoc Tasks — 2026-08-11 infotech ops-warden active claude custodian 2026-08-11 2026-08-11 c8c51e07-f42d-43b1-873f-fec6cda7ed25

Ad Hoc Tasks — 2026-08-11

T01 — Repair stale rapp-qonto-keycape-client wiki anchor (restore green routing suite)

id: ADHOC-2026-08-11-T01
status: done
priority: medium
state_hub_task_id: "b0420c81-81bb-4733-9aa0-e9c867503387"

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.

  • Repointed rapp-qonto-keycape-client.wiki_ref to wiki/CredentialRouting.md#routing-catalog-index (the live heading). No other entry used the stale anchor.
  • uv run pytest tests/test_routing.py -q → 61 passed.
  • 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)

id: ADHOC-2026-08-11-T02
status: done
priority: medium
state_hub_task_id: "546a4299-314c-448d-b2fb-201ddc50353c"

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.

  • 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.
  • 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.
  • 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.
  • secrets-engine warden-sign (80456912) — see T03; replied with status and referred the live-apply question to the owner.

T03 — Open question for the operator: withdraw or keep the warden-sign AppRole

id: ADHOC-2026-08-11-T03
status: wait
priority: medium
state_hub_task_id: "b930df62-b8dd-45ae-b0a5-98298cdfa1b6"

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.

Decision needed from Bernd: keep the AppRole as a broker-independent fallback path to signing, or withdraw SECRETS-WP-0004. ops-warden's recommendation is withdraw unless there is a concrete failure mode the broker cannot cover — a second standing credential to rotate and audit is a real cost for a lane that currently works. Not ops-warden's call; asked secrets-engine to hold live apply until it resolves. Task stays wait pending that answer.