DOCG7 治理文档事实源口径
这个提交包含在:
@@ -110,3 +110,4 @@ Final responses should include:
|
||||
- After AP6, approval reminder, overdue reminder, and workflow productivity summary are current product facts, not open planning items. Reuse `POST /api/workflow/tasks/:taskId/remind`, `GET /api/workflow/tasks/summary`, `job:workflow-overdue-reminders`, existing workflow history, audit logs, notifications, and WeCom personal app delivery semantics. Do not add a parallel reminder channel, change approval status from reminders, or expand into complex BPM/SLA escalation without a new Issue.
|
||||
- After DG7/MRF7, mobile approval is an "approval and progress" entry: employees may use it for submitted-item progress, while approvers use it for assigned tasks. Do not reintroduce disabled approval tabs for ordinary employees, duplicated home pending lists, or notification cards that only bounce users back to the notification center when a business target exists.
|
||||
- After RI6, LP6, ME6 automation, QG6, and R7/OPS7/DOC7 draft materials, keep `ME6-3` open until representative real-device testing passes or the user explicitly accepts that risk. R7 draft rows may be `DONE`, but `R7E-*` true execution rows must stay `TODO` until the user confirms participants, roles, window, rollback contact, issue owner, and daily closeout. Do not treat QG6 or public mobile visual automation as a real-device substitute, and do not start real R7 from documentation alone.
|
||||
- After DOCG7, document governance must start from `docs/文档索引.md` and `docs/文档事实源状态矩阵.md`. Use index archival: do not delete or move historical docs, do not rewrite old Issue CSV history, and resolve conflicts by latest Issue CSV plus current module specs before historical matrices or old runbooks.
|
||||
|
||||
在新工单中引用
屏蔽一个用户