glas-harness/SCOPE.md

SCOPE

One-liner

glas-harness is a profile-driven control-plane library and CLI that resolves one governed execution request to a concrete rein/model/sandbox constellation, coordinates the outer lifecycle, and returns normalized evidence. It consumes sand-boxer; it does not provide a sandbox runtime itself.

Verified capabilities

The repository currently implements:

• strict Pydantic models for execution requests, profiles, rein descriptors, lifecycle results, and compact evidence (src/glas_harness/contract.py);
• deterministic, fail-closed profile and rein-registry resolution, including compatibility, duplicate, status, capability, and inline-secret checks (src/glas_harness/profiles.py);
• one bounded outer gateway lifecycle: resolve, create sandbox, derive the returned transport, start and dispatch one rein session, summarize, clean up, destroy the sandbox, and report normalized evidence (src/glas_harness/gateway.py);
• two CLI-backed rein adapters, for rein-aharness and rein-openweights;
• transport enforcement for SSH workspaces and same-host namespace descriptors. Unsupported, incomplete, ambiguous, unavailable, or unauthorized transports fail closed without falling back to the caller checkout;
• explicit governed actor validation (adm, agt, or atm) before sandbox creation, keeping queue worker_id values outside the actor field;
• one invocation channel: the local glas-harness run CLI;
• a packaged, versioned profile/rein catalog and glas-harness profiles validation command; and
• compact State Hub progress evidence that excludes prompts, model/tool output, provider bodies, and credentials.

The unit and boundary suite exercises these contracts and the Forgejo workflow installs the package, runs the suite, and validates the packaged catalog.

Operational capability status

Surface	Current verified status
Profile/catalog resolution	Implemented and CI-validated
Unknown or invalid profile refusal	Implemented before sandbox creation
Sandbox create/destroy lifecycle	Implemented; live failure paths prove teardown
Original-checkout isolation	Enforced by code: it is never a post-create execution fallback
SSH transport construction	Implemented and unit-tested; no current positive post-hardening live proof
Same-host bwrap execution	Fail-closed, not operational: consumer nsenter is denied and the rein runtime is absent inside the sandbox
rein-aharness adapter	Implemented; current local profile reaches sandbox creation and fails at session start on the bwrap owner boundary
rein-openweights adapter	Implemented; provider credential repair was proven, but current local sandbox execution has the same unresolved owner boundary
CLI channel	Implemented
State Hub evidence	Implemented as compact progress evidence, not a complete session/tool audit service

An enabled profile currently means that catalog policy permits selection. It does not prove that its rein executable, credential delivery, network egress, and sandbox transport are operational on a particular host. That semantics is an open governance gap tracked in GLAS-IN-0005.

In scope

• The versioned Glas execution contract and profile/rein catalogs.
• Exact profile selection and refusal; no implicit governed rein or model.
• Outer execution lifecycle and teardown coordination with sand-boxer.
• Reachability-derived command transport and workspace selection.
• Rein adapters that translate the stable outer contract to backend CLIs.
• Actor attribution and organizational reference propagation without assuming workforce authority.
• Direct-caller results and compact, value-safe execution evidence.
• Channel interfaces that translate invocations into the same execution request; only the CLI implementation exists today.

Out of scope

• Sandbox profiles, placement, provisioning, owner-mediated execution, and teardown implementation — sand-boxer.
• A rein's internal agent loop, provider client, tool enforcement, and credential acquisition — the selected rein.
• Scheduling, claiming, retries, and task sourcing — activity-core or another channel owner.
• Roles, duties, assignments, goals, resource envelopes, and authorization — their workforce/leadership systems.
• Model-provider authority and inference routing — providers and llm-connect.
• Secret storage or credential brokering.
• End-to-end validation and product code generation — wise-validator and snuggle-inventor.
• State Hub work-record authority.

Intended but not implemented

The broader vision in INTENT.md includes long-lived/resumable sessions, gateway-owned tool catalogs and policy checks, memory and skills services, additional chat/email/MCP channels, cron surfaces, bounded subagent delegation, and richer session/tool audit streams. None is a current repository capability. The present implementation is a bounded execution router over two reins, not yet Coulomb's general-purpose agent harness service.

Active gaps

• GLAS-WP-0005-T05 / GLAS-IN-0002: sand-boxer-owned executable bwrap reachability, rein runtime availability, explicit egress, and credential delivery are required for a positive in-sandbox rein proof.
• GLAS-IN-0003: grandfather the pre-canon GLAS-0001 identifiers.
• GLAS-IN-0004: align the documented ad hoc workplan convention with the identifier canon.
• GLAS-IN-0005: make profile enabled status and operational readiness truthful and testable.

Getting oriented

• Intent and gap assessment: INTENT.md, history/2026-08-23-scope-vs-intent-assessment.md
• Contract: docs/harness-contract.md, docs/execution-profiles.md
• Architecture: docs/adr/ADR-001-rein-harness-family.md
• Live work: workplans/, docs/intakes/residuals.md
• Agent workflow: AGENTS.md