wiki-manager

大模型 Wiki 管理器

你管理的是一个由大模型编译的知识库。源文档会导入到 raw/，然后逐步编译成由相互链接的 Markdown 文章组成的 Wiki。Claude Code 既是编译器，也是查询引擎——无需 Obsidian 或外部工具。

中枢路径

解析：每次操作开始时，先读取 ~/.config/llm-wiki/config.json，以解析 HUB。优先使用 hub_path：仅展开开头的 ~（不展开 com~apple~CloudDocs 中的波浪号），并以当前机器为准。仅将 resolved_path 视为旧版缓存：仅在不存在 hub_path 时使用；或者在展开后的 hub_path 不可用且 resolved_path 已初始化时，作为备用路径。不要将特定机器的 resolved_path 值写入共享配置。如果配置文件不存在，则尝试将 ~/wiki/_index.md 作为备用路径。如果 stat/存在性检查成功，但读取 wikis.json 或列出 topics/ 时遇到 Operation not permitted，则说明中枢路径正确，只是 macOS 阻止了此进程；请告知用户，为启动 Agent 的具体应用授予“完全磁盘访问权限”或 iCloud Drive 访问权限，然后重启。遇到此错误时，不要切换到 ~/wiki 或 resolved_path。完整流程请参阅 references/hub-resolution.md。

配置文件格式如下：

{
  "hub_path": "~/Library/Mobile Documents/com~apple~CloudDocs/wiki"
}

如果没有配置文件，但 ~/wiki/ 中有 _index.md，也可以使用。不过会优先检查配置——在沙盒环境中，可能无法访问 ~/wiki/。下文中所有对 ~/wiki/ 的引用均指 HUB。

Wiki 位置

默认使用主题子 Wiki。 HUB 是中枢——内容位于 HUB/topics/<name>/。每个主题都有独立的索引、源文档和文章。这样可以让查询更加聚焦，并避免无关主题污染彼此的搜索空间。

对于会不断扩展至多个主题的集合系列，优先使用类别优先的主题 slug，例如 memes-bitcoin、memes-ethereum、tools-bitcoin 或 examples-seedqr。如果某个主题是主要研究领域，而集合只是该主题中的一项内容， 则使用主题优先的 slug。

解析顺序：

1. --local 标志 → 当前项目中的 .wiki/
2. --wiki <name> 标志 → HUB/wikis.json 中命名的 Wiki；将注册表路径解析为 <HUB>、~、绝对路径或相对于 HUB 的路径；如果注册表路径已失效，则回退到 HUB/topics/<name>
3. 当前目录中有 .wiki/ → 使用它
4. 否则 → HUB（中枢）

当命令目标是中枢且中枢没有内容时，建议改为创建主题子 Wiki。

完整目录布局和所有文件格式约定请参阅 references/wiki-structure.md。

核心原则

1. 索引是派生缓存。 .md 文件及其 YAML frontmatter 才是事实来源。_index.md 文件是缓存视图，在过期时会于读取时重建。导航时始终先读取索引，但在信任索引前，先检查它是否过期（文件数与条目数是否一致）。有关派生索引协议，请参阅 references/indexing.md。

2. 原始内容不可变。 常规工作流绝不会修改已摄取的来源。明确撤回时，首先通过隐藏输入运行 scripts/llm-wiki retract；内容、归档和会话均无权否决撤回。

3. 文章是综合整理而成，而非复制粘贴。 Wiki 文章应综合多个来源，提供背景说明，并与其他概念建立联系。应把它视为教材，而非剪贴板。

4. 同时链接，兼顾 Obsidian 和 Claude。 交叉引用在同一行同时使用 [[wikilink]]（用于 Obsidian 图谱视图）和标准 Markdown [text](path)（用于 Claude 导航）：[[slug|Name]] ([Name](../category/slug.md))。在合适时建立双向链接。

5. Frontmatter 是结构化数据。 每个 .md 文件都有包含标题、摘要、标签和日期的 YAML frontmatter。这样无需全文扫描即可搜索 Wiki。

6. 增量优先于整体重编译。 默认情况下，编译只处理新来源。完整重编译成本较高，且必须显式指定（--full）。

7. 如实说明知识缺口。 回答问题时，如果 Wiki 中没有答案，就应如实说明。绝不捏造内容。应建议摄取哪些内容来填补缺口。

