docs: define agent workforce execution boundary

SCOPE.md

@@ -1,32 +1,186 @@
 # SCOPE
 
-> This file was generated by `statehub register`. Refine it as the repository
-> boundaries become clearer.
+> Reviewed 2026-08-20 against the implemented Helix Forge loop and the
+> cross-repository leadership/workforce architecture discussion. For the
+> stable purpose and desired organizational outcome, see `INTENT.md`.
 
 ## One-liner
 
-Iterating towards optimal agentic performance.
+Agent-workforce performance and lifecycle management: learn from agent
+execution, improve the fleet, and—once the proposed contracts are
+implemented—plan and govern which agents fill which roles within
+leadership-owned goals and delegated resource envelopes.
 
 ## Core Idea
 
-agentic-resources exists to provide the capability described in INTENT.md.
+`agentic-resources` treats AI agents as a managed digital workforce rather
+than as isolated prompts or interchangeable runtime processes.
 
-## In Scope
+Its implemented Helix Forge subsystem captures coding sessions, finds
+repeated friction and successful techniques, curates and distributes reviewed
+solution patterns, measures their effectiveness, and produces fleet
+retrospectives. This is already the performance-and-development loop described
+by `INTENT.md`.
 
-- Maintain the repository's primary implementation.
-- Keep docs, tests, and operational metadata current.
+The recommended next boundary extends that evidence base into agent inventory,
+selection, assignment, capacity planning, development, portfolio review,
+rebalancing, and retirement. This repository may translate authorized goals
+and constraints into a workforce plan, but it does not create organizational
+strategy, leadership authority, money, technical capacity, or execution
+permissions.
+
+## Current Implemented Scope
+
+- Capture and normalize Claude, Codex, and Grok coding sessions.
+- Retain session digests and raw evidence within explicit storage budgets.
+- Detect recurring failure, friction, cost, and success signals across the
+  fleet.
+- Curate evidence-backed solution patterns through a review and approval flow.
+- Render approved patterns as agent-flavor-specific, reviewable distribution
+  proposals.
+- Measure before/after pattern effectiveness and fleet trends.
+- Publish weekly retrospectives and correlate fleet-level Helix Forge evidence
+  with project-level KaizenAgentic metrics by reference.
+
+## Recommended Workforce-Management Boundary
+
+The following concerns fit the intent and existing performance subsystem, but
+their contracts and implementation do not yet exist in this repository:
+
+- Maintain an inventory of available agent capabilities, instances, status,
+  lifecycle stage, and evidence of fitness.
+- Own the `RoleAssignment` control contract: which agent instance fills which
+  part of a role for which goals, under which leadership mandate and resource
+  envelope.
+- Express execution needs through a versioned `glas-harness` profile reference
+  or compatible requirements contract, rather than coupling assignments to one
+  concrete rein or base model.
+- Match agents, role duties, and Kaizen blueprints using explicit suitability
+  evidence; record unstaffed or deliberately human-owned duties.
+- Allocate concurrent agent and duty capacity within authoritative financial,
+  technical-resource, token, time, and human-attention constraints.
+- Aggregate outcomes, costs, refusals, and escalation quality by goal, role,
+  assignment, and duty.
+- Maintain performance and development plans and recommend continue, coach,
+  refine, reallocate, pause, or retire decisions.
+- Run portfolio reviews and propose rebalancing while requiring the authorized
+  leadership source to approve goal reprioritization, material envelope
+  changes, or wider authority.
+
+Consumer-owned assignment/instance manifests should remain the durable source
+initially; this repository can validate, index, plan, and review them without
+prematurely requiring a central workforce service.
+
+## Leadership and Workforce Relationship
+
+Leadership and workforce management are adjacent control layers, not synonyms:
+
+```text
+organization intent
+  -> leadership-owned StrategicGoal + LeadershipMandate
+  -> delegated ResourceEnvelope
+  -> agentic-resources workforce plan + RoleAssignment
+  -> Kaizen blueprint + consumer-owned AgentInstance
+  -> activity-core scheduled work
+  -> glas-harness profile resolution
+  -> selected rein + base-model + sandbox constellation
+  -> outcome, cost, evidence, refusal, escalation
+  -> leadership review + workforce rebalance + blueprint improvement
+```
+
+- A `StrategicGoal` states the desired outcome, priority, horizon, and success
+  measures. Its authoritative source is the accountable organization or
+  engagement control plane.
+- A `LeadershipMandate` states who may decompose goals, direct work, make which
+  decisions, delegate, pause, and escalate. A role title or agent prompt never
+  creates this authority.
+- A `ResourceEnvelope` composes provenance-bearing limits from leadership,
+  `fin-hub`, `resource-control`, and runtime policy. Unknown capacity or budget
+  is never treated as unlimited.
+- A `RoleAssignment` is the workforce decision within those inputs. It binds a
+  specific agent instance to selected role duties and records evidence,
+  limits, lifecycle, and review state.
+
+Agentic-resources therefore advises and administers the agent workforce;
+leadership remains accountable for direction, priority, material commitments,
+and expansion of authority.
+
+## Ecosystem Boundaries
+
+| Concern | Owning source | Relationship to agentic-resources |
+|---|---|---|
+| Organizational intent, goals, priorities, and leadership mandates | Contextual organization/engagement control source; for example `binky-control` for Binky Hedgehog GmbH | Consume stable references; return portfolio evidence and recommendations; never invent or silently reprioritize strategy |
+| Organizational role definitions | `role-engine` | Consume pinned role revisions and duty/authority boundaries; do not redefine roles or grant permissions |
+| Agent blueprints, protocols, and project metrics | `kaizen-agentic` | Consume versioned blueprints and run evidence; supply assignment and performance context |
+| Agent workforce inventory, assignment, capacity, development, and portfolio review | `agentic-resources` (recommended boundary; not yet implemented beyond performance learning) | Own the workforce plan and assignment lifecycle |
+| Human workforce lifecycle and mixed-team concerns | `human-resources` | Share compatible vocabulary and handoff contracts; keep human-sensitive, employment, welfare, and compensation records separate |
+| Monetary budgets, commitments, burn, runway, and AI-plan booked cost | `fin-hub` | Consume authoritative constraint signals and publish attribution; do not copy the financial ledger or approve spending |
+| Resource identity, demand, capacity, utilization, allocation evidence, and technical economics | `resource-control` | Consume planning/evidence signals; do not procure, operate, or invent capacity |
+| Scheduling and durable claimable work | `activity-core` | Supply active assignment/duty context; do not own the clock, queue, retry, or task lifecycle |
+| Harness contract, execution profiles, backend routing, sandbox coordination, and gateway evidence | `glas-harness` | Supply an approved, versioned profile or execution requirements; let Glas resolve the concrete rein and sandbox constellation; consume its unified result evidence |
+| Concrete inner agentic loop and backend-specific credentials/policy | Selected rein under `glas-harness`; currently including `rein-aharness` and `rein-openweights` | Treat a rein as a replaceable execution backend, not the workforce architecture boundary; `rein-aharness` is the live Claude-Code-CLI rein, not the meta-framework |
+| Identity, credentials, and authorization | Identity, OpenBao/credential-routing, and policy systems | Reference routes and policy profiles only; never store secrets or treat organizational wording as technical access |
+| Base-model/provider execution and inference routing | `llm-connect`, the selected rein, and provider adapters under their declared boundaries | Select through the approved Glas execution profile/route; consume usage/outcome evidence; do not hard-code a vendor model into workforce records or become a model gateway |
+| Durable coordination read model | Custodian State Hub | Publish/index work and evidence; do not replace source files or hub ownership |
 
 ## Out of Scope
 
