运行时配置（步骤 0 — 在任何处理之前）
阅读这些文件以配置特定领域的特定行为：
-
ops/derivation-manifest.md— 词汇映射，领域上下文- 使用
vocabulary.notes用于笔记文件夹名称 - 使用
vocabulary.inbox用于收件箱文件夹名称 - 使用
vocabulary.note用于输出中的笔记类型名称 - 使用
vocabulary.topic_map用于 MOC 引用 - 使用
vocabulary.cmd_reduce用于处理/提取命令 - 使用
vocabulary.cmd_reflect用于连接查找命令 - 使用
vocabulary.cmd_reweave用于向后传递命令 - 使用
vocabulary.rethink用于重新思考命令名称
- 使用
-
ops/config.yaml— 阈值，处理偏好self_evolution.observation_threshold（默认：10）self_evolution.tension_threshold（默认：5）
如果这些文件不存在，则使用通用默认值和通用命令名称。
立即执行
不变量：/next 推荐，不执行。 提出一个建议及其理由。用户决定做什么。这可以防止认知外包，即系统做出所有工作决策，用户成为橡皮图章。
按顺序执行以下步骤：
步骤 1：阅读词汇
阅读 ops/derivation-manifest.md（或回退到 ops/derivation.md）以获取领域词汇映射。所有输出必须使用领域原生术语。如果两个文件都不存在，则使用通用术语（笔记，收件箱，主题地图等）。
步骤 2：协调维护队列
在收集状态之前，评估所有维护条件并协调队列。这确保在推荐引擎运行之前维护任务是最新的。
读取队列文件（ops/queue/queue.json 或 ops/queue.yaml）。如果 schema_version < 3，则迁移：
- 添加
maintenance_conditions部分，默认阈值 - 向现有任务添加
priority字段（默认：“pipeline”） - 设置
schema_version: 3
对于 maintenance_conditions 中的每个条件：
- 评估条件：
| 条件 | 评估方法 |
|---|---|
| orphan_notes | 对于 {vocabulary.notes}/ 中的每个笔记，计算传入 [[links]]。零 = 孤儿。 |
| dangling_links | 提取所有 [[links]]，验证目标文件是否存在。缺失 = 悬挂。 |
| inbox_pressure | 计算 {vocabulary.inbox}/ 中的 *.md。 |
| observation_accumulation | 计算 ops/observations/ 中状态为 pending 的数量。 |
| tension_accumulation | 计算 ops/tensions/ 中状态为 pending 或 open 的数量。 |
| pipeline_stalled | 队列任务状态为 pending 且跨会话未改变。 |
| unprocessed_sessions | 计算 ops/sessions/ 中没有 mined: true 的文件数量。 |
| moc_oversize | 对于每个主题地图，计算链接的笔记数量。 |
| stale_notes | 30+ 天未修改且 < 2 链接的笔记。 |
| low_link_density | 所有笔记的平均链接计数。 |
| methodology_drift | 比较 config.yaml 修改时间与 ops/methodology/ 中最新的笔记修改时间。如果配置较新，则方法可能已过时。 |
- 如果条件超过阈值且没有此 condition_key 的待定任务存在：
创建维护任务：
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
MAINT_MAX=$(jq '[.tasks[] | select(.id | startswith("maint-")) | .id | ltrimstr("maint-") | tonumber] | max // 0' ops/queue/queue.json)
NEXT_MAINT=$((MAINT_MAX + 1))
jq --arg id "maint-$(printf '%03d' $NEXT_MAINT)" \
--arg priority "{priority}" \
--arg key "{condition_key}" \
--arg target "{description}" \
--arg action "{recommended command}" \
--arg ts "$TIMESTAMP" \
'.tasks += [{"id": $id, "type": "maintenance", "priority": $priority, "status": "pending", "condition_key": $key, "target": $target, "action": $action, "auto_generated": true, "created": $ts}]' \
ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json
- 如果条件得到满足且存在此 condition_key 的待定任务：
自动关闭它：
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
jq --arg key "{condition_key}" --arg ts "$TIMESTAMP" \
'(.tasks[] | select(.condition_key == $key and .status == "pending")).status = "done" |
(.tasks[] | select(.condition_key == $key and .status == "pending")).completed = $ts' \
ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json
- 如果条件触发且已存在待定任务：
更新目标描述（具体可能已改变）：
jq --arg key "{condition_key}" --arg target "{new description}" \
'(.tasks[] | select(.condition_key == $key and .status == "pending")).target = $target' \
ops/queue/queue.json > tmp.json && mv tmp.json ops/queue/queue.json
步骤 3：收集 Vault 状态
收集所有信号。尽可能并行独立检查。即使检查返回零也要记录每个信号 —— 信号的缺失本身也是信息。
| 信号 | 如何检查 | 记录什么 |
|---|---|---|
| 任务栈 | 读取 ops/tasks.md — 当前优先级和开放项 |
顶部项目，开放计数，任何截止日期 |
| 队列状态 | 读取 ops/queue.yaml 或 ops/queue/queue.json — 待定管道任务 |
总待定，按阶段（创建，反映，重新编织，验证），阻塞阶段 |
| 收件箱压力 | 计算 {vocabulary.inbox}/ 中的 *.md 文件，找到最老的按 mtime |
每个子目录的计数，最旧项目的年龄（天） |
| 笔记计数 | 计算 {vocabulary.notes}/ 中的 *.md |
总笔记数以供上下文 |
| 孤儿笔记 | 对于每个笔记，grep 所有文件中的 [[filename]] — 零命中 = 孤儿 |
计数，前 5 名 |
| 悬挂链接 | 从 notes/ 提取所有 [[links]]，验证每个目标文件是否存在 |
计数，前 5 个目标 |
| 陈旧笔记 | 最近未修改且链接密度低（< 2 链接）的笔记 | 计数 |
| 目标 | 读取 self/goals.md 或 ops/goals.md — 当前优先级，活跃线程 |
优先级列表，活跃研究方向 |
| 观察 | 计算 ops/observations/ 中状态为 pending 的文件数量 |
计数 |
| 紧张 | 计算 ops/tensions/ 中状态为 pending 或 open 的文件数量 |
计数 |
| 方法论 | 检查 ops/methodology/ 中最近的捕获（在过去 7 天内修改的文件） |
最近的计数，总计数 |
| 健康 | 阅读 ops/health/ 中的最新报告 — 记录时间戳和问题 |
上次运行日期，问题计数，任何关键问题 |
| 会话 | 检查 ops/sessions/ 中没有 mined: true 的文件 |
未挖掘会话的计数 |
| 最近的 /next | 读取 ops/next-log.md（如果存在）— 最后 3 个建议 |
之前的建议以避免重复 |
适应规则：
- 目录名称适应领域词汇（例如，{vocabulary.inbox} 而不是硬编码的 “inbox”）
- 对于不存在的目录，静默跳过检查 — 不要报告 “ops/sessions/ 未找到”
- 缺少目录意味着该功能不活跃，这是有效状态
信号收集命令：
# 收件箱压力（适应词汇路径）
INBOX_COUNT=$(find {vocabulary.inbox}/ -name "*.md" -maxdepth 2 2>/dev/null | wc -l | tr -d ' ')
OLDEST_INBOX=$(find {vocabulary.inbox}/ -name "*.md" -maxdepth 2 -exec stat -f "%m %N" {} \; 2>/dev/null | sort -n | head -1)
# 笔记计数
NOTE_COUNT=$(ls -1 {vocabulary.notes}/*.md 2>/dev/null | wc -l | tr -d ' ')
# 待定观察
OBS_COUNT=$(grep -rl '^status: pending' ops/observations/ 2>/dev/null | wc -l | tr -d ' ')
# 待定紧张
TENSION_COUNT=$(grep -rl '^status: pending\|^status: open' ops/tensions/ 2>/dev/null | wc -l | tr -d ' ')
# 未挖掘会话
SESSION_COUNT=$(grep -rL '^mined: true' ops/sessions/*.md 2>/dev/null | wc -l | tr -d ' ')
步骤 4：按后果速度分类
评估每个信号对后果速度的影响 — 不采取行动会多快降低系统质量？
| 速度 | 信号 | 阈值 | 为什么这个优先级 |
|---|---|---|---|
| 会话 | 收件箱 > 5 项，孤儿笔记（任何），悬挂链接（任何），10+ 待定观察，5+ 待定紧张，未处理会话 > 3 | 立即 — 这些会立即降低工作质量 | 孤儿对遍历不可见。悬挂链接混淆导航。收件箱压力意味着丢失想法。观察/紧张阈值意味着系统正在积累未处理的摩擦。 |
| 多会话 | 管道队列积压 > 10，目标中识别的研究空白，陈旧笔记 > 10，收件箱项目老化 > 7 天，方法论捕获 > 5 在同一类别 | 很快 — 这些会在几天内复合 | 未完成的管道批次阻塞下游连接。陈旧笔记代表知识衰减。收件箱老化意味着捕获速度超过处理速度。 |
| 慢 | 健康检查在过去 14+ 天内未运行，{DOMAIN:topic map} 超大（>40 笔记），链接密度低于 2.0 平均值，相对于时间的低笔记计数 | 背景 — 烦人但不是阻塞的 | 这些是维护任务。对长期健康很重要，但不紧急。 |
阈值规则： 10+ 待定观察 OR 5+ 待定紧张始终是会话优先级。在这种情况下推荐 {DOMAIN:rethink}。
信号交互规则：
- 任务栈项目始终覆盖自动化推荐（用户设置的优先级胜过系统检测到的紧急性）
- 多个会话优先级信号：选择影响最大的一个（受影响的项目最多）
- 如果收件箱压力和队列积压：首先推荐减少收件箱（管道需要输入才能处理）
步骤 5：生成推荐
选择最有价值的单一行动。推荐必须足够具体以立即执行 — 一个具体的命令调用，而不是一个模糊的建议。
优先级级联：
1. 任务栈优先
如果 ops/tasks.md 有开放项，从任务栈推荐。用户设置的优先级覆盖所有自动化推荐，因为：
- 用户拥有系统不了解的上下文
- 忽略显式优先级会削弱信任
- 任务栈项目代表深思熟虑的决定，而不是自动化检测
格式：推荐具体任务，并提供为什么它在栈中的上下文。
1.5. 会话优先维护任务
读取队列中的 priority: "session" 和 status: "pending" 的维护任务。这些代表会话健康条件，会降低 THIS 会话。
选择最高影响的一个：
- orphan_notes: “{N} 笔记对遍历不可见”
- dangling_links: “{N} 断裂链接混淆导航”
- inbox_pressure: “{N} 项在收件箱中老化”
推荐队列条目的 action 字段。
2. 会话优先信号
如果没有任务栈项，选择最高影响的会话优先信号：
| 信号 | 推荐 | 理由模板 |
|---|---|---|
| 悬挂链接/孤儿 | /health 或特定修复命令 | “您有 [N] 孤儿笔记对遍历不可见。连接它们会增加图密度和检索质量。” |
| 10+ 观察或 5+ 紧张 | /{DOMAIN:rethink} | “[N] 待定观察已累积。模式检测需要处理这个积压以发展系统。” |
| 收件箱 > 5 项 | /{DOMAIN:reduce} [特定文件] | “您的收件箱有 [N] 项（最旧：[age]）。[文件 X] 根据 [reason] 具有最高的连接潜力。” |
| 未处理会话 > 3 | /remember --mine-sessions | “[N] 会话有未捕获的摩擦模式。挖掘它们可以防止方法论回归。” |
当推荐收件箱处理时： 选择与当前目标最匹配或与现有笔记连接潜力最大的特定收件箱项。推荐一个具体的文件，而不是 “处理一些收件箱。”
3. 多会话信号
如果没有会话优先项：
| 信号 | 推荐 | 理由模板 |
|---|---|---|
| 队列积压 > 10 | /ralph [N] | “[N] 管道任务待定。您最新的 {DOMAIN:notes} 缺乏连接，这意味着它们不能参与合成。” |
| 陈旧笔记 > 10 | /{DOMAIN:reweave} [特定笔记] | “[N] 笔记自 [date] 以来未被触及。[笔记 X] 连接最多，将从更新中受益最多。” |
| 研究空白 | /{DOMAIN:reduce} [与目标对齐的文件] | “您的目标提到 [topic]，但您的图在这个领域只有很少的笔记。[收件箱项] 涉及这个空白。” |
| 方法论收敛 | /{DOMAIN:rethink} | “[N] 方法论捕获在 [category] 区域表明值得提升的模式。” |
当推荐重新编织时： 选择连接最多的陈旧笔记（最高的链接密度 + 最旧的修改）。重新编织高连接性笔记具有最大的连锁反应。
4. 慢信号
如果没有紧迫的事情：
| 信号 | 推荐 | 理由模板 |
|---|---|---|
| 没有最近的健康检查 | /health | “上次健康检查是在 [date]。现在运行一个可以防止结构问题在它们复合之前。” |
| 主题图过大 | 重构建议 | “[主题图 X] 有 [N] 笔记。分割成子主题图可以改善导航并减少认知负荷。” |
| 链接密度低 | /{DOMAIN:reweave} 在最低密度笔记上 | “您的图的平均链接密度是 [N]。重新编织稀疏笔记可以增加遍历路径。” |
5. 一切干净
如果所有信号都健康：
next
所有信号健康。
收件箱：0 | 队列：0 待定 | 孤儿：0 | 悬挂：0
未检测到紧急工作。
建议：从 goals.md 探索新方向
或重新编织旧的 {DOMAIN:notes} 以加深图连接。
理由始终是必须的。 每个推荐都必须解释：
- 为什么这个行动而不是替代品
- 如果这个行动被推迟会有什么降级
- 如何连接到目标（如果适用）
步骤 6：去重
读取 ops/next-log.md（如果存在）。检查最后 3 个条目。
去重规则：
- 如果相同的推荐在过去 2 个条目中出现，则选择下一个最佳行动
- 这可以防止系统陷入重复推荐同一件事，当用户选择不采取行动时
- 如果相同的推荐确实是最高优先级（例如，收件箱压力持续增长），添加一个明确注释：“这之前被推荐过。信号自那时以来变得更强了（[之前] → [现在]）。”
步骤 7：输出
next
状态：
收件箱：[count] 项（最旧：[age]）
队列：[count] 待定（[阶段细分]）
孤儿：[count] | 悬挂：[count]
观察：[count] | 紧张：[count]
[任何其他决策相关信号]
推荐：[具体命令/行动]
理由：[2-3 句话 —— 为什么这个行动，
它如何连接到目标，如果推迟会有什么降级]
之后：[第二优先级，如果相关]
[可选：与 goals.md 优先级对齐]
命令具体性是必须的。 推荐必须是具体的调用：
| 好 | 坏 |
|---|---|
| /{DOMAIN:reduce} 收件箱/article-on-spaced-repetition.md | “处理一些收件箱项” |
| /ralph 5 | “处理队列” |
| /{DOMAIN:rethink} | “回顾你的观察” |
| /{DOMAIN:reweave} [[这里标题]] | “更新一些旧笔记” |
状态显示规则：
- 只显示 2-4 个决策相关的信号 —— 不是全部 14 个检查
- 零计数信号如果是健康的可以省略（不要显示 “孤儿：0” 除非与问题对比）
- 非零信号在会话或多会话优先级时应该始终显示
步骤 8：记录推荐
追加到 ops/next-log.md（如果缺失则创建）：
## YYYY-MM-DD HH:MM
**状态：** 收件箱：[N] | 笔记：[N] | 孤儿：[N] | 悬挂：[N] | 陈旧：[N] | 观察：[N] | 紧张：[N] | 队列：[N]
**推荐：** [行动]
**理由：** [一句话]
**优先级：** 会话 | 多会话 | 慢
为什么记录？ 日志有三个目的：
- 去重 — 防止重复推荐相同的行动
- 进化跟踪 — 显示哪些信号是持久的 vs 短暂的
- /rethink 证据 — 持续未采取行动的推荐可能揭示系统检测和用户价值之间的不一致
边缘情况
空保险库（0-5 笔记）
推荐捕获或减少内容。维护对于 < 5 笔记来说为时过早 — 图没有足够的节点进行有意义的分析。
next
状态：
笔记：[N] — 早期阶段保险库
推荐：捕获或 /{DOMAIN:reduce} 内容
理由：您的图有 [N] 笔记。在这个阶段，增加
内容比维护结构更重要。健康检查，
重新编织和重新思考在大约 10 个笔记后变得有价值。
一切干净
明确说出来。推荐与目标对齐的探索性工作，或对旧笔记进行反思性工作：
未检测到紧急工作。考虑：
- 从 goals.md 探索研究方向
- 重新编织旧的 {DOMAIN:notes} 以加深连接
- 审查和更新 goals.md 本身
没有目标文件
推荐首先创建 self/goals.md 或 ops/goals.md。没有优先级，推荐缺乏基础，系统无法区分 “对用户重要” 和 “由自动化检测到。”
推荐：创建 ops/goals.md
理由：没有目标，/next 只能基于
自动化检测推荐。目标让系统对齐推荐
与真正对你重要的事情。
没有 ops/derivation-manifest.md
使用通用词汇。不要失败 — /next 应该无论配置状态如何总是产生推荐。
队列不活跃
静默跳过队列检查。并非所有保险库都使用管道架构 — 有些依赖手动处理。不要报告 “队列未找到” 作为问题。
多个会话优先信号
当几个信号同时处于会话优先级时，选择可以解锁最多下游工作的那一个：
- 悬挂链接阻塞图遍历 → 首先修复
- 观察阈值 → 重新思考防止方法论漂移
- 收件箱压力 → 处理防止想法丢失
如果确实优先级相等，选择用户最近没有被推荐的那一个（检查 next-log.md）。
过时的 /next 日志
如果 ops/next-log.md 超过 14 天未更新，用户可能不经常运行 /next。注意这一点，但不要将其作为推荐 — /next 是可选的，不是强制性的。
反模式
这些是 /next 必须避免的模式：
| 反模式 | 为什么它是错误的 | 应该做什么 |
|---|---|---|
| 推荐一切 | 压倒用户，违背 “最有价值的单一行动” 的目的 | 选择一个。只提第二优先级作为 “之后那个” |
| 模糊推荐 | “处理收件箱” 没有可操作的起点 | 命名具体文件，笔记或命令 |
| 忽略任务栈 | 用户设置的优先级有原因 | 始终检查 ops/tasks.md 第一 |
| 重复相同的推荐 | 如果用户没有采取行动，再次推荐它是唠叨 | 通过 next-log.md 去重 |
| 提议维护过早 | 5 笔记的保险库不需要健康检查 | 根据保险库成熟度调整推荐 |
| 认知外包 | 为用户做出所有决策 | 推荐并解释 — 永远不执行 |