Typed Hackmode shell: LISH pipelines over operations and assets #14

New issue

Open

opened 2026-08-16 05:19:59 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 05:19:59 +00:00

(Migrated from github.com)

Problem

Hackmode already contains isolated lish:defcommand usage, but it does not yet expose the operation/asset/recon runtime as a coherent typed shell. Most recon wrappers still collapse to strings or shell output.

Current behavior

Hackmode is Common Lisp and depends on the Yew/LISH stack.
at least the crt.sh recon adapter already defines a LISH command.
#6 established a canonical operation/local-store and typed asset lifecycle.
curated legacy scripts in tools/legacy/recon/ are migration inputs, not shell commands to wire directly.

Desired behavior

Build a real Hackmode shell inspired by LISH where commands accept/return structured Lisp/Hackmode objects and can compose without reparsing text.

Initial object vocabulary:

operation
domain
host
url
ip address/network
service/port
certificate
document
finding
actor/job/task

Initial command groups:

op new/open/status/list
asset constructors/selectors: domain, host, url, assets, findings
transforms/recon dispatch: resolve, dns, subdomains, ports, services, http, crawl, certs, search
persistence/sync: ingest, outbox, query, view
actor/job controls: actors, jobs, cancel, status

Conceptual pipeline:

domain example.com | subdomains | resolve | services | ingest

Each stage should consume/produce structured values; printing is a presentation concern at the terminal boundary.

Architecture

shell commands dispatch to canonical Hackmode protocols/providers rather than embed vendor implementations
long recon commands return job/stream handles or otherwise avoid blocking the interactive REPL unnecessarily
programmatic Common Lisp functions remain first-class; LISH commands are adapters
recursive asset discovery enters discover-asset and generic asset events, with dedupe preventing loops
no separate shell-only database/state

Dependencies

#6 canonical operation/asset protocol
#2 Common Lisp provider ports
#9 executable Common Lisp CI
#12 outbox for ingest

Acceptance criteria

operation commands use the same runtime state as library callers
at least one domain -> DNS/subdomain -> typed result pipeline works without string reparsing between stages
pipeline-produced assets can be persisted through discover-asset
provider failure is represented as a structured error/result and does not kill the shell
interactive long-running work does not lock out unrelated shell interaction when an async provider path exists
commands are directly callable/testable as Common Lisp functions

Verification

deterministic fixture pipeline test
direct Lisp invocation and LISH invocation yield equivalent typed results
failure/cancellation test
dedupe test when a pipeline rediscovers the same asset
no direct BBRF state dependency

## Problem Hackmode already contains isolated `lish:defcommand` usage, but it does not yet expose the operation/asset/recon runtime as a coherent typed shell. Most recon wrappers still collapse to strings or shell output. ## Current behavior - Hackmode is Common Lisp and depends on the Yew/LISH stack. - at least the crt.sh recon adapter already defines a LISH command. - #6 established a canonical operation/local-store and typed asset lifecycle. - curated legacy scripts in `tools/legacy/recon/` are migration inputs, not shell commands to wire directly. ## Desired behavior Build a real Hackmode shell inspired by LISH where commands accept/return structured Lisp/Hackmode objects and can compose without reparsing text. Initial object vocabulary: - operation - domain - host - url - ip address/network - service/port - certificate - document - finding - actor/job/task Initial command groups: - `op new/open/status/list` - asset constructors/selectors: `domain`, `host`, `url`, `assets`, `findings` - transforms/recon dispatch: `resolve`, `dns`, `subdomains`, `ports`, `services`, `http`, `crawl`, `certs`, `search` - persistence/sync: `ingest`, `outbox`, `query`, `view` - actor/job controls: `actors`, `jobs`, `cancel`, `status` Conceptual pipeline: `domain example.com | subdomains | resolve | services | ingest` Each stage should consume/produce structured values; printing is a presentation concern at the terminal boundary. ## Architecture - shell commands dispatch to canonical Hackmode protocols/providers rather than embed vendor implementations - long recon commands return job/stream handles or otherwise avoid blocking the interactive REPL unnecessarily - programmatic Common Lisp functions remain first-class; LISH commands are adapters - recursive asset discovery enters `discover-asset` and generic asset events, with dedupe preventing loops - no separate shell-only database/state ## Dependencies - #6 canonical operation/asset protocol - #2 Common Lisp provider ports - #9 executable Common Lisp CI - #12 outbox for `ingest` ## Acceptance criteria - operation commands use the same runtime state as library callers - at least one domain -> DNS/subdomain -> typed result pipeline works without string reparsing between stages - pipeline-produced assets can be persisted through `discover-asset` - provider failure is represented as a structured error/result and does not kill the shell - interactive long-running work does not lock out unrelated shell interaction when an async provider path exists - commands are directly callable/testable as Common Lisp functions ## Verification - deterministic fixture pipeline test - direct Lisp invocation and LISH invocation yield equivalent typed results - failure/cancellation test - dedupe test when a pipeline rediscovers the same asset - no direct BBRF state dependency