binky-control/integrations/executor-cutover-runbook.md
tegwick 7c5e644d6f 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>
2026-07-17 23:37:16 +02:00

2.5 KiB

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

  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.