---
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
```