Cloud code review records — the shape every run must write

Claude Code's cloud multi-agent review (/code-review ultra, formerly /ultrareview) reads a whole pull request with several agents, verifies each finding, and reports. Every run leaves TWO files in this folder, named after the day and the pull request:

2026-09-04-pr1.json the record the machine reads 2026-09-04-pr1.md the same run written out for a person

The App testing board (MASTERdrive/Website/tools/testing-board.py) reads the .json and nothing else — no handoff, no claim, no memory of a run. If the newest .json here is missing a field, the board's panel says record unreadable and names this file rather than falling back to an older record, because a half-written record that quietly reads as an older healthy one is how an absence disguises itself as a measurement.

The record

{
  "pr": 1,
  "url": "https://github.com/scott100-max/Salus-App/pull/1",
  "base": "2bae4b28...",
  "head": "e2d57264...",
  "ran_at": "2026-09-04T03:40:00+01:00",
  "findings": [
    {
      "id": "1",
      "file": "ios/App/App/SomeView.swift",
      "line": 214,
      "severity": "high",
      "summary": "one plain sentence saying what is wrong and what it breaks",
      "verified": true,
      "closed_by": ""
    }
  ],
  "verdict": "one sentence: what the review concluded about this pull request"
}

Every field in pr, url, base, head, ran_at, findings and verdict is required. findings may be an empty list — a review that found nothing is a real result — but the key must be there.

field	what it is
`pr`	the pull request number
`url`	the full `https://` address of that pull request
`base`	the commit the review compared FROM (the full sha)
`head`	the commit it compared TO (the full sha)
`ran_at`	when the run happened, ISO 8601 with a time zone
`findings[].file`	the file the finding is in, repo-relative
`findings[].line`	the line number, or `null` when the finding is not on one line
`findings[].severity`	`high`, `medium` or `low`
`findings[].summary`	one plain sentence
`findings[].verified`	`true` only when a verifying agent confirmed it; `false` otherwise
`verdict`	one sentence, the review's own conclusion

How a finding gets counted as FIXED

The board shows fixed: not recorded until something on disk actually records a fix. That is deliberate: a zero and an unrecorded number look identical on a page and mean opposite things. Two ways to record one, and either is enough:

In this record. Give the finding an id, and when it is fixed set its closed_by to the commit sha that fixed it. A closed_by key that is present but empty means "known, not fixed yet", and it turns the board's not recorded into a real, measured count.
In a later record. A newer run may carry a top-level "closes": ["1", "4"] naming the ids of findings from an earlier run that its own pass proved gone.

Optional fields

closes (a list of finding ids this run proves fixed), model, agents, notes. Anything extra is ignored by the board and kept for the person reading the .md.

Where the board's settings live

The folder for each app, the staleness limit and its reason are declared in ~/Salus-Vault/salus-brain/brain-config.json under code_review — not in the board's code. Today the limit is 7 days: one review pass covers about a week of commits, so once the newest commit on main is more than seven days newer than the newest record here, a whole week of changes has never been read and the panel raises a red flag.