# railiance-master — Agent Instructions ## Repo Identity **Purpose:** Railiance framework architecture home: repository taxonomy, architectural boundaries, framework-level ADRs, and cross-repo workplans for changes spanning multiple Railiance repositories. **Domain:** financials **Repo slug:** railiance-master **Topic ID:** `ca369340-a64e-442e-98f1-a4fa7dc74a38` **Workplan prefix:** `RMASTER-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 (railiance01, in-cluster) | `http://10.43.68.154:8000` | | Optional local edge relay | `http://127.0.0.1:18080` | When an operator has enabled the edge relay, set `API_BASE` to the relay URL. Queueable writes return an explicit queued receipt if the central hub is unreachable. Treat that as pending local evidence, then ask the operator to run `statehub outbox status` or `statehub outbox replay` after connectivity returns. ### Orient at session start ```bash # Offline brief — works without hub connection cat .custodian-brief.md # Active workplans for this domain python3 - <<'PY' import json, urllib.request with urllib.request.urlopen("http://127.0.0.1:8000/workplans/?topic_id=ca369340-a64e-442e-98f1-a4fa7dc74a38&status=active") as r: print(json.dumps(json.loads(r.read().decode()), indent=2)) PY # Check inbox python3 - <<'PY' import json, urllib.request with urllib.request.urlopen("http://127.0.0.1:8000/messages/?to_agent=railiance-master&unread_only=true") as r: print(json.dumps(json.loads(r.read().decode()), indent=2)) PY ``` Mark a message read: ```bash python3 - <<'PY' import json, urllib.request req = urllib.request.Request( "http://127.0.0.1:8000/messages//read", data=b"{}", headers={"Content-Type": "application/json"}, method="PATCH", ) with urllib.request.urlopen(req) as r: print(r.read().decode()) PY ``` ### Log progress (required at session close) ```bash python3 - <<'PY' import json, urllib.request payload = { "summary": "what was done", "event_type": "note", "author": "codex", "workplan_id": "", "task_id": "", } req = urllib.request.Request( "http://127.0.0.1:8000/progress/", data=json.dumps(payload).encode(), headers={"Content-Type": "application/json"}, method="POST", ) with urllib.request.urlopen(req) as r: print(r.read().decode()) PY ``` Omit `workplan_id` or `task_id` when not applicable. ### Update task status ```bash python3 - <<'PY' import json, urllib.request req = urllib.request.Request( "http://127.0.0.1:8000/tasks/", data=json.dumps({"status": "progress"}).encode(), headers={"Content-Type": "application/json"}, method="PATCH", ) with urllib.request.urlopen(req) as r: print(r.read().decode()) PY # values: wait | todo | progress | done | cancel ``` ### Flag a task for human review ```bash python3 - <<'PY' import json, urllib.request req = urllib.request.Request( "http://127.0.0.1:8000/tasks/", data=json.dumps({"needs_human": True, "intervention_note": "reason"}).encode(), headers={"Content-Type": "application/json"}, method="PATCH", ) with urllib.request.urlopen(req) as r: print(r.read().decode()) PY ``` --- ## Session Protocol **Start:** 1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) 2. Check inbox: `GET /messages/?to_agent=railiance-master&unread_only=true`; mark read 3. Scan `workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks 4. Check human-needed 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. If finishing a workplan: hand off residuals as live work records first 3. Log `POST /progress/` with a summary of what changed 4. After workplan file changes, run: ```bash statehub fix-consistency ``` Coding agents should run this directly; ask the operator only if the CLI or State Hub API is unavailable. 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 ```bash warden route find "" --json warden route show --json ``` Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`). ### 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 | | SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only | ### Anti-patterns - `POST /messages/` to `ops-warden` asking for secret values - inventing unsupported `warden` subcommands - pasting secrets into Git, State Hub, workplans, logs, or chat --- ## 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/RMASTER-WP-NNNN-.md` **Archived location:** finished workplans may move to `workplans/archived/YYMMDD-RMASTER-WP-NNNN-.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:** ```yaml --- id: RMASTER-WP-NNNN type: workplan title: "..." domain: financials repo: railiance-master status: proposed | ready | active | blocked | backlog | finished | archived owner: codex topic_slug: ... created: "YYYY-MM-DD" updated: "YYYY-MM-DD" state_hub_workstream_id: "" # 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 id: RMASTER-WP-NNNN-T01 status: wait | todo | progress | done | cancel priority: high | medium | low state_hub_task_id: "" # written by fix-consistency — do not edit ``` Status progression: `todo` → `progress` → `done`; use `wait` for waiting or blocked work and `cancel` for stopped work. ### Repo-specific guidance Use `railiance-master` workplans for framework changes that span multiple Railiance repos, especially repository taxonomy changes, architecture boundary changes, and migrations introducing `rail-*`, `rapp-*`, or `reef-*` concepts. IDs use `RMASTER-WP-` so they do not collide with `RAILIANCE-WP-` in `railiance-platform` and other ownership repos. Do not use this repo to track implementation work that belongs entirely inside one concrete ownership repo such as `railiance-platform` or `railiance-apps`.