ProposalScope.listProjects() requires bold project names that the shipped PROJECTS.md scaffold does not produce — every project-scoped proposal silently routes global #2175

Summary

ProposalScope.listProjects() only recognises a project row when the first table cell is bold. The LIFEOS/USER/PROJECTS.md scaffold that ships with LifeOS writes that cell unbolded. On a clean install, following the scaffold as written, listProjects() returns [] and no project is ever detected. Project-scoped memory proposals then classify as global and accumulate in the always-on rules file.

Checked against main at 5e2f2e8c, LIFEOS/VERSION 7.40.4.

Detail

LIFEOS/TOOLS/ProposalScope.ts, listProjects():

for (const line of readFileSync(path, "utf8").split("\n")) {
  if (!line.startsWith("|")) continue;
  const m = line.match(/^\|\s*\*\*([^*|]{2,40})\*\*/);
  if (m) names.add(m[1].trim());
}

The regex requires **Name** in the first cell.

LIFEOS/USER/PROJECTS.md as shipped:

| Project | Path | URL | Deploy | Stack |
|---------|------|-----|--------|-------|
| (interview — first project) | `~/code/example` | example.com | `bun run deploy` | TS, React |

The first cell is plain text. It will never match, so a user who fills in the scaffold in the shape it was given gets an empty project list.

Reproduction

1. Fresh install. Fill in LIFEOS/USER/PROJECTS.md following the shipped scaffold, leaving the name cell unbolded.
2. bun -e 'import {listProjects} from "./LIFEOS/TOOLS/ProposalScope.ts"; console.log(listProjects())'
3. Observed: []. Expected: the project names.

Found on a 47-row table. Every row was unbolded, so the count was zero.

Impact

listProjects() feeds loadScopeTables() and classifyScope(), consumed by MemorySystem.ts and ProposalGC.ts. With an empty project list, a proposal that names a project cannot classify as project-scoped, so it routes global.

The failure is silent. There is no warning, and the only symptom is the always-on rules file growing rules that belong to a single project. On the install where this was found, that file had reached 65 KB with roughly twenty single-project rules in it.

It is also self-reinforcing: the larger that file grows, the more it costs every unrelated session, and nothing in the loop reports that the router is returning nothing.

Suggested fix

Either would work, and the second is a one-character change per row:

1. Relax the regex to accept an optionally-bold first cell, e.g. /^\|\s*(?:\*\*)?([^*|]{2,40}?)(?:\*\*)?\s*\|/, skipping header and separator rows explicitly.
2. Bold the name in the shipped scaffold, so the template matches what the parser requires.

Option 1 seems the more forgiving, since someone editing a Markdown table has no way to know that bold is load-bearing. If bold is intended to be required, it would help to say so in the scaffold's header comment.

Either way, listProjects() warning when a PROJECTS.md containing table rows yields zero names would turn this from silent into obvious — an empty list from a non-empty table is always a parse failure rather than a legitimate state.

Related

#2077 is in the same subsystem but a different failure: that one is about target_kind not being validated, this one is about the project list being empty before any classification happens. Not a duplicate, but they compound.