Extract runtime journal core into star-journal #31

Merged
lost-rob0t merged 9 commits from extract/runtime-journal-core into main 2026-08-15 14:32:24 +00:00
lost-rob0t commented 2026-08-15 14:30:08 +00:00 (Migrated from github.com)

Scope

Continue the one-authority extraction after PR #30 by moving the existing base runtime journal port/event/replay implementation out of prototype/runtime-journal-port-prototype.lisp into final star-journal.

Final authority

star-journal now owns:

  • runtime journal port construction and validation
  • append/replay operation boundaries
  • runtime journal event shape validation
  • lifecycle command validation through final star-actor-protocol
  • pending vs settled result rules
  • dispatcher sequence/clock replay ordering checks
  • defensive-copy behavior
  • in-memory journal backend
  • existing readable S-expression file backend
  • typed final journal failures

Compatibility

prototype/runtime-journal-port-prototype.lisp is reduced to a standalone loader, the historical runtime-journal-error compatibility condition, and thin delegates to final star-journal.

Prototype domain-remoting recovery code still owns replay interpretation, restoring dispatcher/gateway state, redelivery, terminal reconstruction, and remote recovery policy.

Deliberately preserved

The existing file journal remains readable S-expression persistence in this extraction. This PR does not silently change the persisted journal format to JSON merely because star-canonical-json is now final-owned. A persistence-format migration needs its own compatibility decision and fixtures.

Out of scope

  • domain-remoting journal orchestration
  • dispatcher terminal/idempotency store extraction
  • leases/fencing
  • runtime-directory extraction
  • supervision
  • new durable database backends

Extraction metrics

CI on final head 381eb07d19596d2d70bba2efd82c8fc5b6bbfd78 reports:

  • aggregate prototype/**/*.lisp: 19,664 → 19,550 LOC (-114)
  • prototype/runtime-journal-port-prototype.lisp: +34 / -148, net -114 lines
  • final star-journal/src/journal.lisp: 191 LOC

Validation

GitHub Actions is green:

  • independent target-system loading ✅
  • asdf:test-system :star-actor-protocol ✅
  • asdf:test-system :star-canonical-json ✅
  • asdf:test-system :star-journal ✅ in a fresh process without the prototype package
  • asdf:test-system :star-mailbox ✅
  • asdf:test-system :star-sento-compat ✅
  • asdf:test-system :starlang-runtime ✅
  • HTTP/scrape final tests ✅
  • asdf:test-system :starlang-prototype ✅ — 34 standalone scripts
  • generated interchange validation ✅
  • frozen canonical fixture/hash verification ✅
  • nix flake check --print-build-logs ✅

Remaining journal authority

Domain-remoting journal orchestration remains prototype-owned: event interpretation, gateway restoration, redelivery, terminal reconstruction, and dispatcher-state recovery. This PR does not duplicate those behaviors in star-journal.

Next slice

Proceed to the existing lease/fencing primitive boundary before runtime-directory/dispatcher extraction, unless repository evidence shows the lease code is inseparable from domain-remoting orchestration.

## Scope Continue the one-authority extraction after PR #30 by moving the existing base runtime journal port/event/replay implementation out of `prototype/runtime-journal-port-prototype.lisp` into final `star-journal`. ## Final authority `star-journal` now owns: - runtime journal port construction and validation - append/replay operation boundaries - runtime journal event shape validation - lifecycle command validation through final `star-actor-protocol` - pending vs settled result rules - dispatcher sequence/clock replay ordering checks - defensive-copy behavior - in-memory journal backend - existing readable S-expression file backend - typed final journal failures ## Compatibility `prototype/runtime-journal-port-prototype.lisp` is reduced to a standalone loader, the historical `runtime-journal-error` compatibility condition, and thin delegates to final `star-journal`. Prototype domain-remoting recovery code still owns replay interpretation, restoring dispatcher/gateway state, redelivery, terminal reconstruction, and remote recovery policy. ## Deliberately preserved The existing file journal remains readable S-expression persistence in this extraction. This PR does **not** silently change the persisted journal format to JSON merely because `star-canonical-json` is now final-owned. A persistence-format migration needs its own compatibility decision and fixtures. ## Out of scope - domain-remoting journal orchestration - dispatcher terminal/idempotency store extraction - leases/fencing - runtime-directory extraction - supervision - new durable database backends ## Extraction metrics CI on final head `381eb07d19596d2d70bba2efd82c8fc5b6bbfd78` reports: - aggregate `prototype/**/*.lisp`: **19,664 → 19,550 LOC (-114)** - `prototype/runtime-journal-port-prototype.lisp`: **+34 / -148**, net **-114 lines** - final `star-journal/src/journal.lisp`: **191 LOC** ## Validation GitHub Actions is green: - independent target-system loading ✅ - `asdf:test-system :star-actor-protocol` ✅ - `asdf:test-system :star-canonical-json` ✅ - `asdf:test-system :star-journal` ✅ in a fresh process without the prototype package - `asdf:test-system :star-mailbox` ✅ - `asdf:test-system :star-sento-compat` ✅ - `asdf:test-system :starlang-runtime` ✅ - HTTP/scrape final tests ✅ - `asdf:test-system :starlang-prototype` ✅ — **34 standalone scripts** - generated interchange validation ✅ - frozen canonical fixture/hash verification ✅ - `nix flake check --print-build-logs` ✅ ## Remaining journal authority Domain-remoting journal orchestration remains prototype-owned: event interpretation, gateway restoration, redelivery, terminal reconstruction, and dispatcher-state recovery. This PR does not duplicate those behaviors in `star-journal`. ## Next slice Proceed to the existing lease/fencing primitive boundary before runtime-directory/dispatcher extraction, unless repository evidence shows the lease code is inseparable from domain-remoting orchestration.
Sign in to join this conversation.
No description provided.