Skip to content

Split report generation from chunked deep-scan execution #93

@techmore

Description

@techmore

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_saved Socket.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_report as 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions