feishu-task

name	feishu-task
description	通用飞书任务创建、补全、去重、更新与回读流程。用于用户要求添加、创建、记录、安排或同步飞书任务/待办，或提供聊天记录、截图、会议材料和附件并希望转成可执行飞书任务时。执行前复用或按需补充当前项目的“项目任务协调员”；自动解析账号/Profile、人员角色、时间、任务详情、附件与验收标准；任务写入后判断新增、时间、负责人、状态或工作量变化是否影响当前用户排程，必要时联动 personal-schedule-planner 生成修订草案；附件含密码、令牌、2FA 密钥等局部秘密时，制作并上传不可逆脱敏副本；项目明确指定飞书账号时遵循项目规则，未指定时继承 GLOBAL 记录的全局默认 Profile。

飞书任务

固定依赖

• 执行业务命令前先确认 lark-cli 可用：优先用当前 shell 的命令发现机制，例如 Get-Command lark-cli；Windows 下如命令不在 PATH，可按当前 npm 全局前缀或 %APPDATA%\npm 等用户级 shim 机制定位 lark-cli.cmd/lark-cli.ps1，不要硬编码单一用户名路径。仍不可用时，转 feishu-profile 做 CLI 安装、Profile 或 workspace 恢复，不直接进入任务业务调用。
• 优先通过 lark-cli skills read lark-task 读取当前 CLI 内嵌、版本匹配的任务规则；读取操作引用时使用 lark-cli skills read lark-task references/<文件>。当前 CLI 不支持内嵌读取时，才使用已安装且版本匹配的 Skill 副本。
• 使用 lark-task 执行搜索、创建、更新、成员、关注人、附件和回读；使用全局 feishu-profile 处理认证、Profile、user identity、换机恢复与配置冲突，并按需读取 CLI 内嵌 lark-shared 规则。
• 涉及姓名解析时使用 lark-contact，不得猜测人员 open_id。
• 截图附件需要局部脱敏时使用 imagegen 或当前可用的等效图像编辑能力；完成后必须回查，不能把编辑成功等同于脱敏合格。
• 按实际操作读取 create、update、search、followers、attachment 等引用；设置开始时间前必须确认当前 CLI 内嵌 lark-task 对 start 的真实支持与语法。
• 创建或更新 start 时以当前 CLI 的 skills read、schema 和命令 --help 为准；若 shortcut 没有 start flag，则按当前 schema 使用原生 task tasks create --data ... / task tasks patch --data ... 或等价 JSON payload。更新 start 时必须按当前 schema 把 start 纳入更新字段。
• 任务写入后的排程影响判断使用 personal-schedule-planner 的 飞书任务排程联动契约 和 scripts/task_schedule_handoff.py；通过当前已安装 Skill 入口解析脚本位置，不硬编码用户目录。

选择飞书账号与身份

每次执行按以下优先级解析 Profile，低优先级不得覆盖高优先级：

1. 用户在当前请求中明确指定的账号、公司或 Profile。
2. 当前项目中与目标主体或资源直接匹配的条件化路由。
3. 当前项目 AGENTS.md、项目专属 Skill 或项目长期规则明确指定的项目默认 Profile。
4. GLOBAL/LARK_PROFILES.md 记录的全局默认 Profile。

“当前一句话未提账号”不等于“项目或 GLOBAL 未指定账号”。先检查项目条件化路由和默认规则，再继承 GLOBAL 默认。确定 Profile 后立即通过 auth status 获取实际 Profile、身份类型、当前用户姓名和 open_id，并在本次任务的全部命令中保持同一 Profile 和 user identity。

