vps-work 2.2.0 → 2.4.0

package/skills/vps-pending-approval-assistant/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: vps-pending-approval-assistant
 description: |
-  提供 VPS 审批相关能力：`vps-work approval +wait` / `+pending` / `+my-submitted` / `+my-approved` 拉取本人、部门或全员待办与历史视图，`+logs` 看单证轨迹，`+pass` / `+refuse` 在明确意图下操作当前步骤。在用户查看待我审批、审批流、签核历史、我提交的审批、我已批过的单子、同意或驳回、统计待办类型或整理审批队列时使用。业务单据金额/明细等结构化取数由对应业务域 skill 负责，本技能不下钻业务表。
+  提供 VPS 审批相关能力：`vps-work approval +wait` / `+pending` / `+my-submitted` / `+my-approved` 拉取本人、部门或全员待办与历史视图，`+logs` 看单证轨迹，`+pass` / `+refuse` 在明确意图下操作当前步骤。新版 VPS 及 ERP 历史付款申请列表、金额明细和审批进度复用现有 exec 的 payment_applications 只读查询，需独立全量查询权限。在用户查看待我审批、付款申请单、ERP 历史付款、审批流、签核历史、我提交的审批、我已批过的单子、同意或驳回、统计待办类型或整理审批队列时使用。其他业务单据结构化取数由对应业务域 skill 负责，不拼接业务表查询。
 ---
 
 # 审批助手
 
 ## 何时使用
 
-用户需要审批相关能力：查看待我审批、我提交的审批、我已批过的单子、某单的审批轨迹，或在明确意图下通过/拒绝当前步骤。业务单据的金额/明细等结构化取数由对应业务域 skill 负责，本技能不下钻业务表。
+用户需要审批相关能力：查看待我审批、我提交的审批、我已批过的单子、某单的审批轨迹、新版及 ERP 历史付款申请列表和详情，或在明确意图下通过/拒绝原有审批步骤。付款查询仅支持下述只读能力；其他业务单据的金额/明细等取数仍交给对应业务域 skill。
 
 ## 工作流
 
@@ -18,27 +18,32 @@ description: |
 2. **历史审批** — **`vps-work approval +my-submitted`** / **`+my-approved`**。用户未区分时两条都跑
 3. **审批轨迹** — `vps-work approval +logs --res-model <m> --res-id <id>`
 4. **通过/拒绝** — 仅在用户明确表态后调用 `vps-work approval +pass` / `refuse`，带 res_model + res_id
-5. **下钻业务正文** — 用户要看"具体是哪些单子 / 单据金额 / 申请人 / 明细"等：交给对应 `res_model` 的业务域 skill；本技能不在内部对业务模型拼 `--fields` / `--domain` 绕路。若无对应专项 skill，则说明该明细暂不提供。
+5. **付款申请查询** — `vps-work exec --skill vps-pending-approval-assistant --script payment_applications`，需显式 `approvals.payment.all:read`。默认合并本企业新版 VPS 及 ERP 历史付款申请，可用 `--param source=vps` 或 `--param source=erp` 单独查询。支持日期、状态、申请人、单号和关键词筛选；详情使用 `--param operation=detail --param document_number=<完整单号>`。合并结果以 `next_cursor` 传 `cursor` 续查，单来源按 `next_offset` 传 `offset`。筛选及标识规则见 [reference.md](reference.md)，无发起、审批或编辑能力。
+6. **其他业务正文** — 用户要看其他类型单据的金额/申请人/明细时，交给对应 `res_model` 的业务域 skill；不拼接 `--fields` / `--domain` 绕路。若无对应专项 skill，则说明该明细暂不提供。
 
 ## 硬约束
 
