项目管理制度（Project Management - PJM）¶

文档编号：DOC-A05 / PJM 版本：V3.3 创建日期：2026-08-04 最近更新：2026-08-21 维护人：SPO / DT 关联文档：PMG、RQD、GLY、WLG、DIP1子项目索引、DIP1-IMP §十反馈处理确认状态机、听云工作手册 OCM、听云工作目录 ocm/

一、项目概述¶

1.1 基本信息¶

项	内容
项目名称	香港配送+安装互联网平台 (HKDIP)
运营主体	织布鸟智居科技有限公司（WEAVELY TECHNOLOGIES LIMITED）
品牌	织布鸟 WEAVELY
Slogan	用心编织你的理想家居
当前阶段	筹备期前期

1.2 平台服务架构¶

服务	编号	定位	状态
QSV 报价服务	DOC-P31	定价引擎，多维动态报价	设计完成 V1.1
CPT 客户项目跟踪服务	DOC-P41	全生命周期信息采集	设计完成 V2.4
MDS 主数据服务	DOC-P51	主体档案中心，六库主数据供给	设计完成 V1.2
OPS 运营服务	DOC-P61	获客与增长引擎，B 端合作	设计完成 V1.1
DIS 派单服务	DOC-P71	物流派单决策引擎，三模式+保险策略+人工调整	设计完成 V1.0（V8.0 阶段一新增）

服务关系：MDS 为主数据底座（六库：SCL/BPL/WPL/CPL/PPL/DLV），供给 QSV/CPT/OPS/DIS；CPT 为数据主线，采集全过程数据反哺 QSV 校准与 MDS 画像更新；DIS 承接 CPT L5 阶段派单触发，消费 DLV 主数据执行派单决策，下发 LGP 司机端；OPS 为获客入口，消费 MDS 画像驱动口碑营销，与 CPT 形成 L1 获客→L8 口碑触发闭环。

详细服务设计见各服务子目录，业务需求见 RQD。

1.3 品牌视觉规范¶

品牌色	色值	用途
深墨绿	HEX #004046	主色
浅沙金	HEX #D4AF78	辅色
米白浅灰	HEX #F2F0EB	背景色

二、管理制度¶

2.1 目标管理¶

项目遵循「战略目标 → 阶段里程碑 → 月度目标 → 周任务」的逐级分解：

层级	周期	制定人	示例
战略目标	全周期	SPO	市场份额 >15%
阶段里程碑	每阶段	BO	MVP 报价引擎上线
月度目标	每月	各角色	完成报价模型设计
周任务	每周	各成员	完成基础费率表

2.2 任务管理¶

「分配 → 跟踪 → 闭环」三步法：明确负责人、截止时间、验收标准；阻塞项 24 小时内上报；闭环后记入 WLG。

2.3 进度管理¶

周报：每周五 BO 汇总
里程碑评审：每个阶段前召开
进度偏差：延期超 1 周须提交说明
DIP1 子项目独立进度跟踪（独立 Code Agent 承接阶段 2 原生 App 方案，跳过阶段 1 飞书对接）：
按 dip1/docs/DIP1-IMP-Code-Agent实施指南.md §7「DIP1 状态追踪」三张红黄绿矩阵执行
状态三色标准：🟢（≥90% 无 Critical 阻塞）/ 🟡（30-89% 或 Major 阻塞有方案）/ 🔴（<30% 或 Critical 阻塞 72h）
SPO/BO/TL 无需进入 DIP1 代码或 hk2026 主仓其他业务文档，直接查阅 DIP1-IMP §7 三张表即可评估子项目状态（文档 10/10 🟢 V2.0 已完成 10%；代码 105 人天/部署/UAT 待执行）

2.4 风险管理¶

风险	应对策略	负责角色
数据安全（客户/师傅信息泄露）	权限管控，AI 不外泄敏感数据	TL
法规风险（行业监管趋严）	主动合规，合同规范，保险完备	FL
交付风险（服务质量不达标）	师傅分层、质检体系、客户评价	OL

完整业务风险见 RQD §3.4。

2.5 变更管理¶

变更类型	审批人	记录要求
报价模型参数调整	SPO + BO	更新 QMD，记入 WLG
跟踪流程调整	SPO + OL	更新 CPT，记入 WLG
业务模式调整	SPO	评审会决议，更新 RQD
技术架构变更	TL + SPO	更新 TND
文档规范变更	DT	更新本文件

变更流程：提出 → 评估影响 → 审批 → 执行 → 验证 → 归档。

2.6 质量管理¶

文档质量：正式文档须经评审；DT 负责质量把关
流程图规范：所有流程图统一使用 Mermaid 语法，中文节点名采用 id["中文标签"] 格式（见 §5）
服务质量：师傅分层系统、客户评价机制、神秘客抽检
质检指标：成交率、客诉率、按时完成率、好评率

2.7 决策机制¶

决策层级	决策内容	决策人
战略级	方向、预算、核心合作	SPO
业务级	报价参数、合作条款	BO（重大报 SPO）
执行级	日常任务、技术实现	对应角色

2.8 汇报机制¶

汇报	频率	对象
每日站会	每日	核心角色
周报	每周	全体
月度复盘	每月	SPO + 核心角色
阶段评审	每阶段	SPO + 相关角色

三、团队角色与权责（RACI）¶

3.1 角色缩写速查¶

角色	简称	现任人员	RACI 角色
项目发起人	SPO	曾总	A（决策审批）
业务负责人	BO	洪哥	R（负责执行）
产品负责人	PO	郭总	R（产品设计）
技术负责人	TL	司徒总	R（技术架构）
运营负责人	OL	成文（客户运营）/ 黄总（落地执行）	R（运营执行）
市场负责人	ML	洪哥	R（市场推广）
财务/法务	FL	（待定）	R（合规财务）
听写（Dictation）	DT	AI 文档智能体	辅助建议（负责其他全面）
听码（Weaver Dev Engine）	WDE	AI 代码开发智能体	辅助建议（只做编码）
听云（Weaver Cloud Listener）	OCM	AI 生产运维智能体	辅助建议（只做生产运维）

人员称呼对照表，其它文档原则上不写完整姓名，而是直接用简称称呼 对照表：曾总-广，郭总-郭，司徒总-司徒，成文-成文，黄总-黄，洪哥-洪。
AI 智能体分工（V3.0 对齐 PMG V8.0）：听写（DT）负责其他全面——Gitee 仓库管理、文档发布、项目管理、设计、用户测试（兼文档撰写），工作目录 docs/ 与仓库根；听码（WDE）只做编码，依据听写提供的设计文档对本地代码进行操作，工作目录 dip1/（目前是 dip1），不接触生产环境、不接触 Gitee 远程仓库；听云（OCM）只做生产环境部署、第三方集成、客服等，工作目录 ocm/（原 ops/→ocm/）。三者职责隔离，互不越权，详见 PMG §人机协作模型 + §双轨交付机制 + §日志体系。

现任人员对应基于 2026-08-05 核心运营团队内部讨论确认，详见 WLG 线下讨论。BO/FL 待后续确认。

3.2 RACI 矩阵¶

职责	SPO	BO	PO	TL	OL	ML	FL	MFR	LGP
战略方向	A/R	C	C	C	C	C	C	I	I
业务模式与报价	A	R	C	C	C	I	C	C	C
平台产品设计	I	C	R	C	C	I	I	C	C
系统架构与开发	I	I	C	R	I	I	I	I	I
师傅招募与培训	I	C	I	I	R	I	C	I	I
合作方拓展	A	R	I	I	C	C	C	R	R
MFR 生产商管理	A	R	C	I	C	C	C	R	I
LGP 物流商管理	A	R	C	C	R	I	C	I	R
跨境合规管理	A	C	I	C	C	I	R	I	C
内容与推广	I	C	I	I	C	R	I	I	I
合同/合规	A	C	I	I	C	I	R	C	C
文档与工作日志	I	C	C	C	C	C	C	I	I

MFR/LGP 干系方说明（V2.8 新增）： - MFR 家居产品生产商：B 端客户角色，通过织布鸟平台委托物流配送+安装服务，终端为 Web 端 - LGP 物流配送服务商：物流执行方角色，承接平台派单的配送任务，终端为 App 端 - 两者均为外部合作方，不参与项目内部决策，但需在 RACI 中明确其与平台的协作关系

3.3 角色核心职责¶

角色	核心职责
SPO	战略决策、资源投入、关键合作拍板
BO	业务模式、场景落地、合作拓展、报价校准
PO	平台设计、需求管理、产品路线图
TL	架构选型、技术实现、API 对接
OL	师傅招募培训、SOP、质检、售后。双人分工：成文负责客户运营（前端业务执行、客户跟进、信息同步）；黄总负责落地执行（风险把控、关键节点、作业规范 SOP）
ML	内容矩阵、社交媒体、推广、品牌合作
FL	商业登记、保险、合同、对账、合规

3.4 DIP1 独立技术开发子项目管理¶

定位：DIP1 = 织布鸟 WEAVELY 香港配送+安装平台 阶段 2（一线操作系统·原生 App 方案） 的独立代码实施子项目，承接自 TND-E（技术平台演进方案） §3「阶段划分」。 V2.5 重大变更：原方案「阶段 1（飞书工作台对接）+ 阶段 2」调整为 「跳过阶段 1，直接实施阶段 2 原生 App 方案」（依据 DIP1-ARC V2.0 ADR-008）： - 师傅端从 Next.js PWA → React Native（wkr-app） - 新增客户端 App React Native（cst-app） - 后端模块化单体保留，新增 CST 限界上下文 + 移动认证 + 推送服务 - 技术栈：Expo managed workflow + EAS Build/Submit/Update + NativeWind - 工作量：85 人天 → 105 人天（+20：新增 CST + 移动基建 - 飞书对接） - 阶段 1 飞书对接文档（DIP1-02 P1）保留为「⏸ 暂不实施」，未来视飞书方案运行情况再启动位置：与主项目同一 Git 仓库（hk2026 私有主仓），代码与文档全部位于 dip1/ 子目录内（代码 dip1/backend|frontend|scripts，文档 dip1/docs/ 10 份自包含，工作日志 dip1/docs/worklog/，脱离主仓其他文档即可实施）；发布文档与本项目共用根目录 发布/。

3.4.1 子项目关系图（与 hk2026 项目的对接边界）¶

graph TD
    H["🗂 hk2026 项目根（同一 Git 私有仓 dev 分支）"]
    H --> P1["项目文档（RQD/GLY/WLG/ARC/发布/... 已存在）"]
    H --> DIP1["🧩 DIP1 子项目（独立 Code Agent 执行）"]

    DIP1 --> D_CODE["代码区 dip1/backend|frontend|scripts（纳入 git，暂不纳入发布 PDF）<br/>后端 DDD 4 层 / 前端 Monorepo（opr-admin Web + wkr-app RN + cst-app RN）/ scripts / tests / alembic / openapi.yaml"]
    DIP1 --> D_DOC["文档区 dip1/docs/（纳入 git，纳入发布 PDF）<br/>10 份自包含文档 V2.0 + worklog/ 工作日志<br/>README × 2 / ARC V2.0 / P1 V1.1 ⏸ / P2 V2.0 / P3 V1.1 / SPEC V2.0 / PROTO V2.0 / API V2.0 / SCHEMA V2.0 / IMP V2.0 / Alembic 0001+0002"]

    D_CODE -.->|"⏸ 阶段 1 暂不实施"| F1["飞书多维表格（MVP-FS 已在用）<br/>P1 双轨同步层保留待未来启动"]
    D_CODE -->|"交付数据"| F2["PostgreSQL 16 RDS（生产香港双 AZ）<br/>主仓 22 表 + 30 枚举 + 5 条 RLS 行级策略（V2.0 新增 4 表：CST/移动会话/推送设备/推送记录）"]
    D_CODE -->|"部署"| F3["阿里云香港 ECS + RDS PG + Cloudflare R2 + Pages<br/>（生产凭据：TL 独立保管，Code Agent 不持有）"]
    D_CODE -->|"跟踪"| P1
    D_DOC -->|"登记导航"| P1N["AGENTS.md（TND 技术文档区块：DIP1 12 条目）"]
    D_DOC -->|"发布成品"| PUB["根目录 发布/<br/>AI 特定行为 #1 合并 10 份 DIP1 文档为 PDF 供评审"]
    D_DOC -->|"工作日志<br/>（Code Agent 写入）"| DWLG["dip1/docs/worklog/<br/>DWLG-YYYYMMDD-NN 编号"]
    DWLG -->|"TL 审核关键节点<br/>同步至主仓"| WLG["docs/工作日志/ + DLG-xx<br/>（Code Agent 严禁修改）"]

    %% 关键干系方（RACI 对齐 §3.1 + 独立 Code Agent 角色）
    SP["👤 SPO（曾总）"]  -->|"状态评估🔴🟡🟢 里程碑审批"| DIP1
    BO2["👤 BO（郭总）"] -->|"报价/业务规则/奖励审批"| D_DOC
    TL2["👤 TL（司徒总）"] -->|"全量技术：架构/代码/部署/RBAC"| D_CODE
    CA["🤖 DIP1 Code Agent（独立）"] -->|"按 DIP1-IMP 指南 100% 实施代码<br/>Git 提交/推送由 TL 执行，Agent 不持有 git push 权限"| D_CODE

3.4.2 RACI 对齐（独立角色）¶

本项目 §3.1 RACI 原有 7 角色（SPO/BO/PO/TL/OL/ML/FL）与 DIP1 子项目新增 1 角色「DIP1 Code Agent」对接表：

任务	SPO	BO	PO	TL	OL	ML	FL	DIP1 Code Agent
架构决策（13 ADR）	I	C	C	R/A	I	I	I	R
DIP1 10 份自有文档创建	I	C	C	A	I	I	I	R
QMD/QSV 报价参数维护	I	R/A	C	C	I	I	I	I
RBAC 权限与 RLS 策略	I	C	C	R/A	C	I	I	R 实现代码
CPT 8 阶段状态机代码	I	C	C	A	C	I	C	R
飞书对接 P1（阶段 1）⏸ 暂不实施	I	I	C	A	C	I	I	❌ 跳过（ADR-008）
~~数据迁移：MVP-FS → PG~~ ⏸	I	C	I	R/A	C	I	I	❌ 跳过
移动端 RN 开发（wkr-app + cst-app）	I	C	C	R/A	C	I	I	R
CST 客户端限界上下文 + 移动认证 + 推送	I	C	C	R/A	C	I	I	R
生产凭据保管（飞书/ECS/R2/RDS/App Store/Google Play）	I	I	I	R 唯一持有	I	I	I	❌ 不持有
Git Commit / Push / 同步（PJM §4.3.6）	I	I	I	R	I	I	I	❌ 严格禁止（Agent 仅写本地文件）
DIP1 文档合并 PDF 发布（AI 特定行为 #1）	A	C	I	C	I	I	I	I（由听写助手触发）
105 人天代码自测（一级 Checklist 6.1）	I	I	I	C	I	I	I	R
TL 功能验收（二级 6.2）	I	C	C	R	I	I	I	C
OL UAT（三级 6.3 50 单）	I	C	I	A	R	I	C	I
子项目里程碑跟踪矩阵 §7.1	R 按周	C 报价异常	I	A 日常	I	I	I	C 实现代码提交证据

R=执行 / A=审批（Accountable，最终对结果唯一负责）/ C=咨询（被 Consult 提供输入）/ I=知情（被 Inform）。

文档自主权原则（V2.7 新增，对齐听云 OCM 工作手册 V1.2 + 听码 DIP1-IMP V2.1）：上表中"DIP1 10 份自有文档创建"行的 A=TL 指内容正确性审批，非文件结构审批。听码（WDE）自主决定 dip1/docs/ 下的文档结构（文件清单/命名/组织方式/拆分合并），无需人类逐项审批文件结构。核心理念：人类只在职责层面定义边界，AI 协作者自主决定其工作目录下的文档结构。听云（OCM）对 ocm/ 工作目录享有同等文档自主权（详见 §3.5.1）。

3.4.3 交付物跟踪矩阵（SPO/BO 直接查看 DIP1-IMP §7.1）¶

DIP1 子项目提供一张独立于主仓业务文档的唯一真值跟踪表，位于：

