glas-harness/history/2026-08-23-scope-vs-intent-assessment.md
tegwick 13aea7ff6f
Some checks failed
ci / validate (push) Has been cancelled
docs: reconcile scope with verified capability
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0233b-178d-7162-b92f-31a31ea8ca9b
2026-08-23 10:47:02 +02:00

6.2 KiB
Raw Blame History

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 — high. A catalog-valid enabled profile is currently presented alongside profiles that cannot dispatch on the deployed runtime. GLAS-IN-0005 requires an explicit readiness/enablement contract, including whether unproven profiles must be disabled or separately labeled.

Record-governance gaps

  1. Legacy identifiers. GLAS-IN-0003 owns exact grandfathering of the stable GLAS-0001 bootstrap identities.
  2. 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.

  1. Complete GLAS-IN-0002 and capture one positive, source-isolated rein run.
  2. Resolve GLAS-IN-0005 so catalog output distinguishes selectable schema from deployable runtime capability.
  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 steps 12 complete, 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.