Emacs: replace duplicated file/BBRF state with an asynchronous Hackmode runtime client #17

New issue

Open

opened 2026-08-16 05:33:46 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 05:33:46 +00:00

(Migrated from github.com)

Problem

The Emacs package is now physically in the Hackmode monorepo, but it still maintains a second operation/asset model using ~/.local/share/hackmode/{current-op,op-path}, operation directories, target text files, and direct BBRF shell commands.

The Common Lisp runtime is now the canonical operation/asset authority (#6), so keeping this state in Emacs guarantees drift.

Current behavior

emacs/hackmode.el:

creates/switches operations independently from the CL operation registry
stores current operation in files
manages targets from .config/targets.txt
queries/mutates BBRF directly
uses synchronous shell-command-to-string for several operations

dotfiles now has a separate shared starintel.el client for StarIntel-level server operations; Hackmode-specific operation/recon UI should remain here, not move into dotfiles.

Desired behavior

Make Emacs a non-authoritative asynchronous client of the Hackmode runtime.

Initial UI/features:

operation list/create/select/status
assets tabulated buffer
findings tabulated buffer
asset-at-point/domain-at-point/URL-at-point/IP-at-point
send/discover asset
run recon capability/job
actor/job status and cancellation
outbox/ingest status + failed/quarantined inspection
teammate/presence status when collaboration lands
typed query interface
transient menus where useful

Architecture

Split the package along useful boundaries, not architecture theater:

emacs/hackmode.el — entrypoint/shared UI state
emacs/hackmode-operations.el
emacs/hackmode-assets.el
emacs/hackmode-recon.el
emacs/hackmode-shell.el when LISH integration needs Emacs glue

Transport must be asynchronous (make-process, network process, or async HTTP depending on the runtime/server boundary). Long recon work must return immediately with a process/job handle and update buffers asynchronously.

Compatibility BBRF commands may remain temporarily behind explicit compatibility names, but must stop being canonical state.

Dependencies

#6 canonical runtime protocol
#12 persistent outbox for ingest status UI
#14 typed shell/job protocol where shared
#13 collaboration for teammate status
lost-rob0t/dotfiles#67 / merged starintel.el for StarIntel-level server calls only

Acceptance criteria

operation selector reads runtime operation state, not directory enumeration
create/select operation mutates runtime state only
assets buffer is refreshable/tabulated/clickable
no network/recon command blocks Emacs input
BBRF is no longer the authoritative assets source
failed/quarantined ingest can be inspected without leaving Emacs
package loads without depending on dotfiles; optional starintel.el integration is one-way and non-circular

Verification

ERT with fake async transport for operation list/create/select
ERT assets buffer refresh/click action
long fake recon job proves Emacs remains responsive and receives completion update
assert canonical commands do not invoke shell-command-to-string/BBRF
manual smoke test against Hackmode runtime

## Problem The Emacs package is now physically in the Hackmode monorepo, but it still maintains a second operation/asset model using `~/.local/share/hackmode/{current-op,op-path}`, operation directories, target text files, and direct BBRF shell commands. The Common Lisp runtime is now the canonical operation/asset authority (#6), so keeping this state in Emacs guarantees drift. ## Current behavior `emacs/hackmode.el`: - creates/switches operations independently from the CL operation registry - stores current operation in files - manages targets from `.config/targets.txt` - queries/mutates BBRF directly - uses synchronous `shell-command-to-string` for several operations `dotfiles` now has a separate shared `starintel.el` client for StarIntel-level server operations; Hackmode-specific operation/recon UI should remain here, not move into dotfiles. ## Desired behavior Make Emacs a non-authoritative asynchronous client of the Hackmode runtime. Initial UI/features: - operation list/create/select/status - assets tabulated buffer - findings tabulated buffer - asset-at-point/domain-at-point/URL-at-point/IP-at-point - send/discover asset - run recon capability/job - actor/job status and cancellation - outbox/ingest status + failed/quarantined inspection - teammate/presence status when collaboration lands - typed query interface - transient menus where useful ## Architecture Split the package along useful boundaries, not architecture theater: - `emacs/hackmode.el` — entrypoint/shared UI state - `emacs/hackmode-operations.el` - `emacs/hackmode-assets.el` - `emacs/hackmode-recon.el` - `emacs/hackmode-shell.el` when LISH integration needs Emacs glue Transport must be asynchronous (`make-process`, network process, or async HTTP depending on the runtime/server boundary). Long recon work must return immediately with a process/job handle and update buffers asynchronously. Compatibility BBRF commands may remain temporarily behind explicit compatibility names, but must stop being canonical state. ## Dependencies - #6 canonical runtime protocol - #12 persistent outbox for ingest status UI - #14 typed shell/job protocol where shared - #13 collaboration for teammate status - `lost-rob0t/dotfiles#67` / merged `starintel.el` for StarIntel-level server calls only ## Acceptance criteria - operation selector reads runtime operation state, not directory enumeration - create/select operation mutates runtime state only - assets buffer is refreshable/tabulated/clickable - no network/recon command blocks Emacs input - BBRF is no longer the authoritative assets source - failed/quarantined ingest can be inspected without leaving Emacs - package loads without depending on dotfiles; optional `starintel.el` integration is one-way and non-circular ## Verification - ERT with fake async transport for operation list/create/select - ERT assets buffer refresh/click action - long fake recon job proves Emacs remains responsive and receives completion update - assert canonical commands do not invoke `shell-command-to-string`/BBRF - manual smoke test against Hackmode runtime