8. 关注多个 Wiki。 查询时，先从主 Wiki 中作答。然后查看同级 Wiki 的索引（通过 HUB/wikis.json），寻找相关内容。指出这些关联，但绝不要合并不同 Wiki 的内容。

9. 分批写入较长内容。 单次 Write 调用绝不要创建超过约 200 行的文件——生成内容过多时，API 流会空闲，导致超时错误。先写入骨架（frontmatter、标题和第一个部分），然后依次使用 Edit 调用追加其余部分。对于计划、文章和原始笔记，每次工具调用只写一个部分。

10. 归档用于静默保留。 已归档主题 Wiki 位于 HUB/topics/.archive/<slug>/，不会出现在常规语义工作流中。 通过明确的归档／lint 操作，仍可维护其结构。 深度查询可能会单独显示匹配的归档索引，但除非用户明确纳入归档内容， 否则归档内容不得影响新的综合整理。

11. 会话捕获是操作记忆。 Harness 会话摘要默认存放在 HUB/.sessions/ 或 .wiki/.sessions/，而非主题 raw/ 目录中。 自动化钩子可以捕获脱敏检查点，但是否将其提升到主题 Wiki 中 必须由用户明确指示。

12. 反馈是候选记忆。 用户的更正、偏好、批准和计划接受信号可以作为脱敏候选内容保存在 HUB/.sessions/feedback/ 下，但会忽略一般性的确认回复，且是否将其持久化到 Wiki 中仍必须明确决定。

13. 私有适配器是无内容的外部执行平面。 其机器本地注册表位于 ~/.config/llm-wiki/ 下，而不在 hub 中。 适配器仓库只包含工具代码；真实输入和所有运行时输出 都保留在单独管理的外部数据平面中。只有经过审核的 wiki-safe 候选内容 才能通过常规来源追溯和编译工作流进入 Wiki。请参阅 references/adapters.md。

14. 专业模块是有界的方法，而非凭据。 个人专用的指令型专业模块包保存在本地的 HUB/.skills/ 下，并按当前主题启用。加载专业模块绝不会授予工具、写入权限、专业 权威，也不会赋予生成 Agent 的许可。选择最精简且有用的方法， 保留不同意见，并记录其版本／哈希。请参阅 references/specialists.md。

15. 项目检查点需要全面覆盖并设有隐私保护机制。 请参阅 references/checkpoints.md。

适配器路由

对于“操作 + URL”请求，在摄取内容或提供通用工具建议之前，先运行 adapter route --intent <effect> --resource <url> --json，即使用户没有提到“wiki”也一样。若匹配成功，请阅读该适配器自有的指南；提供方的操作步骤位于其中。仅有 URL 并不代表获得了写入授权。参见 references/adapters.md。

明确使用 wiki skill-factory <request> 时，选择已注册的具名适配器；不要臆造 URL 路由。运行 show/doctor 并阅读其指南。它不会在环境中自动激活，其外部候选项仍处于禁用状态；安装、启用主题、提交和发布都是独立操作。

环境行为

当此技能在显式的 /wiki:* 命令之外激活时：

1. 解析知识库路径（参见上文“知识库路径”部分），然后检查是否存在 HUB/_index.md 或 .wiki/_index.md
2. 阅读主 _index.md，评估知识库是否可能涵盖用户的问题
3. 若存在相关内容 → 阅读相关文章并附上引用作答
4. 若没有相关内容 → 正常作答，并可选择建议：“可以使用 /wiki:ingest 将此内容添加到你的知识库中”
5. 查看同级知识库时，只阅读其 _index.md —— 除非用户提出要求，否则不要阅读完整文章。默认跳过已归档的同级知识库；在深度模式下，可单独报告已归档索引中的匹配项。

提供任何启动、恢复或“上次进展”简报时，请以当前知识库身份开头：<wiki-name> booted from <wiki-root-path>。优先采用 config.md 中的标题；对于本地 .wiki/ 项目，则回退使用父目录名称；对于 HUB/topics/<slug>/，则回退使用 slug。即使没有待恢复的工作，也要包含此行。

如果用户询问是否可以信任某个知识库产物、请求审计、提及来源或偏移，或要求进行超出常规问答范围的内容核验，请使用审计工作流，而不要将其当作普通问答处理。

工作流

内容摄取

