hackmoded bootstrap: service lifecycle, local control boundary, and deterministic drain #26

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

Add the smallest Hackmode-owned daemon/bootstrap surface needed for one continuously running runtime owner. This slice does not yet migrate every actor family.

Scope

executable/entrypoint for hackmoded;
explicit configuration/init-file loading without ambient hidden runtime creation;
exactly one owned runtime instance per daemon process;
health/readiness status;
local control boundary suitable for LISH/Emacs/Nyxt clients;
explicit lifecycle states such as starting, ready, draining, stopped, failed;
deterministic shutdown/drain contract;
PID/process lifetime remains systemd/NixOS territory, not an actor scheduler.

Local control contract

Prefer a narrow typed local protocol over clients loading/starting their own actor systems. The protocol must be able to expose at least:

daemon/runtime status and generation;
operation list/select/open status;
actor/job/run inspection hooks;
provider dispatch through existing canonical APIs;
shutdown/drain request where policy permits.

Do not make the transport itself canonical business state. Unix socket/local IPC is acceptable if it cleanly maps typed protocol values; same-image callers may use the same Common Lisp protocol directly.

Drain semantics

Shutdown sequence must be explicit and testable:

transition to draining;
reject new long-running jobs/runs;
request operation-local actors to stop/yield;
flush/finish already accepted canonical writes/outbox work according to existing semantics;
stop/reap external processes;
stop actor runtime;
join/terminate runtime-owned resources;
exit cleanly.

RED-first tests

second runtime construction in one daemon is rejected or returns the existing instance according to the final API;
two clients observe the same daemon generation/state;
a control client disconnect does not stop the daemon;
drain rejects new work but allows bounded accepted work to finish/classify;
shutdown leaves no child process/thread/actor-system leak;
daemon restart produces a new runtime generation while canonical operation state remains available.

Fence

No direct database internals, no StarIntel product work, no replacement scheduler, and no client-owned actor-system lifecycle.

Dependencies

This can define the Hackmode-facing contract before every StarLang production primitive is final, but the normal production implementation must use the StarLang runtime boundary established by #150 rather than entrenching a second Hackmode-only runtime.

## Parent - Epic: #150 - ADR: #149 ## Outcome Add the smallest Hackmode-owned daemon/bootstrap surface needed for one continuously running runtime owner. This slice does not yet migrate every actor family. ## Scope - executable/entrypoint for `hackmoded`; - explicit configuration/init-file loading without ambient hidden runtime creation; - exactly one owned runtime instance per daemon process; - health/readiness status; - local control boundary suitable for LISH/Emacs/Nyxt clients; - explicit lifecycle states such as `starting`, `ready`, `draining`, `stopped`, `failed`; - deterministic shutdown/drain contract; - PID/process lifetime remains systemd/NixOS territory, not an actor scheduler. ## Local control contract Prefer a narrow typed local protocol over clients loading/starting their own actor systems. The protocol must be able to expose at least: - daemon/runtime status and generation; - operation list/select/open status; - actor/job/run inspection hooks; - provider dispatch through existing canonical APIs; - shutdown/drain request where policy permits. Do not make the transport itself canonical business state. Unix socket/local IPC is acceptable if it cleanly maps typed protocol values; same-image callers may use the same Common Lisp protocol directly. ## Drain semantics Shutdown sequence must be explicit and testable: 1. transition to `draining`; 2. reject new long-running jobs/runs; 3. request operation-local actors to stop/yield; 4. flush/finish already accepted canonical writes/outbox work according to existing semantics; 5. stop/reap external processes; 6. stop actor runtime; 7. join/terminate runtime-owned resources; 8. exit cleanly. ## RED-first tests - second runtime construction in one daemon is rejected or returns the existing instance according to the final API; - two clients observe the same daemon generation/state; - a control client disconnect does not stop the daemon; - drain rejects new work but allows bounded accepted work to finish/classify; - shutdown leaves no child process/thread/actor-system leak; - daemon restart produces a new runtime generation while canonical operation state remains available. ## Fence No direct database internals, no StarIntel product work, no replacement scheduler, and no client-owned actor-system lifecycle. ## Dependencies This can define the Hackmode-facing contract before every StarLang production primitive is final, but the normal production implementation must use the StarLang runtime boundary established by #150 rather than entrenching a second Hackmode-only runtime.

nsaspy referenced this issue

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

Typed curl-impersonate HTTP requester with IPX/capture integration #34

nsaspy referenced this issue

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

Versioned mitmproxy addon -> provider-neutral IPX spool contract #36

nsaspy referenced this issue

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

Supervised operation-scoped mitmproxy/mitmdump capture provider #37

nsaspy referenced this issue

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

Default HTTP capture + browser-profile egress for spawned providers #38