Monorepo: establish canonical layout and migrate Emacs + templates #4

New issue

Closed

opened 2026-08-16 04:52:43 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 04:52:43 +00:00

(Migrated from github.com)

Problem

Hackmode is split across lost-rob0t/hackmode, lost-rob0t/emacs-hackmode, lost-rob0t/hackmode-templates, lost-rob0t/hackmode-scripts, and archived legacy repos. This duplicates operation state and makes the runtime, shell, Emacs UI, templates, and tooling evolve independently.

Current behavior

hackmode owns the Common Lisp runtime, Tek9-backed operations/local DB, typed objects, recon code, hooks, and LISH integration.
emacs-hackmode independently models operations as directories plus ~/.local/share/hackmode/{current-op,op-path} and uses BBRF directly for asset state.
hackmode-templates is a separate tiny repo.
hackmode-scripts contains useful source plus generated binaries/FASLs that must not be blindly imported.

Desired behavior

lost-rob0t/hackmode is the canonical monorepo for Hackmode-owned code and assets. External StarIntel products/libraries (starintel-server, quasar, quasar-ui, tek9, dotfiles) remain separate and integrate through APIs/protocols rather than being vendored.

Architecture

Initial layout:

source/ — Common Lisp runtime and recon systems (existing)
emacs/ — Hackmode Emacs package migrated from emacs-hackmode
templates/ — operation templates migrated from hackmode-templates
tools/legacy/ — curated script sources only, migrated in a separate issue
docs/architecture/ — ownership and repository-boundary documentation

The Common Lisp runtime is the future canonical operation/asset state owner. Emacs becomes a client/interface instead of a second state implementation.

Implementation scope

Add monorepo ownership/layout documentation.
Migrate active Emacs package sources under emacs/.
Migrate operation templates under templates/.
Update root documentation to identify the canonical repo and migration policy.
Do not import generated binaries, FASLs, vendored tool executables, or archived-repo junk.

Dependencies

None. This is the repository-boundary foundation for subsequent operation/asset protocol work.

Acceptance criteria

hackmode contains the active Emacs package and templates.
Root docs define ownership of runtime, Emacs, templates, scripts, and external integrations.
No generated executable/FASL artifacts are imported.
Follow-up issues track script curation and canonical operation/asset protocol migration.

Verification

Inspect committed tree for expected paths.
Confirm migrated text files match source repositories for this slice.
Confirm no large generated binaries/FASLs are added.
Run any available repository checks/CI; if no CI exists, record that as a testing blocker.

## Problem Hackmode is split across `lost-rob0t/hackmode`, `lost-rob0t/emacs-hackmode`, `lost-rob0t/hackmode-templates`, `lost-rob0t/hackmode-scripts`, and archived legacy repos. This duplicates operation state and makes the runtime, shell, Emacs UI, templates, and tooling evolve independently. ## Current behavior - `hackmode` owns the Common Lisp runtime, Tek9-backed operations/local DB, typed objects, recon code, hooks, and LISH integration. - `emacs-hackmode` independently models operations as directories plus `~/.local/share/hackmode/{current-op,op-path}` and uses BBRF directly for asset state. - `hackmode-templates` is a separate tiny repo. - `hackmode-scripts` contains useful source plus generated binaries/FASLs that must not be blindly imported. ## Desired behavior `lost-rob0t/hackmode` is the canonical monorepo for Hackmode-owned code and assets. External StarIntel products/libraries (`starintel-server`, `quasar`, `quasar-ui`, `tek9`, `dotfiles`) remain separate and integrate through APIs/protocols rather than being vendored. ## Architecture Initial layout: - `source/` — Common Lisp runtime and recon systems (existing) - `emacs/` — Hackmode Emacs package migrated from `emacs-hackmode` - `templates/` — operation templates migrated from `hackmode-templates` - `tools/legacy/` — curated script sources only, migrated in a separate issue - `docs/architecture/` — ownership and repository-boundary documentation The Common Lisp runtime is the future canonical operation/asset state owner. Emacs becomes a client/interface instead of a second state implementation. ## Implementation scope 1. Add monorepo ownership/layout documentation. 2. Migrate active Emacs package sources under `emacs/`. 3. Migrate operation templates under `templates/`. 4. Update root documentation to identify the canonical repo and migration policy. 5. Do not import generated binaries, FASLs, vendored tool executables, or archived-repo junk. ## Dependencies None. This is the repository-boundary foundation for subsequent operation/asset protocol work. ## Acceptance criteria - `hackmode` contains the active Emacs package and templates. - Root docs define ownership of runtime, Emacs, templates, scripts, and external integrations. - No generated executable/FASL artifacts are imported. - Follow-up issues track script curation and canonical operation/asset protocol migration. ## Verification - Inspect committed tree for expected paths. - Confirm migrated text files match source repositories for this slice. - Confirm no large generated binaries/FASLs are added. - Run any available repository checks/CI; if no CI exists, record that as a testing blocker.