glas-harness/docs/adr/ADR-002-credential-brokering-and-composable-reins.md

# ADR-002: Credential brokering for rein-openweights; composable reins deferred

- Status: accepted (part 1), open (part 2)
- Date: 2026-07-26
- Deciders: Bernd Worsch

## Context

`GLAS-WP-0001-T06` asked who acquires the OpenRouter credential
`rein-openweights` needs: glas-harness (mirroring how it brokers sand-boxer
sandbox handles) or the rein itself (mirroring how `rein-aharness` already
holds its own OpenBao AppRole lane for IMAP/mail credentials).

Discussion surfaced a prior question: should `rein-openweights` talk to
OpenRouter through `llm-connect`, or through a leaner, independent wrapper
that both `llm-connect` and `rein-openweights` depend on — keeping
`llm-connect`'s monitoring/evaluation/optimization features optional
rather than bundled in?

Checking `llm-connect` directly resolved that half cleanly:

- Its own `ARCHITECTURE-LAYERS.md` already separates Core (frozen adapter
  ABC + models) from Functional (independently shippable per-provider
  adapters, diagnostics, replay, budget tracking — all explicitly
  optional: *"Keeps base install lightweight... optional dep, not
  runtime dep"*) from Configuration (TOML resolution, key lookup).
- `resolve_api_key()` (`llm_connect/config.py`) only reads an
  **already-materialized** key — explicit argument → env var → file. It
  never talks to OpenBao/ops-warden. `llm-connect/INTENT.md` states this
  as an explicit boundary: *"not intended to... manage secrets,
  credentials, or organizational access policies."*

So `llm-connect` was never a credential broker regardless of which
adapter path `rein-openweights` uses — the earlier concern that "using
llm-connect" imports a credential model doesn't hold. `rein-openweights`
can depend on just Core + the `OpenRouterAdapter` Functional module and
skip diagnostics/replay/budget, the same way any other consumer can
today.

## Decision (part 1 — resolved)

**Option B: `rein-openweights` acquires its OpenRouter credential
directly** (OpenBao/ops-warden), the same way `rein-aharness` already
does for its own credentials. glas-harness does not broker LLM-provider
credentials.

Rationale, in order of weight:

1. Consistency with the existing family precedent. `rein-aharness`'s own
   INTENT.md states *"the harness is the only credential holder and only
   policy enforcement point."* Having glas-harness broker for one rein
   but not the other bakes an inconsistency into the family from its
   second member.
2. Scope discipline. glas-harness has zero live end-to-end proof yet
   (`GLAS-WP-0001-T04` is a unit-tested wiring, not a live run) — growing
   it into a secrets broker ahead of validated need repeats the
   premature-generalization mistake ADR-001 was written to avoid on the
   sandbox side.
3. Credential lifecycle doesn't map cleanly onto sand-boxer's
   create/destroy session lifecycle the way a sandbox handle does — the
   analogy that made Option A attractive was weaker than it first looked.

Accepted cost: `rein-openweights` duplicates OpenBao wiring rather than
inheriting it from glas-harness. Revisit centralizing it if a third rein
repeats the same need — decide from evidence, not in advance.

## Consequences (part 1)

- `rein-openweights` (`REIN-OW-WP-0001-T04`) implements its own
  credential acquisition; it does not wait on or call into glas-harness
  for this.
- `rein-openweights` depends on `llm-connect`'s Core + `OpenRouterAdapter`
  only — not the full package surface — confirmed against the actual
  layer boundaries above, not assumed.
- `GLAS-WP-0001-T06` is done. `GLAS-WP-0001-T05` (bootstrap
  `rein-openweights`) is unblocked.

## Part 2 — open, deferred: composable reins as middleware

Separately, the idea surfaced that monitoring/evaluation/optimization
(capabilities `llm-connect` already stages as optional Functional
modules) could eventually become their own **composable reins** —
cross-cutting capabilities that wrap or observe another rein's
`dispatch_tool` calls, rather than each being a complete alternative
harness backend the way `rein-aharness`/`rein-openweights` are.

This is a real extension to `docs/harness-contract.md`: the current
`Rein` ABC assumes one rein *is* the whole session, with no
wrapping/composition concept (no middleware chain, no way for a
"monitoring rein" to sit between glas-harness and the base rein's calls).

**Left open deliberately** — it does not block `rein-openweights`
bootstrap and there is only one candidate capability (llm-connect's
existing optional modules) to generalize from, not evidence of a
recurring pattern. Revisit if/when a second capability
(evaluation, or a distinct optimization concern) wants the same
treatment. If pursued, it would need:

- A `Middleware`/`ReinWrapper` concept distinct from `Rein` in
  `contract.py`, with an explicit chain-of-responsibility around
  `dispatch_tool`.
- A decision on whether `llm-connect` itself gets decomposed into
  reins/middleware, or stays a shared library that both base reins and
  middleware reins happen to depend on (the leaner option, and the one
  consistent with `llm-connect`'s own INTENT.md boundary against owning
  application-level workflow).