rein-openweights/INTENT.md

# INTENT

> Why rein-openweights exists, its boundary, and what it must never
> become. Established by glas-harness
> `docs/adr/ADR-001-rein-harness-family.md`.

## Why it exists

Every current agent harness in the ecosystem (Claude Code, Grok CLI,
Codex/GPT CLI) is a frontier-model-vendor harness: it only drives that
vendor's own model. There is no way to run a current open-weight model
through an equivalent agentic tool-use loop (plan → tool call → observe →
repeat, with a bounded tool policy) without building one from scratch per
occasion.

rein-openweights exists to be that harness: one agentic loop, model
supplied via OpenRouter, usable anywhere a rein-aharness-equivalent
session is wanted but a frontier-vendor dependency is not —
cost-sensitive workloads, offline/degraded-network tolerance, or simply
comparing open-weight model capability against frontier baselines on
the same task.

## Governing principle

It is a **rein** — a concrete harness backend under glas-harness's
router, implementing the same harness contract as `rein-aharness`
(session lifecycle, tool dispatch + policy, sandbox consumption via
sand-boxer, State Hub reporting). It does not reimplement any of that
framework machinery itself; glas-harness owns the contract, this repo
owns the open-weight-model-specific agentic loop and tool execution.

## What it must never become

- **Not a model router.** Choosing which OpenRouter model to use for a
  given task, pricing, and fallback is a caller/config concern (`--model`),
  not logic this repo owns. `llm-connect` remains available as an
  optional dependency for future needs (structured-JSON side calls,
  diagnostics/replay) but is not load-bearing for the base agentic loop
  — see glas-harness ADR-002 and `src/rein_openweights/openrouter_client.py`.
- **Not a second harness framework.** Session semantics, tool policy
  schema, sandbox consumption, and audit reporting are glas-harness's
  contract (`GLAS-WP-0001-T01`) — this repo implements it, not forks it.
- **Not a sandbox provisioner.** Isolation comes from sand-boxer via
  glas-harness, the same as every other rein.
- **Not tenant-specific logic.** Anything specific to one consumer
  belongs in that consumer's configuration, not hardcoded here.

## Status

Minimal agentic loop implemented and unit-tested (26 tests, all mocked
at the network/subprocess boundary): tool surface, OpenRouter client,
credential acquisition, commit-verified success criterion, State Hub
reporting. See `workplans/REIN-OW-WP-0001-bootstrap.md`.

**Live-proven (2026-07-26):** run for real through glas-harness's
gateway (`glas_harness.reins.rein_openweights.ReinOpenWeights`) inside a
real `ext.bwrap` sandbox, against the real OpenRouter API
(`qwen/qwen-2.5-72b-instruct`) — a 2-turn tool-calling loop produced a
real, verified git commit. Credential reused the `OPENROUTER_API_KEY`
already present in the environment (the same one llm-connect resolves),
via this repo's own `credentials.py` env-var short-circuit — no OpenBao
round trip needed for this run.

The glas-harness adapter (`glas_harness/reins/rein_openweights.py`,
mirroring `reins/rein_aharness.py`) now exists and is what performed
this run.

**`GLAS-WP-0002-T02` closed (2026-07-27):** the OpenBao AppRole/vault
credential path (`credentials.py`'s `_acquire_token`/`bao kv get`
branch) is now live-verified, not just unit-tested against mocks.
`ops-mason` built the real infrastructure (AppRole `rein-openweights`,
policy, `reins/rein-openweights/openrouter` KV v2 path); the founder
completed provisioning; a real task ran with `OPENROUTER_API_KEY`
explicitly unset — real AppRole login, real KV v2 read, real OpenRouter
call, real commit. See `ops-mason/plans/rein-openweights-openrouter-approle.md`
for the full build record, including two real bugs (a KV v2 policy path
shape mistake, a missing admin-policy entry for the new mount) found and
fixed by actually running this end to end rather than stopping at mocks.