coulomb/binky-control
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
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

2.1 KiB
Raw Blame History

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.