EPIC: Nyxt operator integration and OWASP ZAP provider pipeline #23

New issue

Open

opened 2026-08-25 07:39:29 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-25 07:39:29 +00:00

(Migrated from github.com)

Outcome

Provide the reusable Hackmode half of the Nyxt operator browser without moving personal browser configuration into this repository.

Tracker

#20 — Nyxt client over canonical Hackmode runtime/operation protocol
#21 — supervised typed OWASP ZAP API provider actor
#22 — ZAP alert -> canonical Hackmode finding/evidence -> StarIntel outbox

Consumer epic: https://github.com/lost-rob0t/dotfiles/issues/152
StarIntel contract coverage: https://github.com/lost-rob0t/starintel-server/issues/120

Boundary

Hackmode owns:

operation and asset state
typed findings/evidence metadata
actor/provider lifecycle
scan scope policy
ZAP API semantics and jobs
durable StarIntel synchronization/outbox

Nyxt/dotfiles owns:

synthwave visual system
browser statusline/panels/prompts
per-buffer proxy toggle
browser-page contextual commands
user endpoint/secret references

StarIntel Server owns:

central API/auth/authorization
canonical persisted central documents/targets/views

Required integrated proof

With a fake/local ZAP and fake StarIntel sink:

Nyxt client selects Hackmode operation.
Current URL is discovered as a typed asset.
ZAP passive alerts are queried through provider state.
Out-of-scope active scan is rejected.
Explicitly scoped scan becomes a cancellable Hackmode job.
Alert imports as a deduplicated finding with provenance.
StarIntel outage leaves finding durable locally/outboxed.
Reconnect synchronizes once without duplicate logical findings.

Invariants

local-first operation remains usable offline
no provider API keys leak to Nyxt presentation data/events
no direct ZAP JSON becomes canonical state without normalization
no new parallel operation database
provider failure cannot kill the operation runtime
active scanning is explicit and constrained to operation-authorized scope

## Outcome Provide the reusable Hackmode half of the Nyxt operator browser without moving personal browser configuration into this repository. ## Tracker - [ ] #20 — Nyxt client over canonical Hackmode runtime/operation protocol - [ ] #21 — supervised typed OWASP ZAP API provider actor - [ ] #22 — ZAP alert -> canonical Hackmode finding/evidence -> StarIntel outbox Consumer epic: https://github.com/lost-rob0t/dotfiles/issues/152 StarIntel contract coverage: https://github.com/lost-rob0t/starintel-server/issues/120 ## Boundary Hackmode owns: - operation and asset state - typed findings/evidence metadata - actor/provider lifecycle - scan scope policy - ZAP API semantics and jobs - durable StarIntel synchronization/outbox Nyxt/dotfiles owns: - synthwave visual system - browser statusline/panels/prompts - per-buffer proxy toggle - browser-page contextual commands - user endpoint/secret references StarIntel Server owns: - central API/auth/authorization - canonical persisted central documents/targets/views ## Required integrated proof With a fake/local ZAP and fake StarIntel sink: 1. Nyxt client selects Hackmode operation. 2. Current URL is discovered as a typed asset. 3. ZAP passive alerts are queried through provider state. 4. Out-of-scope active scan is rejected. 5. Explicitly scoped scan becomes a cancellable Hackmode job. 6. Alert imports as a deduplicated finding with provenance. 7. StarIntel outage leaves finding durable locally/outboxed. 8. Reconnect synchronizes once without duplicate logical findings. ## Invariants - local-first operation remains usable offline - no provider API keys leak to Nyxt presentation data/events - no direct ZAP JSON becomes canonical state without normalization - no new parallel operation database - provider failure cannot kill the operation runtime - active scanning is explicit and constrained to operation-authorized scope

nsaspy referenced this issue

2026-09-02 17:24:36 +00:00

Chain OWASP ZAP through canonical mitmproxy/IPX capture and correlate alerts #33

nsaspy commented

2026-09-02 17:24:43 +00:00

Owner

ZAP architecture follow-up is now split into #139. Keep #21/#22/#23 for ZAP-specific API, scope, scan jobs, alerts, and normalized findings; use #135/#136 canonical mitmproxy/IPX for HTTP traffic capture rather than adding a second ZAP HTTP-history authority.