用途
Render Code Shape 用于渲染代码的形状：模块边界、跨边界的类型、签名，以及带引用来源的调用图。它面向已经存在的代码，也面向即将构建的改动。
代码有一条“水线”。水线之上是形状：模块及其边界，跨越这些边界的类型和值，签名，以及调用实际发生的顺序。水线之下是语法和函数体内的语句。渲染形状时，水线以下的一切折叠为一行意图描述。只有函数体是伪码——每个名称、类型和路径都从源码中读取，并按文件与行号引用，或被标记为 [NEW]。
主要能力
- 渲染类型：声明每个跨越边界的类型、接口或模式及其字段；来自框架外部的类型会被命名并标记为外部。
- 渲染边界：每个模块一行，说明它拥有什么、暴露什么、依赖什么，以及在其表面之后隐藏什么。
- 渲染签名：按模块分组，每个签名携带参数名、参数类型、返回类型和错误类型，均按源码原样；每个函数体折叠为一行意图。
- 渲染调用图：每种 wiring 一张图，以缩进树形式呈现，每条边读取为
→ Receiver.method(arg: Type, arg: Type) : Return，随后是注解，然后是文件与行号；同层调用按执行顺序排列。 - 注解非普通边：对非无条件进程内调用，至少标注一种：
[if …]、[each …]、[async]、[error …]、[boundary: …]、[NEW]。
使用方式
-
框定渲染范围：命名要追踪的入口点和框架边缘（视为外部的包、服务、库），命名每种要渲染的 wiring：生产环境，以及任何替换依赖的组合根（如测试、本地开发、特性开关）。将每个入口点分类为
existing或[NEW]。对[NEW]渲染，确定其必须满足的需求以及它所附着的现有代码。优先选择能回答所问问题的最窄框架。 -
读取部件：从每个入口点跟随每一次调用，打开路径上的每个文件。对到达的每个函数，记录其文件与行号、原样签名、产生的效果以及它发起的调用。扩展一条路径，直到它到达边界穿越、纯叶子、框架边缘或已记录的函数；路径不在其他地方结束。对
[NEW]渲染，以同样的严谨度读取改动所附着的周围模块；尚不存在的部分从需求推导并标记。阅读源码——凭记忆、从名称推断或从旧版本沿用的签名都是捏造，即使碰巧正确；引用使差异可核查。 -
渲染形状：使用项目自身的语言和命名——术语表中的术语，而不是同义词。三部分：类型、边界、签名。当切分不明显时，按表格判断：进程外效果（网络、数据库、文件系统、时钟、随机、环境）在水线之上，纯本地计算在水线之下；改变下游调用发生的分支在水线之上，只改变返回值的水线之下；效果跨越模块边界的辅助函数在水线之上，包含在内部的私有辅助函数在水线之下；构造和注入的位置在水线之上，框架和传输样板在水线之下。
-
渲染调用图：每种 wiring 一张图，作为缩进树。每条边读取为
→ Receiver.method(arg: Type, arg: Type) : Return，然后是注解，然后是文件与行号。同层调用按执行顺序排列。已绘制过的函数以→ Name (above)代替二次展开。 -
返回渲染结果：先给出入口点、框架边缘和绘制的 wiring。然后给出类型、边界表、签名和调用图。以形状所显示的内容结尾，陈述为渲染中已可见的事实而非判断：依赖循环、与模块分层相反的依赖、参数数量、被许多调用者到达的函数、主路径上的边界穿越、没有 wiring 覆盖的路径。命名未读取的内容及原因。
适用场景
- 询问某物如何组合时
- 追踪一个请求实际触及了什么时
- 在实现改动之前进行伪码化时
- 快速上手陌生路径时
- 生成计划及其测试将要核对的形状时
限制
- 只读：渲染是交付物，而非编辑。生成渲染从不授权更改生产代码、测试或配置。只有在请求单独授权时才实施，且须遵循管辖工作流——行为变更用
tdd，行为保持工作用refactoring或reduce-system-complexity。 - 渲染不是裁决：它陈述渲染中可见的内容。判断边界是否画得好属于
codebase-design；判断文件应放在哪里属于structure-codebase；排列架构投资优先级属于improve-codebase-architecture。 - 应与其他技能配合加载：
planning、codebase-design、structure-codebase、finding-seams、characterisation-tests、diagrams、technical-writing。 - 反模式包括：凭记忆或代码摘要渲染而不打开文件；未阅读就从旧版本沿用或从名称推断签名；把每条路径都扩展到叶子导致无人阅读；滑到水线以下用散文复述语句、控制流细节和框架样板；静默混合
[NEW]和现有名称；当测试或特性开关组合根替换依赖并改变图时只绘制生产 wiring；以判断结尾而非事实；在渲染期间编辑代码；渲染[NEW]形状后直接实现，跳过tdd要求的失败行为测试。
完成检查
- 渲染中的每个名称、类型和路径是否解析到当前树中的文件和行号，或带有
[NEW]？ - 框架边缘是否明确，每个替换依赖的 wiring 是否与生产环境并排绘制？
- 每条路径是否终止于边界、纯叶子、框架边缘或已绘制的函数？
- 每个模块行是否说明它隐藏什么，而不仅是暴露什么？
- 每条非普通调用图边是否被注解，每条边是否命名了跨越它的值？
- 结尾观察是否是渲染中可见的事实，决策是否路由到拥有它们的技能？
- 渲染是否保持只读，未读取的区域是否被命名而非悄悄省略？