Kickside engine root — threads, events, projections, hydration, retention, lifecycle reaping, thread notifications, proc supervision, execution identity

BUSL-1.1 3.6k downloads
Updated 2 days ago Repository
kicksidethreadseventsprojectionsschedulerengine

Run

wippy run kickside/core

Kickside Core

Append-only thread/event engine for Wippy. Threads are immutable event logs; projections derive views over them. Thread hydration backfills externally-sourced threads, retention sweeps expired ones, the lifecycle reaper tears down owned subtrees, and thread notifications fan out changes. The projection-cursor scheduler and the durable job/effect engine that advance projections live in the sibling kickside/jobs module.

Access control is delegated entirely to the kickside.component:component_service contract (group resolution included); core never touches the component tables directly. The threads slice registers each thread as a component, gates every read/write on the contract's access context, and removes the component on delete.

Slices (src/)

| Slice | Responsibility | |---|---| | threads | Thread + event aggregate, including thread hydration/backfill; implements the kickside.core:threads contract; access via the component contract. | | projections | Derived views, cursors, catch-up, projection-worker execution (inline + proc-runner). | | retention | Per-thread retention policy and sweeper. | | lifecycle | Owner-delete cascade reaper. |

Dependency interface

The host wires these ns.requirements via ns.dependency:

  • target_db — required SQL database for all kickside_* tables and all runtime persistence, routed through the module's injected db_config.

Child slices declare their own required process-host, router, and security-scope requirements where needed.

The threads slice additionally consumes the kickside.component:component_service contract (the component module is a sibling dependency) for ownership, access, and hierarchy.

Testing

wippy test

The standalone application harness (../test/) provisions an in-memory database, a process host, a permissive scope, and the component module, then runs its harness-owned suites. Suites also run against PostgreSQL by pointing target_db at a db.sql.postgres resource.