• 项目或用户明确指定 Profile 时，所有命令显式传入 --profile <Profile> --as user。
• 使用 GLOBAL 默认 Profile 时，从 GLOBAL/LARK_PROFILES.md 读取治理层默认值，后续命令显式固定该 Profile；CLI active 只用于核验和发现冲突，不得覆盖 GLOBAL 默认。
• 若运行环境注入的临时配置、工作区绑定、环境变量或 CLI active/default 运行值覆盖项目或 GLOBAL 已解析的 Profile/身份，将其视为身份配置冲突。仅在当前命令进程中隔离冲突来源，再重新显式指定已解析的 Profile 和 --as user。
• 不修改全局 active Profile、全局配置或其他项目绑定，不绑定其他主体，不暴露凭据，不静默切换公司，不回退到 bot 身份。
• 指定 Profile 不存在、默认 Profile 无效、登录用户不明或 user 授权不足时，在读取敏感数据或写入任务前转交全局 feishu-profile 检查和恢复；仅在主体不明或多个高优先级来源冲突时询问用户。

路由项目任务岗位

执行任务业务前读取当前项目 AGENTS.md 的“项目组织”模块：

1. 查找“项目任务协调员”或职责等价的长期岗位。已有岗位时复用并把本次任务指派给它；当前会话本身已承接该岗位时直接继续，不递归转派。
2. 没有等价岗位时，先在“项目组织”模块补充“项目任务协调员”，职责限定为本项目飞书任务的创建、更新、去重、回读和排程 handoff；不得接管其他项目任务，也不得覆盖本项目 Profile、负责人或授权规则。
3. 环境支持长期任务窗口管理时，建立或复用对应窗口并传递当前项目入口、用户原始请求、已解析 Profile 和必要任务上下文。环境暂不支持时，由当前会话完成本次任务并在结果中说明岗位已登记、尚由当前会话兜底；不能因缺少窗口而阻塞任务。
4. 岗位补充是用户已确认的 GLOBAL 按需规则，不需要重复询问；除该岗位外，不得借此新增其他长期岗位或扩大授权。

岗位路由只改变执行归属，不改变下节的任务写入授权、身份核验、去重、dry-run 和回读要求。

判断授权与任务边界

• 用户明确说“添加任务”“创建待办”“记录到飞书”等即视为创建或更新授权，无需再次确认。
• 用户只请求查看、分析、总结或起草时不得写入飞书。
• 不删除、完成、关闭或改派现有任务，除非用户明确要求。
• 合并当前对话、引用消息、截图、附件、会议材料和已确认反馈；后续更正覆盖旧决定。
• 多个交付共享目标、负责人和截止时间时可合并；目标、负责人或验收边界明显不同则拆分。

解析人员角色

按以下顺序处理：

1. 先识别每句话的说话人，再识别任务提出者、实际执行者、协作者、审核/验收者和仅需知悉者。
2. 按“用户当前明确指定 → 对话最终确认的分工 → 行动词归属 → 默认规则”判定。
3. 后续更正覆盖前文；例如“不是我做，让 B 做”必须移除当前用户的负责人角色，但不移除其默认关注人角色。
4. 区分确定语气与建议语气：“让 B 做”“B 负责”可直接分配；“可以考虑 B”“要不问问 B”不能据此分配。
5. 截图或转写无法可靠识别说话人、代词或同事姓名时，只询问最少必要信息，不凭气泡位置、头像或语气猜测。

只要任务来源包含聊天记录、截图、会议转写、多名人员，或人员角色存在任何歧义，必须完整读取 references/role-scenarios.md 后再确定负责人和关注人。

核心默认规则：

• 实际承担交付动作的人是负责人，不等同于提出者、创建人或聊天参与者。
• 没有明确执行者时，默认负责人是所选 Profile 的当前登录用户。
• 所选 Profile 的当前登录用户始终作为默认关注人，即使其同时是负责人。
• 任务提出者、交办者、明确审核/验收者和要求同步结果的人加入关注人。
• 同一人可以同时是负责人和关注人；仅被提及或参与讨论不构成角色依据。

解析开始时间与截止时间