👉 dip1/docs/DIP1-IMP-Code-Agent实施指南.md §7.1「DIP1 交付物状态跟踪矩阵」
矩阵分 3 组 × 24 项：
文档 10 份（D-01~D-10，V2.0 已全部 🟢）：子项目入口/DOC 索引/ARC 架构 V2.0/P1 飞书对接 V1.1 ⏸/P2 一线操作系统 V2.0/P3 技术基础设施 V1.1/SPEC V2.0 193+ 功能需求/PROTO V2.0 OPR Web+WKR RN+CST RN 原型/API V2.0 OpenAPI YAML 65 operationId/SCHEMA V2.0 22 表 30 枚举 + Alembic 0001+0002 脚本
代码 9 人天（§0 环境基建）+ 49 人天（§2 后端业务）+ 32 人天（§3 前端 OPR+WKR RN+CST RN）+ 5 人天（§3 移动端基建）+ 10 人天（§4 部署/UAT）= 105 人天（C-00~C-13，当前 0% 🟡 待执行）
部署/UAT/发布（DPL-01~04，当前 0% 🟡 待执行）：EAS Build 双端 4 artifact / App Store + Google Play 提审 / OTA 热更新 / 香港双 AZ 蓝绿部署 / OL UAT 50 单 / 10 份文档 PDF 发布
加权完成度：文档 10%（权重 10%）· 代码 105 人天（权重 60%）· 部署/UAT/发布（权重 30%）；当前 = 10%（文档 10/10 🟢 已交付 V2.0，Code Agent 代码待启动）
状态更新频率：
文档版本：Code Agent 在 PR 中标注建议版本号；正式版本 + WLG 记录由 TL/听写助手执行（Agent 不直接改 WLG 或版本号）
代码里程碑：每 merge 到 dev → TL 运行 make ci-local 截图 → 更新矩阵红黄绿
部署 / UAT：里程碑节点（V1.0 tag）→ SPO 审批发布

3.4.4 升级与越权防护机制¶

禁止越权：DIP1 Code Agent 严禁执行 PJM §4.3.2 之后的 Git Commit/Push/Publish/公开同步动作（即使 Agent 具备工具也必须严格遵循 PMG AGENTS.md AI 特定行为 #3/#4：仅在用户明确指令时执行，不可自行触发）
问题升级路径：阻塞 24h → Issue（严格 DIP1-IMP §8 模板）→ TL 24h 答复 → BO 48h 业务规则裁决 → SPO 架构/预算最终决策（与 DIP1-IMP §7.3 完全对齐）
文档版本回溯：DIP1 文档的所有版本变更，必须同步 WLG（工作日志）DLG 编号；Code Agent 仅提交 PR 描述建议版本号，真正的 WLG 登记由听写助手/TL 执行，保证 PJM §2.5 变更管理合规

3.4.5 工作日志机制（双层 WLG · 对齐主仓 §三/§四记录规范）¶

DIP1 子项目采用双层工作日志机制，既保证 Code Agent 开发过程可追溯，又严格隔离主仓 WLG 写入权限：

层级	位置	写入者	编号体系	用途
子项目层	`dip1/docs/worklog/`	DIP1 Code Agent（✅ 可读可写）	`DWLG-YYYYMMDD-NN`	细粒度记录：每个功能点/PR/Issue/技术决策
主仓层	`docs/工作日志/对话记录/`	TL / 听写助手（Code Agent ❌ 严禁修改）	`DLG-NN`（主仓统一编号）	粗粒度记录：里程碑达成/阶段完成/重大决策

TL 同步触发条件（6 种场景，由 TL 审核子项目层日志后执行主仓层同步）：

同步触发条件	主仓 WLG 编号	同步内容
§0 环境基建（9 人天）完成	DLG-xx	Expo/EAS 工具链 + Monorepo 调整 + docker compose + 种子脚本
§2 后端业务（49 人天）完成	DLG-xx	5+1 大子域（含 CST）+ 65 REST API + Alembic 0001+0002 迁移 + RBAC + 移动认证 + 推送服务
§3 前端 OPR Web（15 人天）完成	DLG-xx	OPR 后台 15+ 页面 + 前后端联调
§3 前端 WKR RN + CST RN（27 人天）完成	DLG-xx	wkr-app + cst-app RN 8+8 页面 + 原生模块（相机/推送/离线）+ 前后端联调
§3 移动端基建（5 人天）完成	DLG-xx	EAS Build 4 artifact + App Store/Google Play 提审 + OTA 热更新配置
UAT 50 单验收完成	DLG-xx	UAT 报告 + 三级 Checklist 全绿
重大 Issue 升级（Critical 72h）	DLG-xx	问题根因 + 影响 + 决策
生产发布 V2.0	DLG-xx	发布报告 + 蓝绿切换 + RPO/RTO 验证 + App 上架

完整规范：DIP1 子项目工作日志的编号体系、记录要素、模板、整理要求详见 dip1/docs/worklog/README.md（DIP1-WLG V1.0），对齐主仓 WLG §三记录规范 + §四整理要求。Code Agent 实施指南详见 DIP1-IMP §九。

3.5 听云（OCM）生产运维管理¶

定位：听云（Weaver Cloud Listener，OCM）是本项目全部子项目的生产环境运维与客服统一入口，承担生产环境部署、监控、故障排查、外部服务集成、客服工单处理等工作。听云与听码（WDE）职责严格隔离：听码负责代码开发（dip1/），听云负责生产运维（ocm/），两者协作通过 Issue + OCL/DWLG 双轨留痕。 工作目录：根目录 ocm/（生产运营文档区），分为 public/（可公开发布）+ private/（不可公开发布，含密钥/账号）+ worklog/（工作日志 OCL-YYYYMMDD-NN）三层结构。详见听云工作目录索引 + 听云工作手册。 适用范围：本项目全部子项目（DIP1 / 未来 DIP2 / DIP3 / …）的生产环境运维工作统一由听云承接，不限于单一子项目。

3.5.1 听云与听码的职责边界¶

维度	听码（WDE）	听云（OCM）
主要职责	代码编写、审查、调试、Bug 修复	生产环境部署、运维、监控、客服
工作目录	`dip1/`（代码 + 技术文档）	`ocm/`（运维文档 + 工作日志）
工作日志编号	`DWLG-YYYYMMDD-NN`	`OCL-YYYYMMDD-NN`
Git 权限	❌ 严禁 commit/push，仅写本地文件	❌ 严禁 commit/push，仅写本地文件
生产凭据	❌ 零持有	❌ 零持有（凭据由 TL 唯一保管）
生产环境操作	❌ 不参与	✅ 在 TL 授权下执行部署/回滚/扩容
代码修改	✅ 主要执行者	❌ 不修改业务代码（仅配置/环境变量）
客服工单	❌ 不参与	✅ 承接并处理
外部服务集成	❌ 不参与	✅ WhatsApp/R2/Push 等对接配置
文档自主权（V2.7 新增）	✅ 自主决定 `dip1/docs/` 下文档结构（文件清单/命名/组织方式/拆分合并），无需人类逐项审批文件结构	✅ 自主决定 `ocm/` 下文档结构（含 `admin-manual/`、`service-manual/`、`private/credentials/` 等目录内文件），无需人类逐项审批文件结构

协作原则：听码交付代码 → TL 审核 + 合并 → 听云在 TL 授权下部署生产 → 听云监控运行状态 → 发现问题通过 Issue 反馈给听码修复。三者形成「开发 → 部署 → 运维」闭环。

3.5.2 RACI 对齐（听云在生产运维中的角色）¶

任务	SPO	BO	TL	OL	WDE（听码）	OCM（听云）
生产环境部署（首次/迭代）	I	I	R/A	I	C（提供部署包）	R
生产环境监控与告警响应	I	I	A	I	I	R
生产故障排查与修复	I	C	A	I	C（代码层修复）	R（运维层修复）
外部服务集成（WhatsApp/R2/Push）	I	C	R/A	I	I	R
生产凭据保管	I	I	R 唯一持有	I	❌	❌
客服工单处理	I	C	I	C	I	R
运维文档编写（操作手册/部署报告）	I	I	A	I	I	R
工作目录文档结构自主决策（V2.7 新增）	I	I	A 内容评审	I	R 自主决策	R 自主决策
运维文档公开/私有可能性判定	I	I	A	I	I	R 建议
OCL 工作日志记录	I	I	C	I	I	R
Git Commit / Push（运维文档）	I	I	R	I	❌	❌

R=执行 / A=审批（Accountable）/ C=咨询 / I=知情。听云与听码同样严禁 Git Commit/Push，所有变更由 TL 审核后统一提交。

文档自主权原则（V2.7 新增）：上表"工作目录文档结构自主决策"行的 A=TL 指内容正确性评审，非文件结构审批。听云（OCM）自主决定 ocm/ 下各目录（admin-manual/、service-manual/、private/credentials/ 等）内的文件清单与组织方式；听码（WDE）自主决定 dip1/docs/ 下的文件清单与组织方式。核心理念：人类只在职责层面定义边界，AI 协作者自主决定其工作目录下的文档结构，实现人类干预最小化。详见听云工作手册 §二文档自主权原则 + 听码实施指南 §一文档自主权。

3.5.3 工作日志机制（OCL · 对齐主仓 WLG §三/§四）¶

听云采用双层工作日志机制，与 DIP1 听码的 DWLG 机制同构复用：

层级	位置	写入者	编号体系	用途
运维层	`ocm/worklog/`	听云（OCM）（✅ 可读可写）	`OCL-YYYYMMDD-NN`	细粒度记录：每次部署/故障/集成/工单
主仓层	`docs/工作日志/对话记录/`	TL / 听写（OCM ❌ 严禁修改）	`DLG-NN`（主仓统一编号）	粗粒度记录：里程碑达成/重大故障复盘

TL 同步触发条件（听云运维日志同步至主仓 WLG）：

同步触发条件	主仓 WLG 编号	同步内容
子项目首次生产部署完成	DLG-xx	部署报告 + 健康检查通过 + 服务上线
生产环境重大故障（P0/P1）	DLG-xx	根因 + 影响 + 修复措施 + 复盘
外部服务集成完成（WhatsApp/R2 等）	DLG-xx	集成方案 + 验证结果 + 配置变更
月度运维简报	DLG-xx	上月可用性/告警数/工单数/SLA 达成
Critical 故障升级闭环	DLG-xx	根因 + 整改 + 预防手段

完整规范：听云工作日志的编号体系、记录要素、模板、整理要求详见 ocm/worklog/README.md（OCL V1.0），对齐主仓 WLG §三记录规范 + §四整理要求。

3.5.4 文档公开/私有划分原则¶

ocm/ 目录下的文档按是否含敏感信息分为两类，听云在创建文档时须严格判定：

分类	位置	判定标准	同步公开仓	示例
可公开	`ocm/public/`	不含密钥、账号、密码、Token、内部 IP、部署细节	✅ 同步	操作手册（通用）、架构说明、集成指南（脱敏后）
不可公开	`ocm/private/`	含密钥、账号、密码、Token、内部 IP、部署细节、客户数据	❌ 不同步	部署完成报告、环境变量配置、上线准备清单

判定红线：凡文档中出现以下内容之一，必须放入 ocm/private/： 1. 真实密钥/Token/密码（JWT_SECRET、API_KEY、数据库密码等） 2. 真实账号信息（管理员账号、服务账号） 3. 内部网络拓扑/IP 地址 4. 部署过程的详细步骤（可被用于攻击） 5. 客户/师傅隐私数据

听云在每次创建文档时主动判定，并在文档头部标注「⚠️ 私有文档，不同步公开仓」或「✅ 可公开文档」。

3.5.5 升级与越权防护机制¶

禁止越权：听云严禁执行 Git Commit/Push/Publish/公开同步动作（与听码一致，遵循 PMG AGENTS.md AI 特定行为 #3/#4）
生产操作授权：听云在生产环境的任何破坏性操作（部署/回滚/扩容/删除数据）必须经 TL 明确授权后方可执行，禁止自行触发
问题升级路径：生产故障 P0 → 立即飞书告警 TL → TL 4h 响应 → BO/SPO 重大故障决策；P1 → Issue + OCL → TL 24h 响应
与听码协作：生产问题如涉及代码缺陷，听云在 Issue 中 @听码（通过 TL 转发），听码修复后提交 PR，听云在 TL 授权下重新部署

四、协作机制¶

4.1 沟通渠道¶

渠道	用途	记录要求
线下会议	战略决策、方案评审	24h 内整理至 WLG
微信	日常沟通、即时协调	重要决策当日整理至 WLG
AI 助手对话	文档撰写、方案起草	整理至 WLG

4.2 会议机制¶

会议	频率	参与人
项目周会	每周	全体核心角色
方案评审会	按需	相关角色 + SPO
每日站会	试运营起每日	BO/PO/TL/OL

4.3 版本管理与 Git¶

本项目所有代码与文档的版本管理、分支协作、仓库发布与公开同步规则，统一由本节维护，是团队 Git 操作的唯一权威依据。

4.3.1 仓库清单¶

所有仓库统一托管于 Gitee 码云（中国境内，国内访问稳定），按职能仅保留唯一私有主仓；文档对外公开发布不再经过 Gitee 公开仓，改为 hk2026 私有主仓 → Cloudflare Pages 直连部署（链路重构 V3.3）：

仓库/系统	地址 / 标识	可见性	定位	维护人
主仓库 hk2026	`https://gitee.com/atonio/hk2026`	私有	项目主仓库：docs/ 源文件、ref/ 参考资料、scripts/ 运维工具、AGENTS.md、发布/ 成品、DIP1 技术开发子项目（同仓子目录 dip1/）、生产运营文档区（同仓子目录 ocm/，听云 OCM 工作目录）；MkDocs 站点构建与 Cloudflare Pages 部署的唯一源代码来源（AI特定行为#4 从本仓本地构建后直传 Pages，不再经过 Gitee 公开仓）	TL / DT
~~公开文档镜像 hk2026-docs~~	~~https://gitee.com/atonio/hk2026-docs~~	⚠ 已废除/不再使用（仅废除 Gitee 这个公开 Git 仓）	历史 Gitee 公开只读镜像仓已关停，所有与 hk2026-docs 这个 Gitee Git 仓相关的 Git clone / push / sync / checkout / scripts/sync-docs-repo.ps1 调用全部永久取消。MkDocs 构建 + Cloudflare Pages 发布流程不受影响，但链路不再经过该仓（改为 hk2026 私有主仓 → Pages 直连，见下表与 §4.3.7）。scripts/sync-docs-repo.ps1 物理保留仅作历史归档。	❌ 禁止使用
Cloudflare Pages 文档站点	Project = `hk2026`；生产域名 `https://hk2026.pages.dev`；预览域名 `<branch-hash>.hk2026.pages.dev`	公开（互联网任意访问）	MkDocs Material 在线文档站点唯一对外发布通道（V3.3 链路重构：从「hk2026→hk2026-docs→Pages」→「hk2026→Pages」直连）；构建：`scripts/build-site.py` + `mkdocs.yml`；部署：`scripts/deploy-site.ps1 -ProjectName hk2026` + `wrangler pages deploy`；覆盖：docs/ + 发布/ + ocm/public/（不含私有内容）+ DIP1 公开文档	TL / DT

职能划分：主仓库 hk2026 = 私有工作区（含敏感内容与原始资料）+ MkDocs 构建源；~~Gitee 公开镜像仓 hk2026-docs 已废除~~；Cloudflare Pages = 对外只读窗口（不再接受直接提交，所有修改在 hk2026 主仓完成后执行 AI 特定行为#4 文档公开发布 → 本地构建 + 直传部署）。

⚠ V3.3 双轨交付机制 + 文档公开发布链路重构（2026-08-22 用户澄清）： - Gitee hk2026-docs 🔴 仅废除 Gitee 平台上这个公开 Git 仓：即所有 Git clone/push/sync/checkout/scripts/sync-docs-repo.ps1 调用全部永久取消；scripts/sync-docs-repo.ps1 物理保留仅作历史归档；MkDocs + Cloudflare Pages 流程不废除、继续使用（用户澄清原话） - Cloudflare Pages Project 参数从 hk2026-docs 改为 hk2026：对应生产域名从 https://hk2026-docs.pages.dev 改为 https://hk2026.pages.dev；scripts/deploy-site.ps1 默认 ProjectName 从 hk2026-docs → hk2026 - Gitee hk2026 ✅ 继续使用，但定位收窄：只作为团队协作的源代码仓库（含 dip1/ 代码 + ocm/ 运维 + docs/ 文档源），不再承担生产部署职责，同时也是 MkDocs 构建的唯一源代码来源 - 双轨交付路径：听码在 dip1/ 本地完成编码 → 听写打包代码包 → 听写 push 到 hk2026（备份）+ 听写通过 scp/rsync 推送代码包到听云本地暂存区 → 听云部署到阿里云生产环境 - 文档公开发布路径（V3.3 新增链路）：hk2026 私有主仓 → 听写本地执行 scripts/build-site.py（MkDocs 构建）→ 执行 scripts/deploy-site.ps1 -ProjectName hk2026（wrangler 直传 Cloudflare Pages）→ 生产域名 https://hk2026.pages.dev，完全跳过 Gitee hk2026-docs 中间仓 - 听云与 Gitee 无关：听云从听写处通过 scp/rsync 接收代码包，部署至阿里云；听云不直接克隆或推送 Gitee 仓库 - 听码与 Gitee 无关：听码只对本地代码进行操作，不执行 git push / git pull 远程操作（与 §3.4.2 RACI 表「DIP1 Code Agent 不持有 git push 权限」一致） - 详见 PMG §双轨交付机制 + PMG §AI特定行为第4条（文档公开发布）

