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>
This commit is contained in:
parent
89754611f0
commit
eea17a7abc
2 changed files with 108 additions and 3 deletions
105
integrations/llm-connect-executor-assessment.md
Normal file
105
integrations/llm-connect-executor-assessment.md
Normal file
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue