kaizen-agentic/docs/assessments/2026-08-20-intent-role-automation-readiness.md

# INTENT Alignment and Role-Agent Automation Readiness

**Date:** 2026-08-20

**Workplan:** KAIZEN-WP-0012

> **Execution-boundary update, 2026-08-21:** This assessment captured the
> then-live activity-core → rein-aharness intake path. GLAS-WP-0004 subsequently
> proved contract 1.0 across two rein/model constellations. Kaizen blueprints
> and agent instances should now hand a versioned `harness_profile_ref` to
> glas-harness rather than encode a concrete rein, provider, model, or sandbox.
> Scheduling remains with activity-core and task/blueprint intake remains
> caller- or rein-local; the assessment's ownership and budget findings remain
> valid.

**Assessment:** materially aligned, operationally useful, not yet at the full
`INTENT.md` maturity target

## Executive assessment

KaizenAgentic has grown beyond the prompt library described by the previous
`SCOPE.md`. It now provides most of the **blueprint and improvement-contract
layer** required by `INTENT.md`: versioned agent definitions, project memory,
protocols, execution metrics, feedback, optimizer recommendations, schedule
manifests, preparation bundles, engagement conventions, and a pilot Role
package.

The strategic boundary remains sound. KaizenAgentic should not absorb runtime,
scheduling, credentials, authorization, or durable task lifecycle. Those pieces
now exist elsewhere:

- **role-engine** defines organizational roles;
- **activity-core** schedules activity and emits durable claimable `ops_run`
  work;
- **rein-aharness** claims work and runs governed agent sessions;
- **llm-connect** supplies provider-neutral model execution;
- identity, OpenBao/credential routing, and policy systems control access;
- State Hub and repo-local `.kaizen/` state retain coordination and improvement
  evidence.

The missing link is a governed, machine-readable chain from a role definition
through an authorized goal and constrained workforce allocation to a specific
agent assignment and executable instance. The runtime path itself is no longer
hypothetical: activity-core's queue and rein-aharness's generic `agent-session`
approach are implemented. However, the current queue payload and harness intake
do not carry an explicit goal, leader, role, assignment, budget envelope, or
arbitrary agent-instance reference. Rein-aharness currently infers the agent
from a small fixed definition/label map and otherwise defaults to `coach`.

## Naming and ownership finding

No repository, service, or contract named `role-manager` was found in the
workspace on 2026-08-20. The current role-definition repository is
**role-engine**; its `INTENT.md` is still marked Draft.

This matters because role-engine's `INTENT.md` explicitly says:

- roles are not identities;
- role definitions do not grant permissions;
- live assignment, scheduling, and workflow execution are out of scope;
- machinery should be added only for demonstrated consumer requirements.

Therefore “roles as defined by role-manager” is treated here as “roles defined
by role-engine.” `agentic-resources` is the best-fit existing repository to
become the **agent workforce and assignment manager**, subject to an explicit
INTENT/SCOPE decision there. That preserves role-engine's catalog boundary and
avoids introducing a role-manager service before a separate runtime service is
actually needed. Consumer-owned assignment manifests can remain the durable
source while agentic-resources indexes, plans, and governs the portfolio.

## Agentic-resources and human-resources finding

`agentic-resources` is **not intent-only**, although its root `SCOPE.md` is a
stale generated placeholder. Its finished AGENTIC-WP-0002 through WP-0011 work
implements a substantial Helix Forge loop:

- capture and normalize Claude, Codex, and Grok coding sessions;
- retain raw/digested memory within storage budgets;
- detect cost, failure, success, and infrastructure-friction signals;
- curate evidence-backed solution patterns with human approval;
- distribute approved patterns into agent environments;
- measure before/after effectiveness and fleet trends;
- publish weekly retrospectives and correlate with Kaizen project metrics.

That is already an **agent performance and development** subsystem. It is a
natural foundation for agent inventory, selection, assignment, capacity
planning, performance review, development, reallocation, and retirement. It
does not currently implement those workforce-management records, nor does its
current session-memory code understand organizational goals or financial
budget envelopes.

`human-resources` is the useful sibling model, but is much earlier: its current
implementation is a draft workflow registry and assessment loop covering
current-state inventory, automation potential, human-touch boundaries, and
readiness. Its INTENT explicitly includes human goal-setting, feedback,
coaching, compensation, workforce planning, and development. The two resource
systems should share vocabulary where useful—goal assignment, accountability,
capacity, performance evidence, development plan, lifecycle—without combining
human-sensitive records with agent telemetry or pretending humans and agents
have identical authority and welfare concerns.

