Epic: Incident lifecycle v1 — real incident data end-to-end

[amondnet]

Context / Motivation

StatusBeam has the two ends of incident handling but nothing in between. The D1 incident schema exists (apps/worker/schema.sql:20-35) and the incident lifecycle timeline UI exists (apps/web/src/components/IncidentList.tsx), but:

• ingest never writes an incident row, and
• there is no way for an operator to create, update, or resolve one.

The consequence is that a production status page falls back to the bundled sample incidents — a deployed page shows fabricated history. This is documented in the persistence-gap section of .please/docs/knowledge/product.md.

This is the blocking gap for the rest of the roadmap. Subscriber notifications have nothing to notify about, SLA reporting has nothing to measure, and the RSS/Atom feeds have nothing real to publish, until incidents are real data.

Proposed scope

Close the loop end to end, so that both automatic (detected) and manual (operator-declared) incidents are persisted, rendered, and syndicated:

1. Automatic — ingest persists response-time samples and opens/resolves incidents from status transitions.
2. Manual — an authenticated API plus CLI for the operator-driven lifecycle (create, update, resolve).
3. Addressable — per-incident permalink pages, so feed items link to something real.
4. Operator surface — a slimmed admin panel on top of the same API, with an MCP surface as follow-up.

Sub-issues (tracked natively):

• feat(worker): persist incidents and response-time samples in ingest #61 — persist incidents and response-time samples in ingest (p1, M)
• feat(cli,api): incident CRUD — create/update/resolve with Markdown body #62 — incident CRUD: create/update/resolve with Markdown body (p1, L)
• Per-incident permalink pages for feed item links #40 — per-incident permalink pages for feed item links (p2, blocked by feat(worker): persist incidents and response-time samples in ingest #61)
• feat: incident admin panel (v1) + MCP agent surface #63 — incident admin panel + MCP agent surface (p2, blocked by feat(cli,api): incident CRUD — create/update/resolve with Markdown body #62)

Acceptance criteria

• A deployed status page shows real incidents and a real response-time chart; the sample-data fallback is unreachable in production.
• An operator can run a full incident lifecycle (declare → update → resolve) against a deployed Worker.
• Every incident has a stable permalink that the RSS/Atom feed items link to.
• All four sub-issues are closed.

Priority / Effort / Dependencies

• Priority: p1 — this unblocks maintenance windows, subscriber notifications, and SLA reporting.
• Effort: tracked per sub-issue.
• Dependencies: none inbound. feat(worker): persist incidents and response-time samples in ingest #61 → Per-incident permalink pages for feed item links #40 and feat(cli,api): incident CRUD — create/update/resolve with Markdown body #62 → feat: incident admin panel (v1) + MCP agent surface #63 are the internal ordering constraints.