coulomb/glas-harness
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ADR-002: resolve credential brokering for rein-openweights (Option B)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 3s
Details

Browse source 
rein-openweights acquires its OpenRouter credential directly
(OpenBao/ops-warden), consistent with rein-aharness's existing
credential-holder principle — glas-harness does not broker
LLM-provider credentials. Confirmed llm-connect itself never brokers
credentials either (resolve_api_key() only reads an
already-materialized key from explicit/env/file), so routing through
llm-connect vs. a leaner wrapper doesn't change this. Composable reins
as middleware (monitoring/eval/optimization) is recorded as a separate,
deliberately deferred question in the same ADR — one candidate
capability isn't evidence of a recurring pattern yet.

GLAS-WP-0001-T06 done; T05 (bootstrap rein-openweights) unblocked.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-26 13:26:00 +02:00
parent eb5fd5d676
commit 139b76e9c1
4 changed files with 124 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

17
workplans/GLAS-WP-0001-harness-router-foundation.md
View file

@ -109,15 +109,20 @@ state_hub_task_id: "84fa62ae-3b34-42fd-a263-f65c35e87586"
## Task: Decide credential-brokering ownership for rein-openweights
Resolve the open question from ADR-001: does glas-harness broker the
OpenRouter/llm-connect credential the same way it will broker sand-boxer
sandbox handles, or does rein-openweights acquire it directly (OpenBao/
ops-warden) the way rein-aharness does today? Record as an ADR addendum
before T05 lands, not after.
Resolved in `docs/adr/ADR-002-credential-brokering-and-composable-reins.md`:
**Option B** — rein-openweights acquires its OpenRouter credential
directly (OpenBao/ops-warden), consistent with rein-aharness's own
credential-holder principle. glas-harness does not broker LLM-provider
credentials. Confirmed llm-connect itself never brokers credentials
either (`resolve_api_key()` only reads an already-materialized key) —
the earlier "does using llm-connect impose a credential model" concern
does not apply. A separate, deliberately deferred question (composable
reins as middleware for monitoring/eval/optimization) is recorded in the
same ADR as open, not blocking this task or T05.
```task
id: GLAS-WP-0001-T06
status: todo
status: done
priority: medium
state_hub_task_id: "b4e775d6-ad81-40a4-9fd0-974ba27182fd"
```