Recommended boundary for agentic-resources:

- **Own:** agent workforce inventory, fit/selection evidence, assignments,
  capacity allocations, performance/development plans, portfolio reviews, and
  rebalance/retirement recommendations.
- **Consume:** leadership goals and mandates, role-engine definitions, Kaizen
  blueprints/metrics, fin-hub constraints, resource-control evidence, State Hub
  work/outcomes, and runtime status.
- **Do not own:** company strategy, the meaning of organizational roles,
  financial truth or spending authority, resource procurement, credentials,
  scheduling, or execution.

## Assessment against INTENT.md

| INTENT commitment | Current evidence | Assessment |
|---|---|---|
| Canonical mission and operating model | `INTENT.md`, wiki, ADRs, agency and engagement documents | Strong |
| KaizenAgent definition template | Template exists; authoring/docs CLI and 20 packaged definitions exist | Partial: the reference fleet still uses less structure than the full template |
| Meta-optimizer concept | `OptimizationLoop`, metrics summaries, `metrics optimize`, feedback and correlation | Strong foundation; refinement approval/version rollout is not closed-loop |
| Measurable behavior | Execution JSONL, summaries, engagement metrics, event and artifact publication | Implemented, but coverage depends on callers recording closeout evidence |
| Idempotent behavior | Idempotency keys exist in engagement closeout and downstream `ops_run`; validation is repeatable | Partial: generic blueprint definitions do not yet declare convergence/idempotency semantics uniformly |
| Codebase improvement guidance | Specialized agents, protocols, templates, tutorials, integration patterns | Useful reference implementation; machine-checkable guidance model remains incomplete |
| Relationship among prompts, experiments, mantras, agents, capabilities | Conceptual material and capability metadata exist | Partial: relationships are documented more than schema-validated |
| Product, pricing, revenue, and brand framing | Agency model, Role packages, Kai pilot settlement, wiki framing | Present at pilot level; not yet a repeatable commercial operating system |
| Versioned, testable, reversible units | Package releases, Git history, tests, Role version, ADRs | Strong for code and packages; blueprint compatibility/pinning needs a formal contract |
| Define → deploy → measure → refine → commercialize | Define/deploy/measure are operational; refine and commercialize have working pieces | Maturity target not yet complete |

### Design-principle fit

- **Continuous improvement:** directly represented in metrics, feedback, memory,
  optimization, and engagement closeout.
- **Measurable by default:** supported by tooling, but not yet mandatory in every
  agent definition or automated run result.
- **Idempotent operations:** present in selected workflows, not expressed as a
  required blueprint field or verified per duty.
- **Evidence over intuition:** strong conventions and event/artifact paths exist;
  optimizer recommendations still require a clearer promotion gate.
- **Separation of concerns:** strong and increasingly proven by the
  activity-core / rein-aharness split.
- **Composable capabilities:** agents, protocols, memory, schedules, Roles, and
  integrations are composable, though their shared schema is fragmented.
- **Human-readable and machine-executable:** human-readable coverage is strong;
  role-engine roles are not yet machine-readable enough for safe compilation.
- **Rollback-ready evolution:** Git/package rollback exists; assignment,
  blueprint pinning, and canary policy need standardization.
- **Compounding value:** evidence can accumulate, but automatic evidence →
  approved blueprint revision → controlled rollout is not closed.

## What already works end to end

The ecosystem has the following proven backbone:

```text
activity-core Temporal schedule/event
        │
        ▼
rule action → durable ops_run (idempotent, lease/claim/retry)
        │
        ▼
rein-aharness claim-loop → approach selection
        │
        ▼  labels/approach_hint = agent-session
repo instance policy → kaizen-agentic schedule prepare
        │
        ▼
bounded LLM session → local commit verification
        │
        ▼
ops_run result + State Hub progress + .kaizen metrics
```

Important existing controls include:

- unique per-fire `ops_run` idempotency keys;
- atomic claim with lease, heartbeat API, retry, and terminal failure;
- target-repository mapping on the harness host;
- named tool profiles, autonomy lanes, token budgets, and harness-major pins;
- offline blueprint/memory/metrics preparation;
- local commit verification and no-push runtime policy;
- completion metadata and artifact links in activity-core;
- per-agent metrics and State Hub progress reporting.

