| name | hf-frame |
| description | HarnessFlow frame 阶段(主链入口)。任何新特性、行为变更或缺陷修复开始时使用:把用户意图定格为一页 frame.md——意图、范围、风险档位(1 微改/2 标准/3 高危)及理由,并用 hf_gate.py run 建立环境基线(全量测试/构建能否真实运行)。不写需求细节、不做设计。产出的档位决定后续流程形态。 |
Frame(定格)
目标:回答三个问题——要做什么(一句话意图与范围)、多危险(风险档位)、这个项目我能验证吗(环境基线)。frame 是唯一没有独立评审的阶段,所以它只允许装低成本、可被后续评审推翻的决定;拿不准的一律往高档靠。
流程
1. 建目录与定意图
读用户请求与相关既有代码。取 features/ 下一个编号创建 features/<NNN>-<slug>/ 与 progress.md(格式见 hf-workflow)。把意图压缩成一句话;会改变范围或验收标准的阻塞性未知项,合并成尽量少的轮次一次问清,不逐条追问;可合理假设的次要项写入 frame.md 假设区,标注"如不对请指出"。
2. 定风险档位
对照判据,从高往低判,任一命中即入该档:
| 档位 | 判据(任一命中) |
|---|
| 3 高危 | 数据迁移/删除;认证、授权、支付等安全面;跨 ≥3 模块的结构调整;破坏公共 API 或存储格式;不可逆操作 |
| 2 标准 | 新功能、行为变更、非平凡缺陷修复;默认档 |
| 1 微改 | 单点小改(典型 ≤2 个文件),行为边界清晰,可逆,不碰数据/安全/公共接口 |
档位理由必须落盘,可被冷读检验。档位由后续评审复核:档位 2/3 在 plan 层评审复核,档位 1 在代码评审复核(diff 与档位不符即严重 finding,升档重走)。
3. 建环境基线
用机械门禁真实运行项目的全量测试(或构建):
python3 skills/hf-workflow/scripts/hf_gate.py run \
--feature features/<NNN>-<slug> --label baseline -- <全量测试命令>
- 找不到测试命令时,读 README、CI 配置、包管理脚本(package.json / Makefile / pyproject 等)。
- 基线失败(环境坏 / 既有测试红):恢复可验证性优先——要么当场修好基线再继续,要么把"恢复基线"列为计划的 T-1。基线可运行之前,后续任何 TDD 证据都不成立。
- 全新项目:基线 = 搭起最小可运行的测试骨架并跑通一个空测试。
4. 写 frame.md 并推进
# <特性名> Frame
- 日期: YYYY-MM-DD
- 意图: <一句话:为谁改什么、改到什么程度算完成>
- 范围外: <明确不做的;无则写"无">
- 风险档位: 1|2|3
- 档位理由: <对照判据,可被冷读检验>
- 环境基线: evidence/baseline-<ts>.log (exit <N>)
- 基线说明: <跑了什么命令;失败时的恢复计划>
- 假设: <未经确认的合理假设;无则写"无">
- 档位 ≥2 → 运行
gate check --to plan,PASS 后进 hf-plan。
- 档位 1 → 运行
gate check --to build,PASS 后直接进 hf-build。
- RESULT 行记入 progress.md 的"门禁输出"。
红线
- 跳过基线直接进 plan/build("这个项目肯定能跑"不算证据)
- 为省流程把明显碰安全/数据/公共接口的改动定为档位 1 或 2
- 档位理由写成"感觉不大"这类不可检验的句子
- 在 frame 里写接口签名、表结构、框架选型等设计内容(那是 plan 的事)
- 阻塞性未知项不问清,靠猜测开工
