Migrate Hackmode actor authority from direct Sento construction to StarLang runtime #25

New issue

Open

opened 2026-09-02 17:24:35 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-02 17:24:35 +00:00

Owner

Parent

Epic: #150
ADR: #149

Outcome

Replace Hackmode's direct product-level Sento actor-system ownership with a StarLang-backed runtime adapter while preserving the existing provider/outbox semantics during migration.

Current state

Hackmode currently creates a Sento actor system directly in source/hackmode-core/actor-system.lisp, including :outbox and :providers dispatchers. source/hackmode-core/provider-actor.lisp creates Sento actors directly for the provider supervisor and per-invocation workers.

That is acceptable as the current implementation but not the target authority model from #149.

Target boundary

Hackmode product code should call a narrow runtime surface conceptually equivalent to:

create-hackmode-runtime(config)
load-hackmode-program(runtime, compiled-star-program)
start-hackmode-runtime(runtime)
resolve-hackmode-actor(runtime, logical-id)
tell/ask through StarLang actor refs
stop/shutdown-hackmode-runtime(runtime)

The concrete Sento backend, when used, stays behind final StarLang/star-sento-compat APIs.

Migration requirements

no big-bang provider rewrite;
preserve dispatch-capability as the canonical Hackmode capability/provider entrypoint;
preserve current typed provider inputs/results and persistence finalization behavior;
actor refs exposed to Hackmode callers are StarLang/runtime refs or Hackmode logical handles, not raw Sento refs;
restart/generation semantics reject stale refs rather than silently retargeting;
direct Sento production calls disappear from Hackmode actor ownership code as corresponding StarLang paths become proven;
temporary compatibility forwarding is allowed only when one semantic authority remains.

StarLang dependencies

Coordinate with:

lost-rob0t/star-lang#42 real actor-system semantic evidence;
lost-rob0t/star-lang#47 production/final runtime extraction;
Hackmode dogfood StarLang epic created from #149.

Do not locally reimplement missing StarLang supervision/journal/process semantics.

RED-first tests

static guard identifies direct Sento actor-system construction in Hackmode product paths selected for migration;
provider dispatch through the StarLang-backed adapter returns the same typed result as the current path;
actor lookup/ref generation changes across runtime restart and stale refs fail;
one provider failure does not terminate the runtime;
runtime shutdown tears down the selected concrete backend;
no raw Sento actor object escapes the new Hackmode runtime boundary.

Definition of done

Hackmode no longer treats ensure-hackmode-actor-system/direct actor-of construction as product actor authority. StarLang owns the semantic runtime path, while Sento remains an implementation adapter only where selected.

## Parent - Epic: #150 - ADR: #149 ## Outcome Replace Hackmode's direct product-level Sento actor-system ownership with a StarLang-backed runtime adapter while preserving the existing provider/outbox semantics during migration. ## Current state Hackmode currently creates a Sento actor system directly in `source/hackmode-core/actor-system.lisp`, including `:outbox` and `:providers` dispatchers. `source/hackmode-core/provider-actor.lisp` creates Sento actors directly for the provider supervisor and per-invocation workers. That is acceptable as the current implementation but not the target authority model from #149. ## Target boundary Hackmode product code should call a narrow runtime surface conceptually equivalent to: ```text create-hackmode-runtime(config) load-hackmode-program(runtime, compiled-star-program) start-hackmode-runtime(runtime) resolve-hackmode-actor(runtime, logical-id) tell/ask through StarLang actor refs stop/shutdown-hackmode-runtime(runtime) ``` The concrete Sento backend, when used, stays behind final StarLang/`star-sento-compat` APIs. ## Migration requirements - no big-bang provider rewrite; - preserve `dispatch-capability` as the canonical Hackmode capability/provider entrypoint; - preserve current typed provider inputs/results and persistence finalization behavior; - actor refs exposed to Hackmode callers are StarLang/runtime refs or Hackmode logical handles, not raw Sento refs; - restart/generation semantics reject stale refs rather than silently retargeting; - direct Sento production calls disappear from Hackmode actor ownership code as corresponding StarLang paths become proven; - temporary compatibility forwarding is allowed only when one semantic authority remains. ## StarLang dependencies Coordinate with: - `lost-rob0t/star-lang#42` real actor-system semantic evidence; - `lost-rob0t/star-lang#47` production/final runtime extraction; - Hackmode dogfood StarLang epic created from #149. Do not locally reimplement missing StarLang supervision/journal/process semantics. ## RED-first tests - static guard identifies direct Sento actor-system construction in Hackmode product paths selected for migration; - provider dispatch through the StarLang-backed adapter returns the same typed result as the current path; - actor lookup/ref generation changes across runtime restart and stale refs fail; - one provider failure does not terminate the runtime; - runtime shutdown tears down the selected concrete backend; - no raw Sento actor object escapes the new Hackmode runtime boundary. ## Definition of done Hackmode no longer treats `ensure-hackmode-actor-system`/direct `actor-of` construction as product actor authority. StarLang owns the semantic runtime path, while Sento remains an implementation adapter only where selected.

nsaspy referenced this issue

2026-09-02 17:24:37 +00:00

Implement Hackpert active engine orchestration and canonical state mutation #49

nsaspy referenced this issue

2026-09-02 17:24:37 +00:00

IPX passive traffic stack: capture proxy -> Hackpert graph -> StarIntel ingest #50

nsaspy referenced this issue

2026-09-02 17:24:37 +00:00

Integrate Hackpert as a Prolog expert layer over canonical Hackmode state #51

nsaspy referenced this issue

2026-09-02 17:24:43 +00:00

Integrate Hackpert as a Prolog expert layer over canonical Hackmode state #51