This means the next work is integration and governance, not building another
scheduler or agent runtime.

## Goal, leadership, and budget governance spine

Role automation needs a control hierarchy above the execution backbone:

```text
organizational intent
        ↓
leadership-owned goals and outcome measures
        ↓
financial/resource/attention envelopes
        ↓
agentic-resources workforce plan and RoleAssignment
        ↓
Kaizen blueprint + consumer-owned AgentInstance
        ↓
activity-core scheduled duty → rein-aharness bounded run
        ↓
outcome, cost, evidence, escalation
        ↓
leadership review + workforce rebalance + blueprint improvement
```

There is no single generic goal/leadership repository in the current
workspace. Goal authority is contextual. For Binky Hedgehog GmbH,
`binky-control` is the ratified company brain: it owns company intent, success
milestones, autonomy lanes, decision queues, and the founder-attention budget.
Other organizations or clients need an equivalent accountable control source.
Agentic-resources may translate a goal into workforce allocation, but it must
not invent or silently reprioritize strategic goals.

Leadership is an accountable relationship, not a prompt adjective. A
`LeadershipMandate` should identify:

- the organization/engagement and accountable leader or leadership agent;
- the goal(s) the leader may decompose and the outcomes it must preserve;
- decision rights, delegation depth, and prohibited commitments;
- who may approve, pause, reallocate, or terminate work;
- reporting/review cadence and the escalation chain;
- conflict-resolution order when goals or constraints compete;
- the time/attention budget expected from human reviewers.

An agent may lead other agents only inside this mandate. Role wording alone
must never create authority, and a leadership agent cannot widen its own budget
or tool grants.

### Budget layers and enforcement

“Budget” must not collapse into one token integer:

| Constraint | Authority/source | Allocation/control | Hard enforcement |
|---|---|---|---|
| Monetary budget, commitments, burn, runway | `fin-hub` | Leadership plus agentic-resources consume bounded constraint signals | Financial/approval systems; no autonomous spend outside an approved envelope |
| Infrastructure/model capacity and technical economics | `resource-control` | Agentic-resources uses forecasts, allocations, and optimization evidence | Platform/provider quotas and owning operators |
| AI-plan entitlement and booked effectiveness | `fin-hub`, joined to State Hub token evidence | Portfolio review and model/profile selection | Provider entitlement plus runtime policy |
| Per-run tokens and wall time | Delegated `ResourceEnvelope` | Agent instance/duty allocation | rein-aharness / llm-connect budget tracker and timeout |
| Concurrent agents and duty capacity | Agentic-resources workforce plan | Assignment allocator | activity-core eligibility plus harness worker/profile limits |
| Human attention and decision load | Organization leadership source; Binky example in `binky-control` | Decision batching and escalation policy | Approval queues and office-hour/autonomy lanes |

Fin-hub already exposes provenance-bearing budget-ceiling, commitment,
burn-pressure, and runway-pressure signals and owns booked AI-plan cost and
entitlements. Resource-control explicitly defers budget authority to fin-hub
and owns resource demand, capacity, utilization, allocation, and technical cost
evidence. Agentic-resources should consume both and allocate agent capacity
within them; it should not create a parallel money ledger or procurement
authority.

The shared `ResourceEnvelope` should support:

- stable ID, authority/source reference, period, scope, and currency/unit;
- hard ceiling, soft target, warning thresholds, and reserve;
- financial, token, wall-time, concurrency, and human-attention dimensions;
- amount allocated, committed, consumed, forecast, and remaining, with unknown
  distinct from zero;
- allowed reallocation authority and approval threshold;
- cost-attribution key and goal/assignment/duty correlation;
- exhaustion behavior: refuse, degrade, defer, or prepare an approval package;
- evidence timestamps and supersession/version links.

Activity-core should schedule only eligible allocations, while rein-aharness
enforces the per-run slice. Agentic-resources controls the period/portfolio
allocation and proposes rebalancing. Leadership decides goal priority and any
material budget or authority change.

## The missing role-to-run contract

The following records must remain distinct even when one manifest references
several of them:

