activity-core/AGENTS.md

activity-core — Agent Instructions

Repo Identity

Purpose: Durable task factory built on Temporal. Manages ActivityDefinitions, schedules recurring workflows via Temporal Schedules, routes events via NATS JetStream, and exposes a FastAPI CRUD surface for the custodian domain.

Domain: custodian Repo slug: activity-core Topic ID: cee7bedf-2b48-46ef-8601-006474f2ad7a Workplan prefix: ACTIVITY-WP-

---

State Hub Integration

The Custodian State Hub tracks work across all domains. Interact via HTTP REST — there is no MCP server for Codex agents.

Context	URL
Local workstation	http://127.0.0.1:8000
Remote via tunnel	http://127.0.0.1:18000

Orient at session start

# Offline brief — works without hub connection
cat .custodian-brief.md

# Active workstreams for this domain
curl -s "http://127.0.0.1:8000/workstreams/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \
  | python3 -m json.tool

# Check inbox
curl -s "http://127.0.0.1:8000/messages/?to_agent=activity-core&unread_only=true" \
  | python3 -m json.tool

Mark a message read:

curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
  -H "Content-Type: application/json" -d '{}'

Log progress (required at session close)

curl -s -X POST http://127.0.0.1:8000/progress/ \
  -H "Content-Type: application/json" \
  -d '{
    "summary": "what was done",
    "event_type": "note",
    "author": "codex",
    "workstream_id": "<uuid>",
    "task_id": "<uuid>"
  }'

Omit workstream_id / task_id when not applicable.

Update task status

curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
  -H "Content-Type: application/json" \
  -d '{"status": "progress"}'
# values: wait | todo | progress | done | cancel

Flag a task for human review

curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
  -H "Content-Type: application/json" \
  -d '{"needs_human": true, "intervention_note": "reason"}'

---

Session Protocol

Start:

1. cat .custodian-brief.md — domain goal and open workstreams (offline-safe)
2. Check inbox: GET /messages/?to_agent=activity-core&unread_only=true; mark read
3. Scan workplans: ls workplans/ — note status: ready, active, or blocked files and open tasks
4. Check blocked tasks: GET /tasks/?needs_human=true

During work:

• Update task statuses in workplan files as tasks progress
• Record significant decisions via POST /decisions/

Close:

1. Update workplan file task statuses to reflect progress
2. Log: POST /progress/ with a summary of what changed
3. Note for the custodian operator: after workplan file changes, run from ~/state-hub:

   make fix-consistency REPO=activity-core
   

   This syncs task status from files into the hub DB.

---

Credential and access routing

Audience: Codex, Claude Code, Grok, and custodian agents that call llm-connect for inference. Run this check before requesting secrets, API keys, SSH access, login tokens, or database passwords — in any repo, not only ops-warden.

ops-warden issues SSH certificates only (warden sign, cert_command). Every other credential need belongs to another subsystem. Do not message ops-warden on State Hub expecting a secret value; the reply is a pointer, not a key.

Lookup (do this first)

warden route find "<describe your need>" --json
warden route show <catalog-id> --json

Requires the warden CLI from ~/ops-warden (uv tool install . or uv run warden).

Agent runtime	How to orient
Codex / Grok (shell, HTTP State Hub)	warden route commands above; inbox to_agent=activity-core is for coordination, not secret vending
Claude Code (MCP when available)	get_domain_summary("custodian") for workstreams; still use warden route for credential ownership
llm-connect (inference service)	Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by warden route

Quick routing table

I need…	Owner	ops-warden executes?
SSH cert (adm/agt/atm)	ops-warden	Yes — warden sign
API key, DB password, provider token	OpenBao (railiance-platform)	No — route only
Login / OIDC / MFA	key-cape / Keycloak	No — route only
Authorization decision	flex-auth	No — route only
activity-core → issue-core emission	activity-core + issue-core	No — warden route show activity-core-issue-sink
SSH tunnel	ops-bridge (+ cert_command from warden)	No — route only

Anti-patterns (do not do these)

• POST /messages/ to ops-warden asking for ISSUE_CORE_API_KEY, OPENROUTER_API_KEY, etc.
• Inventing warden secret, warden login, warden bao, warden tunnel — they do not exist
• Pasting secrets into Git, State Hub, workplans, logs, or chat

Other capabilities (reuse-surface)

Non-credential capabilities are usually discovered through reuse-surface federation (reuse-surface registry / capability.* indexes). Credential routing is inlined in every repo's agent instructions because it is high-frequency, high-risk, and easy to get wrong.

Canon: ~/ops-warden/wiki/CredentialRouting.md · catalog ~/ops-warden/registry/routing/catalog.yaml

Issue-core emission (ISSUE_SINK_TYPE=rest)

activity-core emits tasks to issue-core via IssueCoreRestSink (src/activity_core/issue_sink.py).

Do not request ISSUE_CORE_API_KEY from ops-warden — ops-warden issues SSH certs only. For routing: warden route show activity-core-issue-sink --json.

Env var	Purpose
ISSUE_CORE_URL	issue-core base URL (default http://127.0.0.1:8765)
ISSUE_CORE_API_KEY	Shared ingestion key — sent as Authorization: Bearer
ISSUE_SINK_TYPE	rest (live POST) or null (dry-run; Railiance default)

Local dev: generate one key, export on both activity-core and issue-core processes. See docs/issue-core-emission-boundary.md and issue-core README.md. Use default: local in issue-core backends.json for local smoke.

Production: inject the same key on both sides via OpenBao/K8s (coordinate railiance-platform when the canonical path ships).

---

Workplan Convention (ADR-001)

Work items originate as files in this repo — not in the hub. The hub is a read/cache/index layer that rebuilds from files.

File location: workplans/ACTIVITY-WP-NNNN-<slug>.md

Archived location: finished workplans may move to workplans/archived/YYMMDD-ACTIVITY-WP-NNNN-<slug>.md. The YYMMDD prefix is the completion/archive date; the frontmatter id does not change.

Ad Hoc Tasks: small opportunistic fixes discovered during a session use workplans/ADHOC-YYYY-MM-DD.md with task ids ADHOC-YYYY-MM-DD-T01, etc. Use this only for low-risk work completed directly; create a normal workplan for anything needing analysis, design, approval, dependencies, or multiple phases.

Frontmatter:

---
id: ACTIVITY-WP-NNNN
type: workplan
title: "..."
domain: custodian
repo: activity-core
status: proposed | ready | active | blocked | backlog | finished | archived
owner: codex
topic_slug: ...
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
state_hub_workstream_id: "<uuid>"   # written by fix-consistency — do not edit
---

Use proposed for a new draft, ready after review against current repo state, and finished after implementation. stalled and needs_review are derived health labels, not frontmatter statuses.

Task block format (one per ## section):

## Task Title

` ` `task
id: ACTIVITY-WP-NNNN-T01
status: wait | todo | progress | done | cancel
priority: high | medium | low
state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
` ` `

Task description text.

Status progression: todo → progress → done; use wait for a task blocked on external input and cancel for intentionally abandoned work. Workstream/workplan lifecycle status is separate; frontmatter blocked remains valid there.

To create a new workplan:

1. Write the file following the format above
2. Notify the custodian operator to run make fix-consistency REPO=activity-core (or send a message to the hub agent via POST /messages/)