Nyxt client: embed the canonical Hackmode operation/runtime protocol #20

New issue

Open

opened 2026-08-25 07:36:34 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-25 07:36:34 +00:00

(Migrated from github.com)

Goal

Make Nyxt a first-class Hackmode client without creating another operation/asset state store.

Architecture

Hackmode remains canonical for operations, typed assets, findings, jobs, actors, local Tek9 state, and the durable StarIntel outbox. Nyxt is a presentation/control adapter.

Preferred integration order:

embed/load the Hackmode Common Lisp runtime into Nyxt when dependency compatibility permits;
expose a narrow local protocol adapter if same-image loading is not viable;
do not shell out to BBRF or recreate operation directories/state in Nyxt.

This follows the monorepo boundary in the README and completed issue #6.

Nyxt-facing protocol

list/create/select current operation
operation status and outbox state
discover current URL/domain/IP as typed assets
query assets/findings for current operation
dispatch/cancel/status recon jobs
subscribe to operation/asset/job events
surface typed conditions rather than string-only errors

UI contract

The reusable client belongs in Hackmode; dotfiles owns the personal Nyxt composition/theme/keybindings.

Acceptance criteria

Nyxt can select an operation and observe the same canonical state as CL/LISH clients
current-page URL/domain can be submitted through discover-asset
no duplicate local state or BBRF authority is introduced
long-running jobs do not block the Nyxt UI
reconnect/reload preserves canonical operation state
tests use deterministic fake/in-memory runtime boundaries

Dependencies

completed #6 canonical operation/asset protocol
#12 durable StarIntel outbox where synchronization state is surfaced
#14 typed shell/job protocol where shared
#15 investigation views where queryable views are used

Non-goals

vendoring Nyxt into Hackmode
putting user theme/keybindings in this repo
duplicating StarIntel Server HTTP clients when a Hackmode runtime operation already exists

## Goal Make Nyxt a first-class Hackmode client without creating another operation/asset state store. ## Architecture Hackmode remains canonical for operations, typed assets, findings, jobs, actors, local Tek9 state, and the durable StarIntel outbox. Nyxt is a presentation/control adapter. Preferred integration order: 1. embed/load the Hackmode Common Lisp runtime into Nyxt when dependency compatibility permits; 2. expose a narrow local protocol adapter if same-image loading is not viable; 3. do not shell out to BBRF or recreate operation directories/state in Nyxt. This follows the monorepo boundary in the README and completed issue #6. ## Nyxt-facing protocol - list/create/select current operation - operation status and outbox state - discover current URL/domain/IP as typed assets - query assets/findings for current operation - dispatch/cancel/status recon jobs - subscribe to operation/asset/job events - surface typed conditions rather than string-only errors ## UI contract The reusable client belongs in Hackmode; dotfiles owns the personal Nyxt composition/theme/keybindings. ## Acceptance criteria - Nyxt can select an operation and observe the same canonical state as CL/LISH clients - current-page URL/domain can be submitted through `discover-asset` - no duplicate local state or BBRF authority is introduced - long-running jobs do not block the Nyxt UI - reconnect/reload preserves canonical operation state - tests use deterministic fake/in-memory runtime boundaries ## Dependencies - completed #6 canonical operation/asset protocol - #12 durable StarIntel outbox where synchronization state is surfaced - #14 typed shell/job protocol where shared - #15 investigation views where queryable views are used ## Non-goals - vendoring Nyxt into Hackmode - putting user theme/keybindings in this repo - duplicating StarIntel Server HTTP clients when a Hackmode runtime operation already exists