glas-harness/SCOPE.md

# SCOPE

Assessed 2026-09-06 against source revision `5867842` and the recorded owner
proofs. Detailed comparison: [scope versus intent assessment](history/2026-09-06-102533-scope-vs-intent-assessment.md).

## Current product

`glas-harness` is a Python library and CLI for routing one execution request
through an explicit harness profile to a concrete rein. It coordinates sandbox
creation, one rein session, result collection and teardown. It consumes
sand-boxer for isolation and the selected rein for its agent loop.

It is not yet the general-purpose, persistent agent harness service described
by the maturity target in `INTENT.md`. No committed profile is `ready`.

## Implemented capabilities

- Contract version `1.0`: typed requests, profiles, rein descriptors, sessions,
  tool results and execution evidence. Unknown model fields are rejected.
- Packaged YAML profile and rein catalogs, with deterministic resolution,
  contract/status/capability checks, inline-secret screening and duplicate-key
  rejection, including nested mappings and merge collisions. An unversioned
  reference resolves only when unique; multiple versions require an exact pin.
- Independent catalog enablement and operational readiness. Unknown,
  incompatible, disabled, ambiguous and known-blocked selections refuse before
  sandbox creation. `unverified` permits a labeled proof attempt; it is not a
  successful readiness check.
- A synchronous outer lifecycle: resolve, create, start, dispatch `run_task`,
  summarize, clean up and destroy. Manager initialization failures return
  normalized creation-failure evidence. Cleanup and destruction are attempted
  after session failures; this is not a durable recovery/retry service.
- Two concrete CLI adapters: `ReinAharness` and `ReinOpenWeights`. Each session
  retains its own parsed outcome, model and usage even when an adapter is
  reused. The rein owns the inner tool loop and tool-policy enforcement.
- Same-host commands through `SandboxManager.execute`, preserving the exact
  create-time actor/project/run identity, profile credential references,
  bounded stdin and command timeout. No direct consumer `nsenter` or host
  checkout execution fallback. Remote commands use validated SSH reachability
  and the returned workspace.
- Private, exclusive task-file creation under sandbox Git metadata, followed by
  removal through the execution transport. Prompts travel over stdin rather
  than shell arguments.
- Governed actor types (`adm`, `agt`, `atm`) and opaque assignment, role, duty,
  goal and resource-envelope references. Attribution is not caller
  authentication or workforce authorization.
- One channel implementation, `CLIChannel`, exposed by `glas-harness run`;
  `glas-harness profiles` validates and lists the catalog. Python callers can
  use `run_execution` directly. No HTTP/MCP service is implemented.
- Direct-caller output/errors plus compact State Hub progress evidence.
  Ordinary execution failures are summarized for Hub reporting; raw tool
  output and event payloads are not included in that report. Reporting is
  best-effort HTTP, with no durable outbox, retry or delivery guarantee.
- Acceptance tooling for owner-boundary probes, runtime inventory and a real
  local-rein proof. The latter validates artifact content and a single commit
  before teardown; having the runner does not establish a passing real run.

Token/turn limits are passed to supporting rein adapters. Transport timeouts
bound individual commands; Glas does not implement aggregate wall-clock or
cross-session token accounting. Credential references are labels handed to the
owner, not credentials or an authorization grant. Secret screening is not a
universal redaction guarantee for arbitrary caller/provider data.

## Operational evidence and limits

| Surface | Evidence available | Current limit |
|---|---|---|
| Catalog and adapters | 110 tests passed at the latest code review; packaged catalog validation passed | Tests do not prove provider authentication or deployed runtime readiness |
| Same-host owner boundary | Non-secret live proof: source absent, mutation denied, sandbox-only commit, private task removal and workspace destruction | Deterministic dispatch, not a real model session |
| Standalone runtime and private state | Owner proof of rein CLI startup with pinned read-only Python runtime and private HOME/XDG/TMP state | Temporary proof artifact; pinned Claude executable and production selection still pending |
| Provider egress | Owner extension and persisted-manager proofs of provider TLS reachability, undeclared host/direct-IP denial and cleanup | Destination control, not HTTP-path or TLS-SNI filtering; not a complete real-rein proof |
| Credential transport | Owner synthetic-key proof of delivery, redaction, next-command absence, wrong-project denial and teardown | Real Anthropic lane inactive; custody metadata confirmation does not verify its value or provider authentication |
| Remote SSH | Construction, quoting and refusal tests | No positive post-hardening live execution proof |
| Tool visibility | Claude stream events parsed after subprocess completion when enabled; open-weight events unavailable | No live gateway event stream or complete cross-rein tool audit |

Runtime mounting, credential brokering and egress enforcement above are
**sand-boxer/credential-owner capabilities consumed by Glas**, not implementations
owned by this repository. Proof evidence is in [docs/evidence](docs/evidence/)
and the owner returns in [GLAS-WP-0012](workplans/GLAS-WP-0012-first-local-profile-production-proof.md).
Older provider successes from before transport hardening do not prove current
sandbox-contained execution.

## Committed profile readiness

| Profile | Rein | Readiness |
|---|---|---|
| `harness.agent-dev-local@1.0.0` | rein-aharness / Claude Code | `blocked` |
| `harness.agent-dev-openweights-local@1.0.0` | rein-openweights / OpenRouter | `blocked` |
| `harness.agent-dev@1.0.0` | rein-aharness / remote agent-dev | `unverified` |

The first local Claude acceptance is tracked by `GLAS-WP-0012`. Authorization
contract resolution and policy publication have progressed upstream, but real
owner verification, service deployment/identity, lane activation, runtime
pinning and combined acceptance remain gates. No readiness promotion follows
from those partial proofs.

## Ownership boundaries

Glas owns the execution contract, catalogs, outer lifecycle, adapters,
transport selection, channel translation and normalized evidence.

Other owners retain:

- Sandbox provisioning, placement, runtime environment, exec implementation,
  network enforcement and destruction: sand-boxer.
- Inner agent loop, provider client and tool enforcement: the selected rein;
  inference routing where applicable: llm-connect/provider owners.
- Secret custody and governed credential delivery: OpenBao, secrets-engine and
  the sandbox owner; identity/authorization: their owning services.
- Scheduling, worker allocation and work initiation: activity-core and
  workforce/leadership systems. Glas only carries their references.
- Work-record authority, tunnels, certificates and production hosting: their
  existing owners, not this library.
- Product validation workflows and code-generation pipelines: wise-validator
  and snuggle-inventor. Repository acceptance scripts test Glas integration;
  they do not replace those services.

## Intent gaps and live work

Long-lived/resumable sessions, memory/skills services, bounded subagent
spawn/join, additional channels, general tool-backend plugins, per-tool gateway
policy/elevation and durable session/tool audit remain unimplemented. They are
vision gaps, not implicitly approved workplans. The Channel and Rein interfaces
are an extension foundation, not a complete plugin platform.

Live operational work remains in `GLAS-WP-0012` and `GLAS-IN-0002`; the latter
also retains the independent open-weight acceptance requirement. Identifier
intakes `GLAS-IN-0003` and `GLAS-IN-0004` remain open in
[the residual register](docs/intakes/residuals.md); their historical statements
need owner reconciliation, not an assumption that every old warning still
occurs. The ad hoc ID-registration issue was encountered again in the latest
review and resolved for that task, not for the fleet convention.

See [INTENT.md](INTENT.md) for direction, the
[contract](docs/harness-contract.md) and
[profile documentation](docs/execution-profiles.md) for interfaces, and
[workplans](workplans/) for accepted work.