ADR-004: composable reins as middleware stays deferred (GLAS-WP-0002-T01)

Checked ADR-002 part 2's deferred question against the two observability
additions that landed since (rein-aharness's tool-event stream,
glas-harness's own gateway hub event) -- both turned out simpler as
direct implementations, neither needed a wrapping middleware layer.
Still zero real candidates for that shape. docs/harness-contract.md
gains the Middleware ABC as a documented, unimplemented sketch for if a
real third case ever appears -- no code written now.

Also flagged GLAS-WP-0002-T02 (live OpenBao verification) as blocked:
`bao token lookup` from this workstation returns 403, no usable vault
session to provision a new AppRole with. Needs the operator.

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

docs/harness-contract.md

@@ -74,13 +74,51 @@ Every `dispatch_tool` call and lifecycle transition carries an actor
 glas-harness stamps this at dispatch time; reins do not need their own
 actor model.
 
+## Composable reins as middleware (deferred — sketch only, no code)
+
+`docs/adr/ADR-002-credential-brokering-and-composable-reins.md` part 2
+raised whether monitoring/evaluation/optimization should 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. Resolved
+in `docs/adr/ADR-004-composable-reins-stay-deferred.md`: **still
+deferred, sketch recorded, no code written.** The two observability
+additions since (rein-aharness's per-tool-call audit stream,
+`glas-harness`'s own gateway hub event) both turned out to be simpler as
+direct implementations — neither needed a separate wrapping rein — so
+there still isn't a second real capability wanting this shape, only the
+original one (llm-connect's optional Functional-layer modules,
+untouched).
+
+If a real second candidate appears, the shape would be:
+
+```python
+class Middleware(ABC):
+    """Wraps another Rein's dispatch_tool, does not replace start_session/end_session."""
+
+    def __init__(self, inner: Rein) -> None:
+        self.inner = inner
+
+    @abstractmethod
+    def dispatch_tool(self, session: dict[str, str], tool_call: ToolCall) -> ToolResult:
+        """Call self.inner.dispatch_tool(...), observe/transform, return the result."""
+
+    def start_session(self, profile, inputs, sandbox) -> dict[str, str]:
+        return self.inner.start_session(profile, inputs, sandbox)
+
+    def end_session(self, session) -> dict[str, str]:
+        return self.inner.end_session(session)
+```
+
+A chain of `Middleware` wrapping a base `Rein` still satisfies the `Rein`
+ABC itself (composition, not a parallel type), so glas-harness's gateway
+would not need to change to consume one — this is deliberately *not* a
+speculative gateway-side change, just a documented shape to reach for
+if/when a second candidate shows up.
+
 ## Open questions this contract does not resolve yet
 
-- Whether `start_session` also carries scheduling/blueprint-sourcing
-  parameters (kaizen-agentic blueprint id, activity-core task id) as part
-  of `inputs`, or whether that stays entirely rein-side — tracked in
-  `rein-aharness/workplans/HARNESS-WP-0002-T04`.
-- The exact `SandboxHandle`/`ToolCall`/`ToolResult` field shapes — sketched
-  here at the level needed to unblock `GLAS-WP-0001-T04` (the
-  rein-aharness parity proof); refine once that task is underway rather
-  than speculatively now.
+- The exact `SandboxHandle`/`ToolCall`/`ToolResult` field shapes — these
+  have stabilized in practice (both reins implement them identically)
+  but are not yet declared frozen/versioned the way sand-boxer's models
+  are.