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.