glas-harness/SCOPE.md

SCOPE

Assessed 2026-09-06 against source revision 5867842 and the recorded owner proofs. Detailed comparison: scope versus intent assessment.

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 and the owner returns in GLAS-WP-0012. 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; 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 for direction, the contract and profile documentation for interfaces, and workplans for accepted work.