glas-harness/history/2026-08-23-scope-vs-intent-assessment.md

Scope versus intent assessment — 2026-08-23

Purpose

This assessment compares the verified repository behavior on 2026-08-23 with the target described by INTENT.md. It records capability, not aspiration. Catalog validation, old host-side success, or successful sandbox lifecycle are not treated as proof that a rein executed inside its selected sandbox.

Evidence reviewed:

• contract, gateway, channel, transport, rein-adapter, profile, and registry source plus the 58-test suite;
• GLAS-WP-0004, its corrected evidence note, and the residual handoffs;
• GLAS-WP-0005 production fail-closed evidence through sandbox d750cd5c;
• GLAS-WP-0006 actor-boundary correction; and
• current Forgejo package/test/catalog validation.

Executive assessment

The implemented nucleus matches the narrowest statement in INTENT.md: Glas is a strict, versioned execution router that chooses a declared constellation, coordinates sand-boxer lifecycle, invokes one of two concrete reins through a stable adapter shape, and emits normalized evidence.

It does not yet match the larger claim that Glas is Coulomb's unified agent harness service. The main operational gap is more fundamental than the future feature gaps: neither local profile can currently launch its rein inside the declared bwrap transport. Glas now fails closed at that boundary, which is the correct security behavior but not positive execution capability.

Intent pillar assessment

Intent pillar	Assessment	Evidence and gap
Unified harness API	Partial	Strict request/result and one bounded lifecycle exist. Resume, long-lived sessions, policy transitions, and subagent join semantics do not.
Harness profile catalog	Implemented as configuration resolution	Versioned catalog and rein compatibility checks are packaged and CI-tested. enabled is selection policy, not operational readiness.
Sand-boxer consumption	Partial and fail-closed	Create/destroy and reachability derivation exist. Local owner-mediated execution/runtime/egress are missing; remote positive execution is unproven after the boundary correction.
Concrete harness routing	Partial	Two adapters and explicit selection exist. Current local selections cannot reach rein dispatch inside bwrap.
Tool orchestration and policy	Minimal/delegated	Glas dispatches one opaque run_task; the rein owns its loop and tool policy. Glas has no general tool catalog, per-tool policy engine, or explicit elevated path.
Memory and skills	Not implemented	No memory store, skill service, identity-document lifecycle, or cross-channel persistence exists.
Channels	Minimal	CLI exists. Chat, email, Slack/Telegram, MCP gateway, and production network service do not.
Subagent delegation	Not implemented	No spawn/join contract, bounded context delegation, or sub-session lifecycle exists.
Observability and governance	Partial	Actor/ref attribution, lifecycle outcome, model/profile/rein identifiers, teardown, and value-safe State Hub progress exist. Complete live tool/session event streaming is not a gateway-wide service.
Workforce separation	Implemented	Organizational references remain opaque and scheduling/assignment authority stays upstream. The production actor mismatch now fails before sandbox creation.
Sibling boundaries	Implemented architecturally	Glas does not embed sandbox provisioners, validation orchestration, code generation, scheduling, or secret storage.

Corrections to prior scope language

The previous SCOPE.md said profiles were executable and both constellations were live-proven with real commits and sandbox cleanup. Those runs proved profile selection, rein dispatch, provider behavior, commits, evidence shape, and lifecycle cleanup under the implementation that existed then. They did not prove sandbox-contained rein execution: the adapters still invoked host-local CLIs against the caller checkout.

GLAS-WP-0005 removed that fallback. A production retry with the corrected actor mapping created bwrap sandbox d750cd5c, then failed at session start because direct consumer nsenter was not permitted. Destruction and workspace removal succeeded. Current scope therefore claims secure refusal and teardown, not a positive local execution path.

Gap register and disposition

Operational blockers

1. Owner-mediated local execution and runtime delivery — critical. GLAS-IN-0002 owns the sand-boxer contract for command execution, mounted or imaged rein runtime, explicit model egress, credential delivery, and teardown evidence. GLAS-WP-0005-T05 remains waiting on it.
2. Profile readiness semantics — resolved 2026-08-23. GLAS-WP-0008 separated catalog enablement from typed ready, unverified, and blocked runtime states. Known blockers now refuse before sandbox creation, while a labeled unverified profile remains available for a bounded proof attempt.

Record-governance gaps

3. Legacy identifiers. GLAS-IN-0003 owns exact grandfathering of the stable GLAS-0001 bootstrap identities.
4. Ad hoc convention mismatch. GLAS-IN-0004 owns alignment between the generated AGENTS.md convention and Repo Manager's accepted identifier kinds.

Roadmap deltas, not current commitments

Memory/skills, additional channels, resumable sessions, a gateway-owned tool policy system, subagents, and richer audit streams remain intentional future outcomes. They need consumer-backed workplans and acceptance criteria before implementation. This assessment does not silently promote them into a backlog or claim them as capabilities.

Recommended sequence

1. Complete GLAS-IN-0002 and capture one positive, source-isolated rein run.
2. Use the implemented readiness state in catalog output and evidence; promote a profile to ready only with a positive evidence reference.
3. Reassess whether the remote profile is an operational recovery path or an unproven declaration; retain it only with evidence and owned runtime setup.
4. Add broader harness pillars only when a real channel/consumer supplies the boundary and evidence requirements.

Until step 1 completes and at least one profile has positive runtime evidence, describe Glas as a secure, fail-closed execution router nucleus—not yet the default or unified agent harness service promised by the maturity target in INTENT.md.