Fresh install: several subsystems reference private skills/files not present in the public release

[tzioup]

Hi — first, thank you for putting this out in the open; it's a lot of generous work, and I saw the recent move toward the agentic installer (#922), which is a great direction.

I've been running PAI v5 (on a VM) for a while and just set up a fresh LifeOS install to migrate over — so this is coming from a somewhat familiar starting point, not a first-day stumble. While getting oriented, I noticed a cluster of places where the shipped code, hooks, and docs point at skills or files that don't seem to be in the public payload — mostly private-looking ones (_LIFEOS, _COMMUNICATION, _HARVEST, etc.) and an Assistant Pulse module. They look like they might share a single root cause: references to private/maintenance infrastructure surviving into the public release. I'm raising it as one consolidated issue rather than a pile of separate ones, since it seems systemic and probably better handled as a release-time check than piecemeal — but happy to split it into per-item issues if you'd prefer that for triage. Nothing here is meant as a knock — just a map, in case it's useful.

Install context (so you can reproduce / rule out my setup): fresh LifeOS v7.1.1, fresh Claude Code instance, macOS. Only .claude/PAI/MEMORY and /USER were ported from an existing PAI v5 install (previously on a VM) into the new .claude/ before running /lifeos setup. No competing infrastructure — no prior skills, hooks, or settings files; just the PAI MEMORY/USER content for the installer to fold in. Most of the items below I also confirmed against the vanilla install payload (skills/LifeOS/install/), so they don't appear specific to my port.

Each item lists what I saw and where; I've tried to verify rather than assume.

Appears to affect a fresh/vanilla install too

• SystemFileGuard deny-list scan reads nothing. hooks/lib/system-file-guard-core.ts loads its deny-list + salted-hash files from skills/_LIFEOS/DENY_LIST.txt / DENY_HASHES.json; both are absent, and the loader returns [] on !existsSync. So the PII/privacy scan seems to pass everything silently — the guard looks active but may be inert. Flagging gently because it's privacy-adjacent.
• CommunicationSkillGuard blocks email sends with no shipped path forward. The hook (exit 2) blocks gmail.ts send / aws ses send-email unless carrying LIFEOS_SKILL=_COMMUNICATION, and directs the model to Skill("_COMMUNICATION") → skills/_COMMUNICATION/Workflows/SendEmail.md, which isn't in the release.
• Harvest's mandatory final step is unrunnable. skills/Harvest/SKILL.md documents bun ~/.claude/skills/_HARVEST/Tools/harvest.ts … as the always-run closing step; _HARVEST isn't shipped. (HarvestExecutor.ts also points here when ARBOL_HARVEST_API_BASE is unset, which it is by default.)
• derivedsync launchd job errors every run. It writes skills/_LIFEOS/DENY_HASHES.json; the dir doesn't exist, so it exits 1 with ENOENT (visible in its stderr log).
• Pulse /assistant/* routes 404. ObservabilitySystem.md / PulseSystem.md document ~8 DA endpoints sourced to Assistant/module.ts; that module isn't present, yet PULSE.toml has [da] enabled = true. (pulse.ts even comments that Assistant is "stripped from the public release payload" — so the code knows, but the config still expects it and the docs still list the routes as live.)
• Spinner tips advertise commands that don't ship. settings.enhancements.json spinnerTipsOverride lists ~89 /commands (e.g. /broadcast, /newsletter, /osint); only 3 command files exist in commands/ (context-search, cs, pu). New users see tips for tools they can't invoke.
• Unrendered placeholders in live prompts. Telegram/iMessage system prompts and chat logs contain literal {{DA_NAME}} / {{PRINCIPAL_NAME}}.
• Retired skill still in routing docs. DelegationSystem.md routes "custom agents" to Skill("Agents"), but AgentSystem.md says that skill was retired; skills/Agents/ isn't present.

Small path drifts — happy to send PRs for these (fix is unambiguous)

• skills/CreateSkill/Workflows/CanonicalizeSkill.md reads ~/.claude/LIFEOS/SkillSystem.md; real file is LIFEOS/DOCUMENTATION/Skills/SkillSystem.md.
• LIFEOS/USER_TEMPLATES/README.md copies from LIFEOS/USER/_TEMPLATES/; real dir is LIFEOS/USER_TEMPLATES/.
• LIFEOS/PULSE/setup.ts reads LIFEOS/USER/DA_IDENTITY.md; real path is LIFEOS/USER/DIGITAL_ASSISTANT/DA_IDENTITY.md.
• skills/Remotion/Tools/package.json main/scripts point at index.ts; the actual entrypoint is Render.ts (which has its own import.meta.main CLI). bun run render fails as written.

I'm happy to open PRs for the last group if that's helpful, and to help reproduce any of the others. Thanks again for the project.

---

Checked and deliberately left out as non-bugs: LocalIntelligence Crime is an explicitly-labeled "not yet implemented" TODO stub, not a silent break; observability tool-failures.jsonl volume turned out to be ordinary agent exit-codes, not a subsystem failure.

[tzioup]

One more: airgradient-poll cron job ships enabled = true by default (LIFEOS/PULSE/PULSE.toml, */5 * * * *, running LIFEOS/PULSE/checks/airgradient-poll.ts). It's a real poller, not a stub — docstring says it polls "{{PRINCIPAL_NAME}}'s place ({{PRINCIPAL_LOCATION}}, ID {{AIRGRADIENT_DEVICE_ID}})", i.e. one specific maintainer's specific sensors, template-scrubbed like the rest of this issue. Fails harmlessly on a fresh install but polls every 5 min forever, pure log noise.

Cache dir is LIFEOS/MEMORY/_AIRGRADIENT/ — same private naming convention as _NETWORK/_HELIOS. Of the three integrations ConfigSystem.md lists together (homebridge/unifi/airgradient), only this one actually ships working code and a default-on cron entry — the other two have no implementation. Looks like a personal job that should've been enabled = false (or isolated as a private _AIRGRADIENT skill) before release.