ocm/ 目录说明（V2.6 新增，V2.9 路径更新）：ocm/ 为听云（OCM）工作目录，承担本项目全部子项目的生产环境运维文档管理。分为 public/（可公开，同步至公开仓）+ private/（不可公开，含密钥/账号，不同步）+ worklog/（OCL 工作日志）。详见 §3.5 听云生产运维管理 + ocm/README.md。

DIP1 子项目说明（V2.5 更新）：DIP1 阶段 2 原生 App 方案代码与文档不另建 Git 子仓库，全部纳入主仓库 hk2026，遵守同一 Git 分支策略（§4.3.2）、提交规范（§4.3.3）、归档机制（§4.4）。 - 代码目录：dip1/（后端 Python FastAPI + 前端 Monorepo：opr-admin Web + wkr-app RN + cst-app RN + 脚本 + alembic） - 文档目录：dip1/docs/（10 份自包含文档 V2.0 + worklog/ 工作日志，脱离主仓其他文档即可独立实施交付；原 docs/技术文档/dip1/ 保留轻量跳转索引） - 阶段 1 飞书对接：⏸ 暂不实施（ADR-008），文档保留待未来启动 - Git 分支命名：DIP1 的 feature 分支必须使用前缀 feature/dip1-，例如 feature/dip1-p1-feishu-sdk；PR 标题前缀 dip1:（详见 DIP1-IMP §2.1）。 - DIP1 Code Agent 不得执行 git commit / push，仅可在本地生成变更，由 TL 审核后统一提交（PMG 规则 + DIP1-IMP §2.1）。

4.3.2 分支策略（轻量 Git Flow）¶

采用轻量级 Git Flow 模型，仅保留三类分支：

分支类型	命名规范	来源	合并目标	说明
main	固定 `main`	—	—	稳定主干：仅接受来自 dev 的合并，每笔提交必须可部署、可归档
dev	固定 `dev`	main	main	开发集成主分支：日常文档编辑、脚本修改、功能迭代均在此提交
feature/	`feature/<简述>`	dev	dev	较大变更的隔离分支（如重构需求文档体系、新增 OPS 运营服务），完成后 PR 合并回 dev

工作流：

feature/<任务>  →  开发与验证
       ↓ 合并（PR / fast-forward）
     dev    →  日常集成分支（默认工作分支）
       ↓ 合并（PR，里程碑节点）
    main   →  稳定归档分支

合并规则： - 禁止直接向 main 提交，必须从 dev 合并 - 里程碑/归档节点合并 dev → main - feature 分支命名示例：feature/mds-masterdata、feature/ops-marketing

4.3.3 提交规范¶

格式：<类型>: <简述>

类型（type）	适用场景	示例
`docs`	文档新增/修改/重构	`docs: 完善报价模型品类费率表`
`chore`	脚本/配置/工具类变更（非业务文档）	`chore: 新增文档发布脚本`
`fix`	Bug 修复（含文档错误）	`fix: 修正 V1.1 归档递归问题`
`refactor`	结构重构（不改变文档核心含义）	`refactor: agents.md 解耦为 PMG + PJM`
`feat`	新增独立服务/模块/工具	`feat: 新增 MDS 主数据服务设计`

附加要求： - 单行 commit message 过长时，用多个 -m 参数追加段落说明 - 涉及跨文档变更（如新增 OPS 同步修改 12 份文档）须在附加段落中逐份列出 - 提交变更须与 WLG 工作日志双向可追溯：日志中记录对应 commit 短哈希

4.3.4 版本控制范围（纳入 / 排除）¶

类型	是否纳入 Git	说明
`docs/`（源 Markdown）	✅ 强制	全部正式文档，归档子目录见下
`docs/归档/`	❌ 排除	本地备份快照，远程不纳入（防止仓库体积膨胀与重复）
`ref/`（参考资料）	✅ 建议	只读参考资料；大文件 (>50MB) 建议改用 Git LFS
`发布/`（PDF/HTML 成品）	✅ 强制	面向不同受众的成品输出，与源文件同步版本
`scripts/`（运维脚本）	✅ 强制	含同步脚本、文档生成脚本等
`AGENTS.md`（根）	✅ 强制	AI 协作指南，为项目入口文档
`mkdocs.yml`（根）	✅ 强制	MkDocs 站点源配置（见 §4.3.7）
`ocm/`（听云工作目录）	✅ 强制	听云（OCM）工作目录：运维文档 + 工作日志，纳入私有主仓
`ocm/public/`	✅ 强制	可公开运维文档（操作手册/集成指南等无敏感信息），同步至公开仓
`ocm/private/`	✅ 强制	不可公开运维文档（含密钥/账号/部署细节），纳入私有主仓但❌ 不同步公开仓
`ocm/worklog/`	✅ 强制	听云工作日志 OCL-YYYYMMDD-NN，纳入私有主仓
`dip1/`（DIP1 子项目）	✅ 强制	DIP1 代码 + 文档一体化自包含子目录
操作系统文件（Thumbs.db / .DS_Store / Desktop.ini 等）	❌ 排除	由 `.gitignore` 全局屏蔽
IDE 配置（`.vscode/` `.idea/` `.trae/`）	❌ 排除	本地个人配置，不共享
Python 缓存（`__pycache__/`、`*.pyc`）	❌ 排除	构建产物
临时生成文件（`.tmp`、`.log`、`.bak`、模板 `_temp_`）	❌ 排除	一次性产物
虚拟环境（`venv/`、`.venv/`、`env/`）	❌ 排除	本地开发环境
旧版本残留文件（如 `AGENTSv6.1.pdf`）	❌ 排除	历史遗留，保留旧版本归档
MkDocs 站点产物（`site/`、`.build/`）	❌ 排除	构建产物，由 `build-site.py` 生成（见 §4.3.7）
生产环境真实凭据文件（`.env.prod.local`、`.key`、`.pem`）	❌ 排除	严禁纳入 Git，由 TL 本地保管

.gitignore 为最终排除依据；如需新增例外，同步修改根目录 .gitignore 并记入 WLG。 ocm/private/ 安全提示：虽纳入私有主仓，但须确保 .gitignore 排除真实凭据文件（.env.prod.local 等），仅保留文档化的配置模板与部署报告。

4.3.5 发布目录机制¶

根目录 发布/ 为文档成品发布区，区别于代码发布（后者由后续 CI/CD 流程另行管理）。

维度	文档发布（`发布/`）	代码发布（未来）
内容	PDF / HTML 文档成品	可执行代码 / 部署包
受众	团队内部 / 投资方 / 客户 / 合作方	开发 / 运维
来源	由 `docs/` 源文件经 AI 特定行为（汇总 / 汇报输出）生成	开发编码产出
版本	文件名含版本号，跟随源文件版本	Git tag / release

AI 特定行为输出目标（与 PMG §特定行为条款同步 · V3.3 起文档公开发布链路重构，取消 Gitee hk2026-docs 中间仓）：

AI 行为	输出格式	输出目录/目标
文档汇总输出	单一 PDF，按"篇"分隔，Mermaid 转图片	`发布/`
文档汇报输出	单一 PPT（HTML 格式）	`发布/`
git同步	仅推送 Gitee hk2026 私有主仓 main 分支（团队协作源代码与文档备份唯一通道，不再推送任何公开仓）	Gitee hk2026 私有主仓
文档公开发布（V3.3 链路重构）	在 git 同步（hk2026 main）基础上，本地 MkDocs 构建 + wrangler 直传 Cloudflare Pages（不再经过 Gitee hk2026-docs 仓）	Cloudflare Pages Project = `hk2026`；生产域名 `https://hk2026.pages.dev`

⚠ 执行约束：git同步与文档公开发布均为需用户直接指令的 AI 特定行为，AI 不得自动触发；文档汇总输出与文档汇报输出同样遵循此约束。详见 PMG §AI特定行为。

目录管理： - 新增发布文档须同步更新 发布/README.md 内容清单 - 每次主仓库新增文档或发布成品后，若用户指令「文档公开发布」，则执行 §4.3.7（MkDocs 构建 + deploy-site.ps1 直传 Cloudflare Pages Project = hk2026），不再执行任何 Gitee 公开镜像仓同步脚本

4.3.6 公开文档同步（主仓库 → Gitee hk2026-docs 公开仓）¶

⚠ V3.3 起 🔴 整章已废除（2026-08-22，范围限缩）：仅废除「hk2026 → Gitee hk2026-docs 这个公开 Git 仓的同步流程」（即 scripts/sync-docs-repo.ps1 / Gitee push/sync/checkout 相关操作）。MkDocs + Cloudflare Pages 文档公开发布流程不废除（改为 §4.3.7 直接从 hk2026 私有主仓本地构建后部署到 Project = hk2026 的 Pages，链路不再经过 Gitee 公开仓）。本节所有内容仅保留为历史归档参考，任何情况下不得执行以下任何脚本或操作步骤（scripts/sync-docs-repo.ps1）。

废除原因：用户指令澄清原话：「刚才修改的似乎过头了，我只是废除 gitee 的 hk2026-doc ，Cloudflare Pages 文档公开发布这个AI特定行为还是需要的，实际上，原来 hk2026 --> hk2026-doc --> Cloudflare Pages ，改为：hk2026 --> Cloudflare Pages（仍然是公开的）」。

目标：~~保持 docs/ 只读开放互联网访问，同时私有工作内容不外泄。~~（🔴 已废除）

同步范围：（🔴 已废除，仅供历史参考）仅同步主仓库 docs/ + 发布/ + ocm/public/（排除 docs/归档/、ocm/private/、ocm/worklog/，后三者在 .gitignore 或同步脚本中屏蔽）。

同步项	是否同步至公开仓	说明
`docs/`	✅ 同步	源文档，与主仓结构一致
`发布/`	✅ 同步	PDF/HTML 成品
`ocm/public/`	✅ 同步	可公开运维文档（操作手册/集成指南，无敏感信息）
`ocm/private/`	❌ 不同步	含密钥/账号/部署细节，仅私有主仓保留
`ocm/worklog/`	❌ 不同步	听云工作日志，仅私有主仓保留
`docs/归档/`	❌ 不同步	本地备份快照，`.gitignore` 已屏蔽
`ref/`	❌ 不同步	外部参考资料，不公开
`dip1/` 代码	❌ 不同步	代码暂不纳入公开文档仓（文档发布在 `发布/dip1/`）

自动同步脚本：

项	内容
位置	`scripts/sync-docs-repo.ps1`（编排层）+ `scripts/sync-docs-helper.py`（文件处理层）
执行时机	主仓库 docs/ 或发布/ 有重要变更后手动执行
原理	以 `git ls-tree -r -z --name-only HEAD -- docs 发布` 获取原始路径（NUL 分隔，无转义编码问题），Python 逐文件复制；首次生成落地页 README.md；最后 git commit + push 到公开仓
Commit message	`docs: sync from main <主仓短哈希> (docs/ + 发布/)`，可追溯每笔同步对应的主仓库快照

执行步骤（PowerShell）：

# 1. 克隆公开文档仓库（仅首次）
git clone https://gitee.com/atonio/hk2026-docs.git d:\AC\TF\hk2026-docs

# 2. 每次同步执行
d:\AC\TF\hk2026\scripts\sync-docs-repo.ps1

公开仓规则： - 公开文档仓的 docs/ 与 发布/ 结构与主仓库完全一致，确保 Markdown 相对链接（../xxx.md）在 Gitee 渲染器中有效 - 公开仓根 README.md 为落地页索引（首同步自动生成），含核心文档 / 服务设计 / 技术文档 / 发布成品四大导航区块 - 公开仓 不接受直接提交；任何修改须在主仓库完成后重新同步 - 主仓根目录的 AGENTS.md、ref/ 等不对外公开内容，不会被同步

4.3.7 文档站点发布（MkDocs Material + Cloudflare Pages）¶

V3.3 链路重构（2026-08-22 用户澄清后恢复活跃）：MkDocs + Cloudflare Pages 文档公开发布流程完整保留、继续执行，仅将部署链路从「hk2026 → Gitee hk2026-docs 仓 → Cloudflare Pages Project = hk2026-docs」重构为「hk2026 私有主仓 → 本地 build-site.py 构建 → deploy-site.ps1 + wrangler 直传 Cloudflare Pages Project = hk2026」，不再经过 Gitee hk2026-docs 公开 Git 仓（该仓已废除，见 §4.3.6）。对齐 PMG §AI特定行为第 4 条「文档公开发布」，作为 AI 4 条特定行为之一仅在用户明确指令时执行。

参数迁移要点（V3.3）： - Cloudflare Pages Project 名：hk2026-docs → hk2026（生产域名：https://hk2026-docs.pages.dev → https://hk2026.pages.dev） - 部署命令：scripts/deploy-site.ps1 默认 -ProjectName 改为 hk2026；预览域名变为 <branch-hash>.hk2026.pages.dev - 构建脚本、构建逻辑、slug URL、文件清单（build-site.py / url_map.py / mkdocs.yml / deploy-site.ps1）全部沿用，仅 Project / 域名参数替换；构建源仍然是 hk2026 私有主仓 docs/ + 发布/ + ocm/public/（不含私有内容） - 构建排除项（§4.3.6 废除的 sync-docs-repo.ps1 相关 Gitee Git 操作）不影响本节。

目标：在 hk2026 私有主仓之外，新增可交互的在线文档站点（Cloudflare Pages）作为对外文档公开发布的唯一通道，提供全文搜索、侧边栏导航、Mermaid 原生渲染、深色模式等增强阅读体验。链路重构 V3.3 起不再需要经过任何 Gitee 公开镜像仓（hk2026-docs 已废除）。

背景：原 Gitee hk2026-docs 公开镜像仓直接复制 Markdown 源文件，Gitee 的 MD 渲染较基础（Mermaid 图表不渲染、无全文搜索、无侧栏导航），且 Gitee Pages 服务已停服，无法托管静态站点；同时该公开 Git 仓按用户指令已废除。MkDocs Material + Cloudflare Pages 直传方案弥补这一短板并同时满足公开访问需求。

技术栈：

项	内容
站点框架	MkDocs Material（Python，`pip install mkdocs-material`）
图表渲染	内置 SuperFences（原生 Mermaid，无需额外插件），覆盖项目 65+ 张 Mermaid 图
托管平台	Cloudflare Pages（全球 CDN，免费额度充足）
部署工具	wrangler CLI（`wrangler pages deploy`）
品牌主题	深墨绿 #004046（主色）、浅沙金 #D4AF78（辅色）、米白浅灰 #F2F0EB（背景），经 `assets/css/brand.css` 注入
生产域名 / Project	Project = `hk2026`；默认生产域名 `https://hk2026.pages.dev`（V3.3 替换原 `hk2026-docs.pages.dev`）；可绑定自定义域名
预览域名	`<branch-hash>.hk2026.pages.dev`（wrangler 默认生成）

文件清单：

文件	作用
`mkdocs.yml`（根）	站点源配置（主题/扩展/nav/品牌色）；直接 `mkdocs serve` 会断链，须经 `build-site.py` 构建
`scripts/build-site.py`	构建编排：扁平化 slug 重命名 + 全量链接重写 + 动态 nav 生成，执行 `mkdocs build`
`scripts/url_map.py`	URL 映射核心模块：slug 生成、链接解析、basename 回退、nav 结构定义
`scripts/deploy-site.ps1`	部署编排（V3.3 默认 ProjectName = `hk2026`）：调用 build-site.py 构建后，经 wrangler 上传至 Cloudflare Pages
`site/`（产物）	构建产物，已 `.gitignore` 排除
`.build/`（临时）	构建临时工作区，已 `.gitignore` 排除

源文件零修改原则：所有链接重写仅作用于 .build/docs-src/ 临时副本，主仓 docs/、AGENTS.md、发布/ 源文件不动。构建完成后 .build/ 自动清理（--serve 模式保留供热重载）。

URL 短路径重写机制（slug 方案）：

