diff --git a/.kaizen/schedule.yml b/.kaizen/schedule.yml deleted file mode 100644 index 1af40d0..0000000 --- a/.kaizen/schedule.yml +++ /dev/null @@ -1,17 +0,0 @@ -# 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 diff --git a/DecisionQueue.md b/DecisionQueue.md index 3dd7d2b..0f3dee2 100644 --- a/DecisionQueue.md +++ b/DecisionQueue.md @@ -22,31 +22,7 @@ fallback_if_no_response: "" ## Open decisions -### 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." -``` +*(none)* ## Resolved decisions diff --git a/integrations/company-email-openbao.md b/integrations/company-email-openbao.md index 688b500..5c53540 100644 --- a/integrations/company-email-openbao.md +++ b/integrations/company-email-openbao.md @@ -97,15 +97,7 @@ 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-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`. +9. [ ] Recurring scan via activity-core (BINKY-WP-0003 follow-ons) ### Founder provision (step 6) — interactive human shell diff --git a/integrations/executor-cutover-runbook.md b/integrations/executor-cutover-runbook.md deleted file mode 100644 index cddff83..0000000 --- a/integrations/executor-cutover-runbook.md +++ /dev/null @@ -1,52 +0,0 @@ -# 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. diff --git a/integrations/executor-worker-secrets.md b/integrations/executor-worker-secrets.md deleted file mode 100644 index 6bcd514..0000000 --- a/integrations/executor-worker-secrets.md +++ /dev/null @@ -1,86 +0,0 @@ -# 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. diff --git a/integrations/llm-connect-executor-assessment.md b/integrations/llm-connect-executor-assessment.md index 2a4a5e0..e92a2d8 100644 --- a/integrations/llm-connect-executor-assessment.md +++ b/integrations/llm-connect-executor-assessment.md @@ -97,16 +97,6 @@ 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 diff --git a/workplans/BINKY-WP-0004-workstation-independent-executor.md b/workplans/BINKY-WP-0004-workstation-independent-executor.md index a6e44c0..d499ca4 100644 --- a/workplans/BINKY-WP-0004-workstation-independent-executor.md +++ b/workplans/BINKY-WP-0004-workstation-independent-executor.md @@ -2,7 +2,6 @@ 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, @@ -26,9 +25,8 @@ schedule file committed. Green/Blue lane. ```task id: BINKY-WP-0004-T01 -status: done +status: todo priority: high -state_hub_task_id: "5741487d-2022-4ed6-b4ad-8db745cb90f4" ``` ## Task: binky_rhythm_status resolver in activity-core @@ -42,9 +40,8 @@ or direct PR in that repo per its governance. Green lane (code + tests). ```task id: BINKY-WP-0004-T02 -status: done +status: todo priority: high -state_hub_task_id: "b44af058-22e4-4d63-a28c-8f6c69d65ea1" ``` ## Task: OpenBao lanes for the executor worker @@ -60,9 +57,8 @@ Catalog metadata only; any new secret provisioning is founder Red lane. ```task id: BINKY-WP-0004-T03 -status: done +status: todo priority: medium -state_hub_task_id: "e4740aa0-94f7-4ebe-9217-aaca3ef902cc" ``` ## Task: Executor worker MVP — one task end-to-end on Railiance @@ -77,9 +73,8 @@ Blue lane; deployment location Railiance. ```task id: BINKY-WP-0004-T04 -status: done +status: todo priority: high -state_hub_task_id: "3cb36d02-9934-4c80-81dd-589e7725e407" ``` ## Task: Recurring mailbox scan through the executor @@ -92,9 +87,8 @@ log). Blue lane. ```task id: BINKY-WP-0004-T05 -status: done +status: todo priority: medium -state_hub_task_id: "2fd2f523-5bd6-400f-abc1-45d3b0a8fcec" ``` ## Task: Cut over — enable Binky definitions, retire the cron bridge @@ -107,8 +101,6 @@ 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" +status: todo priority: medium -state_hub_task_id: "eb8c9860-49b4-4d9e-b242-fff48b2ef603" ```