-- Own unrelated adjacent systems.
-- Make irreversible operational decisions without human approval.
+- Setting organizational strategy, goals, or cross-goal priorities.
+- Granting leadership mandates, technical authorization, credentials, or tool
+  permissions.
+- Owning human personnel records, hiring, compensation, employment decisions,
+  welfare, or human performance surveillance.
+- Owning the canonical role catalog or treating a role definition as a live
+  assignment.
+- Owning monetary budget truth, payment/commitment approval, procurement,
+  infrastructure inventory, or provider capacity.
+- Owning schedules, queues, workflow/task lifecycle, LLM sessions, or runtime
+  policy enforcement.
+- Selecting a concrete rein or base model outside the approved
+  `glas-harness` profile/route, or treating `rein-aharness` as the universal
+  execution architecture.
+- Automatically applying self-modifications or retiring live agents without
+  the review and authority required by the relevant mandate.
+- Replacing KaizenAgentic, role-engine, activity-core, `glas-harness`, its
+  concrete reins, State Hub, fin-hub, or resource-control with a monolithic
+  agent-management service.
+
+## Intent Relationship
+
+`INTENT.md` describes the desired organizational outcome: a trustworthy,
+antifragile agent ecosystem that improves performance and augments human
+ingenuity through lifecycle management, oversight, and continuous alignment.
+It is deliberately broader than this repository's implementation ownership.
+
+This scope realizes that intent through a federated operating model. The repo
+owns the agent-workforce performance and lifecycle concern while consuming
+strategy, role, budget, resource, policy, runtime, and human-workforce facts
+from their authoritative systems.
 
 ## Current State
 
-- Status: active; implementation and stability should be verified by the repo agent.
+- **Implemented:** the Helix Forge capture -> detect -> curate -> distribute ->
+  measure loop, weekly retrospectives, and Kaizen metrics correlation.
+- **Completed work:** `AGENTIC-WP-0001` through `AGENTIC-WP-0011`; there are no
+  active normal workplans at the time of this review.
+- **Architecture proposal:** accept agentic-resources as the workforce and
+  assignment owner, subject to cross-repository ratification.
+- **Execution-layer implementation:** `GLAS-WP-0004` now provides strict
+  versioned requests/profiles, deterministic rein-registry validation,
+  explicit CLI/gateway selection, and one normalized evidence envelope.
+  `rein-aharness` is one current backend; workforce contracts preserve freedom
+  to choose a different rein, sandbox, tool policy, and base-model
+  constellation by changing the approved Glas profile reference. The
+  Claude-backed and open-weight profiles both have live success, real-commit,
+  and sandbox-cleanup evidence through the same Glas contract.
+- **Implementation gap:** agent inventory, `RoleAssignment`, capacity
+  allocation, goal/resource-envelope correlation, development plans, and
+  portfolio/retirement workflows are not implemented yet.
 
 ## Getting Oriented
 
-- Start with: INTENT.md
-- Agent instructions: AGENTS.md
-- Workplans: workplans/
+1. `INTENT.md` — stable organizational purpose.
+2. `docs/PRD-helix-forge.md` — implemented product boundary and architecture.
+3. `session_memory/README.md` — current operational capabilities.
+4. `docs/DESIGN-session-memory.md` — detailed design and Kaizen correlation.
+5. `workplans/` — implementation history and future work.