为兼顾短 URL 与可读性，所有 Markdown 文件在构建时以扁平化 slug 命名复制到 docs-src/ 根层，URL 形如 hk2026.pages.dev/pjm/、/cptd/、/dlg01/（V3.3 统一更换主域名从 hk2026-docs → hk2026）。

slug 来源	示例	字符数	说明
项目术语缩写（主文档，35 个）	`pmg`、`pjm`、`gly`、`rqds`、`qsvd`、`cptd`、`mdsd`、`opsd`、`tsmm`	3-5	取自 GLY 术语表，自描述、零维护
DLG 编号（对话记录）	`dlg01`~`dlg48`	5	从文件名提取 DLG 编号
固定 slug（工作日志子页/评审/桩页）	`wlgwx`、`wlgof`、`rev01`、`ref`、`arc`	3-5	手动映射
base36 hash（其他文件）	`a3f9k`	5	路径 MD5 取 5 位 base36，确定性

降级说明：用户原期望 5 位纯流水号（如 00001），但纯流水号不可读且需维护映射表（映射丢失即全站断链）。改用项目已有术语缩写，同样 3-5 字符，且自描述、零维护、无映射丢失风险。

全量链接重写（由 url_map.resolve_link_target() 实现）：

源链接形式	重写为	处理逻辑
`agents.md`（大小写不敏感）	`pmg.md`	特殊路径检测
`ref/...` 目录链接	`ref.md`	ref/ 不公开，跳转桩页面
`归档/...` 目录链接	`arc.md`	归档/ 不进站点，跳转桩页面
Markdown 链接（路径正确）	`<slug>.md`	url_map 直接查找
Markdown 链接（深度错误）	`<slug>.md`	basename 回退修复（如 `../术语表.md` → `gly.md`）
非 Markdown 链接（.pdf/.html）	`发布/<basename>`	发布/ 目录回退
根级文件链接（scripts/、mkdocs.yml）	保留原样	不在文档范围内，9 个残留 WARNING 属合理引用

排除项： - docs/归档/（gitignored，不进构建） - ref/（外部参考资料，不公开，链接指向桩页面） - 工作日志的对话记录/微信/线下/附件页面仍构建（可直达 URL 访问），仅 not_in_nav 不显示在侧栏，避免侧栏过深

构建模式： - 默认非 strict：因工作日志存在历史链接债务（不应改动历史记录），--strict 会在断链处失败。源链接经一次性审计清理后可启用 --strict - --strict：strict 模式，断链即失败（供未来源链接审计） - --serve：本地预览 http://127.0.0.1:8000 - --no-publish：排除 发布/ 目录（PDF 不进站点）

部署流程（PowerShell，需一次性环境配置）：

# 一次性环境配置
pip install mkdocs-material
npm i -g wrangler
$env:CLOUDFLARE_ACCOUNT_ID = "<账号 ID>"
$env:CLOUDFLARE_API_TOKEN  = "<API Token>"
wrangler pages project create hk2026-docs --production-branch=main

# 每次部署
d:\AC\TF\hk2026\scripts\deploy-site.ps1
# 或仅构建不部署
python d:\AC\TF\hk2026\scripts\build-site.py

与 §4.3.6 公开文档镜像仓的关系：

维度	§4.3.6 公开文档镜像仓	§4.3.7 文档站点
形态	Gitee 仓库（MD 源码镜像）	Cloudflare Pages 静态站点
阅读体验	Gitee 基础 MD 渲染	搜索/导航/Mermaid 原生渲染/深色模式
更新方式	`sync-docs-repo.ps1` 同步	`deploy-site.ps1` 构建部署
是否并行	✅ 保留，两条路径并行	✅ 新增，增强阅读体验
受众	需查看源码/二次加工者	非专业技术人员阅读者

两条发布路径独立维护，文档变更后分别执行同步脚本与部署脚本。

4.4 子项目反馈机制（SFM — Subproject Feedback Mechanism）¶

定位：SFM 是 DIP1 及未来 DIP2/DIP3 等独立子项目 Code Agent（听码 WDE）以及生产运维智能体（听云 OCM）向主项目反馈信息、请求决策、升级阻塞的统一通道。机制设计目标：与双层 WLG 同构复用、人类干预成本最小化、100% 过程可追溯、多子项目可扩展、跨项目 Code Agent 可协作、听码与听云同构适用。

适用对象（V2.6 扩展）： - 听码（WDE）：代码开发阻塞/技术决策/跨项目协作 → Issue + DWLG - 听云（OCM）：生产故障/部署阻塞/外部服务集成/客服升级 → Issue + OCL - 两者使用相同的反馈分类矩阵（§4.4.3）+ 相同的状态机（§4.4.4）+ 相同的超时升级规则，仅工作日志编号不同（DWLG vs OCL）

4.4.1 设计目标与核心原则¶

目标	量化指标
人类干预最小化	80% 反馈自动处理 / 15% TL 处理 / 5% 升级 BO+SPO
过程可追溯	100% 反馈通过 Issue + DWLG 双轨留痕，双向可引用
多子项目可扩展	编号体系、模板、标签命名空间预留 DIP2/DIP3 扩展位
跨项目 Code Agent 可协作	共享契约仓 + 跨项目 Issue + TL 仲裁兜底
响应可控	TL 接收 ≤4h / TL 决策 ≤24h / BO ≤48h / SPO ≤7d

核心原则：反馈机制与双层 WLG 同构复用，不另起炉灶。Code Agent 不增加新的提报工具，仅在现有 Issue + DWLG 上叠加「类型标签 + 状态机 + 双向确认」。

4.4.2 总体架构¶

graph TD
    subgraph 子项目层["子项目层（DIP1 / 未来 DIP2 / DIP3）"]
        CA1["🤖 DIP1 Code Agent"]
        CA2["🤖 DIP2 Code Agent（未来）"]
        DWLG1["📂 dip1/docs/worklog/<br/>DWLG-YYYYMMDD-NN"]
        DWLG2["📂 dip2/docs/worklog/<br/>DIP2WLG-YYYYMMDD-NN"]
    end

    subgraph 反馈通道["反馈通道（4 类）"]
        ISSUE["📋 Git Issue<br/>主通道·结构化"]
        PR["💬 PR 评论<br/>实现细节"]
        ALERT["🔔 飞书机器人<br/>Critical 即时"]
        LOG["📝 DWLG 日志<br/>过程留痕"]
    end

    subgraph 处理层["处理与确认（状态机）"]
        S1["SUBMITTED<br/>已提交"] --> S2["RECEIVED<br/>TL 已接收 ≤4h"]
        S2 --> S3["IN_REVIEW<br/>评审中"]
        S3 --> S4["DECIDED<br/>已决策 ≤24h"]
        S4 --> S5["IMPLEMENTED<br/>Code Agent 已实施"]
        S5 --> S6["CONFIRMED<br/>TL 验证确认 ≤24h"]
        S6 --> S7["CLOSED<br/>关闭"]
        S5 -.->|"REOPENED<br/>验证不通过"| S3
    end

    subgraph 主仓层["主仓层（TL/听写维护）"]
        DLG["📂 docs/工作日志/<br/>DLG-NN（里程碑同步）"]
        WEEKLY["📊 周反馈简报<br/>每周一 10:00 自动汇总"]
        MATRIX["🚦 §7.1 红黄绿矩阵<br/>SPO/BO 唯一视图"]
    end

    CA1 -->|"提交反馈"| ISSUE
    CA1 -->|"同步记录"| DWLG1
    CA2 -->|"跨项目协作"| ISSUE
    ISSUE -->|"Critical 自动触发"| ALERT
    ISSUE -->|"状态流转"| S1
    S4 -->|"Code Agent 确认理解"| CA1
    S5 -->|"TL 验证"| S6
    S7 -->|"TL 同步"| DLG
    S1 -->|"每周汇总"| WEEKLY
    WEEKLY -->|"输入"| MATRIX

    classDef sub fill:#2a9d8f,stroke:#004046,color:#fff;
    classDef ch fill:#457b9d,stroke:#004046,color:#fff;
    classDef st fill:#D4AF78,stroke:#004046,color:#004046;
    classDef main fill:#004046,stroke:#004046,color:#fff;
    class CA1,CA2,DWLG1,DWLG2 sub;
    class ISSUE,PR,ALERT,LOG ch;
    class S1,S2,S3,S4,S5,S6,S7 st;
    class DLG,WEEKLY,MATRIX main;

4.4.3 反馈分类矩阵（5 类型 × 3 严重级别）¶

反馈类型（Type）：

类型	代号	场景	处理方	响应 SLA	占比目标
信息同步	`INFO`	进度同步、知识共享、技术债备忘	无需决策，TL 周批量浏览	不适用	80%
请求决策	`REQ`	业务规则不明确、参数缺失、设计歧义	TL（技术）/ BO（业务）	24h / 48h	12%
升级阻塞	`ESCAL`	自行尝试 24h 无果，阻塞后续任务	TL → BO → SPO 三级升级	24h/48h/7d	5%
跨项目协作	`CROSS`	接口契约、数据格式、依赖等待	双方 TL + SPO 仲裁	72h	2%
风险预警	`RISK`	未阻塞但存在潜在风险（性能、安全、合规）	TL 评估是否升级	48h 评估	1%

严重级别（Severity）：

级别	图标	定义	自动动作
Critical	🔴	阻塞 ≥2 个后续任务	飞书机器人 @TL + 自动同步 DLG
Major	🟡	阻塞当前任务	Issue 标签 + DWLG 记录
Minor	🟢	优化建议	月度汇总，不强制响应

类型 × 级别处理矩阵：

类型\级别	🔴 Critical	🟡 Major	🟢 Minor
INFO	不存在	不存在	TL 周浏览
REQ	TL 4h + BO 24h	TL 24h	TL 周处理
ESCAL	飞书告警 + SPO 7d	TL → BO 48h	转 REQ
CROSS	飞书告警 + 双方 TL 72h	双方 TL 72h	转 REQ
RISK	TL 评估后升级	TL 48h 评估	月度汇总

4.4.4 处理确认状态机（双向确认 7 状态）¶

状态	触发方	确认动作	SLA
SUBMITTED	Code Agent 提交 Issue + 同步 DWLG	自动	T0
RECEIVED	TL 评论"已接收，预计 Xh 回复"	TL 4h 内	T0+4h
IN_REVIEW	TL 评审中（可能 @BO/@PO 咨询）	自动	T0+4h~T0+24h
DECIDED	TL/BO 给出决策	Code Agent 8h 内评论"已理解，按 X 方案执行"	T0+24h
IMPLEMENTED	Code Agent 实施完毕，评论"已实施，请验证"	Code Agent	决策后合理工期
CONFIRMED	TL 验证通过，评论"验证通过，关闭"	TL 24h	实施后 24h
CLOSED	自动关闭	自动	CONFIRMED 后自动
REOPENED	TL 验证不通过，退回 IN_REVIEW	TL	—

双向确认要点： - Code Agent → TL：提交时必须同步 DWLG，DWLG 中引用 Issue 编号 - TL → Code Agent：DECIDED 时必须给出可执行的明确指令（禁止"看着办"） - Code Agent → TL：DECIDED 后 8h 内必须回复"已理解"，否则 TL 视为未传达 - TL → Code Agent：IMPLEMENTED 后 24h 内必须验证，否则 Code Agent 可视为默认通过

超时自动升级规则：

超时项	自动动作
TL 4h 未接收	飞书机器人 @TL 二次提醒
TL 24h 未决策	自动升级 severity → Critical + 通知 BO
Code Agent 8h 未确认理解	TL 在 Issue 评论提醒
Code Agent 决策后超期未实施	TL 介入排查（可能阻塞 → ESCAL）
TL 24h 未验证	默认通过 + DWLG 标注"超时默认通过"

4.4.5 与双层 WLG 的统筹机制¶

反馈与日志双向引用：

graph LR
    ISSUE["📋 Issue #NN<br/>type:req severity:major"] -.->|"Code Agent 提交时同步"| DWLG["📝 DWLG-YYYYMMDD-NN<br/>关联 Issue #NN"]
    DWLG -.->|"TL 同步里程碑"| DLG["📂 DLG-NN<br/>汇总本期 Issue 处理"]
    ISSUE -.->|"状态流转留痕"| DWLG
    DLG -.->|"反向引用"| ISSUE

TL 同步至主仓 DLG 的触发条件（扩展 §3.4.5 原有 6 项 → 新增 2 项反馈相关）：

同步触发条件	主仓 WLG 编号	同步内容
§0 环境基建（9 人天）完成	DLG-xx	Expo/EAS 工具链 + Monorepo 调整 + docker compose + 种子脚本
§2 后端业务（49 人天）完成	DLG-xx	5+1 大子域（含 CST）+ 65 REST API + Alembic 0001+0002 迁移 + RBAC + 移动认证 + 推送服务
§3 前端 OPR Web（15 人天）完成	DLG-xx	OPR 后台 15+ 页面 + 前后端联调
§3 前端 WKR RN + CST RN（27 人天）完成	DLG-xx	wkr-app + cst-app RN 8+8 页面 + 原生模块（相机/推送/离线）+ 前后端联调
§3 移动端基建（5 人天）完成	DLG-xx	EAS Build 4 artifact + App Store/Google Play 提审 + OTA 热更新配置
UAT 50 单验收完成	DLG-xx	UAT 报告 + 三级 Checklist 全绿
重大 Issue 升级（Critical 72h）	DLG-xx	问题根因 + 影响 + 决策
生产发布 V2.0	DLG-xx	发布报告 + 蓝绿切换 + RPO/RTO 验证 + App 上架
周反馈简报（每周一）	DLG-xx	上周反馈总数 / 按类型分布 / Critical 处理情况 / 待处理列表
Critical 升级闭环	DLG-xx	根因 + 影响 + 决策 + 整改措施 + 复盘结论

详细反馈类 DWLG 子模板见 dip1/docs/worklog/README.md §六，DIP1 Code Agent Issue 模板与状态机执行细则见 DIP1-IMP §八 + §十。

4.4.6 人类干预成本最小化策略（量化）¶

分级响应模型：

反馈分布	处理方	单次耗时	频率	周耗时
80% INFO	听写助手自动汇总 → TL 浏览	15 min	每周 1 次	15 min
12% REQ	TL 模板化决策	10 min/条	每周 ~3 条	30 min
5% ESCAL	TL + BO 协商	30 min/条	每月 ~2 条	30 min/月
2% CROSS	双方 TL 仲裁	60 min/条	每季度 ~1 条	60 min/季
1% RISK	TL 评估	15 min/条	每月 ~1 条	15 min/月

TL 周干预成本估算：≈ 45 分钟/周（浏览简报 + 处理 REQ）

自动化辅助（听写助手承担）：

自动化项	触发	动作
Issue frontmatter 解析	Issue 创建/更新	自动应用标签
Critical 飞书告警	severity=critical	机器人 @TL + 附 Issue 链接
周反馈简报	每周一 9:00	汇总上周 Issue → 生成简报 → 推送 TL
超时检测	每日 10:00	扫描超时项 → 自动升级 severity
DLG 同步草稿	触发条件命中	听写生成 DLG 草稿 → TL 审核后发布
§7.1 矩阵同步	Issue CLOSED	提示 TL 更新对应里程碑状态

SPO/BO 零介入边界（仅以下情况介入）： 1. Critical ESCAL 升级到 SPO（架构/预算决策） 2. CROSS Issue 72h 未果需仲裁 3. §7.1 矩阵出现 🔴 红灯 4. 周反馈简报中标记"需 SPO 关注"

4.5 跨子项目协作机制¶

4.5.1 多子项目编号体系扩展¶

子项目 / 角色	工作日志编号	示例	目录
DIP1（听码开发）	`DWLG-YYYYMMDD-NN`（保留，向后兼容）	DWLG-20260810-01	`dip1/docs/worklog/`
DIP2（未来，听码开发）	`DIP2WLG-YYYYMMDD-NN`	DIP2WLG-20261115-01	`dip2/docs/worklog/`
DIP3（未来，听码开发）	`DIP3WLG-YYYYMMDD-NN`	DIP3WLG-20270101-01	`dip3/docs/worklog/`
听云（OCM，生产运维）	`OCL-YYYYMMDD-NN`	OWLG-20260811-01	`ocm/worklog/`
跨项目汇总	`SWLG-YYYYMMDD-NN`（Subproject Work Log）	SWLG-20261201-01	`docs/工作日志/子项目汇总/`

设计权衡：保留 DIP1 现有 DWLG- 不破坏向后兼容；新增子项目沿用 {缩写}WLG- 模式；听云（OCM）使用 OCL-（O = OPS 生产运营标识；历史 OWLG- 编号保留，新日志统一使用 OCL-）；跨项目汇总用 SWLG- 由听写助手维护。

