@lark-people/cli 0.0.0-beta.1

package/skills/people-overtime/SKILL.md

@@ -0,0 +1,992 @@
+---
+name: people-overtime
+version: 1.3.0
+description: "飞书加班：支持查询加班审批记录、查询加班提报记录、加班月度汇总、发起加班申请。涉及查询加班、加班记录、加班时长、加班审批、加班汇总、calculation_tag、加班提报、发起加班等关键词时必须使用本 skill。"
+metadata:
+  requires:
+    bins: ["people-cli"]
+  cliHelp: "people-cli attendance --help"
+---
+
+# attendance (v1)
+
+## 🚨 PR0：评测固化的英文场景错误（每次进入本 skill 必须先扫一遍）
+
+> 测评数据反复出现 ——「英文 query + 海外（SGP/MY）+ 加班查询」场景下，LLM 仍把中文 status / 中文 calculation_tag / 中文 display_name / 中文星期直接抛给英文用户。本节是**最高优先级**入口硬规则，违反任意一条都直接导致评分不通过。
+
+1. **英文 query → 英文回复（语种镜像，最高优先级）**
+   - 用户 query **整句英文** / 主词为英文（`overtime` / `OT` / `submit overtime` / `apply overtime` / `overtime hours` / `overtime summary` / `overtime status` / `overtime approval` 等） / 含纯英文日期表达（`today` / `yesterday` / `last week` / `last Monday` / `May 5` 等）
+     → 面向用户的**所有可见文字**（结论、字段名、表头、status、unit、calculation_tag、display_name、reason、星期、日期回显模板、空结果话术、拒绝话术、Step -1 地域确认提示）**必须全部英文**，**禁止**任何中文字符出现在回复中。
+   - **混合 query 时**：query 整句英文 / 主词为英文 → 全英文回复；query 主词中文 → 全中文回复；混合时按整句主体语种判定。同一会话内一旦判定语种，必须保持一致直到用户切换语种。
+
+2. **海外（非 CN）场景的接口与字段强约束**
+   - **必传 `accept_language="en-US"`**：英文 query 调用 `submission.get` (`time_type=2`) / `submission.query_month_summary` 时**必须**显式传 `"en-US"`，不允许省略、不允许默认、不允许 `en` / `en_US` / `en-us` / `en_us` / `english` / `EN-US` 等任何变体。
+   - 即使该字段已显式传 `en-US`，**仍**有极少数 corner case 会返回 `【SGP】1.5 倍时薪` / `【SGP】调休假` / `已通过` / `小时` 这类中文字面值。LLM **必须**核验返回值，按下方「字段值映射表」手动翻译成英文再展示，**禁止**直接抛中文给英文用户。
+
+3. **CN 场景的字段必须翻译**
+   - `user_approval_over_time.list` / `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` / `+overtime-apply-convert` 这些接口**不支持 `accept_language`**，返回字段必为中文。
+   - 当英文用户被路由到这些 CN 接口（已确认 CN 员工或回退场景）时，LLM **必须**手动按映射表把中文字段（status 数字 → Approved/Rejected/...、reason 中文 → 英文意译、星期 → Monday~Sunday）翻译成英文后再回复，禁止直接抛 `已通过` / `星期一` / `项目上线` 这类中文给英文用户。
+
+4. **字段值映射表（必备速查）**
+   | 中文（绝不能出现在英文回复中） | 英文等价 |
+   |---|---|
+   | 已通过 / 审批中 / 已拒绝 / 已撤回 / 已撤销 / 更正审批中 / 已取消 | Approved / Approving / Rejected / Withdrawn / Cancelled / Pending correction / Cancelled |
+   | status 数值 (0/1/2/3/4) | Approving / Rejected / Approved / Withdrawn / Cancelled |
+   | 小时 / 天 / 半天 / 半小时 | Hour / Day / Half day / Half hour |
+   | unit 数值 (1/2/3/4) | Day / Hour / Half day / Half hour |
+   | 出勤 / 加班 / 加班记录 / 加班审批单 / 月度汇总 / 加班提报记录 | Attendance / Overtime / Overtime record / Overtime approval / Monthly summary / Recorded overtime |
+   | 星期一 / 星期二 / 星期三 / 星期四 / 星期五 / 星期六 / 星期日 | Monday / Tuesday / Wednesday / Thursday / Friday / Saturday / Sunday |
+   | 加班原因 / 加班时长 / 加班日期 / 加班类型 / 计算方式 / 补偿方式 | Overtime reason / Overtime duration / Overtime date / Overtime type / Calculation method / Compensation method |
+   | 工作日加班 / 调休假 / 加班费 / 节假日加班 / 周末加班 | Working Day Overtime / Time off in Lieu (Overtime) / Overtime Pay / Public Holiday Overtime / Weekend Overtime |
+   | 【SGP】常规出勤 / 【SGP】1 倍日薪 / 【SGP】1.5 倍时薪 / 【SGP】2 倍日薪 / 【SGP】调休假 | Regular Hours / 1 Daily / 1.5 Hourly / 2 Daily / Time off in Lieu (Overtime) |
+   | 项目上线 / 线上故障 / 项目交付 / 业务支持 / 临时排查 | Project launch / Production incident / Project delivery / Business support / Ad-hoc troubleshooting |
+   | 无加班记录 / 无出勤记录 / 无记录 | No overtime records / No attendance records / No records |
+   | 操作频繁，请5秒后重试 | Operation too frequent, please retry after 5 seconds |
+   | 暂时不支持非CN大陆提交加班，请前往审批系统提交 | Submitting overtime via CLI is only supported for China Mainland (CN) employees. Please submit your overtime application via the approval system. |
+
+5. **回显与回复模板（英文 query 必备）**
+   - **Step -1 地域确认（英文）**：
+     ```
+     To route your overtime query to the correct API, please confirm your work location first:
+     1) China Mainland (CN)
+     2) Overseas (Singapore SGP / Malaysia MY / other overseas regions)
+     Reply with 1 or 2, or tell me your country directly.
+     ```
+   - **日期单日**：`Today is {YYYY-MM-DD} ({weekday}). The date you're asking about is {resolved_date} ({resolved_weekday}). Proceed.`
+   - **日期范围**：`Today is {YYYY-MM-DD} ({weekday}). The range you're asking about is {date_from} ({from_weekday}) ~ {date_to} ({to_weekday}), {N} days in total. Proceed.`
+   - **空结果**：`No overtime records for {date or range}.`（**禁止**追加 `（duration=0, unit=hour）` / `(duration=0, unit=hour)` 之类的零值结构化尾巴）
+   - **拒绝（未来）**：`Future dates are not supported for overtime queries.`
+   - **拒绝（写场景非 CN）**：`Submitting overtime via CLI is only supported for China Mainland (CN) employees. Please submit your overtime application via the approval system.`
+   - **拒绝（写场景超 2 段）**：`A single overtime application supports at most 2 segments. Please reduce to 2 or fewer segments.`
+   - **拒绝（他人）**：`Only the current logged-in user's overtime records are supported.`
+   - **拒绝（撤回 / 取消 / 修改）**：`This skill only supports submitting overtime applications. Withdrawing / cancelling / modifying applications is not supported.`
+   - **限流命中**：`Rate limit hit (99991400) when querying {date}. Please retry later.`
+
+6. **回复前自检清单（英文 query 必做）**
+   - [ ] 回复正文是否含任何**中文字符**？若有 → 立即按映射表翻译再发出
+   - [ ] `status` / `unit` / `calculation_tag` / `display_name` / `reason` / `weekday` 是否都为英文？
+   - [ ] 日期回显是否使用脚本返回的 `anchor_weekday` / `resolved_weekday`？
+   - [ ] 调用 `submission.*` 时是否已传 `accept_language="en-US"`？
+   - [ ] 空结果文案是否为 `No overtime records for ...`，而非 `2026-06-15: 无加班记录` / `(duration=0, unit=hour)`？
+
+> **入口检查口令**：① 主词（出勤 vs 加班） → ② 语种（英文/中文） → ③ Step -1 地域 → ④ Step 0 日期 → ⑤ accept_language（仅 submission.* 必传） → ⑥ 调接口 → ⑦ **回复前自检中文残留** → 用对应语种回复。
+
+
+
+## ⚠️ Step -2 业务主词识别（最优先，先于地域、先于日期）
+
+> **背景**：评测人工原因分析显示高频误路由 —— 用户问的明明是「出勤」（如「查询 2026 年 5 月份带有 Overtime Pay 标签且状态为更正审批中的**出勤**记录」「本月 calculation_tag=1.5x Daily Salary 的**出勤**汇总」「SGP 本月 2x Daily Salary **出勤**汇总」），但模型仅凭 query 中出现了 `Overtime Pay` / `1.5x` / `2x Daily Salary` / `Working Day Overtime` / `Time off in Lieu` 等 calculation_tag 字面值就直接判定为「加班」，错误进入本 skill。**严禁此类反推**。
+
+### 进入本 skill 的硬性前提
+
+进入本 skill 之前，**必须先识别用户的业务主词**，且**只有主词命中"加班"时才进入本 skill**：
+
+| 业务主词 | 路由 |
+|---|---|
+| `加班` / `overtime`（**独立词**，不包含 `Working Day Overtime` / `Overtime Pay` 这类被嵌入到 calculation_tag 字面值里的 overtime） / `OT`（独立缩写） / `补加班` / `加班审批` / `加班提报` / `加班汇总` / `加班记录` / `加班时长` / `加班费` / `调休` / `发起加班` / `申请加班` | **本 skill** |
+| `出勤` / `attendance` / `出勤提报` / `出勤汇总` / `出勤记录` / `出勤时长` / `出勤天数` / `上班时长` / `迟到` / `早退` / `缺勤` / `打卡` | **改用 `people-attendance` skill**，**禁止**进入本 skill 调用 `submission` (`time_type=2`) 或 `user_approval_over_time` |
+
+### 关键规则（绝对不允许放宽）
+
+1. **calculation_tag 字面值不是加班路由信号**：`Overtime Pay` / `Working Day Overtime` / `1.5x Daily Salary` / `2x Daily Salary` / `Time off in Lieu` / `Saturday OT` / `Sunday OT` / `1.5 Hourly` / `Normal Working Hours` / `Regular` / `by_duration` / `by_time` 等都只是**计算标签字段值**。这些标签**同时存在于出勤提报（`time_type=1`）和加班提报（`time_type=2`）数据**中。**禁止**仅凭 query 中包含这些字符串就把意图判定为「加班」并进入本 skill。
+2. **只看主词，不看修饰词**：当 query 同时出现「出勤」与 calculation_tag 字面值（如 "Overtime Pay 标签的**出勤记录**"、"1.5x Daily Salary 的**出勤**汇总"）时，主词为**出勤**，必须切到 `people-attendance` skill 用 `submission.get` (`time_type=1`) 处理；calculation_tag 只是过滤条件，不改变路由。
+3. **混用主词时按出勤优先**：当 query 同时出现"出勤"和"加班"两个主词且无法清晰拆分时（罕见），先反问用户「您是想查出勤记录还是加班记录？」，**禁止**默认按加班处理。
+4. **`Overtime Pay` 标签不等于"加班费"业务主词**：`Overtime Pay` 是 calculation_tag 字面值（出勤提报里也会出现），与中文业务主词「加班费」不能等同看待。用户问「Overtime Pay 标签的出勤」必须按出勤路由；用户问「我的加班费有多少」才属于加班路由。
+5. **只引用了 calculation_tag 字面值、无任何业务主词时**：例如 "上周 Working Day Overtime 几小时"、"本月 2x Daily Salary 多少"，**不要**默认进入本 skill；先反问用户「您查询的是出勤提报（attendance）记录还是加班提报（overtime）记录？」。
+
+### 反例（绝对禁止）
+
+- ❌ 用户问「查询 2026 年 5 月份带有 Overtime Pay 标签且状态为更正审批中的**出勤**记录」 → 模型看到 `Overtime Pay` 直接进入 `people-overtime` 走 `submission.get` (`time_type=2`) → 必须按主词「出勤」改走 `people-attendance` (`time_type=1`)。
+- ❌ 用户问「本月 calculation_tag=1.5x Daily Salary 的**出勤**汇总」 → 模型看到 `1.5x Daily Salary` 直接进入本 skill → 必须按主词「出勤」改走 `people-attendance`。
+- ❌ 用户问「SGP 本月 2x Daily Salary **出勤**汇总」 → 模型看到 `SGP` + `2x Daily Salary` 直接进入本 skill → 主词是「出勤」，地域只是修饰，必须改走 `people-attendance`。
+- ❌ 用户问「Time off in Lieu 标签的**出勤**记录」 → 必须按主词「出勤」改走 `people-attendance`。
+- ❌ 用户问「查询月初第一天**出勤**」 → 模型走入加班场景反问地域 → 主词是「出勤」，应直接走 `people-attendance` 不进入本 skill 的 Step -1 流程。
+
+只有通过 Step -2 主词识别后，才允许继续走 Step -1（地域确认）和 Step 0（日期解析）。
+
+## ⚠️ 全局硬性约束（开始任何调用前先读）
+
+0. **地域强约束（默认互斥，仅允许特定报错回退）**：
+   - `user_approval_over_time.list` / `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` **默认仅支持 CN 中国大陆员工**；非 CN（新加坡 SGP / 马来西亚 MY / 其他海外）员工调用可能返回空或报错。
+   - `submission.get` (`time_type=2`) / `submission.query_month_summary` **默认仅支持非 CN 员工**（如新加坡、马来西亚等海外地域）；CN 中国大陆员工调用可能返回空或语义不一致。
+   - **默认路由**仍然是：**CN ↔ user_approval_over_time / +overtime-apply-\*；非 CN ↔ submission**。
+   - **仅当接口返回特定地域报错文案时才允许自动回退**：
+     - `user_approval_over_time.list` 若报错文案包含 `method only support CHN country`，说明当前账号并非 CN，应立即切换到 `submission` 查询：月度汇总意图切 `submission.query_month_summary`，其余明细/范围意图切 `submission.get`（按日聚合）。
+     - `submission.get` / `submission.query_month_summary` 若报错文案包含 `method not support CHN country`，说明当前账号是 CN，应立即切换到 `user_approval_over_time.list` 查询。
+     - `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` 若报错文案包含 `method only support CHN country`，**不要再切换到其他写接口**，直接告诉用户：`暂时不支持非CN大陆提交加班，请前往审批系统提交。`
+   - **空结果不是回退信号**：只有命中上述精确报错文案才切换接口；空 `items` / 空 `rows` 一律按「无记录」处理，禁止因为空结果来回试探。
+1. **日期参数必须是字符串**：`check_date_from` / `check_date_to` / `submission.get` 的 `date` 虽然 schema 标的是 integer，但 CLI 把数字 JSON 序列化会变成 `2.026e+07` 科学计数法，**必须以 8 位 `"YYYYMMDD"` 字符串**传入，例如 `"check_date_from":"20260601"`。`month` 必须 6 位 `"YYYYMM"` 字符串。
+2. **`submission.get` 的 `time_type` 是必填整数枚举**：`1`=出勤提报、`2`=加班提报。本 skill 全部走 **`time_type=2`**；不要传 `"Overtime"` / `"PeriodTime"` / `0` / `3` 等任何非 `1|2` 值。
+3. **只查询当前登录账号本人的数据**：不接受 employee_id / employment_id / 工号 / open_id / union_id / 下属 / 部门 等任何身份维度过滤；用户提到他人一律拒绝并告知。
+4. **未来日期与非法日期一律拒绝**：解析后日期 > 当前日期、2 月 30 日、13 月等直接告知用户，不调用 CLI。
+5. **单次查询区间 ≤ 30 天**：超过需按自然月拆分逐次查询（API 错误码 `140001`）。
+6. **限流退避**：调用 `submission.*` / `user_approval_over_time.list` 时，若返回 `99991400`（rate limited），**等待 ≥ 2 秒**再重试；逐日 fan-out 查询时建议每次调用间隔 ≥ 300ms，单轮失败重试上限 3 次，仍失败直接告知用户而不是无限重试。
+7. **空结果用统一文案**：`items` / `rows` 为空时，必须回复 `{date} / {range} 无加班记录`，**禁止追加 `（duration=0, unit=hour）` 之类的零值结构化尾巴**，直接以「无加班记录」收尾即可，避免让用户误解为有 0 小时记录；同时不要让 LLM 误判为「参数没找对」继续盲试。
+8. **写操作仅限 CN 员工本人发起加班申请**：不支持代提、撤回、取消、修改、删除、导出。非 CN 员工的加班申请请前往审批系统提交，本 CLI 不支持。
+9. **`accept_language` 取值严格枚举（仅 `submission.get` / `submission.query_month_summary` 这 2 个接口支持）**：
+   - **支持 `accept_language` 的接口（仅这 2 个）**：`submission.get` (`time_type=2`) / `submission.query_month_summary`。
+   - **不支持 `accept_language` 的接口**：`user_approval_over_time.list` / `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` / `+overtime-apply-convert`。**禁止**给这些接口的 `--params` 加 `accept_language` 字段（多传会被忽略，但容易让 LLM 误以为可以拿到英文返回）。这些接口的返回字段是**中文为主**，英文用户问到这些接口的结果时由 LLM 翻译给用户，不要寄希望于参数控制语言。
+   - **服务端字面值严格**：`submission.*` 系列只识别 **`"zh-CN"`** 与 **`"en-US"`** 两个值（区分大小写、必须中划线、地区码必须为 `CN` / `US`）。**禁止**传 `en` / `en_US` / `en-us` / `en_us` / `english` / `EN-US` / `zh` / `zh_CN` / `cn` / `chinese` 等任何变体——服务端会**默默回退到中文**，让英文用户拿到中文 `display_name` / 中文 `status` / 中文 `calculation_tag`，看似查到了数据其实跑偏。
+   - **❗英文查询 + 海外场景的硬性约束（最高优先级，绝不可放宽）**：**只要满足以下两个条件，调用 `submission.get` (`time_type=2`) / `submission.query_month_summary` 时 `accept_language` 必须传 `"en-US"`，不允许省略、不允许默认、不允许任何变体**：
+     - **条件 1（英文查询）**：用户用英文提问 —— query 任意位置出现英文业务词（如 `overtime` / `OT` / `submit` / `apply` / `hours` / `last week` / `this month` / `Approved` / `Approving` / `Working Day Overtime` / `Time off in Lieu` / `Saturday OT` / `Sunday OT` / `Public Holiday OT` / `1.5x Daily Salary` / `2x Daily Salary` / `Recorded Overtime` 等），或整句为英文，或 query 含纯英文日期表达（`today` / `yesterday` / `last Monday` / `May 5` 等）。
+     - **条件 2（海外场景）**：地域已确认为非 CN（SGP / MY / 其他海外），即走 `submission.*` 接口路径。
+     - 即使 query 中夹杂少量中文（如「上周 overtime 的 1.5 倍时薪」），只要主词是英文 `overtime` / `OT`，必须按 `en-US` 传。
+     - 即使查询对象的实际记录在中文环境下显示为 `【SGP】1.5 倍时薪` 之类，英文上下文也必须传 `en-US` 让服务端返回 `1.5 Hourly` / `Approved` / `Time off in Lieu (Overtime)` 等英文字段，**禁止**依赖 LLM 自行做中英映射。
+     - **历史评测复现**：英文用户问 `"What were my overtime hours last week?"`，LLM 默认未传 `accept_language` 或传了 `en` → 服务端返回中文 `【SGP】调休假`，匹配过滤时还需 LLM 自行做中英映射，容易漏匹配/翻译错；**必须**传 `en-US` 直接拿到 `Time off in Lieu (Overtime)` 等英文标签。
+   - **混合判断口径（按优先级）**：① query 整句为英文 → `en-US`；② query 含中文主词（加班 / 加班审批 / 加班汇总等） → `zh-CN`；③ query 含英文主词（overtime / OT / submit overtime 等）但同时夹杂少量中文标签字面值 → 仍按 query 整体语种判定（主体英文用 `en-US`，主体中文用 `zh-CN`）；④ 无法判断时按 `zh-CN`。
+   - **判定原则**：用户用英文提问 / 系统语言为英文 / query 主词为英文 → 调用 `submission.*` 时 **必须**显式传 `accept_language="en-US"`；中文提问 → 显式传 `accept_language="zh-CN"`。两种场景都不允许省略，避免依赖默认值。
+   - **归一化映射（LLM 收到任意变体先做映射，再写入 `--params`）**：
+     | 输入变体 | 实际可传值 |
+     |---|---|
+     | `en` / `en_US` / `en-us` / `en_us` / `english` / `EN-US` / `EN` | `"en-US"` |
+     | `zh` / `zh_CN` / `zh-cn` / `cn` / `chinese` / `中文` / `ZH-CN` | `"zh-CN"` |
+   - **接口适用速查表**：
+     | 接口 | 是否支持 `accept_language` | 中文用户传 | 英文用户传 |
+     |---|---|---|---|
+     | `submission.get` (`time_type=2`) | ✅ | `"zh-CN"`（必填） | **`"en-US"`（强制必填，英文 query 不允许省略）** |
+     | `submission.query_month_summary` | ✅ | `"zh-CN"`（必填） | **`"en-US"`（强制必填，英文 query 不允许省略）** |
+     | `user_approval_over_time.list` | ❌ 不接受 | — | — |
+     | `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` / `+overtime-apply-convert` | ❌ 不接受 | — | — |
+
+### 地域识别信号（用于路由判定）
+
+> ⚠️ **极重要原则**：地域只能从用户**显式给出的地域词**判定，**绝不能**从「加班审批 / 审批状态 / 审批通过 / 已通过 / 已拒绝 / 已撤回 / 已撤销 / 发起加班 / 申请加班 / 调休 / paymod / 工作日加班 / 加班费」这类**加班业务术语**反推地域。这些词在 CN 大陆和海外（SGP / MY 等）的加班制度里都通用，**不与地域强关联**。同样，也禁止用以下信号反推地域：profile / 部门 / leader 中文名、问句是否中英文、env 名称、用户的语气习惯。
+>
+> ⚠️ **特别说明：calculation_tag 字符串不构成地域信号**。`Working Day Overtime` / `1.5x Daily Salary` / `2x Daily Salary` / `Time off in Lieu` / `Saturday OT` / `Sunday OT` / `1.5 Hourly` / `Overtime Pay` / `by_duration` / `by_time` 等都只是**加班计算标签的字面值**，CN 员工完全可能在 query 中引用这些英文标签询问「我的 Working Day Overtime 加了几小时」。**禁止**把这些字符串当成"海外专有术语"来反推地域，必须走 Step -1 强制前置确认。
+
+| 信号 | 判定地域 |
+|------|----------|
+| query 显式包含海外地域词：`海外` / `overseas` / `SGP` / `Singapore` / `新加坡` / `Asia/Singapore` / `MY` / `Malaysia` / `马来西亚` / `Asia/Kuala_Lumpur` / `【SGP】` / `【MY】` / 前提条件标注为 SGP / MY / 海外 | **非 CN（走 submission）** |
+| query 显式包含 CN 大陆地域词：`中国大陆` / `中国` / `大陆` / `mainland` / `China Mainland` / `CN` 员工 / `国内` / 前提条件标注为 CN | **CN（走 user_approval_over_time / +overtime-apply-\*）** |
+| query 仅有加班业务术语（如 `加班审批` / `审批状态` / `审批通过` / `已通过` / `已拒绝` / `已撤回` / `已撤销` / `发起加班` / `申请加班` / `调休` / `paymod` / `工作日加班` / `加班费`） | **❌ 不构成地域信号；进入 Step -1 强制前置确认** |
+| query 仅引用 calculation_tag 字面值（如 `Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` / `Overtime Pay` / `1.5x Daily Salary` 等） | **❌ 不构成地域信号；进入 Step -1 强制前置确认** |
+| query 仅有时间词或纯加班语义但无任何上述显式地域词 | **进入 Step -1 强制地域前置确认，禁止先猜接口** |
+
+### Step -1 地域前置确认（强制交互，所有读/写场景的最前置步骤）
+
+> **背景**：当前 CLI 没有任何接口可以直接查询当前登录员工的 `country_code`；以前版本会用 `user_approval_over_time.list` 的 `method only support CHN country` 报错来兜底判定地域，但这会引入 1 次浪费的失败调用 + 错误路由 + 用户体验差（多轮"我重新查"）。**新策略：地域识别信号缺失时必须先和用户做一次明确的二选一交互，且这次交互不可省略、不可由模型自行猜测。**
+
+#### 触发条件（满足任一即必须前置追问）
+
+1. query 中既不包含「非 CN 信号」也不包含「CN 信号」（参见上一节信号表）。
+2. query 仅有时间词（如 `本月加班多少`、`昨天加班了多久`、`帮我看下加班`、`check my overtime for May`、`我加了多少班`），无任何地域线索。
+3. query 是英文但既未提到 `Singapore` / `Malaysia` 也未提到 `China` / `mainland`（**英文不等于海外**，海外/CN 都可能用英文提问，必须追问）。
+4. query 仅引用 calculation_tag 字面值（如 `Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` / `1.5 Hourly` / `Overtime Pay`）但**没有附带显式地域词** —— 这些只是工时标签字面值，CN 与海外都可能引用，**禁止**据此判海外。
+5. 用户的 profile / 部门 / leader 名字看似中文，**也不能据此判定为 CN**（profile 仅是组织语言，不是工作地）。
+6. 同一个会话里**还没有过用户确认过的地域结论**（首次接入加班 skill 必须确认一次；用户已确认后可以在本会话内复用，不要重复打扰）。
+
+#### 交互话术（固定模板，禁止改写）
+
+```
+为了给您调用正确的加班接口，请先确认您的工作地：
+1) 中国大陆（CN）
+2) 海外（新加坡 SGP / 马来西亚 MY / 其他海外地域）
+
+请回复 1 或 2，或直接告诉我所在国家。
+```
+
+英文场景使用：
+
+```
+To route your overtime query to the correct API, please confirm your work location first:
+1) China Mainland (CN)
+2) Overseas (Singapore SGP / Malaysia MY / other overseas regions)
+
+Reply with 1 or 2, or tell me your country directly.
+```
+
+#### 处理用户回复
+
+| 用户回复 | 判定 |
+|----------|------|
+| `1` / `CN` / `中国` / `中国大陆` / `mainland` / `大陆` | **CN**，进入 `user_approval_over_time` / `+overtime-apply-*` 路径 |
+| `2` / `SGP` / `Singapore` / `新加坡` / `MY` / `Malaysia` / `马来西亚` / `海外` / `overseas` | **非 CN**，进入 `submission.*` 路径 |
+| 其他模糊回复（如 "都查一下" / "不知道"） | 再追问一次，明确"您每月工资由 CN 法人发还是 SGP/MY 法人发"，仍模糊则先按 CN 走，并提示"如查不到记录可能您属于海外，请回复 2 切换"|
+
+#### 地域确定后的报错回退仍然保留
+
+即使做了 Step -1，接口仍可能因为系统地域不一致返回 `method only support CHN country` / `method not support CHN country`。一旦命中这两个**精确**报错文案，按"全局硬性约束 0"自动切换到另一套接口（无需再次追问），并在最终输出里向用户说明"系统识别您的实际地域为 X，已自动切换到 X 接口"。空结果不触发切换。
+
+#### 何时**可以**跳过 Step -1（白名单）
+
+- query 已包含**地域识别信号表第 1~2 行**中的**显式地域词**（CN 大陆词 或 海外地域词，如 `海外` / `SGP` / `Singapore` / `中国大陆` / `mainland` 等）。
+- 用户在**当前会话**之前的轮次已经回答过工作地，且本轮没有冲突信号。
+- 用户原文显式给出指令，例如「我是 CN 员工」「我在新加坡」「I'm in mainland China」。
+
+> **不允许**用以下信号反推地域 —— 它们都不是工作地凭证：
+> - 加班业务术语：`加班审批` / `审批状态` / `审批通过` / `已通过` / `已拒绝` / `已撤回` / `已撤销` / `发起加班` / `申请加班` / `调休` / `paymod` / `工作日加班` / `加班费` 等（这些词在 CN 与海外加班制度里都通用）。
+> - **calculation_tag 字面值**：`Working Day Overtime` / `1.5x Daily Salary` / `2x Daily Salary` / `Time off in Lieu` / `Saturday OT` / `Sunday OT` / `1.5 Hourly` / `Overtime Pay` / `by_duration` / `by_time` 等（这些是工时计算标签，CN 员工也可能引用询问）。
+> - profile.my_department 中文名、leader 中文名、memory 提示词中的关键词、CLI env 名、问句中英文语种、用户的语气习惯。
+> - 同会话中用户附带在末尾的标签（例如「…… \n 海外」「…… \n CN」）属于**显式地域词**，必须按其指定地域路由，**不要**因为问句主体出现「加班审批 / 审批状态」就忽略尾部标签强行判为 CN。
+
+#### 反例（绝对禁止）
+
+- ❌ 用户问「上周五的加班审批状态是什么 \n 海外」，模型把「加班审批」当作 CN 信号，忽略尾部「海外」标签，错误调用 `user_approval_over_time.list` → 必须按尾部「海外」走 `submission`。
+- ❌ 用户问「今天的加班申请审批通过了吗 \n 海外」，模型把「审批通过」当作 CN 信号 → 必须按「海外」走 `submission.get` (`time_type=2`)。
+- ❌ 用户问「上周加班记录里 1.5 倍时薪标签的一共多少小时 \n 海外」，模型因为出现「加班记录 / 时薪标签」自行判断地域 → 必须按「海外」走 `submission.get` 逐日 fan-out。
+- ❌ 用户问「上周 Working Day Overtime 标签的加班总共几个小时」（无显式地域词），模型把 `Working Day Overtime` 当成"海外专有术语"直接判海外 → **必须**走 Step -1 强制追问；calculation_tag 字面值不构成地域信号。
+- ❌ 用户问「how many hours of 2x daily salary overtime do I have this month」（无显式地域词），模型把 `2x Daily Salary` 当成"海外术语"直接判海外 → **必须**走 Step -1；CN 员工也可能引用此标签询问。
+- ❌ 用户问「last week how many hours of overtime were tagged as Time off in Lieu」（无显式地域词），模型把 `Time off in Lieu` 当成"海外术语"直接判海外 → **必须**走 Step -1；该字符串只是 calculation_tag 字面值。
+- ❌ 用户问「我加班够不够抵扣迟到」（无显式地域），模型直接默认 CN 调用 `user_approval_over_time.list` → 必须先走 Step -1 追问。
+- ❌ 把「已通过 / 已拒绝 / 已撤回 / 调休」当成 CN 信号 → 这些都是中性业务术语，不构成地域信号。
+- ❌ 用户问「下周二我会加多少班」「明天会加多少班」「next Tuesday how much overtime」等**未来日期加班查询**意图，模型因为「未来日期 = 不可查」就**不进入本 skill**直接闲聊回复 → 必须进入本 skill，先走 Step -1 / Step 0，识别到未来日期后由 skill 统一回复「不支持查询未来日期的加班记录」并停止；不要绕开 skill 自由发挥。
+
+### 英文环境强化流程（必须按本节顺序执行）
+
+> **背景**：评测人工分析显示英文环境下高频翻车点 ——
+> 1. LLM 看到英文 query 直接默认海外，跳过 Step -1 地域确认，CN 员工被错误路由到 `submission`；
+> 2. LLM 把 `today` / `last week` / `last Friday` / `May 5` 等英文表达自己心算，跳过 `resolve_date.py`，结果星期、年份算错；
+> 3. `accept_language` 写成 `en` / `en_US` / `en-us`，服务端默默回退中文，用户看到中文字段以为查错了。
+>
+> **以下流程不可跳过、不可合并、不可由「我感觉用户是 SGP / CN」之类推断替代**。
+
+#### 流程顺序（严格按 Step 顺序执行）
+
+```
+英文 query（attendance / overtime / OT / submit overtime / how many hours…）
+    │
+    ▼
+[Step -2] 业务主词识别
+    ├─ 主词是 attendance / submit attendance / 出勤 → 切到 people-attendance skill
+    └─ 主词是 overtime / OT / submit overtime / overtime approval → 进入 Step -1
+    │
+    ▼
+[Step -1] 地域前置确认（强制，英文不等于海外！）
+    │   ★ 英文 query 默认必须执行此步，不允许跳过
+    │   ★ 仅当 query 显式包含 "Singapore / SGP / Asia/Singapore / Malaysia / MY /
+    │     Asia/Kuala_Lumpur / overseas / mainland China / China Mainland / CN" 等
+    │     **明确地域词**时才能跳过
+    │   ★ "I'm an employee" / "my team" / "this month" / "Working Day Overtime" /
+    │     "2x Daily Salary" 等词 ❌ 不构成地域信号，必须追问
+    │
+    ▼ (使用英文 fallback 模板)
+"To route your overtime query to the correct API, please confirm your work location first:
+ 1) China Mainland (CN)
+ 2) Overseas (Singapore SGP / Malaysia MY / other overseas regions)
+ Reply with 1 or 2, or tell me your country directly."
+    │
+    ├─ 用户回复 "1 / CN / mainland / China" → 走 user_approval_over_time / +overtime-apply-*
+    └─ 用户回复 "2 / SGP / Singapore / MY / Malaysia / overseas" → 走 submission.*
+    │
+    ▼
+[Step 0] 日期解析（强制走脚本，不要心算）
+    python3 <skill_path>/scripts/resolve_date.py --expr "<原英文表达>" --anchor "<YYYY-MM-DD>"
+    ├─ 脚本已支持的英文表达：today / yesterday / tomorrow / last week / this week /
+    │  next week / this month / last month / next month / this year / last year /
+    │  first half / second half / 3 days ago / two weeks ago / in 5 days /
+    │  last Friday / this Wednesday / next Monday / Monday / May / June /
+    │  May 5 / May 5th / May 5, 2026 / 5 May / Jan 31 / Dec 25 2025 等
+    ├─ 脚本 success=true → 拿 resolved_date / resolved_date_from~to
+    └─ 脚本 success=false → Level 2 推理 → Level 3 追问
+    │
+    ▼
+强制英文回显（不可省略）：
+    "Today is YYYY-MM-DD ({weekday}). The range you're asking about is
+     YYYY-MM-DD ({weekday}) ~ YYYY-MM-DD ({weekday}), {N} days in total. Proceed?"
+    │
+    ▼
+[Step 1] 调接口（参数严格）
+    ★ 非 CN → submission.get / submission.query_month_summary
+        ✅ 必传 accept_language="en-US"（英文上下文，不允许省略，不允许 en / en_US / en-us 变体）
+        ✅ 仅这 2 个接口支持 accept_language；写错变体 → 服务端默默回退中文
+    ★ CN → user_approval_over_time.list / +overtime-apply-*
+        ❌ 这些接口 **不支持 accept_language**，禁止在 --params 里加该字段
+        （返回字段以中文为主；英文用户的回报由 LLM 翻译给用户，不要寄希望于参数控制语言）
+```
+
+#### 英文 query 中的常见地域陷阱
+
+| 英文 query 片段 | 是否构成地域信号 | 处理 |
+|---|---|---|
+| `Singapore` / `SGP` / `Asia/Singapore` / `Malaysia` / `MY` / `Asia/Kuala_Lumpur` / `overseas` | ✅ 海外 | 直接走 `submission.*` |
+| `mainland China` / `China Mainland` / `mainland` / `CN employee` / `I'm in China` | ✅ CN | 直接走 `user_approval_over_time / +overtime-apply-*` |
+| `Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` / `Overtime Pay` / `1.5 Hourly` | ❌ 仅是 calculation_tag 字面值 | 强制 Step -1 追问 |
+| `OT approval` / `overtime status` / `submit overtime` / `apply overtime` | ❌ 业务术语 | 强制 Step -1 追问 |
+| `how many hours of overtime` / `my overtime this month` / `last week's overtime` | ❌ 通用语义 | 强制 Step -1 追问 |
+| `I worked 5 hours overtime` / `please apply 3h OT for me` | ❌ 写意图业务句 | 强制 Step -1 追问，写场景额外不允许跳过 |
+
+#### 英文 Few-shot
+
+```bash
+# 1) 用户："How many hours of overtime did I have last week?"
+#    → Step -2 主词命中 overtime → Step -1 没有地域信号，必须追问
+#    （假设用户回复 "2 / Singapore" → 非 CN）
+# → Step 0 解析 last week
+python3 <skill_path>/scripts/resolve_date.py --expr "last week" --anchor "2026-06-22"
+# → resolved_date_from=2026-06-15, resolved_date_to=2026-06-21
+
+# → Step 1 逐日调用，accept_language 必须是 "en-US"（不是 en / en_US / en-us）
+for d in 20260615 20260616 20260617 20260618 20260619 20260620 20260621; do
+  people-cli attendance submission get \
+    --params "{\"date\":\"$d\",\"time_type\":\"2\",\"accept_language\":\"en-US\"}" --as user
+  sleep 0.4
+done
+
+# 2) 用户："Check my overtime summary for May" + 上文已确认是 SGP
+python3 <skill_path>/scripts/resolve_date.py --expr "May" --anchor "2026-06-22"
+# → resolved_date_from=2026-05-01 ~ 2026-05-31 → month="202605"
+people-cli attendance submission query_month_summary \
+  --params '{"month":"202605","accept_language":"en-US"}' --as user
+
+# 3) 用户："Apply 3h overtime for tomorrow"
+#    → Step -1 写场景必须强制追问地域，不允许 LLM 推断；
+#    若用户回复 "2 / Singapore"，按"不支持非 CN 大陆提交加班，请前往审批系统提交"答复，禁止调用 +overtime-apply-*。
+#    若用户回复 "1 / CN"，进入 Step 0 解析 tomorrow → 未来日期允许写场景，但只支持当天/未来近期；按 +overtime-apply-render 走标准流程。
+
+# 4) ❌ 反例：accept_language="en"
+people-cli attendance submission get \
+  --params '{"date":"20260615","time_type":"2","accept_language":"en"}' --as user
+# 服务端会默默返回中文 status / calculation_tag，英文用户看到中文字段。
+
+# ✅ 必须改为：
+people-cli attendance submission get \
+  --params '{"date":"20260615","time_type":"2","accept_language":"en-US"}' --as user
+```
+
+#### 英文环境的固定回显话术
+
+单日：
+```
+Today is {YYYY-MM-DD} ({anchor_weekday}). The date you're asking about is {resolved_date} ({resolved_weekday}). Proceed.
+```
+
+范围：
+```
+Today is {YYYY-MM-DD} ({anchor_weekday}). The range you're asking about is {date_from} ({from_weekday}) ~ {date_to} ({to_weekday}), {N} days in total. Proceed.
+```
+
+歧义表达必须先确认再调接口：
+```
+Today is {YYYY-MM-DD}. I'm interpreting "{expr}" as {resolved_date} ({weekday}). Is that correct?
+```
+
+## 全局枚举速查（结果解读必备）
+
+### `status` 审批状态
+
+| 接口 | 数值 | 含义 |
+|------|------|------|
+| `user_approval_over_time.list` | 0 | 审批中（**该接口实际不支持查审批中**，传 0 也只会返回空） |
+| `user_approval_over_time.list` | 1 | 已拒绝 |
+| `user_approval_over_time.list` | 2 | 已通过 / 审批通过（默认） |
+| `user_approval_over_time.list` | 3 | 已撤回 |
+| `user_approval_over_time.list` | 4 | 已撤销 / 作废 |
+| `submission.get` `code=status` | — | 文本枚举：`已通过` / `审批中` / `已拒绝` / `更正审批中`（直接以文本透传） |
+
+### `unit` 时长单位（`user_approval_over_time.list`）
+
+| 数值 | 含义 |
+|------|------|
+| 1 | 天 |
+| 2 | 小时 |
+| 3 | 半天 |
+| 4 | 半小时 |
+
+> 输出给用户时**必须把 unit 数字翻译成中文**（如 `duration=8, unit=2` → `8 小时`）。不能用 `end_time - start_time` 自行换算 duration。
+
+### `calculation_tag`（仅 `submission.get` 返回）
+
+> ⚠️ `user_approval_over_time.list` **不返回 `calculation_tag`**。任何"按计算标签 / 加班费 / 调休假 / 1.5x / 2x / Working Day Overtime / Time off in Lieu / Overtime Pay 过滤"的查询，**只能走 `submission.get` (`time_type=2`)** 逐日抓取后再过滤。
+>
+> ⚠️ **calculation_tag 字面值不构成地域信号**：用户 query 引用 `Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` 等英文标签时，**不能**据此判定为海外员工，必须走 Step -1 前置确认；CN 员工也可能在 query 中引用这些标签字面值（哪怕 CN 制度下并不返回它们，也不能因此反推为海外）。
+
+常见取值：`Working Day Overtime`、`Normal Working Hours`、`Overtime Pay`（加班费）、`Time off in Lieu (Overtime)`（调休假）、`1.5 Hourly`、`1.5x Daily Salary`、`2x Daily Salary`、`【SGP】1 倍日薪`、`【SGP】调休假` 等；中英混杂，过滤时按子串匹配（如关键字 `Daily Salary`、`Time off in Lieu`）。
+
+### 相对时间窗口语义（必须按下表统一解析）
+
+| 用户表达 | 解析口径 |
+|----------|----------|
+| 今天 / today / today's | `Now` 日期 |
+| 昨天 / yesterday | `Now - 1 day` |
+| 前天 / day before yesterday | `Now - 2 day` |
+| 明天 / tomorrow（仅写场景；读场景拒绝） | `Now + 1 day` |
+| 本周 / this week | ISO 周一 ~ ISO 周日（包含双休） |
+| 上周 / last week | 上一个 ISO 周一 ~ 上一个 ISO 周日 |
+| 上周 X / last Friday / last Mon | 上一个 ISO 周内对应工作日，**不要落到本周** |
+| 本周 X / this Friday | 本 ISO 周对应工作日 |
+| 本月 / this month / MTD | 本月 1 日 ~ `Now`（"本月已加班"语义为月初到今天，不是整月） |
+| 上个月 / last month | 上月 1 日 ~ 上月最后一天 |
+| 上半年 / 下半年 | 1-6 月 / 7-12 月，需按自然月拆分逐月调用 |
+| 某月（如 `5月` / `May` / `Apr` / `Q2 2026`） | **`Now.year`**；若用户给的月份 > `Now.month`（跨年情形），回退为 `Now.year - 1` 同月；带年份的（`May 2025`）严格按用户给的年份 |
+| `MM/DD` / `M.D` 无年份 | 默认 `Now.year`；若该日期 > `Now`（暗示去年），回退为 `Now.year - 1` |
+| `周末` / weekend | 当前 ISO 周的周六~周日 |
+| `工作日` / weekdays | 当前 ISO 周的周一~周五，按日 fan-out |
+
+> **解析得到日期后必须先以 `YYYY-MM-DD` 文本回显给用户**（如「本周指 2026-06-08 ~ 2026-06-14」「May 解析为 2026-05-01 ~ 2026-05-31」），再继续调用接口。**一旦回显跟用户预期不符，必须立即用新表达重跑解析，不要硬调接口然后再纠偏。**
+
+### Step 0 日期解析（强制前置，所有读/写场景共享）
+
+> **背景**：人工原因分析显示日期推理是失败率最高的环节之一（如「上周三」误推成本周三、`May` 默认错年份、`yesterday` 跨日时区错算）。所有涉及日期/月份的查询/写入意图，必须在调用任何 CLI 之前完成 Step 0；这是 Step -1 之后的下一步。
+
+#### 三级瀑布流程（与"发起加班 Step 0"统一，读场景同样必须执行）
+
+```
+含日期表达的 query（包括"今天/昨天/上周/某月/某日"等任意时间词）
+    │
+    ▼
+Level 1: 调用 resolve_date.py 脚本（确定性计算）
+    ├─ success=true → 获得 resolved_date / resolved_date_from + resolved_date_to
+    └─ success=false → 进入 Level 2
+    │
+    ▼
+Level 2: Agent 基于 ISO 8601 + 英文月份/星期表 + UTC+8 当前日期推导
+    ├─ 有信心推出日期 → 获得推理日期
+    └─ 无信心 → 进入 Level 3
+    │
+    ▼
+Level 3: 主动追问用户「请给出具体日期/月份（如 2026-06-13 / 2026-06）」
+    │
+    ▼
+强制回显（不可省略）：
+    "今天是 YYYY-MM-DD（星期X）。您要查询的范围是 YYYY-MM-DD ~ YYYY-MM-DD（共 N 天），是否正确？"
+    │
+    ├─ 写场景（发起加班）→ 必须等待用户确认后再继续 render
+    ├─ 读场景（查询/汇总）→ 单一明确日期（如"今天"/"昨天"/"5月"等无歧义表达）可直接展示后调接口；歧义表达（如"周三"/"上次"/"那天"）必须等待用户确认
+    └─ 用户纠正 → 用新表达重新从 Level 1 开始
+```
+
+#### 脚本调用方式
+
+```bash
+python3 <skill_path>/scripts/resolve_date.py --expr "<用户日期表达>" --anchor "<当前日期YYYY-MM-DD>"
+```
+
+- `--expr`：用户原始日期表达，如 `下周六`、`6月13日`、`明天`、`yesterday`、`last Friday`、`May`、`5/13`、`MTD`
+- `--anchor`：当前真实日期，从 system prompt / chat_meta 的 `now_time` / `currentDate` 取 `YYYY-MM-DD`，**必须按 UTC+8 截断**；取不到时使用 UTC+8 当前日期
+- 多个日期表达可用空格或逗号分隔（如 `--expr "周一 周三 周五"`），脚本会返回 `type=multiple` 的多日期数组
+
+#### 脚本支持的表达类型（v1.6 扩展）
+
+| 类别 | 中文示例 | 英文示例 |
+|------|----------|----------|
+| 绝对日期 | `2026-06-13`、`6.13`、`6月13日`、`2026年6月13日` | `2026-06-13`、`Jun 13 2026`、`June 13`、`6/13`、`13 Jun`、`May 5, 2026`、`5th May 2026` |
+| 今/明/昨/后/前 | 今天、明天、昨天、后天、大后天、大前天 | today、tomorrow、yesterday、day before yesterday、day after tomorrow |
+| 周X / 本/上/下周X | 周六（默认本周六）、本周六、下周六、上周日、下下周六 | this Friday、last Mon、last Friday、next Saturday、Monday |
+| 周末（范围） | 本周末、下周末、上周末 | （脚本未直接覆盖 weekend，建议改用 `last weekend` 等需 Level 2/3） |
+| 月+日 | 下个月3号、本月15号、上个月20号 | May 5、May 5th、Jan 31、Dec 25 2025 |
+| N天/周后/前 | 三天后、两周后、5天前、上上周 | 3 days ago、two weeks ago、5 days later、in 5 days、from now、from today |
+| 月第N个周X | 本月第二个周五、下个月第一个周一 | （脚本未覆盖，需 Level 2/3） |
+| 单纯月份 | 5月、五月、本月、上月 | May、May 2026、last month、this month、next month、current month |
+| 范围（周/月/年） | 本周、上周、本月、上月、今年、去年、上半年、下半年 | this week、last week、next week、this year、last year、next year、first half、second half、H1、H2 |
+
+#### 脚本不支持的表达（交由 Level 2/3 处理）
+
+- 节假日名称：「端午节那天」「中秋节」「National Day」
+- 复合偏移：「明天第三个周五」「下个月最后一个工作日」「the second to last Friday」
+- 口语模糊表达：「最近的周六」「上次加班那天」「前阵子」
+
+> **强约束（最容易踩坑，评测命中率最低的几条）**：
+> 1. **多日期表达必须把整句一次性传给脚本**（如 `--expr "昨天和前天的加班时长各是多少"`、`--expr "yesterday and the day before yesterday"`、`--expr "上周三和上周五"`），脚本会自动从句子里识别多个相对短语并返回 `type=multiple`；**绝对不要先把多日期手动拆成两次调用**，更不要让 LLM 自己估算其中一个日期的星期。
+> 2. **星期信息必须直接复用脚本返回的 `resolved_weekday` / `resolved_date_to_weekday`**；禁止 LLM 自己根据日期口算星期再回显（评测里出现过 `2026-06-15` 被口算成「星期日」、`2026-06-12` 被口算成「星期四」的低级错误）。
+> 3. 脚本若返回 `matched_expression`，说明只识别到句中的一个相对短语，请把它当作单日期处理；如果用户原句本来包含多个时间点而脚本只识别到一个，必须再调用一次或把另一个表达单独传进来。
+> 4. **N 天前 / N 天后 必须以 `--anchor` 为基准做减法**（如 `4天前 + anchor=2026-06-16` → `2026-06-12 星期五`），禁止手动减完之后再「修正」星期。
+> 5. **脚本返回的 `anchor_weekday` 是真理**：回显「今天是 YYYY-MM-DD（星期X）」时星期 X **必须**用脚本返回的 `anchor_weekday`，不要自己根据日期数算。
+
+#### 读场景日期回显话术（固定模板）
+
+单日：
+```
+今天是 {YYYY-MM-DD}（{anchor_weekday}）。您要查询的日期是 {resolved_date}（{resolved_weekday}），下面去查询。
+```
+
+范围：
+```
+今天是 {YYYY-MM-DD}（{anchor_weekday}）。您要查询的范围是 {date_from}（{from_weekday}） ~ {date_to}（{to_weekday}），共 {N} 天，下面去查询。
+```
+
+模糊表达必须先确认再调接口：
+```
+今天是 {YYYY-MM-DD}。您说的"{expr}"我理解为 {resolved_date}（{weekday}），是否正确？
+```
+
+#### 反例（绝对禁止）
+
+- ❌ 用户说「上周三」，模型推成「本周三」就直接调接口
+- ❌ 用户说「May」时正值 6 月，模型默认推成 `2026-05`，但实际用户已是 `Now.year=2027` 的会话 → 必须以 `anchor` 为准，不要硬编码年份
+- ❌ 用户说「昨天」，但 `now_time` 是凌晨 0:30 (UTC+8)，模型按 UTC 推成前天 → 必须按 UTC+8 截断 anchor
+- ❌ 用户说「5/13」，模型直接当成 5 月 13 日去年的 → 必须按"`MM/DD` 默认本年；若 > Now 才回退去年"规则
+- ❌ 用户说「周三有没有加班」，模型默认本周三 → 「周三」属歧义表达，必须先确认是上周还是本周
+
+## 接口选择路由（重要）
+
+本 skill 涉及多类查询/写入接口，**地域是首要判定维度**：`user_approval_over_time` 与 `+overtime-apply-*` **默认适用于 CN 中国大陆员工**；`submission.*` **默认适用于非 CN 员工**（新加坡 SGP / 马来西亚 MY 等海外）。两类接口默认互斥；**但如果命中指定地域报错文案，必须按报错切换到另一套查询接口**。
+
+| 用户意图关键词 | 适用地域 | 推荐接口 | `accept_language` | 备注 |
+|----------------|----------|---------|-------------------|------|
+| 「本月/上月/某月加班一共多少小时」「月度加班汇总」 | **仅非 CN（SGP / MY 等海外）** | `submission.query_month_summary` | ✅ 必填，英文 `en-US` / 中文 `zh-CN` | 单月汇总；多月/半年逐月调用聚合；CN 员工不要调用 |
+| 「按加班日期查已通过/已拒绝/已撤回/已撤销的加班审批单」 | **仅 CN 中国大陆** | `user_approval_over_time.list` | ❌ 不支持，禁止传 | 历史审批语义，仅 2022-01-01 之后；按 `status` 过滤；**不支持查询审批中数据**；非 CN 用户不要走此接口 |
+| 「加班提报记录 / calculation_tag / display_name / 更正审批中 / 加班费 / 调休假 / 1.5x / 2x / Working Day Overtime / Time off in Lieu」 | **仅非 CN（SGP / MY 等海外）** | `submission.get` (`time_type=2`) | ✅ 必填，英文 `en-US` / 中文 `zh-CN` | 单日明细；多日范围必须逐日 fan-out 后聚合；CN 员工不要走此接口（也没有 `calculation_tag` 概念） |
+| 「提交/发起/申请加班」 | **仅 CN 中国大陆** | `+overtime-apply-render` → `+overtime-apply-create` | ❌ 不支持，禁止传 | 强制 Step 0 日期确认 + create 前二次确认；非 CN 用户告知不支持，引导去审批系统 |
+
+> [!IMPORTANT]
+> **决策树**（Step -2 → Step -1 → Step 0 → 路由 → 调接口）：
+> 1. **Step -2 业务主词识别**：先识别用户的业务主词。主词为「出勤」（即使 query 中含 calculation_tag 字面值如 `Overtime Pay` / `1.5x Daily Salary` / `2x Daily Salary` / `Working Day Overtime` / `Time off in Lieu`）→ **直接切到 `people-attendance` skill，不进入本 skill 的任何 Step**；只引用 calculation_tag 字面值且无业务主词时反问用户出勤还是加班，禁止默认走加班。仅当主词命中"加班"业务术语时才进入下面的 Step -1。
+> 2. **Step -1 地域前置确认**：按"地域识别信号"表先确定 CN / 非 CN（信号缺失或模糊时**必须**走 Step -1 强制追问，不要先猜接口；用户在本会话已确认过则跳过）。
+> 3. **Step 0 日期解析**：所有读/写场景调用 CLI 之前，先调用 `resolve_date.py` 把用户表达落到具体 `YYYY-MM-DD` 或 `YYYYMM`，再以固定模板回显，避免脏推理。歧义表达必须等待用户确认后再继续。
+> 4. **CN 中国大陆员工**：
+>    - 写（申请加班）→ `+overtime-apply-*`
+>    - 读（查加班审批单/历史记录/月度统计）→ `user_approval_over_time.list`（按日期范围 + status；月度统计也用此接口分日聚合或单次区间查询）
+>    - 若误走 `submission.*` 且返回 `method not support CHN country`，立刻切回 `user_approval_over_time.list`
+> 5. **非 CN 员工（SGP / MY / 其他海外）**：
+>    - 月度累计 → `submission.query_month_summary`
+>    - 单日明细 / 按 `calculation_tag` / `更正审批中` 过滤 → `submission.get` (`time_type=2`)
+>    - 若误走 `user_approval_over_time.list` 且返回 `method only support CHN country`，立刻切到 `submission` 对应查询；写操作若 `+overtime-apply-*` 返回同样报错，则直接告知暂不支持非 CN 大陆提交加班
+> 6. **只允许按指定报错文案回退**：第一个接口空结果就是「无记录」，不是「参数没找对」；不要因为空结果切换接口。
+> 7. **报错回退切换接口前**，必须在最终输出里显式告诉用户「系统识别您的实际地域为 X，已自动切换到 X 接口」，避免用户感知到隐式跳路。
+
+**判定优先级**：
+1. **显式地域词优先**：query 任意位置（包括末尾附带的标签如「\n 海外」「\n CN」）出现地域识别信号表第 1~2 行中的地域词，**必须**按该地域词路由，禁止因为问句主体出现「加班审批 / 审批状态 / 已通过 / 已拒绝」等加班业务术语而覆盖用户显式声明的地域。
+2. 若用户为 **非 CN（SGP / MY / 其他海外）员工**（query 出现海外地域词，或前提条件标注为 SGP/MY/海外，或本会话已确认为非 CN），加班数据查询直接走 `submission` 系列；提交加班 / 查 CN 审批单的请求要明确告知「当前 CLI 仅支持 CN 中国大陆员工的加班发起 / 审批单查询，非 CN 员工请使用 `submission.get` / `query_month_summary` 查询提报记录与月度汇总，发起加班请前往审批系统操作」。若地域判断不准、误调了 `user_approval_over_time.list`，且返回 `method only support CHN country`，则立即切到 `submission` 对应查询，不要继续重试原接口。
+3. 若用户为 **CN 中国大陆员工**（query 显式包含 CN 大陆地域词，或会话中已确认为 CN）：按"已通过/已拒绝/已撤回/已撤销"语义走 `user_approval_over_time.list`（**`user_approval_over_time` 暂不支持查询审批中数据**，用户问"审批中/待审批"的加班时直接告知「当前 `user_approval_over_time` 接口暂不支持查询审批中的数据」）；月度累计可以用 `user_approval_over_time.list` 按月查询后聚合 `duration`；发起申请走 `+overtime-apply-*`。若地域判断不准、误调了 `submission.*`，且返回 `method not support CHN country`，则立即切回 `user_approval_over_time.list`，不要继续重试原接口。
+4. 当用户问句出现 `calculation_tag` / `更正审批中` / `display_name` / `加班提报记录` 等 `submission` 专属字段，**或仅引用 `Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` / `Overtime Pay` 等 calculation_tag 字面值**：**禁止据此反推地域**，必须先走 Step -1 前置确认；只有在地域确认为非 CN 后才走 `submission`，若实际为 CN 员工，告知用户「这些字段属于海外（SGP / MY 等）员工的加班提报口径，CN 中国大陆员工只能查询加班审批单（`user_approval_over_time.list`）」。
+5. 一般加班业务术语（`加班审批 / 审批状态 / 审批通过 / 已通过 / 已拒绝 / 已撤回 / 已撤销 / 发起加班 / 调休 / paymod / 工作日加班 / 加班费`）**单独出现时不构成地域信号**；必须按 Step -1 走前置确认或读取会话中已确认的地域。
+6. **未来日期的加班查询意图必须进入本 skill**：用户问「下周二会加多少班」「明天加班几小时」「next Tuesday overtime」时，仍然属于本 skill 覆盖意图，应进入 Step -1 / Step 0 流程，由 skill 在 Step 0 识别到未来日期后统一回复「不支持查询未来日期的加班记录」并停止；**不要绕开 skill 直接闲聊作答**。
+
+## 核心场景
+
+### 1. 查询加班审批记录（仅 CN 中国大陆员工）
+
+**优先使用 [`user_approval_over_time`](references/people-attendance-overtime.md)**。
+
+**适用范围限定**：本接口**默认支持 CN 中国大陆员工**的加班审批单查询；**非 CN（新加坡 SGP / 马来西亚 MY / 其他海外）员工**的加班数据默认请改走 `submission.get` (`time_type=2`) / `submission.query_month_summary`。如果误调本接口且报错文案包含 `method only support CHN country`，必须立刻切到 `submission` 对应查询；如果只是空结果，则直接按「无加班记录」处理，不要切换接口。
+**只支持查询2022年1月1日之后的加班记录**。
+**目前仅支持按照加班日期查询，不支持按照发起时间、创建时间、更新时间等时间条件查询**
+**审批中/待审批通过的加班数据暂时不支持查询**
+
+场景示例：
+- "查一下我今天的加班记录" (传 `check_date_from=今天&check_date_to=今天&status=2`，日期格式要求为 `YYYYMMDD`）
+- "查一下我上半年有多少加班记录" (分批查1到6月的加班记录，每次传 `check_date_from=月开始时间&check_date_to=月结束时间&status=2`，日期格式要求为 `YYYYMMDD`）
+- "查一下我上周加班记录"（传 `check_date_from=上周开始时间&check_date_to=上周结束时间&status=2`，日期格式要求为 `YYYYMMDD`）
+- "查一下我昨天已经撤销的加班记录"（传 `check_date_from=昨天&check_date_to=昨天&status=4`，日期格式要求为 `YYYYMMDD`）
+- "查一下当前部门的加班记录"（不支持，直接返回提示「只支持查询当前登录账号本人的加班记录」）
+- "查一下其他人的加班记录"（不支持，直接返回提示「只支持查询当前登录账号本人的加班记录」，也不支持指定其他员工id查询）
+- "导出、删除、更新一下我的加班记录" (不支持，直接返回提示「不支持导出、删除、更新加班记录等操作」)
+- "我想取消上次的加班申请，帮我先查一下" (不支持，直接返回提示「不支持取消加班申请」，取消、撤回、修改等操作都不支持)
+- "我的加班够不够抵扣迟到" (不支持，直接返回提示「当前只支持查询加班数据，不支持其他联动能力」，当前只支持查询加班记录，不支持加班联动内容，比如加班补贴怎么算、哪一天允许加班)
+- "我是部门经理，帮我查一下我下属本月的加班汇总" (如果用户意图里面有指明查询非本人的加班记录，直接返回提示「只支持查询当前登录账号本人的加班记录」)
+- "给我查询一下2月29号或者-2026年3月的加班记录" (首先校验下用户意图里面的日期是否合法，如果非法直接返回提示「只支持查询合法日期的加班记录」)
+- "查一下我所有加班记录" (用户不指定查询特定审批状态的记录，强制查询审批通过的加班记录，传 `status=2`)
+- "下周二/明天我会加多少班"（未来日期，不调用 CLI，直接告知「不支持查询未来日期的加班记录」）
+
+
+
+## 参数填充规则
+
+查询加班记录必须使用 `list --params` 传 JSON，不存在 `--check-date-from` / `--status` 这类独立 flag。**`YYYYMMDD` 日期必须作为字符串传入**，否则会被 JSON 序列化为 `2.026e+07` 触发 `99992402 field is invalid` 错误。
+
+| 参数 | Required | 类型 | Default | Description |
+|------|---------|------|---------|-------------|
+| `check_date_from` | ✅ | string `YYYYMMDD` | — | 开始日期；用户给出"2026-04-01 / 4月1日 / 本周"时必须先按"相对时间窗口语义"表换算为 `YYYYMMDD` 字符串 |
+| `check_date_to` | ✅ | string `YYYYMMDD` | — | 结束日期；`check_date_to ≥ check_date_from` 且区间 ≤ 30 天，否则按自然月拆分逐次查询 |
+| `status` | ✅ | integer | — | 审批状态，只支持单一值；用户未指明时**强制 `2`**（已通过）。取值见上方 status 表 |
+
+### Few-shot 示例
+
+```bash
+# ✅ 正确：日期作为字符串
+people-cli attendance user_approval_over_time list --params '{"check_date_from":"20260523","check_date_to":"20260523","status":2}'
+
+# ❌ 错误：传 JSON 数字会变成科学计数法
+people-cli attendance user_approval_over_time list --params '{"check_date_from":20260523,"check_date_to":20260523,"status":2}'
+# → API error 99992402: field "check_date_from" value "2.0260523e+07" is invalid
+
+# 跨月查询（4 月 + 5 月）：按自然月拆成 2 次调用
+people-cli attendance user_approval_over_time list --params '{"check_date_from":"20260401","check_date_to":"20260430","status":2}'
+people-cli attendance user_approval_over_time list --params '{"check_date_from":"20260501","check_date_to":"20260531","status":2}'
+```
+
+## 加班记录结果返回字段说明
+
+| 字段 | 描述 |
+|------|------|
+| `duration` | 加班时长数值，必须结合 `unit` 解读（如 `duration=8, unit=2` → `8 小时`）；**禁止用 `end_time - start_time` 重新计算 `duration`** |
+| `unit` | 时长单位枚举：`1`=天、`2`=小时、`3`=半天、`4`=半小时（输出时翻译成中文） |
+| `start_time` | 加班开始时间 (`YYYY-MM-DD HH:MM:SS`) |
+| `end_time` | 加班结束时间（跨日时为次日时间） |
+| `status` | 审批状态枚举（见上方 status 表） |
+| `reason` | 加班原因 |
+| `approval_id` | 审批实例 ID |
+
+### 标准输出模板（务必使用）
+
+**有记录时**（结构化字段必须齐全）：
+
+```
+查询范围：{check_date_from} ~ {check_date_to}（共 N 条）
+- 2026-06-09 (周二)：duration=3, unit=小时, status=已通过, reason=项目上线
+- 2026-06-10 (周三)：duration=2, unit=小时, status=已通过, reason=线上故障
+合计：5 小时
+```
+
+**无记录时**（不要让模型继续盲试其他 `status` / `check_date_type`；**不要追加 `（duration=0, unit=hour）` 之类的零值结构化尾巴**）：
+
+```
+{date 或 range} 无加班记录
+```
+
+**月度汇总场景** 即使本接口结果为空，也按上述空记录模板回复；若用户明确问"本月加班几小时"，建议优先调用 `submission.query_month_summary` 而不是逐日累加。
+
+
+### 2. 发起加班申请（仅 CN 中国大陆员工）
+
+**绝对优先使用 [`overtime-apply`](references/people-attendance-overtime-apply.md)**。
+
+> 🚨 **写场景特别强约束（高于读场景）：地域前置确认是发起加班的第 0 步，且不可被任何信号豁免。**
+>
+> - **不允许跳过 Step -1 地域确认**：即使 query 中含有「加班」「申请加班」「发起加班」「调休」「paymod」「工作日加班」「加班费」「加班审批」等加班业务术语，写场景下这些都**不算**有效的地域信号（这些词在 CN 与海外加班制度里都通用，不与地域强关联）；**必须**先按 Step -1 固定模板向用户做一次「中国大陆 / 海外」二选一确认；不允许由 LLM 直接根据加班业务术语、profile、env 名称、UAT 内容、之前读场景的地域结论、或"用户既然让我提交那肯定是 CN" 之类的推断替代这次显式确认。
+> - **写场景的 Step -1 白名单仅有两类**：
+>   1. 用户在**当前会话**中已用 Step -1 固定模板回答过工作地（例如已回复"1"或"中国大陆"），且本轮无冲突信号；
+>   2. 用户在写意图同一句中**显式声明工作地**（例如「我是 CN 员工，帮我提交今天 3 小时加班」「I'm in mainland China, apply 3h OT today」），或同一句中包含地域识别信号表第 1~3 行的显式地域词 / 海外专有英文术语。
+> - **以上两类之外**，无论 query 是中文还是英文、是否带「加班」字样、是否同会话已做过读查询，都**必须**重新执行 Step -1，且必须等用户明确回复后才能进入 Step 0（日期确认）和 render。
+> - **首次写意图必须展示固定模板**：不要把地域追问改写成「您是不是 CN 员工？」之类的简化问法；必须使用 SKILL.md 顶部 Step -1 中给出的中文 / 英文固定话术全文，列出「1) 中国大陆（CN）/ 2) 海外」选项。
+> - **未确认地域前禁止调用任何 CLI**：包括 `+overtime-apply-render`、`+overtime-apply-options`、`+overtime-apply-create`、`resolve_date.py` 之外的任何申请相关命令。`resolve_date.py` 可以在地域确认前后任意时机调用（纯日期解析），但解析后的日期回显必须晚于地域确认。
+> - **本会话已确认为非 CN 时**：直接告知「暂时不支持非 CN 大陆提交加班，请前往审批系统提交」，并**禁止**为了"试一下"而调用 render/options/create；命中接口报错 `method only support CHN country` 也不再回退或重试。
+> - **违反上述写场景强约束（如未做地域确认就直接调用 render）属于流程错误，必须立即停止，向用户致歉并补做 Step -1**。
+
+**适用范围限定**：`+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create` 的表单结构、calculation 字段、审批流均按 **CN 中国大陆加班制度**设计，**仅支持 CN 中国大陆员工本人发起加班申请**。
+
+**非 CN（新加坡 SGP / 马来西亚 MY / 其他海外）员工**的加班发起意图（如 `apply overtime for today, 3 hours Working Day Overtime`、`submit 加班费 for today`、`帮我申请上周日的加班`、`overtime from 10pm yesterday to 1am today`、`apply 20 hours overtime`、`I worked 5 hours overtime last Sunday`、Asia/Singapore / Asia/Kuala_Lumpur / Saturday OT / Sunday OT 等场景）一律**不要调用 `+overtime-apply-*`**；直接告知用户「当前 CLI 仅支持 CN 中国大陆员工本人通过命令发起加班申请，非 CN（SGP / MY 等海外）员工请前往加班审批系统提交申请，不可猜测构造 form_info。」
+
+如果地域判断不准而实际调用了 `+overtime-apply-render` / `+overtime-apply-options` / `+overtime-apply-create`，且返回报错文案包含 `method only support CHN country`，则**不要尝试回退到任何 submission 写接口，也不要继续 render/options/create**，直接告诉用户：`暂时不支持非CN大陆提交加班，请前往审批系统提交。`
+
+执行发起加班时默认 `people-cli` 已安装可用；不要先执行安装、升级、npm 全局安装、修改 PATH、`build.sh` 等环境准备动作。如命令不可用，只提示用户先完成本地安装配置。
+
+加班申请是**循环渲染**流程，不能一次性直接提交。以 `+overtime-apply-render` 最新返回的 `fields`、`next_action`、`missing_fields`、`validate_results`、`enum_query_paths`、`submit_form_info`、`ready_to_create` 为准；每轮缺失项必须一次性收集齐再重新 render。禁止用“无”“默认”“其他”等占位值补字段。调用 `+overtime-apply-create` 前必须基于最终 `submit_form_info` / `display_summary.text` 回显所有申请数据，并获得用户明确二次确认；不能因 `ready_to_create=true` 自动提交，也不能用日期校准确认、enum 选择确认或前序 render 确认代替 create 前二次确认。
+
+当前发起加班只支持**日期 + 时长**模式，不支持**开始时间 - 结束时间**的加班时段模式。不要询问或构造开始时间、结束时间，不要在 `form_info` 中写入 `work_apply_overtime.work_overtimes`、`start_time`、`end_time`；用户只给出时段时，应转换为加班日期和加班时长让用户确认，无法明确换算时直接追问时长。
+
+如果 `+overtime-apply-render` 返回的 `fields` / `missing_fields` / `submit_form_info` 中出现 `work_apply_overtime.daily_overtime_details`，且其子字段包含 `overtime_date` 和 `overtime_duration`，就必须判定为**日期 + 时长模式**。此时只能问用户「加班日期是哪天、加班时长是多少小时」，绝对不能问「几点到几点」「开始时间/结束时间」「具体时间段」。
+
+**日期确认是加班申请的强制前置步骤（Step 0），不可跳过、不可合并到 render 流程中。** 无论用户给出的是绝对日期还是相对日期，都必须先完成日期确认才能进入 render。具体流程见下方”强制前置：日期确认”章节。
+
+场景示例：
+- "帮我申请今天加班 3 小时，原因是项目上线，备注上线值守"
+- "我明天要加班 8 小时，帮我提交申请"
+- "今天晚上 7 点到 10 点加班"（不使用时段提交；先换算并向用户确认「今天加班 3 小时」后再继续）
+- "加班原因有哪些"（只查询 options，不提交）
+- "补偿方式有哪些"（先 render 获取字段结构，再对对应 enum 字段调用 options）
+- "帮我直接提交加班申请"（禁止直接提交；必须先展示申请摘要并获得二次确认）
+- "帮张三申请加班"（不支持，直接提示「当前只支持给本人发起加班申请」；不要在 `form_info` 中填充 `applicants`）
+- "帮工号 E12345 申请加班"（不支持，直接提示「当前只支持给本人发起加班申请，不支持通过工号、用户 ID 等信息代提他人加班」；不要调用 render/options/create）
+- "我是主管，帮下属提交加班"（不支持，直接提示「当前只支持给本人发起加班申请，不支持代提他人加班」）
+- "帮我申请本周一到周日每天都加班"（不支持，直接提示「当前一次申请最多支持 2 段加班，请减少到 2 段以内后再提交」）
+- "今天加班0小时"（不调用命令，直接提示「加班时长不能为0，请填写有效的加班时长」）
+- "今天加班-3小时"（不调用命令，直接提示「加班时长不能为负数，请填写有效的加班时长」；不要改成3小时）
+- "撤回/取消/修改加班申请"（不支持，直接提示「当前只支持发起加班申请，不支持撤回、取消或修改」）
+
+### 强制前置：日期确认（Step 0，不可跳过）
+
+发起加班申请时，用户输入中涉及的所有日期/日期表达必须经过以下流程确认后才能写入 form_info。此步骤在 render 之前执行，不可跳过、不可与 render 合并。
+
+#### 为什么不能跳过
+日期推理是加班申请中出错率最高的环节。LLM 对”下周六””下个月3号”等表达极易产生幻觉。即使是绝对日期（如 `6.13`），也可能因为年份推断出错。因此所有日期必须经过确定性脚本计算并向用户展示确认。
+
+#### 三级瀑布流程
+
+```
+用户输入含日期表达
+    │
+    ▼
+Level 1: 调用 resolve_date.py 脚本（确定性计算）
+    ├─ success=true → 获得 resolved_date
+    └─ success=false → 进入 Level 2
+    │
+    ▼
+Level 2: Agent 基于 ISO 8601 规则语义推导
+    ├─ 有信心推出日期 → 获得推理日期
+    └─ 无信心 → 进入 Level 3
+    │
+    ▼
+Level 3: 主动追问用户”请给出具体日期（如 2026-06-13）”
+    │
+    ▼
+强制输出确认（不可省略，无论哪个 Level 获得日期）：
+    “今天是 M月D日 星期X，您要申请的加班日期是 YYYY-MM-DD（星期X），是否正确？”
+    │
+    ├─ 用户确认 → 进入 render 流程
+    └─ 用户纠正 → 用新表达重新从 Level 1 开始
+```
+
+#### 脚本调用方式
+
+```bash
+python3 <skill_path>/scripts/resolve_date.py --expr “<用户日期表达>” --anchor “<当前日期YYYY-MM-DD>”
+```
+
+- `--expr`：用户原始日期表达，如 `下周六`、`6月13日`、`明天`
+- `--anchor`：当前真实日期，从 system prompt 的 `now_time` / `currentDate` 中取 `YYYY-MM-DD` 部分；取不到时使用 UTC+8 当前日期
+
+脚本返回 JSON：
+- `success=true` 时包含 `resolved_date`（单日期）或 `resolved_date_from` + `resolved_date_to`（范围）
+- `success=false` 时包含 `reason`，此时由 Agent 在 Level 2 处理
+
+#### 多段加班的日期确认
+
+用户申请多段加班（最多2段）时，每段日期分别调用脚本解析，然后一次性向用户展示所有日期让其确认：
+
+> 今天是 5月29日 星期五：
+> - 第1段加班日期：2026-06-06（星期六）
+> - 第2段加班日期：2026-06-07（星期日）
+>
+> 以上日期是否正确？
+
+#### 脚本支持的表达类型
+
+| 类别 | 示例 |
+|------|------|
+| 绝对日期 | `2026-06-13`、`6.13`、`6月13日`、`2026年6月13日` |
+| 今/明/昨/后/前 | 今天、明天、昨天、后天、大后天 |
+| 周X / 本/上/下周X | 周六（默认本周六）、周日（默认本周日）、本周六、下周六、上周日、下下周六 |
+| 周末（范围） | 本周末、下周末、上周末 |
+| 月+日 | 下个月3号、本月15号、上个月20号 |
+| N天/周后/前 | 三天后、两周后、5天前 |
+| 月第N个周X | 本月第二个周五、下个月第一个周一 |
+| 年/半年 | 今年、明年、上半年、下半年 |
+
+#### 脚本不支持的表达（交由 Level 2/3 处理）
+
+- 节假日名称：”端午节那天””中秋节”
+- 复合偏移：”明天第三个周五””下个月最后一个工作日”
+- 口语模糊表达：”最近的周六””这个礼拜六”（注：”这周六”可以识别）
+
+#### 确认话术模板
+
+```
+今天是 {M}月{D}日 星期{W}，您要申请的加班日期是 {resolved_date}（{resolved_weekday}），是否正确？
+```
+
+用户确认后，将确认的日期以 `YYYY-MM-DD` 格式写入后续流程。
+
+---
+
+快捷发起加班（用户提供完整信息）：
+1. **执行日期确认（Step 0）**：从用户输入中提取日期表达 → 调用 `resolve_date.py` → 向用户展示确认 → 用户确认后继续。
+2. 调用 `people-cli attendance +overtime-apply-render --form-info ''` 获取真实字段结构。
+3. 按 `fields` 构造 `form_info`：只写入用户明确提供或已选择的业务字段；`required=true` 必填，`writable=true` 可改，`writable=false` 不构造；任何申请人、工号、用户 ID 等身份字段都不构造；只构造日期 + 时长相关字段，禁止构造 `work_overtimes`、`start_time`、`end_time`；非法时长先拦截，不调用 render。
+4. 首次 render 后，如果 `missing_fields` 同时包含非 enum 和 enum 字段，必须先一次性追问并收集所有非 enum 字段；当字段路径是 `daily_overtime_details[*].overtime_date` / `daily_overtime_details[*].overtime_duration` 时，只能追问加班日期和加班时长，不能追问加班时段；不要在非 enum 字段缺失时查询 enum options，**也不要在只收集了部分信息时就调用 render**。
+5. 非 enum 字段写入 `form_info` 后，再查询 enum；如果没有任何非 enum 字段可收集或依赖，允许用空 `form_info` 查询 enum。enum 字段之间是平等关系，不要求固定查询顺序，可并行调用 options；若某个 enum 已经确定，把它也拼进 `form_info` 作为查询其他 enum 的已知上下文。
+6. **收集完所有缺失字段（包括所有非 enum 和 enum 字段）后**，才调用 `people-cli attendance +overtime-apply-render --form-info '<form_info_json>'` 校验；优先内联传 JSON，不写 `form_info.json`；不要每补一项就 render。
+7. 每轮 render 后优先使用返回的 `display_summary.text` 展示全量字段；用户修改后更新 `form_info` 并重新 render。
+8. `ready_to_create=true` 后，使用 `submit_form_info` 作为最终提交参数；仅离线处理历史 render 响应时才用 `+overtime-apply-convert`。
+9. 调用 create 前按固定模板进行**独立二次确认**：必须回显最终 `submit_form_info` / `display_summary.text` 中的所有字段（包括服务端默认值、多段明细、不可修改字段和唯一选项 enum），且确认必须发生在 `+overtime-apply-create` 前一刻；前面的日期校准、enum 选择或 render 确认都不算。
+10. 用户明确确认后，直接把 `submit_form_info` 序列化为 JSON 字符串并调用 `people-cli attendance +overtime-apply-create --form-info '<submit_form_info_json>' --time-zone "Asia/Shanghai" --yes`，不要写 `final_form.json`。
+11. 发起过程中命令报错时：仅对非业务校验类的临时命令/API 错误重试；输入参数不变时原命令最多原样重试 1 次；大模型基于已知信息自动修改参数后重试最多 3 次。用户补充或修改了信息属于新的输入轮次，不计入这 3 次自动改参重试。仍失败时停止重试，直接把错误原因和建议告知用户。
+
+快捷查询选项：
+1. 先调用 `people-cli attendance +overtime-apply-render --form-info ''` 获取表单结构。
+2. 再调用 `people-cli attendance +overtime-apply-options --form-info '' --query-path "<enum_path>"` 查询选项，例如 `work_apply_overtime.daily_overtime_details[0].paymod`。
+3. 展示返回的 `name`，用户选择后将对应 `key` 写入 `form_info`；若只返回一个选项，默认自动填充该选项并标记不可修改。多个 enum 是平等关系，可并行查询；如果查询时已有其他 enum 的确定值，就把这些已知 enum 一并放入 `form_info`。没有非 enum 上下文时允许空 `form_info` 查询 enum。
+
+关键规则：
+1. 时间：**所有日期必须经过"强制前置：日期确认（Step 0）"流程**。先调用 `scripts/resolve_date.py` 做确定性计算，脚本失败时由 Agent 基于 ISO 8601 推理，仍无法确定则追问用户。无论哪种方式获得日期，都必须向用户展示确认后才能写入 form_info。时间部分（时分秒）按 `YYYY-MM-DD HH:MM:SS` 格式处理，日期部分由 Step 0 确认提供。
+2. 结构：按 render 返回的 `type` 构造参数；`record` 填对象，`list<record>` 填对象数组；缺少明确值不构造 key。发起加班只支持日期 + 时长明细，优先使用 `daily_overtime_details` 等 render 返回的日期/时长字段；只要 render 出现 `daily_overtime_details.overtime_date/overtime_duration`，就只能收集日期和时长，禁止询问或使用 `work_overtimes`、`start_time`、`end_time` 这类时段字段。
+3. enum：`writable=true` 的 enum 可修改，但只能从 options 返回的选项中取值；不在选项集内必须拒绝。enum options 查询依赖当前 `form_info`，因此必须先收集非 enum 字段；如果没有非 enum 字段，允许空 `form_info` 查询。enum 字段之间不要求顺序，可以并行查询；若某个 enum 已知，查询其他 enum 时应把该已知值带入 `form_info`。
+4. 全量确认：每轮 render 后展示 `submit_form_info` 所有字段；`writable=true` 标记可修改，`writable=false` 或 options 只有一个选项的 enum 标记不可修改。调用 `+overtime-apply-create` 前还必须再做一次独立二次确认，完整回显最终提交数据；没有这次确认不得 create。
+5. 固定文案：确认态和成功态优先复用 `display_summary.text`，必须使用固定标签「加班类型 / 加班日期 / 加班时长 / 加班原因 / 计算方式 / 请确认以上信息」，不要改写成「补偿方式」「调休」等非标准口径。
+6. 业务红线：`validate_results`、`create_invalid_msg`、制度提示中出现超限、当天不可申请、每周至少 1 个完整休息日等信息时，先视为阻断并给出可执行建议（如“调整为 3 小时”“只选择一天”），不要仅因 `ready_to_create=true` 自动提交；如果 create 返回操作频繁，提示用户“操作频繁，请5秒后重试。”。
+7. 边界：一次申请最多包含 2 段加班；2 段以内必须放在同一次 `form_info` 里一起提交，不要拆成多个独立申请；超过 2 段直接拒绝并让用户减少到 2 段以内。只支持给当前登录用户本人发起，不询问申请人，不构造 `applicants`、`employee_id`、`employee_no`、`employment_id`、`user_id`、`open_id`、`union_id` 等身份字段；取消/撤回/修改需引导用户去审批系统撤回。
+8. 重试：仅对非业务校验类的临时命令/API 错误重试。命令执行报错但参数未变化时，只允许原样重试 1 次；大模型仅基于已有上下文和错误信息自动修改参数后再 render/create 时，自动改参重试累计最多 3 次。用户补充或修改信息后再次执行属于新的输入轮次，不计入自动改参重试次数。所有不支持的操作、确定性业务拦截和鉴权类错误都不重试，直接告知用户不支持或给出修正建议。超过上限仍失败必须停止，向用户说明未提交成功和最后一次错误信息。
+9. 发起申请返回结果中的 `record_id` 是创建生成的加班记录的唯一ID，并非审批流程的ID，也非申请单号。
+
+### 3. 查加班提报记录（仅非 CN 员工，SGP / MY / 其他海外）
+
+**绝对优先使用 [`submission`](references/people-attendance-submission.md)**（`time_type=2`）。
+
+**适用范围限定**：本接口**默认支持非 CN 员工**（新加坡 SGP / 马来西亚 MY / 其他海外）的加班提报记录查询；**CN 中国大陆员工默认应走 `user_approval_over_time.list`**。如果误调本接口且报错文案包含 `method not support CHN country`，必须立刻切回 `user_approval_over_time.list`；如果只是空 `data.rows`，则直接按「该日无加班提报」处理，不要切换接口。
+
+接口仅支持**单日**查询；"本周/上周/本月/上月/最近两周"等范围意图，必须先把范围解析为日期列表，逐日 `submission.get` 后在内存中聚合。
+
+#### 调用约束
+
+- **`time_type` 是必填整数**：本 skill 全部固定 `"time_type":"2"`（CLI 接受字符串/整数皆可，但**只接受 `1` 或 `2`**）。任何 `Overtime` / `PeriodTime` / `0` / `3` 等取值都会触发 `99992402` 错误，不要尝试。
+- **`date` 是 `YYYYMMDD` 字符串**（同 `user_approval_over_time` 的处理方式，不要传 JSON 数字）。
+- **逐日 fan-out**：上周 7 天 → 7 次调用；每次间隔 ≥ 300ms 防限流；命中 `99991400` 立即 sleep 2s 后单次重试，仍失败告知用户「服务限流，请稍后再试」并停止。
+- **空 `data.rows` ≠ 没找对参数**：直接判定为「该日无加班提报」，不要再换 `time_type` / 加 `accept_language` 之类盲试。
+
+#### Few-shot
+
+```bash
+# ✅ 单日加班提报（time_type=2）—— 中文用户
+people-cli attendance submission get --params '{"date":"20260609","time_type":"2","accept_language":"zh-CN"}' --as user
+
+# ✅ 单日加班提报（time_type=2）—— 英文用户：accept_language 必须是 "en-US"（不是 en / en_US / en-us / en_us）
+people-cli attendance submission get --params '{"date":"20260609","time_type":"2","accept_language":"en-US"}' --as user
+
+# ✅ 本周（2026-06-08 ~ 2026-06-14）逐日 fan-out（中文环境）
+for d in 20260608 20260609 20260610 20260611 20260612 20260613 20260614; do
+  people-cli attendance submission get --params "{\"date\":\"$d\",\"time_type\":\"2\",\"accept_language\":\"zh-CN\"}" --as user
+  sleep 0.3
+done
+
+# ✅ 本周逐日 fan-out（英文环境）—— accept_language 必须 en-US
+for d in 20260608 20260609 20260610 20260611 20260612 20260613 20260614; do
+  people-cli attendance submission get --params "{\"date\":\"$d\",\"time_type\":\"2\",\"accept_language\":\"en-US\"}" --as user
+  sleep 0.3
+done
+```
+
+#### 结果解析（`data.rows[].code` → 含义）
+
+| `code` | 含义 |
+|--------|------|
+| `overtime_date` | 加班日期 |
+| `display_name` | 展示名称（如「出勤」） |
+| `status` | 审批状态文本（`已通过` / `审批中` / `已拒绝` / `更正审批中`） |
+| `calculation_tag` | 计算标签 / 工时口径（见上方 calculation_tag 列表） |
+| `duration` | 时长**字符串**，按 `parseFloat` 累加；最终输出按小时 |
+| `unit` | 时长单位文本（如「小时」） |
+| `start_time` / `end_time` | 加班起止时间 |
+| `reason` | 加班原因（部分场景才返回） |
+
+#### 场景示例
+
+- "今天/昨天/前天/4 天前/上周三/last Friday 加班了多久" → 单日 `submission.get`
+- "5 月 28 号那天加班了多少" → 单日 `submission.get`
+- "这周到现在加了多少班" / "上周总共加了几个小时的班" → 解析日期范围 → 逐日 `submission.get` → 求和 `duration`
+- "上周哪几天加班超过 2/3 小时" → 逐日 `submission.get`，按 `parseFloat(duration) > 阈值` 过滤
+- "上周 calculation_tag 包含 Working Day Overtime / Time off in Lieu / 1.5x Daily Salary / 2x Daily Salary / Overtime Pay 的加班" → 逐日 `submission.get`，按 `calculation_tag` 子串匹配过滤 / 汇总
+- "上周/本月已通过 / 审批中 / 已拒绝 / 更正审批中的加班" → 逐日 `submission.get`，按 `status` 过滤 / 计数 / 汇总
+- "上周加班 > 2h 且 status=已通过" / "本月已通过按 calculation_tag 分组汇总" → 多条件 AND 过滤 + 分组汇总
+- "上周和上上周哪周加班更多" → 两周分别逐日聚合后比较
+- "今天的加班审批通过了吗 / has my overtime for last Saturday been approved?" → 单日 `submission.get` 后判断 `status`
+- "下周二我会加多少班 / 明天加班" → 未来日期，**直接拒绝**，不调用 CLI
+- "查张三 / 工号 E12345 / 我下属的加班" → 不支持，告知「只支持查询当前登录账号本人的加班提报记录」
+
+### 4. 加班月度汇总（仅非 CN 员工，SGP / MY / 其他海外）
+
+**优先使用 [`submission.query_month_summary`](references/people-attendance-submission.md)**。
+
+**适用范围限定**：本接口**默认支持非 CN 员工**（新加坡 SGP / 马来西亚 MY / 其他海外）的加班月度汇总；**CN 中国大陆员工默认应走 `user_approval_over_time.list` 按月份范围查询后聚合 `duration`**。如果误调本接口且报错文案包含 `method not support CHN country`，必须立刻切回 `user_approval_over_time.list`；如果只是空汇总，则直接按统一空结果模板回复。
+
+只支持**单月**汇总；多月对比 / 跨年累计 / 半年汇总需逐月调用后聚合。
+
+#### 调用约束
+
+- **`month` 必须 6 位字符串 `YYYYMM`**（如 `"202606"`），**不是 `YYYY-MM`**，也不要传整数。
+- 跨年场景直接传该月份（如去年 12 月 → `"month":"202512"`）。
+- 当用户问句是「本月/上月/某月加班一共多少小时」时**优先用本接口**，不要拆 30 天窗口逐日 fan-out。
+
+#### Few-shot
+
+```bash
+# ✅ 本月汇总（2026-06）—— 中文环境
+people-cli attendance submission query_month_summary --params '{"month":"202606","accept_language":"zh-CN"}' --as user
+
+# ✅ 本月汇总（2026-06）—— 英文环境：accept_language 必须是 "en-US"（不是 en / en_US / en-us / en_us）
+people-cli attendance submission query_month_summary --params '{"month":"202606","accept_language":"en-US"}' --as user
+
+# ✅ 上月汇总（2026-05）—— 中文环境
+people-cli attendance submission query_month_summary --params '{"month":"202605","accept_language":"zh-CN"}' --as user
+
+# ✅ 跨年（2025-12）—— 英文环境
+people-cli attendance submission query_month_summary --params '{"month":"202512","accept_language":"en-US"}' --as user
+```
+
+#### 输出解析
+
+`data.overtime_summary_stats[]` 每项 `{label, value, detail_stats_lists}`，`value` 形如 `"34 小时"`、`"0 小时"`。把 `value` 解析为 `duration + unit` 后输出：
+
+```
+2026-06 加班汇总：duration=34, unit=小时
+明细：
+- 1.5 Hourly：4 小时
+- 2x Daily Salary：30 小时
+```
+
+> 当 `overtime_summary_stats` 为空或所有 `value` 都是「0 小时」，按统一空结果模板回复 `{month} 无加班记录`，**不要追加 `（duration=0, unit=hour）` 之类的零值结构化尾巴**。
+
+#### 场景示例
+
+- "我这个月加班了多少小时" → 单次 `query_month_summary`（`month=本月YYYYMM`）
+- "上个月加班时间统计" / "check my overtime summary for May" → 单次 `query_month_summary`
+- "去年 12 月的加班统计" → 跨年，`month=202512`
+- "4 月和 5 月我分别加了多少班" → 分别调用 `query_month_summary` 后比较
+- "上半年加班总时长" → 1~6 月分 6 次调用后求和
+
+> **注意**：`month` 参数格式为 `YYYYMM`（如 `202606`），不是 `YYYY-MM`。
+
+## 关键约束（汇总）
+
+- **Step -2 业务主词识别**（最优先）：进入本 skill 之前，**必须先确认用户业务主词是「加班 / overtime / OT / 加班审批 / 加班提报 / 调休 / 加班费 / 发起加班」等加班术语**。当主词为「出勤 / attendance / 出勤提报 / 出勤汇总 / 出勤记录」时（即使 query 同时引用 `Overtime Pay` / `1.5x Daily Salary` / `2x Daily Salary` / `Working Day Overtime` / `Time off in Lieu` 等 calculation_tag 字面值），**直接切到 `people-attendance` skill 用 `time_type=1` 处理**，**不进入本 skill 的 Step -1/Step 0**。calculation_tag 字面值不构成加班路由信号，禁止据此反推数据域。
+- **Step -1 地域前置确认**：地域信号缺失/模糊时必须先以固定模板和用户做一次二选一交互，**不可由 LLM 直接猜地域**；用户已在本会话答过则可复用，跨会话必须重新确认。不允许用 profile/部门/leader 中文名反推地域。**特别强调：`Working Day Overtime` / `2x Daily Salary` / `Time off in Lieu` / `Overtime Pay` / `1.5 Hourly` 等 calculation_tag 字面值不构成地域信号**，CN 员工同样可能引用这些英文标签。**英文 query 也不构成海外信号**，必须按"英文环境强化流程"先地域、再日期、再调接口。
+- **`accept_language` 仅 `submission.get` / `submission.query_month_summary` 这 2 个接口支持**，且字面值仅接受 `"zh-CN"` / `"en-US"`：服务端不识别 `en` / `en_US` / `en-us` / `en_us` / `english` 等任何变体，会默默回退中文。英文上下文调用 `submission.*` 时必须显式传 `"en-US"`，中文上下文显式传 `"zh-CN"`，不允许省略；任何变体都必须先归一化再写入 `--params`。`user_approval_over_time.list` / `+overtime-apply-*` 不支持 `accept_language`，禁止在其 `--params` 里塞该字段。
+- **❗英文查询 → 英文回复（语种镜像，强制规则，所有接口路径统一适用）**：用户用英文提问（query 含英文业务词 / 整句英文 / 含英文日期表达） → 面向用户的最终回复（结论文字、字段标签、表格表头、状态枚举、calculation_tag、unit、reason、星期、回显日期模板、拒绝话术、空结果话术等）**必须全部用英文**，**禁止**任何中文字符出现在回复中。
+  - **海外（SGP / MY 等）路径**：`submission.*` 已传 `accept_language="en-US"`，服务端通常返回英文字段；LLM 仍要核验并把任何残留中文映射成英文再展示。
+  - **CN 路径**：`user_approval_over_time.list` / `+overtime-apply-*` 接口**不支持 `accept_language`**，返回字段必为中文。LLM **必须**手动按下表把中文字段映射成英文后再回复英文用户，不允许直接抛中文。
+  - **字段值映射表（必备）**：
+    | 中文（不允许出现在英文回复中） | 英文等价 |
+    |---|---|
+    | 已通过 / 审批中 / 已拒绝 / 已撤回 / 已撤销 / 更正审批中 / 已取消 | Approved / Approving / Rejected / Withdrawn / Cancelled / Pending correction / Cancelled |
+    | 小时 / 天 / 半天 / 半小时 | Hour / Day / Half day / Half hour |
+    | 出勤 / 加班 / 加班记录 / 加班审批单 / 月度汇总 / 加班提报记录 | Attendance / Overtime / Overtime record / Overtime approval / Monthly summary / Recorded overtime |
+    | 星期一 / 星期二 / 星期三 / 星期四 / 星期五 / 星期六 / 星期日 | Monday / Tuesday / Wednesday / Thursday / Friday / Saturday / Sunday |
+    | 加班原因 / 加班时长 / 加班日期 / 加班类型 / 计算方式 / 补偿方式 | Overtime reason / Overtime duration / Overtime date / Overtime type / Calculation method / Compensation method |
+    | 工作日加班 / 调休假 / 加班费 / 节假日加班 / 周末加班 | Working Day Overtime / Time off in Lieu (Overtime) / Overtime Pay / Public Holiday Overtime / Weekend Overtime |
+    | 【SGP】常规出勤 / 【SGP】1 倍日薪 / 【SGP】1.5 倍时薪 / 【SGP】2 倍日薪 / 【SGP】调休假 | Regular Hours / 1 Daily / 1.5 Hourly / 2 Daily / Time off in Lieu (Overtime) |
+    | 无加班记录 / 无出勤记录 / 无记录 / 项目上线 / 线上故障 / 项目交付 | No overtime records / No attendance records / No records / Project launch / Production incident / Project delivery |
+    | 操作频繁，请5秒后重试 | Operation too frequent, please retry after 5 seconds |
+  - **回显模板（英文版本，全部场景必备）**：
+    - 单日：`Today is {YYYY-MM-DD} ({weekday}). The date you're asking about is {resolved_date} ({resolved_weekday}). Proceed.`
+    - 范围：`Today is {YYYY-MM-DD} ({weekday}). The range you're asking about is {date_from} ({from_weekday}) ~ {date_to} ({to_weekday}), {N} days in total. Proceed.`
+    - 拒绝（未来）：`Future dates are not supported for overtime queries.`
+    - 拒绝（写场景非 CN）：`Submitting overtime via CLI is only supported for China Mainland (CN) employees. Please submit your overtime application via the approval system.`
+    - 拒绝（写场景超 2 段）：`A single overtime application supports at most 2 segments. Please reduce to 2 or fewer segments.`
+    - 拒绝（他人）：`Only the current logged-in user's overtime records are supported.`
+    - 拒绝（撤回/取消/修改）：`This skill only supports submitting overtime applications. Withdrawing / cancelling / modifying applications is not supported.`
+    - 空结果：`No overtime records for {date or range}.`（**禁止**追加 `（duration=0, unit=hour）` 之类的零值结构化尾巴）
+    - 限流：`Rate limit hit (99991400) when querying {date}. Please retry later.`
+  - **Step -1 地域确认（英文话术固定模板）**：
+    ```
+    To route your overtime query to the correct API, please confirm your work location first:
+    1) China Mainland (CN)
+    2) Overseas (Singapore SGP / Malaysia MY / other overseas regions)
+    Reply with 1 or 2, or tell me your country directly.
+    ```
+  - **混合 query 时**：query 整句英文 / 主词为英文 → 全英文回复；query 主词中文 → 全中文回复；混合时按整句主体语种判定。同一会话内一旦判定语种，需保持一致直到用户切换语种。
+  - **历史评测复现**：英文用户问 `"Was my overtime for last Saturday approved?"`，CN 走 `user_approval_over_time.list` 返回 `status=2`（已通过），LLM 直接抛 `已通过` 给英文用户 → ❌；正解 → 必须翻译为 `Approved` 再回复。海外走 `submission.*` 时已传 `en-US` 仍偶发返回 `【SGP】常规出勤` → 必须翻译成 `Regular Hours`。
+- **未来日期意图必须进入 skill**：「下周二我会加多少班」「明天加班几小时」之类未来日期加班意图属于本 skill 覆盖范围，必须进入 Step -1 / Step 0 流程，由 skill 在 Step 0 检测到未来日期后统一回复「不支持查询未来日期的加班记录」并停止；不要绕开 skill 自由作答。
+- **Step 0 日期解析**：所有读/写场景调 CLI 前，必须先调用 `scripts/resolve_date.py`（中英文表达均覆盖）。脚本失败再 Level 2 推理，仍模糊则追问；最终必须以 `YYYY-MM-DD` 文本回显（歧义表达需等待用户确认）。
+- **地域适配（默认互斥，命中特定报错才回退）**：
+  - `user_approval_over_time.list` / `+overtime-apply-render` / `-options` / `-create` 默认走 CN 中国大陆员工；若查询时报错包含 `method only support CHN country`，切到 `submission` 查询；若写时报同样错误，直接告知暂不支持非 CN 大陆提交加班。
+  - `submission.get` (`time_type=2`) / `submission.query_month_summary` 默认走非 CN 员工（SGP / MY / 其他海外）；若报错包含 `method not support CHN country`，切到 `user_approval_over_time.list` 查询。
+  - 除上述精确报错外，**空结果/普通业务错误都不允许拿来做地域回退信号**。
+- **只支持当前登录账号本人**；不支持他人/工号/employee_id/下属。
+- **不支持未来日期**；解析后日期 > 当前日期直接拒绝。
+- **非法日期**（2 月 30 日、13 月）直接拒绝。
+- **`time_type=1` 出勤提报、`time_type=2` 加班提报**；查出勤请用 `people-attendance` skill。
+- **面向用户的回复中禁止暴露 skill 名称及切换提示**：不得出现 `people-attendance` / `people-overtime` 等 skill 名称，也不得出现「将切到 …」「改用 … skill」「切换到 … skill」「如需查出勤请切换到 people-attendance」之类话术。skill 之间的路由是内部行为，对用户透明执行即可；如确需澄清意图，使用业务措辞反问（例如「您想查询的是出勤记录还是加班记录？」），不要提及 skill 标识。
+- **超时长拦截**：单日加班 > 24 小时 / 时长为 0 / 时长为负，禁止提交，直接告知用户。
+- **写操作严限**：仅 CN 员工可发起本人加班申请；不支持代提、撤回、取消、修改、删除、导出。
+- **参数类型**：所有日期 (`check_date_*` / `date`) 必须是 `YYYYMMDD` 字符串、`month` 必须是 `YYYYMM` 字符串、`time_type` 必须是 `1|2` 整数；不要传科学计数法或 `Overtime` / `PeriodTime` 等文本枚举。
+- **空结果统一文案**：`{date} 无加班记录`，**禁止追加 `（duration=0, unit=hour）` 之类的零值结构化尾巴**；不要把空结果当成参数错误反复重试。
+- **限流处理**：`99991400` → sleep 2s 单次重试，仍失败停止并告知用户；`140001 interval > 30` → 按自然月拆分；`1000020904` / `1000020847` → 直接透传给用户，不重试。
+
+## 错误码速查
+
+| 错误码 | 含义 | 推荐处理 |
+|--------|------|---------|
+| `99992402` | 字段非法（最常见：`check_date_*` 传了 JSON 数字 / `time_type` 非 `1\|2`） | 改为字符串 `YYYYMMDD` / 改 `time_type=2`；不重试相同请求 |
+| `140001` | 区间 > 30 天 | 按自然月拆分逐次调用 |
+| `99991400` | 限流 | sleep 2s 单次重试，仍失败告知用户 |
+| `1000020904` | 当前员工未灰度 | 原文透传给用户，不重试 |
+| `1000020847` | 当前账号无相应权限点 | 提示「请联系管理员开通后再试」，不重试 |
+| `150006` / `1000020411` ErrWorkOrgNotExist | 仅在加班申请时出现，账号未挂 CN 工作组织 | 告知「当前账号不属于 CN 工作组织，无法发起加班申请」，不重试改 `form_info` 形态 |
+
+## 命令速查
+
+| 需求 | 推荐命令 |
+|------|---------|
+| 日期解析（加班申请 Step 0） | `python3 <skill_path>/scripts/resolve_date.py --expr "<表达>" --anchor "<YYYY-MM-DD>"` |
+| 查加班审批单（已通过/已撤回等） | `people-cli attendance user_approval_over_time list --params '<json>'` |
+| 查指定日期的加班提报记录（含 calculation_tag/status） | `people-cli attendance submission get --params '{"date":"YYYYMMDD","time_type":"2",...}'` |
+| 查指定月份的加班累计汇总 | `people-cli attendance submission query_month_summary --params '{"month":"YYYYMM",...}'` |
+| 渲染加班申请表单 | `people-cli attendance +overtime-apply-render` |
+| 查询加班申请选项 | `people-cli attendance +overtime-apply-options` |
+| 转换加班申请参数 | `people-cli attendance +overtime-apply-convert` |
+| 发起加班申请 | `people-cli attendance +overtime-apply-create` |
+
+## 参考文档
+
+- [people-attendance-overtime.md](references/people-attendance-overtime.md) — 加班审批记录查询
+- [people-attendance-overtime-apply.md](references/people-attendance-overtime-apply.md) — 发起加班申请
+- [people-attendance-submission.md](references/people-attendance-submission.md) — 查询加班提报记录 / 月度汇总