C1: Failure inputs per treatment step (#21, #22, #23)

[yaniv-kwb]

Do not merge before the release. Failure work stays out of main until C1–C5 are released together (roadmap decision D5): every merge into main deploys to production. This PR stays open, is kept up to date with main, and is tested on dev. C2 and C3 will build on it.

What changes

Users can enter a failure frequency (failure days per year, 0–365, default 0) and a failure duration (whole minutes, 1–1440, default 30) for each treatment step, and the values are stored with the scenario. Nothing in the calculation changes yet: results and export packages are identical with and without failure inputs (C2 adds the effect).

• Configurator (C1: Failure inputs on a treatment step in the configurator (enter, check ranges, save, reopen, edit) #21): each step card shows both fields with their units. Values are checked on run and save, and stay with their step through save, reopen and edit. Existing assessments get 0 and 30 through the migration. Tidy-up: the duplicated min ≤ max LRV check is now one shared rule for both treatment step forms.
• Positive LRV and guests (C1: Failure frequency only on steps with a positive LRV (D4), with messages for guests too #22): a step can only have a failure frequency above 0 if at least one of its LRVs is positive (D4).
  • Guests now see validation messages on the affected field and step; before, an invalid guest result failed silently. This also covers the existing LRV errors.
  • The treatments section now grows with its content, so the new fields no longer sit under the footer.
• Personal treatment steps (C1: Personal treatment steps store failure inputs and the configurator copies them in #23): they store both values under the same rules, and the configurator copies them into a newly added step. The copy can be changed without touching the personal step. Invalid input in the personal step form now shows its messages.

The branch also carries the docs commits for the C1 and C2 tickets. These include the per-pathogen rule for arranging combined failures in the C2 Spec and in CONTEXT.md (Combined failure).

Spec and Tickets

• Spec: docs/specs/c1-failure-inputs.md (Change C1 in docs/failure_roadmap.md)
• Tickets: C1: Failure inputs on a treatment step in the configurator (enter, check ranges, save, reopen, edit) #21, C1: Failure frequency only on steps with a positive LRV (D4), with messages for guests too #22, C1: Personal treatment steps store failure inputs and the configurator copies them in #23 (local copies docs/tickets/04–06)

Checks

• Mock-data check (Controlled server):
  • The full test suite passes (46 tests), including 24 new HTTP-level tests through Django's test client.
  • A local server with scratch databases, driven by a headless browser, checked three flows:
    • guest errors shown and cleared;
    • a personal step rejected, then saved and copied into an assessment (2.5 and 90), with a bundled step at 0 and 30;
    • the copy changed to 10 and 15 and reopened, while the personal step kept 2.5 and 90.
  • Still to do: the manual check on dev (see the list below).
• Real-data check (Workstation): not done yet.
• Quality goals checked:
  • Input validity: every failure input shows its unit, and values outside 0–365 or 1–1440, fractional minutes, empty fields and D4 violations are rejected with a message. Covered by HTTP tests for the saved configurator, the guest result and the personal step form.
  • Reproducibility: reopening returns exactly the stored values, and assessments from before C1 read back 0 and 30 (HTTP tests).
  • Export stability: the export package of an assessment is byte-identical with and without failure inputs (HTTP test).
  • Privacy of registered-user data: another user's list of personal treatment steps doesn't contain the step (HTTP test).

Manual check on dev

• Before the deploy, note the results or export of one or two saved assessments on dev. Afterwards they reopen with 0 and 30 and unchanged results.
• Configurator (registered user): the fields and units are there, and values survive save, reopen, edit and delete. The listed invalid values are rejected with messages. A step whose only positive LRV is protozoa 0–2 is accepted with frequency 1.
• Guest: valid failure inputs give a result. Frequency 400 is marked on the field and on the step, and the marks clear after correcting.
• Personal treatment step: invalid input shows a message. After saving, adding the step copies its values, the copy can be changed without touching the personal step, and a second account doesn't see it.

Known behaviour that isn't from C1:

• Server error (500) when events per year or volume per event is empty #27: an empty "Events per year" or "Volume per event" gives a server error.
• If you type into a field and then click "Show assessment results" straight away, the first click is lost.

Once this is on dev, the migrations can't be reversed there. Only C1 and branches built on it should go to dev until the release. A merge into main would put dev back on code without these columns, until this branch is pushed again.

Definition of Done

• Tests pass
• code-review findings are handled (fixed, or answered in this PR)
• Mock-data check done (automated and local browser checks, and the manual check on dev)
• Real-data check done, or marked not needed above
• No secrets or Real data committed
• Glossary, ADRs and Vision document updated if this Change affects them (C1 needs no update; the C2 docs commit updated CONTEXT.md)
• Relevant Quality goals checked
• I can explain this Change in my own words

🤖 Generated with Claude Code