4.5.2 子项目新增流程¶

新增 DIP2/DIP3 时，Code Agent 实施指南须包含： 1. 复用本 §4.4 SFM 机制（不重新设计） 2. 工作日志目录 {子项目}/docs/worklog/ 3. 编号体系 {缩写}WLG-YYYYMMDD-NN 4. Issue 模板 frontmatter 的 subproject 字段填对应值 5. §7.1 状态跟踪矩阵独立维护

4.5.3 Git Issue 全局标签命名空间¶

标签类别	示例	用途
子项目	`subproject:dip1` `subproject:dip2`	过滤本子项目反馈
角色	`role:wde`（听码开发）`role:ocm`（听云运维）	区分反馈来源：代码开发 vs 生产运维
类型	`type:info` `type:req` `type:escal` `type:cross` `type:risk`	类型筛选
严重级别	`severity:critical` `severity:major` `severity:minor`	优先级排序
里程碑	`milestone:c-03`	关联 §7.1 矩阵代码组 ID
跨项目	`cross-project` + `subproject:dip1,dip2`	跨项目协作标识
运维场景	`ops:deploy`（部署）`ops:incident`（故障）`ops:integration`（集成）`ops:ticket`（工单）	听云运维场景细分
状态	`status:received` `status:decided` `status:confirmed`	状态机辅助（可选）

4.5.4 跨项目 Code Agent 交互协议¶

交互场景与处理路径：

场景	处理路径	人类介入点
接口契约不明确	Code Agent A 开 CROSS Issue → @Code Agent B 讨论 → 72h 未果双方 TL 仲裁	72h 后双方 TL
数据格式不兼容	同上	同上
依赖等待（A 等 B 交付）	Code Agent A 开 CROSS Issue 标注 `blocked-by:dip2-xxx` → B 评估工期 → A 调整排期	工期变更 ≥3d 时 TL 介入
共享组件复用	在 `docs/技术文档/contracts/` 提 PR 定义契约 → 双方 TL + SPO 批准	契约变更必经 SPO

共享契约仓结构：

docs/技术文档/contracts/
├── README.md                           # 契约索引
├── api-contracts/                      # 跨项目 API 契约
│   ├── dip1-dip2-sync-api.yaml         # DIP1↔DIP2 同步接口
│   └── ...
├── data-formats/                       # 共享数据格式
│   ├── order-event-schema.json         # 订单事件 Schema
│   └── ...
└── shared-components/                  # 跨项目共享组件清单
    └── README.md

Code Agent 直接沟通约束： - ✅ 允许：在 Issue/PR 评论中 @mention 对方 Code Agent（通过 TL 转发，因 Agent 无 git push 权限） - ✅ 允许：在 DWLG 中引用对方子项目的 Issue/DWLG 编号 - ❌ 禁止：Code Agent 之间通过非 Git 渠道（微信/邮件）直接沟通 - ❌ 禁止：Code Agent 修改其他子项目目录下任何文件

4.6 文档版本与归档机制¶

V3.0 重大变更：原 docs/归档/ 目录已删除并废止，归档机制由「目录快照 + robocopy 复制」改为「git tag / git branch 快照」管理。本节保留版本规范（§4.6.1），归档操作规范（§4.6.2~4.6.6）改为 git tag 快照说明；历史归档命令仅供追溯，禁止再执行。详见 PMG §归档目录取消与导航表 ARC 行「V8.0 已废止」标注。

4.6.1 文档版本规范¶

项	规范
版本号格式	`V<主版本>.<次版本>`，如 V1.0、V1.1、V2.0
主版本升级	重大重构、方向调整、结构变更（V1.0 → V2.0）
次版本升级	内容增补、修订优化、局部调整（V1.0 → V1.1）
版本记录	每份文档末尾须附「修订记录」表，记录版本、日期、修订人、修订内容
版本标注	文档头部须标注当前版本号与最近更新日期

4.6.2 快照触发条件（V3.0 改为 git tag）¶

触发条件	快照时机	执行人	命令
里程碑快照	每个阶段里程碑评审通过后	DT / TL	`git tag -a milestone/<阶段>-<版本> -m "..."`
版本快照	主版本升级（V1.0 → V2.0）时	DT	`git tag -a v<版本> -m "..."`
定期快照	每月末进行一次定期快照	DT	`git tag -a monthly/<YYYYMM> -m "..."`
临时快照	SPO 指定或重大变更前	DT	`git tag -a snapshot/<主题>-<YYYYMMDD> -m "..."`

4.6.3 git tag 命名规范¶

项	规范	示例
里程碑 tag	`milestone/<阶段>-<版本>`	`milestone/筹备期前期-V3.0`
版本 tag	`v<主版本>.<次版本>`	`v3.0`
月度 tag	`monthly/<YYYYMM>`	`monthly/202608`
临时 tag	`snapshot/<主题>-<YYYYMMDD>`	`snapshot/三AI重构-20260820`
分支保护	重要里程碑同时打分支 `release/<阶段>-<版本>` 供长期回溯	`release/筹备期前期-V3.0`

4.6.4 快照操作规范¶

