Vishnu Bhaga

保持和维护正在运行的东西——锚定已验证的知识、在扰动下维持一致性、保护功能性模式免受不必要的更改。

适用场景

• 工作方法面临被范围蔓延或过早优化打断的风险
• 上下文漂移正威胁要用陈旧假设覆盖已验证的知识
• 多个并行关注点正在制造压力，要求更改应该保持稳定的东西
• 在 shiva-bhaga 溶解之后——幸存的东西在重建期间需要主动保护
• 当长会话面临因上下文压缩而丢失早期已验证决定的风险时
• 在对当前正确运行的系统进行更改之前

输入

• 必需：当前工作状态或要保持的已验证知识（隐式可用）
• 可选：对稳定性的具体威胁（例如"范围蔓延"、"上下文压缩即将到来"）
• 可选：MEMORY.md 和项目文件用于基础支撑（通过 Read）

步骤

第 1 步：盘点正在运行的东西

在保护任何东西之前，识别当前什么是功能性的和已验证的。

Preservation Inventory:
+---------------------+---------------------------+------------------------+
| Category            | Verification Method       | Anchoring Action       |
+---------------------+---------------------------+------------------------+
| Verified Facts      | Confirmed via tool use    | Record source and      |
|                     | (file reads, test runs,   | timestamp; do not      |
|                     | API responses)            | re-derive              |
+---------------------+---------------------------+------------------------+
| Working Code        | Tests pass, behavior      | Do not refactor unless |
|                     | confirmed, user approved  | explicitly requested   |
+---------------------+---------------------------+------------------------+
| User Requirements   | Explicitly stated by      | Quote directly; do not |
|                     | the user in this session  | paraphrase or infer    |
+---------------------+---------------------------+------------------------+
| Agreed Decisions    | Decisions made and        | Reference the decision |
|                     | confirmed during this     | point; do not revisit  |
|                     | session                   | without new evidence   |
+---------------------+---------------------------+------------------------+
| Environmental State | File paths, configs,      | Verify before assuming |
|                     | tool availability         | unchanged              |
+---------------------+---------------------------+------------------------+

1. 对每个类别，列出当前已验证和正在运行的具体项目
2. 注明验证方法——你怎么知道这是真的？
3. 没有验证的项目不被保持——它们是假设（可能需要 shiva-bhaga）

预期结果： 一份具体的已验证、正在运行的元素清单，附有其证据基础。

失败处理： 如果清单很稀疏——几乎没有什么是已验证的——这本身就是有价值的信息。运行 heal 重新建立基础，然后再尝试保持未验证的假设。

第 2 步：识别扰动来源

命名威胁稳定状态的力量。

1. 范围蔓延：任务是否在超出约定范围地扩展？
2. 上下文漂移：早期事实是否被更近期的（可能不正确的）推理覆盖？
3. 优化压力：是否有改进已经正常运行的东西的冲动？
4. 外部变化：环境是否发生了变化（文件被修改、工具不可用）？
5. 压缩风险：对话是否接近上下文限制，早期决定可能被丢失？

对每个来源评估：这是实际威胁还是预期风险？

预期结果： 命名的扰动来源，附有评估的严重程度（主动威胁 vs. 预期风险）。

失败处理： 如果没有明显的扰动来源，可能不需要保持——考虑 brahma-bhaga（创造）或继续执行是否更合适。

第 3 步：锚定稳定状态

应用具体技术保护正在运行的东西免受已识别威胁的影响。

1. 记忆锚定：对于面临上下文漂移风险的关键事实，明确重新陈述：
   • "已确立事实：[X]，通过 [方法] 在 [对话中的时间点] 验证"
   • 如果有持久记忆可用，将持久事实写入 MEMORY.md
2. 范围边界强制：对于范围蔓延，重新陈述约定的范围：
   • "约定范围：[原始请求]。当前工作在此边界之内/之外。"
3. 变更抵抗：对于面临优化压力的工作代码：
   • "此组件正在运行并已测试。除非用户明确请求，否则不做更改。"
4. 状态快照：对于压缩风险，创建心理检查点：
   • 总结：已完成什么、剩余什么、做了哪些关键决定
5. 环境验证：对于外部变化，在继续之前重新检查：
   • 重新读取关键文件，而不是依赖早期的读取

预期结果： 每个已识别的威胁都有具体的锚定响应。稳定状态被明确保护。

失败处理： 如果锚定感觉过度——平等地保护一切——确定优先级。什么是绝对不能更改的那一件事？先保护它。

第 4 步：通过行动维持

保持不是被动的——它需要在后续工作中持续关注。

1. 在每个行动之前，检查："这会威胁保持清单中的任何东西吗？"
2. 如果是，找到一种不干扰稳定状态的替代方法来实现目标
3. 如果干扰不可避免，明确承认并更新清单
4. 定期重新验证被保持的项目——特别是在复杂操作之后
5. 当任务完成时，确认被保持的项目完好无损

预期结果： 工作状态在当前任务中完整存活。更改仅在需要时进行，没有干扰正在运行的组件。

失败处理： 如果被保持的项目被无意更改，立即评估损害。如果更改破坏了某些东西，回滚。如果更改是中性的，更新清单。不要让清单变得陈旧。

验证清单

• 工作状态已盘点，附有验证证据
• 扰动来源已被识别和评估
• 锚定行动已应用于每个实际威胁
• 在整个任务中维持了范围边界
• 完成后重新验证了被保持的项目

常见问题

• 将假设作为事实保持：只有已验证的知识才值得保护。伪装成事实的未验证假设制造虚假的稳定性
• 过度保持：平等地保护一切会阻止必要的更改。保持必须是有选择性的——保护有效的，释放无效的
• 被动保持：假设事情会在没有主动验证的情况下保持稳定。上下文漂移是持续的；保持需要持续关注
• 抵抗合法变更：使用保持作为避免必要修改的借口。如果用户请求对工作组件进行更改，这优先于保持
• 陈旧清单：未能在新信息到达时更新保持清单。清单必须反映当前现实，而不是创建时的状态

相关技能

• shiva-bhaga — 破坏先于保持；在溶解中幸存的东西是毗湿奴所维持的
• brahma-bhaga — 创造建立在被保持的基础之上；新模式从稳定的土壤中涌现
• heal — 子系统评估揭示什么是真正功能性的，而不是表面稳定的
• observe — 持续的中性观察在漂移威胁稳定性之前检测到它
• awareness — 态势感知（Cooper 颜色代码）直接映射到扰动检测