补充安全权限日志与草稿状态约定

docs/contracts/状态流转约定.md

@@ -14,31 +14,41 @@
 
 | 状态 | 含义 |
 | --- | --- |
-| `PENDING_CONFIRM` | 草稿已整理完成，等待老板确认、修改、取消或转经理 |
-| `NEED_MANAGER_CONFIRM` | 老板已确认，但复杂任务需要程经理确认 |
-| `CONFIRMED` | 已人工确认，等待转换任务或提醒 |
-| `CONVERTED` | 已转换为事项或提醒 |
-| `CANCELLED` | 已取消 |
-| `FAILED` | AI 解析或草稿处理失败，仅用于调试追踪 |
+| `pending_confirmation` | 草稿已整理完成，等待老板确认、修改、取消或补充/重说 |
+| `awaiting_follow_up` | 老板已点击补充/重说，等待 30 分钟内下一条补充消息 |
+| `confirmed` | 已人工确认，等待转换为事项或提醒 |
+| `converted` | 已转换为事项或提醒；复杂事项已创建 `pending_manager_confirm` 事项壳也视为已转换 |
+| `cancelled` | 已取消 |
+| `answered` | 已直接回复或留痕，不进入事项、提醒或通知闭环 |
+| `superseded` | 已被补充/重说生成的新草稿替代 |
+| `expired` | 补充/重说等待超时，旧确认卡片不可继续使用 |
+| `parse_failed` | AI 解析或草稿处理失败，仅用于调试追踪 |
 
 允许流转：
 
 ```text
-PENDING_CONFIRM -> CONFIRMED
-PENDING_CONFIRM -> NEED_MANAGER_CONFIRM
-PENDING_CONFIRM -> CANCELLED
-PENDING_CONFIRM -> FAILED
-NEED_MANAGER_CONFIRM -> CONFIRMED
-CONFIRMED -> CONVERTED
-CONFIRMED -> FAILED
+pending_confirmation -> confirmed
+pending_confirmation -> awaiting_follow_up
+pending_confirmation -> cancelled
+pending_confirmation -> parse_failed
+awaiting_follow_up -> superseded
+awaiting_follow_up -> expired
+awaiting_follow_up -> cancelled
+confirmed -> converted
+confirmed -> parse_failed
 ```
 
 约束：
 
-1. `FAILED`、`CANCELLED`、`CONVERTED` 为终态。
-2. 未进入 `CONFIRMED` 的草稿不得转换。
-3. `need_more_info`、`answered`、`context_summary` 是非草稿处理结果，不落 `ai_drafts.status`。
-4. 多次补充/重说优先合并到同一个 `pending_draft`，直到老板确认、取消、过期或明确新建，不要求每次补充都新建草稿。
+1. `parse_failed`、`cancelled`、`converted`、`answered`、`superseded`、`expired` 为终态。
+2. 未进入 `confirmed` 的草稿不得转换。
+3. `note`、`unknown`、`qa`、`realtime_qa`、`need_more_info`、`unsupported` 不进入事项、提醒或通知闭环；如需留痕，只能使用 `answered` 或 `parse_failed`。
+4. 老板点击补充/重说后，原草稿进入 `awaiting_follow_up`，并使原确认卡片失效。
+5. 30 分钟内收到补充消息后，新草稿 `parent_draft_id` 指向原草稿，原草稿进入 `superseded`。
+6. 超过 30 分钟后，原草稿进入 `expired`，老板下一条消息按新输入处理。
+7. 飞书回调确认、取消、补充/重说前，必须校验回调来自 `active_card_notification_id` 对应的当前有效卡片。
+8. 复杂事项不使用草稿状态等待程经理确认；老板确认后应创建 `tasks.status=pending_manager_confirm` 的事项壳。
+9. `answered` 和 `parse_failed` 可以作为最小留痕草稿的初始终态，不参与确认和转换。
 
 ## 3. 事项状态
 
@@ -144,21 +154,28 @@ triggered -> expired
 | 状态 | 含义 |
 | --- | --- |
 | `pending` | 待发送 |
+| `sending` | 发送中 |
 | `sent` | 已发送 |
 | `failed` | 发送失败 |
 | `retrying` | 补发中 |
 | `cancelled` | 已取消 |
+| `expired` | 卡片或通知操作已过期 |
 
 允许流转：
 
 ```text
+pending -> sending
 pending -> sent
 pending -> failed
+sending -> sent
+sending -> failed
 failed -> retrying
 retrying -> sent
 retrying -> failed
 pending -> cancelled
 failed -> cancelled
+pending -> expired
+sent -> expired
 ```
 
 约束：
@@ -166,6 +183,8 @@ failed -> cancelled
 1. `sent` 不得重复发送同一通知。
 2. 补发必须保留原失败记录和新发送结果。
 3. 飞书通知必须使用幂等键。
+4. `expired`、`cancelled` 通知不得继续处理卡片确认、反馈或补充/重说。
+5. 被新卡片替代或业务取消时，必须写 `invalidated_at`。
 
 通知幂等键建议：
 
@@ -252,8 +271,10 @@ processing -> cancelled
 约束：
 
 1. 同一 `event_id` 只处理一次。
-2. 验签失败不得执行业务动作。
-3. 处理失败必须写失败记录。
+2. 如果飞书某类回调没有稳定 `event_id`，必须使用 `idempotency_key` 做事件幂等。
+3. 验签失败不得执行业务动作。
+4. 旧卡片、失效卡片、已替代草稿和已过期通知的回调只记录事件并标记 `ignored`，不得写业务对象。
+5. 处理失败必须写失败记录。
 
 ## 12. 用户和配置状态
 
@@ -295,5 +316,6 @@ Prompt 上下文状态：
 | `empty` | 当前没有可补充或可确认的草稿 |
 | `awaiting_more_info` | AI 已追问，等待老板补充 |
 | `awaiting_confirm` | 草稿已整理完成，等待老板确认、修改、取消或转经理 |
+| `awaiting_follow_up` | 老板点击补充/重说后，等待下一条消息修订上一版草稿 |
 | `expired` | 已过期 |
 | `cleared` | 草稿已确认、取消或转换完成，上下文已清空 |