骨架与核查清单
骨架是可启动的最小实现：它不含任何业务功能，却决定后面每一次增量能不能叠加得上去。这一页给出骨架的五件事、完成现象，以及提交前逐条打勾的核查清单。
1这一页管什么
骨架（skeleton）是可启动的最小实现：不含业务，却有完整的分层、配置、健康检查与日志。
- 管运行骨架的五件事。分层与目录、配置外置、健康检查端点、结构化日志、一键启动，以及提交前的核查清单。
- 不交由这一页。往各层里加模块时要遵守的约束属规范各页；本轮实现哪些能力属规约；规范如何落进规则与技能属上一页。
- 落法。分层、命名、配置读取方式写成规则；「按规范加一个接口」「从零启动一次」这类流程写成技能。骨架只用
/opsx-apply执行骨架那一组任务，一次生成整套业务是这一页最需要避免的做法。
对应的课程知识点：软件体系结构中的分层架构（layered architecture）与依赖倒置（Dependency Inversion）、最小可运行骨架（walking skeleton）、就绪与存活探针（readiness / liveness probe）、可复现构建（reproducible build）。骨架的价值不在功能，而在它把「能启动、能观察、能复现」这三件事先固定下来。
2骨架要包含什么
五件事，缺一件则后续课次都要补做；每件都写明为什么。
- 分层与目录。接口层、业务层、数据访问层自外向内排列，外部能力收在最外侧的适配层（adapter）；依赖方向单一，不允许反向依赖。反向依赖一旦出现，改动任何一层都要通读全部代码。
- 配置外置。地址、密钥、特性开关一律从环境变量读取；代码里不出现字面量，也不以默认值降级——缺了就启动失败，比取到错误值继续运行更容易暴露故障。
- 健康检查（health check）。入口提供免认证访问的健康检查端点
/health，返回版本、时间与外部依赖的连通状态。它是就绪探针（readiness probe）的落点，编排据此判断是否可以接入流量；后续课次的验收也都从它开始。 - 结构化日志（structured logging）。单行 JSON，带请求标识（request ID）。请求标识是串联一次请求跨模块行为的唯一线索，事后补加会漏掉大量路径，所以从骨架阶段就写成这样。
- 一键启动。容器化编排文件（Dockerfile 与 Compose）随骨架入库，一条命令把应用与依赖一并启动。可复现构建是回归与故障复现的前提，靠口头步骤做不到这一点。
3完成现象与归档
完成现象要能当场演示，归档要留下可对比的基线。
克隆拿到仓库最新代码
填配置复制示例配置为本地配置并填入取值
一条命令应用与依赖一并启动
健康检查
/health 返回成功四步之间不需要任何人工补充说明——需要补充就说明 README 还没写全，补的是文件，不是口头解释。骨架定下来后归档本次变更并打标签（tag，如 v0.0.1-skeleton），作为后续课次对比的基线；实现过程中对设计与规范的调整，同步回设计文档、任务清单与规范文件。
对应的课程知识点：基线（baseline）与回归测试（regression testing）——打过标签的骨架版本是后面每次回归的对照物，出问题时可以先回到它，判断是新增能力引入的还是骨架本身的问题；可复现构建保证不同机器上得到同一结果，这也是交叉评审能够成立的前提。
4核查清单
提交前逐条勾选；勾选不上的那一条就是本课没做完的部分。
| 维度 | 怎么算通过 | 核对 |
|---|---|---|
| 仓库 | 地址可访问且教师具备访问权限；按 README 能从零跑起来；在仓库全部提交历史中检索不到任何密钥明文 | |
| 规约 | 四份文件齐备；校验命令 --strict 通过；每条能力至少一组场景，其中失败路径不少于四条；能力与场景的对应关系可列出 | |
| 规范 | 五类规范均已落成文件并置于 Harness 可读取的位置；修改一次代码，生成产物的分层与命名符合规范；另起一次会话结果仍一致 | |
| 骨架 | 分层无反向依赖；配置全部外置且缺失即启动失败；/health 免认证可访问并返回外部依赖连通状态；日志单行 JSON 且带请求标识（request ID） | |
| 交付 | 骨架版本标签存在；验证记录已归档到仓库的 docs/ 目录；组内另一名成员在自己机器上从零启动成功 |
最后一条是交叉评审（peer review）：由组内另一名成员在自己机器上按 README 从零启动一次，在哪一步受阻就改哪一步。新成员能否成功启动，是骨架是否合格的唯一外部标准。
对应的课程知识点：完成定义（Definition of Done, DoD）与质量门禁（quality gate）。这张表就是本课的完成定义——每条都写成可判定的现象才能当门禁用；写不出判据的一条，等于这一维度没有要求。