LifeOS 品牌重命名工程解析RenamePlan 分波次策略、RenameMap.json 映射表与切日运行手册【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本文围绕 LifeOS 仓库中的重命名计划文档 RenamePlan.md 展开一个将系统从旧标识PAI迁移到LifeOS的分阶段重命名工程。读完你将掌握三个可迁移的工程能力如何用“机器可读映射表 分层裁决”驱动跨数千文件的大规模改名如何让隐私/清理门禁scrub gate随重命名同步演进以避免静默失效以及如何设计带彩排、带探针的“切日cut-day运行手册”。一、为什么全局改名不是“查找替换”一条铁律文档开宗明义给出了整个计划的核心约束半截重命名half-rename是一种静默的隐私回退比直接破坏更糟。一个用 grep 搜索某个已不存在 token 的清理门禁会“空转通过”pass vacuously——检查项还在但它守的边界已经消失了。因此每个重命名阶段都必须在同一个变更里更新门禁且门禁必须从RenameMap.json读取而非硬编码旧标识。这条铁律解释了为什么 LifeOS 的改名不是一次grep -r全局替换而是一个分波次、有状态机、有门禁联动、有回退 shim 的工程项目。它保护的对象很具体LifeOS 的公开发布流程中存在一套隐私/清理门禁ShadowRelease G1–G14、sync-docs 规则、DenyListCheck 等这些门禁负责在公开树中擦除私有标识。如果门禁仍按旧 token 列表扫描而代码里旧 token 已被删光门禁就会“全部通过”却实际失去拦截能力——这正是文档警告的“静默隐私回退”。二、单一事实来源RenameMap.jsonRenamePlan.md 明确自己是叙述性文档机器可读的配套文件是同目录下的 RenameMap.json。重命名工具与所有隐私/清理门禁都消费这个 JSON永远不消费硬编码 token 列表——这是“门禁与重命名同变更”这条铁律的落地机制。映射表的关键结构可以分四层看2.1 大小写约定casing场景约定散文/品牌/UI一律LifeOSPascalCase 文件名仅在文件名约定强制时保留LifeOs如LifeOsThesis.md带空格的Life OS已退役retired这一约定本身就是一次独立的“波次”状态表中“Casing standardization”一行标记为 2026-06-13 完成核心文件并统一了散文层的写法避免LifeOS/Life Os/PAI等混写。2.2 三层策略strata历史层、过渡层、目标层映射表把改名对象按“能否被改写”分为三层这是避免“一刀切”的关键历史层historicalNEVER rewrittengit 历史与提交信息、旧路径命名的会话目录、MEMORY/WORK下的归档 ISA 与分析文件、已发布的公开 URL、LIFEOS/ALGORITHM/v*.md归档的算法快照。这些内容被刻意保留旧名——改名文档必须能“命名它改过名的东西”这也是RenamePlan.md自身标题故意引用退役标记文档内注释引用了公开 issue #1554一次 2026-07-04 的盲扫把文档自己的标题改写成了 LifeOS → LifeOS的原因。过渡层transitionalshim 保留一个发布周期后退役文件系统兼容符号链接、LIFEOS_DIR/LIFEOS_CONFIG_DIR等环境变量的读回退别名、GitHub 仓库重定向。目标层target按第 2.3 节分类裁决立即改或在 cut 时改。2.3 九类裁决classes规模 裁决 破坏点映射表把改名对象切成 9 个类每类标注规模行数/文件数/出现次数、裁决verdict与具体破坏点。核心信息如下类名称规模裁决1docs-prose-branding4566 行 / 572 文件rename-now2026-07-04 完成仅扫 .md 文档散文2pulse-ui-display-strings298 行 / 74 文件rename-nowMenuBar 应用包与 logo 资源路径例外留到 cut3filesystem-paths-dirs3979 行 / 662 文件rename-at-cut原子操作 一个发布周期的兼容 symlink4env-vars-config-keys1341 处 / 311 文件rename-at-cut-with-shim新名引入PAI_*读回退保留一个版本5code-identifiers194 处 / 49 文件原定 at-cut-or-never实际 2026-07-04 提前完成6repo-remote-names86 行 / 35 文件rename-at-cut——GitHub 仓库改名本身就是 cut7core-management-skill235 处 / 99 文件rename-at-cut经 CreateSkill 流程与类 3/4 同扫保证路由永不指向死名8mode-banners-hook-regexes3 个字面量 / 2 个 hookrename-at-cutprompt 与 hook 字面量在一次协调提交中保持字节级一致9context-block-tags5 个标签 / 6 代码文件 / 4 文档rename-now-with-dual-accept读者双前缀兼容窗口两个细节尤其值得注意类 1 的“盲扫禁区”文档明确记录2026-07-04 的散文扫描只碰.md文档且刻意不扫代码字符串/正则/路径中的裸PAI——“那属于类 3/4在那里盲扫会破坏逻辑”。同时用 lookbehind 保护了受保护 token如danielmiessler/PAI、PAI ALGORITHM。这是“按类裁决、绝不全局替换”的直接证据。类 3 的破坏点清单~/.claude/LIFEOS/USER符号链接、launchdcom.lifeos.*的 WatchPaths/exec 路径、settings.json 的 additionalDirectories 与环境块、--append-system-prompt-file启动器路径、按路径 sha256 键控状态的 DerivedSync、LIFEOS_StatusLine.sh、以及USER/TELOS/LIFEOS_STATE.json的读取方Pulse 环、statusline。这些就是 cut 日“逐路径探针”要覆盖的对象。类 9 揭示了一个隐蔽的耦合FormatGate把 MEMORY行的强制渲染与 delta 标签的子串匹配绑定。如果只改发射端不改门禁端“半截改名”会让 MEMORY 行检查静默停止生效——所以该类裁决是“发射端、读取端、门禁与系统提示在一次变更中一起动读取端在迁移窗口内双前缀接受”。2.4 明令禁止项forbidden映射表还列出了四条红线可作为同类工程的反模式清单对LifeOS做不分层的 grep-and-sed 全局替换重命名~/.claude本身它不迁移在改名后新建任何名为 LifeOS 的公开仓库会毁掉 GitHub 重定向手改生成物ARCHITECTURE_SUMMARY.md、PRINCIPAL_TELOS.md、LIFEOS_STATE.json——生成文件要改源和生成器再重新生成。三、波次状态与“framing 波”改了什么RenamePlan.md的核心是下面的波次状态表完整继承自文档波次范围状态Casing standardizationLifeOS散文标准退役Life OS仅 PascalCase 文件保留LifeOsDONE 2026-06-13核心文件fleet 波次随 rename-nowRename-nowframing文档散文/品牌类 1、Pulse UI 显示字符串类 2除应用包与 logo 资源、核心身份文件系统提示、CLAUDE.md、thesis、架构母版IN PROGRESS 2026-06-13Rename-at-cutLIFEOS/目录 约 4K 路径引用兼容 symlink、PAI_*环境变量键读回退 shim、核心管理 skill 经 CreateSkill、仓库 URLGitHub 改名即 cut、模式横幅 hook 正则、menubar 应用包、logo 资源QUEUED——受 cut 前置条件门控Post-cut optional代码标识符194 处QUEUED——机械操作可无限期滞后“framing 波”rename-now实际落地的内容文档给出了三点LifeOS成为 LIFEOS_SYSTEM_PROMPT.md、CLAUDE.md、LifeOsThesis.md、LifeosSystemArchitecture.md以及重新生成的ARCHITECTURE_SUMMARY.md中的首要身份——零规则/门禁/模板语义变化三个模式横幅字面量在 cut 之前保持字节级不变由 OutputFormatGate DriftReminder hook 钉住。Pulse 显示字符串改用 LifeOS包名、资源路径、路由、环境变量一律不动。文档子系统自述把每个子系统挂接到“当前状态 → 理想状态”循环上。四、源码印证门禁如何随重命名“同变更”演进映射表承诺的“读者双前缀、发射端只写新名、横幅字面量钉住到 cut”在仓库源码中可以直接验证到实现。4.1 双前缀兼容窗口FormatGate 的 TAG_PREFIXES类 9 的“rename-now-with-dual-accept”裁决在 FormatGate.hook.ts 中有精确实现。该 Stop-hook 负责确定性校验输出格式横幅首行、️收尾、em-dash 上限以及本回合出现lifeos-memory-delta/lifeos-system-delta块时必须渲染对应 MEMORY:/⚙️ SYSTEM:行。关键的“半截改名防护”就在这个函数里// LifeOS/install/hooks/FormatGate.hook.ts (L94-L108) /** * Readers accept BOTH prefixes; emitters write only lifeos-. A stale in-flight * session or a replayed transcript still carries pai- blocks, and a gate that * only knew the new name would silently stop enforcing the memory line — the * exact half-rename failure raised in public issue #1592 / PR #1594 * (anikinsasha). Drop the legacy prefix once no pai- transcripts remain. */ const TAG_PREFIXES [lifeos-, pai-] as const; function deltaThisTurn(rawTranscript: string, suffix: string): boolean { if (!rawTranscript) return false; const lastUser rawTranscript.lastIndexOf(role:user); const region lastUser 0 ? rawTranscript.slice(lastUser) : rawTranscript.slice(-8000); return TAG_PREFIXES.some((p) region.includes(p suffix)); }实现细节与映射表裁决逐条对应只扫描本回合从 transcript 尾部最后一个role:user标记之后取区域找不到则回退最后 8000 字符防止上一回合的 delta 造成误判双前缀接受lifeos-与pai-任一前缀命中即认定本回合有 delta 块——仍在飞行中的旧会话或重放的 transcript 里是pai-*块门禁若只认新名就会静默停止强制 MEMORY行退役条件写死在注释里“一旦不再存在pai-transcript 即可移除旧前缀”与过渡层“一个周期后退役”的策略一致。4.2 横幅字面量钉住到 cutDriftReminder 与 FormatGate 的字节一致映射表类 8 要求“模式横幅 hook 正则”在 cut 前保持字节级一致在 cut 日才随一次协调提交改动。当前仓库状态印证了“钉住”这一半DriftReminder.hook.ts 第 82–84 行// One format since 2026-07-11 (modes retired): the single LifeOS banner.后定义const MODE_BANNERS [═══ LifeOS ═══] as const;用该横幅做存在性检查与漂移提醒FormatGate.hook.ts 第 75 行const BANNER /════\s*LifeOS/;校验首行必须是 LifeOS 横幅LIFEOS_SYSTEM_PROMPT.md 中的输出格式契约也使用════ LifeOS ═══…统一横幅。系统提示、hook 正则、UI 字面量三处同源这正是类 8 所说“byte-parity verified between prompt and hooks”的现状形态。4.3 发射端只写新名从 MemoryDeltaSurface.hook.ts 等 hook 的现状看发射端输出的是lifeos-memory-delta/lifeos-memory-health块文档 MemorySystem.md 与 HookSystem.md 的记载一致读取端FormatGate才保留pai-双前缀窗口。发射新名、读取双名、门禁同变更——映射表类 9 的 procedure 在代码中是字面成立的。五、Cut 前置条件与切日运行手册5.1 Cut 前置条件全部必须成立文档列出 5 条前置条件映射表cut_preconditions中有更全的机器可读版本额外包含“每阶段后双仓同步 symlink 链验证”与“G3 TELOS 目标的 star-redirect 连续性确认”LifeOS 传感器循环2026-06-13 MasterReport 的 R3–R7可证明在运行——此时改名是“形式而非迁移”在飞行中的 fork 已调和.claude-fablev7、skill-only shadow release发布根 仅LifeOS/skill不复制整个.claude/、无根级install.sh、5.0.0/5.1.0 shadow 发布清理门禁从 RenameMap.json 程序化读取而非硬编码 token在CLAUDE_CONFIG_DIR克隆中完成彩排并跑过迁移 ISA逐路径探针launchd agent 存活、symlink 链完整、双仓同步绿、statusline 渲染正常、Pulse 健康GitHub 改名重定向已验证stars clone URL 存活此后绝不新建名为 LifeOS 的仓库。5.2 Cut-day runbook六步冻结禁止其他会话两个私有仓库各做一个 checkpoint commit原子 GitHub 改名公开仓库——与私有树变更是分离的决策与时点公开仓库的内容变更在此之前保持 out of scope私有树LIFEOS/目录改名一次原子操作完成 建立LifeOS → new兼容 symlink环境变量 shim 上线launchd plist 重写并 kickstartsettings.json 路径清扫横幅 hook 正则 测试在一次协调提交中改完清扫类 6/7仓库 URL、核心管理 skill 改名经 CreateSkill探针通道迁移 ISA 逐路径探针 bun testhooks/ 工作目录 Pulse 的 Interceptor 截图 iMessage 冒烟 对 fleet 中每台 LifeOS worker 机器的探针shadow 发布重排 改名树上跑 14 道门禁通过后才允许任何未来的公开发布。六、可复用的工程启示从RenamePlan.md与RenameMap.json的组合中可以提炼出一套“大规模标识改名”的通用做法全部有仓库内证据支撑叙述与数据分离计划文档给人读JSON 映射给工具和门禁读门禁永远不硬编码 token。对应 RenameMap.json 的$schema_note自述。分层裁决替代全局替换历史层永不改写、过渡层 shim 限期退役、目标层按 9 类逐一裁决“grep-and-sed 全局”被列为明令禁止项。半截改名 静默失效任何“检查旧物是否消失”的门禁都会在新 token 消失后空转通过所以门禁必须与被改内容在同一变更中演进——类 9 的TAG_PREFIXES双前缀窗口就是这一原则的最小实现单元见 FormatGate.hook.ts。把 cut 设计成原子 可彩排的事件冻结 → 原子改名 → 同扫关联类 → 逐路径探针 → 重排发布门禁六步 runbook 中每一步都有可验证的绿/红信号且要求先在克隆目录里完整彩排一遍。适用前提与限制本文所述状态、日期与 issue 编号#1554、#1592/#1594 等均以当前仓库文档快照为准仓库改名属于 cut 阶段的未执行项状态表中标记 QUEUED文中关于 cut 日 runbook 的叙述是“计划”不是已完成事实。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考