Repository navigation
Docs vision architecture glossary - #17
Conversation
Add the shared project documentation baseline: - docs/vision.md: product vision, users, workflows, current calculation model, principles, limitations, and open questions. - docs/architecture_baseline.md: architecture of the current main branch, covering system shape, deployment, persistence, calculation boundary, workflows, and open questions for ADR treatment. - docs/glossary.md: shared QMRA vocabulary and preferred language. - docs/templates/adr.md: template for architecture decision records. - .github/pull_request_template.md: pull request template. - CLAUDE.md: project instructions, including deploy-key Git usage on this server. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 844820e63c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| A user can add multiple treatment steps to a scenario. Each step contributes minimum and maximum LRVs for bacteria, viruses, and protozoa. The current calculation combines treatment steps by summing LRVs within each pathogen group. | ||
|
|
||
| Users can explore alternative scenarios by changing the configuration and rerunning the assessment. There is no dedicated comparison view for multiple saved assessments. |
There was a problem hiding this comment.
Document the existing saved-assessment comparison
This states that no dedicated comparison view exists, but authenticated users already have a comparison workflow in risk-assessment-list.html: they select saved assessments, click “Compare selected assessments,” and lines 293–299 render their serialized results in a Plotly comparison modal. Classifying comparison as absent and next-phase functionality makes the product vision and roadmap misleading; document the current result-comparison view and reserve only the proposed expanded comparison capabilities for the next phase.
Useful? React with 👍 / 👎.
Derive a CONTEXT.md from docs/glossary.md with one canonical term per concept and an avoid-list, add the terms the code relies on but the glossary lacks (inflow, pathogen group, reference, reference-level exceedance), and record the glossary/code conflicts and open questions to resolve in a later session. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Address PR review: the saved-assessments page already lets a registered user select assessments and open a Plotly plot comparing annual infection probability per reference pathogen. Describe that view as current functionality in the vision, glossary, architecture baseline and CONTEXT.md, and reserve only input and DALY comparison for next phase. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
CONTEXT.md now carries the canonical vocabulary, so the separate glossary would drift. Point the open-questions note at CONTEXT.md. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Converted from QMRA_Failure_Approach.docx (Hambsch et al. 2019 based method for integrating treatment failure events into the annual infection-risk calculation). Equations are rendered as LaTeX. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
01: onboard Malte to the AI development framework (server account, GitHub access and group membership already in place; Claude authentication, first launch and method walkthrough remain). 02: establish the current product vision and glossary, recorded as done with its follow-ups. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Explain each technical term where it first appears and keep every fact, checkbox and link unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ma-z-am
left a comment
There was a problem hiding this comment.
All docs seem good to me. Open questions yet to be answered.
Add inflow/outflow concentration, best-case/worst-case, normal operation, site-specific source water, recontamination and risk measure; redefine scenario and assessment; widen treatment step. Record code renames as follow-ups and defer UI wording and the LRV-above-6 rule. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Four Changes for treatment failure: failure inputs (Large), failure calculation (Large), failure inputs in export and report (Small) and explaining treatment failure (Small), with dependencies, parallel work, sequence, release rule and open decisions D1-D4. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
D4: steps with at least one positive LRV accept failure inputs, and a failure removes only positive LRVs. The independent benchmark moves from the calculation change into a new Small change C5, built after C2 and required before release; expected values come from an independent Monte Carlo script, and domain experts sign off the benchmark comparison. D1-D3 remain open for tolerance and names. The vision's success criterion now covers results only. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Record C5 failure benchmark, the settled D4, the benchmark method and the acceptance rule; narrow the open decisions to D1-D3. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Describes where the application runs, its addresses and endpoints, a five-minute check for each environment, how a change reaches each one, and how the servers are reached. Checked on 24 September 2026 from the workflows, the workflow runs and requests to the public addresses. Notable findings: a merge into main deploys to production automatically, whatever files changed (the last push to main changed only a PR template and still deployed); dev follows whichever branch pushed last; the GitHub environments have no protection rules; /metrics is public on both environments. Facts that live outside the repository (who runs the servers, SSH access, backups) are left as a table to fill in. The architecture baseline now points to this page and lists where its section 2 differs from what the pipeline does: microk8s and Helm instead of Docker Compose, TLS defined in the Helm chart, tests on Python 3.11 against a 3.12.5 image. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…release Every merge into main deploys to production without approval, so "nothing is deployed until C1-C5 are merged" cannot hold as written. D5 names the options (a setting that keeps the failure inputs off, an integration branch, or a required approval on the prod environment), blocks the C1 Spec and Release, and the Release dependency and sequence now refer to it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a section to the environments page on skipping the pipeline with [skip ci], including what to do when merging into main and the caveat about required checks. This commit itself carries the text, to check on a pull-request branch that no run starts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous commit carried [skip ci] and started no workflow run and no check on the pull-request branch. Not yet checked on a merge into main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
C1-C5 stay open pull requests, built on each other and tested on the dev environment, and are merged into main together at the release, since every merge into main deploys to production. Record the rule in the roadmap, environments page and CLAUDE.md. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Spec for the first failure roadmap Change: failure frequency and failure duration per treatment step and on personal treatment steps, shared validation including D4, HTTP-level test seam with a manual dev-environment check, and acceptance criteria mapped to the vision's quality goals. Link it from the roadmap. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Spec for the failure calculation: failure days per exposure event with shared random draws, worst-case full loss of positive LRVs, best-case mixed-water assumption with the lowest-concentration arrangement, and frequency 0 reproducing today's results. Tests at the calculation seam with closed-form cases. Record the arrangement rule for three or more failing steps in CONTEXT.md and the failure approach. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
No description provided.