channels/base.py: GatewayInvocation dataclass + Channel ABC
(parse_invocation/render_result), mirroring Rein one layer up -- a
channel turns an external invocation into what run_task_through_rein
needs, and turns its result back into whatever the invocation medium
expects.
channels/cli_channel.py: CLIChannel, a pure refactor of what cli.py did
inline -- argparse Namespace -> GatewayInvocation, result dict ->
json.dumps(..., indent=2). cli.py's run handler is now a thin
construct-parse-invoke-render wrapper.
docs/channel-contract.md documents the pattern and sketches (without
building) a second channel.
Found and fixed a real bug while live-testing this refactor:
ReinAharness's default cli_bin was still "agent-harness", stale from
before HARNESS-WP-0002-T02's rename.
4 new tests (27/27 passing), plus a real live run through
python3 -m glas_harness.cli against rein-aharness/real Claude Code
confirming identical output shape and a real commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Closes HARNESS-WP-0002-T04. With rein-openweights now real (not
hypothetical), the two reins already sit at opposite ends of this
question with no code change needed -- rein-aharness keeps its
kaizen-agentic + issue-core coupling, rein-openweights has none at all.
glas-harness does not become a task source or scheduler, consistent
with its own INTENT.md boundary.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
start_session/dispatch_tool/end_session, mirroring sand-boxer's
SandboxExtension ABC one layer up: sand-boxer establishes where work
runs, this contract governs how an agent session runs on top of it.
Unblocks the rein-aharness parity proof (T04) and rein-openweights
bootstrap (T05).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
