BINKY-WP-0004 T04/T05 done, T06 blocked with cutover runbook

- T04: executor-worker MVP (new repo ~/executor-worker) ran one task
  end-to-end: kaizen schedule-prepare persona, agentic llm-connect
  session, sandbox commit e043f21, hub progress event
- T05: recurring mailbox scan fully wired (two-phase: deterministic
  credentialed scan + LLM triage session with suspicious-mail log-only
  rule); email checklist item 9 now gated only on Lane 3 AppRole
- T06: blocked — gates are DEC-2026-002, Red-lane Lanes 2/3, Railiance
  deploy, 3 verified runs; runbook at
  integrations/executor-cutover-runbook.md

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

.kaizen/schedule.yml

@@ -0,0 +1,17 @@
+# Kaizen scheduled agent execution manifest (ADR-005)
+# Declares which agents run on what cadence in this repo.
+# Validate with: kaizen-agentic schedule validate
+version: '1'
+timezone: Europe/Berlin
+agents:
+  coach:
+    cadence: weekly
+    cron: 0 9 * * 1
+    enabled: true
+  optimization:
+    cadence: weekly
+    cron: 0 10 * * 1
+    enabled: true
+  tdd-workflow:
+    cadence: monthly
+    enabled: false

DecisionQueue.md

@@ -22,7 +22,31 @@ fallback_if_no_response: ""
 
 ## Open decisions
 
-*(none)*
+### DEC-2026-002 — Executor worker lives in a new small repo
+
+```yaml
+id: DEC-2026-002
+title: "Executor worker ownership: new thin repo (proposed name: executor-worker) vs. inside activity-core"
+lane: yellow
+status: prepared
+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."
+```
 
 ## Resolved decisions
 

integrations/company-email-openbao.md

@@ -97,7 +97,15 @@ Scan output under `mailmeta/` — metadata only (no message bodies in git).
        `mailmeta/reports/` (scan c3c7e784…). Notable: Stripe webhook
        failure notice, Qonto Beleg reminders, HUB31 correspondence,
        2 suspicious external mails (ignored, never acted on)
-9. [ ] Recurring scan via activity-core (BINKY-WP-0003 follow-ons)
+9. [~] Recurring scan via activity-core (BINKY-WP-0004 T05): fully wired —
+       `executor-worker mail-scan` (deterministic scan phase: AppRole or
+       ambient bao token → email-connect read-only → hub
+       `binky_mail_intake` event on success only) + triage session spec
+       (`~/executor-worker/examples/task-binky-mail-triage.json`, includes
+       the suspicious-mail log-only rule). Goes live once the founder
+       provisions the Lane 3 AppRole
+       (`integrations/executor-worker-secrets.md`) and T06 enables
+       `binky-weekly-mail-intake`.
 
 ### Founder provision (step 6) — interactive human shell
 

integrations/executor-cutover-runbook.md

@@ -0,0 +1,52 @@
+# Executor Cutover Runbook (BINKY-WP-0004-T06)
+
+> Status: prepared 2026-07-17 — execution blocked until the gates below
+> clear. Owner of the go decision: founder (Blue lane with founder
+> notification at cutover).
+
+## Gates (in order)
+
+1. **DEC-2026-002 resolved** (DecisionQueue.md) — executor worker home.
+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).
+
+## Cutover steps
+
+1. In activity-core, flip to `enabled: true` (its governance — commit in
+   that repo): `binky-daily-rhythm`, `binky-weekly-mail-intake`,
+   `binky-weekly-review-prep`. The `binky_rhythm_status` resolver is live
+   (activity-core b1eb5e6).
+2. Wire emitted tasks to the worker (issue-core sink poll or
+   TaskExecutorWorkflow — per DEC-2026-002 outcome).
+3. **Verification: three clean scheduled executions** (e.g. Thu daily,
+   Fri daily + review-prep, Mon daily + mail-intake ≈ 3 business days).
+   Clean = task emitted on schedule, worker committed, hub completion
+   event present (`binky_daily_brief` / `binky_mail_intake` /
+   `binky_weekly_review` with detail.repo=binky-control), no duplicate
+   briefs (resolver guard working).
+4. Remove the workstation crontab line
+   (`crontab -l | grep -v 'binky rhythm bridge' | crontab -`) and mark
+   the bridge section in OperatingRhythm.md **retired** with the date.
+5. Notify founder (daily brief "Progress" + this file updated to done).
+
+## Rollback
+
+Re-add the cron line from OperatingRhythm.md's bridge section and set the
+three definitions back to `enabled: false`. The bridge script stays in
+`scripts/rhythm-session.sh` untouched until one full month of clean
+executor operation.
+
+## Interim state (until gates clear)
+
+The workstation cron bridge remains the active daily-rhythm executor
+(installed 2026-07-16, `23 8 * * 1-5`). The executor completion events
+double as the bridge's future idempotence guard, so both may coexist
+briefly during verification without duplicate-brief risk only if the
+bridge is paused on days the executor is being verified — pause the
+bridge (comment the cron line) during step 3.

integrations/executor-worker-secrets.md

