BINKY-WP-0003-T06: llm-connect executor assessment; workplan done

llm-connect = engine (adapter library), kaizen-agentic WP-0006/ADR-005 =
persona + schedule-prepare convention, activity-core = scheduler with a
stub TaskExecutorWorkflow. Missing piece: one thin executor worker on
Railiance. Follow-up workplan proposal (BINKY-WP-0004 candidate) included.
All six WP-0003 tasks done.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

integrations/activity-core-wiring.md

@@ -0,0 +1,44 @@
+# Binky Rhythm → activity-core Wiring
+
+> Status: proposed definitions landed — 2026-07-16 (BINKY-WP-0003-T05).
+
+## Deployment state (verified 2026-07-16)
+
+activity-core is an **active, production-backed service on Railiance**
+(Temporal Schedules + NATS event router + FastAPI admin, PostgreSQL;
+`~/activity-core/SCOPE.md` "Current State"). Task emission goes to the
+**issue-core REST sink** (`ISSUE_SINK_TYPE=rest` in the Railiance runtime
+ConfigMap; API key via ExternalSecret from OpenBao). Two open gates:
+daily-triage calibration (ACTIVITY-WP-0006) and the coding-retro upstream
+(ACTIVITY-WP-0008). Crucially, **`TaskExecutorWorkflow` is a stub** —
+activity-core schedules and emits tasks but nothing executes them yet.
+That executor slot is what the llm-connect assessment (T06) targets.
+
+## What was landed
+
+Three definitions in `~/activity-core/activity-definitions/` (commit
+`b2fa964`), all `status: proposed`, `enabled: false`, validated against
+activity-core's `definition_parser`:
+
+| id | schedule (Europe/Berlin) | replaces |
+|----|--------------------------|----------|
+| `binky-daily-rhythm` | weekdays 08:23 | workstation cron bridge (`scripts/rhythm-session.sh`) |
+| `binky-weekly-mail-intake` | Mon 09:37 | manual AWQ-008 trigger |
+| `binky-weekly-review-prep` | Fri 16:43 | founder self-reminder |
+
+## Enablement dependencies (in order)
+
+1. **`binky_rhythm_status` state-hub resolver** — small addition to
+   `activity-core/src/activity_core/context_resolvers/state_hub.py`
+   returning due-items for kinds `daily_brief`, `mail_intake`,
+   `weekly_review`. No generic "fire unconditionally" resolver exists, so
+   this is required; it also gives idempotence (no duplicate briefs).
+2. **Executor** — emitted tasks land in issue-core; execution needs
+   llm-connect (T06 assessment → follow-up workplan) or, interim, the
+   workstation bridge picking tasks up.
+3. **Enable flip** — set `enabled: true` per definition, sync, and remove
+   the corresponding workstation cron line (OperatingRhythm.md bridge
+   section) in the same change.
+
+Governance: definitions carry `governance: custodian`; enabling follows
+activity-core's own workplan process, not this repo's.

integrations/llm-connect-executor-assessment.md

