diff --git a/integrations/llm-connect-executor-assessment.md b/integrations/llm-connect-executor-assessment.md new file mode 100644 index 0000000..e92a2d8 --- /dev/null +++ b/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 `. + 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. diff --git a/workplans/BINKY-WP-0003-autopilot-and-rhythm.md b/workplans/BINKY-WP-0003-autopilot-and-rhythm.md index c50c75f..df4c509 100644 --- a/workplans/BINKY-WP-0003-autopilot-and-rhythm.md +++ b/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 ```