recohere

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Decoherence is locally valid code built on models that disagree: two HTTP clients, three error shapes, a migration left half done. Each one makes every later change translate between models, and it grows with change, not with time. This skill finds it and finishes one migration completely, because a migration left half done is more decoherence.

**Decoherence（失谐）**是指建立在相互不一致的模型之上、但局部仍然有效的代码：两个 HTTP 客户端、三种错误格式，以及一项未完成的迁移。每一种不一致都会迫使后续变更在不同模型之间进行转换，而且这种成本会随着变更次数增长，而不会随时间推移自行消失。此 skill 会发现这些问题，并完整完成其中一项迁移，因为半途而废的迁移会制造更多失谐。

Steps

步骤

Scope to where change happens. If the user named an area, take it. Otherwise walk
```
git log
```
back a few hundred commits and rank directories by how often they change; decoherence only costs where people keep working. Read the glossary (
```
spec/glossary.md
```
), ADRs and standards in scope first.
Find the candidates. Look for each of these, in the scope:
- parallel models: more than one way to do one job, such as fetching, errors, validation, dates, config, state, logging, test setup
- half migrations: a new pattern some callers use and others do not, often with a TODO, a
```
legacy
```
  or
```
v2
```
  name, or a shim
- drifted terms: one domain concept under several names across code, schema and UI
For each, count the call sites of every model with
```
grep
```
or the language's own tools, and note which files changed in the last 90 days. The dominant model is the one most recent changes use, not always the one with most call sites.
Rank by drag: call sites on the losing models, times how often those files change. Drop candidates the repo has an ADR for, unless the drag is real enough to reopen it, and say so.

Report to

.scratch/recohere/<YYYY-MM-DD>.md

, one entry per candidate, worst first:

markdown

## <n>. <concern>: <winning model> over <losing models>

- Models: <model> - <call sites> sites, <files>; <model> - ...
- Drag: <changes to those files in 90 days>
- Finish line: <what is true when one model is left>
- Guard: <the lint rule, type, or check that stops the losing model coming back>
- Size: <small | medium | large>

Show the user the top three and ask which to finish.

Finish the one they pick. Call the Skill tool with "interview" to settle the finish line, the winner, and the order. A migration is finished when the losing models are deleted and the guard is in place, so nobody, human or agent, reintroduces them. Plan the whole migration, even when it runs as several slices: once the interview closes, tell the user to run
```
/write-spec
```
on its decision record.

Scope creep is the risk: one concern per run, finished completely.

将范围限定在实际发生变更的位置。 如果用户指定了某个区域，就采用该区域。否则，向前查看
```
git log
```
中最近数百次提交，并按照目录的变更频率进行排序；只有在人们持续工作的地方，失谐才会产生成本。首先阅读范围内的术语表（
```
spec/glossary.md
```
）、ADR 和规范。
寻找候选项。 在指定范围内查找以下问题：
- 并行模型：完成同一项工作存在多种方式，例如数据获取、错误处理、校验、日期处理、配置、状态管理、日志记录和测试初始化
- 未完成的迁移：新模式仅被部分调用方采用，其他调用方仍未采用，通常会表现为 TODO、
```
legacy
```
  或
```
v2
```
  名称，或者 shim
- 术语漂移：同一个领域概念在代码、schema 和 UI 中使用了多个不同名称
对于每个候选项，使用
```
grep
```
或该语言自身的工具统计每种模型的调用点，并记录过去 90 天内发生过变更的文件。 主导模型是指近期变更所使用的模型，而不一定是调用点数量最多的模型。
按照阻力进行排序：失败模型上的调用点数量乘以这些文件的变更频率。如果仓库中已有针对某个候选项的 ADR，则将其排除；除非其阻力确实大到值得重新讨论该 ADR，否则应予排除，并明确说明原因。

报告到

.scratch/recohere/<YYYY-MM-DD>.md

，每个候选项占一个条目，并按照从最严重到最轻微的顺序排列：

markdown

## <n>. <关注点>：用 <获胜模型> 替代 <失败模型>

- 模型：<模型> - <调用点数量> 个调用点，<文件>；<模型> - ...
- 阻力：这些文件在 90 天内的变更次数
- 完成标准：只剩一个模型时需要达到的状态
- 防护措施：用于阻止失败模型重新引入的 lint 规则、类型或检查
- 规模：<small | medium | large>

向用户展示排名前三的候选项，并询问要完成哪一项迁移。

完成用户选定的那一项。 使用“interview”调用 Skill 工具，以确定完成标准、获胜模型以及执行顺序。当失败模型被删除，并且防护措施已经到位、不论是人类还是 agent 都无法重新引入它们时，一项迁移才算完成。即使整个迁移需要分多个批次执行，也要为其制定完整计划；访谈结束后，告知用户对该决策记录运行
```
/write-spec
```
。

范围蔓延是主要风险：每次运行只处理一个关注点，并将其彻底完成。