checkSurvivingPlaceholders returns passed:true on a zero-file scan, so a mis-rooted Setup 9(d) gate cannot fail

[cammcd]

Summary

checkSurvivingPlaceholders() in skills/LifeOS/Tools/InstallEngine.ts returns
passed: true when it scans zero files. A mis-rooted or nonexistent rootDir therefore
reports success, which is precisely the failure mode Setup.md step 9(d) exists to catch.

The code

export function checkSurvivingPlaceholders(rootDir: string): {
  passed: boolean; files: Array<...>; total: number;
} {
  // ...walk, which begins: if (!existsSync(dir)) return;
  return { passed: total === 0, files, total };
}

passed is derived from total === 0 alone. Nothing records how many files were examined,
so "clean tree" and "never looked at anything" are indistinguishable to every caller.

Why it matters

Setup.md step 9(d) leans on this as a gate:

then checkSurvivingPlaceholders(<configRoot>) and require passed: true [...] a skipped
or mis-rooted pass is the difference between a system that knows the user's name and one
that addresses them as {{PRINCIPAL_NAME}}

The document explicitly anticipates a mis-rooted pass, but the function's return shape cannot
express one. A bad root produces a green result and the installer proceeds.

Reproduction

const r = checkSurvivingPlaceholders("/path/that/does/not/exist");
// => { passed: true, files: [], total: 0 }

Encountered for real: a mis-rooted call reported passed: true while Doctor.ts
simultaneously reported 68 unrendered placeholders across 26 sites in the same tree.

Suggested fix

Count scanned files and require a non-empty scan.

let scanned = 0;
const processFile = (filePath: string): void => {
  if (!TEMPLATE_EXTENSIONS.has(fileExtension(filePath))) return;
  scanned++;
  // ...
};
// ...
return { passed: total === 0 && scanned > 0, files, total, scanned };

Returning scanned also gives callers something to log, which makes a mis-rooted pass
obvious in transcripts rather than invisible.

Related

The #1874 / #1852 / #1993 cluster covers substituteTree corrupting the engine's own
IDENTITY_PLACEHOLDERS table. This is a distinct defect in the verification half: even
with a correct table, the gate cannot fail when it never ran.

[jbmml]

Confirmed on current main (5e2f2e8) and on a 7.40.4 install. LifeOS/install/skills/LifeOS/Tools/InstallEngine.ts:518 returns passed: total === 0 with no check that any file was read, so both a nonexistent root and an empty directory report success:

nonexistent                              -> passed=true  total=0 files=0
empty dir                                -> passed=true  total=0 files=0
positive control (placeholder present)   -> passed=false total=1 files=1
clean rendered dir                       -> passed=true  total=0 files=0

Fix in #2060: count the files actually read and require scanned > 0 && total === 0. Same four cases afterward: the first two fail, the positive control still fails, the clean dir still passes. The change is applied to both byte-identical copies (LifeOS/Tools/InstallEngine.ts, which Setup 9(d) runs, and the deployed LifeOS/install/skills/... copy, which Doctor.ts imports). Doctor.ts sums total and never reads passed, so it is unaffected. Report + fix produced by my DA against my install.