Export Hackmode operation assets as StarIntel v0.9 documents #178

New issue

Open

opened 2026-09-05 02:02:51 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-05 02:02:51 +00:00

Owner

Outcome

Add an explicit, deterministic Hackmode export surface for canonical StarIntel v0.9 documents.

Hackmode already has per-asset v0.9 projection in source/hackmode-core/starintel-documents.lisp. This slice turns that existing projection into a usable operation/export boundary rather than inventing another schema.

Sequence after the first packaged CLI/flake work in #175 is reconciled.

Required behavior

export supported assets from one selected Hackmode operation;
use the existing asset->starintel-document / asset->starintel-json projection path;
produce canonical StarIntel v0.9 JSON documents with stable identity/provenance;
deterministic ordering for the same canonical operation state;
explicit handling/reporting of unsupported assets instead of silently pretending they exported;
support a machine-readable stdout/file form suitable for later ingestion and pipelines;
keep export separate from proof of remote acceptance/persistence;
preserve local-first operation when StarIntel Server is unavailable.

A CLI/LISH adapter may expose the capability once #175 is the canonical command surface, but the Common Lisp export function remains the authority.

Acceptance proof

Seed a deterministic operation with domain, resolvable host, URL, and one currently unsupported asset type.
Export the operation twice and prove byte-stable document ordering/content where timestamps/state are unchanged.
Every emitted document validates as the repository's pinned StarIntel v0.9 representation.
Domain/host/URL output uses the existing canonical projection functions rather than a parallel encoder.
Unsupported assets are reported explicitly and do not corrupt the export stream.
Export succeeds with no StarIntel Server reachable.
A transport send, when added separately, is not reported as accepted persistence without the existing durable outbox/ack semantics.

Fence

This is Hackmode integration/export work, not ordinary StarIntel product development. Do not change StarIntel's schema to make Hackmode data fit; adapt Hackmode through the canonical v0.9 interface.

## Outcome Add an explicit, deterministic Hackmode export surface for canonical StarIntel v0.9 documents. Hackmode already has per-asset v0.9 projection in `source/hackmode-core/starintel-documents.lisp`. This slice turns that existing projection into a usable operation/export boundary rather than inventing another schema. Sequence after the first packaged CLI/flake work in #175 is reconciled. ## Required behavior - export supported assets from one selected Hackmode operation; - use the existing `asset->starintel-document` / `asset->starintel-json` projection path; - produce canonical StarIntel v0.9 JSON documents with stable identity/provenance; - deterministic ordering for the same canonical operation state; - explicit handling/reporting of unsupported assets instead of silently pretending they exported; - support a machine-readable stdout/file form suitable for later ingestion and pipelines; - keep export separate from proof of remote acceptance/persistence; - preserve local-first operation when StarIntel Server is unavailable. A CLI/LISH adapter may expose the capability once #175 is the canonical command surface, but the Common Lisp export function remains the authority. ## Acceptance proof 1. Seed a deterministic operation with domain, resolvable host, URL, and one currently unsupported asset type. 2. Export the operation twice and prove byte-stable document ordering/content where timestamps/state are unchanged. 3. Every emitted document validates as the repository's pinned StarIntel v0.9 representation. 4. Domain/host/URL output uses the existing canonical projection functions rather than a parallel encoder. 5. Unsupported assets are reported explicitly and do not corrupt the export stream. 6. Export succeeds with no StarIntel Server reachable. 7. A transport send, when added separately, is not reported as accepted persistence without the existing durable outbox/ack semantics. ## Fence This is Hackmode integration/export work, not ordinary StarIntel product development. Do not change StarIntel's schema to make Hackmode data fit; adapt Hackmode through the canonical v0.9 interface.

nsaspy referenced this issue

2026-09-05 02:16:53 +00:00

agent-zero: restore two Hackmode development workers #180

nsaspy referenced this issue

2026-09-05 08:07:21 +00:00

[EPIC][module-lish] Native LISH module console: search, use, info, options, run, jobs, and sessions #193

nsaspy referenced this issue

2026-09-05 08:07:21 +00:00

[EPIC][module-framework] Native Hackmode security module framework with Metasploit-inspired concepts #197