Add browser notifications to /tickets page via /tickets/watch stream

Add browser notifications to the /tickets page via the /tickets/watch NDJSON stream. User expects notifications for ticket status changes without caching the notification script.

Design

Inline a small script at the bottom of the /tickets HTML template (in src/html.rs) that:

1. Requests notification permission on page load if not already granted
2. Connects to /tickets/watch with Bearer token auth (same as MCP endpoints)
3. Parses the NDJSON stream event-by-event
4. Filters and notifies on substantive ticket changes (skip connected, heartbeat, lagged housekeeping events)

Event Stream Format

The /tickets/watch endpoint returns NDJSON where each line is a JSON object like:

{"event": "connected", "at": "2026-04-24T13:00:00Z"}
{"event": "heartbeat", "at": "2026-04-24T13:00:20Z"}
{"ticket_id": "...", "status_after": "proposed_resolution", "by": "handler", "action": "...", ...}
{"event": "lagged", "dropped": 5, "at": "..."}

Notification Logic

Show a browser notification when:

• Event has a status_after field (status transition occurred)
• Event is not connected, heartbeat, or lagged (skip bookkeeping)
• Notification.permission is granted

Do not notify on:

• Pure comment events (no status change)
• Housekeeping events

Notification Details

• Title: Short ticket ID (first 8 hex chars of UUID)
• Body: Status name (e.g., "→ proposed_resolution")
• Tag: ticket-{ticket_id} to dedupe updates on the same ticket
• requireInteraction: true only for proposed_resolution (sticky, needs user action)
• onClick: Focus window and optionally navigate to the ticket detail page

Bearer Token

The script needs a Bearer token to authenticate to /tickets/watch. Options:

1. Embed in a <script> variable from server-side session state (preferred if you have session tokens)
2. Read from a meta tag in the HTML head
3. If no token, skip notifications gracefully

Recommend checking window.BEARER_TOKEN (injected by server if user is logged in) or fall back to skipping notifications.

Implementation Notes

• Keep the script under 100 lines
• Use fetch() with streaming body + manual NDJSON parsing (no external deps)
• Handle disconnects gracefully (don't hard-error, log to console)
• Consider adding a console message when notifications start: "Ticket notifications enabled"
• Test on a real /tickets page connected to an active ticketing session

Files to Change

• src/html.rs: Add <script> block to tickets_page() or similar template function
• Possibly add a helper to extract/inject the Bearer token into the page context

Acceptance Criteria

• Script inline in HTML, no external requests
• Browser notifications appear when ticket status changes
• Housekeeping events (connected, heartbeat, lagged) are filtered out
• Notification permission prompt appears on first visit
• Script handles auth failures gracefully
• Hard reload of page resets the notification stream (no caching)

Done per spec + your mid-flight correction.

What shipped

Inline <script> in /tickets HTML that subscribes to /tickets/watch NDJSON and surfaces browser notifications on status transitions. Filtering, dedup tag, sticky requireInteraction on proposed_resolution, onclick-focus-and-navigate — all per the spec body. Single file: src/html.rs. +83 lines. No new Cargo deps, no browser-lib imports, pure fetch + TextDecoder + Notification.

Your mid-flight correction ("authentication and OAuth should have nothing to do with any of this") reshaped the design:

• Stripped the window.CHUKWA_TOKEN feature guard.
• Stripped the Authorization: Bearer header from the fetch.
• Stripped every piece of client-side business logic contingent on auth state.
• The script's graceful-failure path (non-2xx → console.info + return) is now its only auth interaction: it observes whatever the server returns, and never decides anything based on "am I authenticated."

What I deliberately did NOT do

The server's auth posture on /tickets/watch — the Bearer-gate in src/server.rs::tickets_watch — is UNCHANGED. I read your comment as "don't make the feature contingent on authentication in its own business logic," not as "remove authentication from the protected resource." The permission layer also flagged that distinction when I initially tried to drop the Bearer check as part of this commit. If you actually wanted the endpoint opened up, that needs explicit direction — it's a substantive privacy decision (public stream = anyone on the internet who hits /tickets/watch reads the live ticket mutation feed), and I'm not prepared to make that call unilaterally.

Implication in production right now

Because /tickets/watch still returns 401 on unauthenticated requests, and the deployed script sends no Authorization header, a browser visiting /tickets will:

1. Load the page (fine).
2. Ask for notification permission (on first visit).
3. fetch /tickets/watch → 401.
4. console.info the 401 + return.
5. No notifications will ever fire.

Feature is installed and dormant. Activating it is one of two server moves you'd need to make in a separate ticket:

• (A) Drop the Bearer requirement on /tickets/watch. Simple, one-line change. Publishes the ticket stream to any reader of the page — which may be fine if /tickets itself is already public, or may not be if you want ticket-mutation-level observability to stay gated.
• (B) Make /tickets/watch accept the existing human-session cookie in addition to the Bearer token. Slightly more code; preserves the "only logged-in humans see the stream" posture.

I didn't pick between (A) and (B) because the call depends on policy, not code. Flagging for a follow-up ticket.

Receipts

Commits on main, pushed to gitlab:

• 058eaf9 feat(html): browser notifications on /tickets via /tickets/watch
• 4a846f2 Merge branch 'feat/ticket-notifications'

Tests:

• cargo build dev + release: clean (one expected dead_code warning on the unchanged replace_exact_skipping_tags, unrelated).
• cargo test --lib: 303 passed (unchanged; no Rust tests added — behavior is browser-side).
• cargo test --test phase0: 14 passed.
• ant_scenario skipped per the subagent brief — this is a frontend-only change, the live-router path is untouched.

Deploy: bash k8s/deploy.sh clean; pod chukwa-5d57999cb6-lwgm2 Running 1/1.

Production smoke on https://chukwa.benac.dev :

• GET /tickets → HTTP 200. grep counts in response:
  • Ticket notifications enabled (the console.info the script emits on successful subscribe): 1 hit — script landed.
  • fetch("/tickets/watch"): 1 hit — subscribe code present.
  • CHUKWA_TOKEN anywhere in the HTML: 0.
  • Authorization or Bearer anywhere in the HTML: 0.
• GET /tickets/watch (unauthenticated from the host): HTTP 401 — server auth UNCHANGED.

What activation would feel like

If you (or a follow-up ticket) drop /tickets/watch's Bearer requirement: no code change to this commit, no redeploy of this feature, nothing else. A browser visiting /tickets would then see the fetch succeed, console.info "Ticket notifications enabled", and start firing OS notifications on every status transition until the tab is closed. The feature is wired; only the server gate is closed.

Per standing guidance I am not confirming this ticket — only proposing. If this is the shape you wanted ("script is in place, auth is orthogonal, activation is a separate decision"), accept. If you wanted the endpoint opened up in this ticket, reject and I'll handle that as a separate commit after explicit go-ahead.