InterviewScan.ts checks v5.0.0 flat USER paths instead of v6.0.5 nested schema — false 'file does not exist' for populated PRINCIPAL_IDENTITY.md/DA_IDENTITY.md/PROJECTS.md

[Rubix-BNL]

Component: LifeOS/install/LIFEOS/TOOLS/InterviewScan.ts, LifeOS 6.0.5 (confirmed byte-identical on current main — not yet fixed).

Reproducible steps

1. Fresh LifeOS 6.0.5 install onto an existing ~/.claude (i.e. Core deploy + hooks + ScaffoldUser/LinkUser, per INSTALL.md).
2. Populate identity for real (via /interview, or via migrated content from an older PAI install) so that:
   • USER/PRINCIPAL/PRINCIPAL_IDENTITY.md exists and is fully populated
   • USER/DIGITAL_ASSISTANT/DA_IDENTITY.md exists and is fully populated
   • USER/PROJECTS.md exists and is fully populated
3. Run the routing probe documented in the Interview skill's own routing decision:

   bun ~/.claude/LIFEOS/TOOLS/InterviewScan.ts --json | jq '[.targets[] | select(.phase == 0 and .completeness_score < 80)] | length'
   

Expected behavior

The probe should report 0 (or at least not flag these three specific files), since they exist and are fully populated at their correct v6.0.5 paths, and the routing decision should send /interview straight to ContextCheckin (review mode) rather than Phase0Setup (from-scratch setup).

Actual behavior

The probe returns 5 phase-0 targets, three of which are false positives:

{
  "phase": 0,
  "path": "/Users/<user>/.claude/LIFEOS/USER/DA_IDENTITY.md",
  "name": "DA_IDENTITY",
  "completeness_score": 0,
  "why_incomplete": ["file does not exist"]
},
{
  "phase": 0,
  "path": "/Users/<user>/.claude/LIFEOS/USER/PRINCIPAL_IDENTITY.md",
  "name": "PRINCIPAL_IDENTITY/setup",
  "completeness_score": 0,
  "why_incomplete": ["file does not exist"]
},
{
  "phase": 0,
  "path": "/Users/<user>/.claude/LIFEOS/USER/PROJECTS/PROJECTS.md",
  "name": "PROJECTS/setup",
  "completeness_score": 0,
  "why_incomplete": ["file does not exist"]
}

All three files exist, fully populated, at their correct v6.0.5 paths — just not at the paths the scanner checks.

Root cause

InterviewScan.ts still hardcodes the pre-6.0.0 flat USER/ layout instead of the current nested v6.0.5 schema shipped by DeployCore/ScaffoldUser's own templates:

const USER_DIR = join(LIFEOS_DIR, "USER");
...
{ phase: 0, path: join(USER_DIR, "DA_IDENTITY.md"), name: "DA_IDENTITY", ... }                    // line 73
{ phase: 0, path: join(USER_DIR, "PRINCIPAL_IDENTITY.md"), name: "PRINCIPAL_IDENTITY/setup", ... } // line 78
{ phase: 0, path: join(USER_DIR, "PROJECTS", "PROJECTS.md"), name: "PROJECTS/setup", ... }         // line 92
{ phase: 4, path: join(USER_DIR, "PRINCIPAL_IDENTITY.md"), name: "PRINCIPAL_IDENTITY", ... }        // line 211

The actual v6.0.5-shipped USER/ structure (verified against the templates ScaffoldUser.ts deploys, not anything install-specific) nests these under:

• USER/PRINCIPAL/PRINCIPAL_IDENTITY.md (not USER/PRINCIPAL_IDENTITY.md)
• USER/DIGITAL_ASSISTANT/DA_IDENTITY.md (not USER/DA_IDENTITY.md)
• USER/PROJECTS.md — a flat file (not USER/PROJECTS/PROJECTS.md, a nested dir)

Why this is an upstream bug, not a local/migration issue

A direct diff between LifeOS/install/LIFEOS/TOOLS/InterviewScan.ts at the v6.0.5 tag and the current main HEAD is byte-identical — no commit has touched this file since release 6.0.2 (2026-07-03, commit 5468ccd8), which predates the 6.0.0 nested-schema rename entirely. Every fresh v6.0.5 install populating identity via /interview or migration hits this, since the scanner was never updated when the nested schema shipped. This is not specific to any non-standard install path — the paths it checks against don't match what LifeOS's own ScaffoldUser template payload produces.

Suggested fix

Update the four path constructions above (lines 73, 78, 92, 211) to the nested schema:

join(USER_DIR, "DIGITAL_ASSISTANT", "DA_IDENTITY.md")
join(USER_DIR, "PRINCIPAL", "PRINCIPAL_IDENTITY.md")   // both phase-0 and phase-4 entries
join(USER_DIR, "PROJECTS.md")

No routing-logic or heuristic changes needed — this is a pure path-constant fix.

Impact

Low-severity but broad: since InterviewScan.ts's output only drives the Phase0Setup-vs-ContextCheckin routing decision documented in the Interview skill, the practical effect is that populated installs can get incorrectly routed into from-scratch Phase0Setup instead of a review-mode ContextCheckin. Worth noting alongside the related but distinct path-mismatch issues already fixed (#1357/#1244, #1181) — this looks like the same class of bug recurring in a different set of files that weren't covered by those fixes.

---

Filed after confirming no existing open/closed issue, PR, or commit covers this exact mismatch (searched for InterviewScan, USER_DIR, PRINCIPAL_IDENTITY, DIGITAL_ASSISTANT combinations, and diffed the file directly between v6.0.5 and main).

[danielmiessler]

Thanks — your root-cause is exactly right, and it was indeed the same path-schema class recurring in a file the earlier fixes didn't cover. All four registry entries are updated in the development source to the nested schema (DIGITAL_ASSISTANT/DA_IDENTITY.md, PRINCIPAL/PRINCIPAL_IDENTITY.md for both phase-0 and phase-4, and flat PROJECTS.md), and I verified your exact probe now returns 0 phase-0 false positives on a fully populated install. Ships with the next release. Closing as integrated.