@@ -0,0 +1,105 @@
+# llm-connect as Workstation-Independent Executor — Assessment
+
+> Status: v1 — 2026-07-16 (BINKY-WP-0003-T06). Green-lane assessment only.
+> Founder note (2026-07-16): "llm-connect should enable real automated work
+> based on activity-core independently from this workstation. This will
+> hopefully connect well with kaizen-agentic, too."
+
+## What each piece actually is (verified against the repos)
+
+- **activity-core** (`~/activity-core`, production-backed on Railiance):
+  owns *when/what/where*. Temporal Schedules fire ActivityDefinitions,
+  rules emit tasks into the **issue-core REST sink**. Its
+  `TaskExecutorWorkflow` is explicitly a **stub** — there is a designed but
+  empty executor slot. The three Binky rhythm definitions are already
+  landed there, disabled (see `activity-core-wiring.md`).
+- **llm-connect** (`~/llm-connect`, pre-release 0.1.0): a **Python client
+  library**, not a service — a provider-neutral `LLMAdapter` layer
+  (OpenAI, Gemini, OpenRouter, Anthropic-compatible, and a
+  `ClaudeCodeAdapter` that shells out to the installed `claude` CLI).
+  Its own SCOPE rules out "a complete application-level agent framework"
+  and secret storage. So llm-connect is the *engine block*, not the car:
+  the executor is a small new service that *uses* llm-connect.
+- **kaizen-agentic** (`~/kaizen-agentic`, v1.1.0): agent personas
+  (markdown instruction sets) + project memory + Custodian MCP lookup
+  (`get_kaizen_agent`). Explicitly does **not** own runtime execution.
+  Its **active WP-0006 (with ADR-005) targets "scheduled agent execution
+  via activity-core"** — the convergence the founder hopes for is already
+  an active workstream on the kaizen side. Design (per
+  `wiki/EcosystemIntegration.md`): a repo opts in by committing
+  `.kaizen/schedule.yml` (`kaizen-agentic schedule init`); activity-core
+  fires the cron (resolver spec `discover-kaizen-scheduled-repos`, handoff
+  checklist in `docs/integrations/`) and creates one task per
+  `(repo, agent)` that runs `kaizen-agentic schedule prepare <agent>`.
+  Note the verb: *prepare*, not execute — kaizen assembles persona +
+  context, and runtime execution remains Claude Code's job. llm-connect is
+  ranked P3 in kaizen's own integration list, "when Coach/optimizer
+  synthesis becomes automated beyond CLI context assembly" — i.e. exactly
+  the executor-worker scenario below.
+
+## Architecture that falls out
+
+The missing piece is one thin service — call it the **executor worker** —
+deployable on Railiance (workstation-independent):
+
+```text
+activity-core (Temporal, Railiance)
+   └─ definition fires → rule emits task → issue-core REST sink
+        └─ executor worker (new, small; implements TaskExecutorWorkflow
+           or polls issue-core)
+             ├─ persona: get_kaizen_agent(name) via dev-hub MCP / HTTP
+             ├─ engine: llm-connect adapter
+             │    • ClaudeCodeAdapter where the claude CLI exists
+             │    • hosted-API adapters (OpenAI/Gemini/OpenRouter/…)
+             │      for CLI-less container runtime
+             ├─ secrets: OpenBao via secrets-engine exec-time delivery
+             │    (API keys; company-email creds for mail-triage tasks —
+             │     same lane as integrations/company-email-openbao.md)
+             └─ output: git commits to target_repo (forgejo), progress
+                events + task closes to State Hub
+```
+
+Design points:
+1. **Don't grow llm-connect into an agent framework** — its SCOPE forbids
+   it. The worker composes llm-connect + kaizen persona + repo checkout.
+2. **Task contract**: emitted tasks already carry `target_repo`,
+   `task_template`, `description`, `labels` — enough to select persona
+   (label → agent name mapping) and workspace.
+3. **Secrets**: worker gets provider API keys and repo credentials via
+   OpenBao/secrets-engine AppRole — no keys in configs. This is the same
+   plumbing T01 prepares, so the two integrations reinforce each other.
+4. **Autonomy guard**: the worker must enforce lanes the way
+   `scripts/rhythm-session.sh` does (Green/Blue only, no push beyond its
+   target repo, bounded effort) — policy text lives in the persona +
+   AutonomyPolicy.md, enforcement in the worker's tool allow-list.
+5. **Model choice** through llm-connect config (TOML) keeps cost policy
+   (Token Budget) adjustable per task label without code changes.
+
+## Gaps → follow-up workplan proposal (BINKY-WP-0004 candidate)
+
+Draft tasks, in dependency order:
+1. Opt binky-control into kaizen scheduling (`.kaizen/schedule.yml` via
+   `kaizen-agentic schedule init`) and align executor-worker ownership
+   with kaizen WP-0006/ADR-005 (likely home: a new small repo or
+   activity-core's TaskExecutorWorkflow, per that WP's handoff checklist).
+2. Implement `binky_rhythm_status` resolver in activity-core (unblocks the
+   three landed Binky definitions).
+3. Executor worker MVP: consume one emitted task end-to-end on Railiance —
+   persona load, llm-connect ClaudeCodeAdapter or hosted adapter, commit
+   to binky-control, hub progress event (dry-run/sandbox repo first).
+4. OpenBao lanes for the worker (provider API key + forgejo deploy key)
+   via secrets-engine catalog entries.
+5. Enable `binky-daily-rhythm`, remove the workstation cron bridge line.
+6. Then: email-triage task type (joins T01's mailbox lane with the
+   executor — real-world events driving real automated work).
+
+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.
+
+## Verdict
+
+Feasible and well-aligned: every layer already exists or is an active
+workstream in its own domain; the only genuinely new code is a thin
+executor worker plus one context resolver. Binky-control's role is
+integrator and first customer, not implementor.

workplans/BINKY-WP-0003-autopilot-and-rhythm.md

@@ -1,7 +1,7 @@
 ---
 id: BINKY-WP-0003
 title: "Autopilot Execution & Recurring Rhythm"
-status: active
+status: done
 ---
 
 Turn the operating rhythm from pull-based (founder-initiated sessions) into
@@ -72,7 +72,7 @@ state and where dispatched work items land. Green/Blue lane.
 
 ```task
 id: BINKY-WP-0003-T05
-status: todo
+status: done
 priority: medium
 ```
 
@@ -88,6 +88,6 @@ note + follow-up workplan proposal. Green lane (assessment only).
 
 ```task
 id: BINKY-WP-0003-T06
-status: todo
+status: done
 priority: medium
 ```