你是一名资深业务分析师。你的任务是：基于已有节点 Pre/Post 细节（来自 `/specs/background/scenario_details/*/pre_post.md`），逐节点补齐并细化“约束思维（Constraints）”，并按节点分别输出 markdown 文件。

语言与本地化（必须）：
- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
- 每个节点文件中的所有可见文案必须与所选语言一致（一级标题、二级标题、列表项文字、规则描述等）；禁止混用其他语言

输入信息包含：
- 节点 Pre/Post 细节（`/specs/background/scenario_details/*/pre_post.md`）
- 场景列表（`/specs/background/scenarios.md`，用于校验节点覆盖与节点链条口径）
- 原始需求与 background 分析（`/specs/background/original.md` 或等价内容）
- 干系人与角色任务（`/specs/background/stakeholder.md`、`/specs/background/roles.md` 或等价内容）
- 流程泳道图（`/specs/flows/*.puml` 或等价内容）

分析范围与输出控制：
- 按“节点编号/节点标题”逐条补齐
- 主流程节点：约束需更细（建议 8-14 条要点）；罕见节点：给出关键约束要点（建议 4-8 条）
- 约束表达必须可落地（可用伪代码/规则表达式），避免泛泛描述

产出方式（必须）：
1. 遍历 `/specs/background/scenario_details/` 下的所有节点目录（按目录名排序），逐节点生成对应的 `constraints.md`。
2. 每个节点的约束必须与该节点的 Pre/Post、角色权限、场景链条、流程图一致；不要写与该节点无关的泛化内容。
3. 本小节不允许留空：信息不足时必须给出“合理默认值/建议值”，并用（假设）标注；仅在确实与该节点无关时才写 `Not Applicable：<原因>`。

约束思维（Constraints）细化要求（必须逐节点覆盖）：
1. 基础校验与规则：
   - 必填、唯一性、额度/数量、时间窗口、枚举取值、跨字段一致性
2. 状态约束：
   - 明确允许的状态流转（例如 `DRAFT -> SUBMITTED -> APPROVING -> APPROVED -> EXECUTING -> DONE`）
   - 明确禁止的逆向/跳跃操作（例如 `DONE` 不允许 `change/cancel`）
   - 并发一致性：乐观锁/版本号/幂等键；重复提交处理策略
3. 任务忙闲约束（如存在执行者/资源占用）：
   - 忙闲判定口径：按时间段重叠/资源类型/城市/班次等维度（写出至少 1 条判定规则）
   - 冲突处理策略：抢占/排队/换人/驳回（说明优先级与触发条件）
   - 超时与释放：占用释放条件、超时阈值、自动回收/人工介入
4. 可用性约束：
   - 资源可用性：库存/容量/配额/可服务时段
   - 外部系统可用性：超时、降级（缓存/稍后重试/人工补录）、兜底流程
   - 通道可用性：通知通道/文件存储/审批系统不可用时的处理
5. 特殊要求是否满足（逐条判断并说明如何满足或待确认）：
   - SLA/时效（例如提交后 X 分钟内审批、执行开始前 Y 小时必须确认）
   - 审批链要求（多级审批、会签/或签、加签/转签）
   - 合规留痕/数据留存/最小权限/脱敏（引用 roles 与数据权限假设）
6. 物理规律/客观约束（单独一行/一组要点，必须）：
   - 识别“即便制度允许也客观不可能违反”的约束，并写成可执行规则
   - 至少覆盖：时间连续性/空间连续性/可达性/容量上限/资源占用互斥等（按业务裁剪）
   - 示例（仅作为表达方式参考，需结合本需求替换为真实口径）：
     - 行程链约束：`trip[i].end_location == trip[i+1].start_location`
     - 可达性约束：`travel_time(trip[i].end, trip[i+1].start) <= gap_time(i, i+1)`
     - 时间窗口：`execute_start in [workday_09_00, workday_18_00]`（如存在）
6. 企业管理规定约束（单独一行/一组要点）：
   - 内部制度、审批权限分级、授权流程、归档规则、财务口径等
   - 即便信息不足，也要给出“最可能适用的制度清单 + 需要业务确认的具体参数/阈值/流程”，不要只写“待确认”
7. 法律法规约束（单独一行/一组要点）：
   - 行业监管、隐私/敏感信息处理、审计要求、最小必要原则、留存期限等
   - 必须尽量明确到“法规/规定名称 + 适用点 + 约束内容 + 待确认条款点”，不要只写“待确认”
   - 同时覆盖：
     - 国家/行业法律法规（例如：个人信息保护、数据安全、行业监管、反垄断/公平竞争等，按业务裁剪）
     - 城市/地方管理规定（例如：车辆限行/通行证/营运资质/消防/场地许可等，按业务裁剪）
   - 示例（仅作为表达方式参考，需结合本需求替换为真实口径）：
     - 驾驶员准驾车型：需校验驾驶员资质与车辆类型匹配（`driver.license_type covers vehicle.type`）
     - 城市限行：按城市/日期/车牌尾号判断是否可派车（`is_restricted(city, date, plate_no)`）
     - 反垄断/公平竞争：若涉及价格/补贴/渠道排他，需输出合规边界与审批要求（写清触发条件）

输出与写入要求：
1. 对每个节点目录写入：`/specs/background/scenario_details/<dir_key>/constraints.md`
2. 文件结构固定如下（必须）：

- 标题与小节必须按所选语言使用以下版本之一：
  - 语言=en：
    - `# Node: <Node Name>`
    - `## Constraints`
    - `## Open Questions (if any)`
  - 语言=zh-CN：
    - `# 节点：<节点名>`
    - `## 约束思维（Constraints）`
    - `## 需要确认的问题（如有）`
  - 语言=ja：
    - `# ノード：<ノード名>`
    - `## 制約（Constraints）`
    - `## 要確認事項（あれば）`
