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.

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 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-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 workload-only credential transport change is integrated at 7357115: credential-free housekeeping and explicit rein workloads use separate paths; SSH credential routes refuse without an owner delivery contract. This source integration does not promote profile readiness.

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; 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.

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 for schema compatibility and acknowledgement semantics. The timestamped intent assessment remains a historical baseline; broader audit, aggregate budgets and session features are still gaps.

Latest runtime installation evidence — 2026-10-19 review

Custodian's docs/changes/netkingdom-target-2026-10-17/native-runtime-install-r3/execution-receipt.json supersedes the older not-installed runtime narrative: complete artifact f59959b605a51abd2901becde14e7abd852c2bd3f848004b51d250d1cb81af6d is installed on Railiance and its offline rein/Glas/Claude startup is verified. Full digest matched after rehearsal, durable receipt preceded cleanup, and process quiescence was verified. The failed revision-2 rehearsal remains historical evidence. This revision-3 receipt has zero model calls and no credential or owner-configuration reads; it does not prove active credentials, profile readiness or isolation of the actual Custodian interactive assignment.