# 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/`