tegwick
c2a788aed9
Establishes glas-harness as the framework routing between concrete
harness backends ("reins"): rein-aharness (renamed from agent-harness)
and the newly chartered rein-openweights. GLAS-WP-0001 defines the
harness contract, rein registry, and a minimal gateway proving parity
against rein-aharness.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.7 KiB
| id | title | status |
|---|---|---|
| GLAS-WP-0001 | Harness router foundation: contract + first two reins | proposed |
Turn glas-harness from a charter into the actual harness router per
docs/adr/ADR-001-rein-harness-family.md. Define the contract concrete
harness backends ("reins") implement, register the first two
(rein-aharness, rein-openweights), and stand up a minimal gateway
that can run a session through either. No channel work, no memory/skills
layer yet — this workplan is the sand-boxer-extension-model equivalent
for harnesses: contract + registry + one working round trip.
Task: Define the harness contract
Specify the interface a rein implements: session start/resume/end, tool
dispatch + policy check, actor attribution (adm/agt/atm), sandbox
policy resolution (mode/scope/workspaceAccess) handed to sand-boxer, and
the audit envelope reported to State Hub. Mirror sand-boxer's
SandboxExtension ABC shape (provision/wait_ready/teardown) at the
harness level: something like start_session/dispatch_tool/
end_session. Document in docs/harness-contract.md.
id: GLAS-WP-0001-T01
status: todo
priority: high
Task: Rein registry
A named, versioned registry of reins (registry/reins/rein-aharness.yaml,
registry/reins/rein-openweights.yaml) analogous to sand-boxer's
extensions/ext.*.yaml — each entry declares its capabilities (e.g.
unattended/interactive, model-class: frontier|open-weight,
credential-source) and a handler reference. Extend
registry/indexes/capabilities.yaml with a capability.platform. glas-harness entry per the registry-first-reuse principle.
id: GLAS-WP-0001-T02
status: todo
priority: medium
Task: Harness profile catalog seed
First harness profile, harness.agent-dev, paired with sand-boxer's
profile.agent-dev (existing docs/integrations/glas-harness.md contract
in sand-boxer already assumes this pairing — verify it still matches).
Add a second profile, harness.agent-dev-local, paired with sand-boxer's
forthcoming profile.bwrap-local (SAND-WP-0013) once that lands, for
fast local iteration without an SSH hop.
id: GLAS-WP-0001-T03
status: todo
priority: medium
Task: Minimal CLI gateway — prove the contract against rein-aharness
Implement just enough of the harness contract to run one existing
rein-aharness run (task-file path) through glas-harness: resolve
harness.agent-dev, request a sandbox from sand-boxer, dispatch to
rein-aharness's adapter, verify commit, report to State Hub. This is the
parity proof gating any later "retire agent-harness as a standalone
concern" conversation — deliberately not attempted until this exists.
id: GLAS-WP-0001-T04
status: todo
priority: high
Task: Charter and bootstrap rein-openweights
Turn the ~/rein-openweights scaffold into a working minimal rein: an
agentic tool-use loop (plan → tool call → observe → repeat) driving an
open-weight model via llm-connect's OpenRouter path, implementing the
GLAS-WP-0001-T01 contract. Start with the same tool surface as
rein-aharness's green-commit-only profile (Read/Write/Edit/Glob/Grep +
local git) so it's directly comparable. Needs its own Forgejo remote
before anything is pushed — coordinate repo creation with the operator.
id: GLAS-WP-0001-T05
status: todo
priority: high
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.
id: GLAS-WP-0001-T06
status: todo
priority: medium