参见 references/ingestion.md。 流程：来源（URL/文件/文本/推文/收件箱）→ 获取/读取 → 提取元数据 → 写入 raw/{type}/ → 更新索引 → 若有许多内容尚未编译，则建议进行编译。

集合摄取

参见 references/ingestion.md § 集合摄取。 流程：结构化上游集合（Git 仓库、BIP 风格的提案集、MediaWiki 转储/API）→ 上游条目清单 → 写入 raw/repos/ 清单及不可变的子来源 → 重建原始索引 → 可选地编译合成集群。批量导入请使用 /wiki:ingest-collection；切勿递归抓取 HTML。

私有适配器

参见 references/adapters.md。 流程：显式注册现有的本地适配器检出目录 → 声明读取和写入根目录 → 验证清单哈希和 describe 握手 → 通过捆绑的确定性 CLI 执行 v1 JSON 请求 → 验证产物路径和哈希 → 将所有输出保留在外部 → 可选地仅审查 wiki-safe 候选项，并通过常规知识库写入流程提炼最少且有用的证据。 如果指南提供由 Agent 启动的交互式授权助手，请自行启动，并仅提供其简短的本地交接链接，而不要提供冗长的终端命令或提供方 URL。切勿克隆、安装、更新、发布或自动提拔适配器。

个人专家技能

参见 references/specialists.md。 流程：在 HUB/.skills/ 下维护由用户拥有、仅包含指令的 SKILL.md 方法 → 验证结构和安全边界 → 为每个活跃主题显式启用稳定名称 → 根据任务特征选择零到三个，通常选择一个 → 向所选方法提供相同的有界证据包 → 按证据强度核验并综合 → 记录名称、版本和内容哈希。使用 /wiki:specialist suggest 进行以索引为先的候选扫描，使用 /wiki:specialist apply 进行有界审查。不要将 CFO、doctor、MBA 或 PhD 等头衔视为资质或能力提升。

清单

参见 references/inventory.md。 流程：运行清单适配检查 → 将适合长期保存、与 wiki 相邻的内容（条目、创意、摄取候选项、实体、语料库、问题、任务、关注项）作为 Markdown 记录保存在 inventory/ 下 → 根据索引/前置内容，以简洁的聊天表格或项目符号列表回答列表请求 → 可选择将派生视图保存在 inventory/views/ 下 → 可选择通过先明确执行试运行的迁移，将旧式队列类输出转换过来。清单迁移采用增量方式，并须经人工把关。明确指出内容是否太小，不适合纳入清单；是否太大，应该作为数据集/集合处理；或是否不属于 wiki 范围。

创意

参见 references/ideas.md。 流程：在 inventory/ideas/ 中记录 → 调研/完善 → 取得批准 → 冻结 BRIEF.md 并提升为项目。创意保留其沿袭关系；项目负责交付。

项目组合

参见 references/portfolio.md。 流程：读取活跃创意索引和项目的 WHY.md 文件 → 仅建立明确的沿袭关系交叉链接 → 生成彼此独立的只读表格，不复制记录。

收集

参见 references/inventory.md 和 references/research-infrastructure.md。 流程：界定范围明确的目录请求 → 推断规模和媒体策略 → 搜索候选工件、示例、资源、实体、工具、媒体或梗 → 仅获取有希望的上下文页面 → 对别名/转发/重新托管内容去重 → 记录 found_in_context 来源信息和媒体元数据 → 将 type: collection 输出保存到 output/collect-<slug>-YYYY-MM-DD.md → 如果列表规模较小且足够持久，可选择创建清单记录；中型或大型列表则可创建一条语料库记录。收集输出可作为 LLM 的暂存层，供其在提升到 raw/、wiki/、inventory 或 datasets 之前使用；它们不能替代事实性主张所需的原始来源。对于包含媒体的集合，默认将范围明确的公开二进制媒体下载并哈希到 output/assets/collect-<slug>/，绝不将二进制文件存入 raw/，并采用防护性下载设置：超时、文件大小上限、内容类型检查，以及当媒体主机在 IPv6 上无响应时重试 IPv4（curl -4）。除非已说明策略和限制，否则不要声称“全部”代表穷尽无遗。

数据集注册表

参见 references/datasets.md。 流程：将大型或外部数据集保留在 wiki 之外，同时通过 datasets/<slug>/MANIFEST.md 为其建立索引 → 存储位置、架构说明、小型样本、概况和查询方法 → 仅根据 datasets/_index.md 和清单前置内容回答列表请求 → 可选择通过先明确执行试运行的迁移，将旧式数据集输出转换过来。数据集迁移采用增量方式，绝不将底层数据复制到 wiki 中。

