slice-and-spine-review

Slice 和 Spine 审查

由人工主导、带有 Agent 式准备辅助流程的全仓库一致性检查。单个更改可能都通过 sliced-bread-review、sliced-bread-depth 和 sliced-bread-audit，但切片与 Spine 之间的接缝却可能逐渐累积有漏洞或重复的逻辑，而任何有界差异检查都看不到这些问题。此技能会盘点仓库、分发摘要，然后与人工协作逐一检查每个接缝。

调用

/slice-and-spine-review [scope: slice names | seam ids | full]

默认范围为 full。指定范围（切片名称或接缝 ID）会将第 2 阶段的检查和第 3 阶段的 Spine 检查限制在匹配的接缝和用例内，但第 0 阶段的盘点和矩阵仍会覆盖整个仓库，以便排名时掌握完整背景。

术语

• 切片 — 以教义角色定义的 domains/* 模块，不一定是名为 domains 的实际目录。
• 外壳 — 切片以语言原生形式呈现的公共接缝（导出标识符、包的 __init__ 接口、索引模块、公共类接口，或没有原生可见性机制的语言中的位置根目录）。 完整说明： https://cheeselord.dev/sliced-bread-architecture/reference/sliced-bread/ （仓库内：[[architecture/crust-definition]]）。
• Spine — app/use_cases 加上组合根（app/bootstrap）。
• 接缝 — 跨越边，共分为三种：切片间（外壳导入或事件）、Spine 到切片、适配器到端口的绑定。不同于 Feathers 式测试替换接缝。

阶段 0 — 盘点

1. 列举所有切片（crust）、主干，以及穿过它们的每条接缝， 并按上述三种边类型分类。

2. 根据调用方图代码智能分析得出热路径（从入口点出发，穿过主干进入切片的依赖闭包／调用层级）。 热路径用于接缝排序（见下文）、SeamDossiers（阶段 1）以及主干访问顺序（阶段 3）。

3. 构建切片链接级别矩阵：每对切片对应一个序数级别及其证据：

   级别	含义
   L0	无链接
   L1	事件链接
   L2	crust 导入
   L3	多符号导入
   L4	热门共变更

   无论级别如何，每个单元格都记录固定的三项证据（imports、co_change、 hot_paths，参见 references/formats.md）；级别的含义可以在文字中引用用于区分的检测输入 （例如，L1 的事件链接、L3 的多个导入符号），但该输入不应成为单独的证据字段。

   L4（热门共变更）在共变更分数较高，或热路径穿过该切片对时触发，无需满足导入条件——序数级别阶梯并不意味着 L4 要求存在导入。

   在 references/formats.md 中固定此架构；此处不要重述字段形状。

4. 按变更耦合优先级排列接缝遍历顺序：按 co_change 降序排列（主键）；平局时使用由 0-1 归一化项构成的综合指标打破平局（可调）：

   tiebreak = w_f * norm(fan_in) + w_d * depth_verdict_weight
            + w_h * norm(|hot_paths_crossing|)
   norm(x) = x / max(x over all seams)   # 0 when the max is 0
   

   • fan_in — 穿过边界的原始静态扇入计数；按所有接缝中的最大 fan_in 归一化到 [0,1]。
   • depth_verdict_weight — [0,1]，见下方判定表。
   • |hot_paths_crossing| — SeamDossier 的 hot_paths_crossing 数组长度（由热路径标识符组成的 string[]）， 按所有接缝中的最大计数归一化到 [0,1]。

   初始权重为 w_f=0.4, w_d=0.35, w_h=0.25；根据代码库进行调整， 并在会话报告中记录调整。

   co_change 是连续值，因此在实践中，综合指标会对 co_change 相同的接缝排序——通常为零； 这些权重对从未共同变更的接缝尤其重要。

   depth_verdict_weight 根据边界问题信号强度（依照该技能自身的语义），将 sliced-bread-depth 判定映射到 [0,1]；接缝取其两侧切片判定权重中的最大值，非切片侧（主干、适配器／端口） 贡献 0。判定来自 sliced-bread-depth 运行结果或其最新报告；如果没有可用的深度报告，则将所有接缝的 depth_verdict_weight = 0，并在会话报告中记录降级情况，方式与下方浅层 Git 历史的降级规则一致：

   判定	权重
   抽取	1.0
   收窄	0.75
   观察	0.5
   意图	0.25
   健康	0

5. 只有在 common/ 边被共变更标记时，才在遍历中将其设为停靠点——默认不要对每条 common/ 导入都停靠。

6. 浅层 Git 历史会使排序降级为仅按扇入排序；请在会话输出（阶段 4）中明确说明。切勿因历史深度不足而导致审查失败。

阶段 1 — 扇出

在人类会话开始前，为调用范围内的每组文件和测试分派一个子 Agent：范围内切片的文件（及其测试）、主干，以及与范围内切片相连的每条接缝的另一侧切片——只有同时具备两侧的档案才能评估接缝；如果范围是 full，则覆盖整个仓库。 如果执行环境提供 Workflow 工具，则使用该工具；否则改用 Agent 工具。

每个子 Agent 都会生成一份 FileDigest，并符合 references/formats.md 中固定的架构：公开的接口、使用的接口、从测试中提取的行为断言，以及疑似重复项。没有测试的文件应在行为断言位置标记为 UNTESTED——不要根据阅读实现代码推断断言。

汇总 FileDigest：

• 每个切片一份 SliceDossier——外部接口、内部文件、断言映射、规模。
• 每条接缝一份 SeamDossier——根据接缝两侧切片的 SliceDossier（非切片侧则提供简要标识符和摘要），以及阶段 0 的共同变更和热路径证据整理。

每份档案都要注明其生成时所依据的提交（防陈旧保护——如果会话期间发生编辑，某条路径上的档案早于当前 HEAD 时，该档案即为陈旧；必须在该档案对应的停靠环节前重新生成，不得默默沿用）。

所有架构均位于 references/formats.md——在档案和提示词中引用该路径；不要在此处重复架构。

阶段 2 — 接缝巡查

引导式会话，按排名顺序逐条接缝停靠：

1. 展示一张停靠卡片：接缝 ID、边类型、链接层级（仅限切片与切片之间的接缝）、两侧摘要（切片侧使用 SliceDossier 摘要；主干或适配器／端口侧使用标识符和一句话摘要）、共同变更和热路径证据，以及档案中的候选发现。

2. 人类可自由询问——Agent 根据档案和实时代码分析能力（搜索、读取、调用方图）作答，而非凭记忆或猜测。

3. 人类对每个停靠点恰好给出一种处置意见：

   处置意见	含义
   pull-up	将重复或泄漏的逻辑向上移入共享接缝
   push-down	将逻辑从接缝向下移出，移入切片或主干
   rethink-seam	接边类型或方向本身有误
   healthy	无需操作

4. 记录结论（理由、后续事项），然后按排名顺序前往下一条接缝。

人类可以随时结束巡查；无论巡查在哪里结束，都会在会话报告中记录覆盖率（已访问接缝数／接缝总数）。

阶段 3 — 主干审查

优先检查 app/use_cases 热路径（按阶段 0 推导的热路径顺序进行），然后检查组合根：

• 仅编排检查——用例中若包含内联领域逻辑（业务规则分支、计算、不变量检查），而非委托给切片处理，则可考虑向下移出。
• 组合根连线检查——app/bootstrap 将适配器连接到端口和用例；若发现领域逻辑或针对特定适配器的分支，则可考虑将其向下移入适配器或相关切片。

主干发现采用与阶段 2 相同的处置选项，并纳入同一份会话报告。

第 4 阶段 — 收尾

1. 将会话报告写入 .cheese/slice-and-spine/<repo>/<date>.md： 访问过的停靠点、覆盖范围、判定、链接级矩阵，以及关于排名降级（历史记录较浅、权重已调整）的说明。
2. 每项重要判定（上提、下调、重新考虑边界——不包括健康）都要在 .hallouminate/wiki/ 下创建由 ADR 支持的 Wiki 页面。 在仓库中首次收尾时，根据 Wiki 自身的 ADR 约定确定具体命名空间（decisions/ 还是 architecture/），并在会话报告中说明这一决定，以确保后续运行保持一致。
3. 将剩余的后续工作整理成移交菜单（/mold、/cook）——不要悄悄丢弃未处理的发现。

非目标

• 不检查限定差异范围内的规则合规性——使用 sliced-bread-review。
• 不进行自主审计或提报问题——使用 sliced-bread-audit。
• 不评估深度或外壳形状——使用 sliced-bread-depth。