Summary
Upgrading an existing install from v7.1.1 → v7.28.3 via the documented Update path (bash install/install.sh then the LifeOS skill's Update workflow) surfaced two gaps: a hook-wiring manifest that's missing several new hooks entirely, and a documented "re-overlay system" step that has no automated tool behind it.
Environment
- ThinkPad (few months old), Ubuntu 24.04.4 LTS
- Claude Code, existing install predating the VERSION marker convention (was on v7.1.1)
1. New hooks shipped but absent from install/hooks/hooks.json
InstallHooks.ts --apply correctly detected 11 hook files present in the release payload's install/hooks/ directory that have no entry anywhere in install/hooks/hooks.json (checked via direct grep — zero occurrences), so it copied the files but could not wire them into settings.json:
SystemChangeSurface.hook.ts (this one turned out to be fine — it's invoked by composition from inside PostToolObserver.hook.ts, not via a standalone manifest entry, so no fix needed here once PostToolObserver.hook.ts itself is updated)
VersionDrift.hook.ts
ISAGate.hook.ts
ISACloseGate.hook.ts
ISAFoldGate.hook.ts
ISAStaleWriteGuard.hook.ts
SpendAuditor.hook.ts
KnowledgeWriteGuard.hook.ts
ModelRungGuard.hook.ts
AtlasEventCapture.hook.ts
TimeContext.hook.ts
The remaining 10 (everything except SystemChangeSurface) have no hooks.json entry, so there's no manifest-sanctioned event/matcher to install them against. I chose not to hand-wire them on a live personal install by guessing trigger config from header comments — the risk of a wrong PreToolUse/Stop matcher misfiring on a daily-use system outweighs getting these features immediately. They currently sit on disk as inert, unwired code.
2. Unsubstituted {{PRINCIPAL_NAME}} in a functional (non-comment) string
While reviewing the above hooks before considering wiring them, ModelRungGuard.hook.ts had {{PRINCIPAL_NAME}} inside an actual emitted message string (not a comment):
`Do not ask which rung to use, and do not ask ` +
`{{PRINCIPAL_NAME}} to change /model.`,
If this hook ever fires unwired-then-later-wired without the onboarding substitution pass running, it would print the literal placeholder to the user. Several other hooks have {{PRINCIPAL_NAME}} too, but those are all inside comments (harmless). Worth a payload-wide grep for {{PRINCIPAL_NAME}} outside comments as a release gate.
3. Workflows/Update.md step 3 ("Re-overlay system") has no implementing tool
The Update workflow document says:
Re-overlay system — re-copy the system templates (CLAUDE, system prompt, settings.system.json minus hooks), and overwrite <configRoot>/LIFEOS/VERSION with the payload's version
But there's no script in Tools/ that does this — DeployCore.ts and DeployComponents.ts handle skills/runtime/dependencies, not CLAUDE.md or LIFEOS_SYSTEM_PROMPT.md. I ended up hand-diffing CLAUDE.template.md against the live CLAUDE.md (confirmed the only real difference was the routing-table content plus the identity-import comment state, which ActivateImports.ts --apply correctly restored after the file swap) and hand-copying LIFEOS_SYSTEM_PROMPT.md + the renamed RULES/VerificationExpanded.md → RULES/Verification.md (plus Philosophy.md, SelfHealing.md), with manual {{PRINCIPAL_NAME}} substitution in the system prompt frontmatter. This worked, but it's real manual diligence a less careful update run could skip, silently leaving a stale system prompt/CLAUDE.md alongside a bumped VERSION marker.
Suggested fixes
- Add the 11 hooks above to
install/hooks/hooks.json with their documented triggers (each file's header comment already states the intended TRIGGER).
- Add a release gate grepping for
{{PRINCIPAL_NAME}} (and other {{...}} placeholders) outside comments across the payload.
- Build the actual "re-overlay system" tool
Workflows/Update.md step 3 describes, so CLAUDE.md/system-prompt/RULES updates aren't a manual diff-and-copy exercise.
Summary
Upgrading an existing install from v7.1.1 → v7.28.3 via the documented Update path (
bash install/install.shthen the LifeOS skill's Update workflow) surfaced two gaps: a hook-wiring manifest that's missing several new hooks entirely, and a documented "re-overlay system" step that has no automated tool behind it.Environment
1. New hooks shipped but absent from
install/hooks/hooks.jsonInstallHooks.ts --applycorrectly detected 11 hook files present in the release payload'sinstall/hooks/directory that have no entry anywhere ininstall/hooks/hooks.json(checked via direct grep — zero occurrences), so it copied the files but could not wire them intosettings.json:SystemChangeSurface.hook.ts(this one turned out to be fine — it's invoked by composition from insidePostToolObserver.hook.ts, not via a standalone manifest entry, so no fix needed here oncePostToolObserver.hook.tsitself is updated)VersionDrift.hook.tsISAGate.hook.tsISACloseGate.hook.tsISAFoldGate.hook.tsISAStaleWriteGuard.hook.tsSpendAuditor.hook.tsKnowledgeWriteGuard.hook.tsModelRungGuard.hook.tsAtlasEventCapture.hook.tsTimeContext.hook.tsThe remaining 10 (everything except
SystemChangeSurface) have nohooks.jsonentry, so there's no manifest-sanctioned event/matcher to install them against. I chose not to hand-wire them on a live personal install by guessing trigger config from header comments — the risk of a wrongPreToolUse/Stopmatcher misfiring on a daily-use system outweighs getting these features immediately. They currently sit on disk as inert, unwired code.2. Unsubstituted
{{PRINCIPAL_NAME}}in a functional (non-comment) stringWhile reviewing the above hooks before considering wiring them,
ModelRungGuard.hook.tshad{{PRINCIPAL_NAME}}inside an actual emitted message string (not a comment):If this hook ever fires unwired-then-later-wired without the onboarding substitution pass running, it would print the literal placeholder to the user. Several other hooks have
{{PRINCIPAL_NAME}}too, but those are all inside comments (harmless). Worth a payload-wide grep for{{PRINCIPAL_NAME}}outside comments as a release gate.3.
Workflows/Update.mdstep 3 ("Re-overlay system") has no implementing toolThe Update workflow document says:
But there's no script in
Tools/that does this —DeployCore.tsandDeployComponents.tshandle skills/runtime/dependencies, notCLAUDE.mdorLIFEOS_SYSTEM_PROMPT.md. I ended up hand-diffingCLAUDE.template.mdagainst the liveCLAUDE.md(confirmed the only real difference was the routing-table content plus the identity-import comment state, whichActivateImports.ts --applycorrectly restored after the file swap) and hand-copyingLIFEOS_SYSTEM_PROMPT.md+ the renamedRULES/VerificationExpanded.md→RULES/Verification.md(plusPhilosophy.md,SelfHealing.md), with manual{{PRINCIPAL_NAME}}substitution in the system prompt frontmatter. This worked, but it's real manual diligence a less careful update run could skip, silently leaving a stale system prompt/CLAUDE.md alongside a bumped VERSION marker.Suggested fixes
install/hooks/hooks.jsonwith their documented triggers (each file's header comment already states the intendedTRIGGER).{{PRINCIPAL_NAME}}(and other{{...}}placeholders) outside comments across the payload.Workflows/Update.mdstep 3 describes, soCLAUDE.md/system-prompt/RULES updates aren't a manual diff-and-copy exercise.