2026-07-17 17:17:15 +02:00
|
|
|
# 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)
|
|
|
|
|
|
2026-07-17 23:37:16 +02:00
|
|
|
1. ~~DEC-2026-002 resolved~~ **done 2026-07-17**: single shared
|
|
|
|
|
`agent-harness` repo (ADR-001 there); prototype adopted as its seed.
|
2026-07-18 11:07:12 +02:00
|
|
|
2. ~~Lane 2 + Lane 3 Red-lane provisioning~~ **done 2026-07-17**
|
|
|
|
|
(`integrations/executor-worker-secrets.md`): forgejo deploy key on
|
|
|
|
|
`coulomb/executor-sandbox` + AppRole `agent-harness-binky-mail` on
|
|
|
|
|
railiance01. **Still at cutover:** attach the same deploy key write
|
|
|
|
|
access to `coulomb/binky-control`.
|
|
|
|
|
3. ~~Harness on Railiance + tenant onboarding~~ **done 2026-07-18**:
|
|
|
|
|
HARNESS-WP-0001-T06 (image + k8s + host smoke) and T07 (instance
|
|
|
|
|
manifest + three definition runs). See
|
|
|
|
|
`integrations/harness-tenant-onboarding.md`.
|
2026-07-17 17:17:15 +02:00
|
|
|
|
|
|
|
|
## 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.
|