| Record | Question answered | Recommended owner |
|---|---|---|
| `RoleDefinition` | What outcomes, duties, authority, interfaces, and evidence define the role? | role-engine |
| `AgentBlueprint` / executable Role package | How can an agent perform a safe subset of those duties? | kaizen-agentic |
| `StrategicGoal` | What outcome matters, why, by when, and how will success be judged? | Accountable organization/engagement leadership source |
| `LeadershipMandate` | Who may decompose the goal, direct work, decide, and escalate? | Accountable organization/engagement leadership source |
| `ResourceEnvelope` | Which financial, token, time, capacity, and attention constraints apply? | Fin-hub/resource-control/leadership facts composed into a delegated envelope |
| `RoleAssignment` | Which agent instance fills which role, for which goals, within which mandate and envelope? | Recommended: agentic-resources, with consumer-owned manifest as source |
| `AgentInstance` | Which blueprint, cadence, lane, profile, budget, memory, and runtime pin apply? | Consuming repository, validated by kaizen-agentic and the selected rein |

The first implementation should define a versioned `RoleAssignment` contract
with at least:

- stable assignment ID and lifecycle state;
- `goal_refs`, accountable outcome owner, and leadership-mandate reference;
- `role_ref` containing role ID plus immutable revision/version;
- `blueprint_ref` containing agent name plus package/version or content digest;
- client/tenant and one or more target references;
- duty selection: only the role duties delegated to this agent;
- expected outputs and evidence for each duty;
- cadence/event trigger references and timezone;
- autonomy lane, named tool profile, token/time budget, and harness-major pin;
- resource-envelope references plus duty-level allocation and exhaustion policy;
- credential-route **references**, never secret values;
- approval and escalation rules derived from role decision rights;
- memory/metrics custody location and retention classification;
- start/end dates, pause/disable switch, owner, and rollback revision.

## Required changes by repository

### Organization leadership/control source

1. Publish stable goal and leadership-mandate records with accountable owners,
   outcomes, measures, priority, horizon, decision rights, and escalation.
2. Delegate bounded financial, capacity, token, time, and attention envelopes;
   do not express “use judgment” as unlimited authority.
3. Resolve cross-goal priority and approve material reallocation, spending,
   external commitments, or expansion of autonomy.
4. For the Binky company context, reuse `binky-control` intent, milestones,
   autonomy lanes, decision packages, and founder-attention policy instead of
   creating parallel company governance in an agent repository.

### agentic-resources

1. Deliberately refine INTENT/SCOPE from the implemented Helix Forge
   session-improvement subsystem into an agent-workforce control boundary.
2. Define agent inventory, `RoleAssignment`, capacity allocation,
   performance/development plan, portfolio review, and retirement contracts.
3. Match roles and blueprints to delegated goals using evidence; record why an
   assignment is suitable and which role duties remain unstaffed.
4. Consume fin-hub constraint signals and resource-control evidence to allocate
   period budgets without copying financial or resource ledgers.
5. Aggregate run outcomes/costs by goal, role, assignment, and duty; recommend
   continue, coach/refine, reallocate, pause, or retire.
6. Require leadership approval for goal reprioritization, material envelope
   changes, and authority expansion.

### human-resources

1. Reuse compatible goal, accountability, capacity, review, and development
   vocabulary where it helps human/agent collaboration.
2. Keep human-sensitive records, compensation, welfare, employment, and
   relational judgment separate from agent telemetry and automated scoring.
3. Represent mixed human-agent teams and handoffs without treating people as
   interchangeable compute resources.

### role-engine

1. Add stable revision metadata or a small machine-readable companion format
   after agreeing the consumer need.
2. Structure at least duties, cadence suggestions, decision rights,
   escalations, interfaces, and success evidence.
3. Preserve the human-readable role contract as authoritative.
4. Do **not** add assignment, credentials, or scheduling merely to make the
   catalog look executable.

### kaizen-agentic

1. Define a `role_ref` and duty-coverage mapping for executable Role packages.
2. Reconcile the local `roles/<id>/ROLE.yaml` concept with role-engine: the
   former should be a derived execution package, not a competing organizational
   role source.
3. Add a compiler/scaffolder that consumes a pinned role definition plus an
   assignment, goal, mandate, and resource-envelope references and produces:
   - a bound agent blueprint;
   - protocols and success metrics;
   - `.kaizen/schedule.yml` base/runtime fields;
   - activity-core definition/rule fragments;
   - validation evidence showing which role duties are covered or excluded.
