feat: add versioned execution profiles

INTENT.md

@@ -1,7 +1,7 @@
 ---
 domain: infotech
 repo: glas-harness
-updated: "2026-06-22"
+updated: "2026-08-20"
 ---
 
 # INTENT
@@ -9,8 +9,8 @@ updated: "2026-06-22"
 > glas-harness is the Coulomb **meta-framework for agent harnesses** — a unified
 > API and extension platform for running agentic assistants with tools, memory,
 > channels, and subagent delegation, while **consuming** sand-boxer for isolated
-> execution. This file is preliminary; refine as the harness boundary is
-> implemented.
+> execution. The implemented nucleus is a versioned, profile-driven execution
+> router over concrete reins.
 
 ---
 
@@ -36,7 +36,7 @@ Coulomb splits that stack deliberately:
 | **Code generation** — specs, generation, PR output | **snuggle-inventor** |
 
 glas-harness exists to be the harness side of that split: **one consistent way to
-run agents**, with extensions for channels and tool backends, and a single
+execute assigned agent work**, with extensions for channels and tool backends, and a single
 integration path to sand-boxer when tools need isolation.
 
 sand-boxer is OpenRouter for sandboxes. glas-harness is the parallel **harness
@@ -59,8 +59,8 @@ It answers:
 2. **What can the agent invoke?** Tool catalog, policies, elevated escape hatches.
 3. **What does the agent remember?** Memory, skills, identity documents, cron.
 4. **Where does the user interact?** Channel extensions (CLI, chat, email, …).
-5. **When do tools run in isolation?** Sandbox policy (`mode`, `scope`,
-   `workspaceAccess`) — fulfilled by **sand-boxer**, not implemented here.
+5. **When do tools run in isolation?** A named sand-boxer profile selected by
+   the Glas profile — fulfilled by **sand-boxer**, not implemented here.
 6. **How are subagents delegated?** Isolated sub-sessions with bounded context.
 7. **What happened?** Session and tool audit events to State Hub.
 
@@ -68,6 +68,31 @@ It must **not** become the sandbox provisioner, the e2e validator, the code
 generator, the scheduler, work-state authority, tunnel/CA owner, or production
 service host on Railiance01.
 
+## Relationship to leadership and workforce management
+
+Leadership and workforce management govern responsibility: roles, duties,
+goals, assignments, resource envelopes, escalation, and who may initiate work.
+Glas governs execution after that decision. Its request can carry opaque
+`assignment_ref`, `role_ref`, `duty_ref`, `goal_refs`, and
+`resource_envelope_refs` so evidence remains attributable without duplicating
+the organizational records.
+
+This separation is intentional:
+
+```text
+leadership / workforce authority
+  -> authorized assignment + organizational references
+  -> Glas ExecutionRequest + explicit harness profile
+  -> resolved rein/model/sandbox/tool-policy constellation
+  -> normalized evidence linked back to the assignment
+```
+
+Glas may refuse an unavailable or incompatible execution profile. It does not
+choose a leader, allocate a worker, reinterpret a duty, compile a role into a
+blueprint, or decide when work should run. Those decisions remain inspectable
+in their owning system while Glas supplies a stable, replaceable execution
+boundary.
+
 ---
 
 ## Coulomb sibling boundaries
@@ -148,7 +173,11 @@ glas-harness is a **meta-framework** with four pillars (preliminary):
 
 ### 1. Unified harness API
 
-One surface for session lifecycle across channel and automation consumers:
+One versioned surface for session lifecycle across channel and automation
+consumers. The implemented gateway accepts an explicit `ExecutionRequest`,
+resolves a harness profile, executes one bounded rein session, and returns
+`ExecutionEvidence`. Longer-lived sessions and subagent join semantics remain
+future work.
 
 - Start / resume / end sessions; subagent spawn and join
 - Tool dispatch with policy checks and audit metadata
@@ -160,14 +189,18 @@ human operators via CLI.
 
 ### 2. Harness profile catalog
 
-Named, versioned **harness profiles** (distinct from sand-boxer sandbox profiles):
+Named, versioned **harness profiles** (distinct from sand-boxer sandbox profiles)
+are runtime inputs, not documentation. They currently bind:
 
-- Default toolset and tool policy
-- Sandbox policy defaults (`mode`, `scope`, `workspaceAccess`) — OpenClaw-aligned
-- Memory and skills layout conventions
-- Channel allowlist
-- Model routing hints (consumer of `llm-connect`, not owner)
-- Registered in `registry/` via reuse-surface
+- concrete rein and required capabilities;
+- sand-boxer profile;
+- tool profile;
+- model provider, route, class, and explicit model identifier;
+- token, timeout, and turn limits; and
+- credential-route references without credential values.
+
+Resolution is deterministic and fail-closed. Governed execution has no implicit
+rein, model, sandbox, or tool policy.
 
 Example pairing:
 
@@ -268,11 +301,11 @@ for integration design only.
 
 ---
 
-## Sandbox consumption contract (preliminary)
+## Sandbox consumption contract
 
 When harness policy requires isolation, glas-harness:
 
-1. Resolves sandbox profile id (from harness profile or session override)
+1. Resolves the sandbox profile id from the versioned harness profile
 2. Calls sand-boxer `create` with `consumer: { harness: glas-harness, session_id, actor }`
 3. Stores `sandbox_id` and reachability descriptor on the session
 4. Routes `exec`, `read`, `write`, `edit`, and related tools through that handle
@@ -280,7 +313,7 @@ When harness policy requires isolation, glas-harness:
 
 Harness owns **tool semantics**; sand-boxer owns **environment lifecycle**.
 
-Open questions (for first workplan):
+Open integration questions:
 
 - Does glas-harness proxy exec or delegate SSH/tunnel to the agent client?
 - How are mirror vs remote-canonical workspace modes exposed to tool implementations?
@@ -290,15 +323,16 @@ T08 lands.
 
 ---
 
-## Near-term outcomes (preliminary)
+## Implemented nucleus and next outcomes
 
-1. **This charter** — `INTENT.md` aligned with sand-boxer sibling boundaries
-2. **Harness profile schema sketch** — distinct from sand-boxer profile schema
-3. **sand-boxer integration doc** — consumer contract (may start in sand-boxer repo)
-4. **First harness profile** — `harness.agent-dev` paired with `profile.agent-dev`
-5. **CLI gateway stub** — minimal session + local tools (no channels yet)
-6. **Registry entry** — e.g. `capability.platform.agent-harness`
-7. **State Hub session events** — tool audit envelope
+Implemented: strict contract version `1.0`, executable profile catalog,
+rein-registry validation, explicit CLI/channel selection, sand-boxer lifecycle,
+two concrete rein constellations, and normalized State Hub evidence.
+
+Next outcomes should be driven by real consumers: an additional channel,
+memory/skills integration, bounded subagent delegation, and an organizational
+assignment adapter. None should weaken explicit profile selection or move
+workforce authority into Glas.
 
 ---
 
@@ -313,4 +347,4 @@ A mature glas-harness is Coulomb's **default agent runtime**:
 - Extensions add channels and tool backends without forking core gateway logic
 
 The harness thinks and coordinates. sand-boxer establishes the box. wise-validator
-proves correctness. snuggle-inventor invents code. **glas-harness runs the agent.**
+proves correctness. snuggle-inventor invents code. **glas-harness runs the agent.**