feat: add versioned execution profiles

SCOPE.md

@@ -2,21 +2,31 @@
 
 ## One-liner
 
-Meta-framework routing between concrete agent-harness backends ("reins"),
-consuming sand-boxer for isolation. See `docs/adr/ADR-001-rein-harness-family.md`.
+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, sandbox request/teardown via sand-boxer, actor attribution. A
-rein owns its own inner agentic loop and is invoked through that contract.
+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
 
-- The `Rein` ABC and `SandboxHandle`/`ToolCall`/`ToolResult` types
+- Versioned strict execution request, profile, lifecycle, result, and evidence
+  models plus the `Rein` ABC
   (`src/glas_harness/contract.py`)
-- The gateway that resolves a harness profile, requests a sand-boxer sandbox,
+- 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
@@ -24,29 +34,42 @@ rein owns its own inner agentic loop and is invoked through that contract.
   `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`, ...)
-- Scheduling/task sourcing — stays rein-local
+- 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
 
-`GLAS-WP-0001` (harness contract + first two reins) is done. Both
-`rein-aharness` and `rein-openweights` are live-proven through the gateway
-against their real underlying providers (Claude Code CLI, OpenRouter).
-Not yet built: channel bridges, memory/skills layer, glas-harness's own
-State Hub reporting from the gateway (currently each rein reports its own
-events).
+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`
+- Contract: `docs/harness-contract.md`, `docs/execution-profiles.md`
 - Agent instructions: `AGENTS.md`
 - Workplans: `workplans/`