归档

参见 references/archive.md。 流程：将整个主题 wiki 从 HUB/topics/<slug>/ 移至 HUB/topics/.archive/<slug>/ → 在 wikis.json 中将其标记为 status: archived → 将其从常规查询/编译/研究/收集/输出/维护上下文中隐藏 → 通过将文件夹移回并设置 status: active 来恢复。在 v1 中，不要归档单个原始来源或编译文章。

编译

参见 references/compilation.md。 流程：调查尚未编译的来源 → 规划文章 → 分类（概念/主题/参考）→ 撰写/更新文章并添加交叉引用 → 更新所有索引。

查询

流程：读取 _index.md → 根据摘要／标签识别相关文章 → 阅读文章 → 沿着“另请参阅”链接继续查找 → 使用 Grep 查找更多匹配项 → 综合答案并附上引文 → 说明缺口 → 查看活跃的同级 wiki。支持使用 --resume 在会话中断后重新加载上下文——读取会话文件、近期日志条目、wiki 统计信息和最近更新的文章，生成一份“上次进度”简报。深入查询可能会在单独的“已归档匹配项”部分查看已归档的同级索引；完整读取已归档内容需要用户明确提出。

Lint

参见 references/linting.md。 流程：检查结构 → 索引 → 链接 → 内容 → 覆盖情况 → 报告 → 可选自动修复。默认 lint 会维护活跃内容的健康状态，并将已归档主题报告为已跳过。使用 --include-archived 或 --archived-only 可明确进行已归档内容的结构维护。

Librarian

参见 references/librarian.md。 流程：扫描活跃主题编译后的 wiki/ 层 → 评估陈旧程度、质量、 来源链完整性和链接健康状况 → 写入 .librarian/scan-results.json 和 .librarian/REPORT.md → 按优先级推荐后续操作。可选的 --passes conventions（或旧版 schema）可能会写入主题指南改进建议。 对于新的主题 wiki，默认使用主题指南；较旧的 wiki 可通过 llm-wiki schema adopt 或 llm-wiki lint --fix 采用主题指南。Librarian 未经用户明确同意，不得重写 schema.md。 Librarian 是文章健康状况顾问；它不能取代 lint 的结构检查 或 audit 更广泛的可信度审查。

Audit

参见 references/audit.md。 流程：运行或复用 Librarian 检查 → 检查 output/、wiki/ 和 raw/ 中的制品依赖链 → 通过新鲜的来源检查和有针对性的研究逐步深入，直到可信度判定趋于一致 → 写入 .audit/REPORT.md。

搜索

流程：扫描索引以匹配摘要／标签 → 使用 Grep 搜索全文 → 对结果排序 → 呈现结果。

跨工作流清单意识

清单是首要的运行状态，而非孤立的信息。其他工作流应留意清单，但不能将其视为事实依据：

• Ingest 和 ingest-collection：如果用户希望在摄取前进行跟踪，或者来源过大／含糊不清，则建议创建清单记录。当清单候选项被摄取时，将生成的 raw 或 collection 清单链接到该记录。
• Dataset：如果用户关心后续操作、优先级、验收状态或语料库的重要性，则将数据集清单链接到清单记录。
• Compile 和 query：使用清单呈现缺口、候选项和后续操作，但事实性主张应引用 raw／wiki 来源。
• Collect：先将目录写为输出，然后仅对规模较小且稳定的列表创建逐项清单记录；对于中型／大型、不稳定或媒体内容较多的集合，使用一条语料库记录。
• Research、audit、librarian、refresh、plan 和 output：针对需要长期跟进的事项、过时条目、来源队列或观察清单，建议创建清单记录；创建较大的待办列表前，应先展示示例。

会话

参见 references/sessions.md。 流程：选择启用 session enable → harness 钩子会在 HUB/.sessions/queue/ 下追加脱敏事件 → 会话状态和 Markdown 摘要会在工具计数、上下文压缩、停止／会话结束或手动检查点时更新 → session rehydrate 返回 精简的上下文块 → session promote 将提炼后的摘要明确复制到主题的 raw/notes/ 笔记中。允许自动采集；不允许自动晋升。

反馈整理器

