# 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`.