Retest queue items never transition to completed — TUI shows stale pending items

[badchars]

Bug Summary

During web penetration testing, the retest queue accumulates pending items in the TUI but never clears them after inspection is complete. The agent claims items are processed ("should be cleared now") but the TUI still shows all items as pending.

Root Cause

WebRetest.updateStatus() and WebRetest.next() are defined in packages/cyberstrike/src/session/web/web-retest.ts but never called from anywhere in the codebase. The retest queue lifecycle is incomplete:

• Enqueue works: WebRetest.checkTriggers() is called from web-write-object-value.ts:54 and web-write-role.ts:54, creating items with status: "pending"
• TUI display works: WebRetest.getPending() and WebRetest.count() are read by the server route (session.ts:1022-1023) and web_get_session_context tool
• Consumption is broken: No code ever calls updateStatus(id, "processing") or updateStatus(id, "completed") — items stay "pending" forever

Additionally, there is no agent-facing tool to dequeue or complete retest items. The agent can see the queue via web_get_session_context(include: ["retest_queue"]) but has no mechanism to mark items as done.

Steps to Reproduce

1. Run a web pentest session with hackbrowser against any target with multiple credentials
2. Let the proxy-analyzer discover objects/roles — this triggers WebRetest.checkTriggers() via web_write_object_value and web_write_role
3. Observe the TUI showing pending retest items (e.g. "25 HTTP requests pending")
4. Let the agent complete its testing cycle
5. Observe the TUI still showing the same pending items — they never clear

Expected Behavior

Retest queue items should transition through pending → processing → completed as the agent works through them. Completed items should no longer appear in the TUI pending count.

Affected Files

• packages/cyberstrike/src/session/web/web-retest.ts — updateStatus() (L146) and next() (L162) are dead code
• packages/cyberstrike/src/tool/web-get-session-context.ts — exposes queue to agent (read-only, no write)
• packages/cyberstrike/src/tool/web-write-object-value.ts — enqueues retests (L54)
• packages/cyberstrike/src/tool/web-write-role.ts — enqueues retests (L54)
• packages/cyberstrike/src/server/routes/session.ts — TUI reads pending items (L1022-1023)

Suggested Fix

1. Wire WebRetest.next() into the ingest/processing pipeline so items are dequeued and processed
2. Call WebRetest.updateStatus(id, "completed") after the agent finishes testing each request
3. Consider adding a web_complete_retest tool (or extending an existing tool) so the agent can mark items as done
4. The Bus event (web_retest.updated) already propagates to the TUI — once updateStatus is called, the TUI will update automatically

Priority

High — this is a user-visible bug that makes the TUI unreliable during active pentest sessions. Users lose trust in the queue status and cannot tell which items still need attention.

Labels

bug, web-testing, tui

[badchars]

Proposed Solution

The root cause is that WebRetest.updateStatus() and WebRetest.next() are implemented but never called from anywhere in the codebase. Items are enqueued via checkTriggers() but never transition from pending → processing → completed.

The orchestrator prompt (Step 7) states: "If there are high-priority items, the system will feed them as new requests" — but this auto-feed behavior is not implemented.

Option A: Fully Automatic (Recommended)

Wire the retest queue into the existing ingest pipeline:

1. Auto-feed: When checkTriggers() enqueues an item, push the associated request back into IngestQueue so the orchestrator re-processes it with new context (new credentials, new object values)
2. Auto-complete: When the ingest pipeline finishes processing a retest-originated request, call updateStatus(id, "completed") automatically
3. The Bus event (web_retest.updated) already propagates to TUI — once updateStatus is called, TUI will update automatically

Pros: No agent involvement needed, matches the original prompt design intent, deterministic
Cons: Requires changes to both web-retest.ts and ingest-queue.ts/processor.ts

Option B: Agent-Driven (Tool-based)

Add a new tool web_complete_retest that the agent can call:

1. Agent checks retest queue via web_get_session_context (Step 7 — already described in prompt)
2. Agent processes the pending items using existing attack tools
3. Agent calls web_complete_retest(id) to mark items as completed

Pros: Simpler to implement, gives the agent control over when items are cleared
Cons: Depends on the agent correctly calling the tool — the current bug exists precisely because the agent says "cleared" without actually clearing anything

Option C: Combined (Best Coverage)

Implement both:

• Auto-feed + auto-complete as the primary path (Option A)
• web_complete_retest tool as a fallback for edge cases where the agent needs manual control

This ensures items are always cleared when processing completes, while still giving the agent a way to manually manage the queue if needed.

Files to Modify

File	Change
packages/cyberstrike/src/session/web/web-retest.ts	Wire updateStatus() and next() into lifecycle
packages/cyberstrike/src/session/ingest-queue.ts	Accept retest-originated requests
packages/cyberstrike/src/session/processor.ts	Call updateStatus("completed") after processing
packages/cyberstrike/src/tool/ (new)	Add web_complete_retest tool (Option B/C)
packages/cyberstrike/src/agent/prompt/orchestrator/web-proxy-agent/prompt.txt	Update Step 7 to reference the new tool