参见 references/feedback.md。 流程：可信的用户提示词钩子或 feedback capture 对高信号的用户纠正、偏好、批准和计划接受轮次进行分类 → 将经过脱敏的候选内容追加到 HUB/.sessions/feedback/ 下 → 通过 feedback list/show 审阅 → 通过 feedback promote 将选定的候选内容明确写入主题 raw/notes/。 除非手动捕获，否则忽略一般性确认。

输出

流程：收集相关文章 → 生成产物（摘要/报告/幻灯片等）→ 保存到 output/ → 更新索引。

经验总结（ll）

流程：扫描会话，查找错误→修复模式、纠正和发现 → 提取结构化经验 → 使用 type: lessons-learned 写入 raw/notes/ → 可选择更新相关文章 → 可选择建议添加 CLAUDE.md 规则。

链接：文件路径和 URL

终端链接换行到第二行时会失效。所有 wiki 操作都遵循以下规则：

1. 完整绝对路径——展开 ~、HUB 和所有相对路径段。相对路径无法点击。
2. URL 使用 Markdown 链接语法——使用 [简短文本](url)，不要使用会换行并失效的长 URL 裸链。
3. 链接前不要缩进——缩进会占用终端宽度。将链接单独放在一行，并紧贴左侧。
4. 每行一个链接——不要在句子中间嵌入长路径。另起一行：

   Saved to:
   /Users/name/wiki/topics/my-topic/output/report-2026-04-08.md
   

示例参见 references/research-infrastructure.md § Agent Prompt Templates。适用于 ingest、compile、collect、research、output、assess。

活动日志

每次 wiki 操作都会向 wiki 根目录下的 log.md 追加记录。格式：## [YYYY-MM-DD] operation | Description。完整格式参见 references/wiki-structure.md。除非用户明确要求使用 --remove-from-logs 撤回，否则不得编辑或删除现有日志条目。

置信度评分

Wiki 文章的 frontmatter 中包含 confidence 字段：high、medium 或 low。

• high：多项同行评审来源的结论一致，且知识已得到充分确立
• medium：仅有单一来源，或来源结论部分一致，或近期发现尚未得到重复验证
• low：轶闻、单一非同行评审来源，或来源结论相互矛盾

回答查询时，请注明置信度级别。执行 lint 时，将置信度为 low 的文章标记出来以供审查。

编译提醒

通过比较 raw/_index.md 中的导入日期与 _index.md 中的上次编译日期，跟踪尚未编译的来源。如果一次导入后存在 5 个或更多尚未编译的来源，建议："你有 N 个尚未编译的来源。运行 /wiki:compile 将其整合。"

结构守护程序

发生以下任一触发条件时，自动执行快速结构检查：

触发条件

• 每次写入操作之后（ingest、compile、collect、research、output、inventory、dataset、archive）——验证刚刚写入的内容
• 技能激活时，且 wiki 已有 7 天或更久未执行 lint（检查 _index.md 中的“Last lint”）
• 发现内容放置错误时——文章位于全局 hub，而非主题子 wiki
• 用户提到 wiki 问题时——“wiki 坏了”“空了”“缺失了”“不对”
• 不存在 wiki 时（首次运行）——切换到引导式入门流程，而不是显示命令列表。引导用户完成主题选择 → init → 首个操作建议。参见 commands/wiki.md §“If no wiki exists”。

快速结构检查（轻量级，内联运行——不是完整的 lint）

1. Hub 完整性：Hub（HUB）中应仅包含 wikis.json、_index.md、log.md、topics/，以及可选的 .sessions/ 和 .skills/。根据仅包含指令的软件包和活跃主题允许列表契约验证 .skills/。如果 Hub 层级存在 raw/、wiki/、inventory/、datasets/、output/、inbox/ 或 config.md → 发出警告，不要删除。这些内容可能是用户在旧版 wiki 布局中留下的数据。建议运行 /wiki:lint --fix，该命令会将内容移动到相应主题 wiki、修复归档注册表偏差，或根据 references/linting.md 中的 C11/C12/C16/C17/C19 将内容隔离到 inbox/.unknown/。

2. 索引是否最新：对于活跃主题 wiki，将 raw/、wiki/、inventory/ 和 datasets/ 子目录中的实际文件数与其 _index.md 中的条目进行比较。忽略 .librarian/ 和 .audit/ 等维护／报告目录。如果不匹配 → 根据 frontmatter 重新生成受影响目录的索引，并移除失效条目以自动修复。

