Skip to content

hackbrowser: model crawl outcome states (running/completed/stopped/failed) instead of labelling aborts 'completed' #114

Description

@badchars

Summary

HackbrowserStatus conflates distinct crawl outcomes. When a run is aborted, the launcher transitions it to completed — the code comment even states "cancellation is a normal lifecycle exit." With the crawl-lifetime fix (crawl now runs to its own maxPages/empty queue), the difference between outcomes becomes user-visible and worth modelling correctly.

Desired states

  • running — crawl actively exploring.
  • completed — crawl finished on its own terms (reached maxPages, or page queue drained).
  • stopped — a user/genuine teardown stopped it early (Esc, session delete, /hackbrowser-stop).
  • failed — worker/LLM/browser error.

Why it matters

Currently a user-stopped or turn-end-aborted crawl is labelled completed, which reads as "done exploring the whole app" when it isn't. Distinguishing stopped from completed (and surfacing pagesExplored/maxPages) makes the sidebar/status honest about coverage.

Proposed

Thread the stop reason through the worker's final result / launcher result handler and set the correct HackbrowserStatus.phase. Update the schema (hackbrowser-status.ts) to include stopped, and the TUI sidebar to render it. Keep backward compatibility for existing readers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions