glas-harness/workplans/GLAS-WP-0002-observability-and-composability-followups.md

---
id: GLAS-WP-0002
type: workplan
title: "Observability and composability follow-ups"
status: finished
state_hub_workstream_id: "ec0777ff-18ce-4666-abaf-5bd2ff0fd4b9"
---

Four items surfaced as open-but-not-urgent while closing out
`GLAS-WP-0001`/`HARNESS-WP-0002`/`SAND-WP-0013`/`REIN-OW-WP-0001` — none
blocking, all worth doing. Bundled into one workplan since three of the
four are glas-harness-scoped and the fourth needs glas-harness
coordination either way.

## Task: Design composable reins as middleware

Resolve ADR-002 part 2 (deliberately deferred): should
monitoring/evaluation/optimization become their own composable reins —
middleware that wraps or observes a base rein's `dispatch_tool` calls —
rather than each being a complete alternative harness backend the way
`rein-aharness`/`rein-openweights` are? At the time of ADR-002 there was
only one candidate capability (llm-connect's optional Functional-layer
modules) to generalize from; that's still true today, so this task is a
**design decision first, implementation only if it clearly pays for
itself** — don't build a `Middleware`/`ReinWrapper` abstraction on
spec.

Concretely: draft the `Middleware` shape in `docs/harness-contract.md`
(a chain-of-responsibility around `dispatch_tool`, distinct from `Rein`),
record the decision as an ADR addendum, and only write code if a real
middleware candidate (e.g. a monitoring rein) is scoped alongside it in
this same task — not before.

**Done (2026-07-26), stays deferred.** `docs/adr/ADR-004-composable-reins-stay-deferred.md`
checked this against the two observability additions that landed since
ADR-002 (rein-aharness's tool-event stream, glas-harness's own gateway
hub event, both `HARNESS-WP-0002-T03`/`GLAS-WP-0002-T03`) — both turned
out simpler as direct implementations, neither needed a wrapping
middleware layer. Still zero real candidates for *this* shape, so no
code written. `docs/harness-contract.md` now carries the `Middleware`
ABC sketch for future reference, explicitly marked don't-build-yet.

```task
id: GLAS-WP-0002-T01
status: done
priority: medium
state_hub_task_id: "2de6074e-b72b-4eb7-b454-6b849011348c"
```

## Task: Live-verify rein-openweights's OpenBao credential path

The live proof in `REIN-OW-WP-0001` used the `OPENROUTER_API_KEY`
env-var short-circuit in `rein_openweights/credentials.py` — the
AppRole/vault path (`_acquire_token`, `resolve_openrouter_api_key`'s
`bao kv get` branch) is only unit-tested against mocked `bao` calls,
never exercised against a real OpenBao instance. Set up a real (or
realistic sandboxed) OpenBao AppRole for `rein-openweights` — mirroring
`rein-aharness`'s existing `binky-mail` AppRole pattern — and run one
live task through it with `OPENROUTER_API_KEY` unset, confirming the
vault round trip actually works end to end. Coordinate with
`rein-openweights` directly; this task's outcome should be recorded in
both repos.

