Monorepo: make the Common Lisp runtime canonical for operation and asset state #6

New issue

Closed

opened 2026-08-16 04:53:02 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 04:53:02 +00:00

(Migrated from github.com)

Problem

The Common Lisp runtime and emacs-hackmode currently maintain separate operation/asset state. The runtime uses Tek9-backed operation databases and typed objects; Emacs uses files/directories plus direct BBRF commands. This guarantees drift and blocks reliable shell/server/Emacs collaboration.

Current behavior

Runtime:

source/hackmode-core/operations.lisp owns operation, *current-operation*, Tek9 operation registry, and per-operation *db*.
source/hackmode-core/objects.lisp owns typed Hackmode objects.
discovery hooks exist for findings/domains.

Emacs:

emacs/hackmode.el (migrated by #4) tracks current operation using ~/.local/share/hackmode/current-op and op-path.
assets are primarily BBRF shell calls with separate per-type hooks.

Desired behavior

The Common Lisp Hackmode runtime is canonical for operation and asset lifecycle. Emacs, LISH, and later server/Quasar clients call a stable Hackmode protocol/API instead of reimplementing state.

Architecture

Introduce the smallest useful protocol boundary around:

list/create/select/get operation
discover/normalize/store/query asset
publish asset-discovered event
query current operation/status

Do not duplicate StarIntel schemas; map Hackmode assets to the existing StarIntel document representation where possible.

Implementation scope

define protocol functions/types in Hackmode core
remove class-slot :allocation :class bugs from per-instance asset/operation state where necessary
add generalized asset discovery event instead of one callback family per asset type
keep Tek9 as local operation store unless inspection proves it cannot satisfy requirements
adapt Emacs to call the runtime asynchronously rather than direct BBRF/file state in a follow-up slice

Dependencies

Depends on #4 monorepo migration. Blocks CouchDB asset integration (#3), outbox ingest, shell pipelines, Emacs convergence, and Quasar reuse.

Acceptance criteria

one canonical operation model
one canonical typed asset lifecycle
dedupe key/canonical value is deterministic
discovered assets are persisted before publication
event subscription is generic by asset/event type
existing recon code can emit through the protocol without knowing storage internals

Verification

tests for create/select/reopen operation
tests for discover -> normalize -> dedupe -> store -> event
repeat discovery does not duplicate work/events unexpectedly
compatibility tests for existing domain/url/host objects

## Problem The Common Lisp runtime and `emacs-hackmode` currently maintain separate operation/asset state. The runtime uses Tek9-backed operation databases and typed objects; Emacs uses files/directories plus direct BBRF commands. This guarantees drift and blocks reliable shell/server/Emacs collaboration. ## Current behavior Runtime: - `source/hackmode-core/operations.lisp` owns `operation`, `*current-operation*`, Tek9 operation registry, and per-operation `*db*`. - `source/hackmode-core/objects.lisp` owns typed Hackmode objects. - discovery hooks exist for findings/domains. Emacs: - `emacs/hackmode.el` (migrated by #4) tracks current operation using `~/.local/share/hackmode/current-op` and `op-path`. - assets are primarily BBRF shell calls with separate per-type hooks. ## Desired behavior The Common Lisp Hackmode runtime is canonical for operation and asset lifecycle. Emacs, LISH, and later server/Quasar clients call a stable Hackmode protocol/API instead of reimplementing state. ## Architecture Introduce the smallest useful protocol boundary around: - list/create/select/get operation - discover/normalize/store/query asset - publish asset-discovered event - query current operation/status Do not duplicate StarIntel schemas; map Hackmode assets to the existing StarIntel document representation where possible. ## Implementation scope - define protocol functions/types in Hackmode core - remove class-slot `:allocation :class` bugs from per-instance asset/operation state where necessary - add generalized asset discovery event instead of one callback family per asset type - keep Tek9 as local operation store unless inspection proves it cannot satisfy requirements - adapt Emacs to call the runtime asynchronously rather than direct BBRF/file state in a follow-up slice ## Dependencies Depends on #4 monorepo migration. Blocks CouchDB asset integration (#3), outbox ingest, shell pipelines, Emacs convergence, and Quasar reuse. ## Acceptance criteria - one canonical operation model - one canonical typed asset lifecycle - dedupe key/canonical value is deterministic - discovered assets are persisted before publication - event subscription is generic by asset/event type - existing recon code can emit through the protocol without knowing storage internals ## Verification - tests for create/select/reopen operation - tests for discover -> normalize -> dedupe -> store -> event - repeat discovery does not duplicate work/events unexpectedly - compatibility tests for existing domain/url/host objects