docs: reconcile scope with verified capability

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0233b-178d-7162-b92f-31a31ea8ca9b

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

@@ -0,0 +1,104 @@
+# 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
+
+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. 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 1–2 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`.