glas-harness/history/2026-09-06-102533-scope-vs-intent-assessment.md

Scope versus intent assessment

Timestamp: 2026-09-06 10:25:33 CEST (UTC+02:00). Baseline: Glas 5867842; INTENT.md dated 2026-08-20.

Assessment

Glas implements the nucleus that INTENT.md explicitly identifies: a versioned, profile-driven execution router over concrete reins. It supplies a useful library/CLI boundary, strict catalog selection, sandbox lifecycle coordination and compact results. It does not yet satisfy the larger promise of Coulomb's default unified agent runtime.

The most immediate gap is operational acceptance: no committed profile is ready, and no post-hardening real local model run has satisfied the full acceptance contract. The broader feature gaps remain substantial but should not distract from closing that first usable execution path.

Evidence and method

Reviewed SCOPE.md and INTENT.md against:

• src/glas_harness/{contract,profiles,gateway,transport,hub,cli}.py, both rein adapters and the channel interface/CLI implementation;
• all three committed profiles and both rein registry descriptors;
• the test suite and the latest review result: 110 passing tests, catalog validation passing at code commit 863fab7, with final record sync at 5867842; no tests or live credential/model runs were repeated for this documentation-only assessment;
• scripts/prove-owner-boundary.py, inspect-local-runtime.py and prove-local-profile.py, plus recorded boundary, egress and credential transport evidence in docs/evidence/;
• GLAS-WP-0012, the residual register and the prior 2026-08-23 assessment;
• recorded owner updates at secrets-engine 7b4b9e3 / 083bee7 and FLEX-WP-0021; these show implementation/publication, not deployment; and
• .forgejo/workflows/ci-smoke.yaml workflow intent (package installation, tests, catalog validation). No fresh remote CI receipt was checked in this review.

Source behavior, historical proof and operational readiness are treated as separate evidence levels. Owner mechanisms are not counted as Glas-owned implementations. This is an assessment snapshot, not a live backlog authority.

Alignment with INTENT.md

Intent area	Assessment	Remaining gap / boundary
Unified harness API	Partial	Versioned request and synchronous single-run lifecycle exist. No resume, persistent session store, turn API or recovery service.
Profile catalog	Strong within the nucleus	Explicit constellation, compatibility and readiness checks work. Runtime artifact provenance is not fully encoded by the Glas schema; readiness still needs host-scoped evidence.
Sandbox consumption	Implemented boundary, partial operational acceptance	Local owner execution and remote SSH are implemented. Local non-secret proofs pass; real local rein acceptance and positive remote proof remain outstanding.
Tool orchestration and policy	Delegated/minimal	One opaque run_task invokes a rein. Tool policy is passed to it. No general Glas tool catalog, per-tool authorization or configurable elevated escape path.
Limits	Partial	Per-command timeout and backend token/turn parameters exist. No aggregate execution deadline, shared resource accounting or subagent budget enforcement.
Memory, skills and identity documents	Absent as Glas services	No store, synchronization, retrieval or lifecycle API. A rein's own features do not establish shared Glas capability.
Channels and extension platform	Foundation only	Channel/Rein contracts and CLI exist. No chat/email/MCP bridge, generic tool-backend or memory plugin contract, discovery/lifecycle service or hosted gateway.
Subagents	Absent	No spawn/join, bounded context, parent-child identity or delegated sandbox lifecycle contract.
Observability	Partial	Run evidence, attribution and optional captured Claude events exist. No live cross-rein event stream, durable audit outbox or guaranteed reporting. Open-weight tool events remain unavailable.
Workforce separation	Aligned	Opaque organizational references are preserved; scheduling/allocation remain upstream. Actor enum validation does not authenticate an initiator or authorize an assignment.
Sibling ownership	Aligned in code	Provisioning, secrets, scheduling, product validation and generation are not embedded. Integration tests do not turn Glas into wise-validator.
Default production agent runtime	Not achieved	No ready profile, production service surface or proven workstation-independent consumer deployment.

Progress since the previous assessment

The August assessment's missing owner-execution path is no longer current. Glas replaced direct namespace entry and host task writes with sand-boxer exec; non-secret source isolation, identity, task cleanup and teardown passed. Sand-boxer separately proved runtime mounting/private state, controlled egress and synthetic credential delivery. The real-rein acceptance runner now checks committed/worktree artifact content before teardown.

Local code reviews also fixed shared adapter result state, normalized manager startup failures and rejected duplicate YAML keys rather than silently accepting overwritten routes or limits. These improve the nucleus without adding long-lived harness features or proving a provider workload.

Credential custody is confirmed only through metadata. Gate-house settled the approval-claim/decision split, secrets-engine implemented it, and flex-auth published the lifecycle policy. Real decision verification, deployment, production service identity and lane activation remain distinct prerequisites.

Gaps and disposition

1. First usable local profile — highest operational priority. Continue GLAS-WP-0012 with SAND-WP-0015 and SECRETS-WP-0009 owner returns. Require pinned Claude startup, real protected delivery, provider scope/budget inputs, combined artifact/identity/cleanup acceptance and a versioned profile review. Do not promote either blocked profile based on synthetic proofs.
2. Other execution routes — independently unproven. GLAS-IN-0002 retains open-weight acceptance. The remote profile remains unverified; its lack of a current positive proof must remain visible and must not be treated as a ready fallback.
3. Broader harness features — consumer-backed design needed. Memory, skills, persistent sessions, subagents, additional channels and generic tool plugins are INTENT deltas, not defects in the bounded router contract. Establish specific consumers and acceptance criteria before new workplans.
4. Operational governance and audit — partial. External authorization is not supplied by Glas attribution. Durable audit delivery, complete tool visibility and aggregate limits need explicit requirements if consumers depend on them; existing progress reporting cannot imply those guarantees.
5. Record conventions — existing owner work. GLAS-IN-0003/0004 remain recorded as open. The latest ad hoc task needed a registration workaround; successful synchronization of that task does not resolve the convention. Legacy-bootstrap intake wording is historical and needs owner reconciliation against the current migrated workplan before claiming a current defect.

No new implementation workplan is created by this assessment. Existing operational blockers retain their live records; vision gaps remain proposals.

INTENT.md details that need reconciliation

INTENT is intentionally aspirational, but some integration details are stale or ambiguous even as a target:

• The sandbox example describes an HTTP create call and consumer fields harness/session_id/actor. Current Glas uses the Python manager with actor/project/run_id, then owner exec locally or SSH remotely. It does not implement generic exec/read/write/edit tool APIs or recreate transitions.
• The direct-exec integration question is answered for the current nucleus: local commands use owner exec; remote commands use SSH. Mirror versus remote-canonical policy is not exposed as a general Glas tool API.
• Cron appears among harness concerns while scheduling is explicitly excluded. A future invocation adapter can consume scheduled work; ownership of when work runs must stay upstream.
• Assigning model API keys broadly to llm-connect does not describe the current native workload lane: OpenBao custody, secrets-engine delivery and owner execution participate, and rein-openweights has its own provider client.
• "Observable by default" is an aspiration beyond best-effort progress posts; complete audit delivery and per-tool control are not present guarantees.

INTENT.md is left unchanged: narrowing or revising its target is a separate product decision. SCOPE.md now states the implemented behavior and limits.

Result

SCOPE.md now distinguishes implemented router behavior, owner proof evidence, profile readiness, intended features and external ownership. The appropriate capability claim is a bounded execution-router library/CLI with hardened sandbox integration and pending real-workload acceptance.