Back to Details

ds-blueprint

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ds-blueprint

ds-blueprint

Fix the shape of the code before writing the bodies, so the model fills in a plan instead of inventing one as it goes.
在编写函数体之前先确定代码结构，让模型按照计划填充，而不是边做边自行发挥。

Steps

步骤

  1. Ground yourself. Read every module the new code will touch. If you cannot explain how they fit together, run /ds-explain first. Skip this only for code with no surrounding system.
  2. Write at least two structurally different sketches. Each sketch is real files with types, signatures, module boundaries and stub bodies that raise "not implemented", plus short pseudocode. Use /ds-best-of-n to produce them in parallel when the design matters.
  3. Compare the sketches. Prefer the one with the smaller public surface that hides more inside. Prefer the one where a change that looks right from a single file is also right for the whole repo. Note what you rejected and why.
  4. Run the type checker or compiler on the chosen sketch. Paste the output. Stubs must compile.
  5. Show the user the chosen sketch and wait for agreement before you fill in bodies. In an unattended run, record the choice with /ds-ledger instead.
  6. Implement one stub at a time. After each, run the type checker and the relevant tests. If the sketch turns out wrong, stop and revise the sketch, not just the body.
  7. Delete leftover stubs, dead sketches and unused types. Grep for "not implemented" to prove none remain.
  1. 理解上下文。阅读新代码将涉及的每个模块。如果无法解释它们如何协同工作，先运行 /ds-explain。仅当代码不涉及任何周边系统时，才可跳过。
  2. 至少编写两个结构上不同的草案。每个草案都应体现为真实文件，包含类型、签名、模块边界以及抛出 "not implemented" 的桩函数体，并附简短伪代码。当设计很重要时，使用 /ds-best-of-n 并行生成这些草案。
  3. 比较这些草案。优先选择公开接口面更小、能在内部隐藏更多细节的方案。优先选择那种从单个文件看似合理的改动，对整个仓库而言也合理的方案。记录否决了哪些方案以及原因。
  4. 对选定的草案运行类型检查器或编译器。粘贴输出。桩代码必须能够编译。
  5. 向用户展示选定的草案，在填充函数体之前等待确认。在无人值守运行中，改为使用 /ds-ledger 记录选择。
  6. 每次实现一个桩函数。完成后，运行类型检查器和相关测试。如果证明草案有误，停止并修订草案，而不只是修改函数体。
  7. 删除遗留桩代码、无效草案和未使用的类型。使用 Grep 搜索 "not implemented"，以证明没有残留。

Stop when

停止条件

  • Every stub is implemented, the type checker passes and the tests pass, with output shown.
  • Or the sketch needed three revisions during implementation. Stop and redesign with the user.
  • 每个桩函数均已实现，类型检查器和测试均通过，并展示输出。
  • 或者，草案在实现过程中需要修订三次。此时停止，并与用户一起重新设计。

Rules

规则

  • Signatures change only through step 6's revise path, never silently.
  • Keep each sketch file small enough to read in one pass.
  • Evidence is compiler and test output, not "it should work".
  • 签名只能通过第 6 步中的修订流程更改，绝不能静默修改。
  • 每个草案文件都应足够小，以便一次读完。
  • 证据应是编译器和测试输出，而不是 "it should work"。