Add kaizen context resolver for scheduled agent fleet discovery.

Implement discover_kaizen_scheduled_repos and discover_kaizen_projects per
kaizen-agentic ADR-005 contract: State Hub roster, roster.yaml filter, schedule
validation, and prepare_command emission. Register kaizen/resolver/shell source
types with unit tests and runbook dry-run instructions.
This commit is contained in:
2026-06-18 07:46:46 +02:00
parent 29bf87a44c
commit 517bf9c133
6 changed files with 560 additions and 5 deletions

View File

@@ -159,14 +159,34 @@ repos, and emits one automated task per stale repo through explicit
`weekly-coding-retro` follows the same cron -> context resolver -> per-repo task
pattern for coding-session retrospection. It runs Saturdays at 19:00
Europe/Berlin and resolves the latest State Hub `/progress/` item with
`event_type=coding_retro` into `context.retro.suggestions`. Each positive-score
suggestion emits one task to `context.s.repo` with labels
`coding-retro`, `improvement`, and `automated`.
`event_type=coding_retro` and a matching `window_days` into
`context.retro.suggestions`. Each positive-score suggestion emits one task to
`context.s.repo` with labels `coding-retro`, `improvement`, and `automated`.
The weekly schedule intentionally ignores broader retro windows such as 30-day
catch-up reports.
Keep `weekly-coding-retro` disabled until Helix Forge publishes the
`coding_retro` read model and a smoke run confirms the resolver returns a
non-empty suggestion set with no duplicate target tasks on re-run.
## Ops inventory evidence posture
The current accepted live backend for activity-core ops inventory probes is
State Hub progress with `event_type=ops_inventory_probe`.
Inter-Hub / ops-hub per-entity submission remains intentionally deferred until
all of these are true:
- `OPS_HUB_KEY` is provisioned through an operator-owned secret path, never Git,
chat, or State Hub detail.
- Widget or capability mapping is configured for the target ops-hub entities.
- Production Inter-Hub intake is deployed and smoke-tested for the relevant
authenticated routes.
Until then, missing Inter-Hub configuration should produce an explicit skipped
sink result, not a failed probe. This posture was recorded in State Hub decision
`7c235bbb-ee6f-4c3e-b1dd-74717eac9082`.
---
## Temporal UI — filtering by activity
@@ -342,6 +362,14 @@ uv run alembic history # show full migration history
## Railiance Deployment
### Production API access posture
The FastAPI admin surface remains ClusterIP-only in production. Do not publish
it through an external ingress until a separate access-policy work item chooses
the hostname, authentication layer, allowed users/agents, and audit
expectations. This posture was recorded in State Hub decision
`9ffaf7a9-227a-4e39-92e3-cd93d8cda1f2`.
### Pre-requisites
- Docker ≥ 24 with Compose v2 (`docker compose` not `docker-compose`)
- ≥ 4 GB RAM available (Temporal server takes ~1 GB)
@@ -412,6 +440,31 @@ make railiance-up
---
## Kaizen fleet resolver (coulomb-loop)
Dry-run scheduled agent discovery against State Hub + pilot roster:
```bash
export STATE_HUB_URL=http://127.0.0.1:8000
export KAIZEN_RUNNER_HOST=$(hostname)
export ACTIVITY_DEFINITION_DIRS=/home/worsch/coulomb-loop
uv run python -c "
from activity_core.context_resolvers.kaizen import discover_kaizen_scheduled_repos
print(discover_kaizen_scheduled_repos({
'roster': '/home/worsch/coulomb-loop/loops/kaizen-stack/roster.yaml',
'cadence': 'daily',
}))
"
make sync-activity-definitions # requires ACTCORE_DB_URL + stack up
```
Source types: `kaizen`, `resolver`, or `shell` (alias). Queries:
`discover_kaizen_scheduled_repos`, `discover_kaizen_projects`.
---
## Wipe and restart dev stack
```bash