1. 优先使用用户明确给出的日期和时间。明确出现“开始、启动、从……开始、安排在……开始、明早开始做、今晚开工”等开始语义时，设置任务 start。
2. 当前请求中的“今天、明天、下周一、明早、今晚”等以当前会话时区和日期换算；历史消息、截图或转写中的相对时间以该消息实际时间和会话时区换算。消息时间不可靠时，不得据此设置 start 或 due。
3. 只有日期没有时刻时，使用全天日期：start.is_all_day=true 或 due.is_all_day=true，并把对应日期换算为毫秒时间戳。
4. “周五前完成”“月底交付”等属于有效最终截止信息，应换算为具体 due；“周五开始”“月底启动”等才设置 start。
5. 多个时间节点要区分 start、评审/检查/同步、提交和最终 due。最终交付设为 due；明确的开始节点设为 start；评审、检查、同步等中间节点写入描述的 【时间节点】，不得误设为 start 或 due。
6. 不得把消息时间、任务创建时间、当前时间、“现在记录一下”“尽快”“越快越好”“有空时”等擅自当作 start。没有开始时间证据时，不设置 start。
7. 同时设置 start 和 due 时，必须保证 start <= due，且两者 is_all_day 设置一致；无法满足时先询问或只写入可确定的描述节点，不写入冲突字段。
8. 更新已有任务时，只有用户提供新的明确开始时间，或上下文出现可可靠换算且应覆盖旧值的开始时间证据，才更新 start。无新证据时保留原 start，不清空、不覆盖；用户明确要求清除开始时间时，按当前 CLI schema 使用 update_fields:["start"] 且 task 中不提供新 start，并先 dry-run 核对清空意图。
9. 没有截止时间证据时不编造 due。日期缺失会使任务无法执行，或用户要求必须有日期时，再询问。

生成可执行任务

标题使用简洁动宾结构，说明最终交付。描述按内容选用：任务目标、背景与已确认结论、交付内容、具体执行要求、禁止项与边界、时间节点、负责人和关注人、验收标准、来源与推定。

只要任务包含连续修改意见、多个交付物、精确文案或数字、视觉/内容制作、会议行动项、项目实施、复杂验收要求，必须完整读取 references/task-description.md 后再生成标题和描述。

• 精确保留用户给出的文案、数字、名称、尺寸、路径、链接和格式。
• 把连续反馈整理为保留项、修改项和禁用项，不把已否定的旧方案写成要求。
• 合理推断标记为“根据上下文推定”；不得捏造业务事实、职责、日期或验收口径。
• 删除空章节，不为了套模板制造冗余正文。

处理附件

• 默认上传与任务执行、验收或来源追溯直接相关的附件；纯界面状态、重复信息或仅用于说明问题的截图可以不上传，并在结果中说明。项目规则另有更严格要求时从其规定。
• 逐一检查密码、API token、2FA 密钥/二维码、恢复码、带凭据的 URL、未脱敏证件等秘密；不在任务描述、命令、文件名或结果中重复秘密本身。
• 秘密集中在可明确定位的区域时，不跳过整份附件：制作局部脱敏副本并上传，含秘密的原件不得进入飞书。只遮盖敏感位置，保留任务执行、验收和追溯所需内容；同一秘密在正文、二维码或 URL 参数中重复出现时全部遮盖。
• 使用完全不透明的实色覆盖或彻底删除敏感区域，保证不可逆；不把模糊、半透明遮罩或仅降低清晰度的马赛克作为最终脱敏。
• 脱敏后以原始分辨率回查：秘密不得可读、可扫描或可推断，非敏感任务事实不得被改写、裁掉或生成错误。副本使用不含秘密的文件名，并在描述或结果中仅注明“附件已脱敏”。
• 只有无法可靠定位全部秘密、无法验证遮盖效果、脱敏会破坏附件主要证据，或文件受密码保护而无法安全处理时，才不上传；说明原因和可行补救方式，不用空附件伪装完整。
• 脱敏副本仅保留到上传和任务回读完成，随后删除本地临时副本；不得删除或改写用户提供的原始文件。
• 普通聊天内容、业务背景、修改意见和常规人员信息不属于应自动排除的机密附件。
• 逐一核对附件，不得因只上传了其中一项而把任务报告为完整。

创建、去重与回读

