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>
65 lines
2.4 KiB
Markdown
65 lines
2.4 KiB
Markdown
# 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.
|
|
|
|
## Related
|
|
|
|
- [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
|
|
- [schedule-schema.md](schedule-schema.md)
|
|
- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)
|