tegwick 9ed8b452a1

CI Smoke / host-smoke (push) Successful in 0s

Details

CI Smoke / container-smoke (push) Successful in 2s

Details

Refresh the activity-core issue-sink lane; close WP-0032-T01

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>

2026-08-21 00:43:42 +02:00

3.1 KiB

Raw Blame History

activity-core IssueSink → issue-core REST emission

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 owner repos — this page is a checklist and index only (no-double-source rule).

Owners

Concern	Owner repo	Authoritative doc
IssueSink consumer (`IssueCoreRestSink`)	`activity-core`	`docs/issue-core-emission-boundary.md`
Ingestion server (`POST /issues/`)	`issue-core`	`README.md` — REST Ingestion Server
Production secret injection (K8s/OpenBao)	`railiance-platform`	catalog id `issue-core-ingestion-api-key` (draft until path ships)

Do not ask ops-warden

ISSUE_CORE_API_KEY is a shared ingestion key between activity-core and issue-core. It is not an SSH certificate and ops-warden does not vend it.

Generic API-key routing: warden route show openbao-api-key --json
This emission lane: warden route show activity-core-issue-sink --json
State Hub messages to ops-warden expecting a key value will not succeed.

Never paste key values into Git, State Hub, workplans, logs, or agent chat.

Worker checklist

Confirm sink mode — ISSUE_SINK_TYPE=rest for live emission; null for dry-run (Railiance production default today). See activity-core SCOPE.md.
Pair env vars on both sides (same value):
- 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
Local dev — generate once, export on both processes:
```
export ISSUE_CORE_API_KEY="$(python3 -c 'import secrets; print(secrets.token_urlsafe(32))')"
issue serve --host 127.0.0.1 --port 8765   # issue-core terminal
```
Use default: local in ~/.config/issue-tracker/backends.json for local smoke — a remote Gitea default backend will hang on ingest.
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).
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

issue-core requires triggering_event_id as a UUID; activity-core cron paths may send non-UUID keys (e.g. "scheduled"). Event-driven emission with real event UUIDs works; align schemas before enabling cron rules against live REST.

3.1 KiB Raw Blame History