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 that reports catalog enablement separately from typed operational readiness; 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, invalid, or known-blocked 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: both local profiles are declared blocked and refused before creation; the underlying proof found consumer nsenter denied and no in-sandbox rein runtime
rein-aharness adapter	Implemented; local selection is blocked before creation, while the remote profile remains an explicitly labeled unverified proof path
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 means only that catalog policy permits selection. Typed operational readiness separately records ready, unverified, or blocked. Known-blocked profiles refuse before sandbox creation; unverified profiles may run only as labeled proof attempts, with the state preserved in evidence. There is currently no committed ready profile.

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.

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