4. Add schema validation for blueprint version, role revision, idempotency,
   expected output, evidence, goal traceability, budget/refusal behavior, and
   escalation metadata.
5. Close the improvement promotion loop: evidence → proposed blueprint change →
   tests/evaluation → human approval → versioned canary → rollback or promote.

### activity-core

1. Keep schedule and queue ownership.
2. Extend the task/`ops_run` contract with structured execution metadata instead
   of encoding it only in labels or prose. Minimum useful fields are
   `goal_refs`, `leadership_mandate_ref`, `resource_envelope_ref`,
   `assignment_id`, `role_id`, `duty_id`, `agent_instance`, `blueprint_ref`,
   `expected_output`, allocated run budget, and a correlation/run key.
3. Emit `labels: [automated, agent-session]` and
   `approach_hint: agent-session` for governed agent sessions.
4. Resolve only active, enabled assignments and generate a unique run for each
   `(assignment, duty, target, scheduled fire)`.
5. Keep prompts, credentials, and raw model output out of `ops_run` records.

### rein-aharness

1. Keep runtime, credentials, policy enforcement, and claim execution ownership.
2. Replace fixed label-to-agent inference for role sessions with an explicit
   validated `agent_instance`/blueprint reference from the run contract.
3. Verify the run's assignment is active and its role/blueprint/runtime versions
   match the repo manifest; refuse expired mandates or envelopes.
4. Enforce duty-level tool profile, target allow-list, budget, timeout,
   concurrency, and escalation policy.
5. Return compact structured evidence: outcome, artifact path, commit, target,
   goal/blueprint/role/assignment revisions, allocated/consumed budget,
   metrics, and refusal/escalation reason.
6. Separate deterministic connectors from the LLM session. For example,
   Telegram collection or publishing should be bounded adapters; the model
   should receive prepared data and should not gain arbitrary network access.

### State Hub and policy/identity systems

1. Index goals, mandates, envelopes, assignments, and correlation IDs without
   becoming their authoritative source or the runtime.
2. Connect `goal → assignment → activity_run → ops_run → harness execution →
   artifact/commit → kaizen metrics → workforce review` for audit.
3. Represent human-needed/refused/escalated outcomes explicitly.
4. Route credential needs through the catalog/OpenBao path and enforce technical
   authorization independently of role wording.

### fin-hub and resource-control

1. Fin-hub remains authoritative for monetary budgets, commitments, burn,
   runway, AI-plan booked cost, entitlement, and viability signals.
2. Resource-control remains authoritative for resource identity, demand,
   capacity, utilization, allocation evidence, and technical economics.
3. Expose provenance-bearing constraints with stable period/scope keys so
   agentic-resources can allocate without guessing or treating unknown as zero.
4. Accept goal/assignment/duty attribution on usage and outcome evidence while
   keeping allocation evidence distinct from booked spend.

## Proposed instance shape

This is a **target contract**, not the current kaizen schedule schema:

```yaml
version: "2"
timezone: Europe/Berlin
harness: 0
assignments:
  community-manager-coulomb:
    goal_refs:
      - binky-control:goal:coulomb-community-health
    leadership_mandate_ref: binky-control:mandate:community-operations
    accountable_outcome_owner: founder
    role_ref:
      repository: role-engine
      id: community-manager
      revision: "<immutable-git-revision>"
    blueprint_ref:
      name: community-manager
      package_version: "<kaizen-agentic-version>"
    target: coulomb-society-operations
    resource_envelopes:
      financial: fin-hub:budget:coulomb-community:2026-Q3
      capacity: agentic-resources:envelope:community-ops:2026-W34
      attention: binky-control:attention:founder:2026-W34
    duties:
      weekly-community-health:
        goal_ref: binky-control:goal:coulomb-community-health
        cadence: weekly
        cron: "0 9 * * 1"
        enabled: true
        expected_output: reports/community-health/YYYY-MM-DD.md
        lane: green
        tool_profile: community-observe-report
        run_budget_tokens: 40000
        run_timeout_seconds: 900
        exhaustion: defer-and-report
        approval: none
      publication-draft:
        cadence: weekly
        enabled: false
        expected_output: outbox/community-update-YYYY-MM-DD.md
        lane: green
        tool_profile: community-draft-only
        run_budget_tokens: 30000
        approval: human-before-publish
```

