From 4fa511ac5f2aa422456c49610a2cf29dfee46dfd Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Mon, 18 May 2026 23:30:00 +0200
Subject: History deletion: delete one entry (x) or clear everything (X)

Store had full CRUD for match-and-replace rules but no way to delete or
prune history at all - it only ever grew, with no way to remove an
accidental capture or start a new engagement clean short of manually
deleting the DB file outside the tool entirely.

internal/store: DeleteEntry(id) removes one history row and its
history_fts search index row in a transaction. ClearHistory() empties
both tables entirely; rules are untouched. internal/ipc: new
"delete_entry" and "clear_history" request types, Client.DeleteEntry/
ClearHistory methods.

TUI: 'x' deletes the selected history entry, 'X' clears the whole
database. Both gated behind a y/n confirmation - a small reusable
confirmPrompt/confirmYes model state, checked first in the history
list's key handling, so any key other than y/Y safely cancels rather
than falling through to whatever that key normally does elsewhere (this
also means ctrl+c during a pending confirmation cancels the prompt
rather than quitting - a deliberate fail-safe, not an oversight: quick
to dismiss, and a second ctrl+c then quits normally).

'X' is explicitly NOT scoped to an active search filter - it always
clears the true total (read from daemon status, not len(m.entries),
which would understate the count under a filter and make the
confirmation prompt itself misleading about what's about to happen).

Verified live in tmux against a running daemon with real captured
entries: 'x' shows "delete #N? y/n", 'n' cancels with the entry
untouched, 'y' deletes it and the list/count both refresh correctly;
'X' shows "clear all N history entries (not just this view)? y/n" with
the true count, 'y' empties the database (confirmed via direct SQLite
query: both history and history_fts at 0 rows afterward) and the TUI
correctly shows "history (0)" / "0 requests"; 'x'/'X' on an empty list
correctly no-op without crashing.

go build/vet/gofmt/test/mod tidy all clean.
---
 PLAN.md | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

(limited to 'PLAN.md')

diff --git a/PLAN.md b/PLAN.md
index edaf599..90a27fd 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -206,6 +206,45 @@ rather than hanging or crashing.
 
 This closes every item from the original "worth considering" list.
 
+## Post-audit hardening and history management
+
+A hands-on robustness audit (two parallel passes, backend and frontend,
+actually driving the daemon/TUI against adversarial input rather than
+reading code - "run it, don't read it") found and fixed six real bugs:
+raw ANSI/control-character injection from captured traffic reaching the
+operator's actual terminal (severe - confirmed a malicious Host value
+changed the real tmux pane title); a table-cursor desync that left
+enter/r/i/f/c inert on a live-captured entry until an unrelated
+navigation keypress; Intruder silently hanging 60s per payload on
+body-parameter fuzzing because Content-Length was never recalculated
+after marker substitution; match-and-replace rules accepting an invalid
+regex with zero validation or feedback, silently never firing; captures
+that hit the 10 MiB cap being marked "exact" anyway, hiding data loss
+from exactly the kind of investigation that needs the tail of a large
+body; and no timeouts anywhere, so a slow-loris connection or a client
+that completed CONNECT and never sent a TLS ClientHello held a
+connection and goroutine open forever. See commit history for full
+detail on each - every fix was verified against the actual failure
+mode, not just code-reviewed.
+
+Also added: history deletion. `Store` had full CRUD for rules but no
+way to delete or prune history - it only ever grew, with no way to
+remove an accidental capture or start fresh for a new engagement short
+of manually deleting the DB file outside the tool. `x` deletes the
+selected entry, `X` clears the entire database (explicitly not scoped
+to an active search filter - the confirmation always states the true
+total count, since understating it would make the prompt itself
+misleading about what's about to happen). Both gated behind a `y`/`n`
+confirmation: a small reusable confirmPrompt/confirmYes pattern in the
+TUI model, checked first in the history list's key handling, so any key
+other than y/Y safely cancels rather than falling through to whatever
+that key normally does.
+
+Still open from the expanded "worth considering" list: export/import
+(HAR, copy-as-curl), and scope/target filtering (to keep noise -
+trackers, CDNs, unrelated third-party hosts - out of history and
+search). Both requested explicitly; not started yet.
+
 Skipped deliberately (from the research, matches this tool's stated
 scope): active/passive vulnerability scanning, plugin marketplace,
 Collaborator/OAST, team collaboration, CI integration, client TLS
-- 
cgit v1.2.3