# Root resolution — before (wrong) vs after (correct)

_Source: `system/caliber/lib/c77-app-submodule-mutation-discipline.mjs` (root-resolution block, ~L153-156)
and `system/caliber/docs/plans/2026-05-08-c77-finding-coverage-fix.md` (Current behavior + Phase 1a).
No redaction required — scanner logic and a plan doc, no secrets or customer data._

The C77 scanner audits an implicit target: the FoundryOS repo it should inspect is not passed as an
argument, it is **resolved** by walking the filesystem upward until a directory containing
`system/SYSTEM_REGISTRY.md` is found. The bug was in *where the walk starts*.

## Before — script-anchored (resolves the WRONG root)

The scanner anchored the walk to the directory the **script file itself** lives in
(`fileURLToPath(import.meta.url)`):

```js
const thisDir = path.dirname(fileURLToPath(import.meta.url));
const foundryRoot = findFoundryRoot(thisDir);   // ← walks up from where the CODE lives
```

FoundryOS sessions routinely run from a linked git worktree
(`.claude/worktrees/<name>/`), and every worktree carries its own copy of
`system/SYSTEM_REGISTRY.md`. So when the scanner file lived inside a worktree, the upward walk stopped
at the **worktree root** — regardless of which repo the operator actually invoked it against. The
scanner then looked for initialized app submodules under `<worktree>/apps/<app>/.git`, found none (a
fresh worktree has no submodules initialized), skipped every app, and returned:

```
verdict: PASS
findings: []
```

A green result — from a repo the operator never meant to inspect.

## After — cwd-first, script-fallback (resolves the target the operator MEANT)

The fix resolves the target from the **active working context first**, falling back to the
script location only when the working directory is not inside any FoundryOS repo (the imported-as-a-
library edge case):

```js
const thisDir = path.dirname(fileURLToPath(import.meta.url));
const cwdRoot = findFoundryRoot(process.cwd());   // ← the operator's invocation context = intent
const scriptRoot = findFoundryRoot(thisDir);      // ← where the scanner code happens to live
const foundryRoot = cwdRoot || scriptRoot;        // ← cwd-first, script-fallback
```

`findFoundryRoot` itself is unchanged — the same upward walk for `system/SYSTEM_REGISTRY.md`. What
changed is that it is now applied to `process.cwd()` first. If the operator runs the scanner from the
main repo, `cwdRoot` short-circuits at depth 0 and the scanner audits the main repo. If cwd is outside
any FoundryOS repo, `cwdRoot` is `null` and the walk falls back to the script's location, preserving
the old behavior exactly for the library case.

## Why this is a root-cause fix, not a patch

The defect was a category confusion baked into the resolver: it conflated *where the code lives* with
*what the code is operating on*. The fix separates the two and makes the operator's invocation context
authoritative — the natural intent signal for a tool that takes an implicit repo target. The evidence
fields shipped alongside it (see `evidence-fields.md`) make any future recurrence self-announcing
rather than silent.