glas-harness/SCOPE.md
tegwick 1cd890d871
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
feat: add versioned execution profiles
2026-08-21 00:21:53 +02:00

75 lines
3.3 KiB
Markdown

# SCOPE
## One-liner
Primary, profile-driven execution layer routing governed work between concrete
agent-harness backends ("reins") while consuming sand-boxer for isolation. See
`docs/adr/ADR-001-rein-harness-family.md`.
## Core Idea
glas-harness owns the harness contract (`docs/harness-contract.md`:
`start_session`/`dispatch_tool`/`end_session`) and the outer loop — profile
resolution, rein/model/tool-policy selection, sandbox request/teardown via
sand-boxer, actor attribution, and normalized evidence. A rein owns its own
inner agentic loop and is invoked through that contract.
Workforce and leadership systems decide *who is responsible for what* and pass
assignment, role, duty, goal, and resource-envelope references. Glas decides
*how that already-authorized assignment executes*. It does not assign workers,
elect leaders, decompose organizational goals, or schedule work.
## In Scope
- Versioned strict execution request, profile, lifecycle, result, and evidence
models plus the `Rein` ABC
(`src/glas_harness/contract.py`)
- Deterministic harness-profile and rein-registry validation/resolution
(`src/glas_harness/profiles.py`)
- The gateway that resolves an explicit harness profile, requests a sandbox,
runs one task through a rein, verifies, tears down
(`src/glas_harness/gateway.py`)
- Rein adapters that shell out to each rein's own CLI
(`src/glas_harness/reins/`) — currently `rein_aharness.py`,
`rein_openweights.py`
- The rein registry (`registry/reins/`) and harness profile catalog
(`profiles/`)
- Compact, non-secret execution evidence and attribution references for State
Hub and other audit consumers
## Out of Scope
- Sandbox provisioning, profiles, placement — owned by `sand-boxer`
- A rein's own agentic loop, tool execution, credential acquisition —
owned by the rein itself (`rein-aharness`, `rein-openweights`, ...)
- Leadership, workforce allocation, role/duty/goal definitions, assignment
authority, scheduling, and task sourcing — owned by their domain systems and
passed to Glas as references
- Scheduling/blueprint sourcing inside the execution layer — stays rein-local
(`docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md`)
- Provider/model catalog authority and inference APIs — owned by providers and
`llm-connect`; Glas carries the approved route and resolved identifier
- Secrets and credential brokering — credentials remain rein-local and profiles
contain route references only
- e2e validation, code generation — owned by `wise-validator`,
`snuggle-inventor`
## Current State
The contract and first two reins are implemented. Profiles are executable,
versioned runtime inputs; CLI and gateway invocation require an explicit
profile; and both rein/model constellations are live-proven with real commits,
sandbox cleanup, and the same evidence shape.
The CLI channel and Glas-owned State Hub gateway reporting are implemented.
Still outside the current prototype: additional real channel extensions,
memory/skills services, subagent delegation, requirements-based profile
selection, and workforce-management APIs. Those are not implicit capabilities
of the profile router.
## Getting Oriented
- Start with: `INTENT.md`, `docs/adr/ADR-001-rein-harness-family.md`
- Contract: `docs/harness-contract.md`, `docs/execution-profiles.md`
- Agent instructions: `AGENTS.md`
- Workplans: `workplans/`