diff --git a/DecisionQueue.md b/DecisionQueue.md index aaf306a..bea6d6a 100644 --- a/DecisionQueue.md +++ b/DecisionQueue.md @@ -22,35 +22,30 @@ fallback_if_no_response: "" ## Open decisions -### DEC-2026-002 — Executor worker lives in a new small repo +*(none)* + +## Resolved decisions + +### DEC-2026-002 — Agent harness: one shared runtime repo ```yaml id: DEC-2026-002 -title: "Executor worker ownership: new thin repo (proposed name: executor-worker) vs. inside activity-core" +title: "Executor worker ownership: new thin repo vs. inside activity-core" lane: yellow -status: prepared +status: resolved +outcome: "approved, rescoped: single shared `agent-harness` repo for ALL projects" +resolved_at: "2026-07-17" +resolved_by: Bernd state_hub_decision_id: "63620255-59d0-4109-bdee-4d0644c450e5" -created_at: "2026-07-17" -needed_by: "before BINKY-WP-0004-T04 deployment (soft)" -attention_cost: "~2 min read" -agent_recommendation: "Create a new small repo. ADR-005 (kaizen-agentic) explicitly - excludes LLM invocation from both kaizen-agentic ('no LLM invocation; prepare - produces a runner-agnostic bundle') and activity-core (owns cron→task only); - headless-runner integration is marked 'future; prepare output is runner-agnostic'. - activity-core's TaskExecutorWorkflow is a stub by design. A thin repo consuming - emitted tasks + `schedule prepare` bundles + llm-connect adapters keeps all three - existing boundaries intact and matches the executor assessment - (integrations/llm-connect-executor-assessment.md)." -evidence: - - ~/kaizen-agentic/docs/adr/ADR-005-scheduled-agent-execution.md (Boundaries) - - integrations/llm-connect-executor-assessment.md -options: [approve, reject, revise, defer] -fallback_if_no_response: "Proceed with new-repo prototype for T04 in a sandbox; - no cutover (T06) before this decision is resolved." +consequence: "Three-layer model: blueprints in kaizen-agentic; instances as + declarative manifests + .kaizen state in consuming repos (no code, no + credentials, named tool profiles, pinned harness major); agent-harness is + the single credential holder / policy enforcer, deployed once on Railiance, + multi-tenant — binky-control is tenant #1. executor-worker prototype + adopted as the harness seed. Recorded as agent-harness ADR-001 + + docs/architecture.md; foundation work in HARNESS-WP-0001." ``` -## Resolved decisions - ### DEC-2026-001 — Ratify company canon v0 ```yaml diff --git a/integrations/executor-cutover-runbook.md b/integrations/executor-cutover-runbook.md index cddff83..c4e5e68 100644 --- a/integrations/executor-cutover-runbook.md +++ b/integrations/executor-cutover-runbook.md @@ -6,15 +6,16 @@ ## Gates (in order) -1. **DEC-2026-002 resolved** (DecisionQueue.md) — executor worker home. +1. ~~DEC-2026-002 resolved~~ **done 2026-07-17**: single shared + `agent-harness` repo (ADR-001 there); prototype adopted as its seed. 2. **Lane 2 + Lane 3 Red-lane provisioning** done (`integrations/executor-worker-secrets.md`): forgejo deploy key (sandbox repo first, binky-control at cutover) and AppRole - `executor-worker-binky-mail`. -3. **Worker deployed on Railiance** (repo `~/executor-worker` prototype; - deployment per activity-core's Railiance conventions) and one sandbox - task executed there end-to-end (same smoke as the 2026-07-17 - workstation run, sandbox commit e043f21). + `agent-harness-binky-mail`. +3. **Harness deployed on Railiance** (HARNESS-WP-0001-T06 in the + agent-harness repo) and one sandbox task executed there end-to-end + (same smoke as the 2026-07-17 workstation run, sandbox commit + e043f21). Tenant onboarding = HARNESS-WP-0001-T07. ## Cutover steps diff --git a/integrations/executor-worker-secrets.md b/integrations/executor-worker-secrets.md index 6bcd514..243f36e 100644 --- a/integrations/executor-worker-secrets.md +++ b/integrations/executor-worker-secrets.md @@ -1,10 +1,10 @@ -# Executor Worker — OpenBao Secret Lanes (BINKY-WP-0004-T03) +# Agent Harness — OpenBao Secret Lanes (BINKY-WP-0004-T03) > Status: prepared 2026-07-17. Catalog metadata and provisioning steps only — > **no secret values appear here or anywhere in git/hub/chat**. All new > provisioning is founder Red lane per AutonomyPolicy.md. -The executor worker (DEC-2026-002: new small repo, deployed on Railiance) +The agent harness (DEC-2026-002 resolved: single shared runtime repo `agent-harness`, deployed on Railiance) needs three credential lanes. One exists and is reusable; two need provisioning. @@ -19,7 +19,7 @@ Warden catalog `openrouter-llm-connect` (active, resolvable, reviewed - Policy gate: `flex-auth check secret.read:llm-connect` (advisory today) **Verdict: reuse.** The key is scoped to "llm-connect in activity-core"; the -executor worker is the consumer that scoping anticipated (it executes tasks +agent harness is the consumer that scoping anticipated (it executes tasks activity-core emits, via llm-connect adapters). No new secret needed. If the worker later gets its own workload identity, bind that identity to the same policy — same secret, separate auth principal — rather than duplicating the @@ -36,14 +36,14 @@ Proposed provisioning (founder Red lane, ~10 min): 1. Generate an ed25519 keypair on Railiance (worker host), private key never leaves the host; store a copy under OpenBao - `platform/workloads/executor-worker/forgejo-deploy-key` + `platform/workloads/agent-harness/forgejo-deploy-key` (fields: `SSH_PRIVATE_KEY`, `SSH_PUBLIC_KEY`). 2. In forgejo, add the public key as a **per-repo deploy key with write access** — sandbox repo only at first; add binky-control at T06 cutover. Per-repo deploy keys beat a machine-user account here: blast radius is exactly the repo list. -3. New OpenBao policy `workload-kv-read-executor-worker-forgejo` scoped to - that path; warden catalog entry `executor-worker-forgejo-deploy` (owner: +3. New OpenBao policy `workload-kv-read-agent-harness-forgejo` scoped to + that path; warden catalog entry `agent-harness-forgejo-deploy` (owner: railiance-platform, risk: high). ## Lane 3 — Non-interactive AppRole for company-email scan: NEW (Red lane) @@ -57,7 +57,7 @@ Proposed provisioning (founder Red lane, ~10 min): 1. Enable/confirm AppRole auth on the OpenBao instance (`bao auth list`; enable at path `approle` if absent). -2. Create role `executor-worker-binky-mail` bound to the **existing** policy +2. Create role `agent-harness-binky-mail` bound to the **existing** policy `workload-kv-read-binky-company-email-imap` (no policy change needed): `token_ttl=15m`, `token_max_ttl=30m`, `secret_id_ttl=0` (or rotate quarterly), `token_num_uses` bounded. @@ -66,7 +66,7 @@ Proposed provisioning (founder Red lane, ~10 min): repo). The worker logs in per run: `bao write auth/approle/login role_id=… secret_id=…` → short-lived token → `bao kv get -field=IMAP_USERNAME|IMAP_PASSWORD tenants/binky/company-email/imap`. -4. Warden catalog entry `executor-worker-binky-mail-approle` (owner: +4. Warden catalog entry `agent-harness-binky-mail-approle` (owner: railiance-platform, risk: high) so the lane is discoverable and audited. Scan invocation stays exactly the manual pattern (read-only email-connect, @@ -78,7 +78,7 @@ config `integrations/mailbox-binky-company.yml`, reports to - [ ] Lane 2: forgejo deploy key (generate, register on sandbox repo, store in OpenBao, catalog entry) -- [ ] Lane 3: AppRole `executor-worker-binky-mail` (create role, deliver +- [ ] Lane 3: AppRole `agent-harness-binky-mail` (create role, deliver role_id/secret_id to Railiance, catalog entry) - [x] Lane 1: nothing to do — reuse confirmed diff --git a/workplans/BINKY-WP-0004-workstation-independent-executor.md b/workplans/BINKY-WP-0004-workstation-independent-executor.md index a6e44c0..2c26e3b 100644 --- a/workplans/BINKY-WP-0004-workstation-independent-executor.md +++ b/workplans/BINKY-WP-0004-workstation-independent-executor.md @@ -108,7 +108,7 @@ re-add the cron line. Blue lane with founder notification at cutover. ```task id: BINKY-WP-0004-T06 status: blocked -blocking_reason: "Gates: DEC-2026-002 resolution + Red-lane Lane 2/3 provisioning + Railiance deployment + 3 business days of verified runs. Runbook prepared: integrations/executor-cutover-runbook.md" +blocking_reason: "Gates: Red-lane Lane 2/3 provisioning + agent-harness Railiance deployment (HARNESS-WP-0001-T06/T07) + 3 business days of verified runs. DEC-2026-002 resolved 2026-07-17 (agent-harness). Runbook: integrations/executor-cutover-runbook.md" priority: medium state_hub_task_id: "eb8c9860-49b4-4d9e-b242-fff48b2ef603" ```