coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

Refresh the activity-core issue-sink lane; close WP-0032-T01
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
issue-core asked us to drop a CoulombCore/port-18765 bridge topology from
activity-core-issue-sink. That topology was never in this repo — the only address
the playbook carried was a local-dev 127.0.0.1:8765 example. What was actually
stale was step 5, which still told workers to coordinate with railiance-platform
"when the canonical path ships"; it shipped 2026-07-02 and the lane is active.

So: point at issue-core's SCOPE.md for the production address rather than
restating it here (ADR-0001), state plainly that no bridge or forwarded port is
involved so the next reader does not re-derive the retired topology, and route
step 5 through warden route / warden rotate-guide instead of a read.

WP-0032-T01 closes as done. What was owed was inputs, not a design, and
ZONE-WP-0001-T02 is done carrying all of them — including the two that were
corrections to ops-warden's own claims (organization_posture, refused by
net-kingdom; and the workload join key, which this repo wrongly said did not
exist anywhere).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 00:43:42 +02:00
parent 72f7dc2c5d
commit 9ed8b452a1
3 changed files with 34 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

2
registry/routing/catalog.yaml
View file

@ -274,7 +274,7 @@ entries:
warden_executes: false
wiki_ref: wiki/playbooks/activity-core-issue-sink.md#worker-checklist
canon_ref: net-kingdom/docs/platform-identity-security-architecture.md
reviewed: "2026-06-18"
reviewed: "2026-08-21"
status: active
delegation:
mode: native

15
wiki/playbooks/activity-core-issue-sink.md
View file

@ -1,6 +1,6 @@
# activity-core IssueSink → issue-core REST emission
Date: 2026-06-18
Date: 2026-06-18 · Reviewed: 2026-08-21
Pointer playbook for agents wiring **activity-core** task emission to the
**issue-core** REST ingestion endpoint. Authoritative contracts live in the
@ -36,7 +36,10 @@ Never paste key values into Git, State Hub, workplans, logs, or agent chat.
1. **Confirm sink mode** — `ISSUE_SINK_TYPE=rest` for live emission; `null` for
dry-run (Railiance production default today). See activity-core `SCOPE.md`.
2. **Pair env vars on both sides** (same value):
- `ISSUE_CORE_URL` — e.g. `http://127.0.0.1:8765` locally
- `ISSUE_CORE_URL` — `http://127.0.0.1:8765` for local dev. The production
address is issue-core's to publish, not ours to restate; take it from
`issue-core`'s `SCOPE.md` (in-cluster on railiance01 as of ISSUE-WP-0007 —
no CoulombCore bridge or forwarded port is involved)
- `ISSUE_CORE_API_KEY` — shared secret; activity-core sends
`Authorization: Bearer <key>`; issue-core validates on ingest
3. **Local dev** — generate once, export on both processes:
@ -48,9 +51,11 @@ Never paste key values into Git, State Hub, workplans, logs, or agent chat.
smoke — a remote Gitea default backend will hang on ingest.
4. **Verify** — `uv run pytest tests/test_issue_sink.py` in activity-core;
one live POST should return `201` with `issue_id` (see issue-core README).
5. **Production** — inject `ISSUE_CORE_API_KEY` via OpenBao/K8s on both
deployments; coordinate with `railiance-platform` when the canonical path
ships (`issue-core-ingestion-api-key` catalog entry).
5. **Production** — `ISSUE_CORE_API_KEY` is injected via OpenBao + ESO. The
canonical path shipped 2026-07-02 and the lane is `active`:
`warden route show issue-core-ingestion-api-key --json`. Rotation is
`railiance-platform`'s; use `warden rotate-guide` rather than reading the
value to check it.
### Known contract gap

24
workplans/WARDEN-WP-0032-security-zones.md
View file

@ -50,7 +50,7 @@ and most of that estate is ops-warden's:
```task
id: WARDEN-WP-0032-T01
status: todo
status: done
priority: high
state_hub_task_id: "b6dac514-4b05-47b8-8745-6a1c67b6100e"
```
@ -74,6 +74,28 @@ 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: wait