Ren build

ren-build

启动必读

先 Read .ren-flow/attention.md —— 各技术栈的命名规矩、分层约束、构建命令、易错点都在这里。ren-build 对前端、后端、客户端一视同仁,差异全靠 attention.md 承载。缺失则提示先 ren-init 并补 attention.md。

加载栈规范技能:attention.md 若声明了「栈规范技能」（项目把详细编码规范放在专门的技能里,而非全部内联）—— 实现对应栈代码前主动加载那个技能。ren-build 自身栈无关,真正的「这门语言 / 框架怎么写」由项目指定的栈技能承载。

工作区模式（根 attention.md 标 mode: workspace）：先确认本次的业务域，再 Read .ren-flow/domains/{domain}/attention.md 取该域的栈约定与命令；规格也在 .ren-flow/domains/{domain}/specs/ 下。

这个技能干什么

按 ren-spec 定稿的规格把代码写出来。核心纪律就一条：照规格推进,不偷偷扩范围。

为什么不按角色拆成 ren-build-frontend / ren-build-backend?语言语法模型本就会;技能要补偿的是流程和项目专有约定,后者写在 attention.md,与角色无关。

流程

1. 接规格

Glob .ren-flow/specs/ 找到对应 {slug}-spec.md,确认 status: approved。没有规格 —— 若是小改动(快路级别)可让用户口述需求直接做;否则提示先走 ren-spec。

读规格第 4 节「推进步骤」作为执行清单。

2. 扫现状

动手前读规格点到的现有代码,确定:改哪些文件、函数级落点、新逻辑放哪个文件。新逻辑默认放新文件,别往已经偏胖的文件里塞。规格第 2.5 节若把微重构定为推进步骤第 1 步,先做完它并独立验证,再做功能主体。

发现规格与现实对不上(接口已变 / 模块不存在)→ 停下来告诉用户,回 ren-spec 修,不在 build 里偷偷绕开。

3. 分步实现

按推进步骤逐步做,每步:

• 能测的先写测试(见下「测试先行」)
• 写代码,遵守 attention.md 里对应栈的约定
• 涉及 DB / 缓存 / 循环调外部资源的步骤:动手前 Read references/data-access-checklist.md 过红线;该步写完,自己当 reviewer 拿清单对照 diff 自查 —— 这类问题要在写的当下接住,留给评审兜底就是返工
• 每步做完对照规格里该步的「做完的标志」自检
• 步与步之间可向用户简短汇报进度,长流程别一口气闷头跑完

测试先行(TDD)

对有明确输入输出的逻辑(函数、Service、校验、状态分支),按 RED → GREEN → REFACTOR:

1. RED —— 先写一个最小测试描述「应该发生什么」,跑一遍看它失败,确认是因为功能缺失而失败(不是 typo)。
2. GREEN —— 写刚好让测试通过的最少代码,别顺手加规格外的功能。
3. REFACTOR —— 绿灯后再清理重复 / 命名,保持绿灯。

为什么先写:测试后补,写完立刻就过,证明不了它真能抓 bug —— 可能测错了东西、可能漏了你忘记的边界。先写先看它失败,才知道测试有效。

适用边界:核心业务逻辑、bug 修复(先写一个能复现 bug 的失败测试)一律先行。纯渲染 / 配置 / 一次性原型可放宽 —— 但「渲染对了就行」不能替代对 API 调用、状态分支、表单校验的断言。拿不准就先写测试。

反"就这次跳过 TDD"借口:"这次很简单" / "时间紧" / "改一行不至于"——都是合理化跳步,不是例外。真正例外只有:一次性原型 / 生成代码 / 纯配置改,且与负责人明确确认过。

4. 边做边守的纪律

• 照规格,不扩范围:实现中发现的 bug → 记下来建议走 ren-fix,不在本次改动里顺手修(混着改验收时分不清范围)。发现规格漏了东西 → 回 ren-spec 补,不自己加。
• 复用优先:写新东西前先想能否复用 / 扩展现有代码 —— 这是熵增的第一道闸。
• 不留占位符:不写 TODO / throw NotImplemented 充数;一步要么真做完,要么明说没做。
• 改完能编译能跑:每步尽量保持可编译。

5. 自检与收尾

全部步骤做完,跑 attention.md 里的构建 / 检查命令,确认通过。然后告诉用户「实现完成,接下来 ren-verify 做交付验收」。

接口契约同步:本次新增 / 改动了对外接口,且该域维护着 arch/openapi/{slug}.openapi.json(供 Apifox 导入联调)时,同步更新该文件 —— 加 / 改对应 path、请求响应结构、鉴权 header。没有该文件、或接口纯内部不外联调,可跳过。详见 ren-arch 的「openapi/ 接口契约文件」。

上线物料清单:本次改动涉及代码之外的上线动作(发哪些服务 / 改配置中心 / 加调度任务 / 跑 DB 脚本)时,在该 spec 目录产出 {slug}-release.md,收成一份可执行清单:上线照着做、verify 照着核、ship 附进 PR。模板与填写说明见 references/release-template.md。纯代码、无上线副作用的改动跳过本产物。

与其他技能的边界

• 不做验收 —— 那是 ren-verify,独立于写代码的人来核对
• 不写规格 —— 规格变更回 ren-spec
• 实现中的踩坑值得记 → 收尾时提示 ren-note

退出条件

• 规格第 4 节每个推进步骤都已实现,每步「做完的标志」自检通过
• 核心逻辑有先行的测试(看过它失败再实现);bug 修复有能复现的失败测试
• 涉及数据访问(DB / 缓存 / 循环调外部资源)的步骤,已对照 references/data-access-checklist.md 自查
• attention.md 的构建 / 静态检查命令已跑且通过
• 无占位符 / 未实现桩
• 实现中发现的 bug / 规格缺口已记录,未在本次偷偷夹带
• 涉及上线动作(发服务 / 配置中心 / 调度 / DB 脚本)时,{slug}-release.md 已产出,每块有内容或标「无」
• 已引导用户进入 ren-verify

容易踩的坑

• 不读 attention.md 就写 —— 命名 / 分层 / 易错点全凭猜
• 循环里逐条查 DB、catch 吞异常这类数据访问病灶等评审才发现 —— 红线清单要在写时过,不是写完补
• 顺手修 bug / 加规格外的东西 —— 验收时范围说不清
• 往偏胖的文件继续塞代码 —— 新逻辑应进新文件
• 用 TODO / 空实现充「做完了」
• 规格跟现实对不上还硬写下去 —— 该停下来回 ren-spec
• 闷头跑完整个流程不汇报 —— 走偏了用户没机会拦