tegwick
bfa0eda327
T03 stays parked (neither apply nor withdraw). Neither un-park trigger has fired, so the ad-hoc is finished and WP-0027 T02 owns the question.
145 lines
7.3 KiB
Markdown
145 lines
7.3 KiB
Markdown
---
|
|
id: 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: "c8c51e07-f42d-43b1-873f-fec6cda7ed25"
|
|
---
|
|
|
|
# Ad Hoc Tasks — 2026-08-11
|
|
|
|
### T01 — Repair stale `rapp-qonto-keycape-client` wiki anchor (restore green routing suite)
|
|
|
|
```task
|
|
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`.
|
|
|
|
- [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: 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.
|
|
|
|
- [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: ADHOC-2026-08-11-T03
|
|
status: done
|
|
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.
|
|
|
|
**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
|