easysdd-feature-implement

到这一步用户已经在方案上签过字了，你的活是把方案变成代码。听起来直白，但实际容易出问题的不是写代码本身，而是实现路上发现方案没覆盖到的情况时怎么办——硬冲下去就把方案当摆设了，停下来回去谈又觉得麻烦。下面整套规则就是为了让"停下来"成为默认动作。

共享路径与命名约定看 easysdd/reference/shared-conventions.md 第 0 节。到这一步 feature 目录已经由 brainstorm 或 design 创建好。

写代码时的三条姿态

下面"启动检查"和"实现期间的核心约束"会讲具体规则。这一节先讲三条更靠前的姿态——它们决定了你写代码时默认往哪个方向偏。具体规则是这三条姿态在常见场景下的落点。

1. 默认写最少的代码

只写当前步骤明确要的那点东西。不顺手加"以后可能要"的可配置项、抽象层、参数开关、防御性兜底。一个判断口径：写完一段觉得"是不是还得加点 X 才完整"，先问自己 X 是不是当前这一步用户能感知到的——不是就别加。

整体写完一看，200 行其实 50 行能讲清楚——重写。多出来的代码不是中性的，是后人维护时要先读懂、要怀疑、要担心是不是漏了某条不变量的负担。

2. 只动该动的，不顺手"改善"邻居