-- **下钻明细必须切技能**：用户追问业务字段（金额/伙伴/状态/申请人/明细行 等）时，交给对应业务域 skill，不在本技能里查 res_model 业务表
+- **按已登记契约查询**：新版及 ERP 历史付款的业务明细只用 `payment_applications`；其他业务字段交给对应业务域 skill，不在本技能里查 `res_model` 业务表。本付款入口仅只读，禁止将查询权限当作审批或付款权限，也不得将原生付款 UUID 交给 ERP 的 `+pass/refuse/logs`。
 - **禁止盲构查询**：字段名/关系/枚举必须出现在 **skills/** 文档中；禁止 `vps-work knowledge`；禁止 `_fields` 嗅探；缺口 `POST /ai/skills/v1/feedback`
-- 只向用户展示 model_name 与数量，禁止展示 res_model/res_ids/原始 id 列表
-- web.approval.commit/approvaled 与 wait 同形，fields 完全相同
+- **原有审批队列视图**（`+wait` / `+pending` / `+my-submitted` / `+my-approved`）只向用户展示 `model_name` 与数量，禁止展示 `res_model/res_ids` 或原始 id 列表。
+- **付款查询例外（新版及 ERP 历史）**：已有独立权限且通过 `payment_applications` 取得数据时，可直接展示单号、申请人、部门、金额、币种、收款人、状态、明细行、审批进度和附件名称，无需转交其他技能。不展示内部附件标识或上传凭据；业务字段按名称解释，没有返回的数据不得编造。区分来源和日期口径；ERP 查询失败不能按“无历史单据”回答。
+- 原有 `web.approval.commit/approvaled` 与 `wait` 同形，fields 完全相同；这条仅描述原有队列视图，不限制付款查询的输出。
 - 所有 CLI 以当前用户 ACL 执行，不提供法律/强制性建议
 
 ## 常见坑点
 
 | 现象 | 根因 | 正确做法 |
 |------|------|---------|
-| 用户追问"具体是哪些单子 / 金额 / 申请人" | 只看了 model_name 和 count，想在本技能里直接查业务表 | **停下，交给对应 res_model 的业务域 skill**；无对应专项 skill 则说明该明细暂不提供 |
-| 业务字段报错 / 返回空 | 在本技能内对业务模型自行猜字段 | 禁止盲构；交给对应域 skill 后只使用文档已列字段，无文档则 feedback |
-| 审批后状态未变 | 没确认审批轨迹 | 通过/拒绝后查 approval logs 验证 |
+| 用户追问新版或 ERP 历史付款的单号、金额、申请人或明细 | 将原有队列的汇总限制套到付款查询 | 用 `payment_applications` 查询列表或详情，直接按返回数据展示；缺少独立权限时说明权限不足，不绕过授权 |
+| 同一单号在两边都有 | 只按单号无法定位来源 | 传 `source=vps/erp`，或用对应 `submission_id/erp_id`；不得按名称或金额猜匹配 |
+| 按人查历史单报关联缺失 | VPS 和 ERP 使用不同身份编号 | 不直接把 VPS 数字 ID 当 ERP 用户 ID；可明确只查新版，或使用 `source=erp` 与已知 ERP 员工 ID |
+| 用户追问其他类型单据的具体单子、金额或申请人 | 只看了 model_name 和 count，想在本技能里直接查业务表 | **交给对应 res_model 的业务域 skill**；无对应专项 skill 则说明该明细暂不提供 |
+| 其他类型单据的业务字段报错 / 返回空 | 在本技能内对业务模型自行猜字段 | 禁止盲构；交给对应域 skill 后只使用文档已列字段，无文档则 feedback |
+| 原有审批操作后状态未变 | 没确认审批轨迹 | 通过/拒绝后查 approval logs 验证 |
 
 ## 关联技能
 
-- 未知字段先读对应专项 skill 文档，禁止运行时字段嗅探；下钻前读专项文档
+- 新版及 ERP 历史付款按 [reference.md](reference.md) 的已登记契约直接查询和展示；其他业务下钻前读对应专项 skill 文档，未知字段禁止运行时嗅探。
 - **vps-current-user-identity** — 第一人称身份解析，审批视图已自动限定当前用户，无需额外取身份
 
 ---

package/skills/vps-pending-approval-assistant/reference.md

@@ -10,6 +10,21 @@
 | 通过 | `vps-work approval +pass --res-model … --res-id …` | VPS 审批服务 |
 | 拒绝 | `vps-work approval +refuse …` | VPS 审批服务 |
 | 轨迹 | `vps-work approval +logs …` | VPS 审批服务 |
+| 新版及 ERP 历史付款申请 | `vps-work exec --skill vps-pending-approval-assistant --script payment_applications` | 默认合并两个来源，只读，需 `approvals.payment.all:read` |
+
+付款查询参数：默认 `operation=list`、`source=all`，合并新版 VPS 和 ERP `cost.pay.apply` 历史申请，也可指定 `source=vps` 或 `source=erp`。可选 `start_date/end_date`（VPS 提交日期、ERP 申请日期，含首尾日期）、`status`、`applicant_user_id`、`keyword`、`document_number`。`limit` 默认50、最大100；合并结果原样传回 `next_cursor` 到 `cursor`，不能与 `offset` 同传或更改筛选条件；单来源按 `next_offset` 传 `offset` 续查。合并列表先按 VPS 提交时间 / ERP 申请日上海零点降序，同一时刻先 VPS，各来源内部再按 ID 降序；两库分别为只读快照，翻页期间源数据变化可能影响列表位置。
+
+`operation=detail` 必须且只能传 `submission_id`（VPS UUID）、`erp_id`（ERP 正整数 ID）或完整 `document_number`；带对应 ID 时自动确定来源。只传单号时默认在两边精确查找；两边同号或 ERP 内同号多条均报冲突，应指定来源或精确 ID，不能按金额/姓名猜匹配。仅有当前企业独立权限才可查询全员，不继承普通审批或管理员通配权限，不授予任何写入操作。
+
+`applicant_user_id` 始终是 VPS 用户 ID，历史筛选只使用当前企业账号的明确 `res.users` 来源关联；缺失/歧义时报错。历史离职员工未在 VPS 关联时，可明确 `source=erp --param erp_employee_id=<ERP员工ID>` 查询，不能和 `applicant_user_id` 同传。ERP 输出中的 `erp_employee_id/erp_applicant_user_id` 为来源标识，不当作 VPS 身份。
+
+新版及 ERP 历史付款都是本技能可直接展示业务明细的例外，不受原有队列“只展示类型与数量、明细切技能”的限制：列表 `items` 可展示 `source`、`document_number`、`applicant_name`、`applicant_department_path`、`amount/amount_cny`、`currency`、`payee`、`status`、`submitted_at/application_date` 及 `pending_approvers`；详情 `submission` 可展示 `values` 的表单与明细行、`approval_tasks`、`approval_history`、`comments`、`attachments` 和 `node_materials` 的业务信息。新版按冻结 `fields` 解读，ERP 的 `fields` 是已登记的原字段标签。无需转交其他技能，不展示内部标识或上传凭据。
+
+ERP `source_status` 保留原始状态：`draft→draft`、`approval→in_progress`、`finished→approved`，用于统一筛选；`finished` 表示 ERP 流程完成，不能据此断言已打款，应结合 `payment_date` 和原始历史。ERP `application_date` 是业务申请日，`submitted_at=null`，不能伪造成实际提交时刻。ERP 费用、发票、付款阶段、固定资产、分摊明细分别在 `values.payment_expense_lines/payment_invoice_lines/payment_stage_lines/payment_asset_lines/payment_allocation_lines`，完整返回，未设原审批卡片的8行展示上限。VPS 回写 ERP 的镜像按 `vps_request_id/vps_tenant_id` 明确标记排除，不按单号或金额去重。任一数据源不可用时合并查询报错；可明确 `source=vps` 单独查新版，不能把错误当作历史单据数量0。
+
+`attachments` 是表单附件与旧附件表的合并目录，含 `file_name/content_type/size_bytes`、来源 `source`（`form_values` 或 `legacy`）及位置 `field_key/field_path`；明细行位置如 `["payment_expense_lines",0,"evidence"]` 中行号从0开始，向用户说“第1行”。相同文件在不同字段或行内的引用保留，不按文件名去重。原表单未记录上传时间时 `created_at=null`，不能用提交时间代替。`id` 仅供程序识别，目录不提供原文件下载能力；审批节点材料仍在 `node_materials` 中单列。
+
+ERP 附件目录还包含 `erp_form_values/erp_attachment` 来源：主表发票、结算单、付款凭证、行政发票 JSON 附件、发票行附件及旧 `ir_attachment`/关系表附件；不复制附件 URL、访问令牌或二进制内容到目录。无法解析的原附件通过 `attachment_issues` 标明字段位置和原因，不能把它描述成“没有附件”。ERP 办理附件包含在此目录，没有单独的 VPS 节点材料表，`node_materials=[]`。
 
 ## 三种视图的通用查询
 
@@ -33,9 +48,9 @@
 - **`vps-work approval +logs`**：`res_model`、`res_id`。
 - **`vps-work approval +pass` / `+refuse`**：`res_model`、`res_id`；`+pass` 可选 `proposal`。
 
-## 下钻明细必须切技能
+## 其他类型单据下钻明细必须切技能
 
-用户从"审批待办/历史"进入"具体是哪些单子 / 金额多少 / 谁提交的 / 明细行" 这一步时，**本技能就到此为止**：
+除上述新版及 ERP 历史付款查询外，用户从原有"审批待办/历史"进入其他类型单据的"具体是哪些单子 / 金额多少 / 谁提交的 / 明细行" 这一步时，切换到对应技能：
 
 1. **交给对应 `res_model` 的业务域 skill** —— 由它负责业务模型取数；若无对应专项 skill，则说明该明细暂不提供。
 2. 匹配 **Features** 中与 `res_model` 对应的专项 skill，读其 `reference.md` / `references/*.md` 中的字段与 domain 示例。
@@ -49,7 +64,8 @@
 
 ## 输出结构（对用户）
 
-1. 待办/历史：仅文档类型标签 + 数量。
+1. 原有队列待办/历史：仅文档类型标签 + 数量。
 2. 轨迹：时间顺序叙述，无内部 id。
-3. 其他业务信息：经数据技能路径取数后，用业务语言转述。
-4. 可给简短核对建议，不编造数据。
+3. 新版及 ERP 历史付款：直接展示已授权查询返回的来源、单号、申请人、金额、明细行、进度及附件名称。
+4. 其他业务信息：经数据技能路径取数后，用业务语言转述。
+5. 可给简短核对建议，不编造数据。

package/skills/vps-purchase/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: vps-purchase
+description: "只读查询 VPS 原生采购申请及明细、ERP 采购订单及订单行。适用于采购单、办公采购申请、供应商订单、采购数量、单价、收货及开票数量查询。必须使用当前身份的独立采购只读权限。"
+---
+
+# 采购只读查询
+
+开始前读取 [vps-shared](../vps-shared/SKILL.md)。先用 `vps-work catalog --domain purchase` 检查当前企业可见能力。
+
+## 权限和来源
+
+- `purchase.requests.all:read`：本内部企业全部 **VPS 原生**采购申请及明细。
+- `purchase.orders.all:read`：内部企业 ERP 业务库的全部采购订单及明细，可按公司筛选。
+- 两项独立，沿用 VPS 角色 → 权限组 → 权限项配置；管理员、普通审批权限、付款权限均不自动获得。无权限应说明权限不足，不切换身份或绕过授权。
+- ERP 订单查询要求企业开通 ERP；企业停用 ERP 不影响原生采购申请。
+- 本入口不读取 ERP 历史 `cost.procure.apply`，不将 VPS 采购申请当成采购订单；不存在申请到 ERP 订单的推定关联。
+
+## 命令
+
+```bash
+vps-work purchase +requests --start-date 2026-10-01 --end-date 2026-10-28 --limit 50
+vps-work purchase +request-detail --id <VPS申请UUID>
+vps-work purchase +request-lines --document-number <完整申请单号> --limit 50 --offset 0
+vps-work purchase +orders --company-id 1 --status purchase --keyword <关键词>
+vps-work purchase +order-detail --id <ERP订单整数ID>
+vps-work purchase +order-lines --id <ERP订单整数ID> --limit 50 --offset 0
+```
+
+已有 CLI 可通过通用 `exec` 使用相同能力，无需等待快捷命令发布：
+
+```bash
+vps-work exec --skill vps-purchase --script requests --param operation=list
+vps-work exec --skill vps-purchase --script orders --param operation=lines --param id=123
+```
+
+## 查询契约
+
+脚本为 `requests` 或 `orders`，参数以 catalog 为准。`operation` 支持 `list`（默认）、`detail`、`lines`。
+
+- 详情和明细必须提供一个标识：申请用 `submission_id`（快捷命令 `--id`），订单用整数 `id`，或二者都可用 `document_number` 精确匹配完整单号。多个同号记录返回冲突，改用 ID。
+- 列表支持 `status`、`keyword`、`company_id`、`start_date`、`end_date`、完整单号；条件取交集。日期均按上海时区且包含两端，申请按提交日期，订单按订单日期。未提交日期为空的申请不进入日期筛选结果。
+- 列表和明细分页：`limit` 1–100，默认 50；用响应 `next_offset` 继续，直到 `has_more=false`。不能把一页当作完整清单。详情不接受分页参数。
+- 申请详情含 `details.purchase_lines`；订单详情返回 `line_count` 和 `lines_query`，另用 `lines` 分页取明细，避免静默截断。
+- ERP 金额和数量按十进制字符串返回。申请明细区分预计数量／单价与实际采购数量／单价／金额。不同币种不得直接相加。
+- `erp_buyer_user_id` 是 ERP 用户 ID，不是 VPS 用户 ID，不用姓名匹配身份。
+- 仅返回固定业务字段，不返回附件 URL、上传凭据或审批操作能力。禁止任意模型、字段、SQL、domain、租户参数和写入动作。
+- ERP 失败必须报告不可用，不得回答“没有订单”；申请查询不会依赖 ERP 在线校验。

package/skills/vps-sale-personnel-efficiency/SKILL.md

@@ -67,7 +67,7 @@ description: |
 - **开单率目标源例外**：分母必须显式传 `okr_source=legacy`，与管理端个人业绩目标页面一致
 - **开单率固定排除**：国内渠道排除二级部门国内代理；AI渠道排除二级部门AI电商；输出必须披露
 - **人产共用口径**：分母和固定排除与开单率一致，禁止改用在职人数或开单人数
-- **取数走 CLI 封装**：脚本通过 `vps-work sales +…` 直连规范视图执行，无需手写连接
+- **取数走 VPS 业务工具**：通过 `vps-work sales +…` 查询 VPS 平台提供的销售数据，连接与认证由宿主管理，无需配置数据库连接
 
 ## 常见坑点
 

package/skills/vps-store-management/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: vps-store-management
-description: "门店管理：查询国内渠道门店接待、进店客流、客户画像、意向商品、加微信、有效客户、产品触摸/试用和现场成交过程数据。用户问门店接待情况、进店组数、进店人数、客户画像、意向商品、加微率、有效客户、触摸率、使用率、现场成交率、门店客流排行时使用 `vps-work store +reception`。"
+description: "门店经营查询：Walk-in 按部门和日期筛选分组，门店库存按报表部门、门店和商品筛选分组，以及接待转化和客户画像。自然进店来源的经销商订单使用 sales +agent-walkin。"
 ---
 
 # 门店管理
 
 **CRITICAL — 开始前 MUST 先读取 [`../vps-shared/SKILL.md`](../vps-shared/SKILL.md)。**
 
+## Walk-in 与门店库存
+
+按部门、日期查询客流使用 `vps-work store +walk-in`；查询当前门店库存使用 `vps-work store +inventory`。参数、组合分组和统计口径见 [references/store-analytics.md](references/store-analytics.md)。
+
+库存报表中的部门是库位对应名称，不等同人事部门 ID；库存为当前账面数量，不要解释为可售数量。回答前核对 filter，跨页汇总使用 summary。
+
 ## 门店接待情况
 
 使用 `vps-work store +reception`，详细参数和口径见
@@ -29,7 +35,9 @@ vps-work store +reception --period this_month --source dealer
 ## Script
 
 - `skill_key`: `vps-store-management`
-- `script_key`: `store_reception_summary`
+- `script_key`: `store_reception_summary`、`store_walkin_summary`、`store_inventory_summary`
 - 权限：`sales.headline_kpi:read`
 
-返回除汇总和门店行外，还包含 `breakdowns`：接待类型、到店时段、单据状态、性别、年龄段、购买目的、手机品牌、客户来源、微信状态和意向商品。
+`store +reception` 返回除汇总和门店行外，还包含 `breakdowns`：接待类型、到店时段、单据状态、性别、年龄段、购买目的、手机品牌、客户来源、微信状态和意向商品。
+
+`store +walk-in` 和 `store +inventory` 返回 `summary`、分页 `rows` 与 `total_groups`，不返回 `breakdowns`。

package/skills/vps-store-management/references/store-analytics.md

@@ -0,0 +1,47 @@
+# Walk-in 与门店库存
+
+## Walk-in 查询
+
+```sh
+vps-work store +walk-in --start-date 2026-10-01 --end-date 2026-10-14 --group-by department,date
+vps-work store +walk-in --department "上海国金" --period this_month --group-by date --date-grain week
+vps-work store +walk-in --department-id 1464 --period today --source all --group-by all
+```
+
+接口为 `POST /v1/execute`，`skill_key=vps-store-management`，`script_key=store_walkin_summary`。
+
+- `department` / `department_id`：接待所属部门精确匹配，不自动包含子部门。两者一起提供取交集。
+- `start_date` / `end_date`：含首尾日期；只提供一端按该单日查询。也支持 `period`，默认本月。日期使用接待自然日，不根据成交日期归属。
+- `store`：接待表单门店名称精确匹配。
+- `source`：`store` 默认排除代理商、`dealer` 仅代理商、`all` 全部。
+- `group_by`：`department`、`date`、`store` 的逗号组合；`all` 仅总计。默认 `department,date`。
+- `date_grain`：`day` 默认、`week`、`month`；分组日期分别为当日、周一、月初。
+- `limit` / `offset`：分组分页，默认 100 / 0，limit 上限 1000。
+
+指标：`walkin_groups` 接待记录数；`walkin_people` 进店人数；`deal_groups` 成交组数；`deal_amount` 成交金额（仅成交记录）。保留未归属部门或门店为 null。此接口不将客流限于四个国内区域；需要旧区域、客户画像和转化率报表使用 `store +reception`。
+
+## 门店库存查询
+
+```sh
+vps-work store +inventory --group-by department,store,product
+vps-work store +inventory --department "北京国贸CL2009" --store "北京国贸" --group-by product
+vps-work store +inventory --product "METAVERTU" --group-by store
+vps-work store +inventory --product-code "商品编码" --group-by all
+```
+
+接口同上，`script_key=store_inventory_summary`。
+
+- `department`：现有库存报表部门名称精确匹配，**不是人事部门 ID**。
+- `store`：库位路径首段的门店名称精确匹配。
+- `product`：商品名称或商品编码包含匹配，百分号和下划线按普通文字处理。
+- `product_code`：编码精确匹配。多个筛选条件取交集。
+- `group_by`：`department`、`store`、`product` 的逗号组合，或 `all`。默认三者组合。
+- `limit` / `offset` 同上。商品分组保留 `product_code` 和 `product`，避免不同编码的同名商品混合。
+
+复用 ERP 实时库存报表视图的库位排除和名称归一规则，只统计归类为门店库存的产成品、半成品，不包含工厂、线上、海外分类库存。`quantity` 为当前账面库存净数量，保留负数抵减；不代表可售库存。不接受日期参数，也不承诺历史库存查询。`queried_at` 是请求完成时间，不是某份物化快照的刷新时间。
+
+## 返回值和权限
+
+两个接口都返回 `filter`、`group_by`、`summary`、`rows`、`total_groups`、`limit`、`offset`。`summary` 是完整筛选范围，不能把单页 rows 当成全部结果；需要全部分组时按 offset 翻页。没有匹配记录时 summary 为零、rows 为空（`all` 分组返回一行零汇总）。
+
+权限沿用 `sales.headline_kpi:read`，服务端 catalog 和执行入口统一检查。服务端通过既有 `VERTU_PG_*` 环境配置读取业务库，CLI 不接收数据库凭据。部署服务端后，旧 CLI 可通过 `catalog` / `exec` 发现调用；新快捷命令需要发布新版 CLI。

package/skills/vps-task-management-assistant/SKILL.md

@@ -60,6 +60,19 @@ description: |
 | `+tc-okr-options` | 当前用户可绑定的正式 OKR/KR；可选 `--period YYYY-MM`、`--owner-type`、`--owner-id` |
 | `+my-okr` | 个人或团队 OKR（`--type mine|team`，默认 mine；`--period YYYY-MM` 省略=当前周期） |
 
+## 简单日期查询的快速路径
+
+“我明天的任务是什么”只查询当前用户在所问日期的事项，不默认扩展到其他部门、研发 MCP、品牌增长、审批、考勤或整周日历。用户明确要求跨系统时再扩展；“工作安排/日程”才增加本人日历查询。
+
+当前 CLI 提供 `--start-time YYYY-MM-DD --end-time YYYY-MM-DD --date-field deadline|start_date`（待办不支持 start_date），日期范围含首尾两天。先在宿主当前 CLI 的帮助中确认这些参数可用；旧版本没有这些参数时不要猜测或声称已经按日期筛选。
+
+- 当前用户身份已通过本轮认证上下文确认后复用，不重复查询身份。
+- 第一次列表查询就传本人 `--owner-user-id <当前用户ID>` 和 `--no-include-department`，不要先读取全部门再筛选。
+- 并行读取本人当天 `deadline` 到期任务、`start_date` 计划开始任务，以及 `deadline` 到期待办；日期按业务时区解释。任务 UUID 去重，不能把没有到期项说成“当天没有工作”。
+- `has_more=true` 时继续翻页：任务 `--offset` 从 0 开始递增实际页长度；待办 `--page` 从 1 开始递增。没有完整读完不能声称零项或给出全量数量。
+- 查询成功且范围内无结果就返回明确范围，不通过扫描无关系统“凑答案”。失败说明失败，不当作空结果。
+- 实时语音优先先给结论和最多五条必要事项；不要生成长表格或顺带扩展任务。
+
 ## 工作流
 
 1. 判断用户是查询还是写操作；任务/待办/项目都走 `+tc-*`。