Paths relative to the payload root (LifeOS/install/); verified in the 7.40.4 release and byte-identical at current main.
The defect. BitterPillEngineering's instructions send its auditor after two settings keys that exist nowhere:
skills/BitterPillEngineering/SKILL.md:84 (Gotchas): "The loadAtStartup list in settings.json and postCompactRestore.fullFiles must stay in sync — if you remove a file from one, check the other."skills/BitterPillEngineering/Workflows/Audit.md:10-11 (step 1, "Discover what's loaded"): the first two bullets read loadAtStartup.files and postCompactRestore.fullFiles.
Neither key exists in any shipped settings file: jq 'has("postCompactRestore")' settings.system.json → false, and loadAtStartup appears in no shipped settings JSON. The payload's own LIFEOS/LIFEOS_StatusLine.sh:413 and :2366 describe loadAtStartup as empty since the v5.0 move to CLAUDE.md @-imports. So the skill whose whole job is finding dead instruction weight opens its audit hunting for keys that no longer ship, and its Gotchas list instructs keeping them "in sync" — an invitation to reintroduce them.
Not a duplicate of #1083/#1212/#1216/#799 — those are v4/v5-era startup/compaction proposals (all closed unmerged); this is instruction text pointing at keys that no longer ship.
One deliberate scope note: LIFEOS/LIFEOS_SYSTEM_PROMPT.md:196 also uses the word loadAtStartup — but as a prose label for the CLAUDE.md @-import block ("loadAtStartup @-imports carry identity + project context"), not as an instruction to read a settings key. The attached PR leaves that file alone (renaming a label in the system prompt is your call, not a docs-rot fix); flagging it here so a grep doesn't read as something I missed.
Fix (PR attached, 2 files, +1/−3):
SKILL.md:84 → a retirement statement that names the keys so a future auditor flags rather than reintroduces them: "Startup context comes from CLAUDE.md @-imports plus the dynamicContext settings key — loadAtStartup was retired at v5.0's move to @-imports, and postCompactRestore no longer ships in any settings file. A reference to either in an instruction file is dead weight to flag, not a sync obligation."Workflows/Audit.md:10-11 → both dead-key bullets deleted; the remaining dynamicContext and CLAUDE.md bullets are the real startup load.
Paths relative to the payload root (
LifeOS/install/); verified in the 7.40.4 release and byte-identical at currentmain.The defect. BitterPillEngineering's instructions send its auditor after two settings keys that exist nowhere:
skills/BitterPillEngineering/SKILL.md:84(Gotchas): "TheloadAtStartuplist in settings.json andpostCompactRestore.fullFilesmust stay in sync — if you remove a file from one, check the other."skills/BitterPillEngineering/Workflows/Audit.md:10-11(step 1, "Discover what's loaded"): the first two bullets readloadAtStartup.filesandpostCompactRestore.fullFiles.Neither key exists in any shipped settings file:
jq 'has("postCompactRestore")' settings.system.json→false, andloadAtStartupappears in no shipped settings JSON. The payload's ownLIFEOS/LIFEOS_StatusLine.sh:413and:2366describeloadAtStartupas empty since the v5.0 move to CLAUDE.md@-imports. So the skill whose whole job is finding dead instruction weight opens its audit hunting for keys that no longer ship, and its Gotchas list instructs keeping them "in sync" — an invitation to reintroduce them.Not a duplicate of #1083/#1212/#1216/#799 — those are v4/v5-era startup/compaction proposals (all closed unmerged); this is instruction text pointing at keys that no longer ship.
One deliberate scope note:
LIFEOS/LIFEOS_SYSTEM_PROMPT.md:196also uses the wordloadAtStartup— but as a prose label for the CLAUDE.md@-import block ("loadAtStartup@-imports carry identity + project context"), not as an instruction to read a settings key. The attached PR leaves that file alone (renaming a label in the system prompt is your call, not a docs-rot fix); flagging it here so a grep doesn't read as something I missed.Fix (PR attached, 2 files, +1/−3):
SKILL.md:84→ a retirement statement that names the keys so a future auditor flags rather than reintroduces them: "Startup context comes from CLAUDE.md@-imports plus thedynamicContextsettings key —loadAtStartupwas retired at v5.0's move to@-imports, andpostCompactRestoreno longer ships in any settings file. A reference to either in an instruction file is dead weight to flag, not a sync obligation."Workflows/Audit.md:10-11→ both dead-key bullets deleted; the remainingdynamicContextand CLAUDE.md bullets are the real startup load.