用途：sliced-bread-depth 是 Sliced Bread 架构中的“测量”环节，把每个 slice 当作深层模块来评分——即小而稳定的公共面隐藏大量实现。它不修改代码，只做只读评估，用于发现“crust 本身就是实现”的浅层 slice（如 900 行 crust 包裹两个简单 helper）。
主要能力与使用方式：默认测量仓库中全部 slice；用户指定时只测那些，但仍列出完整清单以提供比例背景。流程分三步。第一步 Inventory：按语言原生形式找到每个 slice 的 crust（Go 的导出标识符、Python 的包 init、TypeScript 的 index 模块、其他语言的公共类面），应用 surface test 判断消费者能否在顶层看到一组小而明确的操作，并将 crust 分类为 Thin facade、Framework-bound 或 Service/sim。第二步 Measure：用代码而非估算计算 crust LOC、slice 总 LOC、实现占比（crust LOC ÷ slice 总 LOC）、内部模块数量与 LOC、公共面数量以及生命周期混合情况。第三步 Assess：当 crust 持有热路径实现，且深层空或薄、或公共面混合无关生命周期时，建议拆分 crust（提取内部实现，不新增第二个公共接缝）。
校准与限制：比例是核心指标，而非绝对 LOC；框架绑定的 crust 有内聚豁免；内部文件多是指 API 聚集问题，应 narrow 而非拆分；有文档声明表面意图的给 intent（软否决并引用）；双接缝应澄清而非拆分；对比同类 slice 深度差异是最高置信发现。成长保护包括：单一消费者不自动证明过早抽象，新增单文件保持单文件是正确做法，为打破跨 slice 循环引入的 dispatcher 视为已证明压力，数值阈值只是建议信号。
输出：只读报告三部分——Catalog 表（slice、shape、crust LOC、内部模块、实现占比、公共面）、Assessment 表（逐 slice 结论，按 extract → narrow → watch 排序并附 file:line 理由）、按 ROI 排序的前三个提取建议（什么离开 crust、去哪里、可参照的仓内先例）。全部 healthy 是有效结果，不得编造发现。