Idea: optional live/editable mode for /html-report

[smstahir]

Problem

/html-report provides a useful offline snapshot of job_search_tracker.csv, but it becomes stale as soon as /apply, /outcome, or the user changes the tracker.

Refreshing requires regenerating the report, and updating fields still requires editing the CSV manually. This becomes harder once the tracker contains multiple interview processes, follow-ups, and closed applications.

Proposed direction

Would an optional live mode fit the scope of /html-report?

For example:

/html-report --live

[MadsLorentzen]

Your post seems to have been cut off mid-example (it ends inside the code fence at /html-report --live) - feel free to edit and finish it, and I'll respond to the full shape. But the direction is clear enough to give you the honest frame now:

The refresh half has a boring answer: regenerating is one command, and keeping the report a static self-contained file is a deliberate property - it works offline, opens anywhere, and nothing has to keep running. A --live mode means a resident process watching the tracker, which is a real cost in a template whose every other surface is run-and-done. The positioning settled when /notion-sync arrived (#166) applies: /html-report is the deep-review snapshot at your desk; the "current state, glanceable, anywhere" lane is /notion-sync's.

The editable half is the bigger no, and I want to give the reason rather than just the verdict: the tracker deliberately has a single writer. /outcome owns the status vocabulary and every reader cites its definition - that discipline is recent (#299) and it fixed real bugs where two surfaces spelled a status differently and rows silently fell out of reports. A dashboard that writes back to the CSV is a second writer with none of that enforcement, plus a served-page-to-filesystem write path this repo has avoided everywhere else. Editing belongs in /outcome (which validates, timestamps, and preserves), not in a browser form.

If the pain point underneath is "regenerating is friction", say more about where the friction actually bites (the command? finding the file? remembering to re-run after /outcome?) - a cheap convenience like /outcome offering to refresh the report after a status change would be a scoped, philosophy-compatible fix, and that's a door I'd leave open.