6.0.0: settings.system.json contract mismatch — payload ships it without hooks, MemoryHealthCheck requires hooks registered in it (fresh installs report CRITICAL)

[infinitelyloopy-bt]

Components: install/settings.system.json, Setup workflow step 4, LIFEOS/TOOLS/MemoryHealthCheck.ts / MemoryHealthGate.hook.ts, LifeOS 6.0.0.

What happens: three parts of 6.0.0 disagree about what settings.system.json is:

1. The payload ships install/settings.system.json deliberately without a hooks block ('the system half WITHOUT the hooks block; InstallHooks owns hooks' — Setup.md).
2. Setup.md step 4 overlays it as settings.json, so nothing ever lands at ~/.claude/settings.system.json.
3. MemoryHealthCheck.ts treats ~/.claude/settings.system.json as a required regression-reference file and reports CRITICAL if it's missing — and once you copy the shipped one there, it still reports CRITICAL because the four memory hooks (MemoryReviewTrigger, MemoryReviewFire, MemoryHealthGate, MemoryDeltaSurface) aren't registered inside it.

Net effect: every fresh 6.0.0 install surfaces 🩺 MEMORY HEALTH: CRITICAL via MemoryHealthGate even when the live settings.json wiring is complete and correct.

Repro: fresh 6.0.0 install per INSTALL.md → bun LIFEOS/TOOLS/MemoryHealthCheck.ts → settings-missing:settings.system.json (critical); copy the payload file in → four settings-hook-missing:... criticals.

Workaround: compose the file as payload system-half + the hooks object from install/hooks/hooks.json and write it to ~/.claude/settings.system.json — health then passes (warn-only).

Suggested fix: pick one contract — either ship settings.system.json including the canonical hooks block and have Setup place it at the config root, or drop the settings.system.json checks from MemoryHealthCheck for skill-payload installs.

[rpriven]

One more data point on the contract mismatch, from a Linux (Debian) install: the merged SessionStart hook chain runs MergeSettings.ts every session with --system ~/.claude/settings.system.json --output ~/.claude/settings.json — i.e., against the file setup never places.

Verified the failure mode is at least fail-safe. When the system file is absent, MergeSettings.ts (lines ~465–468) no-ops cleanly:

MergeSettings: input(s) absent (system/user settings layer not established) — nothing to merge

exit 0, output file untouched — confirmed both in source and live on our install.

So severity stays where you put it (cosmetic: permanent statusline PROBLEM + memory-health.jsonl logging overall: critical on a healthy fresh install) — but it means the intended settings-layering feature is silently dead on every install where the file was merged rather than placed. Placing the file (or teaching the health check + merge chain about the merged layout) revives the layering, not just the indicator.