Add GLAS-WP-0002: observability and composability follow-ups

Bundles the four items surfaced while closing out GLAS-WP-0001/
HARNESS-WP-0002/SAND-WP-0013/REIN-OW-WP-0001: composable-reins-as-
middleware design (ADR-002 part 2), live-verifying rein-openweights'
OpenBao path, wiring the gateway's own State Hub reporting, and scoping
a first slice of glas-harness's remaining charter pillars. None were
blocking; all are worth doing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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

@@ -0,0 +1,95 @@
+---
+id: GLAS-WP-0002
+title: "Observability and composability follow-ups"
+status: 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.
+
+```task
+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.
+
+```task
+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`.
+
+```task
+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.
+
+```task
+id: GLAS-WP-0002-T04
+status: todo
+priority: low
+```