binky-control/integrations/activity-core-wiring.md
tegwick 89754611f0 BINKY-WP-0003-T05: activity-core wiring — 3 proposed definitions landed
Deployment verified: production-backed on Railiance, issue-core REST sink,
TaskExecutorWorkflow still a stub (llm-connect's slot). Definitions landed
disabled in activity-core commit b2fa964; enablement needs the
binky_rhythm_status resolver + an executor.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-16 14:04:37 +02:00

44 lines
2.1 KiB
Markdown

# 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.