Supervised operation-scoped mitmproxy/mitmdump capture provider #37

New issue

Open

opened 2026-09-02 17:24:36 +00:00 by nsaspy · 0 comments

nsaspy commented

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

Owner

Outcome

Implement the process/provider half of #26/#133: Hackmode can start, supervise, inspect, and stop one operation-scoped mitmdump capture service with stable capture-session identity.

Owning RAGE lane

Provider/runtime/tool worker.

Fence

Do not write Tek9 directly. Do not move persistence into Python. Do not implement Hackpert reasoning here. Database-owned HTTP/checkpoint/quarantine/rotation records remain canonical.

Dependencies

parent #26
transport/policy umbrella #133
existing typed HTTP/capture persistence on current master

Typed lifecycle

Expose at least :stopped, :starting, :running, :degraded, :failed, :stopping, plus operation ID, capture-session ID, endpoint, process identity, spool identity, version, and failure classification.

Required behavior

spawn mitmdump with explicit operation/capture configuration;
isolate process crashes from operation runtime;
bounded restart policy and clean shutdown;
never silently downgrade an operation to uncaptured HTTP when policy requires capture;
expose endpoint/configuration to compatible providers;
capture service may remain running even when individual tools use tunnel/direct modes;
no arbitrary target fan-out or active probing is introduced by merely starting capture.

RED-first tests

Fake process runner proves lifecycle transitions, crash isolation, restart exhaustion, explicit stop, stable capture-session identity, and no Tek9 write path in the addon/provider.

Acceptance proof

Start an authorized operation capture session, observe typed running state, route deterministic fixture HTTP through it, stop/restart without losing session/provenance semantics, and prove a crashed mitmdump does not kill the operation runtime.

## Outcome Implement the process/provider half of #26/#133: Hackmode can start, supervise, inspect, and stop one operation-scoped `mitmdump` capture service with stable capture-session identity. ## Owning RAGE lane Provider/runtime/tool worker. ## Fence Do not write Tek9 directly. Do not move persistence into Python. Do not implement Hackpert reasoning here. Database-owned HTTP/checkpoint/quarantine/rotation records remain canonical. ## Dependencies - parent #26 - transport/policy umbrella #133 - existing typed HTTP/capture persistence on current master ## Typed lifecycle Expose at least `:stopped`, `:starting`, `:running`, `:degraded`, `:failed`, `:stopping`, plus operation ID, capture-session ID, endpoint, process identity, spool identity, version, and failure classification. ## Required behavior - spawn `mitmdump` with explicit operation/capture configuration; - isolate process crashes from operation runtime; - bounded restart policy and clean shutdown; - never silently downgrade an operation to uncaptured HTTP when policy requires capture; - expose endpoint/configuration to compatible providers; - capture service may remain running even when individual tools use tunnel/direct modes; - no arbitrary target fan-out or active probing is introduced by merely starting capture. ## RED-first tests Fake process runner proves lifecycle transitions, crash isolation, restart exhaustion, explicit stop, stable capture-session identity, and no Tek9 write path in the addon/provider. ## Acceptance proof Start an authorized operation capture session, observe typed running state, route deterministic fixture HTTP through it, stop/restart without losing session/provenance semantics, and prove a crashed mitmdump does not kill the operation runtime.