Publish a page per DINS incident with its three-state field split

[ChelseaKR]

What

dins.html carries one row per incident and a per-field split for the whole file; the per-incident field split exists in the artifact (incidents_detail) and is rendered nowhere. A county emergency manager or a reporter working one fire wants exactly that: for the Camp Fire, which fields were recorded, which carry Unknown, which are blank, split by assessed and inaccessible structures. This renders site/incidents/<slug>.html for every incident from the existing artifact, with the incident's name and number as published, its record count, its damage-value counts, and the per-field three-state table in the same layout as the file-level page, plus incidents/index.html in name order.

Why it matters

The README's argument for the per-incident table is that "an average across the file describes no incident in particular", and the same holds one level down: a per-incident completeness percentage describes no field in particular. The data is already computed and gated; the gap is rendering. Static pages with no script keep the current posture; the WCAG, reflow, contrast, and prose-number gates run over all of them, which is the cost and the reason to do it with the existing tooling rather than a filter widget. No address, parcel, or coordinate appears; an incident with no assessed records prints "none assessed" in words.

Scope

• render.py: incident page template and index; slugs derived deterministically from incident number and name with collision handling recorded in the artifact.
• pages.yml and site-offline build all pages; gates parametrized over the directory.
• Cross-links: the incident row on dins.html links to its page; each page links back and to the data artifact.
• Page count stated on the index; the fixture build renders the fixture incidents.

Out of scope

• Any map, chart, or per-incident rate beyond the counts already in the artifact.
• Client-side filtering or search.

Done when

• The fixture build renders one page per fixture incident, each passing every page gate, and the index lists them in name order.
• Two incidents with the same name and different numbers get distinct slugs and both appear.
• An incident whose records are all inaccessible shows assessed denominators in words and the inaccessible split.
• Every number on an incident page traces to incidents_detail.

Pointers

• src/perimeter/render.py, coverage.py (IncidentCoverage), site/data/dins-coverage.json (incidents_detail)
• tools/a11y.mjs, tools/a11y_browser/, tests/test_pages_html.py

Proposed with AI assistance.

[ChelseaKR]

Triage against origin/main @ d4f533f (2026-09-06). Not built: no site/incidents/. incidents_detail is present in site/data/dins-coverage.json and in artifacts.py, gated by tests/test_artifacts_and_pages.py and tests/test_field_notes.py, and rendered nowhere — so the premise is exactly right: the data is already computed and gated; the gap is rendering.

Automatable, no owner decision, no new data. Static pages with no script, built by the existing site-offline path, gated by the existing WCAG, reflow, contrast and prose-number checks parametrized over the directory. No address, parcel or coordinate leaves the build; only counts already in the artifact.

The two details that decide whether it is right:

1. Slugs. Derived deterministically from incident number and name, with the collision handling recorded in the artifact rather than resolved silently in the renderer. Two incidents sharing a name and differing in number must both get a page, and a reader must be able to tell which is which from the artifact alone.
2. "An incident with no assessed records prints 'none assessed' in words." A per-incident completeness of 0% over an assessed denominator of zero is not a measurement, and the issue is right to insist the words appear instead of the number.

The third, easy to forget: the page count is stated on the index, so a build that rendered fewer pages than there are incidents is visible rather than inferred.

Not started here.

Triaged with AI assistance.

[ChelseaKR]

Triage, 2026-09-07. Unbuilt, unblocked, well specified. incidents_detail is already computed and already gated, so the issue is right that the gap is rendering.

One cost the issue does not put a number on, and it is the thing that decides how this is built: the pinned retrieval holds 398 distinct INCIDENTNAME values and 445 distinct INCIDENTNUM values, so "a page per incident" is roughly four hundred pages, not a handful.

make pages runs html-validate, axe in jsdom, axe again in Chromium, and a 320px reflow check over every built page. Parametrizing those gates over the directory, as the issue asks, multiplies the Chromium pass by four hundred. That is very likely minutes of CI per run, on a repository whose verify is currently fast.

Worth deciding before writing the renderer: gate every page, or gate the index plus a declared sample and say in the artifact which pages were checked and which were not. The second is defensible only if it says so plainly, since "checked" and "not checked" are exactly the distinction this project refuses to blur elsewhere. That is a judgment call, not a detail.

Prepared with AI assistance; reviewed before submission.