DEC-2026-002 resolved: agent-harness (single shared runtime)

- DecisionQueue: moved to resolved log with rescoped outcome (three-layer
  model; binky-control = tenant #1); hub decision resolved
- Secret lanes doc: identifiers renamed executor-worker → agent-harness
  before any provisioning happens
- Cutover runbook + WP-0004-T06: gate 1 done; deployment gate now points
  at HARNESS-WP-0001-T06/T07 in the agent-harness repo

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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

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
 

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
 

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"
 ```