# 模块 1：案例引子：从状态变更提取资产原料

<div class="mt-6 text-sm">

“取消原因不能为空”看起来只是一个字段校验，实际却处在派车、车辆、司机和行程状态交汇的位置。

这里不讨论如何完成这一项改动，而是用它识别后续可沉淀的约束、提问框架与验证方法。

</div>

<div class="grid grid-cols-4 gap-3 mt-8 text-sm">
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">申请</div>
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">派车</div>
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30">车辆 / 司机</div>
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30">行程</div>
</div>

<!--
逐字稿：先看这个案例的表面，它只是“取消时原因不能为空”。但它触及派车、车辆、司机和行程四条状态线，所以真正要处理的不是一个表单字段，而是状态写入前的业务保护。我们用这个案例提取后续能够复用的判断原料，而不把它当作通用业务答案。

第五天不从“工具能做什么”开始，而是先用真实的状态机模块建立问题背景。模型能看到代码片段，但只有理解状态之间的关系，才有能力判断改动是否越界。
-->

---

# 公务用车模块中的三条状态线

<div class="mt-5 text-xs">

| 对象 | 正常演进 | 取消或完成后的变化 |
|---|---|---|
| 申请 | `DRAFT -> PROCESSING -> COMPLETED` | 取消回到 `CANCELLED` |
| 派车 | `DISPATCHED -> COMPLETED` | 取消变为 `CANCELLED` |
| 车辆 | `AVAILABLE -> RESERVED -> IN_USE` | 取消或行程完成后回到 `AVAILABLE` |
| 司机 | `AVAILABLE -> ON_TASK` | 行程完成后回到 `AVAILABLE` |

</div>

<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
一个派车动作会改变多个对象；校验位置错了，错误状态就会扩散。
</div>

<!--
逐字稿：这里要先建立一个判断：派车不是孤立对象。取消派车会同时改变派车状态和车辆可用状态，后续还可能影响申请和行程的衔接。因此，任何校验如果放在状态写入之后，错误就可能扩散到多个对象。

表中的状态来自 OfficialVehicleConstants，以及派车、出车、归还和验收的 Service 实现。这里不需要讲完整模块，而是让学员建立一个基本认识：不同对象的状态并不是独立的。

取消派车时，派车状态改为 CANCELLED，车辆被释放回 AVAILABLE。任何无效取消都必须在这些写入动作之前被挡住。
-->

---

# 取消派车的真实调用链

<div class="mt-7 text-sm">

```text
取消按钮（仅 DISPATCHED 状态可见）
  -> 取消弹窗（cancelReason 必填）
  -> POST /official/vehicle/dispatch/cancel
  -> Controller（权限 + 审计）
  -> DispatchService.cancel
  -> 派车状态 CANCELLED + 车辆状态 AVAILABLE
```

</div>

<div class="mt-6 grid grid-cols-3 gap-3 text-sm">
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">前端：减少误操作</div>
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30">权限：限制谁能调用</div>
<div class="p-3 rounded-xl bg-red-500/10 border border-red-500/30">Service：保护业务状态</div>
</div>

<!--
逐字稿：这条链路说明了三层保护的职责差异。前端必填是为了减少误操作，权限控制的是谁有资格调用，而 Service 才负责保证业务状态不能被无效请求破坏。只要绕过前端仍能发请求，真正的业务保护就必须落在 Service 的状态写入之前。

这是从 Vue 页面、API 文件、Controller 和 Service 真实读取出的调用链。三种保护不要混为一谈：前端负责交互体验，权限负责调用资格，Service 负责业务规则。

这个区分直接决定了最小改动应该放在哪一层。
-->

---

# 把业务语言变成可验证的目标

<div class="mt-5 text-xs">

| 业务表达 | 可验证的技术表达 |
|---|---|
| 取消必须写原因 | `cancelReason` 不能是 `null`、空串或全空白 |
| 不允许无效取消 | 在读取派车记录、更新派车和释放车辆之前拒绝请求 |
| 不能影响正常取消 | 非空原因仍沿用原有状态更新与资源释放逻辑 |
| 不扩大改动 | 不改变权限、审计、页面交互、数据库字段或行程协议 |

</div>

<div class="mt-6 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
目标越可验证，TRAE 越不容易把一个小需求扩写成跨层重构。
</div>

<!--
逐字稿：业务语言必须被翻译成可验证的技术条件。这里不是笼统地说“原因必填”，而是明确空白值要在读取和写入之前被拒绝，同时确认正常取消仍会完成既有的状态更新和资源释放。这样才能约束改动范围，不让模型把小需求扩大成跨层重构。

这张表建立后续所有分析和提示词的共同输入。业务语言如果只剩“取消原因必填”，模型很容易提出数据库 NOT NULL、Controller 参数校验、前端重构等多种方案。

把边界写成可验证的技术表达，才能比较不同方案是否贴合当前项目。
-->

---

# 从案例中提取资产原料

<div class="grid grid-cols-3 gap-4 mt-8 text-sm">
<div class="p-4 rounded-xl bg-blue-500/10 border border-blue-500/30">
<div class="font-bold">项目事实</div>
<div class="mt-2 text-xs op-70">状态、入口、权限、写入顺序和测试结构。</div>
</div>
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
<div class="font-bold">重复判断</div>
<div class="mt-2 text-xs op-70">哪些结论下次同类任务仍然需要重新做。</div>
</div>
<div class="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
<div class="font-bold">可沉淀资产</div>
<div class="mt-2 text-xs op-70">Rule、Prompt、Skill、检查单和反例各自承接什么。</div>
</div>
</div>

<!--
逐字稿：到这里，案例本身的任务已经完成了。我们已经拿到项目事实，也识别出哪些判断会在同类任务中反复出现。接下来要做的是把这些判断分别交给合适的资产承载，而不是把代码结论原样复制到下一个项目。

案例到这里完成它的作用：提供真实、可核对的资产原料。第五天后续模块的核心不再是这一次改动，而是如何把这些原料拆成可以在下一次任务中复用的工程资产。
-->