Works for any kind of home: a function's module, a check's script, a package, a layer, a service, a CI job, or a bounded context.
Characterise the thing being placed: what it does, what it reads or owns, what triggers it to change, and what it depends on.
List the candidates. Use the user's list, and add an obvious candidate they missed if the evidence points to one (say you added it). Separate a home (where the code or rule lives) from wiring (where it is invoked, such as a CI job that only calls a script). If a candidate is wiring, say so: the answer may be "lives in A, runs from B". Still score a wiring-only candidate, judging it by where its logic would have to go (inline YAML, a new script), so the table compares like with like.
Score each candidate from 1 to 5 (higher is better), citing evidence for each score:
| Criterion | Question |
|---|
| Responsibility fit | Does this home already describe itself as doing this kind of thing (its header, README, ADR, naming)? |
| Dependency direction | Does placing it here keep dependencies pointing the way they already point (tests depend on code, not code on tests; shipped code not on repo-only files)? |
| Existing analogues | Does this home already hold similar things you could copy the pattern from? |
| Wiring cost | How much new plumbing is needed: new jobs, CLI verbs, imports, duplicated discovery logic? Less is better. |
| Change alignment | Does it change for the same reasons and get maintained by the same people as this home? |
Total the five scores (out of 25) unweighted, unless the user named a priority; then say which criterion you weighted and why. If the top two are within 2 points, treat it as a tie and decide on the criterion that matters most for this case, defaulting to lower wiring cost, then to the stronger existing analogue. Name the deciding criterion either way.
State the recommendation, the main risk, and anything that would change it.
适用于任何类型的归属位置：函数的 module、检查的 script、package、layer、service、CI job 或 bounded context。
描述待定位对象：它做什么、读取或拥有什么、什么变化会触发它，以及它依赖什么。
列出候选项。 使用用户提供的列表；如果证据指向一个被遗漏的明显候选项，则将其补充进来，并说明已添加该候选项。应区分归属位置（代码或规则存放在哪里）与接线位置（从何处调用，例如仅调用脚本的 CI job）。如果候选项只是接线位置，应明确说明；答案可能是“逻辑存放在 A，从 B 运行”。仍然要给仅作为接线位置的候选项评分，依据其逻辑最终应放置的位置进行判断，例如内联 YAML 或新脚本，从而保证表格中的候选项具有可比性。
对每个候选项按 1 到 5 分评分（分数越高越好），并为每项评分引用证据：
| 标准 | 问题 |
|---|
| 职责契合度 | 该位置是否已通过其 header、README、ADR 或命名明确定位为负责此类事项？ |
| 依赖方向 | 放在这里是否能保持现有依赖方向（测试依赖代码，而不是代码依赖测试；发布代码不依赖仅存在于仓库中的文件）？ |
| 现有类似案例 | 该位置是否已经包含可复用模式的类似内容？ |
| 接线成本 | 需要多少新的连接工作，例如新 job、CLI verb、import 或重复的发现逻辑？成本越低越好。 |
| 变更一致性 | 它是否会因为与当前位置相同的原因发生变化，并由同一批人员维护？ |
将五项分数相加得出总分（满分 25），默认不加权；除非用户明确指定了优先级，否则不进行加权。如果用户指定了优先级，应说明对哪项标准进行了加权以及原因。如果前两名相差不超过 2 分，则视为并列，并选择本案例中最重要的标准作出决定；默认优先考虑更低的接线成本，其次是更明确的现有类似案例。无论采用哪种方式，都应指出最终决定性标准。
应给出推荐方案、主要风险，以及哪些情况会改变该推荐。