Related to #1724, which covers the same underlying fragility on the update path (Update.md step 3 has no re-overlay tool). This is the fresh-install sibling, via the AI-native install page, with a distinct sharp edge: the silent ok:true.
The dangerous part first: ActivateImports returns ok: true with an empty activation list. A success code on zero work means an install can leave every identity import dead while reporting success — the assistant then runs on {{PRINCIPAL_NAME}}/{{DA_NAME}} placeholders and nothing signals a problem.
Verified in source: ActivateImports.ts:59 hardcodes ok: true on the --apply path regardless of how many imports activated; written is the only zero-work signal. InstallEngine.activateImports (:717) returns an empty {activated, skipped} when CLAUDE.md is absent (no throw). So --apply with no CLAUDE.md present yields ok: true silently. Note the asymmetry: the dry-run path (ActivateImports.ts:39-42) does error on missing CLAUDE.md — only --apply is silent, which is backwards from what you'd want.
How it was reached on a fresh Linux user: on the AI-native path, CLAUDE.md was not yet in place when ActivateImports --apply ran, so it activated nothing and still reported success. (I can't quote the served ourlifeos.ai/install page's exact steps — it isn't in the release payload — so I'm not asserting the page's wording; what's certain is the fresh flow reached ActivateImports before CLAUDE.md existed.) The installing assistant caught it by cross-reading Workflows/Setup.md, which is correct (places CLAUDE.template.md→CLAUDE.md at :30-31, runs InstallSettings :33, then ActivateImports :55), placed the file, and re-ran — all imports then activated. So the Setup workflow is right; the gap is the fresh path reaching activation too early. (Consistent with #1724's part 2 — unsubstituted {{PRINCIPAL_NAME}} in functional strings — same placeholder-survives-silently mode from a different entry point.)
Suggested fix (the first is the load-bearing one):
- Make
ActivateImports fail loudly — or at minimum warn — when its import target doesn't exist. ok: true on zero activations is the trap regardless of how you got there.
- Add the CLAUDE.md/InstallSettings overlay step to the install page so the fresh path matches the Setup workflow.
Environment: Debian 13 (headless), Claude Code 2.1.220, bun 1.3.14, fresh OS user, installed via https://ourlifeos.ai/install at tag v7.28.3 (36c6f01). All line references are to this tag. One of four reports from the same fresh-install trial.
— Reported by Rob Pratt (@rpriven), co-authored with Kai.
Related to #1724, which covers the same underlying fragility on the update path (Update.md step 3 has no re-overlay tool). This is the fresh-install sibling, via the AI-native install page, with a distinct sharp edge: the silent
ok:true.The dangerous part first:
ActivateImportsreturnsok: truewith an empty activation list. A success code on zero work means an install can leave every identity import dead while reporting success — the assistant then runs on{{PRINCIPAL_NAME}}/{{DA_NAME}}placeholders and nothing signals a problem.Verified in source:
ActivateImports.ts:59hardcodesok: trueon the--applypath regardless of how many imports activated;writtenis the only zero-work signal.InstallEngine.activateImports(:717) returns an empty{activated, skipped}whenCLAUDE.mdis absent (no throw). So--applywith noCLAUDE.mdpresent yieldsok: truesilently. Note the asymmetry: the dry-run path (ActivateImports.ts:39-42) does error on missingCLAUDE.md— only--applyis silent, which is backwards from what you'd want.How it was reached on a fresh Linux user: on the AI-native path,
CLAUDE.mdwas not yet in place whenActivateImports --applyran, so it activated nothing and still reported success. (I can't quote the servedourlifeos.ai/installpage's exact steps — it isn't in the release payload — so I'm not asserting the page's wording; what's certain is the fresh flow reachedActivateImportsbeforeCLAUDE.mdexisted.) The installing assistant caught it by cross-readingWorkflows/Setup.md, which is correct (placesCLAUDE.template.md→CLAUDE.mdat:30-31, runs InstallSettings:33, then ActivateImports:55), placed the file, and re-ran — all imports then activated. So the Setup workflow is right; the gap is the fresh path reaching activation too early. (Consistent with #1724's part 2 — unsubstituted{{PRINCIPAL_NAME}}in functional strings — same placeholder-survives-silently mode from a different entry point.)Suggested fix (the first is the load-bearing one):
ActivateImportsfail loudly — or at minimum warn — when its import target doesn't exist.ok: trueon zero activations is the trap regardless of how you got there.Environment: Debian 13 (headless), Claude Code 2.1.220, bun 1.3.14, fresh OS user, installed via
https://ourlifeos.ai/installat tagv7.28.3(36c6f01). All line references are to this tag. One of four reports from the same fresh-install trial.— Reported by Rob Pratt (@rpriven), co-authored with Kai.