Add reusable recon capability commands to the Common Lisp control plane #32

New issue

Open

opened 2026-08-16 05:23:25 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 05:23:25 +00:00

(Migrated from github.com)

Problem

Hackmode and Quasar both need reconnaissance capabilities, but provider implementations must not be duplicated per product. Quasar already has an authoritative Common Lisp control plane and typed command/event envelope (quasar.control.v1); recon should extend that boundary rather than live in browser JavaScript or a parallel RPC stack.

Current behavior

Quasar control-plane state/mutations are Common Lisp-owned after completed #5.
control-plane/src/protocol.lisp defines typed command/result/error/event envelopes and stable error codes.
actor infrastructure already exists under control-plane/src/actors/.
Hackmode is building typed provider/asset protocols in lost-rob0t/hackmode (#2, #6, #14).

Desired behavior

Expose a small provider-neutral recon capability layer in Quasar Common Lisp that can invoke reusable/local actors where possible.

Candidate commands (names may follow existing command conventions):

recon.start
recon.status
recon.cancel
recon.results

Inputs should be typed asset descriptors (domain/url/host/ip/etc.) plus capability/provider selection, not provider-specific browser payloads.

Architecture

prefer a shared Common Lisp provider package/protocol that Hackmode and Quasar can both depend on; if Hackmode's provider actors remain Hackmode-owned initially, define a narrow reusable package boundary before copying code
one Shodan/Censys/URLScan/etc implementation, multiple callers
actor/job execution remains local to the Common Lisp backend
Quasar protocol adapters translate command envelopes to provider-neutral calls
provider credentials stay server-side
results should be convertible to canonical StarIntel/Hackmode asset/document forms without callers learning vendor internals

Do not create separate quasar-shodan implementations when the same provider exists for Hackmode.

Dependencies

lost-rob0t/hackmode#6 canonical asset lifecycle
lost-rob0t/hackmode#2 provider actor ports
Quasar's existing control-plane protocol and actor supervisor

Acceptance criteria

at least one passive/free provider capability can be invoked through the real Quasar control plane
command returns a job/result identifier through the existing protocol envelope
status/cancel/result paths use existing Quasar error/result conventions
backend provider failure does not crash the control plane
no provider secret appears in events/results/browser payloads
provider implementation is reusable by Hackmode rather than copied

Verification

Common Lisp unit/integration test on the actual control-plane command path
fake provider success/failure/cancel tests
assert encoded result/event payloads contain no configured secret
cross-repo compatibility fixture proving the same provider result can enter Hackmode's canonical asset lifecycle

## Problem Hackmode and Quasar both need reconnaissance capabilities, but provider implementations must not be duplicated per product. Quasar already has an authoritative Common Lisp control plane and typed command/event envelope (`quasar.control.v1`); recon should extend that boundary rather than live in browser JavaScript or a parallel RPC stack. ## Current behavior - Quasar control-plane state/mutations are Common Lisp-owned after completed #5. - `control-plane/src/protocol.lisp` defines typed command/result/error/event envelopes and stable error codes. - actor infrastructure already exists under `control-plane/src/actors/`. - Hackmode is building typed provider/asset protocols in `lost-rob0t/hackmode` (#2, #6, #14). ## Desired behavior Expose a small provider-neutral recon capability layer in Quasar Common Lisp that can invoke reusable/local actors where possible. Candidate commands (names may follow existing command conventions): - `recon.start` - `recon.status` - `recon.cancel` - `recon.results` Inputs should be typed asset descriptors (domain/url/host/ip/etc.) plus capability/provider selection, not provider-specific browser payloads. ## Architecture - prefer a shared Common Lisp provider package/protocol that Hackmode and Quasar can both depend on; if Hackmode's provider actors remain Hackmode-owned initially, define a narrow reusable package boundary before copying code - one Shodan/Censys/URLScan/etc implementation, multiple callers - actor/job execution remains local to the Common Lisp backend - Quasar protocol adapters translate command envelopes to provider-neutral calls - provider credentials stay server-side - results should be convertible to canonical StarIntel/Hackmode asset/document forms without callers learning vendor internals Do **not** create separate `quasar-shodan` implementations when the same provider exists for Hackmode. ## Dependencies - lost-rob0t/hackmode#6 canonical asset lifecycle - lost-rob0t/hackmode#2 provider actor ports - Quasar's existing control-plane protocol and actor supervisor ## Acceptance criteria - at least one passive/free provider capability can be invoked through the real Quasar control plane - command returns a job/result identifier through the existing protocol envelope - status/cancel/result paths use existing Quasar error/result conventions - backend provider failure does not crash the control plane - no provider secret appears in events/results/browser payloads - provider implementation is reusable by Hackmode rather than copied ## Verification - Common Lisp unit/integration test on the actual control-plane command path - fake provider success/failure/cancel tests - assert encoded result/event payloads contain no configured secret - cross-repo compatibility fixture proving the same provider result can enter Hackmode's canonical asset lifecycle