ooodc a7883dbed9 refactor(todo): 重构待办事项管理逻辑及更新状态规则

- 移除 TodoItem 中的 priority、created_at 和 updated_at 字段
- 强制每个任务都必须有唯一 id，且由用户负责生成
- 修改合并模式逻辑，merge=true 下保留未提及的旧任务
- 支持已完成和已取消任务重新激活（状态改回 pending 或 in_progress）
- 禁止 in_progress 状态退回到 pending，必须标记为 completed 或 cancelled
- 优化状态转换校验，允许特定状态间合法切换
- 简化任务变更消息，移除详细的新增/更新/移除统计
- 更新文档和示例，明确 id 必须由用户生成和使用
- 修复和补充测试，增强状态转换和合并模式验证
- 调整任务时间戳生成逻辑，统一使用当前时间及索引
- 该变更提供更合理的任务状态机械及管理模式，提升稳定性和易用性

2026-06-13 09:22:33 +08:00

3.1 KiB

Raw Blame History

Group Chat Identity Rules

Warning: The most common source of failure in group operations is choosing the wrong identity. Confirm the identity before performing the action.

Group-chat operations support both --as user (UAT user identity) and --as bot (TAT bot identity). Choosing the correct identity is critical for success.

Basic Principles

If the user explicitly specifies an identity: use exactly what the user requested (--as user or --as bot) without guessing.
If the user does not specify an identity: infer the correct identity from context instead of relying on the default.

Identity Selection by Operation

Operation	Recommended Identity	Why
Create group (`+chat-create`)	Depends on the scenario	Infer from context
Add members (member-management flow)	`--as user`	Bot visibility is limited and often fails when the target user is mutually invisible to the bot (232024)
Update group (`+chat-update`)	Owner identity	Permission changes require owner/admin privileges; owner transfer requires owner identity

Inferring the Owner

When an owner-level action is needed and the owner is unknown, infer in this order:

A bot created the group and --owner was not specified -> the owner is the bot (--as bot)
A bot created the group and --owner ou_xxx was specified -> the owner is that user (--as user)
A user created the group and --owner was not specified -> the owner is the current user (--as user)
Still unclear -> ask the user to confirm who owns the group before making owner-level changes

When the Owner Is Neither the Current User Nor the Bot

If the query shows that the owner is a third-party user (owner_id is neither the currently authorized user nor the bot), the current identity does not have owner privileges. In that case:

Permission/setting changes: if the bot is an admin of the group, --as bot can still perform admin-level operations such as renaming the group or changing permissions.
Owner-only actions such as owner transfer: require the actual owner to complete UAT authorization via lark-cli auth login, then perform the action as that owner.
Explain the limitation clearly to the user instead of retrying blindly.

Common Pitfalls

Inviting Members During Group Creation

If a bot creates a group and --users includes users who are mutually invisible to the bot, the entire request fails with 232043. Use two steps instead:

Create the group with the bot first, excluding invisible users: lark-cli im +chat-create --name "Group Name"
Add users later with a user-identity member-management flow

Insufficient Privileges

232016 / 232002 / 232017: the current identity is not the owner or an admin -> switch to the owner identity
232011: the current user is not in the group -> use a group-member identity, or join the group first
232024: the bot and the target user are mutually invisible -> switch to --as user

References

lark-im - all IM commands
lark-shared - authentication and global parameters

3.1 KiB Raw Blame History