Files

127 lines
6.0 KiB
Markdown
Raw Permalink Normal View History

# sitrep-panel
A live local HTML report you keep updated as you work. It lives at
`.sitrep-panel/report/` inside whatever project you're invoked from, served
on localhost, and it live-reloads in the browser every time you update it —
the user never has to hit refresh.
This is not a hosted artifact. It never leaves the user's machine, needs no
publish step, and works offline. Use it whenever the user wants to *watch*
a task happen rather than read about it after the fact — they'll typically
ask by name ("start a sitrep-panel", "/sitrep-panel") or describe wanting a
"progress report", "status page", or "live doc" for a task.
## Invocation
`sitrep-panel [start | open | stop | archive]` — default (no argument) is
`start`.
- **`start`** (default) — scaffold a new report if none is active, or resume
the active one. Always ends by printing the localhost URL prominently.
- **`open`** — just print the URL of the active report (start the server if
it isn't running); never touches content.
- **`archive`** — move the current active report to
`.sitrep-panel/archive/<timestamp>-<slug>/` and scaffold a fresh one. Use
this when starting genuinely new, unrelated work rather than continuing
the current task.
- **`stop`** — kill the background server. Content on disk is untouched;
`start` or `open` later brings it back.
## First run — scaffold
If `.sitrep-panel/report/` doesn't exist yet in the current project:
1. Create `.sitrep-panel/report/screenshots/`.
2. Copy `assets/template.html` (from this package's own directory) to
`.sitrep-panel/report/index.html`. Replace `{{TITLE}}` with a short name
for the task, and `{{SUBTITLE}}` with one line of context (what this
report is tracking, and when it started).
3. Write `.sitrep-panel/report/meta.json`:
```json
{"updated_at": "<current ISO-8601 UTC timestamp>"}
```
4. If the project is a git repo and `.sitrep-panel/` is not already covered
by `.gitignore`, append it — this is local scratch, not something to
commit. Mention you did this; don't ask first, it's trivially reversible.
If `.sitrep-panel/report/` already exists, skip scaffolding — resume it. Use
`archive` first for unrelated new work if you want a clean slate.
## Serving it
Start the bundled server in the background, from this package's own
directory (so the relative path to `scripts/serve.py` resolves regardless of
the caller's cwd):
```bash
python3 <package-dir>/scripts/serve.py <project>/.sitrep-panel/report
```
Run this via your background-execution mechanism — it blocks forever. It
prints exactly one line, `SERVING http://localhost:<port>/`, before
blocking; capture that for the URL. It auto-picks a free port (tries 8934
first, falls back to any free port on conflict), so several reports can run
for different projects at once. Stdlib-only Python, no dependencies.
Record the port for reuse: write `.sitrep-panel/report/.server.json`
(`{"port": <port>, "started_at": "<iso8601>"}`), gitignored along with the
rest of `.sitrep-panel/`. On a later `start`/`open`, read this file first —
if a `GET` to `http://localhost:<port>/meta.json` succeeds, the server is
already up; reuse that URL instead of spawning a second one.
**Always tell the user the URL after `start` or `open`, even if you just
reused an existing server.**
## The update protocol — what makes this useful
A sitrep-panel that only gets written once at the start is worthless.
Update it at every real step:
1. **Update "What's happening now"** (`#current-work-body`) with prose —
what you're doing right now and *why*. Replace the block's content each
time; it always reflects the present, not history.
2. **Prepend a new log entry** to `#entries` (newest-first — insert right
after the `<div id="entries">` opening tag), using the exact `.entry` /
`.entry-rail` / `.entry-dot` markup shown in the template's commented
example — the timeline rail depends on that structure. One entry per real
step: what happened, what was decided and why, what was verified. Skip
entries for trivial reads; log entries for writes, decisions, and
verification.
3. **Save screenshots** into `.sitrep-panel/report/screenshots/` and
reference them with a relative `<img src="screenshots/whatever.png">` —
inline in a log entry, appended to `#shots-body`, or both.
4. **Update the board** — the board is four columns, each with its own
container: `#board-todo`, `#board-progress`, `#board-done`,
`#board-blocked`. Add/move/remove a plain `<div class="board-card">…</div>`
in the container matching its current status as steps start, block, or
finish — moving a card means removing it from one column's container and
appending it to another's, not changing a class. See the commented
example markup in the template.
5. **Touch `meta.json` last, always.** Rewrite `updated_at` to the current
ISO-8601 UTC timestamp as the final write of every update — the page
polls this file every 2s and reloads on change. This is the one step
you must never skip.
## Tracker-synced board (optional)
If the project has a working issue-tracker connection available right now
and there are real tickets relevant to this task, render the board from
that real data — real key, real title, real link, real status. Refresh it
each time you update the doc.
If no tracker is connected, or nothing relevant is filed there, fall back
to a plain manually-maintained checklist kept in sync by hand. Never
fabricate ticket data, and don't silently guess which tracker to use if
more than one is plausible — ask.
## Notes
- One active report per project at a time by design (`.sitrep-panel/report/`
is a fixed path) — the URL stays stable across a whole session. Use
`archive` to start clean.
- Genuinely static HTML plus polling JS — no build step, no external
requests, works fully offline once loaded.
- If the user wants something shareable with people not at their machine,
that's a hosted artifact, not this — this is specifically for
local/private, zero-publish visibility.