Live dashboard work proofs

Invariant: Working requires evidence from the currently assigned, unrevoked agent. A box receipt cannot attach an agent. Only that agent's bot API key can report its items; another org, project-bound key outside its project, another assigned agent or an unattached item is rejected. Detachment, reassignment, revocation and expiry invalidate stored proofs on read. Ticket comments/events through the currently assigned key also count.

POST /v1/orgs/:orgId/work-liveness accepts one bounded batch of at most 500 {issueId, at, kind, ref?} proofs plus boxId. Use the agent bot key in the Authorization bearer header. Sign the canonical body from canonicalWorkProof(orgId, batch) with HMAC-SHA256 keyed by that same bot token; send the lowercase hex digest in X-GQ-Work-Proof. UUID case is normalized before authorization and deduplication; equivalent UUIDs share one upsert identity. The signature binds the org, box and each proof; missing or altered signatures are rejected. Proof timestamps never advance on replay. Newer evidence wins, serialized with reassignment; a new agent replaces the old agent's receipt. More than 60 seconds future skew is rejected.

The box sensor is node tools/command-center/work-proof.mjs --manifest MANIFEST --state STATE --key-file BOT_KEY_FILE --api-url API_ORIGIN. The manifest has {orgId, boxId, items:[{issueId, pid, log?, transcript?, repo?, branch?}]}. Each box/agent identity owns one manifest and state. Invoke once per 60 seconds, serialized per state file; no service or schedule is installed here. The current sensor reports only process+output growth, new complete agent transcript events, and confirmed remote branch commits. A process alone, unchanged output, user prompts, lifecycle/heartbeat events and unpublished commits do not renew evidence. Failed publication does not persist advanced state. Missing evidence remains Pending.

Both visible dashboards consume organization-scoped SSE invalidations generated after committed writes, with 500 ms server coalescing and at most one client fetch per two seconds. Working is green through five minutes, Stalled? amber through fifteen, then Pending grey. Proof ages refresh every fifteen seconds; the five/fifteen-minute state deadlines are scheduled separately so labels decay at the boundary without a new server event. Hidden pages pause reads and streams; visible pages refresh and reconnect. Reconnection backs off from 1–2 seconds to 30–60 seconds with jitter.

The transport switches myWork.realtime, commandCenter.realtime and proof switch workLiveness.enabled default on. Existing parent switches myWork.enabled and commandCenter.enabled retain their dark defaults: reviewed promotion and Operations enablement are prior owner decisions in the respective feature docs. This lane changes no platform settings. An enabled org's /orgs/:orgId/my-work now exists; an unentitled org or disabled parent still intentionally answers 404. After reviewed promotion the orchestrator must enable the parent platform feature through its normal settings workflow, with the org entitlement enabled. No production state was read to classify the earlier P51 response.

Every data push and 15-second heartbeat rechecks authentication and scope. Revocation ends idle streams at the next heartbeat. Each viewer is limited to three streams per dashboard and each instance to 500; reservations precede asynchronous reads. Slow readers and lifetime expiry close streams. The heartbeat contains no work proof.

Local proof: REALTIME_BROWSER=1 pnpm --filter @bugtracker/api exec vitest run test/realtime-browser.test.ts after a production web build with NEXT_PUBLIC_API_URL="" and API_PROXY_TARGET pointing to the local API (both are build-time inputs). The reusable live spec acceptance/realtime-dashboards.live.json is executed by the orchestrator's browser runner with a locally generated or authorized storage state. It checks the enabled pages and screenshots; the two-browser test checks actual writes, cross-org isolation, proof decay and latency. Production execution remains MANUAL-PENDING after deployment.

Reference

• API reference: /v1/openapi.json includes the enabled work-liveness operation.
• MCP tools: MCP tool reference.
• Runbook: operations and tests.