**Done (2026-07-27).** The blocker got its own builder: `ops-mason`
(chartered specifically for this class of problem — see its `INTENT.md`)
ran the full construction-plan → review → executive-summary → approval →
build pipeline for real (`ops-mason/plans/rein-openweights-openrouter-approle.md`),
against real OpenBao (founder logged in via `bao login -method=oidc
-path=netkingdom role=platform-admin`, after the bare `-method=oidc`
default 403'd against the wrong mount path).

Real infrastructure now live: `reins/` KV v2 mount, policy
`workload-kv-read-rein-openweights-openrouter`, AppRole
`rein-openweights`, role_id/secret_id delivered to
`~/.local/rein-openweights/approle/`. Founder completed
`paste_once_provision` through ops-warden's desk. Catalog entry
`rein-openweights-openrouter-approle` is `active` in `ops-warden`.

**Live verification, for real:** ran a task through `rein-openweights`
with `OPENROUTER_API_KEY` explicitly unset and
`REIN_OPENWEIGHTS_APPROLE_DIR` pointed at the delivered credential —
real AppRole login, real KV v2 read, real OpenRouter API call, real
2-turn tool-calling loop, real commit
(`e30d520c79a3493aeea5e8ea4d5ec331512b781d`). The vault round trip is
what ran, not the env-var short-circuit.

Two real bugs surfaced and were fixed at the root cause along the way
(not this repo's code — `ops-mason`'s and `ops-warden`'s): a KV v2
policy path shape bug (`ops_mason/executor.py::_policy_hcl` was writing
the bare KV-v1-shaped path, which silently denies everything on a v2
mount) and a missing `platform-admin` policy entry for the brand-new
`reins/` mount. Full account in `ops-mason`'s plan file section 7.

```task
id: GLAS-WP-0002-T02
status: done
priority: medium
state_hub_task_id: "74b4f35b-9cdd-4228-aeed-e0eec458c0bf"
```

## Task: Wire glas-harness's own State Hub reporting from the gateway

Both live runs so far passed `--no-hub` through to the rein's own CLI —
each rein reports its own events, but `run_task_through_rein` itself
never posts a session-level event under glas-harness's own actor
attribution. Add a State Hub progress event (and, where meaningful, a
token event) emitted by `gateway.py` around sandbox create/destroy and
rein dispatch, distinct from whatever the rein itself reports — this is
what makes the *gateway's* audit trail exist independent of which rein
ran, matching the "observable by default" design principle in
`INTENT.md`.

**Done (2026-07-26).** `src/glas_harness/hub.py` (mirrors the two
reins' hub.py under `author: agt-glas-harness`); `gateway.py`'s
`run_task_through_rein` gains `report_to_hub: bool = True`, posting one
`gateway_run` progress event from a `finally` block — fires on both
success and failure (a raised exception still leaves an audit trail),
with `ok`/`rein`/`sandbox_id`/`sandbox_profile`/`project`/`result`/
`error` in the detail. `cli.py` gained a matching `--no-hub` flag. Live
verified: ran a real task through `ReinOpenWeights` with hub reporting
enabled, confirmed the `gateway_run` event landed in State Hub with the
correct detail (`author: agt-glas-harness`, real commit sha in
`result`). Token events skipped for now — `ToolResult` doesn't carry a
uniform token count across reins, and it wasn't worth forcing one just
for this task. 4 new tests (success/failure/disabled paths), 23/23
passing.

```task
id: GLAS-WP-0002-T03
status: done
priority: high
state_hub_task_id: "76462175-4a85-4552-a6c1-af871cc1b8d3"
```

## Task: First slice of glas-harness's remaining charter pillars

`INTENT.md` describes four pillars: (1) unified harness API, (2) profile
catalog, (3) extension platform (channels, memory/skills), (4)
observability/governance. Only slices of (1), (2), and (4) exist today
(contract, two harness profiles, the per-tool audit stream). Channels
and memory/skills are entirely unbuilt. This task is **not** "build all
of it" — it's picking and scoping the smallest real slice worth doing
next (most likely candidate: a CLI channel extension, since one already
exists implicitly via `glas_harness.cli`; formalizing it as the first
of possibly several channel extensions clarifies the channel contract
before a second channel is attempted). Produce a scoped follow-up
workplan (`GLAS-WP-0003` or later) rather than expanding this task
indefinitely.

**Done (2026-07-26).** Scoped as
`workplans/GLAS-WP-0003-first-channel-extension.md`: formalize the CLI
as the first `Channel` extension (contract + refactor + tests +
second-channel documentation), explicitly not building a second channel
now — same discipline as ADR-002/ADR-004.

```task
id: GLAS-WP-0002-T04
status: done
priority: low
state_hub_task_id: "98d4be61-5923-4445-b1f8-5135ada13ad9"
```