Skip to content

Build tickets: the application

Stage 3 for the Chemical Safety Assistant, derived from .scratch/chemical-safety-assistant/PRD.md. Tickets are one file each under issues/, per docs/agents/issue-tracker.md, which overrides /to-tickets's single-file convention. Numbering continues from the wayfinder children rather than restarting — ids are never reused.

Work the frontier: any ticket whose blockers are all resolved. Take one by setting Status: in progress — <why> before doing any work. Run ./init.sh before starting and after finishing; the parent gate was COVERAGE: FAIL with 67 problems when this chart was written, and that was stage 1's debt rather than this chart's. It closed 2026-09-11 and the gate has been green since; the sentence is kept because a ticket that told an agent to expect red should say when it stopped being true, not quietly stop saying it.

Dependency order

#TicketBlocked by
13Pull the Corpus onto the deviceresolved
14Escalation, present everywhereresolved
23Seam 3 — Identification
15First Aid14
16Spill Response14
17The Routing Floorresolved13
20Curated Explanation lookup13
21History and Settings13
22Seam 1 — the Corpus artifactresolved13
18The Escalation Trigger14, 17
19The Query Intent tier17
24Seam 5 — the Routing Fixture17, 19

Every ticket except 19 is resolved. 19 is part-built and stays open — its client half landed and its endpoint is owner-blocked on a provider key, the spend cap number and the per-address bucket size. This chart has no frontier, and what is left on it is owner decisions rather than tickets. The buildable work has moved to curation-tickets.md.

One question it leaves for a ruling: §2 says the snapshot is pulled "opportunistically when a connection exists", and that cannot coexist with Seam 4's zero-request assertion without deciding whether a background sync counts as exercising a surface. The pull is on-demand until then.

Already built — do not re-ticket

The Corpus data model and its migrations; the sync endpoint (/api/v1/corpus/snapshot and /version); the on-device Corpus store, the snapshot-version sentinel and the four no-answer states; the Chemical Record surface with identity, hazards, PPE, storage and the chooser; manual search, QR identification, Home and the PWA shell; Seam 2 and Seam 4.

Deliberately not ticketed

  • Curating documents. The spec is explicit that tickets filling the Corpus "cannot be sized as engineering work at all", and the Study Area is unchosen. This is handoff blocker 3, not a ticket.
  • Camera text recognition. Risks item 1 requires a spike against photographs of real drum labels before any ticket assumes it works, and those photographs do not exist.
  • Curation tooling — page-image verification (D-56), the cross-section Restriction detector (D-49), span selection (D-50), QR label generation (D-63). Real scope, and curator-side rather than app-side: mixing it here would make the frontier misleading, since an agent taking the next ticket would move between building the product and building an internal tool. It needs its own chart. It has one, since 2026-09-11: curation-tickets.md, tickets 25–33, sharing this directory and this number line. Its frontier is 25, the write surface those four pieces have nowhere to write without.
  • Accounts, login, cross-device sync (D-60). There is no login surface anywhere.