1. 解析 Profile、当前用户、标题、start、due、负责人、关注人、描述和全部附件。
2. 用 lark-contact 解析人员；候选不唯一、无法解析或同名时，在写入前询问，不猜 open_id。
3. 已提供任务 GUID 或可解析出 GUID 的 applink 时，直接回读并更新该任务，不再搜索；ID 不明确时，才以标题、截止日期和关键交付搜索近期任务。确认是同一任务时更新原任务，不创建“修正版”；无法判断时列出候选请用户确认。
4. 更新已有任务的多个字段时，能力支持则先 dry-run，核对目标 GUID、请求方法、更新字段和主要 payload；新建任务使用稳定的 idempotency key。dry-run 核对必须包含 start 的写入、保留或未变更判断。
5. 按版本匹配的能力补齐多名负责人、关注人和执行相关附件。
6. 判断成功以返回 ok == true 为准，写入后必须回读。
7. 回读验证实际 Profile、标题、状态、开始时间、截止时间、负责人、关注人、附件数量、描述中的关键交付、精确文案和验收标准。
8. 发现漏项时更新同一任务，不重复创建。
9. 返回任务标题、实际使用的公司/Profile、负责人、关注人、开始时间、截止时间和可点击链接。
10. 按下节执行一次排程影响判断；批量任务在全部任务完成回读后统一判断一次。

联动个人排程

完整读取 飞书任务排程联动契约，在任务写入和最终回读之后执行：

1. 保存更新前已回读状态；新建任务的 before 为 null。以最终回读结果构造 after，不得用拟写 payload 代替。
2. 只保留判定所需的来源项目名称与根目录、任务 GUID、Profile、当前用户 open_id、变更前后负责人、start、due、状态和可靠估时；来源项目从当前项目入口取得，不根据 Profile 猜测。不把任务全文、附件内容、客户秘密或内部链接写入临时交接文件。
3. 使用今天的自然日窗口调用 personal-schedule-planner/scripts/task_schedule_handoff.py。更新前或更新后的执行者包含当前用户，才可能触发；始终只是关注人、提出者、审核者或知悉者时不触发。
4. 对变更前后涉及的未来日期，先轻量回读全部治理层 Profile 的稳定排程标记，分别填写该日期是否已有个人时间管理员创建的受管排程；不得把未来观察窗口、普通忙碌日程或任务截止本身当作已排程证据。新增到尚未建立受管排程的未来日期时不触发。
5. 今天或已有受管排程日期中的新增、时间进入/离开/移动、负责人转入/转出、完成/取消/重开，以及可靠工作量变化属于排程相关变化。只改标题、描述、附件、关注人或验收文案不触发。
6. 用户明确要求“加入安排”“排进当前计划”或重排目标日期时设置 explicit_schedule_request=true；即使没有日期，也交给排程 Skill 判断能否容纳，但仍要求当前用户是执行者。
7. 批量创建或更新时把全部 change 放进同一个输入，只调用一次判定和一次排程 Skill，不能逐条重排。
8. 输出 trigger=true 时，在当前任务中继续调用 personal-schedule-planner，传入完整 handoffs[] 并重新采集实时任务与日历。自动发生的是只读重评和完整草案，不是日历写入；必须再次获得用户对修订草案的明确确认。
9. 输出 trigger=false 时正常报告任务结果，不启动完整排程。脚本因必要字段缺失而失败时补齐并重跑，不得把失败静默当成无需排程。

任务从今天调到明天时仍会触发：排程草案应释放今天原受管时间块，并根据完整规划判断是否在明天创建新时间块。任务从未排程的明天调到今天、在今天内提前/延后，或当前用户失去/获得今天的执行责任时使用同一逻辑。未来日期只有已存在受管排程或用户明确要求安排时才触发。

失败与中断处理

• 身份、Profile 或权限异常时先按全局 feishu-profile 排查和恢复，并按需读取 lark-shared；不尝试其他公司的 Profile。
• 已创建任务但详情、成员或附件写入不完整时，保留原任务并更新修复。
• 人员候选不唯一、日期无法可靠换算、多个任务边界不清或同名任务疑似重复时，提供最少必要信息并请用户确认。
• 附件无法可靠脱敏而被跳过时明确报告，不用空附件或未经验证的替代文件伪装为已上传。
• 不以命令无报错代替回读验证，不凭猜测报告成功。