工程规范写进规则与技能
规范有两种落地方式：常驻约束写成规则，按场景执行的流程写成技能。落进这两处的规范才会被 Harness 反复读到；写在会话里的规范，会话一结束就失效。
1这一页管什么
规范落在哪里，以及怎么判定它真的生效；各类规范的具体条目不在这里。
- 管落法与生效判定。常驻约束写规则、按场景执行的流程写技能，外加三条验证规范是否生效的办法。
- 不交由这一页。五类规范与三类补充规范的条目各有一页明细；本轮实现哪些能力属规约；目录结构与启动方式属骨架一页。
- 两种落法。判断依据是生效时机：每次改代码都要遵守的写规则，只在某个动作里走一遍的写技能。
对应的课程知识点：软件过程中的过程资产（process assets）与标准规程、质量门禁（quality gate）、同行评审（peer review）。把规范写进规则与技能，本质是把个人经验转成团队可复用的过程资产——它不依赖某一次会话，也不依赖某一位成员在场。
2两种落法
按「生效时机」区分，不按内容长短区分。
判据只有一句：把这条内容放进规则，看它是否每次改动都被读到；放进技能，看它是否只在对应动作中被调用。两条都对不上，说明这条约束还没想清楚。
3五类规范
五类规范，每类都要落成文件并写清「违反时如何处理」；点击规范名进入该类规范的明细页。
| 规范 | 要写清什么，为什么独立成一类 | 主要落在 |
|---|---|---|
| 产品设计规范 | 用户与场景、页面清单、视图四状态（加载中 / 正常 / 错误 / 空状态（empty state））、文案与术语、表单校验、视觉基线、可达性；前端实现约定并入这一类。独立成类的原因：产品的判定依据是用户能否完成任务，与代码结构无关 | 规则 + 技能 |
| 后端开发规范 | 分层与依赖方向、接口命名与版本控制、请求与响应结构、错误码清单、参数校验的位置、数据访问与事务、幂等与并发、配置外置。独立成类的原因：契约一旦出现第二套写法，所有调用方都要分支处理，而分支是后期最难删除的一类代码 | 规则 + 技能 |
| 安全开发规范 | 默认拒绝（default deny）与逐资源授权判定、越权失败场景、密钥外置与轮换（rotate）、输入校验（validation）与输出转义（escaping）、依赖漏洞扫描频率。独立成类的原因：安全缺陷的后果与功能缺陷不同，且不能靠运行时观察发现，必须左移（shift-left）到编码阶段 | 规则 |
| 测试规范 | 测试层次与用例来源、按正常路径 / 失败路径 / 边界三类组织、数据隔离、一键运行的命令与通过判定。独立成类的原因：测试是唯一能把「完成」变成判定结果的手段，其组织方式直接决定回归成本 | 规则 + 技能 |
| 部署运维规范 | 可复现构建与环境分级、健康检查（health check）与优雅停机、结构化日志（structured logging）与指标、发布与回滚、数据变更顺序、备份与恢复。独立成类的原因：可复现与可回滚决定故障时的恢复时间目标，属运行期质量属性 | 规则 + 技能 |
五类规范各自有一页明细：条目、检查方式，以及本课的最小完成集合。另有三类补充规范（AI 应用、数据、评审与完成定义）视项目性质选做，性能与容量、依赖引入审批两条已并入部署运维与安全开发两页。分类不是行政划分，而是为了让每一类都有明确的判定主体：产品看场景、后端看契约、安全看授权、测试看用例、运维看可复现。规范的价值在于可执行——写「命名要统一」不如写「资源路径用小写复数、参数用驼峰」。可由工具自动检查的写成检查项，只能由人工判定的写入评审表。
4规范怎么才算生效
判定办法只有一种：修改一次代码，检查生成产物。三条办法对应三个层次。
- 用一次改动验证。让 Harness 按规范新增一个接口：目录是否落在规范指定的层、命名是否符合规范、错误是否按规范格式返回。若不一致，说明规范未被读取或写得不够具体。
- 另起一次会话再验一次。另起一个会话做同样的改动，结果应当一致。不一致说明规范没有常驻，还留在上一次会话里。
- 冲突时先改代码。已有代码与规范冲突，改代码；确有理由保留旧写法，就把例外写进规范本身，而不是让规范默许例外。
三条办法对应三个层次：单次改动看产物是否合规，换一次会话看约束是否常驻，冲突时看处置顺序是否写在规范里。规范与规约的分工：规约说明本次要实现什么，规范约束任何一次实现的方式。规约随变更归档进主干分支，规范常驻在规则与技能中。