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:
tegwick 2026-07-17 17:17:15 +02:00
parent ce14c254db
commit 02a8d293ab
3 changed files with 65 additions and 7 deletions

View file

@ -97,10 +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-0004 T03/T05; auth
blocker solved on paper — non-interactive AppRole lane designed in
`integrations/executor-worker-secrets.md`, provisioning is founder
Red lane)
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

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

View file

@ -77,7 +77,7 @@ 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"
```
@ -92,7 +92,7 @@ log). Blue lane.
```task
id: BINKY-WP-0004-T05
status: todo
status: done
priority: medium
state_hub_task_id: "2fd2f523-5bd6-400f-abc1-45d3b0a8fcec"
```
@ -107,7 +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"
```