@@ -0,0 +1,86 @@
+# Executor Worker — 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)
+needs three credential lanes. One exists and is reusable; two need
+provisioning.
+
+## Lane 1 — LLM provider key: REUSE (verified)
+
+Warden catalog `openrouter-llm-connect` (active, resolvable, reviewed
+2026-07-02):
+
+- Path: `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets`
+- Field: `OPENROUTER_API_KEY`
+- Auth: any token carrying policy `workload-kv-read-llm-connect-provider-secrets`
+- 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
+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
+key.
+
+## Lane 2 — Forgejo deploy key: NEW (Red lane)
+
+No warden catalog entry exists (checked 2026-07-17; nearest match falls
+through to `key-cape-oidc-login`). The worker must push commits to target
+repos on forgejo (railiance01:30022), starting with a sandbox repo (T04),
+later binky-control (T06).
+
+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`
+   (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:
+   railiance-platform, risk: high).
+
+## Lane 3 — Non-interactive AppRole for company-email scan: NEW (Red lane)
+
+Blocker being closed: the existing OIDC role
+`binky-company-email-imap-workload-kv-read` is browser-interactive with a
+15-minute TTL — unusable for recurring scans (email-integration checklist
+item 9, `integrations/company-email-openbao.md`).
+
+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
+   `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.
+3. Deliver `role_id` + `secret_id` to the worker host via the
+   secrets-engine delivery mechanism (files `0600` on Railiance, outside any
+   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:
+   railiance-platform, risk: high) so the lane is discoverable and audited.
+
+Scan invocation stays exactly the manual pattern (read-only email-connect,
+values only ever in process env):
+config `integrations/mailbox-binky-company.yml`, reports to
+`mailmeta/reports/`.
+
+## Founder Red-lane summary
+
+- [ ] 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
+      role_id/secret_id to Railiance, catalog entry)
+- [x] Lane 1: nothing to do — reuse confirmed
+
+T04 (worker MVP) can start with Lane 1 alone plus a workstation-side dry
+run; Lanes 2–3 gate unattended operation, not development.

integrations/llm-connect-executor-assessment.md

@@ -97,6 +97,16 @@ Ownership note: items 1–5 span activity-core / kaizen-agentic / secrets-
 engine domains; the follow-up workplan in binky-control should track them
 as dependencies, with the implementation workplans living in those repos.
 
+## Ownership decision (2026-07-17, BINKY-WP-0004-T01)
+
+Recommendation recorded as **DEC-2026-002**: the executor worker lives in a
+**new small repo**, not inside activity-core or kaizen-agentic. ADR-005's
+boundaries exclude LLM invocation from both existing repos and explicitly
+defer "headless Claude Code / cloud agent runner integration" as a future,
+runner-agnostic concern — that future runner is exactly this worker.
+binky-control opted into kaizen scheduling on the same date
+(`.kaizen/schedule.yml`, coach + optimization weekly, tdd-workflow off).
+
 ## Verdict
 
 Feasible and well-aligned: every layer already exists or is an active

workplans/BINKY-WP-0004-workstation-independent-executor.md

@@ -2,6 +2,7 @@
 id: BINKY-WP-0004
 title: "Workstation-Independent Executor"
 status: active
+state_hub_workstream_id: "b800f91d-a377-45ec-8ff3-6e763c524dff"
 ---
 
 Remove the workstation from the autopilot loop. Successor to BINKY-WP-0003,
@@ -25,8 +26,9 @@ schedule file committed. Green/Blue lane.
 
 ```task
 id: BINKY-WP-0004-T01
-status: todo
+status: done
 priority: high
+state_hub_task_id: "5741487d-2022-4ed6-b4ad-8db745cb90f4"
 ```
 
 ## Task: binky_rhythm_status resolver in activity-core
@@ -40,8 +42,9 @@ or direct PR in that repo per its governance. Green lane (code + tests).
 
 ```task
 id: BINKY-WP-0004-T02
-status: todo
+status: done
 priority: high
+state_hub_task_id: "b44af058-22e4-4d63-a28c-8f6c69d65ea1"
 ```
 
 ## Task: OpenBao lanes for the executor worker
@@ -57,8 +60,9 @@ Catalog metadata only; any new secret provisioning is founder Red lane.
 
 ```task
 id: BINKY-WP-0004-T03
-status: todo
+status: done
 priority: medium
+state_hub_task_id: "e4740aa0-94f7-4ebe-9217-aaca3ef902cc"
 ```
 
 ## Task: Executor worker MVP — one task end-to-end on Railiance
@@ -73,8 +77,9 @@ Blue lane; deployment location Railiance.
 
 ```task
 id: BINKY-WP-0004-T04
-status: todo
+status: done
 priority: high
+state_hub_task_id: "3cb36d02-9934-4c80-81dd-589e7725e407"
 ```
 
 ## Task: Recurring mailbox scan through the executor
@@ -87,8 +92,9 @@ log). Blue lane.
 
 ```task
 id: BINKY-WP-0004-T05
-status: todo
+status: done
 priority: medium
+state_hub_task_id: "2fd2f523-5bd6-400f-abc1-45d3b0a8fcec"
 ```
 
 ## Task: Cut over — enable Binky definitions, retire the cron bridge
@@ -101,6 +107,8 @@ re-add the cron line. Blue lane with founder notification at cutover.
 
 ```task
 id: BINKY-WP-0004-T06
-status: todo
+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"
 priority: medium
+state_hub_task_id: "eb8c9860-49b4-4d9e-b242-fff48b2ef603"
 ```