glas-harness/SCOPE.md

# SCOPE

## One-liner

`glas-harness` is a profile-driven control-plane library and CLI that resolves
one governed execution request to a concrete rein/model/sandbox constellation,
coordinates the outer lifecycle, and returns normalized evidence. It consumes
`sand-boxer`; it does not provide a sandbox runtime itself.

## Verified capabilities

The repository currently implements:

- strict Pydantic models for execution requests, profiles, rein descriptors,
  lifecycle results, and compact evidence (`src/glas_harness/contract.py`);
- deterministic, fail-closed profile and rein-registry resolution, including
  compatibility, duplicate, status, capability, and inline-secret checks
  (`src/glas_harness/profiles.py`);
- one bounded outer gateway lifecycle: resolve, create sandbox, derive the
  returned transport, start and dispatch one rein session, summarize, clean up,
  destroy the sandbox, and report normalized evidence
  (`src/glas_harness/gateway.py`);
- two CLI-backed rein adapters, for `rein-aharness` and `rein-openweights`;
- transport enforcement for SSH workspaces and same-host namespace descriptors.
  Unsupported, incomplete, ambiguous, unavailable, or unauthorized transports
  fail closed without falling back to the caller checkout;
- explicit governed actor validation (`adm`, `agt`, or `atm`) before sandbox
  creation, keeping queue `worker_id` values outside the actor field;
- one invocation channel: the local `glas-harness run` CLI;
- a packaged, versioned profile/rein catalog and `glas-harness profiles`
  validation command; and
- compact State Hub progress evidence that excludes prompts, model/tool output,
  provider bodies, and credentials.

The unit and boundary suite exercises these contracts and the Forgejo workflow
installs the package, runs the suite, and validates the packaged catalog.

## Operational capability status

| Surface | Current verified status |
|---|---|
| Profile/catalog resolution | Implemented and CI-validated |
| Unknown or invalid profile refusal | Implemented before sandbox creation |
| Sandbox create/destroy lifecycle | Implemented; live failure paths prove teardown |
| Original-checkout isolation | Enforced by code: it is never a post-create execution fallback |
| SSH transport construction | Implemented and unit-tested; no current positive post-hardening live proof |
| Same-host bwrap execution | Fail-closed, not operational: consumer `nsenter` is denied and the rein runtime is absent inside the sandbox |
| `rein-aharness` adapter | Implemented; current local profile reaches sandbox creation and fails at session start on the bwrap owner boundary |
| `rein-openweights` adapter | Implemented; provider credential repair was proven, but current local sandbox execution has the same unresolved owner boundary |
| CLI channel | Implemented |
| State Hub evidence | Implemented as compact progress evidence, not a complete session/tool audit service |

An `enabled` profile currently means that catalog policy permits selection. It
does not prove that its rein executable, credential delivery, network egress,
and sandbox transport are operational on a particular host. That semantics is
an open governance gap tracked in `GLAS-IN-0005`.

## In scope

- The versioned Glas execution contract and profile/rein catalogs.
- Exact profile selection and refusal; no implicit governed rein or model.
- Outer execution lifecycle and teardown coordination with sand-boxer.
- Reachability-derived command transport and workspace selection.
- Rein adapters that translate the stable outer contract to backend CLIs.
- Actor attribution and organizational reference propagation without assuming
  workforce authority.
- Direct-caller results and compact, value-safe execution evidence.
- Channel interfaces that translate invocations into the same execution
  request; only the CLI implementation exists today.

## Out of scope

- Sandbox profiles, placement, provisioning, owner-mediated execution, and
  teardown implementation — `sand-boxer`.
- A rein's internal agent loop, provider client, tool enforcement, and
  credential acquisition — the selected rein.
- Scheduling, claiming, retries, and task sourcing — `activity-core` or another
  channel owner.
- Roles, duties, assignments, goals, resource envelopes, and authorization —
  their workforce/leadership systems.
- Model-provider authority and inference routing — providers and `llm-connect`.
- Secret storage or credential brokering.
- End-to-end validation and product code generation — `wise-validator` and
  `snuggle-inventor`.
- State Hub work-record authority.

## Intended but not implemented

The broader vision in `INTENT.md` includes long-lived/resumable sessions,
gateway-owned tool catalogs and policy checks, memory and skills services,
additional chat/email/MCP channels, cron surfaces, bounded subagent delegation,
and richer session/tool audit streams. None is a current repository capability.
The present implementation is a bounded execution router over two reins, not
yet Coulomb's general-purpose agent harness service.

## Active gaps

- `GLAS-WP-0005-T05` / `GLAS-IN-0002`: sand-boxer-owned executable bwrap
  reachability, rein runtime availability, explicit egress, and credential
  delivery are required for a positive in-sandbox rein proof.
- `GLAS-IN-0003`: grandfather the pre-canon `GLAS-0001` identifiers.
- `GLAS-IN-0004`: align the documented ad hoc workplan convention with the
  identifier canon.
- `GLAS-IN-0005`: make profile `enabled` status and operational readiness
  truthful and testable.

## Getting oriented

- Intent and gap assessment: `INTENT.md`,
  `history/2026-08-23-scope-vs-intent-assessment.md`
- Contract: `docs/harness-contract.md`, `docs/execution-profiles.md`
- Architecture: `docs/adr/ADR-001-rein-harness-family.md`
- Live work: `workplans/`, `docs/intakes/residuals.md`
- Agent workflow: `AGENTS.md`