From 53165d2a50d5bcbd54c442ec64f7e2ea03832d28 Mon Sep 17 00:00:00 2001 From: tegwick Date: Tue, 11 Aug 2026 22:54:30 +0200 Subject: [PATCH] Place telemetry on the Quality dimension as Q2 Observability The placement question seeded as open is answered by canon rather than by a new decision. OAS section 8 defines Q2 Observability as 'telemetry and monitoring: metrics, logs, traces' - this repo in canon's own words. The 2026-08-11 coherence review found Railiance had been modelling itself on one of OAS's six required dimensions and treating everything else as unplaced. Observability was never homeless; the dimension it belongs to was not in use. Notes Q7 Governance as the sibling concern - the conformance loop, the other half of the self-evidencing aspiration this repo serves. Co-Authored-By: Claude Opus 5 --- .gitignore | 5 + AGENTS.md | 199 ++++++++++++++++++ INTENT.md | 27 ++- SCOPE.md | 5 +- WORK-RECORDS.md | 14 ++ .../RAILIANCE-WP-0001-statehub-bootstrap.md | 59 ++++++ 6 files changed, 297 insertions(+), 12 deletions(-) create mode 100644 .gitignore create mode 100644 AGENTS.md create mode 100644 WORK-RECORDS.md create mode 100644 workplans/RAILIANCE-WP-0001-statehub-bootstrap.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e4e0199 --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +# state-hub: track .claude/rules +# Claude Code local state (track shared rules; ignore machine-specific files) +.claude/* +!.claude/rules/ +!.claude/rules/*.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..ff00222 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,199 @@ +# railiance-telemetry — Agent Instructions + +## Repo Identity + +**Purpose:** Observability for Railiance — monitoring, metrics, logs, traces, and alerting that turn running behaviour into evidence and give the self-organizing control loop a signal to close on. + +**Domain:** financials +**Repo slug:** railiance-telemetry +**Topic ID:** `ca369340-a64e-442e-98f1-a4fa7dc74a38` +**Workplan prefix:** `RAILIANCE-WP-` + +--- + +## State Hub Integration + +The Custodian State Hub tracks work across all domains. Codex uses HTTP REST and +the `statehub` CLI by default. MCP is opt-in because the current Codex MCP bridge +adds severe call latency; the full administrative MCP surface remains available +to clients that need it. + +| Context | URL | +|---------|-----| +| Local workstation | `http://127.0.0.1:8000` | +| Remote via tunnel | `http://127.0.0.1:18000` | +| 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/replay after connectivity returns. + +Codex workspace-write sandboxes need network access enabled to reach the host's +loopback listener. Bootstrap this once with `make -C ~/state-hub configure-codex` +and restart Codex. The canonical REST health endpoint is `/state/health`, not +`/health`. If a sandboxed loopback probe fails, retry it with escalated execution +before declaring State Hub unavailable; a managed Codex permission profile may +still enforce isolated networking. Experimental MCP can be enabled explicitly +with `make -C ~/state-hub configure-codex WITH_MCP=1`. + +### Orient at session start + +```bash +# Offline brief — works without hub connection +cat .custodian-brief.md + +# Active workplans for this domain +curl -s "http://127.0.0.1:8000/workplans/?topic_id=ca369340-a64e-442e-98f1-a4fa7dc74a38&status=active" \ + | python3 -m json.tool + +# Check inbox +curl -s "http://127.0.0.1:8000/messages/?to_agent=railiance-telemetry&unread_only=true" \ + | python3 -m json.tool +``` + +Mark a message read: +```bash +curl -s -X PATCH "http://127.0.0.1:8000/messages//read" \ + -H "Content-Type: application/json" -d '{}' +``` + +### Log progress (required at session close) + +```bash +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", + "workplan_id": "", + "task_id": "" + }' +``` + +Omit `workplan_id` / `task_id` when not applicable. + +### Update task status + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"status": "progress"}' +# values: wait | todo | progress | done | cancel +``` + +### Flag a task for human review + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"needs_human": true, "intervention_note": "reason"}' +``` + +--- + +## Session Protocol + +**Start:** +1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) +2. Check inbox: `GET /messages/?to_agent=railiance-telemetry&unread_only=true`; mark read +3. Scan workplans: `ls 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 + (intake with `origin: residual` + `origin_ref: `, or a next workplan / + decision / engagement). Do not park leftovers only in prose or `SCOPE.md`. + Canon: `the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals. +3. Log: `POST /progress/` with a summary of what changed (name handoff ids) +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_ROUTING} + + + + +--- + +## 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/RAILIANCE-WP-NNNN-.md` + +**Archived location:** finished workplans may move to +`workplans/archived/YYMMDD-RAILIANCE-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: RAILIANCE-WP-NNNN +type: workplan +title: "..." +domain: financials +repo: railiance-telemetry +status: proposed | ready | active | blocked | backlog | finished | archived +owner: codex +topic_slug: ... +created: "YYYY-MM-DD" +updated: "YYYY-MM-DD" +state_hub_workstream_id: "" # fix-consistency — do not edit (legacy field name; workplan UUID) +--- +``` + +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. + +**Terminology:** workplan is the fleet term; `workstream` appears only in legacy +API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see +`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`. + +**Task block format** (one per `##` section): + +``` +## Task Title + +` ` `task +id: RAILIANCE-WP-NNNN-T01 +status: wait | todo | progress | done | cancel +priority: high | medium | low +state_hub_task_id: "" # written by fix-consistency — do not edit +` ` ` + +Task description text. +``` + +Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work. + +**Residuals when finishing:** actionable leftovers become live work records +before `status: finished` — usually an intake (`origin: residual`, +`origin_ref: RAILIANCE-WP-NNNN`) or a spawned workplan. Residual is a *role*, +not a kind. Fleet list lives on State Hub, not in `SCOPE.md`. + +To create a new workplan: +1. Write the file following the format above +2. Run `statehub fix-consistency` locally; ask the operator only if the CLI or + State Hub API is unavailable. diff --git a/INTENT.md b/INTENT.md index a9d0ca1..e565f9c 100644 --- a/INTENT.md +++ b/INTENT.md @@ -125,19 +125,26 @@ of it: --- -## Open Placement Question +## Placement: Quality dimension, Q2 Observability -Railiance's stack dimension defines five levels (S1–S5). Observability is -cross-cutting: it draws signal from every level and is consumed by all of them. +This repo is **not** a stack level and not an exception to the stack model. It +is a concern on the **Quality dimension**, sub-level **Q2 Observability**, whose +canon definition (`canon/standards/orthogonal-architecture_v1.0.md` §8) is: -Whether this repo is best modelled as an S3 platform capability (it runs -stateful services and is consumed by others), or as a concern on the Quality -dimension rather than the Stack dimension, is **not settled here**. It is a -decision for `railiance-master`, which owns the taxonomy. +> *Telemetry and monitoring. Examples: metrics, logs, traces.* -This is stated explicitly because leaving placement undeclared is exactly how -`railiance-forge` ended up outside the stack model without anyone deciding it -should be. +That is this repo, in canon's own words. + +The question was originally raised as open — S3 platform capability, or Quality +concern? — and answered by the 2026-08-11 coherence review, which found that +Railiance had been modelling itself on one of OAS's six required dimensions and +treating everything else as unplaced. Observability was never homeless; the +dimension it belongs to was simply not in use. + +Ratification sits with `railiance-master`, which owns the taxonomy. Related: +the conformance loop is **Q7 Governance and Change Management** — a sibling +concern on the same dimension, and the other half of the self-evidencing +aspiration this repo exists to serve. --- diff --git a/SCOPE.md b/SCOPE.md index ee4f439..86f9a19 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -70,8 +70,9 @@ output. - Status: **seeded** — `INTENT.md` written 2026-08-11, no implementation yet - The live cluster has no monitoring namespace; this is greenfield -- Open: stack-dimension placement is undecided (see `INTENT.md`, "Open - Placement Question") and belongs to `railiance-master` +- Placement: **Quality dimension, Q2 Observability** — canon defines Q2 as + "telemetry and monitoring: metrics, logs, traces". Ratification sits with + `railiance-master`; the question is answered, not open --- diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md new file mode 100644 index 0000000..91ac9be --- /dev/null +++ b/WORK-RECORDS.md @@ -0,0 +1,14 @@ +# Work Records — railiance-telemetry + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | RAILIANCE-WP-0001 | ready | — | workplans/RAILIANCE-WP-0001-statehub-bootstrap.md | +| task | RAILIANCE-WP-0001-T01 | todo | — | workplans/RAILIANCE-WP-0001-statehub-bootstrap.md | +| task | RAILIANCE-WP-0001-T02 | todo | — | workplans/RAILIANCE-WP-0001-statehub-bootstrap.md | +| task | RAILIANCE-WP-0001-T03 | todo | — | workplans/RAILIANCE-WP-0001-statehub-bootstrap.md | diff --git a/workplans/RAILIANCE-WP-0001-statehub-bootstrap.md b/workplans/RAILIANCE-WP-0001-statehub-bootstrap.md new file mode 100644 index 0000000..b1d41ab --- /dev/null +++ b/workplans/RAILIANCE-WP-0001-statehub-bootstrap.md @@ -0,0 +1,59 @@ +--- +id: RAILIANCE-WP-0001 +type: workplan +title: "Bootstrap State Hub integration" +domain: financials +repo: railiance-telemetry +status: ready +owner: codex +topic_slug: railiance +created: "2026-08-11" +updated: "2026-08-11" +state_hub_workstream_id: "60f5fe7c-9749-40be-9945-6ad608398b3f" +--- + +# Bootstrap State Hub integration + +Observability for Railiance — monitoring, metrics, logs, traces, and alerting that turn running behaviour into evidence and give the self-organizing control loop a signal to close on. + +## Review Generated Integration Files + +```task +id: RAILIANCE-WP-0001-T01 +status: todo +priority: high +state_hub_task_id: "de712c57-79fa-49be-97a2-873e9e1a8bec" +``` + +Review `INTENT.md`, `SCOPE.md`, `AGENTS.md`, and `.custodian-brief.md`. +Replace generated placeholders with repo-specific facts where needed. + +## Verify Local Developer Workflow + +```task +id: RAILIANCE-WP-0001-T02 +status: todo +priority: high +state_hub_task_id: "79febfbb-6a67-40e0-9c24-96ff83ab706e" +``` + +Identify the repo's install, test, lint, build, and run commands. Add or refine +those commands in the agent instructions so future coding sessions can verify +changes confidently. + +## Seed First Real Workplan + +```task +id: RAILIANCE-WP-0001-T03 +status: todo +priority: medium +state_hub_task_id: "adea3657-c074-443b-9c5e-3c2095dd7c5b" +``` + +Create the first implementation workplan for the repository's most important +next change. After workplan file updates, run the sync locally from this repo +checkout: + +```bash +statehub fix-consistency +```