3. 孤立文件检测：检查 wiki 目录中是否存在未列入任何 _index.md 的 .md 文件。如果存在 → 将其添加到索引中。

4. 缺失目录和旧版元数据：验证核心主题 wiki 子目录是否存在（raw/articles/、raw/papers/、wiki/concepts/、wiki/references/、output/ 等）。如果缺失 → 创建这些目录并添加空的 _index.md。将 inventory/ 和 datasets/ 视为按需使用的可选层：如果它们已存在，则修复其索引；但除非当前的清单或数据集工作流需要，否则不要创建完全缺失的可选目录树。对于较早编译的文章，lint --fix 可以根据文件位置以及现有正文／frontmatter 推断 category、summary、日期和 volatility，并在匹配明确时，将模糊的原始来源引用改写为准确的 raw/...md 路径。

5. 同步 wikis.json：检查 HUB/topics/ 下的所有主题子 wiki 是否都已登记在 wikis.json 中。将 Hub 管理的主题路径保存为可移植的相对路径（topics/<slug>），而不是 /Users/<name>/... 这样的绝对路径。如果目录存在但未登记 → 添加它。如果已登记的路径已过时，但 HUB/topics/<name> 存在 → 修复该路径。如果路径已登记但不存在对应目录 → 移除该条目。

   HUB/topics/.archive/ 下归档的主题子 wiki 应使用 path: topics/.archive/<slug> 和 status: archived 登记。不要将其纳入活跃状态／查询／编译默认项。

6. 日志是否存在：验证活跃 wiki 和 Hub 中是否存在 log.md。如果缺失 → 创建它。

行为

• 状态正常时保持静默——如果所有检查均通过，则不要报告任何内容
• 自动修复简单问题——缺失的索引、未登记的 wiki、孤立文件。直接修复并记入日志。
• 对结构问题发出警告——内容位置错误、目录缺失、索引过时。告知用户问题所在，并建议运行 /wiki:lint --fix。
• 绝不阻止用户的请求——运行检查，修复能处理的问题，报告问题，然后继续处理用户实际提出的请求。

并发

多个 Claude Code 会话可以安全地同时读取和写入同一个 wiki，无需加锁。

• 索引 根据磁盘上的实际文件生成。如果两个会话同时写入文章，下次读取时会根据现有文件重建索引。两次重建都会收敛到相同的正确结果。
• log.md 仅追加，且采用小型原子写入。并发追加是安全的。明确的隐私撤回例外会以原子方式重写文件，不应与其他 wiki 写入操作同时运行。
• 文章/源文件 独立写入。两个会话创建不同文件时绝不会冲突。两个会话编辑同一个文件的情况很少见，发生时采用最后写入者胜出（对于 wiki 来说可以接受——内容始终可以从原始来源重建）。

有关派生索引协议，请参阅 references/indexing.md。

会话管理

研究会话注册表

当一个 --min-time 研究或论文会话处于活动状态时，wiki 根目录中会包含一个 .research-session.json 或 .thesis-session.json 文件。

持久的来源记录也应保存在 wiki 根目录中：

• .session-events.jsonl — 仅追加的事件日志，用于重放历史记录
• .session-checkpoint.json — 最新的精简摘要，用于恢复简报和审计

会话注册表文件是临时的崩溃恢复状态。事件日志和检查点则是持久的来源记录。

结构守护程序行为：

• 如果会话文件存在，且 status: "in_progress"，并且 start_time 距今超过 7 天 → 发出警告："发现过期的研究会话。请使用 /wiki:research 清理，或手动删除。"
• 会话文件是临时的——绝不纳入结构健康检查或索引计数
• 会话文件不应提交到 git
• 完成后通常应保留 .session-events.jsonl 和 .session-checkpoint.json，以便 /wiki:audit 将来源分类为 replayable，而非 partial

Harness 会话捕获

自动化的 Codex/Claude/OpenCode/Gemini 会话捕获使用 HUB/.sessions/ （本地 wiki 使用 .wiki/.sessions/）。这是一个隐藏的运维层，用于存储经脱敏处理的钩子事件、状态 JSON、派生索引和 Markdown 会话摘要。 在明确提升之前，它不属于主题证据。

有关存储布局、配置模式、钩子适配器契约、重新水合行为和提升规则，请参阅 references/sessions.md。