Ren bootstrap

ren-bootstrap

启动必读

先 Read .ren-flow/attention.md。工作区模式：确认本次新应用归哪个业务域（或要不要新立域），新代码落点 repo 路径要先和用户对齐。

这个技能干什么

把一个全新仓库 / 服务从零带到「可编译、能起、能部署」的骨架状态。它管的是实际应用代码骨架（src/、CI、部署配置 —— Dockerfile / K8s / Serverless 等，按团队部署形态），不是 ren-flow 元数据目录。

与 ren-init 的边界（别混）：

	ren-bootstrap	ren-init
产出	新 repo 的应用代码骨架 + CI / 部署配置	.ren-flow/ 工作流元数据目录
何时	立项一个新服务 / 新前端	给已有代码接入 ren-flow 流程
关系	先 bootstrap 搭骨架 → 再 init 接工作流 → 再 spec 开第一个功能	—

核心纪律：先查沉淀,再动手

新应用立项是高复用场景 —— 同类脚手架、同类踩坑大概率有人做过。开工前必须按序查：

1. Glob .ren-flow/templates/** —— 有没有现成脚手架（cicd/、app-skeleton/{lang}/、k8s/）。找到 → 复制改占位符;没有 → 从零搭,用完回填到 templates/ 供下次复用。
2. Glob .ren-flow/**/notes/ + Grep 关键词 —— 同类立项清单（如某份 new-service-checklist.md 记了新服务上线的 容器平台 / 配置中心 / Ingress / 网关 / 权限菜单 等步骤）。
3. 查已有约定（memory / CLAUDE.md / 团队规范文档）—— 框架版本坑（如某框架升大版本后启动路由注册方式变了、默认端口变了、依赖注册写法变了）、命名 / 数据规范。

不查就照抄旧仓库是头号事故源 —— 旧版本模板抄到新版本仓库常直接崩。

流程

1. 对齐要建什么

确认：语言 / 框架、服务类型（API 服务 / 管理后台 / 消息消费者 / 定时任务 / 前端）、落点 repo 路径、配置中心标识 / 命名空间（若团队用配置中心）、归属业务域。拿不准的逐项问，别假设跟某个旧仓库一样。

2. 查沉淀（上面三步，强制）

把找到的模板、清单、踩坑列给用户，说明本次复用哪些、从零搭哪些。

3. 搭骨架

按项目惯例 + 召回的约定建最小可跑骨架：

• 目录分层（按你框架 / 团队的标准结构，见项目 attention.md）
• 入口项目能编译、健康检查端点能过（注意有些框架要显式注册路由 / 中间件才生效）
• CI + Dockerfile + 部署配置（按团队部署形态），优先抄同框架版本的正确范本（别抄到跨大版本的旧范本）
• 配置占位（配置文件 / 配置中心），敏感值留占位符不写死
• 接入集中日志 / 可观测性时：按项目 notes 的新服务清单关联公共观测配置、并把 ServiceName 类字段覆盖成本应用标识（具体公共配置名 / 字段随环境，见项目层清单）

4. 自证可起

至少跑通构建（如 dotnet build / npm run build / go build，按栈）；能本地起则起一下确认健康检查端点。不留 TODO 空壳充数 —— 骨架要真能跑，不是摆样子。

5. 回填 + 交棒

• 本次从零搭的可复用部分（CI 配置 / 骨架）→ 回填 .ren-flow/templates/，下次直接复用
• 提示后续：ren-init 接工作流 → ren-spec 开第一个功能
• 立项中踩的新坑 / 定的新约定 → ren-note

退出条件

• 已查过 templates/ + notes 立项清单 + 已有约定（memory / CLAUDE.md），复用 / 从零的边界说清
• 骨架可编译（贴构建输出），关键探针 / 路由不是 404 空壳
• CI / 部署配置抄的是同框架版本的正确范本
• 敏感配置留占位符，未写死凭证
• 可复用产物已回填 templates/；已提示接 ren-init / ren-spec

容易踩的坑

• 不查 templates / 清单 / memory 就照抄旧仓库 —— 版本差导致探针 404 / CrashLoop / 编译报错
• 骨架留一堆 TODO 空实现就说「搭好了」—— 必须真能编译能起
• 把 ren-bootstrap 和 ren-init 混为一谈 —— 一个搭应用代码，一个接工作流
• 敏感配置直接写死进 yaml / appsettings
• 从零搭完不回填 templates/ —— 下次又得重来一遍