tegwick
cac605abd7
Some checks failed
ci / validate (push) Has been cancelled
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0233b-178d-7162-b92f-31a31ea8ca9b
105 lines
6.3 KiB
Markdown
105 lines
6.3 KiB
Markdown
# 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`.
|