# Evidence fields — tying a PASS to the repo actually inspected

_Source: `system/caliber/lib/c77-app-submodule-mutation-discipline.mjs` (JSON payload, ~L630-632) and
`system/caliber/docs/plans/2026-05-08-c77-finding-coverage-fix.md` (Phase 1b, ~L147-149). No redaction
required — scanner logic and a plan doc, no secrets or customer data._

Fixing the resolver was necessary but not sufficient. A resolver can silently regress again; the
deeper problem was that the report gave no way to tell **which repo produced the verdict**. So the fix
also emits the resolution as first-class evidence in every report payload:

```js
const payload = {
  criterion: CRITERION,
  name: CRITERION_NAME,
  verdict,
  severity: 'Major',
  points: 2,
  family: 'Process',
  graceUntil: GRACE_END,
  withinGrace: inGrace,
  noFetch: opts.noFetch,
  targetRoot: foundryRoot,                                      // the repo actually inspected
  scriptRoot: scriptRoot,                                       // where the scanner code lives
  rootResolution: cwdRoot ? 'cwd-first' : 'script-fallback',   // which branch resolved the target
  findings,
  summary,
};
```

## What each field proves

| Field | Meaning | Why it matters |
| --- | --- | --- |
| `targetRoot` | The FoundryOS root the scan actually walked. | A `PASS` is now bound to a named repo path — you can read the verdict and see exactly what it inspected. |
| `scriptRoot` | Where the scanner code was loaded from. | Makes the intentional "audit main using the worktree copy of the scanner" workflow explicit rather than ambiguous. |
| `rootResolution` | `cwd-first` (working context resolved the target) or `script-fallback` (cwd was outside any FoundryOS repo). | Removes ambiguity about which code path fired; a `script-fallback` where you expected `cwd-first` is a visible misdirection signal. |

## The load-bearing property

Before the fix, `PASS / findings: []` was indistinguishable between "the target repo is genuinely
clean" and "the scanner inspected the wrong, empty repo." After the fix those two cases are
distinguishable **from the report alone**: a clean pass on the intended repo shows
`targetRoot` = the intended path with `rootResolution: cwd-first`, whereas the old silent-misdirection
case would show `targetRoot` pointing somewhere unexpected. As the plan states it: the fields are added
"so future misdirection bugs cannot hide."

A pass is now tied to the repository actually inspected — which is the whole point of a repository
guard.