The assignment compiler could initially render this into the current v1
`.kaizen/schedule.yml` plus an activity-core definition. Moving the base
schedule schema to v2 should happen only after kaizen-agentic, activity-core,
and rein-aharness agree the fields and compatibility path.

## Recommended first pilot

Use role-engine's only current role, `community-manager`, but automate a narrow,
low-risk duty rather than claiming the entire role is autonomous.

**Pilot duty:** produce a weekly community-health brief from an approved,
read-only snapshot of community activity.

**Why this duty:** it exercises role revision, assignment, scheduled intake,
blueprint preparation, evidence metrics, and escalation without granting
publishing, moderation, sanctions, membership, or direct messaging authority.

Pilot sequence:

1. Pin the role-engine revision and identify which Community Manager success
   criteria the brief measures.
2. Record the leadership-owned goal, accountable outcome owner, review cadence,
   and bounded financial/capacity/attention envelopes.
3. Have agentic-resources create the assignment and allocate a weekly duty/run
   budget without copying the authoritative budget ledger.
4. Create a Kaizen blueprint/protocol and tests for evidence quality,
   provenance, privacy handling, and “insufficient evidence” refusal.
5. Create a consumer-owned assignment and strict read/report-only instance.
6. Have a deterministic adapter place a sanitized activity snapshot in the
   target repo or artifact input; do not expose general Telegram credentials to
   the model session.
7. Register an activity-core weekly definition that emits an `agent-session`
   run with explicit assignment and duty identity.
8. Run through rein-aharness, producing only a local report commit.
9. Require human review and measure correctness, provenance, usefulness,
   false assertions, runtime, tokens, and escalation quality.
10. Review goal progress and envelope burn through agentic-resources; reallocate
    or pause if marginal value is poor or leadership priorities change.
11. Complete five clean scheduled/forced cycles before removing any manual
   fallback or considering a write-capable duty.

Only after the observation/reporting pilot is stable should the system add
drafting to a human-reviewed outbox. Automatic publishing or moderation should
remain separate, more privileged duties with explicit policy and approval.

## Operational definition of “fully automated”

For this system, fully automated should mean:

- the schedule/event fires without a person;
- an eligible assignment resolves deterministically;
- work is emitted once, claimed safely, and retried within policy;
- the exact role, duty, blueprint, target, runtime, and policy versions are
  known before execution;
- the run traces to a leadership-owned goal, accountable owner, active mandate,
  and unexpired resource envelope;
- portfolio and per-run financial/token/time/attention constraints are checked,
  with unknown never treated as unlimited or zero;
- the agent receives bounded context and tools;
- success is verified against an explicit output/evidence contract;
- results and costs are correlated and reviewable;
- refusal, escalation, pause, rollback, and lease recovery work without manual
  database repair.

It should **not** mean that every responsibility in a human role is delegated or
that role wording grants technical authority. A role can be fully scheduled
while only its safe, explicitly assigned duties are automated.

## Recommended implementation order

1. **Ownership decisions:** confirm role-engine as definition source,
   agentic-resources as agent-workforce/assignment owner, and the contextual
   leadership source for goals and mandates.
2. **Governance contracts:** StrategicGoal, LeadershipMandate,
   ResourceEnvelope, RoleAssignment, role-to-blueprint coverage, and structured
   `ops_run` execution context.
3. **Constraint integration:** consume fin-hub budget/viability signals,
   resource-control capacity evidence, and organization attention/autonomy
   policy without duplicating their authority.
4. **Adapters and validation:** Kaizen compiler/scaffolder, agentic-resources
   allocator, and explicit role-agent intake in rein-aharness.
5. **Read-only pilot:** Community Manager weekly health brief, human-reviewed,
   goal- and budget-correlated, for five clean cycles.
6. **Production controls:** dashboards, alerts, retry/dead-letter policy,
   pause/rollback, version canary, secret-route/policy audit.
7. **Improvement closure:** use measured pilot evidence to rebalance the agent
   portfolio and version/canary a blueprint refinement without rewriting the
   leadership goal or source role contract.

This route reuses the platform that is already live, preserves each
repository's stated intent, and concentrates new work on the genuinely missing
capability: goal-directed, leadership-accountable, budget-constrained agent
workforce allocation.