# 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, 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 | 121 tests passed after GLAS-WP-0013; 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. 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.