rein-aharness/docs/architecture.md
tegwick 66ccd4fa01 feat: issue-core task intake poll/claim/run (HARNESS-WP-0001-T03)
Add intake client mapping emissions to TaskSpec, CLI poll and
run --from-issue-core, keep --task-file for local dev. Completes
HARNESS-WP-0001 workplan.
2026-07-18 11:30:40 +02:00

5 KiB

agent-harness Architecture

Status: v0.1, 2026-07-17. Companion to ADR-001 and INTENT.md. The code in agent_harness/ is the prototype seed (formerly ~/executor-worker, built for BINKY-WP-0004-T04); this document describes both what exists and the target shape.

The three-layer model

┌─────────────────────────────────────────────────────────────┐
│ CONSUMING REPO (e.g. binky-control)              [instance] │
│   .kaizen/schedule.yml + agent manifest   ← declarative only│
│   .kaizen/agents/<name>/memory.md, metrics                  │
└──────────────▲──────────────────────────────────────────────┘
               │ reads instance state          ┌──────────────┐
┌──────────────┴──────────────┐  blueprint via │kaizen-agentic│
│ AGENT-HARNESS      [runtime]│◄───────────────┤  [blueprint] │
│  task intake → persona bind │ schedule       └──────────────┘
│  → credential acquisition   │ prepare
│  → bounded agentic session  │
│  → commit verification      │        ┌───────────────┐
│  → hub + kaizen reporting   │◄───────┤ activity-core │ emits tasks
└───┬──────────┬──────────┬───┘        │  [scheduler]  │ (cron/event)
    │          │          │            └───────────────┘
 llm-connect  OpenBao   State Hub
 (adapters)  (ops-warden  (REST: progress,
              lanes)       tasks, decisions)

Components (current prototype → target)

Component File Today Target
Instance manifest manifest.py extends .kaizen/schedule.yml; validate CLI unchanged contract; tenant onboarding
Tool profiles profiles.py green-commit-only, blue-mail-triage registry additional named profiles as needed
Task intake intake.py + taskspec.py issue-core GET/PATCH poll+claim; JSON task-file for local dev NATS when activity-core migrates
Persona persona.py kaizen-agentic schedule prepare (ADR-005) unchanged, plus phase-memory profile hook
Session adapter.py AgenticClaudeCodeAdapter (cwd-pinned, profile allow-list) + hosted adapters
Orchestration runner.py profile/budget → session → commit → metrics → hub activity-core intake
Metrics metrics.py ADR-004 .kaizen/metrics write per run correlate with Helix fleet metrics
Mail lane mailscan.py deterministic credentialed pre-step outside the session pattern generalizes to other credentialed pre-steps
Hub reporting hub.py REST progress event + task close + token event unchanged

Contracts

Instance manifest.kaizen/schedule.yml (ADR-005 base + harness extensions). Full contract: instance-manifest.md. Fields: blueprint, cadence, enabled, lane (green/blue), tool_profile (named), budget (tokens/run), harness (pinned major).

Tool profiles are named allow-lists defined centrally in the harness (profiles.py), referenced by name from manifests — instances never enumerate tools. Seed: green-commit-only, blue-mail-triage. No push, no network, no arbitrary shell. Unknown profile = refuse to run.

Completion events are the idempotence currency: each run posts a progress event (e.g. binky_daily_brief, binky_mail_intake) with detail.repo; activity-core's binky_rhythm_status-style resolvers read them to decide dueness. Failures post generic failure events so slots stay due.

Credentials are acquired per run, held only in process memory/child env, never logged: LLM key via the llm-connect OpenBao lane, git push via per-repo forgejo deploy keys, tenant secrets (e.g. IMAP) via non-interactive AppRole. See binky-control integrations/executor-worker-secrets.md for the provisioned lanes.

Regulation and evolution

  • Regulation: manifest declares, harness enforces. flex-auth gates apply at credential acquisition; ops-warden catalogs every lane; each instance runs under a named hub identity (agt-…).
  • Evolution: the harness emits .kaizen/metrics per run so the kaizen optimization loop covers both blueprints and the harness itself. Harness releases are versioned; instances pin majors; blueprint conformance tests run before rollout.

Deployment

One deployment on Railiance (single-tenant-host, multi-tenant-repos). State Hub reachable at :18000 via ops-bridge from remote hosts. The workstation may run the harness ad hoc for development; production runs must not depend on it (that dependence is the problem this repo solves).