LifeOS

• A stranger on any supported OS and harness ends with a working, personalized install: Core placed after one consent, every enhancement they did not decline, identity placeholders gone, the lifeos launch command wired, and Pulse showing their own current and ideal state.
• Every change to the user's machine was shown before it happened and is reversible: settings and shell rc are backed up first, updates and uninstalls move or back up instead of deleting, and nothing the user authored is overwritten.
• Setup completes and its hooks and integration are in place before the Interview writes anything.
• Nothing changes without an explicit yes, during the install and afterwards, unless the user turned on the opt-in automode component (Intents/Setup.md step 7), which ships off and needs a clear yes.
• Every "installed", "updated" or "removed" claim rests on the evidence the intent names, and a capability the user declined is reported as declined, never as broken.
• Feedback sent upstream is redacted, reproducible and posted only on the user's own yes.

doctor is the one tool-backed route: Doctor.ts prints each capability's state and the fix for anything broken. Relay it and honor decline (Setup step 9.6).

<configRoot> is the harness config dir DetectEnv reports (on Claude Code, $CLAUDE_CONFIG_DIR when set, else ~/.claude). The user tree is reached at <configRoot>/LIFEOS/USER once LinkUser has linked it in.

• USER/CONFIG/LIFEOS_CONFIG.toml holds the DA name and voice and the [principal] identity. Interview writes it; Update reads it to re-render identity placeholders.
• USER/PRINCIPAL/PRINCIPAL_IDENTITY.md (prose only; names and voice live in LIFEOS_CONFIG.toml) and USER/TELOS/TELOS.md are written by Interview; SeedPulse derives LIFEOS_STATE.json and PRINCIPAL_TELOS.md from them.
• USER/CUSTOMIZATIONS/SKILLS/LifeOS/Config.md holds install_host, the host that serves INSTALL.md and install/install.sh (written as ourlifeos.ai in this skill), and spinner_verbs_file, the optional spinnerVerbs.json beside it that the spinnerverbs component deploys in place of the shipped list, and pulse_templates_dir, the USER template tree Tools/ScaffoldUser.ts copies from and Tools/PulseHealth.ts audit compares USER/ against (default <configRoot>/skills/LifeOS/install/USER; an explicit --skill-root wins for ScaffoldUser). Every key, the file shape and a proof run: Setup.md.
• <configRoot>/LIFEOS/MEMORY/STATE/reports/current/ holds the Report intent's in-progress report; Report.ts reset clears it.

• The frontmatter version: is the COMPONENT line, not the release. Claude Code ignores it; the maintainer-side BumpSkillVersions (not shipped) maintains it at the source repo. The DISTRIBUTION version, what a user means by "LifeOS 7.x", is the GitHub release tag + LIFEOS_RELEASES/<version>/ + the install.sh fetch. Never read the component line as the release number.
• Config root keeps its canonical name. The user tree lives under the config dir and is linked into the harness tree; "LifeOS" is the brand, the resolved config path does not rename (renaming it breaks the identity @-imports).
• Dev-tree refusal checks one marker. The install tools refuse to run inside the LifeOS source repo. detectDevTree (Tools/InstallEngine.ts) checks one thing: whether the maintainer-side release skill directory exists under the config root. It does not look at git remotes, so a source checkout without that private skill is not detected. --allow-dev overrides the refusal on the tools that accept it (InstallSettings.ts, ActivateImports.ts and others). Never mutate the author's live system.
• Config is .toml, never .yaml. LifeosConfig.ts reads TOML; the legacy .yaml template was retired 2026-06-19.
• Every install tool is a dry run without --apply (InstallAll: --yes). Between 2026-07-08 and 2026-07-31 the documented update path omitted it, and users saw success-shaped output while nothing changed.

• "install LifeOS" → Setup, then Interview: Core and every enhancement not declined are in place with permission at each step, hooks fire, and the user rolls straight into onboarding.
• "run the lifeos interview" → Interview: TELOS and current/ideal state captured, the user's sources merged in, Pulse showing real rings.
• "lifeos doctor" → Doctor.ts: the capability table, with the fix command offered for anything broken.
• "audit pulse setup" → PulseHealth.ts audit: one status block with real counts for the schema tool, provenance of the USER template copies, missing templates and /healthz, NOT RUN shown as such.
• "update LifeOS" → Update: the install is on the latest release with the user's data untouched, or reported already current.
• "report this bug to LifeOS" → Report: a redacted five-field issue the user has read, posted only on their yes. "contribute this fix" adds a green run and a PR on top; "suggest this to the project" files a discussion instead.