完整性：快照在 main 分支稳定态下打 tag，确保当前提交可部署、可回溯
只读性：tag 与 release/* 分支为只读引用，禁止 fast-forward 推进（如需修正另打新 tag）
可追溯：tag message 须记录快照范围、对应 PJM/RQD 版本号、关键 commit 哈希
远程推送：tag 须 git push origin <tag名> 仅推送到 Gitee hk2026 私有主仓（hk2026-docs Gitee 公开镜像 Git 仓已🔴废除，任何情况下不得向该仓推送 tag 或任何提交；Cloudflare Pages Project=hk2026 的部署不通过 git tag，走 wrangler 直传链路，详见 §4.3.7 V3.3）
本地备份：TL 本地保留全量 tag 与 release 分支，作为 git 远程仓库之外的二次备份

递归防护废弃（V3.0）：原 robocopy /XD "归档" 递归校验要求已废止，归档目录 docs/归档/ 已物理删除，不再有递归风险。

4.6.5 快照类型与策略¶

快照类型	适用场景	范围	操作要点
全量快照	里程碑、主版本升级	当前 `main` 全部提交	`git tag -a` 打 annotated tag + 推送
分支快照	长期回溯、版本维护	创建 `release/*` 分支	`git branch release/<阶段>-<版本> main`
临时快照	临时需求、敏感变更前	当前 HEAD	`git tag -a snapshot/<主题>-<日期>`

全量快照命令示例（PowerShell）：

# 在 main 分支稳定态打里程碑 tag
git tag -a milestone/筹备期前期-V3.0 -m "PJM V3.0 整体重构：三AI新分工+双轨交付+日志体系+归档目录废止"
# 推送到 Gitee hk2026 私有主仓（注意：hk2026-docs 已暂停，不推送）
git push origin milestone/筹备期前期-V3.0
# 同时建 release 分支供长期回溯
git branch release/筹备期前期-V3.0 main
git push origin release/筹备期前期-V3.0

历史归档目录（已废止）：原 docs/归档/20260804_V1.0_筹备期前期/、docs/归档/20260805_V1.1_筹备期前期/ 已物理删除；如需查阅历史版本，使用 git log --all -- docs/归档/ 或检出对应 tag 回溯。原 归档清单.md 索引机制同步废止。

五、业务设计完整性/一致性/连续性核查（V3.1 新增）¶

承接用户指令（2026-08-21）：从源头业务调研文档（ref/DOC-P2*、ref/DOC-P30、ref/DOC-P4*、ref/DOC-P5*）到需求、服务设计、原型、用例的全链路三性核查。明确引入 DDD 方法，扩充业务用例覆盖典型流程与异常场景，建立原型↔用例↔服务↔需求相互关联（Ctrl+鼠标停留查看）。

5.1 核查目标与范围¶

5.1.1 三性定义¶

性	定义	失败示例
完整性	业务调研→需求→服务设计→原型→用例全链路无遗漏	服务设计提及但需求文档未定义、原型缺失关键页面
一致性	跨文档术语、引用、数据流、阶段编号无矛盾	GLY 与服务设计术语缩写冲突、阶段编号跨服务不对齐
连续性	服务边界、阶段演进、版本化路径清晰可追溯	DIS 派单流程与 CPT L5 触发关系断裂、版本迭代断档

5.1.2 核查范围（源头到末端）¶

flowchart LR
    subgraph SRC["① 源头业务调研"]
        P2["ref/DOC-P2 公司/场景/销售包"]
        P30["ref/DOC-P30 市场调研+报价模型"]
        P4["ref/DOC-P4 行业分析+楼宇库"]
        P5["ref/DOC-P5 物流报价模型+供应商"]
    end
    subgraph REQ["② 需求"]
        RQDS["RQD-S 战略级"]
        RQDB["RQD-B 业务级"]
        RQDO["RQD-O 执行级"]
    end
    subgraph SRV["③ 服务设计（DDD）"]
        QSV["QSV-D 报价"]
        CPT["CPT-D 跟踪"]
        MDS["MDS-D 主数据 + 六库"]
        OPS["OPS-D 运营"]
        DIS["DIS-D 派单"]
    end
    subgraph PRX["④ 原型（5端 52页）"]
        OPR["opr-admin Web"]
        CST["cst-app RN"]
        WKR["wkr-app RN"]
        MFR["mfr-portal Web"]
        LGP["lgp-app RN"]
    end
    subgraph UC["⑤ 业务用例"]
        UCM["用例库（待建）"]
    end
    P2 --> RQDS
    P30 --> RQDB
    P4 --> RQDB
    P5 --> RQDB
    RQDS --> RQDB --> RQDO
    RQDB --> QSV
    RQDB --> CPT
    RQDB --> MDS
    RQDB --> OPS
    RQDB --> DIS
    QSV -.->|技术落地| PRX
    CPT -.->|技术落地| PRX
    MDS -.->|技术落地| PRX
    OPS -.->|技术落地| PRX
    DIS -.->|技术落地| PRX
    PRX <-->|双向关联| UCM
    UCM <-->|双向关联| SRV

5.1.3 核查责任分工¶

角色	核查职责
DT 听写	主导核查执行，产出核查报告与差距清单
TL 司徒总	DDD 方法合规性审批
OL 成文/黄总	业务用例真实性、典型场景覆盖度审批
BO 洪哥	业务调研→需求映射完整性审批

5.2 源头业务调研清单与映射¶

调研文档	编号	内容摘要	映射到需求/服务
公司介绍手册	DOC-P21	织布鸟公司介绍、品牌定位	RQD-S §一品牌定位
项目场景业务流	DOC-P22	6 类获客场景业务流	OPS-D 6 类获客场景、RQD-B §5 OPS 需求
场景配套资料包	DOC-P23	各场景配套物料	OPS-M 7 组 32 项物料
整体销售文件包	DOC-P24	销售组合工具	OPS-M 销售物料体系
市场调研+报价模型	DOC-P30	香港上门安装市场调研 + 报价模型	RQD-B §1 QSV 需求 + QMD 8 大参数 + MDS/BPL 楼宇系数
交叉行业深度分析	DOC-P31	上门安装平台行业分析	RQD-S §二市场机会
楼宇特征库 BPL V2.0/V2.1	DOC-P43/P44	全港住宅楼宇数据	MDS/BPL 楼宇特征库 V1.0
物流报价模型+方案架构	DOC-P50	中港配送物流费用报价与方案	DIS-D 三模式派单、QMD 物流费公式、DLV 物流商档案
物流报价模型 LQM V1.0	DOC-P51	物流报价参数表	QMD 物流费参数 + DLV 费率标准
中港物流供应商调研	DOC-P52	物流供应商清单	DLV 物流商档案库、M3 物流公司合同

完整性检查项：每份调研文档须在需求或服务设计中体现，未映射的调研结论须登记到差距清单。

5.3 DDD 方法落实核查¶

5.3.1 各服务 DDD 战略设计状态¶

服务	子域划分	限界上下文	上下文映射（OHS/ACL/PL）	领域事件	战略设计状态
QSV-D	⚠ 部分	⚠ 部分	❌ 缺	❌ 缺	🔴 待补全（阶段二）
CPT-D	⚠ 部分（L1-L8 子流程）	⚠ 部分	❌ 缺	❌ 缺	🔴 待补全（阶段二）
MDS-D	⚠ 部分（四库）	⚠ 部分	❌ 缺	❌ 缺	🔴 待补全（阶段二）
OPS-D	⚠ 部分（6 场景）	❌ 缺	❌ 缺	❌ 缺	🔴 待补全（阶段二）
DIS-D	✅ 5 子域	✅ 5 BC	✅ ACL+OHS+SK+CS	✅ 4 事件	🟢 完成（V1.0）

5.3.2 各服务 DDD 战术设计状态¶

服务	聚合根	实体	值对象	领域服务	仓储	战术设计状态
QSV-D	❌	❌	❌	❌	❌	🔴 待补全
CPT-D	❌	❌	❌	❌	❌	🔴 待补全
MDS-D	❌	❌	❌	❌	❌	🔴 待补全
OPS-D	❌	❌	❌	❌	❌	🔴 待补全
DIS-D	✅ DispatchOrder	✅ 3 实体	✅ 6 VO	✅ DispatchMatchingService	✅ 3 仓储	🟢 完成

5.3.3 DDD 方法引入要求（阶段二统一标准）¶

项	要求	参考文档
子域定位表	标注核心/支撑/通用 + 现阶段定位	DIS-D §2.1
限界上下文图	Mermaid 含本服务 BC + 外部 BC	DIS-D §2.2
上下文映射表	OHS/ACL/PL/SK/CS/OHS 明确标注	DIS-D §2.3
聚合根定义	名称 + 唯一标识 + 不变量 + 边界	DIS-D §四
领域事件清单	事件名 + 触发条件 + 订阅方	DIS-D §四
防腐层设计	外部上下文→内部 VO 转换规则	DIS-D §2.3

5.4 业务用例覆盖度核查¶

5.4.1 当前用例分布¶

服务	用例位置	用例数	覆盖度
CPT-D	CPT-UC-用例库 V1.0（典型8 + 异常8）	16	🟢 高
QSV-D	QSV-UC-用例库 V1.0（典型5 + 异常5）	10	🟢 高
MDS-D	MDS-UC-用例库 V1.0（典型5 + 异常5）	10	🟢 高
OPS-D	OPS-UC-用例库 V1.0（典型5 + 异常5）	10	🟢 高
DIS-D	DIS-UC-用例库 V1.0（典型5 + 异常5）	10	🟢 高

5.4.2 期望用例扩充目标¶

服务	期望典型用例	期望异常用例	合计目标
QSV	① 标准家居（家具）② 灯具安装 ③ 卫浴（含楼宇系数）④ 家电（家电系数）⑤ 智能家居（技能等级乘数）	加价险触发 / 封顶价 / 师傅超能力拒绝 / 增项报价	8-10
CPT	L1~L8 各 1 个典型 + 跨阶段流转	流失/异常池/跨阶段回退/重新报价/换师傅/客诉升级	14-16
MDS	六库新增/更新/查询 + 标签变更	师傅等级降级 / 楼宇系数过期 / 客户标签冲突	8-10
OPS	6 场景各 1 个典型 + 推荐激励流程	推荐客户重复 / 物料版本冲突 / 渠道失效	8-10
DIS	① M3 合同匹配 ② M1 自营调度 ③ M2 独立司机 ④ 跨模式降级 ⑤ OL 人工调整	司机拒绝/保险触发/超时/全模式不可用/合同匹配失败	8-10
合计	—	—	✅ 实际 56 = CPT 16 + QSV 10 + MDS 10 + OPS 10 + DIS 10（目标 46-56 已达成）

5.4.3 用例文档化形式¶

新增独立用例库 docs/业务测试/用例/：

docs/业务测试/
├── 原型/             # 5 端 62 页（登录页 5 + 非登录页 57）
└── 用例/             # V3.2 已建成
    ├── README.md     # UCL V1.2 用例总索引（按服务/典型/异常分类）
    ├── QSV-UC-用例库.md     # 单文档含 QSV-UC-01~10（典型5+异常5）
    ├── CPT-UC-用例库.md     # 单文档含 CPT-UC-01~16（典型8+异常8）
    ├── MDS-UC-用例库.md     # 单文档含 MDS-UC-01~10（典型5+异常5）
    ├── OPS-UC-用例库.md     # 单文档含 OPS-UC-01~10（典型5+异常5）
    └── DIS-UC-用例库.md     # 单文档含 DIS-UC-01~10（典型5+异常5）

每份用例须包含： - 用例编号（<服务>-UC-NN） - 用例名称 + 分类（典型/异常） - 触发条件 + 前置条件 - 主流程步骤（含数据样例） - 异常分支与处理动作 - 关联原型页面（data-comp-id） - 关联服务设计章节 - 关联需求条目（RQD-XX-NN）

5.5 原型与用例关联度核查¶

5.5.1 原型盘点（当前 5 端 62 页 = 登录页 5 + 非登录页 57）¶

终端	目录	HTML 数	主要场景	缺口识别
OPR 运营后台	`原型/opr-admin/`	24	仪表盘/线索/报价/订单/楼宇/品类/师傅/客户/推荐/物流/派单调度 + OPS 运营 5 页（驾驶舱/投放/物料/口碑/漏斗）	✅ 已完成：dispatch.html 派单管理/调度页（阶段一-5 落盘；2026-08-21 扩展安装三模式候选池）；✅ 补 OPS 运营 5 页（ops-cockpit/ops-campaigns/ops-materials/ops-reputation/ops-funnel）
CST 客户端	`原型/cst-app/`	11	下单/订单/验收/回访 + 异常订单/加价险购买	✅ 已完成：异常订单（order-exception.html，CPT L7 客诉升级）+ 加价险购买页（cst-insurance.html，C1 98 vs C5 258 双档推荐）
WKR 师傅端	`原型/wkr-app/`	10	接单/安装/完工/上传 + 保险确认/拒绝接单	✅ 已完成：保险确认页（wkr-insurance.html，C7 签字 + 扣分说明）+ 拒绝接单页（wkr-reject.html，2 连拒 -25 分 + 挂起 30m）
MFR 生产商端	`原型/mfr-portal/`	9	委托/产品/订单/结算	较完整
LGP 物流商端	`原型/lgp-app/`	8	待接/进行中/完成/详情 + 保险确认/接单确认	✅ 已完成：保险确认页（lgp-insurance.html，跨境投保 8800×1.5%）+ 接单确认页（lgp-accept.html，M2 运单取件码 + SLA）

5.5.2 原型 data-* 关联属性规范¶

属性	用途	示例	当前使用情况
`data-comp-id`	组件唯一ID	`OPR-DASH-01.KPI.01`	✅ 顶层+子元素全量注入（阶段二-9 47 页顶层×6属性全量 + 阶段三-8 11 缺口页子元素 36 张关键卡/按钮/漏斗再注入）
`data-comp-desc`	组件描述	`今日新增线索 KPI 卡`	✅ 顶层+子元素全量注入（子元素中文描述≥10字，annotate.js V1.1 Ctrl+Hover 分色解析正常）
`data-req-ids`	关联需求ID（多值逗号分隔）	`F-OPS-001,F-CPT-065`	✅ 顶层+子元素全量注入（子元素均挂 RQD-B xx/RQD-O xx 需求段编号）
`data-service-id`	关联服务设计文档	`DIS-D` / `CPT-D §2.1`	✅ 顶层+子元素全量注入（阶段二-9 47 非登录页 × 720 元素 6 属性全量；阶段三-8 再补齐 11 新页共 36 子元素；annotate.js V1.1 解析）
`data-usecase-id`	关联用例ID（多值）	`DIS-UC-01,DIS-UC-05`	✅ 顶层+子元素全量注入（56 用例 UCL V1.2；dispatch 候选池三模式 + 11 新原型页共 36 子元素扩展补齐）
`data-source-ref`	关联源头调研/业务设计文档	`DOC-P50 §三` / `DOC-P71-D §6`	✅ 顶层+子元素全量注入（DOC-P2~DOC-P71 + ADR编号调研源已在原型各卡 data-source-ref 标注）

5.5.3 Ctrl+Hover 交互实现¶

原型 HTML 已注入 assets/js/annotate.js V1.1（扩展自原 comp-hover.js）：

触发：用户按住 Ctrl 键 + 鼠标悬停组件
弹出样式：5 行 pill 分色解析（需求深蓝 / 服务青绿 #2a9d8f / 用例海蓝 #457b9d / 调研沙金 #D4AF78 / 组件 ID）
弹出内容：组件描述 + 关联服务（data-service-id）+ 关联需求（data-req-ids）+ 关联用例（data-usecase-id）+ 关联调研（data-source-ref）
跳转：点击弹层中的链接，跳转到对应文档锚点

5.6 跨文档一致性核查清单¶

#	检查项	期望状态	当前状态	责任人	后续动作
1	术语统一（GLY）	所有文档术语与 GLY V4.7 一致	🟢 已完成	DT	—
2	服务编号统一	DOC-P31/41/51/61/71 编号一致	🟢 已完成	DT	—
3	交叉引用路径	全部相对路径	🟢 已完成	DT	—
4	三模式派单术语	M1/M2/M3 + DME/INS-CFM 统一	🟢 已完成	DT	—
5	DIS 与其他服务关系图	5 服务互相引用一致	🟢 已完成	DT	—
6	CPT L5 → DIS 触发关系	CPT-D §L5 + DIS-D §三对齐	🟢 已完成	DT	—
7	MDS → DIS 主数据供给	MDS-D §供给表 + DIS-D §依赖对齐	🟢 已完成	DT	—
8	DLV → DIS 物流商档案引用	DLV + DIS 边界清晰	🟢 已完成	DT	—
9	RQD-B 派单需求归属 DIS	LGP-03/DSP-01~06 归属 DIS	🟢 已完成	DT	—
10	RQD-O 派单功能组归属 DIS	DSP 功能组归属 DIS	🟢 已完成	DT	—
11	平台服务架构表含 DIS	PJM §1.2 含 DIS 行	🟢 已完成	DT	—
12	文档导航表含 DIS	PMG / PJM 导航含 DIS	🟢 已完成	DT	✅ PMG agents.md §服务与技术文档 DIS 行（V8.0 已挂）；PJM §1.2 平台服务架构表含 DIS 行；§5.7.1 服务边界连续图含 DIS 节点
13	QSV-D DDD 补全	子域/BC/聚合根完整	🟢 已完成（V1.2 §三/§四：QSV报价战略子域 + PricingEngine 9步伪代码）	DT	—
14	CPT-D DDD 补全	子域/BC/聚合根完整	🟢 已完成（V2.5 §二/§三：CPT客户项目跟踪2BC + CustomerProject 8阶段状态机）	DT	—
15	MDS-D DDD 补全	子域/BC/聚合根完整	🟢 已完成（V1.3 §二/§三：MDS 2子域2BC + MasterDataCatalog 6库6状态）	DT	—
16	OPS-D DDD 补全	子域/BC/聚合根完整	🟢 已完成（V2.1 §二/§三：3BC获客/物料/口碑 + 3聚合根×4不变量 + 3台状态机）	DT	—
17	用例库独立成册	5 服务 46-56 用例	🟢 已完成（56=CPT16+QSV10+MDS10+OPS10+DIS10，UCL V1.2总索引）	DT	—
18	原型补充派单管理页	dispatch.html 落地 + 安装三模式候选池扩展	🟢 已完成	DT	✅ 阶段一-5 dispatch 派单页落盘；2026-08-21 扩展安装师傅 M1_SELF/M2_FREE/M3_SME 三列候选池 + 今日派单记录安装类型列
21	DIS 安装师傅三分类	WPL REGISTER_TYPE + DIS-D 双轴 3×3=9 组合矩阵 + dispatch 可视化	🟢 已完成	DT	✅ WPL V1.2 REGISTER_TYPE Enum 三分类 + 4 不变量；DIS-D V1.1 §6.1.4-6.1.7 安装三模式 + 9 组合（加权运输×0.55 + 安装×0.45）；dispatch.html 三列卡片 + 安装类型 badge 列
22	原型 11 缺口页补做	OPS 运营 5 页 + CST 2 页 + WKR 2 页 + LGP 2 页	🟢 已完成	DT	✅ ops-cockpit/ops-campaigns/ops-materials/ops-reputation/ops-funnel（OPS 运营驾驶舱布局优化版）+ order-exception/cst-insurance（客户异常+加价险）+ wkr-insurance/wkr-reject（师傅保险+拒单）+ lgp-accept/lgp-insurance（物流商接单+投保）共 11 页极简框架
19	原型 data-service-id 属性	5 端全量补充	🟢 已完成（47非登录页×720元素 6属性全量注入；annotate.js V1.1 Ctrl+Hover解析）	DT	—
20	Ctrl+Hover 脚本	comp-hover.js 落地	🟢 已完成（扩展 annotate.js V1.1）	DT	阶段一-5 完成
23	TND V2.0 D01-D10 文档完整性	D01架构/D02报价/D04派单/D10MDS主数据+D05/6/7/8/9/3三合一合并 ≥7.md首版	🟢 已完成	DT	✅ docs/技术文档/ 目录：系统总体架构设计(D01)+MDS主数据(D10)+报价引擎(D02)+订单派单(D04)+B端对接与安全三合一(D05+D06+D07)+师傅端跟踪表楼宇三合一(D08+D09+D03) 共7份.md首版（实际覆盖D01-D10编号10项）；TND README V3.2 挂表同步
24	OpenAPI 136+ 路由向后兼容 + /v2 新契约	原有V3.3 136路由零改动；新增5服务×~175 operationId 全写/v2前缀YAML	🟢 已完成	DT	✅ docs/技术文档/openapi/qsv.yaml+mds.yaml+dis.yaml+cpt.yaml+ops.yaml 共5份 OpenAPI 3.0.3 契约；双鉴权（Bearer JWT + InternalSecret Kong内部头）；保留/api/v1/旧路由无改动；新路由统一/api/v2/前缀
25	Alembic 0003~0007 纯增量零破坏	5份迁移仅 ALTER TYPE ADD VALUE + CREATE TABLE 新表 + ALTER TABLE ADD COLUMN；零 DROP/零原列 ALTER	🟢 已完成	DT+WDE	✅ D01 §3.2 兼容性铁律；D02 0004 qsv新增表；D04 0005 DIS/CPT新增；D05/6/7 0006 B端+三方+安全；D08/09/3 0007 CPT183字段9表+视图；全部设计为纯增量，V3.3 原有22表22列零破坏
26	原型11缺口页子元素全量注入	每页≥3关键功能子元素×data-* 6属性非空；annotate.js Ctrl+Hover解析	🟢 已完成	DT	✅ OPS5+CST2+WKR2+LGP2 共11页注入36个功能子元素（cockpit6个最豪华+其余每页3个）；抽查cockpit6卡+wkr-reject3卡 6属性全非空；备份目录 backup-t3-8-20260822003123 留存
27	3处OCM听云专属评审加签权标注	D01 部署+ADR010/014/016；D06第三方9项清关；D07 PDPO6库+密钥轮转+审计7年	🟢 加签表就位待OCM签字	DT+OCM	✅ D05+D06+D07文档三处已显式写OCM必须加签红色提示；字段：加签章节/OCM责任人/TL签字/日期/评审意见；OCM/TL双人电子签字后生效
28	12角色Keycloak RBAC + PG RLS策略SQL就绪	4终端角色(CST/WKR/MFR/LGP)+OPR6角色(PO/TL/OL/ML/FL/AUDIT)+SUPER；pg_catalog行级RLS	🟢 设计落地SQL样例	DT+OCM	✅ D05/6/7 §四 §五 12角色×5门户×88服务路由 RBAC矩阵；PG 5库(CPL/WPL/PPL/DLV/QSV报价快照) RLS策略SQL样例；D01 ADR-010 Keycloak；V3.3 听码实现阶段直接参考

5.7 业务设计连续性核查¶

5.7.1 服务边界连续性¶

graph LR
    subgraph 主数据供给
        MDS["MDS 主数据服务<br/>六库供给"]
    end
    subgraph 业务服务
        QSV["QSV 报价"]
        CPT["CPT 跟踪"]
        OPS["OPS 运营"]
        DIS["DIS 派单"]
    end
    subgraph 端
        CST["CST 客户端"]
        WKR["WKR 师傅端"]
        MFR["MFR 生产商端"]
        LGP["LGP 物流商端"]
        OPR["OPR 运营后台"]
    end

    MDS -->|SCL/BPL/WPL/CPL/PPL/DLV| QSV
    MDS -->|主体档案ID| CPT
    MDS -->|CPL/WPL 画像| OPS
    MDS -->|DLV 物流商档案| DIS

    OPS -->|L1 线索| CPT
    QSV -->|L3 报价| CPT
    CPT -->|L5 物流单事件| DIS
    DIS -->|派单决策| LGP
    DIS -->|保险预警| OPS
    CPT -->|L8 NPS 反哺| OPS
    CPT -->|实际数据反哺| MDS

    CST --> CPT
    MFR --> CPT
    WKR --> CPT
    LGP --> DIS
    OPR --> CPT
    OPR --> DIS

5.7.2 阶段演进连续性¶

阶段	时间	服务启用	原型启用	用例覆盖
筹备期	1-3 月	QSV/CPT/MDS	OPR+CST+WKR	阶段二补全
试运营	3-6 月	+ OPS	+ MFR	阶段二补全
扩张期	6-12 月	+ DIS（M3 为主）	+ LGP + dispatch	阶段二补全
成熟期	12-24 月	DIS M2 启用 + C2C	全端	阶段三补全

5.8 阶段化核查执行计划¶

阶段	任务	交付物	状态
阶段一-4（本节）	PJM 完整性核查专章 + DIS 入 PJM 架构表	PJM V3.1 §五	🟢 已完成
阶段一-5	原型补充 dispatch.html + 5 端 data-* 属性补全 + comp-hover.js	1 新页 + 52 页属性补 + 1 脚本	🟢 已完成（派单页 + annotate.js V1.1 + 阶段二-9 其他端 47 页 720 元素全量补）
阶段一-6	验证 + commit + DTL-06 日志 + PMG 导航表同步	commit + DTL-06	🟢 已完成（见 DTL 日志目录）
阶段二	4 服务 DDD 重构（QSV/CPT/MDS/OPS）+ 用例库建设（56 用例 = CPT16+QSV10+MDS10+OPS10+DIS10）+ 原型↔用例关联（47 页 data-* 全量）	QSV V1.2/CPT V2.5/MDS V1.3/OPS V2.1 DDD + UCL V1.2 5 用例库 V1.0 + 47 页 720 元素注入	🟢 已完成
阶段三	技术设计准备（TND 文档升级 + 架构图 + API 契约）	TND V2.0	🟢 已完成（2026-08-21：7份独立/合并.md覆盖D01-D10全号段 + 5份OpenAPI 3.0.3 YAML + Alembic 0003~0007纯增量迁移 + 原型11页子元素36卡6属性再注入）
阶段四	听码WDE按TND V2.0编码（dip1/ V3.4首版）	dip1/ 后端+前端+部署	🟢 已完成（2026-08-22 WDE首版：后端5服务DDD四层165路由+44表Alembic 0001+269 pytest全绿 + 前端pnpm monorepo + OPR Next.js14驾驶舱 + 部署8服务docker-compose/Kong/Keycloak；遗留9项划分OCM/WDE下一阶段；详见WDL L-20260822-01/02）
阶段五	听云OCM生产部署准备 + 三处加签 + 5项OCM专属遗留点	阿里云生产环境 + 三处加签生效 + 第三方联调	⏸ 待TL签字触发（听写DT已起草启动指令 DTL L-20260822-13，听云OCM接收后写首份OCL日志）

5.9 核查结论（V3.4 阶段三TND V2.0完成，30 项清单 = 30 🟢 + 0 🟡 + 0 🔴）¶

完整性：5 服务 DDD 全部落地（QSV V1.2/CPT V2.5/MDS V1.3/OPS V2.1/DIS V1.1），5 服务架构 + 6 库主数据供给闭环；业务用例库 56 篇全量建成（CPT 4典型+12异常 / QSV 5典型+5异常 / MDS 5典型+5异常 / OPS 5典型+5异常 / DIS 5典型+5异常）；原型 57 非登录页 × 6 data-* 属性 100% 注入（原 47 页 + 新增 11 页缺口补做 = OPR24/CST11/WKR10/MFR9/LGP8 共 62 页 HTML，登录页 5 不计）；DIS 派单双轴三模式完整闭环（运输轴 M1自营车/M2个体物流商/M3物流公司 × 安装轴 M1_SELF自营师傅/M2_FREE个体注册/M3_SME签约小B = 3×3=9 组合矩阵，加权公式：综合分 = 运输分×0.55 + 安装分×0.45；CPT L5小众品类 ≥2 M2 强制、MFR批量强制 3-3 组合）。
一致性：BAS V1.0 业务架构稳定基线已建立（§六 DDD 实施规范 8 要素统一模板 + §七变更治理 TL 审批机制）；术语 GLY V4.7 新增 DIS/DME/INS-CFM/BAS 5术语统一；服务编号 DOC-P31~P71 连续无跳号；DSP→DIS 归属遗留全量修复；OPS-D §九.9.5 五服务协同图补 PPL/DLV/DIS 三方 + 3 BC 配色，与 BAS §三 C4 总图一致；DIS 安装三分类与 WPL REGISTER_TYPE Enum 严格对齐（WPL-006a 字段 + WPL-006b M3_SME 必绑 PPL 企业 ID），dispatch.html 可视化三列候选池 + 今日派单记录安装 badge 列与 WPL/DIS-D 100% 对应；OPS 运营驾驶舱 ops-cockpit.html（6KPI×2行 + 漏斗CAC + NPS分档 + 场景物料口碑三卡） 替换原 admin.html RBAC 页作为 OPS 全局驾驶舱，响应"布局不好"的用户反馈。
连续性：阶段演进表筹备期→成熟期四阶段连续；§5.7.1 服务边界数据流图（MDS→4业务→5端完整链路）与 5 服务 DDD ACL 映射 1:1 对齐；OPS ACL 只读不写 + CPT→MDS 写回链路闭环保证架构边界成熟期前不会擅自演进；碎片化设计修补→PJM §五立即同步机制已落地（本次 4 条用户指令 → WPL V1.2/DIS-D V1.1/11 原型页补做/dispatch.html 扩展 → PJM V3.2→V3.3 同步 7 处 §5 段落 + #12🟡→🟢 + 新增 #21/#22 🟢，三性核查清单永远 100% 最新）。

阶段三 TND V2.0 技术设计升级完成段（V3.4 追加 2026-08-22）¶

TND文档完整性（7份.md覆盖D01-D10全号段）：D01系统总体架构设计（12章、C4容器5服务DDD+5端、6张Mermaid拓扑、18条ADR含ADR-010 Keycloak/014可观测/016加密3处OCM必须加签）；D10 MDS主数据（26表=V3.3 22表+4新增PPL/DLV主+合同/C7赔付、校准4通道Mermaid+NATS DLQ、6库AES-256-GCM L1~L4分级）；D02报价引擎（8大参数32因子、PricingEngine聚合根4不变量+calc()9步公式伪代码、DME运输三模式公式矩阵、封顶价策略、JSON/Drools双引擎抽象端口）；D04订单派单（CustomerProject 6不变量+8阶段状态机、DIS派单6步+9组合C11~C33综合分公式、DispatchOrder 5不变量DIS I3连拒扣-25+黄牌、3候选拒单降级、C7四档赔付表、L7客诉SAGA 5服务Choreography补偿链+持久化表DDL）；D05+D06+D07三合一（MFR开放报价桥代码样例+LGP流程Mermaid+Alembic 0006；第三方对接9项电商3/中港2/支付4+Kong治理+清关红线OCM加签1/3；5层安全+Keycloak 12角色RBAC矩阵+PG RLS策略SQL样例+AES双信封90天轮转+Maker-Checker+sec_audit_log append-only RULE 7年审计OCM加签2/3+3/3）；D08+D09+D03三合一（Expo SDK51依赖、L6三重校验GPS/时间/照片TypeScript Hook、SQLite离线24h队列、DIS I3挂起全屏Overlay组件；8阶段183字段=18+24+28+15+20+30+17+31、Alembic 0007纯新建9表+完成率自动视图；PostGIS 3.4 三几何列+GIST索引+50m围栏触发器plpgsql+L6 ST_DWithin打卡校验+DIS 5km半径师傅查询+pg_trgm地址相似度）。
5份OpenAPI 3.0.3契约 + Alembic 0003~0007纯增量兼容保证：qsv.yaml(×25)+mds.yaml(×40 OHS供给)+dis.yaml(×35 Core/OL/LGP/WKR/C7/SAGA)+cpt.yaml(×40 Lifecycle/Pool/Collect/Exception/NPS)+ops.yaml(×41 Cockpit/Campaigns/Materials/Reputation/Funnel/Lead) 合计≥175 operationId；双鉴权Bearer JWT(Keycloak)+InternalSecret(Kong内部)；V3.3原有136路由/api/v1/零改动，新增路由统一前缀/api/v2/并存；Alembic 0003~0007迁移全部设计为纯增量：ALTER TYPE qsv/xx_enum ADD VALUE新值；CREATE TABLE qsv_dis_/mds_ppl/mds_dlv/cpt_183/dlq/sec_audit_新表；ALTER TABLE 原表 ADD COLUMN新增列；零DROP TABLE/零ALTER COLUMN原列修改，保证V3.3 dip1/data/migrations.sql原有22表100%向后兼容。
原型11缺口页子元素6属性再注入（阶段三-8）：OPS 5页（cockpit6卡+campaigns3+materials3+rep3+funnel3）共18子元素；CST 2页（exception3+ins3）共6；WKR 2页（ins3+rej3）共6；LGP 2页（acc3+ins3）共6；合计36子元素data- 6属性100%非空；抽查cockpit 6卡+wkr-reject 3卡 6属性全非空 annotate.js Ctrl+Hover 解析正常。向后兼容保证：所有原47页阶段二注入的顶层data-零改动，仅11新页在子元素层二次注入，DOM结构/class/style零破坏。

下一里程碑：听码 WDE 按 TND V2.0 启动 dip1/ V3.4 编码阶段（5服务 FastAPI 后端 + 5端 Next.js SSR + RN Expo SDK51 前端 + Alembic 0003~0007 迁移按纯增量顺序执行）；OCM 听云完成 D01/D06/D07 三处加签后，TND V2.0 权威技术规范正式生效。

当前核查清单总览：🟢×30 项（原 #1-22 24🟢 + 新增 #23-#28 TND V2.0 6🟢 = 合计 30🟢） / 🟡×0 项 / 🔴×0 项 → TND V2.0 技术设计升级三性核查通过（PASS · V3.4 听码编码唯一权威依据）

六、关键约束与原则¶

数据准确：参数与数据须标注来源，不确定信息须标注
保密合规：客户/师傅信息、商业机密不得外泄
格式一致：跨文档术语统一（见 GLY）；遵循品牌视觉规范
相对路径：所有文档引用一律相对路径，确保项目迁移有效
效率优先：减少不必要交互；明确指令直接执行
流程图规范：所有流程图统一使用 Mermaid 语法，禁止 ASCII 字符画流程图

七、修订记录¶

版本	日期	修订人	修订内容
V1.0	2026-08-04	DT	首版创建，从 PMG 迁移项目管理制度内容
V1.1	2026-08-04	DT	§5 新增第6条：流程图统一使用 Mermaid 语法
V1.2	2026-08-04	DT	§2.6 新增流程图规范，与 §5 形成呼应
V1.3	2026-08-04	DT	§4.4 新增文档版本与归档机制（版本规范/触发条件/目录结构/命名规范/操作规范）
V1.4	2026-08-05	DT	§4.4.5 新增「非递归性」原则与递归防护要求；新增 §4.4.6 归档类型与策略（全量/增量/指定部分）；修复 V1.0 归档递归问题
V1.5	2026-08-05	DT	§4.4.6 全量归档命令移除 ref 复制；新增归档排除范围说明（ref/、临时文件、.git/、IDE 配置）；校验脚本新增 ref 排除检查
V1.6	2026-08-05	DT	§3.1 角色缩写速查表新增「现任人员」列（曾总/郭总/司徒总/成文/黄总/洪哥）；§3.3 OL 角色补充双人分工说明（成文客户运营/黄总落地执行）；基于 2026-08-05 核心运营团队内部讨论
V1.7	2026-08-06	DT	§4.3 版本管理与 Git 系统化扩展（原 3 行扩展为 6 小节）：仓库清单（私有主仓 + 公开文档镜像仓）、轻量 Git Flow 分支策略（main/dev/feature）、提交规范（5 类型 + 示例）、版本控制范围（纳入/排除对照表 + .gitignore）、发布目录机制（与 PMG AI 特定行为同步）、公开文档同步（脚本原理 + 执行步骤）；成为团队 Git 操作唯一权威依据
V1.8	2026-08-06	DT	§4.3 新增 §4.3.7 文档站点发布（MkDocs Material + Cloudflare Pages）：可交互在线文档站点作为第二条对外发布路径（搜索/导航/Mermaid 原生渲染/深色模式）；新增 `mkdocs.yml`+`build-site.py`+`deploy-site.ps1`；源文件零修改原则（链接重写仅作用于 `.build/` 临时副本）；§4.3.4 版本控制范围表新增 `mkdocs.yml`（纳入）与 `site/`、`.build/`（排除）；与 §4.3.6 公开镜像仓并行
V1.9	2026-08-06	DT	§4.4.5 归档原则第 6 条「Git 双备份」修正为「本地备份」：归档目录不纳入 Git 远程仓库（`.gitignore` 排除 `docs/归档/`，避免含 PDF 成品的归档包膨胀仓库体积），消除规范与执行矛盾（依据 DLG-46 §七用户决策）
V2.0	2026-08-06	DT	§4.3.5 AI 特定行为输出目标表新增 git同步与公开文档同步两行，并添加执行约束说明（需用户直接指令，AI 不得自动触发）；与 PMG V7.7 §AI特定行为同步
V2.1	2026-08-07	DT	§4.3.7 文档站点发布新增「URL 短路径重写机制（slug 方案）」：扁平化 slug 命名（术语缩写 3-5 字符）+ 全量链接重写 + basename 回退；文件清单新增 `scripts/url_map.py`；构建警告从 60+ 降至 9（均为根级文件引用）
V2.2	2026-08-09	DT	新增 §3.4 DIP1 独立技术开发子项目管理（承接 TND-E 阶段 1+2 代码实施）：§3.4.1 子项目关系图（与主仓同 Git 仓 dip1/ + docs/技术文档/dip1/ 双区，发布共用发布/dip1/）；§3.4.2 RACI 对齐新增「DIP1 Code Agent」独立角色（严禁 Git Commit/Push，仅写本地文件；生产凭据零持有）；§3.4.3 交付物跟踪矩阵唯一真值入口（DIP1-IMP §7.1，3组24项红黄绿矩阵，文档10/10🟢 / 代码85人天🟡 / 部署UAT🟡，加权完成度 10%，SPO/BO 零背景即可评估）；§3.4.4 升级越权防护机制（24h阻塞升级路径+文档版本回溯）；§2.3 进度管理新增 DIP1 独立进度跟踪三色标准；§4.3.1 仓库清单主仓说明新增 DIP1 入仓规范（代码 dip1/ 暂不纳入发布 PDF，文档 docs/技术文档/dip1/ 全量纳入发布）；§4.3.2 分支策略新增 DIP1 feature 分支前缀规范 `feature/dip1-` + PR 标题前缀 `dip1:`；§4.3.4 版本控制范围隐含确认 DIP1 代码纳入 Git、发布目录 dip1/ 纳入 Git；§4.3.5 发布目录机制隐式对齐 DIP1 汇总 PDF 生成（PMG AI 特定行为 #1）与状态矩阵快速入口
V2.3	2026-08-09	DT	DIP1 目录合并 + 工作日志接入：§3.4.1 子项目关系图 D_DOC 节点从 `docs/技术文档/dip1/` 更新为 `dip1/docs/`（代码+文档一体化自包含），新增 DWLG 节点展示双层工作日志机制（子项目层 dip1/docs/worklog/ → TL 审核 → 主仓层 docs/工作日志/）；§3.4.3 跟踪矩阵路径同步；§3.4.5 新增「工作日志机制（双层 WLG）」专章（子项目层 DWLG-YYYYMMDD-NN + 主仓层 DLG-NN + 6 种 TL 同步触发条件 + Code Agent 越权防护）；§2.3/§4.3.1 路径引用全部从 `docs/技术文档/dip1/` 更新为 `dip1/docs/`；关联文档 DIP1 链接同步更新
V2.4	2026-08-09	DT	新增 §4.4 子项目反馈机制（SFM）+ §4.5 跨子项目协作机制（承接用户指令"子项目向主项目反馈+相互确认+统筹WLG+多子项目扩展+跨Code Agent协作+人类干预最小化"）：§4.4.1 5项目标+核心原则（WLG同构复用）；§4.4.2 总体架构Mermaid图（4层：子项目层/反馈通道4类/处理层7状态机/主仓层）；§4.4.3 5类型×3级别反馈分类矩阵+处理矩阵；§4.4.4 7状态双向确认状态机+5条超时自动升级规则；§4.4.5 反馈与DWLG双向引用机制+TL同步DLG触发条件扩展为8项（新增周反馈简报+Critical闭环）；§4.4.6 分级响应模型量化TL周成本≈45min+6项听写自动化辅助+SPO/BO零介入边界4条；§4.5.1 多子项目编号体系扩展（DWLG→DIP2WLG→SWLG）+子项目新增流程5步；§4.5.3 Git Issue全局标签6类命名空间；§4.5.4 跨项目Code Agent交互协议4场景+共享契约仓结构+4条沟通约束；原§4.4归档机制整体重编号为§4.6（4.4.x→4.6.x），保持内容不变
V2.5	2026-08-09	DT	§3.4 DIP1 原生 App 方案升级同步（对齐 DIP1-ARC V2.0 ADR-008）：① §3.4 定位从「阶段 1 飞书对接 + 阶段 2」调整为「跳过阶段 1，直接实施阶段 2 原生 App 方案」，师傅端 PWA→React Native（wkr-app）+ 新增客户端 React Native（cst-app）+ Expo managed workflow + EAS Build/Submit/Update + NativeWind；② §3.4.1 关系图 D_CODE 节点新增「opr-admin Web + wkr-app RN + cst-app RN」、D_DOC 节点标注 V2.0 版本号、F1 节点标注⏸ 暂不实施、F2 节点 18 表→22 表；③ §3.4.2 RACI 表架构决策 10 ADR→13 ADR、飞书对接/数据迁移行标注⏸ 跳过、新增「移动端 RN 开发」与「CST 限界上下文+移动认证+推送」行、85 人天→105 人天、生产凭据新增 App Store/Google Play；④ §3.4.3 跟踪矩阵文档 V1.0→V2.0、代码 85→105 人天（4 阶段新拆分：§0 9+§2 49+§3 32+§3 移动基建 5+§4 10）、部署新增 EAS Build/App Store/Google Play/OTA；⑤ §3.4.5 + §4.4.5 TL 同步触发条件表全面更新（6→8 项，对齐 4 阶段实施计划）；⑥ §2.3 DIP1 进度跟踪描述同步；⑦ §4.3.1 DIP1 仓库说明更新前端 Monorepo 三端 + 阶段 1 ⏸ 标注
V2.6	2026-08-11	DT	新增 §3.5 听云（WCL）生产运维管理（承接用户指令"将生产环境操作部署工作交给听云 WCL，承担全部生产环境和客服工作"）：① §3.1 角色缩写速查表新增听写（DT）/听码（WDE）/听云（WCL）三个 AI 智能体角色 + AI 智能体分工说明；② 新增 §3.5 听云生产运维管理（5 小节）：§3.5.1 听云与听码职责边界对照表（8 维度）+ 协作闭环原则、§3.5.2 RACI 对齐（10 任务×6 角色矩阵，含 WDE/WCL 列）、§3.5.3 OWLG 双层工作日志机制（运维层 ops/worklog/ + 主仓层 DLG + 5 种 TL 同步触发条件）、§3.5.4 文档公开/私有划分原则（5 条判定红线）、§3.5.5 升级与越权防护机制；③ §4.3.1 仓库清单主仓说明新增 ops/ 目录、公开仓说明新增 ops/public/、新增 ops/ 目录说明段；④ §4.3.4 版本控制范围新增 ops/ + ops/public/ + ops/private/ + ops/worklog/ 4 条 + dip1/ 条目 + 生产环境真实凭据文件排除条目 + ops/private/ 安全提示；⑤ §4.3.6 公开文档同步新增同步项对照表（8 项明确同步/不同步），ops/public/ ✅ 同步、ops/private/ + ops/worklog/ ❌ 不同步；⑥ §4.4 SFM 定位扩展：适用对象新增听云（WCL），明确听码与听云使用相同反馈分类矩阵+状态机+超时规则；⑦ §4.5.1 多子项目编号体系新增听云 OWLG-YYYYMMDD-NN 条目；⑧ §4.5.3 Git Issue 全局标签新增 role:wde/role:wcl 角色标签 + ops:deploy/incident/integration/ticket 运维场景标签；⑨ 关联文档新增听云工作手册 + ops/ 目录索引
V2.7	2026-08-11	DT	新增「文档自主权原则」（对齐听云 WCL 工作手册 V1.2 + 听码 DIP1-IMP V2.1）：① §3.4.2 RACI 表后新增「文档自主权原则」说明段——明确"DIP1 10 份自有文档创建"行的 A=TL 指内容正确性审批，非文件结构审批，听码自主决定 `dip1/docs/` 下文档结构；② §3.5.1 职责边界对照表新增「文档自主权」维度行——听码 ✅ 自主决定 `dip1/docs/` 文档结构，听云 ✅ 自主决定 `ops/` 文档结构（含 `admin-manual/`、`service-manual/`、`private/credentials/` 等）；③ §3.5.2 RACI 表新增「工作目录文档结构自主决策」行——WDE/WCL 为 R（自主决策），TL 为 A（内容评审，非文件结构审批）；④ §3.5.2 RACI 表后新增「文档自主权原则」说明段——核心理念：人类只在职责层面定义边界，AI 协作者自主决定其工作目录下的文档结构，实现人类干预最小化
V2.8	2026-08-18	DT	§3.1 角色表新增 MFR/LGP 干系方（对齐 GLY V4.5）；§3.1 角色缩写速查表补全 MFR/LGP/SCENE 等术语引用，与 GLY V4.5 同步
V2.9	2026-08-20	DT	运维目录重命名 ops/ → ocm/ + 听云角色简称 WCL → OCM + 工作日志前缀 OWLG → OCL（承接用户指令"ops→ocm 批量替换"）：① §3.1 角色缩写速查表听云角色简称 WCL → OCM（保留 Weaver Cloud Listener 英文全称与"听云"中文角色名不变）；② §3.5 听云生产运维管理章节：标题/定位/职责边界对照表/RACI 矩阵列头/工作日志机制/文档公开私有划分/升级路径中所有 WCL→OCM、`ops/`→`ocm/`、`OWLG-YYYYMMDD-NN`（格式定义）→`OCL-YYYYMMDD-NN`、`OWLG 工作日志记录`→`OCL 工作日志记录`、`Issue+OWLG`→`Issue+OCL`；③ §3.5.3 双层工作日志机制标题由"OWLG · 对齐主仓"改为"OCL · 对齐主仓"；④ §3.5.2 表后文档自主权原则段链接 `[听云工作手册](../ops/WCL-听云工作手册.md)`→`[听云工作手册](ora1i.md)`；⑤ §4.3.1 仓库清单主仓说明 `ops/，听云 WCL 工作目录`→`ocm/，听云 OCM 工作目录`、公开仓 `ops/public/`→`ocm/public/`、`ops/ 目录说明`段重命名为 `ocm/ 目录说明` 并更新内部路径；⑥ §4.3.4 版本控制范围 4 条 ops/ → ocm/ + `OWLG-YYYYMMDD-NN`→`OCL-YYYYMMDD-NN` + `ops/private/ 安全提示`→`ocm/private/ 安全提示`；⑦ §4.3.6 公开文档同步表 3 行 `ops/`→`ocm/`；⑧ §4.4 SFM 定位听云（WCL）→听云（OCM）、`Issue+OWLG`→`Issue+OCL`、`DWLG vs OWLG`→`DWLG vs OCL`；⑨ §4.5.1 多子项目编号体系听云行 WCL→OCM、`OWLG-YYYYMMDD-NN`格式定义→`OCL-YYYYMMDD-NN`（历史条目 `OWLG-20260811-01` 保留）、`ops/worklog/`→`ocm/worklog/`；⑩ §4.5.3 Git Issue 标签 `role:wcl`→`role:ocm`；⑪ 关联文档行 `[听云工作手册 WCL](../ops/WCL-听云工作手册.md)`→`[听云工作手册 OCM](ora1i.md)`、`[听云工作目录 ops/](bub8q.md)`→`[听云工作目录 ocm/](g0lra.md)`；⑫ 文档自主权原则说明段引用 `听云 WCL 工作手册 V1.2`→`听云 OCM 工作手册 V1.2`、`ops/`→`ocm/`；⑬ 页脚链接 `[ops/README.md](bub8q.md)`→`[ocm/README.md](g0lra.md)` + 锚点 `#35-听云wcl生产运维管理`→`#35-听云ocm生产运维管理`。保留：历史条目 `OWLG-20260811-01`/`OWLG-09~11` 等具体编号保留不动；§3.1 修订记录 V2.6/V2.7 条目保留原 WCL/ops/ 描述（历史留痕）；业务术语 OPS（运营服务）不改动
V3.0	2026-08-20	DT	阶段 4 整体重构对齐 PMG V8.0（承接用户指令"AGENTS.md V7.4→V8.0 升级 + PJM 关键段落更新"）：① §3.1 三 AI 角色表描述对齐 PMG V8.0 新分工——听写 DT 改为"负责其他全面"（Gitee/文档发布/项目管理/设计/用户测试）、听码 WDE 改为"只做编码"（dip1/ 本地，不接触 Gitee）、听云 OCM 改为"只做生产运维"；§3.1「AI 智能体分工」段同步重写，增加"不接触生产环境/不接触 Gitee 远程仓库""原 ops/→ocm/"等边界说明，并加挂 PMG §双轨交付机制 / §日志体系锚点链接；② §4.3.1 仓库清单后新增「V3.0 双轨交付机制」说明段——明确 Gitee hk2026-docs ⏸ 暂停使用（保留操作信息但禁止执行 push/sync）、hk2026 仅作团队协作源代码仓库、双轨交付路径（听码本地 → 听写打包 → push hk2026 备份 + scp/rsync 推送听云 → 听云部署阿里云）、听云与 Gitee 无关、听码与 Gitee 无关；③ §4.6 文档版本与归档机制整体重构——保留 §4.6.1 版本规范；§4.6.2 归档触发条件改为 git tag 快照触发条件；§4.6.3 归档目录结构改为 git tag 命名规范（milestone/vX.X/monthly/snapshot + release/* 分支）；§4.6.4 归档操作规范改为快照操作规范（含远程推送规则，明确 hk2026-docs 已暂停不推送 + 递归防护废弃说明）；§4.6.5 归档类型与策略改为快照类型与策略；§4.6.6 归档命名规范/归档类型合并到 §4.6.3/§4.6.5；新增"历史归档目录（已废止）"说明段，明确原 `docs/归档/20260804_V1.0_` / `20260805_V1.1_` 已物理删除，历史查阅改用 `git log --all -- docs/归档/` 或检出 tag 回溯；④ 新增顶部 V3.0 重大变更提示，标注归档机制由「目录快照 + robocopy」改为「git tag / git branch 快照」、历史归档命令禁止再执行；⑤ 修订记录追加 V3.0 条目
V3.1	2026-08-21	DT	新增 §五业务设计完整性/一致性/连续性核查专章（承接用户指令"全面检查业务设计的完整性/一致性/连续性，落实在 PJM 文档"）：① §1.2 平台服务架构表新增 DIS 派单服务（DOC-P71，物流派单决策引擎，三模式+保险策略+人工调整，V1.0）；服务关系描述更新（DIS 承接 CPT L5 派单触发，消费 DLV 主数据，下发 LGP）；② 新增 §五业务设计完整性/一致性/连续性核查（9 小节）：§5.1 三性定义+核查范围 Mermaid 全链路图+责任分工；§5.2 源头业务调研清单与映射（10 份调研文档→需求/服务对应表）；§5.3 DDD 方法落实核查（战略设计 5 服务状态表+战术设计 5 服务状态表+引入要求 6 项）；§5.4 业务用例覆盖度核查（当前用例分布+期望扩充目标 46-56 用例+文档化形式）；§5.5 原型与用例关联度核查（5 端 52 页盘点+data-* 属性规范 6 项+Ctrl+Hover 交互实现）；§5.6 跨文档一致性核查清单 20 项（11 项🟢已完成+1 项🟡待补+8 项🔴待补）；§5.7 业务设计连续性核查（服务边界 Mermaid 图+阶段演进表）；§5.8 阶段化核查执行计划（5 阶段任务表）；§5.9 核查结论；③ 原 §五关键约束与原则顺延为 §六；原 §六修订记录顺延为 §七
V3.2	2026-08-21	DT	阶段二收口：§5.6 核查清单 6 项 🔴/🟡→🟢 + §5.8 阶段二状态 🟢 + §5.9 新核查结论：① #13 QSV-DDD V1.2 / #14 CPT-DDD V2.5 / #15 MDS-DDD V1.3 / #16 OPS-DDD V2.1 共 4 服务 DDD 重构全部 🟢；② #17 用例库 5 文档建成 56=CPT16+QSV10+MDS10+OPS10+DIS10 🟢；③ #19 原型 47 非登录页 × 720 交互元素 6 个 data-* 属性 100% 全量注入（annotate.js V1.1 Ctrl+Hover解析）🟢；④ §5.8 阶段一-6 🟢已完成 + 阶段二 🟢已完成；⑤ §5.9 核查结论全面更新（三性完整论述 + 22🟢/1🟡/0🔴 三性 PASS） + 阶段三TND V2.0下一里程碑
V3.3	2026-08-21	DT	阶段二设计修补完善（用户指令 4 条响应）+ PJM 连续一致机制落地：① §5.4.1 用例分布表旧阶段一数据（QSV 2🔴/DIS 0🔴）→ 56 全量 5 服务 🟢 高覆盖；② §5.4.2 期望扩充目标合计 46-56 → ✅ 实际 56 达成；③ §5.4.3 用例文档化形式 10 散文件 → 5 单文档（QSV/CPT/MDS/OPS/DIS-UC-用例库.md）+ 原型 5 端 HTML 数 52→62（非登录页 57）；④ §5.5.1 原型盘点：OPR 19→24 / CST 9→11 / WKR 8→10 / LGP 6→8，缺口列 dispatch✅（扩展安装三模式候选池）+ OPS 运营 5 页 + CST/WKR/LGP 各 2 页缺口全部 ✅ 补完；⑤ §5.5.2 data-* 属性规范表 3 行 ❌→✅ 已完成（阶段二-9 47页×720元素 + 扩展 11 页同步）；⑥ §5.5.3 Ctrl+Hover 脚本 comp-hover.js→annotate.js V1.1（5 行 pill 分色：需求深蓝/服务青绿/用例海蓝/调研沙金/组件 ID）；⑦ §5.6 核查清单：#12 PMG/PJM 导航 DIS 行 🟡→🟢 + #18 dispatch ✅ 已完成扩写说明 + 新增 #21 DIS 安装师傅三分类 🟢（WPL REGISTER_TYPE + DIS-D 双轴 3×3=9 矩阵 + dispatch 可视化）+ 新增 #22 原型 11 缺口页补做 🟢（OPS5/CST2/WKR2/LGP2）；⑧ §5.9 核查结论全面重写：22🟢/1🟡/0🔴 → 24🟢/0🟡/0🔴，三性 PASS + 碎片化设计修补→PJM 立即同步机制声明；⑨ 响应"运营驾驶舱布局不好"：ops-cockpit.html 新 OPS 全局驾驶舱（6KPI×3×2 + 漏斗CAC + NPS + 场景物料口碑三卡）替代原 admin.html RBAC 页定位
V3.4	2026-08-22	DT	🔴 hk2026-docs 公开文档镜像仓全面废除 + PMG AI特定行为双轨同步（对齐用户指令）：① §4.3.1 仓库表从双仓→单仓（仅保留 hk2026 私有主仓），hk2026-docs 行标注「已废除/不再使用」+ git同步/MkDocs构建/Cloudflare部署全部永久取消说明；② §4.3.1 双轨交付机制 V3.0→V3.2 措辞从"⏸暂停使用"升级为"🔴已废除，所有操作永久取消"，并明确 scripts 仅保留不执行；③ §4.3.3 chore 提交示例「新增公开文档同步脚本」→「新增文档发布脚本」（中性描述，V3.5 确认无需再变动）；④ §4.3.5 AI输出目标表删除"公开文档同步"整行 + git同步行改写为「仅推送 hk2026 私有主仓 main 分支」；⑤ §4.3.5 目录管理项"执行公开同步脚本"删除线+废除说明；⑥ §4.3.6 公开文档同步整章顶部新增 V3.2 废除标注（整章仅保留作历史归档，不得执行）；⑦ §4.3.7 MkDocs+Cloudflare Pages 整章顶部新增 V3.2 废除标注；⑧ §4.6.4 快照操作规范#L4远程推送：明确「仅推Gitee hk2026私有主仓，任何情况下不得向hk2026-docs推送tag或任何提交」；⑨ 同步 PMG（AGENTS.md V8.1 §AI特定行为）：AI特定行为原4条→3条（删除公开文档同步；git同步改写为「仅hk2026 main，取消hk2026-docs相关」）+ 仓库现状表+边界约束#1措辞废除升级。依据用户8-22原话：「PJM和 PMG 帮我调整：git同步和公开文档同步（AI特定行为），我需要暂停使用 hk2026-doc，请将与这个 git 仓库有关的操作都取消。」
V3.5	2026-08-22	DT	纠偏：V3.4废除过头→V3.3双轨链路重构，Cloudflare Pages文档公开发布AI特定行为恢复保留（对齐用户澄清指令）：① §4.3.1 仓库清单从单仓表→三系统表（Gitee hk2026私有主仓✅/~~Gitee hk2026-docs Git仓废除🔴~~/Cloudflare Pages Project=hk2026活跃✅）+新增V3.3双轨交付机制+文档公开发布路径重构说明（原三节点hk2026→hk2026-docs Git仓→Pages→两节点直连hk2026→Pages Project=hk2026；生产域名hk2026-docs.pages.dev→hk2026.pages.dev）；② §4.3.3 chore提交示例「新增文档发布脚本」确认中性无需再改；③ §4.3.5 AI输出目标表从3条→4条，恢复第4条文档公开发布（V3.3链路重构：Project=hk2026，生产域名hk2026.pages.dev，MkDocs构建+wrangler直传Pages，不再经过Gitee公开仓）+加挂"需用户指令，AI不得自动触发"约束+目录管理项"执行公开同步脚本"改写为「执行文档站点构建部署脚本→§4.3.7 MkDocs+Pages」；④ §4.3.6废除范围从V3.4的MkDocs+Pages全废→限缩仅废除hk2026-docs Git仓同步（sync-docs-repo.ps1/Gitee clone/push/sync/checkout），MkDocs+Cloudflare Pages不废除，继续使用；⑤ §4.3.7 MkDocs+Cloudflare Pages整章从V3.4废除标注→恢复活跃，重写头段为V3.3链路重构说明+参数迁移要点4条（ProjectName hk2026-docs→hk2026 / 生产域名 hk2026-docs.pages.dev→hk2026.pages.dev / 脚本build-site.py+deploy-site.ps1+mkdocs.yml+url_map.py沿用，构建源零修改 / sync-docs-repo.ps1保留不删禁执行）+技术栈表生产/预览域名修正+文件清单deploy-site.ps1标注「V3.3默认ProjectName=hk2026」+URL slug示例域名hk2026-docs→hk2026全量替换；⑥ §4.6.4快照操作规范#L4远程推送：补充Cloudflare Pages Project=hk2026的部署不通过git tag，走wrangler直传链路（详见§4.3.7 V3.3）；⑦ scripts/deploy-site.ps1 L5 .PARAMETER ProjectName注释与L14 param默认值同步迁移：`hk2026-docs`→`hk2026`，保证文档描述与脚本行为一致；⑧ 同步PMG（AGENTS.md V8.2 §AI特定行为）：AI特定行为从V3.4/V8.1的3条→恢复4条（第3条git同步仅hk2026 main + 第4条文档公开发布V3.3链路重构）+仓库现状表3行（三系统表对齐PJM）+双轨交付路径代码块新增AI#4分支（听写→MkDocs构建→wrangler直传Pages→hk2026.pages.dev）+边界约束#1重写为「仅废除hk2026-docs Git仓Git操作+sync-docs-repo.ps1；deploy-site.ps1等Pages脚本继续使用、ProjectName改hk2026」+修订记录追加V8.2条目；⑨ 决策依据完整引用用户两条原话（V3.4废除指令+V3.5纠偏指令）。依据用户8-22纠偏原话：「刚才修改的似乎过头了，我只是废除 gitee 的 hk2026-doc ，Cloudflare Pages 文档公开发布这个AI特定行为还是需要的，实际上，原来 hk2026 --> hk2026-doc --> Cloudflare Pages ，改为：hk2026 --> Cloudflare Pages（仍然是公开的）」。

本文件为 PJM（项目管理制度），详细业务需求见 RQD，AI 协作规则见 PMG（agents.md），DIP1 子项目独立跟踪见 DIP1-IMP §7.1，听云生产运维管理见 §3.5 + ocm/README.md。