这次不拿你的真实项目冒险。你会下载一个只有 6 个文本文件、没有依赖和网络请求的练习仓库：普通用户满 99 元免运费的旧功能已经能工作，新需求是增加“会员满 59 元免运费”和非法金额检查。
任务有一个清楚的前后对照：修复前 2 项基线通过、3 项验收失败；修复后必须 5 项全部通过，并且只能修改一个源码文件。
下载练习包和验收表
- 下载 WorkBuddy Coding 练习 ZIP
- 下载空白验收表
- 下载参考补丁：完成自己的修复后再打开。
- 查看本站练习校验记录：区分材料测试与 WorkBuddy 实测。
本站已在 Node.js 24.15.0 上运行这套练习。参考补丁能让 5 项测试通过，但这只验证练习项目，不代表 WorkBuddy 已被本站实测。
解压后目录应是：
workbuddy-coding-lab/
README.md
package.json
task.md
src/shipping.js
test/baseline.test.js
test/acceptance.test.js第一步：自己建立可回滚基线
在终端进入练习目录：
git init
git add .
git commit -m "Add shipping rule exercise"
npm run test:baseline
npm run test:acceptance预期结果：
| 命令 | 修复前预期 | 用途 |
|---|---|---|
npm run test:baseline | 2 通过、0 失败 | 证明旧规则本来可用 |
npm run test:acceptance | 0 通过、3 失败 | 证明新需求尚未实现 |
git status --short | 无输出 | 给 Worktree 一个干净 HEAD |
验收测试失败是练习设计，不是安装故障。若基线测试也失败，先确认 Node 版本、解压目录和文件完整性，不要交给 Agent 猜环境问题。
第二步：创建 Worktree Task
在 WorkBuddy 新建任务，选择练习仓库。只要工作空间含 .git，当前官方界面会显示 Worktree 开关：
- 打开 Worktree。
- Base Branch 选择刚才提交所在的分支。
- 保持默认权限。
- 附上或粘贴
task.md的内容后发送。
WorkBuddy 会基于 Base Branch 的 HEAD commit 在 ~/WorkBuddy/Worktrees 建立隔离目录，并生成 workbuddy/... 任务分支。源目录里的未提交改动不会自动带入，这是为什么前一步要先提交练习文件。
非 Git 目录不会显示 Worktree；当前官方说明也明确 V1 不支持云端 WorkBuddy、CodeBuddy、非 Git 项目或跨仓库任务。看不到开关时，不要假装已经隔离，可先完成 git init 与首个 commit 后重新新建任务。
第三步：先用 Ask 检查项目，不允许修改
在“+ → 模式”开启 Ask（仅问答），发送：
只读检查 README、package.json、src 和 test。
说明当前规则、目标规则、允许修改的唯一文件、三个测试命令；
分别运行基线与验收测试，报告通过数和失败数。
不要修改文件、安装依赖、提交或推送。通过条件：它指出 src/shipping.js 是唯一可改文件，识别普通用户阈值 99、会员阈值 59 和 RangeError 要求，并报告 2 个基线通过、3 个验收失败。
如果它只说“测试失败”，继续要求给出实际命令、退出状态和失败用例名称。模型解释不能替代命令输出。
第四步：用 Plan 审查最小修改
关闭 Ask，开启 Plan：
为这个任务制定执行计划。只允许修改 src/shipping.js；
不得修改测试、package.json、README 或 task.md，不得安装依赖。
计划必须列出输入校验、普通用户与会员阈值、要运行的命令、
diff 检查和回滚方法。等我确认后再执行。一个合格计划不需要重构项目、增加类或引入第三方库。核心实现只需处理参数校验、选择阈值并返回运费。
第五步：确认计划，让默认 Agent 执行
点击“开始执行”。当前 WorkBuddy 把可修改文件的默认执行模式称为 Agent，旧教程里的 Craft 已不是当前三模式名称。
过程中遇到权限确认时，检查三点：命令是不是 npm、node 或只读 Git 命令，路径是不是 Worktree，操作有没有越过唯一允许文件。这个练习不需要开启对整个客户端所有任务生效的完全访问。
执行结束后发送一个停止修改的交付要求：
不要继续改文件。请报告：
1. 实际修改文件；
2. npm test 的通过数、失败数和退出状态；
3. git diff --stat 与完整 diff；
4. 未执行的检查；
5. 如何撤销本次修改。第六步：独立核对，不只看 Agent 总结
在 WorkBuddy 的终端或你自己的终端里核验任务 Worktree：
npm test
git diff --check
git status --short
git diff -- src/shipping.js
git diff -- test package.json README.md task.md预期证据：
npm test：5 通过、0 失败。git diff --check：无输出。git status --short：只有M src/shipping.js。- 最后一条 diff 命令：无输出，证明测试和任务定义没被改。
然后再打开参考补丁。实现不必逐字相同，但这些边界必须一致：
| 输入 | 预期运费或错误 |
|---|---|
shippingFee(99, false) | 0 |
shippingFee(98, false) | 10 |
shippingFee(59, true) | 0 |
shippingFee(58, true) | 10 |
shippingFee(-1, false) | 抛出 RangeError |
三种典型假通过
修改测试来适配错误实现
测试全绿也判失败。需求和验收文件是任务边界，不允许 Agent 降低断言。
把所有会员都设为免运费
shippingFee(58, true) 必须仍返回 10。只覆盖一个成功案例的实现不完整。
主目录通过，Worktree 没有改动
检查任务标题旁的 worktree 标识和任务分支；官方说明 Worktree 与主仓库文件系统隔离。不要在错误目录里运行验收命令。
测试不符合预期怎么查
找不到 npm： Node 没加入 WorkBuddy 进程的 PATH。先在系统终端确认 node --version 和 npm --version，重启客户端后再试。
**出现模块语法错误：**确认 package.json 仍含 "type": "module"，且 Agent 没改文件类型。
**只剩负数测试失败：**检查实现是否在比较阈值前验证 Number.isFinite(orderTotal) 与小于 0 的情况。
**出现额外文件：**先查看内容和来源，不使用危险清理命令。确认只是生成物后，再要求 Agent 列表化删除并重新检查 status。
何时算真正完成
- 修复前的 2/0 与 0/3 结果被记录。
- 任务运行在正确的 Worktree 和任务分支。
- Plan 明确只修改
src/shipping.js。 - 修复后 5 项测试通过，diff 没有空白错误。
- 测试和任务定义未被修改。
- 参考补丁、Agent 输出和你独立运行的结果三者没有混为一种证据。