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

id	title	status
GLAS-WP-0002	Observability and composability follow-ups	proposed

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.

id: GLAS-WP-0002-T01
status: todo
priority: medium

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.

id: GLAS-WP-0002-T02
status: todo
priority: medium

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.

id: GLAS-WP-0002-T03
status: todo
priority: high

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.

id: GLAS-WP-0002-T04
status: todo
priority: low