tegwick
3b2edd4a9e
Enable kaizen agents to run on a regular cadence against a preselected repo roster, orchestrated by activity-core and prepared by kaizen-agentic — without this repo owning cron, Temporal workers, or an LLM runtime. CLI + module: - src/kaizen_agentic/schedule.py — .kaizen/schedule.yml parse/validate/scaffold - `kaizen-agentic schedule` group: init, validate, list, prepare <agent> (prepare bundles agent prompt + memory + metrics + repo pointers, offline) - tests/test_schedule_cli.py — 15 tests Contract & design: - ADR-005 scheduled agent execution; schema doc + example manifest - discover_kaizen_scheduled_repos resolver spec, state-hub roster fields, kaizen.schedule.prepared event payload, activity-core handoff checklist - INTEGRATION_PATTERNS Pattern 2 extended with roster model ActivityDefinition drafts (enabled: false): - weekly-coach-orientation, weekly-optimization-review Docs: agency-framework, CLI cheat sheet, PACKAGE_RELEASE runner prereqs, EcosystemIntegration, CHANGELOG, TODO. Workplan closed (status: done). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.4 KiB
State Hub Roster Fields for Kaizen Scheduling (Design)
Status: design only — implemented in the-custodian/state-hub, not here
(repo boundary). This document specifies what kaizen-agentic and activity-core
need from the hub so the State Hub team can add the fields and filter.
Problem
activity-core's resolver needs to answer: which registered repos participate in
kaizen fleet scheduling, and where do they live on disk? Today state-hub knows
the canonical repo list and host_paths but has no notion of schedule opt-in.
Existing hub data (sufficient for v1)
GET /repos/ already returns, per repo:
| Field | Use |
|---|---|
slug |
Canonical repo identifier (target_repo in tasks) |
host_paths[hostname] → local_path |
Where the repo is checked out on a runner |
domain |
Scope filter (e.g. custodian) |
For v1, opt-in is detected in the repo (.kaizen/schedule.yml exists and
validates). The resolver clones/reads each candidate path and checks for the
file. No hub schema change is strictly required to ship the pilot.
Proposed hub fields (v2, optional)
To let operators query eligibility without touching every checkout, add an optional repo-metadata flag:
| Field | Type | Default | Meaning |
|---|---|---|---|
kaizen_schedule_enabled |
bool | false |
Operator-confirmed fleet participation |
kaizen_schedule_updated_at |
timestamp | null | Last time schedule.yml was synced/seen |
Suggested filter
GET /repos/?kaizen_schedule_enabled=true&domain=custodian
Returns only schedule-eligible repos with their host_paths, so the resolver
skips repos that have not opted in — cheaper than scanning every checkout.
Write path
The flag is set by an operator (or a future kaizen-agentic schedule register
that calls the hub). It is advisory: the authoritative opt-in remains the
presence of a valid .kaizen/schedule.yml in the repo, re-checked by the
resolver at run time. The flag is an index, not a source of truth.
Boundary
- kaizen-agentic does not write these fields in WP-0006.
- state-hub schema migration is tracked in
the-custodian. - The resolver (activity-core) treats the hub flag as a pre-filter and the repo file as the decision.