docs: define decision center document numbering

2026-05-21 04:53:34 +00:00
parent 32d3517fa9
commit 44e1fb2613
2 changed files with 5 additions and 0 deletions
@@ -257,6 +257,9 @@ D601 上必须显式使用原生 k3s kubeconfig：`KUBECONFIG=/etc/rancher/k3s/k
 - 部署引用：后端源码位于 UniDesk 仓库 `src/components/microservices/decision-center`，Dockerfile 为 `src/components/microservices/decision-center/Dockerfile`；k3s manifest 为 `src/components/microservices/k3sctl-adapter/k3s/decision-center.k3s.json`，Kubernetes 运行清单为 `src/components/microservices/k3sctl-adapter/k3s/decision-center.k8s.yaml`，镜像名固定为 `unidesk-decision-center:d601`。dev 环境使用 `src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-decision-center.k8s.yaml` 和 `unidesk-dev-decision-center.k3s.json`，服务名为 `decision-center-dev`。主 server `docker-compose.yml` 不得加入该服务，也不得公开 `4277`。
 - 状态权威：Decision Center 必须写入主 PostgreSQL，权威记录表为 `decision_center_records`，日记表为 `decision_center_diary_entries`；不得使用浏览器 `localStorage`、IndexedDB、容器 writable layer 或本地 JSON 文件作为会议、决议、目标、问题或日记状态权威。D601 Pod 通过集群内 `d601-tcp-egress-gateway.unidesk.svc.cluster.local:15432` 访问主 PostgreSQL。
 - 记录数据模型：记录类型为 `meeting|decision|goal|external_goal|internal_goal|blocker|debt|experiment`，等级/优先级为 `G0|G1|G2|G3|P0|P1|P2|P3|none`，状态为 `active|blocked|parked|done`，字段包含 `title`、Markdown `summary/body`、`priority`/`level`、`source`、`issueId`、`linkedGoalId`、`tags`、`evidenceLinks`、`sourceSession`、`taskId`、`commitId`、`createdAt` 和 `updatedAt`。
+- 文书正规化：Decision Center 记录应逐步从松散需求记录升级为带文号的工程化文书系统，默认文号格式为 `DC-<TYPE>-<PRIORITY>-<YEAR>-<SEQ>`。`TYPE` 固定为 4 位英文缩写，当前保留 `DCSN` 决策/决议、`GOAL` 目标、`PLAN` 计划、`RPRT` 报告/态势评估、`ACTN` 行动项、`ISSU` 问题/阻塞、`RETR` 复盘、`RQST` 请示、`RESP` 批复/答复、`MINS` 纪要；`PRIORITY` 使用 `P0|P1|P2|P3`，G 级目标在文号中映射为 P 级紧迫度，其中 G0 默认映射 P0；`YEAR` 使用签发年份，`SEQ` 是同一 `TYPE+PRIORITY+YEAR` 下从 `001` 起递增的三位序号。示例：`DC-DCSN-P0-2026-001`、`DC-GOAL-P0-2026-001`。
+- 文书元数据：正式产品化后，记录模型必须显式保存 `docNo`、`docType`、`docPriority`、`docSeq`、`signer`、`issuedAt`、`effectiveScope`、`supersedes` 和 `supersededBy` 等字段，并为 `docNo` 建立唯一约束；在 schema 完成前，临时过渡可以把文号写入 `title` 前缀、`tags` 和 Markdown `body` 首段，但不得把临时正文约定当作长期数据模型。
+- 文书流转：正式文书应支持 `draft` 草拟、`review` 核稿、`issued` 已签发、`active` 执行中、`done` 办结、`void` 作废等状态或等价状态映射；Agent 可以起草、核稿和生成报告，但涉及战略优先级、外部目标和长期约束的 `DCSN`/`GOAL` 文书必须由用户签发后才进入已签发序列。编号一经签发不得复用，作废也必须保留编号和替代关系。
 - 需求管理：Decision Center 里的 `external_goal` 记录应承接外部需求或外部目标，`internal_goal`/`goal` 记录应承接拆解后的内部目标，`decision` 记录应承接需求分解后的取舍，`blocker` 记录应承接当前阻塞，`experiment` 记录应承接验证性工作，`debt` 记录应承接必须偿还的技术/流程债。任何新需求都应先写成可验证的外部收益，再分解为这些内部记录，而不是先发散成内部审美或架构偏好。需求管理 API 复用 `decision_center_records`，`/api/requirements` 在同一模型上排除 `meeting`，并提供 list/create/show/update/upsert 的需求语义入口，不引入第二套需求表。
 - 日记数据模型：基于 Markdown 的日记系统以“每天一篇”为最小单元，导入器识别 `# YYYY年M月D日`、`# YYYY-MM-DD` 或 `# YYYY/M/D` 标题并拆分为 `entry_date`、`month`、Markdown `body`、`source_file`、`content_hash` 与虚拟 `markdown_path=YYYY-MM/YYYY-MM-DD.md`；同一 `source_file + entry_date` 使用 upsert，内容未变时保持幂等。
 - 日记编辑：工作日记必须支持按真实日期创建当天条目，并支持按日期回看和编辑历史条目；`GET /api/diary/today` 按服务当前真实日期自动创建或返回当天条目，`PUT /api/diary/today` 保存当天 Markdown，`PUT /api/diary/entries/:idOrDate` 允许安全更新 `body`/`markdown`、`title`、`tags` 和 `sourceFile`，按 `YYYY-MM-DD` key 且不存在时创建当天或历史条目，按非日期 id 时只编辑既有条目。数据库仍是唯一权威，前端只是编辑入口和展示入口。