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>
This commit is contained in:
parent
ce14c254db
commit
02a8d293ab
3 changed files with 65 additions and 7 deletions
52
integrations/executor-cutover-runbook.md
Normal file
52
integrations/executor-cutover-runbook.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue