Clean up stray legacy PAI/Kai branding remnants (cosmetic only)

[elhoim]

Summary

Cleans up a small number of stray legacy "PAI"/"Kai" branding remnants in the skills — verified individually against this repo's own content, not a find-and-replace.

Each candidate string was classified as either a cosmetic remnant (safe to modernize — prose/identifier with no functional effect) or a functional identifier (a real path, trigger phrase, or flow name that code/users actually depend on). Only the cosmetic ones are changed here.

Changes

File	Change	Why it's safe
LifeOS/install/skills/Art/Tools/Generate.ts	stampKaiSignature → stampDaSignature	Private, non-exported function, only one call site, both in this same file. The text it actually stamps is already the generic {{DA_NAME}} template — only the internal function name still said "Kai".
LifeOS/install/skills/Remotion/Tools/Theme.ts	PAITheme/PAIColors/PAITypography/PAIAnimation → LifeosTheme/LifeosColors/LifeosTypography/LifeosAnimation	Repo-wide search shows these exported type aliases are referenced nowhere else in the repo — dead branding left behind by the codebase's earlier Pai* → Lifeos* identifier sweep, which appears to have missed this file.
LifeOS/install/skills/CreateCLI/SKILL.md	Example --repo pai → --repo myrepo	Purely an illustrative value in a usage example, not a real repo/flag/identifier.
LifeOS/install/skills/LifeOS/install/settings.enhancements.json	Fact string "...runs from PAI/LIFEOS_StatusLine.sh." → "...runs from LIFEOS/LIFEOS_StatusLine.sh."	Stale doc string — the repo's own install layout and deploy code (LifeOS/Tools/DeployComponents.ts) use LIFEOS/ throughout with zero PAI references, so the fact told to the DA no longer matched reality. This file is JSON, not .md, so it fell outside the repo's earlier "prose branding" doc sweep.

Found but intentionally NOT changed — why

These all matched "PAI"/"Kai" but are load-bearing, not cosmetic:

• Knowledge/SKILL.md — references pai-knowledge-linking-architecture.md. This file also appears to be missing/dangling already; renaming the reference wouldn't fix that, and could make the drift harder to spot. Left for a maintainer to resolve directly.
• Interceptor/SKILL.md — /tmp/pai-screenshots/. Verified functional: install/hooks/ContextReduction.hook.sh literally does mkdir -p /tmp/pai-screenshots && cd's there before rewriting Interceptor --save calls. Renaming the doc without touching the hook would break the documented behavior.
• Upgrade/SKILL.md — "pai upgrade" in the USE WHEN trigger list. A real, user-typed trigger phrase; removing it silently drops a working trigger.
• CreateSkill/Workflows/CreateSkill.md and UpdateSkill.md — `UpdateKaiRepo` ship-flow name, invoked by the (templated-out) private release skill at version-bump time. A real flow name, not prose.
• Daemon/Tools/SecurityFilter.ts — (?:LIFEOS|PAI)/USER/, (?:LIFEOS|PAI)/MEMORY/, PAI/Algorithm/v[\d.]+\.md regexes. Deliberate dual-branding patterns in the public-daemon-profile security scrubber — removing PAI narrows what gets redacted. Security-relevant, not cosmetic.
• Daemon/Tools/DaemonAggregator.ts — thesis.match(/PAI\/|hooks\/|.../) gates which knowledge ideas get treated as "internal architecture" and skipped. Changing the pattern changes filtering behavior; out of scope for a branding-only PR (possibly worth its own look — it doesn't also match LIFEOS/).
• LifeOS/Tools/InstallEngine.ts — comments describing detection of "a prior LifeOS/PAI install". These correctly document real backward-compatibility logic for legacy installs; not a remnant.

No filesystem paths, usernames, or credentials from any local environment are referenced anywhere in this diff.

[danielmiessler]

Thanks — this is exactly the kind of PR I want. You verified each candidate against the repo instead of blind find-and-replace, and every call in the "found but NOT changed" list was right, especially leaving the dual-brand regexes in SecurityFilter alone.

One quirk of this repo: the public tree is a generated artifact, rsync'd from my private source at release time, so anything merged only here gets wiped on the next release. The way I adopt community changes is to port them into source with credit, which I've done. All four of your changes are in as-is and will ship with the next release.

Good catch on DaemonAggregator too (the internal-architecture filter matches PAI/ but not LIFEOS/). Tracking that as a follow-up.

Closing because it's ported, not because it was rejected. Thanks again.