diff --git a/integrations/activity-core-wiring.md b/integrations/activity-core-wiring.md deleted file mode 100644 index f5c7cc2..0000000 --- a/integrations/activity-core-wiring.md +++ /dev/null @@ -1,44 +0,0 @@ -# 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. diff --git a/integrations/llm-connect-executor-assessment.md b/integrations/llm-connect-executor-assessment.md deleted file mode 100644 index e92a2d8..0000000 --- a/integrations/llm-connect-executor-assessment.md +++ /dev/null @@ -1,105 +0,0 @@ -# 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 df4c509..c50c75f 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: done +status: active --- 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: done +status: todo priority: medium ``` @@ -88,6 +88,6 @@ note + follow-up workplan proposal. Green lane (assessment only). ```task id: BINKY-WP-0003-T06 -status: done +status: todo priority: medium ```