glas-harness/SCOPE.md

# SCOPE

Catalog and dependency evidence refreshed 2026-10-19. The original source
assessment is retained as a historical baseline. 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. Non-READY owner handoffs refuse
  before rein startup, and reachability preparation errors retain their stage. Cleanup and destruction are attempted
  after session failures, with independent cleanup/destruction outcomes even
  when an earlier execution error remains primary. 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; direct results now distinguish accepted, failed and disabled
  reporting. There is 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 | 129 tests passed after GLAS-WP-0014; 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 | Pinned Claude/rein startup and protected local artifact proofs; later owner runtime and isolated integration preparation recorded in GLAS-WP-0012 | Startup and isolated fixture proofs do not establish acceptance of the actual interactive Custodian assignment |
| 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 | Synthetic delivery/redaction/teardown proofs; GLAS-WP-0012 records September 27 native lane activation and revocation | Historical lane activation is not current authorization or a passing combined interactive run |
| 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-local@1.1.0` | rein-aharness / Claude Code | `blocked` |
| `harness.agent-dev-local@1.1.1` | rein-aharness / Claude Code | `unverified` |
| `harness.fi-research-brief@1.0.0` | rein-aharness / Claude Code | `unverified` |
| `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
and runtime owner evidence has progressed upstream; consult the dated returns
in that workplan instead of inferring missing implementation from the old
September baseline. Exact owner admission, active native approvals and combined
acceptance remain gates. The FI profile has sandbox and tool profiles, with its
remaining acceptance in `GLAS-WP-0016-T04`. No readiness promotion follows
from those partial proofs. The October 16 workload-only credential transport
change is a prepared Custodian bundle, not canonical Glas capability.

## 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 snuggles-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.

GLAS-WP-0013 closed the independent cleanup/reporting-outcome gap on 2026-09-06.
Old evidence without the new fields remains explicitly unknown. See
[the contract update](docs/harness-contract.md) for schema compatibility and
acknowledgement semantics. The timestamped intent assessment remains a
historical baseline; broader audit, aggregate budgets and session features are
still gaps.