-
Notifications
You must be signed in to change notification settings - Fork 0
Closed
Labels
Description
Summary
This issue is still valid, but the backend now has a dedicated saved-scan PDF flow. The remaining gap is that the product workflow and UI action model still center generate_report as the primary path, so scan execution and report rendering are not yet separated cleanly from the user’s point of view.
What Changed
The codex/runtime-contract-fixes branch added a real PDF-only path from previously saved scan data:
generate_pdf_from_savedSocket.IO event- shared latest-saved-scan lookup
- shared PDF generation from saved XML
That means the architectural foundation for separation now exists.
Remaining Problem
The remaining work is to make the workflow explicit and consistent end-to-end:
- the UI still treats
generate_reportas the main action in places where users may expect "render a PDF from existing data" - large-network/chunked scan behavior is still closely tied to the report-generation action model
- product messaging still needs to distinguish clearly between:
- running a fresh comprehensive scan
- generating a PDF from existing saved data
- doing both intentionally
Proposed Fix
- Make the primary UI actions explicit:
- fresh scan
- chunked/comprehensive scan
- PDF from latest saved scan
- Default "Generate PDF" behavior to saved data where that matches user intent
- Keep an explicit combined action only where scan-plus-report is intentional
- Add regression coverage for UI and handler flows so the distinction stays clear
Severity
Medium — now a workflow/UX boundary issue built on top of backend support that already exists.
Reactions are currently unavailable