全域文件体系基本法 技术标准

前言

本文件按照 GB/T 1.1-2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。

本文件为「全域文件体系基本法」（V2.3.0）的技术标准载体，锚定《全域任务脑手架构宪法》V1.2.0 与《全域文件体系基本法》V2.3.0，效力层级为基本法层。

本文件的附录 A 给出了六层主干与宪法条号的对照关系，附录 B 给出了载体源清单索引。

1 范围

本文件规定了全域文件体系基本法（V2.3.0）的术语和定义、工作流架构、技术要求、校验方法与交付要件。

本文件适用于全域文件体系基本法的加载、执行、返工、验收与升级迭代全过程。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。

• 《全域任务脑手架构宪法》V1.2.0（管任务链路）
• 《全域文件体系基本法》V2.3.0_2026-09-25_1605（管文件）
• GB/T 1.1-2020 标准化工作导则 第1部分：标准化文件的结构和起草规则

3 术语和定义

下列术语和定义适用于本文件。

3.1 脑（K3）

负责定标、裁决、诊断与留痕，不施工。

3.2 手（DeepSeek）

按脑下发的标准施工、返工与落盘，不定标。

3.3 本地机械闸

零 Token 校验实体，退出码非零禁止交付，不自备标准，持有熔断计数。

3.4 人

负责确认、放行与宣布；闭环宣布权留人。

3.5 六层主干

宪法第 17 条规定的架构主干，由 A 入口层至 F 终结层六个层级构成。

3.6 一进一出

每个任务一次进入、一次交付，不并发多形态产出。

4 工作流架构

本章给出全域文件体系基本法的六层主干工作流架构，层序与条号严格对齐宪法第 17 条至第 23 条。

4.1 A 入口层（第18条）

本层承担角色：人（确认放行）、本地机械闸，共 4 个节点。

• 用户提出文件任务意图（人（确认放行））
• 场景识别（设计/施工/管理/科研/紧急/AI生成）（人（确认放行））
• 【本地】规范性引用文件核对（本地机械闸）
• 【本地】入口权限预检（先验权后读资料）（本地机械闸）

4.2 B 编排层_脑_K3（第19条）

本层承担角色：脑（K3），共 5 个节点。

• 【脑】M0 总则与治理 · 定标下发（脑（K3））
• 【脑】M1 基础定义（脑（K3））
• 【脑】M3 排版规则定标（脑（K3））
• 【脑】M2 命名规则定标（脑（K3））
• 【脑】M4 场景定义（场景定义需求）（脑（K3））

4.3 C 安全与权限层（第20条）

本层承担角色：人（确认放行）、本地机械闸，共 3 个节点。

• 【本地】M6 文件分级管理规则核验（本地机械闸）
• 【本地】M9 访问控制与安全保密（本地机械闸）
• 【人】高危/涉密文件放行确认（人（确认放行））

4.4 D 执行层_手（第21条）

本层承担角色：手（DeepSeek），共 5 个节点。

• 【手】M5 文件交付与留存规则施工（手（DeepSeek））
• 【手】W1–W6 工作流执行（手（DeepSeek））
• 【手】G3 命名 / G4 版本控制（手（DeepSeek））
• 【手】M12 文件传输与交换（手（DeepSeek））
• 【手】R8 AI 执行日志生成（手（DeepSeek））

4.5 E 交付与验收层（第22条）

本层承担角色：人（确认放行）、本地机械闸、混合（跨角色协同）、脑（K3），共 6 个节点。

• 【本地】R2 校核记录表 · R3 命名检查单（本地机械闸）
• 【本地】G1 校核方法论 · M11 内容结构标准（本地机械闸）
• 【本地】R4 审查记录表（父子表）（本地机械闸）
• 【人】M5 文件留存确认 · 归档（人（确认放行））
• 【脑】G2 审查方法论 · 缺陷分级裁断（脑（K3））
• 【脑/人】R5 版本变更记录 · 返工裁决（混合（跨角色协同））

4.6 F 终结层（第23条）

本层承担角色：人（确认放行）、手（DeepSeek）、本地机械闸，共 5 个节点。

• 【手】结果回传来源通道（手（DeepSeek））
• 【本地】R6 审计报告模板落盘（本地机械闸）
• 【本地】台账核算 · Token/费用/耗时（本地机械闸）
• 【本地】R7 问题报告与改进表单（本地机械闸）
• 【人】结束 · 闭环宣布权留人（人（确认放行））

5 技术要求

本章按「架构图六层骨架 ＋ 载体源正文」合成，源正文为全域文件体系基本法的权威记载。

本体系依据 GB/T 1.1-2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。

**版本**：V1.0.0 ｜ **发布日期**：2026-09-18 ｜ **状态**：现行有效

**效力层级（2026-09-18 炳哥裁定）**：全域规范效力从高到低依次为——**宪法（《全域任务脑手架构宪法》）＞ 基本法（本基本法）＞ 行政法规（MEMORY.md 机器级执行规则与各分项技术标准/SOP/范式）＞ 地方法规（工作区级规范、映射台账之场景映射）＞ 地方规章（任务夹级临时规程）**。下位规范与上位规范冲突的，以上位规范为准；本基本法与《全域任务脑手架构宪法》冲突的，以宪法为准。

**适用范围**：WorkBuddy 全域所有受控文件（含技术标准、规范、SOP、范式、报告、设计文件、管理文档、科研文档等）以及 AI 生成文件；公众号三件套排版独立豁免（见 M13 EX-1）

**与脑手架构宪法的分管边界**：《全域任务脑手架构宪法》V1.2.0 为全域最高宪法，管「任务链路」（角色、回路、熔断、总线、终止、降级、链路经济性）；本基本法管「文件」（命名、排版、场景、交付、留存、分级、工作流、记录），为其下位基本法。同一事项两法均有规定的，以宪法为准。

**成文基准（强制）**：本文的成文逻辑与格式体例遵循《MASTER RULE · 技术标准成文规范》V1.1.0（STD-A/B/C/D/E/F/G/H/Z 共 87 条）。成文格式类问题以该母规则为唯一基准；业务领域内容以本文为准

**成文规则**：正文只承载规范性内容与一行沿革指针；实测锚点、首例落地、三原则校验、同步清单等留痕信息一律写入任务夹与冻结历史版，不再入正文（见 M0.3）。

本体系为通用框架，共五个篇，外加附加模块。各篇内部采用模块化组织，模块按需启用，但核心模块（标记必选）不得删除。体系适用于所有受控文件，支持 AI（WorkBuddy / DeepSeek）自动化执行与校验。

5.1 目次

• 第一篇 目的与底层逻辑（1 目的与适用范围 / 2 总体方法论与底层逻辑 / 3 规范性引用文件 / 4 术语与定义）
• 第二篇 全域文件行动总纲领（M0 总则与治理 / M1 基础定义 / M2 命名规则 / M3 排版规则 / M4 场景定义 / M5 文件交付与留存规则 / M6 文件分级管理规则 / M7 配置管理与基线规则 / M8 变更管理规则 / M9 访问控制与安全保密规则 / M10 术语扩展与行业适配 / M11 文件内容结构标准 / M12 文件传输与交换规则 / M13 豁免清单 / M14 复用矩阵）
• 第三篇 全域文件工作流准则（W1 工作流基础模型 / W2 场景化工作流定义 / W3 并发控制与例外处理 / W4 规则版本与系统集成 / W5 非受控文件生命周期管理 / W6 工作流绩效与审计）
• 第四篇 全域文件指导方法论（G1 校核方法论 / G2 审查方法论 / G3 命名方法论 / G4 版本控制方法论 / G5 工作流建模方法论 / G6 其他方法论）
• 第五篇 全域文件记录规范化（R1 记录总则 / R2 校核记录表 / R3 命名检查单 / R3.1 历史文件命名差异记录表 / R4 审查记录表 / R5 版本变更记录表 / R6 审计报告模板 / R7 问题报告与改进表单 / R8 AI执行日志规范）
• 附加模块 新技术适配（AI 生成文件管理规则 / 新兴技术适配）

5.2 第一篇 目的与底层逻辑

5.2.1 1 目的与适用范围

1.1 目的

建立全域文件从创建、命名、排版、校核、审批、发布到归档/作废的统一技术标准，提升跨项目可读性、检索效率与自动化治理能力，支持 AI 与人工协作的无缝衔接。

1.2 适用范围

本体系适用于 WorkBuddy 全域所有受控文件（含技术标准、规范、SOP、范式、报告、设计文件、管理文档、科研文档等），以及 AI 生成文件。公众号三件套排版独立豁免（见 M13 EX-1）。

1.3 本体系解决什么问题（用途与目的）

本体系解决的核心问题：把分散在命名、排版、场景、交付、分级、工作流、方法论、记录各环节的零散规则，收敛为一套可识别、可执行、可校验的统一技术标准体系，使任何文件从「创建」到「归档/作废」的每一步都有规则可依、有角色可追、有闸门可验。治理的失效模式与本体系治理模块对照：

失效模式与本体系治理模块对照

1.4 编制目的

（1）统一技术标准：把全域文件治理规则收敛为一份可被全员调用的统一标准。（2）可执行可校验：每条规则以量化锚点与工具链硬闸落写，确保能被脚本自动校验。（3）支持 AI 自动化：明确 AI 执行指南与区域路由，实现 WorkBuddy/DeepSeek 自动化执行。（4）对齐治理底座：命名、落盘、四件套与权威库、双盘同步严格对齐。

5.2.2 2 总体方法论与底层逻辑

2.1 总体方法论

本体系遵循「规则做应用底座、工具链做硬闸门」的成文逻辑，四条方法论支柱：

• 规则做应用底座：所有治理动作必须先有规则条目（M/W/G/R 各模块），落字为据。
• 工具链做硬闸门：规则编码为可复用工具脚本（_tools），不合规即拦截。
• 场景做路由入口：以台账映射「场景-技能-规范」，任务启动先查台账。
• 不丢工程严谨性：每条规则配套可自动校验的判定标准与量化锚点。

2.2 底层逻辑

全域文件治理的底层逻辑是「规则 → 工具链 → 闸门 → 反馈」的四阶闭环：规则（M0-M14 / W1-W6 / G1-G6 / R1-R8 各模块规则条目）→ 工具链（命名校验、四件套生成、区域路由、双盘同步、风格检查等 _tools 脚本）→ 闸门（命名闸、排版闸、区域闸、四件套闸，不合规即拦截）→ 反馈（闸门拦截/告警回流到规则库与版本清单，形成持续迭代闭环）。

规则即代码（实现层）：每条规则等价于一段可执行代码，由触发条件、执行动作、责任人、例外处理、校验方式五要素构成；正文不嵌入具体脚本名，实现以 _tools 工具链清单解耦演进。

2.3 逻辑思维简图（认知入口）

本体系的逻辑思维简图自顶向下分为五层认知框架（L0 机器级规则层 → L1 行动总纲领层 → L2 工作流准则层 → L3 指导方法层 → L4 记录规范化层），层间依赖箭头为「拆解 / 指导 / 套用 / 支撑」。

2.4 成文基准声明

本文的成文逻辑与格式体例必须遵循《MASTER RULE · 技术标准成文规范》V1.1.0（STD-A/B/C/D/E/F/G/H/Z 共 87 条）。该母规则为全域技术标准成文的唯一最高基准。

（1）效力层级：成文格式类问题以母规则为准；业务领域内容（M/W/G/R 各模块）以本文为准。二者分层分册，互不冲突。（2）发布前必检：本文每次升版必须逐项执行 doc_style_check.py 机器判定，P1 阻断项存在任一不通过即不予发布。（3）扩展而非冲突：本文后续新增的格式类条款必须为母规则的「扩展」或「细化」，禁止冲突、禁止放宽既有阈值。（4）基线保护：母规则基线 MD5 篡改即 P1 阻断。

5.2.3 3 规范性引用文件

下列文件对于本体系的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本体系；凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本体系。

• GB/T 1.1-2020 标准化工作导则 第1部分：标准化文件的结构和起草规则
• GB/T 15834-2011 标点符号用法
• GB/T 7714-2015 信息与文献 参考文献著录规则
• ~/.workbuddy/MEMORY.md（2026-09-03 终版重构，唯一执行权威）
• 全域更新逻辑图_映射台账_2026-09-02_1558.xlsx（场景-技能-规范映射权威）
• ~/.workbuddy/spec/3.行政法规/ 下全部范式与 SOP（权威库）
• ~/.workbuddy/_tools/ 工具链（命名校验、四件套生成、区域路由、双盘同步、风格检查等）
• 《全域任务脑手架构宪法》V1.2.0（任务链路协作架构专项准据，2026-09-18）

5.2.4 4 术语与定义

下列术语和定义适用于本体系。

核心术语与定义

规范性要求等级（RFC 2119）

所有条款若未特别标注，均视为「必须」级别。若条款使用「应」「宜」「可」等词，则按上表执行。

5.3 第二篇 全域文件行动总纲领

本篇为体系的行动基础，包含总则、基础定义、命名、排版、场景、交付留存、分级等规则。其中目的、适用范围、总体方法论与底层逻辑、规范性引用文件、术语与定义已前置至第一篇。

第二篇模块划分

5.3.1 M0 总则与治理

0.1 冲突解决

任何规则冲突，按以下优先级裁决：《全域任务脑手架构宪法》（最高宪法）> 本基本法（全域文件体系基本法）> MEMORY.md 与各分项技术标准/SOP/范式（行政法规层）> 工作区级规范与台账场景映射（地方法规层）> 任务夹级临时规程（地方规章层）> 引用国家标准 > 其他规范。若 MEMORY.md、台账或任何分项标准条款与本基本法不一致，以本基本法为准，并应在下次升版中修正；本基本法与《全域任务脑手架构宪法》不一致的，以宪法为准，并应在下次升版中修正本基本法。

0.2 审计 KPI 定义

审计 KPI 定义

0.3 体系版本管理

本体系版本号遵循语义化版本（主.次.修订），并同步更新 MEMORY.md 中的引用。每次升版须执行：更新本文件版本号与修订日期；同步 spec/3.行政法规/范式/ 中相关范式；更新 skills_registry.json 中本体系的记录；发布四件套（见 M5）并归档至发布盘。

升版留痕外置：每次升版的实测锚点、首例落地、三原则校验、同步清单等留痕信息必须写入当次任务夹，禁止以前言版本状态行长文、条款内「首例落地」详述段、定稿校核结论沿革段等形式进入正文；历史版本全文冻结为来源附件承担详查职能。违反本款导致的正文膨胀按《全域任务脑手架构宪法》第 41 条缺陷分级处置。

0.4 管理承诺

标准委员会负责本体系的制定、解释、修订与培训，确保所有相关人员理解并执行。每年至少组织一次体系符合性评审。

0.5 外部标准对照

本体系条款与 GB/T 1.1-2020 对照

0.6 S10 场景隔离（任务收尾总结触发范围）

任务收尾总结（S10，权威定义见 spec/3.行政法规/SOP/S10_任务收尾总结SOP.md V1.4）的触发范围，按 2026-09-04 用户裁定（场景A禁触发 / 场景B触发，全域统一）执行以下五项条款：

1. 生效判据：以 `_tools/scene_gate.json` 的 `effective_status` 字段为单一事实来源——非 active（pending 等）时按现行全域规则执行（任何任务每次结束后收尾，生效前零行为变化）；active 后方按本条执行场景隔离。
2. 触发范围：仅场景B（治理流：skill/专家升级、升版、迭代、训练、知识注入、订阅源训练、规则库写回、四件套生成、权威库发布、宪法/规范修订）任务结束后触发 S10；场景A（通用执行流：公众号单篇写作、报告生成、排版、画图等日常业务交付，未改变任何治理资产）禁止触发 S10。治理文档场景细则：产出治理类文档/图表/报告但未写入权威位置（仅落任务夹产出/）判场景A；改变治理资产状态（规则库/登记表/规范/宪法内容或版本）判场景B。
3. 判定优先级：① 用户显式意图词（训练/订阅/升级/升版/迭代/知识注入/发布/写回规则库/四件套）＞ ② 脚本指纹（train_subscriptions.py / skill_upgrade.py / fourpiece.emit 等）＞ ③ 落盘指纹（style_rules* / skills_registry / spec 写入、Class B 四件套产出）＞ ④ skill 路由节点；全部信号缺失时默认场景A；混合会话以最后一轮实质动作所属场景为准。
4. 用户令牌：S10_FORCE 强制执行 S10；S10_OFF 跳过 S10（显式覆盖，仅 active 态生效）。
5. 强制执行点：`settings.json → hooks.Stop` 审查器第 0 步场景判定——场景A直接放行；场景B按 S10 V1.4 全量审查（200 字三要素 + 遗留问题分组分级 + 增强提示词五要素 + P0/P1/P2 清零硬闸）。场景A收束时回复末尾输出一行「遗留状态：延续前轮 <级别><编号> N 项，详见增强提示词库」索引。

0.7 业务交付铁律条款

业务交付类铁律共十条（第 1~10 条），覆盖任务夹命名、HTML 交付、单文件可视交付、专家与 Skill 评价、公众号查重、PPT 蓝本生成、产业链研究、理财输出与异源双模校核。原技术经济性条款（治理 token 预算与条件装载）及与《全域任务脑手架构宪法》同源承载的条文已删除——任务链路经济性、脑手分离红线、施工验收与停损、AI 瞎飘治理以《全域任务脑手架构宪法》为唯一准据；被删条文的沿革留痕见同目录冻结历史版。

M0.7 十条铁律索引

0.7 第 1 条 · 三字标题命名强制与存量整改铁律

（1）标题口径唯一，载体名与版本号禁入：任务夹名恒为 `<三字标题>_<YYYY-MM-DD_HHMM>`。三字标题必须为纯汉字恰三字（正则 `^[一-鿿]{3}$`）——禁英文、禁数字、禁版本号、禁连字符与下划线、禁空格、禁标点。时间戳必须为 `YYYY-MM-DD_HHMM`（同分钟重复追加两位秒 `_%S`），禁省。载体名、版本号、任务描述短语禁止进入标题段；标题由文章／任务标题凝练，非文章类功能夹取功能名。

（2）机器闸门，禁静默通过：`_tools/deliverable.py` 必须提供 `TITLE3_RE` 与 `assert_title3(theme)`，并由 `_ensure_task_folder()` 在建夹前调用——标题非纯三汉字即 raise NamingError；`assert_in_task_folder()` 以同口径复核落盘路径。任何新增 skill／脚本自建任务夹路径一律适用。唯一逃生阀为环境变量 `WB_TITLE3_OFF=1`（属受控例外而非默认）。

（3）存量整改义务（一轮一审，逐项留档）：存量违规任务夹整改须同时满足四要件——①可执行改名脚本 + 同构回滚脚本；②改名日志（`产出/_rename_log.jsonl`）与落盘核验映射（`产出/_rename_verified.json`）双留档；③改后复评并写入 R3.1；④占用项不得强改（`WinError 5` 时登记为未处置项、附重试命令与占用归因）。

（4）豁免清单（明列，禁扩张）：①结构目录 `_tools`／`scripts`／`spec`／`skills`／`README`／`dist`／`output`；②任务夹内固定子目录 `产出`／`素材`／`图源`；③隐藏与系统目录 `.git`／`.workbuddy`／`.sync_snapshots`；④备份与临时夹 `_bak_*`／`_backup_*`／`_archive_*`／`*_tmp`／`_probe`；⑤载体目录按 M2.2.2／2.2.3；⑥顶层子工作空间按 M2.2 沿用「利衡辨_XXX」（另案专项裁定）。上述豁免项禁止被本条扩张解释。

0.7 第 2 条 · HTML 交付自包含与版式统一铁律

（1）同级相对路径，禁跨目录引用：HTML 内 `<img>` 的 `src` 必须为同级相对路径（形如 `图源/图1.png`），禁含 `../` 段，禁盘符绝对路径与 `file:///` 协议地址；路径必须与磁盘实体逐字符一致。

（2）产出自包含，构建期即随行：构建脚本必须把所引图源复制进「产出」目录下的同名子目录后再渲染；复制后必须逐个回读校验，解析命中率须为 100%；同一图片在产出目录内只保留一份。

（3）分发以目录为单元，单文件为例外：对外交付必须以整个「产出」目录为单元；仅当渠道限制必须单文件传递时，可以 base64 内嵌（体积约 +33%，须核算并标注 `-单文件版`），禁以内嵌件覆盖默认外链件，禁内联 SVG 源码。

（4）校验前置于分发，缺校验不得分发：附图可达性校验必须前置于分发动作；校验须由构建脚本自打印三项计数——图片条目数／跨目录引用数／解析命中数，形态为 `N / 0 / N` 方为通过。

（5）同批同基线，指纹须为 1，四壳类名须一致：同一交付批次内的同类 HTML 必须共用同一「统一完整版式」基线，以全部样式规则构成的 CSS 块取 `sha256` 前 8 位为版式指纹；同批指纹去重个数须为 1，且须在页眉显式标注。页眉／目次／正文／页脚四壳必须齐备，四壳类名必须为本批 CSS 已定义者且同批一致。

（6）派生件与事实源一致，禁失号与缺条目：HTML 派生件的权项编号与条数、章节标题层级、表格数、正式附图数、关键参数数值五项必须与事实源逐项一致；禁整节无号、跳号、并号，禁层级降级，禁丢节，禁残留 Markdown 源标记。构建脚本应内置五项对账，任一项不符即 fail-closed。正式附图计入附图数，补充制图不计入；同一图号下只许一份文件。

（7）交底书目次基线与三级全锚点：同一体系的交底书 HTML 必须采用同一目次基线——一级七节固定，二级槽位含 2.5 本领域的技术地图，3.2 三级槽位含 3.2.1 底层原理逻辑结构简图；目次必须对 `h2`／`h3`／`h4` 全部生成锚点并入册，判据为 `href` 集合 = `id` 集合。

（8）技术地图图文化，禁以文字充抵：交底书 2.5 节实质内容必须以「坐标图 + 文字说明」双载体呈现。图面必须齐备六项要素——①两条坐标轴及其分类档位；②现有手段集中区；③坐标空位；④本发明坐标；⑤约束条件线；⑥标记号（须与附图标记对照表逐项对应）。图必须作为正式附图登记入「附图说明」与「附图标记对照表」，正文须以「见图 N」引导。同一交付件内的结构简图适用同一判据。

（9）标记良构，禁游离条目与拍平：`<ul>`／`<ol>`／`<li>` 的开标签计数必须分别等于其闭标签计数；禁游离 `<li>`、禁悬空闭合标签。源侧为嵌套列表时，构建期必须保留嵌套；禁把子项拍平为同级条目。

（10）单文件离线版须可生成，能力强制＋渠道条件强制：构建脚本必须内置将全部 `<img>` 同级相对路径引用统一 base64 内嵌为 `data:image/png;base64,...` 的能力（禁内联 SVG）；仅当渠道限制只能传递单个 HTML 文件时，必须产出 `-单文件版`，并与默认外链版同源并存；不得用内嵌件覆盖默认外链交付件。单文件版必须满足：内嵌后非 `data:` 的 `src` 残留数须为 0，`<link href>`／`<script src>` 外链须为 0，base64须可解码；页脚须标注 `-单文件版`。

（11）适用形态路由与兜底口径：HTML 类交付必须先按输入类型完成形态路由——① 输入为一个产品名者路由至 LHB/TS-2026-005《产业链报告自动生成技术标准》，未挂接 NEV 产业链者必须按其 §4.1 拒绝执行；② 输入为一篇论文／学位论文／技术报告者路由至 LHB/TS-2026-006《论文可视摘要单页自动生成技术标准》；③ 输入为其他文档或已有 HTML 者判为第三类输入，当且仅当交付要求中未明确指定 Word／三件套／四件套／五件套／两件套等特定载体形态时，方由 LHB/TS-2026-004《HTML 交付自包含技术标准》的通用条款承担唯一执行层依据（兜底口径）；禁强扭 005／006 的形态骨架。反向约束：一旦交付要求明确指定件套形态，必须转由对应形态标准或《四件套强制交付物断言技术标准》承接。底座恒定：004 恒被引用，三者关系为「1 横向底座 + N 纵向形态」，禁并列为互斥的「三选一」。形态路由结果必须写入任务 `state.json` 的 `form_route` 字段，并在交付说明中一句话声明路由依据。

0.7 第 3 条 · 单文件可视交付三闸校验铁律

（1）三闸必跑，缺一禁交付，结论须留痕：单文件 HTML 可视交付物必须依次通过——闸一结构校验（HTML 解析器标签闭合＋`<svg>` 配平）、闸二版式静态审计（文本越界／容器溢出／同水平带重叠三项全 0）、闸三真实渲染核验（无头内核桌面整页＋移动端精确视口）；禁以「生成成功」替代校验通过。三闸结论必须连同实测数值写入 `state.json` 的 `gates` 字段。

（2）闸二前置硬要求，禁假绿：被审计图形必须写成 `<svg class="<非空类名>" viewBox="0 0 W H" …>`，`class` 必须存在且位于 `viewBox` 之前；审计必须按 XML 解析并继承 `<g>` 上的 `font-size`／`text-anchor`。前置要求不满足即判审计无效。

（3）闸三须 iframe 精确视口：必须先以 `document.documentElement.scrollWidth ≤ window.innerWidth` 诊断，再以 `<iframe width="390" height="…">` 套壳取得真实窄屏布局视口；禁用 `--window-size=390` 截图后裁切的产物判定溢出。

（4）闸三-B 须区分滚动区与真溢出：视口溢出探测必须双判据——页面级 `scrollWidth ≤ innerWidth`＋元素级 `getBoundingClientRect().right > innerW + 1`；`overflow-x` 为 `auto`/`scroll` 的容器自身＝设计上横向滚动区，其内部子元素越界必须沿父链追溯豁免，同时必须反向校验滚动容器自身未超宽。

（5）图形自绘，坐标先定后算：单文件可视交付物必须全程内联（外链引用数须为 0），图形必须手写 SVG，禁引入图表库；必须先定绘图区再算点并做文字宽度估算，配色语义必须锁定。宽幅 SVG 的 `min-width` 应取 `viewBox 宽度 × 0.9`。

（6）取文与读图预算受限，禁全文灌入：源文档取文必须先探文本层再定路线；必须建带行号索引的全文并按行区间精读结论性章节，应控制精读量 ≤ 全文 25%；读图预算必须优先分配给封面／摘要／目录／各章小结／结论与展望／关键结果图页。

0.7 第 4 条 · 专家与 Skill 评价铁律

（1）分类分级前置，禁无定位打分：任何载体在评价前必须完成形态分类（T1 业务型 skill／T2 知识型专家／T3 双端载体／T4 元载体）与风险级（R1 低／R2 中／R3 高）两项静态定位，并由风险级导出门槛系数 k（1.00／1.05／1.15），k 同时缩放达标分数线与观察样本下限。禁跳过定位直接打分；禁以「分类困难」为由放弃定位（无法定位即判「不得判定」）；禁以降风险级规避样本量要求。

（2）四组十二项，逐项附证据指针：评价维度固定为四组十二项——A 组需求锚定（A1 场景覆盖率／A2 触发 F1／A3 独有能力数，20 分）、B 组交付质量（B1 任务成功率／B2 交付物合规率／B3 事实准确与可溯源率／B4 稳定性与复现率，40 分）、C 组边界与诚实（C1 拒绝能力／C2 抗应试性／C3 构念区分效度，24 分）、D 组评测体系有效性（D1 金题与真值质量／D2 评判者效度／D3 效度与统计纪律，16 分）。每项分数必须附可复核证据指针；无证据的分数判无效分。四条口径红线：①任务成功率必须取 reliability@k 的全 k 次均成功口径（默认 k=5），禁用「k 次中至少一次成功」的乐观口径计分；②金题集必须含不可完成题且占比 ≥ 20%（信息不足／条件不可能／超边界／意图模糊四类各 ≥2 题），禁排除出分母；③漏拒率权重必须高于误拒率，二者必须同时报告；④安全或合规类声明必须附构念区分效度举证（区分 ρ_d < 0.30、收敛 ρ_c > 0.60），禁以「控制能力变量后的偏相关」代替构念分离。

（3）三条一票否决线先于总分：V1 冗余否决——A3 独有能力 = 0 且触发词与既有载体可互换，判不达标并按载体冗余收敛处置（机制层以 skills_registry.json retired 区登记为准）；V2 构念混淆否决——载体产出安全或合规声明而 C3 = 0，该声明判无效、不得作为部署依据；V3 不可复现否决——B4 复现率 < 0.70，该次评价全部分数不得用于部署决策。命中任一 V 线，结论不得高于「不达标」。

（4）四要件达标判定与四分法结论：判定必须同时满足——①样本达标②证据可复核③评测体系自检通过（D 组 ≥ 10，L3 及以上 ≥ 12）④无否决项；四要件为合取。结论必须取四分法之一——达标／有条件达标／不达标／不得判定（金题未过审计、样本不足、评判者不合格、真值不独立、B1 分母不含不可完成题五情形之一）。「不得判定」是合格结论而非失败；禁以「有条件达标」规避总分不足。

（5）短板必须可路由至训练，改动后必须重评：评价结论必须经短板路由回灌训练流程；评价报告作为治理留档件同批产出（不得作为升级依据）；载体升版即评价失效，训练注入后必须以同金题、同评判者、同口径做配对前后对照，并必须过正式显著性检验（bootstrap 或置换检验），报告 p 值、效应量与 MDE；观测差异小于 MDE 时禁声称「提升」或「退化」。评价频率按成熟度分档（L1/L2 每轮必评、L3 每 3 轮、L4 每季度 + 触发式），禁在一次会话内对全部载体做无差别全量评价。

0.7 第 5 条 · 公众号成文查重降重铁律

（1）双基准 + 自重复，禁单基准：查重基准必须由三部分构成——原稿、历史稿库、稿件自身；历史稿库必须排除与当前稿同标题的同源文件。

（2）句子级计量，禁宽口径子串包含：计量必须为句子级（按 `。！？!?；;…` 切分），仅计「散文正文」，标题／引用行／结尾模块不得计入且不得改写；单句 CJK 字数 < 12 者不得计入。判定信号为或关系：①复制——存在长度 ≥ 20 的连续相同 CJK 子串；②近义改写——长度比 ∈ [0.7, 1.43] 且字符 bigram Jaccard ≥ 0.85。

（3）阈值 8%，超标自动降重（≤3 轮）：重复率 = 复制/近义句 CJK 字数之和 ÷ 散文正文 CJK 总字数 × 100%，阈值 ≤ 8.0%。超阈值必须触发 LLM 逐行改写并回填（保原意、保行数），循环至 ≤ 8%；轮次上限 3。

（4）不达标预警，禁静默通过、禁阻断出稿：3 轮后仍 > 8% 或无可改写行时必须记 `degraded` 并预警人工；不得阻断出稿，亦不得静默通过。无 API Key 时不得伪报通过。

（5）判定零 LLM，成本可核算：判定阶段必须为纯本地脚本、0 LLM 调用；仅当重复率超阈值时按次触发一次改写。本环节 `usage` 必须并入链路 token 统计落盘。

0.7 第 6 条 · 项目立项 PPT 蓝本克隆生成铁律

（1）蓝本规格前置固化，禁目视誊写：首次使用或蓝本更替时，必须先由解析器产出机器可读规格（页数与版式名／逐形状身份与坐标尺寸／逐形状 run 样式／表格行列数／图片哈希／字体字号集／图表与外部关系清单／画布尺寸），不得凭目视誊写规格，不得以「参照某份文档的样式」这类口头基准代替。

（2）只允许克隆与注入，禁自造页、禁改结构：生成必须以蓝本为源全量复制包结构后仅在副本上注入；注入只允许改写既有 run 的文字、既有单元格的文字、图片本体三类，不得新增或删除形状，不得改坐标与尺寸，不得增删表格行列。文本注入的样式链路必须两条分取——段落属性取自基准 run 所在段落、字符属性取自基准 run 自身；基准 run 必须优先「带显式字号的 run」，不得取段首无字号占位 run。同名形状命中数大于 1 时必须以祖先组名路径消歧，不得默认取首个。

（3）自包含化强制后置，禁留待人工：生成件必须在保存后立即剥离外部关系，且必须同时删除关系条目与引用该关系 ID 的元素，不得只删其一构成悬空引用；不得以「离线打不开是蓝本的问题」为由留待人工处理。

（4）三闸机器判定，禁以目视替代结论：必须跑版式闸、内容闸、自包含闸，退出码非 0 不得交付。版式闸的样式判据不得采用「run 指纹集合相等」，必须改用「生成件样式词表包含于蓝本词表＋按文本字数加权的主导字号与中英文字体不漂移」；布尔属性的「缺省」与「显式假」必须视为等同。三闸报告必须随件留档且可被第三方仅凭留档复算。

0.7 第 7 条 · 产业链公司映射四要素补录铁律

（1）四要素必填，禁留空：凡产业链研究报告的公司映射表，必须补录 ①市占率排名 ②对应顾客 ③设备成本（RMB 含税）④维护成本 四列。四列均为必填，不得留空（仅财务或治理已失效主体可填「不适用」并说明理由）。无公开数据时必须写「无公开数据」并列入数据缺口清单，不得以推测数字顶替。

（2）口径唯一性，禁混榜与凑数：市占率必须声明「区域口径 + 统计机构 + 统计年度」三要素，同一榜内不得混用中外统计；整机与零部件必须分榜。榜单不足时必须明写「第 N 位后无公开排名依据」，不得以企业自述份额或百科口径凑数。顾客必须逐名可溯源到招股书／年报／机构调研／权威具名报道，禁止由话术推演具体名单。

（3）矛盾数据判废，禁照抄：来源给出的份额百分比必须先做内部一致性校验——合计 >100%、后位份额高于前位、与同报告自身规模数据冲突，满足任一即判不可采信；此时只保留名次，并必须在表注写明判废理由。判废不得静默。

（4）竞价与维护双口径，禁口径失真：设备成本必须声明含税口径与价格性质；禁止以实验室／小型机型价格代表产线级价格；价格必须给区间并注明「标准配置」。维护成本必须同时给出「占设备采购价 %」与「绝对值区间（万元/年）」双口径，必须列易损件更换周期；停机损失必须单列；引用非本行业参数时必须标注跨品类同构性假设，折算值必须标注为测算值。

（5）禁以份额代归类：四要素不得作为三分类标签的判定依据；表注中必须显式声明。

（6）呈现要求：四要素必须随公司映射表同屏呈现（不得移入附录或仅以文字描述）；表前必须给出四要素通用口径说明段；表后应汇总数据缺口清单。注：本款原「独立榜 + 复筛表」分表呈现要求已经第 8 条同批同源变更停止适用，改由第 8 条单表综合榜承接。

0.7 第 8 条 · 产业链设备解构与 BOM 成本构成铁律

（1）装配层解构必出，禁只到整机：凡标的物为资本品／设备类者，必须出「标的物解构与 BOM 成本构成」一节，把整机拆到装配层——基准九层为机架外壳／内胆腔体／门体密封／加热控温／真空获得／阀门管路／物料承载输送／控制仪表／安全环保附件；禁止以「整机—零部件」两级罗列代替。非标设备可按实际合并层，但必须显式声明合并口径与理由。

（2）BOM 成本构成表必给，禁只给定性占比：至少 9 列——装配层／主要外购件／自制占比／外购占比／成本区间／占比来源／来源等级（A/B/C/D）／供给集中度／是否真卡点。占比必须给区间并声明口径；禁止只写「占比较高」一类定性表述。

（3）来源等级如实标注，禁降级与静默：占比数据必须溯源并标等级——A 级（企业公告／招股书／权威具名报道）、B 级（第三方研究机构白皮书／行业协会报告）、C 级（营销页／百科／科普站测算）、D 级（无公开来源、仅本报告建模）。凡按系统成本测算者，必须标测算值并写明换算假设；跨品类同构性类比必须标注假设与折算依据。无公开数据为合法占位，但整表不得全空。

（4）双因子判卡点，禁单以占比定瓶颈：判定真卡点必须同时看BOM 权重 × 供给刚性——占比高而供给充分可替代者不判卡点；占比低而独家供货／交期长／有出口管制或认证壁垒者判卡点。卡点判定必须与本报告供给约束一节结论一致。

（5）结构爆炸图可判读，禁装饰性插图：必须出结构爆炸图——九装配层逐层可辨（三种透视择一，同报告内必须统一）；外购件与自制件必须以线型区分（虚线＝外购、实线＝自制）；真卡点层必须以「专用底色 + 虚线外环 + 角标」三重视觉标记；必须含图例与图注三句；图内文字不得小于 9px。

（6）呈现与自洽，禁移入附录：解构节必须置于公司映射节之前；BOM 表必须与结构爆炸图同屏呈现；各装配层占比之和必须自洽（合计 100% ±3% 内）；表后应汇总数据缺口清单。

同批同源变更（第 7 条呈现口径修订）：公司映射两表合并为一张综合榜——按市占率降序、公司数封顶 TOP 15、名次依据独立成列；第 7 条（6）分表呈现要求停止适用，其余五款继续有效，四要素列并入综合榜（14 列），不得以「单表放不下」为由删列。

0.7 第 9 条 · 理财专家输出治理与实现状态透明铁律

（1）合规前置：输出前按 W-E1～W-E20 失败模式清单逐项扫描，命中即阻断并按处置列执行；反诈清单（非法集资／虚拟货币／非法荐股／原始股骗局／养老投资骗局／杀猪盘／跨境非法平台）命中即拒绝并提示 96110／110／12386。

（2）适配匹配：KYC + 风险测评前置（有效期 ≤12 个月，过期即拒绝具体产品推荐）；客户风险等级 R1–R5 ≥ 产品风险等级 R1–R5 方可推荐；私募类须先核验合格投资者资格；特殊人群（≥65 岁／未成年／残障）额外审慎。

（3）四问穿透：底层资产／现金流／风险收益比／退出路径；任一未过即整标的标「未穿透·不可推荐」。

（4）双模式输出：任务启动第一步路由——常规模式＝六段式＋事实建议分离＋免责五要素＋尾行状态栏；评估模式＝12 维 M0–M5 全量＋R15–R22 逐项＋评估感知自检＋拒绝能力判定；禁在常规模式展开评估全量。

（5）实现状态透明：Prompt 声称的动作须标盘上实现状态（已落地／部分落地／未落地三态）；未落地一律标「声称·未验证」，禁以文本声称替代盘上实体。

（6）数据时效与冲突仲裁：来源分级（S 监管与交易所／A 公告／B 权威媒体与行业机构／D 自媒体降权）＋「来源｜发布日｜读取日」标注；行情 >1 交易日／财报 >1 季度／政策 >1 年 stale 即降权；双知识库冲突按「合规 > 事实 > 搞钱内核理论 > 利衡辨四步框架」仲裁并显式标注冲突点。

0.7 第 10 条 · 异源双模校核体系铁律

（1）异源三判据可执行化，禁存在性冒充独立性：两路模型必须过三判据——端点域名（去 path）／密钥前 8 位／厂商字段，任一重合即 fail-closed 并写 `meta.hetero_audit`；precheck 仅查存在性不得作为异源证据；路由单一事实源为 `scripts/routes.json`，密钥只从 `models.json` 读取、禁落任何文本。

（2）S 仲裁序与口径纪律，禁单指标独断与跨口径横比：计算顺序 Kappa_raw → Kappa_signal → Jaccard → Dice → overlap → Cosine_adj_scope；Kappa 退化（Po=Pe=1.0）降级 Jaccard/Dice；|Jaccard − Dice| > 0.30 判共识不成立强制 REVIEW；overlap 与 Jaccard/Dice 方向相反判共识不稳定强制 REVIEW；仲裁写 `meta.arbitration`；S_adj 可算则报、不可算显式 null + 缺件原因；路 B 模型或口径变更后 S 不得与历史横比。

（3）Z3 伪成功闸门与实现状态透明，禁文本声称冒充盘上实体：HTTP 200 + 合法 JSON + 空 issue_list + 四维全 100 → 强制 REVIEW；凡 Prompt 或标准要求的动作必须标注实现状态（已落地／部分落地／未落地），未落地项一律标「声称·未验证」；R15–R22 落地状态以标准 §7 表为唯一口径。

（4）成熟度自评带外部锚，禁无锚打分：校核类 Agent 能力评估按 12 维 M0–M5 执行；每维须附至少一项盘上实体锚，无锚标「自评·未校准」；权重默认值标「初始值·未标定」；第二评审者盲审 10% 维度、一致性 <0.60 整体降一档；D3/D4/D8 任一 M0/M1 判「不可用于高风险交付判定」，D1/D5 任一 M0/M1 判「校核结论不可采信」。

5.3.2 M1 基础定义

1.1 角色与权限矩阵

角色与权限矩阵

1.1-A 脑手分离角色映射表

脑手分离角色映射表

映射口径：上表为职责边界映射而非一一等同；同一承载体在不同节点可承不同既有角色，以脑手分离四条红线（《全域任务脑手架构宪法》第 16 条）为最高约束。

1.2 文件分类与编码

受控文件必须分配 UUID，遵循完整工作流，命名合规；非受控文件不分配 UUID，可自由命名，但不得进入正式流程。编码规则：场景代码-年份-序列号，如 DES-2026-001。

1.3 文件格式与工具链约束

• Word 交付物：.docx，必须符合 M3 排版规则。
• Excel 交付物：.xlsx，变更履历和版本清单必须含指定列。
• 范式源文件：.md（Markdown），作为权威源。
• 工具链：必须调用 ~/.workbuddy/_tools/ 中的 deliverable.py、check_deliverables.py、fourpiece.emit()、region_gate.py、sync_disks.py、doc_style_check.py 等，禁止手写路径/文件名。

5.3.3 M2 命名规则

2.1 通用字符规则

仅允许中英文、数字、下划线、连字符（但推荐用下划线），禁止空格、特殊符号。时间戳统一为 YYYY-MM-DD_HHMM（年月日_时分，24 小时制，下划线）。版本号格式 V主.次.修订，递增规则见 G4。

2.2 文件命名模板

文件命名模板

2.2.1 三字标题提炼规则

任务文件夹「三字标题」由文章 / 任务标题自行提炼（凝练主题核心，非机械截取），全文统一；非文章类功能夹（如参考库、素材库、工作流）三字化用功能名。凡标题可提炼出三字者一律用三字，禁止用长标题 / 全标题作任务夹名。

2.2.2 自建（DIY）技能目录命名规则（基本法级硬约束）

凡由本人或 Agent 自行创建（SKILL.md frontmatter 含 `agent_created: true`）的 skill，其技能目录名与 frontmatter `name` 必须一致，且一律采用四段式 `V<版本号>_lihengbian_DIY_<功能名>`：

1. 版本段：`V主.次.补` 三段式，新建一律 `V1.0.0`，升位按 G4；
2. 品牌段：固定小写 `lihengbian`，禁止写作 `利衡辨` / `Lihengbian` 等变体；
3. 标识段：固定大写 `DIY`，用于区分「自建」与第三方 / 平台内置 skill；
4. 功能段：沿用功能原名（英文原名或 kebab-case），不做中译、不改大小写。

配套要求：frontmatter 三必含 `name` / `description` / `version`，`name` 必须等于目录名，时间字段用 `updated`（`YYYY-MM-DD`）。存量自建 skill 新建或更名时按本条收敛；第三方 skill（非 `agent_created`）保留原名，不适用本条；专家插件目录从其平台约定。

2.2.3 第三方 skill 转化自建（DIY）强制流程（基本法级硬约束）

凡从外部下载并加载成功的 skill，一经在本机落盘并纳入自有体系，即视为「自建（DIY）skill」，必须按下列五步完成转化，禁止长期保留 `skill_<数字ID>` 形态或第三方原名：

1. `_skillhub_meta.json` 改造：置 `source` 为 `local-diy`，新增 `origin_skillId`、`convertedAt`、`convertedBy: 利衡辨`。
2. 目录更名：`skill_<数字ID>` 或第三方原名 → `V1.0.0_lihengbian_DIY_<功能名>`；功能段沿用原功能标识，多词用 `-` 连接，不做中译。
3. frontmatter 重写：`name` = 目录名；`description` 改为「利衡辨_DIY_<功能名> V1.0.0 — <能力一句话>……触发词：……」句式；补齐 `version: 1.0.0`、`author: 利衡辨`、`created` / `updated`、`based_on`、`agent_created: true`、`allowed-tools`。
4. 双端同步：用户级 `~/.workbuddy/skills/` 与工作区 `skills/` 必须同名同内容；旧 ID 目录移入任务夹 `_backup_*/` 归档，禁止直接删除。
5. 落规闭环：转化完成后须同步写入本基本法（本条）、`MEMORY_CORE.md` 硬约束一行、`MEMORY_REFERENCE.md` §六执行细则，否则视为转化未完成。

2.2.4 三字标题强制与存量整改（基本法级硬约束）

本条为 2.2.1 的强制化与存量延伸，规则本体见 M0.7 第 1 条。三条要点：

1. 取值口径：任务夹标题段必须匹配 `^[一-鿿]{3}$`（纯汉字恰三字）；载体名、版本号、任务描述短语禁止进入标题段。
2. 闸门：建夹走 `_tools/deliverable.py::ensure_task_folder()`，其内已内联 `assert_title3()`；禁止手写 `os.makedirs` 或绕过该入口建任务夹。
3. 存量整改：违规存量任务夹按 M0.7 第 1 条（3）四要件整改（脚本 + 回滚 + 双留档 + 复评登记）；Windows 占用项登记不修改。

2.3 标题缺失硬闸

主题名（任务文件夹 / 交付物主题）缺失或经字符清洗后为空时，生成 / 封包环节必须失败终止（raise），禁止以「未命名」「未命名_<时间戳>」兜底产出。中间产物（源稿、配图、编译缓存等）严禁直落工作区根目录或个人目录，必须落于 `<三字标题>_<YYYY-MM-DD_HHMM>/产出|素材/` 任务夹或 `_build/` 归档区，任务结束立即清理。

2.4 命名校验工具

所有命名合规校验必须调用 ~/.workbuddy/_tools/deliverable.py 中的 assert_naming_ok、save_doc、save_wb 等函数，禁止手写文件名。交付前需运行 check_deliverables.py 整目录扫描。

2.5 受控/非受控判定

受控文件必须满足：已分配 UUID；文件名符合 M2.2 模板；已进入工作流状态（至少 draft）。非受控文件不满足上述任一条件，不得进入正式流程，定期清理（30 天未转受控即删除）。

5.3.4 M3 排版规则

3.1 总体排版方法论

采用「分级套版 → 模板驱动 → 字段化 → 机器校核闭环」。所有技术标准、规范、范式、SOP 类文档必须使用 GB/T 1.1 国标模式（正文宋体五号、标题黑体、表格 Table Grid、表题居中于表上方）。公众号文章可使用楷体五号模式（全文楷体、五号 10.5pt、行距 1.15、首行缩进 2 字符），但此模式严禁用于技术标准（参见 M13 EX-7）。

3.2 具体格式参数（国标模式）

• 纸张：A4 纵向，上/下 2.54cm，左/右 3.17cm。
• 正文：宋体，五号（10.5pt），1.15 倍行距，首行缩进 2 字符。
• 标题：黑体，篇级小二（18pt）居中，章级小三（15pt），节级四号（14pt），条目小四（12pt）。
• 表格：Table Grid 全边框，表头黑体加粗并加浅底纹，表题位于表上方居中，编号如「表3.1」。
• 图：居中，图题位于图下方「图 X — 名称」，图号随章连续。
• 页眉：标准名称与版本；页脚：页码域「第 X 页 共 Y 页」。
• 目录：必须使用 TOC 域代码自动生成，禁止手敲静态目录。
• 封面：必须包含五要素（标准名称、标准编号、版本号、发布日期、实施日期、发布机构），并附版本线、适用范围、权威关系、上位关系、待确认事项。

3.3 技术标准成文母规则（STD 系列）

成文格式类问题以 ~/.workbuddy/spec/3.行政法规/母规则/MASTER_RULE_技术标准成文规范.md（V1.1.0）为唯一基准，其核心要求嵌入本 M3，并配套自动判定器 ~/.workbuddy/_tools/doc_style_check.py。规则分组如下：

技术标准成文母规则（STD 系列）

发布前必须运行 doc_style_check.py 进行机器判定，P1 阻断项必须清零方可发布。母规则完整细则（87 条）存储于权威文件，必要时可查阅冷存储 ~/.workbuddy/_archive/MASTER_RULE_FULL_DETAILS.md。

3.4 排版引擎

• 技术标准/规范 → 使用 V1.11.1_lihengbian_DIY_jishubiaozhunpaibanzhushou 的 render.py（国标模式）。
• 学术论文 → 使用 V1.0.0_利衡辨_学术论文排版 的 render_thesis.py（模板锚定华南理工大学硕士学位论文答辩终稿 V21 PDF；仅限学术论文排版，其他风格拒绝执行）。
• 期刊论文 → 使用 V1.0.0_利衡辨_期刊论文排版 的 render_journal.py（《电源技术》期刊版式，前置信息+章条编号+公式编号+图/表+GB/T 7714 参考文献）。
• 公众号 → 使用lihengbian_DIY_gongzhonghaozhushou（版本以 skills_registry.json 登记为准）的 build_word.py（Word 版式）与 build_package.py（三件套封包）。

3.5 量化校验标准

字体、字号、行距、缩进、页边距、表格边框、题注位置等必须与上述参数一致；由 doc_style_check.py 自动化检查（STD-H 组全部条款）。

3.6 公众号三件套豁免

公众号排版独立于本 M3 强制校验，其规范由公众号助手自身流程保证（楷体五号，五号 10.5pt，行距 1.15，首行缩进 2 字符）。命名独立豁免见 M13 EX-1。

5.3.5 M4 场景定义

4.1 场景总览

本体系覆盖 6 个一级场景，细分为 32 个子场景。每个子场景的调用 Skill/专家、输出物、引用 SOP、引用技术规范、关联与复用均以台账的「映射台账」工作表为唯一权威定义，本体系不再重复列出，仅提供子场景清单及所属一级场景。

一级场景与子场景

4.2 场景映射使用规则

每个子场景的详细配置（包括但不限于：调用 Skill/专家名称及版本、输出物清单、引用 SOP 编号、引用技术规范编号、关联与复用关系）必须以台账「映射台账」工作表中对应行的内容为准。当台账更新时，本体系自动同步，无需修改本文件版本。任务启动时，AI 须先读取台账，确认当前场景的完整配置，再执行后续步骤。

4.3 场景与工作流模板对应关系

六个一级场景分别对应 W2 中定义的场景化工作流（DES/CON/MGT/RND/EMG/AI），子场景继承其所属一级场景的工作流路径与分级要求。具体子场景归属哪个工作流模式，由任务发起人根据文件内容性质在启动时指定，或参考台账中隐含的工作流类型。本体系不硬性绑定，允许灵活适配。

5.3.6 M5 文件交付与留存规则

5.1 发布规则

• 所有发布文件必须经过校核、审批（或按场景豁免），最终状态为 released 或 released_pending（紧急）。
• 发布前必须通过命名校验（M2）和排版校验（M3）。
• 技术标准类发布前必须通过 doc_style_check.py 全部 P1 项清零。
• 发布前必须将发布态文件同步至权威库 ~/.workbuddy/spec/ 相应分层目录，并更新 spec/3.行政法规/文档登记表.json。
• （2026-09-18 订正：原 5.1 第 5 条「技术标准自动发布授权」（豁免清单编号 EX-8）及其「E6b 边界句」，因 EX-8 授权本体已删除、且其豁免口径与宪法第 48 条双盘同步口径不符，依「以宪法为准、有冲突即删」口径整条删除；如需重设自动发布授权，须先经人（炳哥）重新裁定并在本 M5.1 本体登记。）

5.2 输出物规则（四件套强制）

凡涉及 skill/专家迭代升版、训练、知识注入，或单份报告/文档（业务交付物 Class A），必须同时产出四件套合一治理件（Class B）：技术规范要求、摘要、变更履历、版本清单合并为离线可运行的单件 HTML 报告。单报告版本清单为本次交付物清单（列：交付物/类型/版本/状态），升级/迭代时为全域登记表快照。四件套生成必须调用 ~/.workbuddy/_tools/fourpiece.emit() 或 skill_upgrade.py，禁止手工拼凑。四件套命名须符合 M2.2 Class B 正则，由 save_doc/save_wb 校验后落盘。

5.3 存储与归档规则

5.3.1 任务夹铁律

所有交付物必须先建任务夹 <三字标题>_YYYY-MM-DD_HHMM/产出/ 再落盘，禁止直落工作区根、桌面、下载、文档等个人目录。此规则由 _tools/deliverable.py 的 ensure_task_folder 和 assert_in_task_folder 硬闸保障。轻量活不豁免。

5.3.2 规范盘配置与同步

工作区动作落盘路由以宪法第48条为唯一准据：规范盘配置与同步实行权威盘→发布盘双盘机制，全域统一为双盘：规范件落权威盘，任务产物与交付物落发布盘；不再设训练盘／校核盘落盘路由。

5.3.3 权威库优先发布

所有发布内容必须同步到权威库 ~/.workbuddy/spec/ 相应目录（范式→spec/3.行政法规/范式/，SOP→spec/3.行政法规/SOP/，标准库→spec/3.行政法规/标准库/，母规则→spec/3.行政法规/母规则/），并更新 spec/3.行政法规/文档登记表.json。未经权威库同步的发布视为虚假发布。工具链入口为 _tools/refresh_register.py，禁止绕过工具链手工篡改登记表。回拷规范库强制步骤：升版脚本在四件套生成后强制调用 sync_specs_register.py 完成回拷与登记表升级，未收敛即阻断升版。

（2026-09-18 订正：原 5.3.4「双盘同步架构（权威盘→发布盘单向同步）」，因覆盖宪法未及的训练盘／校核盘，与宪法第 48 条确立的「权威盘→发布盘」双盘同步口径不一致，依「以宪法为准、有冲突即删」口径删除该整节；盘位与同步规则以宪法第 48 条为唯一准据。）

5.3.5 技术标准版本保留策略（权威盘仅留最新版）

权威盘 spec/3.行政法规/范式/ 下技术标准 docx 升版后立即删除该主题旧版 docx，仅保留最新版；旧版不归档 .bak，直接删除。校验方式：同一技术标准主题的 docx 版本数 = 1，旧版残留 = 0。

5.3.6 训练资料唯一归档区

高级专家、异源双模校核、电池专家等对象的训练资料须归档至各自专用归档区，由 _tools/archive_train_assets.py / archive_battery_assets.py 执行非破坏复制 + MD5 校验，禁止手工零散拷贝。每轮训练后必须归档并跑 --check，将结果写入场景B任务收尾总结（S10，见 M0.6）。

5.3.7 规范文件统一保存与双盘同步规则

本款与《全域任务脑手架构宪法》第 48 条同源承载，为文件域执行细则（2026-09-18 炳哥指令设立）。

• 双盘定位：权威盘 `C:\Users\xub\.workbuddy`（SSOT，唯一可写）；发布盘兼备份盘 `D:\★WorkBuddy_ReStructuration★\★利衡辨_全域发布★`（权威盘只读同步副本，兼作全域规范文件备份载体）。
• 统一目录：今后所有规范文件统一保存至各盘 `spec` 文件夹；该文件夹不存在时，必须先新建再保存。
• 分层路径与命名规则：

规范文件分层保存路径与命名规则

• 同步方式：权威盘 → 发布盘单向增量同步，副本禁止反向写入，冲突一律以权威盘当前态为准；治理资产变更后即触发增量同步，每日全量对账；同步前在发布盘 `.sync_snapshots\` 创建快照，同步失败保留上一稳定副本、自动回滚并告警，禁止以失败态副本冒充成功；快照保留 7 天；工具链 `_tools/sync_disks.py`，实现前以人工 robocopy 执行。
• 归并口径（2026-09-18 炳哥裁定）：统一归入 `spec` 口径——既有 `specs/` 权威库归并入 `spec` 分层结构（宪法→`spec\1.宪法\`，基本法→`spec\2.基本法\`，范式/SOP/标准库/母规则等分项规范→`spec\3.行政法规\`），`spec` 为规范文件唯一执行依据，`specs/` 不再作为执行依据。

5.3.7 M6 文件分级管理规则

6.1 分级判定标准

文件分级判定标准

若无法确定，默认按 B 级处理。

6.2 分级与工作流/模板映射

分级与工作流/模板映射

6.3 AI 校验强度细化

• A级：命名校验（100%）、排版全项（P1+P2）、内容完整性、引用有效性、版本连续性、哈希校验。
• B级：命名校验、排版关键项（P1）、内容关键字段。
• C级：仅命名与存储路径检查。

5.3.8 M7 配置管理与基线规则

7.1 基线定义

基线是经过正式审核批准的技术状态文件集合，作为后续开发、修改和审计的基准。本体系维护两类基线：技术基线（所有技术标准、规范、范式的已发布版本）与文档基线（项目/系统的关键文档（A 级文件）的已发布版本）。

7.2 基线标识规则

基线编号：BL-<基线类型>-<YYYYMMDD>-<序号>；基线状态：草案 → 审核中 → 已批准 → 已归档。

7.3 基线审计

频率：每季度对技术基线进行符合性审计，每年对文档基线进行抽样审计。范围：检查基线文件是否齐全、版本是否正确、是否与登记表一致。报告：审计结果记入 R6 审计报告，并提交标准委员会。

7.4 变更影响分析

当提议修改已批准基线中的任何文件时，必须执行变更影响分析（见 M8），评估对上下游文件、系统、流程的影响。影响分析结果作为变更申请的必要附件。

5.3.9 M8 变更管理规则

8.1 变更类型与优先级

变更类型与优先级

（2026-09-18 订正：原优先级代码「P1（最高）／P2（高）／P3（中）」与《全域任务脑手架构宪法》第 41 条缺陷分级「P0 阻断性／P1 严重／P2 一般／P3 轻微」同形异义，跨法引用必生歧义，依效力层级删除该代码，优先级改用文字口径；缺陷分级一律以宪法第 41 条为准。）

8.2 变更影响评估维度

变更请求必须评估以下维度，影响评分 = 范围×严重性：范围为单文件（1分）/多文件（2分）/跨项目（3分）；严重性为轻微（1分）/中等（2分）/重大（3分）。评分 ≥ 6 必须升主版本并通知所有下游用户。

8.3 变更请求模板（R7）

所有变更须填写 R7 问题报告与改进表单，包含变更原因、变更内容、影响分析、测试结果。

5.3.10 M9 访问控制与安全保密规则

9.1 访问控制模型（RBAC）

基于角色的访问控制，角色与权限映射见 M1.1。权限级别：读（R，查看文件内容与元数据）；写（W，修改文件内容，仅 draft 状态）；执行（E，执行状态转移）。

9.2 密级权限映射

密级权限映射

9.3 加密与审计日志

秘密及以上密级文件在传输和存储时须使用 AES-256 加密。所有访问与操作行为须记录审计日志（时间戳、操作人、操作类型、文件 UUID），保存期限 ≥ 10 年。

5.3.11 M10 术语扩展与行业适配

10.1 行业专用术语

本模块预留用于各行业（如电力、建筑、金融）专用术语的登记。新增术语须经标准委员会审批后补充至第一篇术语与定义。

10.2 特殊文件类型扩展

预留用于新增文件类型（如 CAD 图纸、BIM 模型）的命名与排版规则扩展。

5.3.12 M11 文件内容结构标准

11.1 必备章节定义（适用于技术标准/规范/范式）

按照 STD-B 四篇式结构：

四篇式必备章节

11.2 元数据嵌入位置

范式源（.md）：使用 YAML frontmatter 或 HTML 注释块。发布态（.docx）：使用 Word 文档属性（标题、主题、版本、UUID）或封面页显式列出。元数据字段必须包含：UUID、版本号、状态、最后更新日期。

5.3.13 M12 文件传输与交换规则

12.1 传输渠道

内部网盘用于正式文件流转；邮件仅用于通知与摘要，不传输完整受控文件；API 接口用于系统间自动化同步（延迟 ≤5 分钟）；小程序/云端沙箱按 MEMORY 多端文件体系区分，云端产物须通过「查看文件→导出」或「连接电脑」模式传回。

12.2 格式转换

转换前必须校验源文件完整性（哈希比对）。转换后必须校验目标文件格式是否符合 M3（如 PDF 由 docx 导出，需校验字体嵌入）。格式转换不视为内容变更，不触发版本递增。

12.3 接收确认与完整性校验

接收方在接收受控文件后 24 小时内反馈确认，并在系统中记录接收日志。接收时必须校验文件哈希与登记表记录一致，不一致则拒绝接收并报告。

5.3.14 M13 豁免清单

本清单集中定义各项豁免条款。任何豁免仅在满足触发条件时生效，不得扩展解释。

豁免清单

（2026-09-18 订正：EX-5 生效范围原标注「M9 安全红线」，经全篇核查 M9 访问控制与安全保密规则无该条款、MEMORY.md 亦无对应定义，属悬空锚点，经炳哥裁定删除该指向；EX-5 豁免项本身保留，生效范围待 M9 本体登记安全红线条款后另行锚定。）

（2026-09-18 订正：原 EX-8「技术标准自动发布授权」，其本体（M5.1 授权条）已依「以宪法为准、有冲突即删」口径删除，本豁免行随之失效并删除；如需重设，须先在人（炳哥）裁定下重建 M5.1 授权条，再行登记豁免。）

5.3.15 M14 复用矩阵

本矩阵集中定义台账「复用矩阵」工作表中的所有复用对象及其覆盖子场景。凡标注 Ⓡ 的复用对象，其生效范围与引用方式以此表为准。

复用矩阵

复用矩阵使用说明：任务启动时，须根据子场景判定需引用的 Ⓡ 对象，并确保相关 SOP/规范已读且工具链可用。若矩阵中列出的某 Ⓡ 对象与台账「关联与复用」列不一致，以台账为准，并立即同步更新本矩阵。

5.4 第三篇 全域文件工作流准则

本篇以 MEMORY.md 中「skill 生命周期统一 SOP」及「启动顺序」为基础，定义 W1–W6 工作流准则。

5.4.1 W1 工作流基础模型

1.1 状态定义

文件状态定义

1.2 通用转移规则

• 所有文件必须从 draft 开始，除 AI 生成文件从 ai_pending 开始。
• 发布前必须经过至少一次校核（紧急场景和 AI 场景 C 级文件除外）。
• 超时处理：各节点时限超时后，系统自动向责任人及上级发送提醒；超时 24 小时未处理，升级至项目经理或部门负责人；超时 72 小时，挂起流程并通知标准委员会。
• withdrawn 仅允许在 check、review、approved 状态由提交者发起，撤回后回到 draft。
• merging 状态由版本控制工具自动置入，合并完成后进入 check 重新校核；合并完成后系统自动通知原提交者或项目负责人指定的责任人，须在 24 小时内发起校核。
• released_pending → released：补充校核/审核记录完成后，由系统自动触发。
• released_pending → obsolete：超过 7 天未补充记录，归档管理员可手动转为 obsolete。
• released_pending → withdrawn：提交者或批准人发现重大缺陷时可发起撤回，经批准人确认后回到 draft。
• ai_rejected → draft：人工确认不通过后，由人工接管修改，直接进入 draft 状态。
• 所有状态转移必须记录审计日志（时间戳、操作人、原因）。

1.3 并发控制与锁定

• 编辑前必须签出，其他用户只读。
• 签入哈希比较基准：首次签入记录哈希分配 V1.0；后续签出记录当前哈希作为基准；签入时计算新哈希，与基准比较：相同则仅解除锁定，不同则提示选择变更类型。
• 已发布文件修订：从 released 发起修订，创建新草稿（继承 UUID，自动分配下一版本号），旧版转为 archived。默认升主版本（如 V1.0 → V2.0），仅错别字/格式微调可申请次版本（经批准人确认）。
• 非 draft 状态文件自动锁定编辑权限。

5.4.2 W2 场景化工作流定义

每种场景根据文件级别（A/B/C）定义不同的状态路径。

2.1 设计场景（DES）

设计场景（DES）状态路径

并发：允许并行编辑，合并时进入 merging，合并后重新校核。例外：紧急变更可转 EMG 场景；设计变更需重新校核并升版。

2.2 施工场景（CON）

施工场景（CON）状态路径

例外：口头指令可先执行，事后 24 小时内补文件流程。

2.3 管理场景（MGT）

管理场景（MGT）状态路径

本场景 B 级依据 M6.2 例外条款，省略批准节点，以场景定义为准。例外：周报、会议纪要可批量校核。

2.4 科研场景（RND）

科研场景（RND）状态路径

本场景 B 级依据 M6.2 例外条款，省略批准节点。例外：实验记录可采用非受控命名，但需定期归档。

2.5 紧急场景（EMG）

所有级别均采用相同路径：draft → approved → released_pending（发布后补记录）。审批节点：批准人（项目负责人或授权代表）。时限：立即处理，批准后 1 小时内发布。

紧急批准授权人：项目负责人可预先指定 1-2 名授权代表，授予紧急批准权限，有效期不超过 30 天。

例外处理（安全回退机制）：

• 紧急发布后进入 released_pending，文件可被引用，但须标记「待补记录」。
• 必须在 24 小时内补充校核和审核记录（A级须补审核，B/C级可仅补校核）。
• 补充完成后，状态自动转为 released，清除标记。
• 补充记录操作：校核人/审核人通过系统「补充记录」入口填写 R2/R4 表单，提交后系统自动判断并转为 released。
• 若 24 小时内未补充，系统持续提醒；超过 7 天仍未补充，归档管理员可决定转为 obsolete。
• released_pending 文件在下游引用时，系统应提示风险。

2.6 AI生成场景（AI）

按文件分级采用不同状态路径与审批节点。

AI生成场景（AI）状态路径

时限：AI 生成后 4 小时内必须人工确认，否则自动标记「待处理」。ai_rejected 后续处理：人工接管修改，进入 draft 走正常流程，或直接废弃（转 obsolete）。例外：未经人工确认不得用于正式用途。

5.4.3 W3 并发控制与例外处理

3.1 并发控制与锁定

同 W1.3。

3.2 例外处理规则

• 紧急放行：按 W2.5 执行，使用 released_pending 状态。
• 历史文件处理：历史文件首次流转时，不强制立即改名，但必须填写 R3.1 历史文件命名差异记录表，并制定迁移计划（最长期限 6 个月）。
• 校核豁免：历史文件在填写 R3.1 后，G1 校核判定中的「命名错误=0」和「版本断裂=0」不适用，以 R3.1 替代 R3。
• 历史文件不参与命名合规率 KPI 统计，直至完成迁移。逾期未完成迁移的文件，恢复纳入 KPI 统计，并由标准委员会启动整改。
• 规则变更迁移：新规则生效后，仅适用于新建文件；历史文件保持原规则，可在下次升版时逐步迁移。

5.4.4 W4 规则版本与系统集成

4.1 规则版本自动同步与分发

规则配置中心：所有规则以结构化文件（YAML/JSON）存于 Git 仓库，版本号唯一。AI 任务启动时强制拉取最新已发布规则版本，校验哈希值。更新通知通过消息队列推送，AI 实例需在 5 分钟内确认；若未确认，系统每 2 分钟重试一次，最多重试 3 次。超过重试窗口仍失败，暂停该实例并记录异常。

4.2 系统集成接口规范

集成对象：文档管理系统（如 SharePoint）、项目管理系统（如 Jira）、版本控制工具（如 Git）。冲突解决优先级（从高到低）：安全/权限冲突 > 状态冲突 > 版本冲突 > 元数据冲突。

4.3 规则优化库与修订流程

规则优化库：位于配置中心 Git 仓库的 rule_optimization/ 目录。评审流程：标准委员会每季度评审一次；若月度错误率 > 2%，立即触发评审。修订触发：评审通过后更新规则版本，通知所有 AI 实例，记录修订原因。

4.4 一键升版脚本

skill 升版：python ~/.workbuddy/scripts/skill_upgrade.py --skill <技能名> --type feature|bugfix --note "说明"。自动计算版本号、更新 SKILL.md、归档旧目录（.bak）、同步登记表、生成四件套、执行一致性体检。升版前强制 check_spec_gate（无范式拒绝），区域路由强制发布盘。支持 --dry-run 预览，--audit 全量体检。

5.4.5 W5 非受控文件生命周期管理

5.1 非受控文件定义

不满足 M2.4 受控条件的文件，包括临时笔记、参考资料、草稿片段、实验原始数据等。

5.2 生命周期

创建：直接保存至非受控区域（如 素材/ 或临时目录），不分配 UUID，不进入工作流。使用：仅限个人或小组内部参考，不得用于正式交付或下游引用。转受控：如需转为受控文件，必须经过命名校验、元数据补全、审批，分配新 UUID，进入 draft 状态。清理：非受控文件保存期限不超过 30 天，超期未转受控即删除。归档管理员每月执行一次清理。

5.3 标识与隔离

非受控文件在文件名或元数据中标记 UNCONTROLLED，与受控文件物理隔离存储。

5.4.6 W6 工作流绩效与审计

6.1 审计范围与频率

审计范围：所有 A 级文件、B 级关键文件、全部紧急放行记录、AI 生成文件抽样。审计频率：每季度进行一次全面审计；月度进行 KPI 指标通报。

6.2 抽样方法

采用基于风险的抽样方法，从各场景、各级别中分层抽样：高风险场景（紧急放行、A级文件）抽样比例不低于 10%，其他场景不低于 2%；最低抽检数量不少于 20 条，最高不超过 200 条。若当月日志总数不足 20 条，则全量抽检。

6.3 审计报告要素

审计报告（R6）须包含：审计范围、抽样方法、KPI 达成情况、不符合项清单（引用 R4）、改进建议、审计结论。

6.4 不符合项闭环

发现的不符合项必须填入 R4-B，指定整改责任人、期限，整改完成后由审计人员验证并关闭。

5.5 第四篇 全域文件指导方法论

5.5.1 G1 校核方法论

输入：待校核文件、命名检查单（或 R3.1 历史文件差异记录表）、技术依据、关联文件。

步骤：

1. 命名合规检查：调用 ~/.workbuddy/_tools/check_deliverables.py 或 naming_audit.py 进行机器扫描。常规文件命名错误=0；历史文件以 R3.1 为准，检查差异记录表是否填写完整。
2. 内容完整性检查：比对 M6 分级模板必填项，检查缺失项=0。
3. 技术正确性检查：核验引用规范版本、计算公式、数据来源是否有效。
4. 格式一致性检查：调用 doc_style_check.py 进行排版参数校验（A 级强制全项，B 级关键项，C 级仅命名）。
5. 版本连续性检查：检查版本号、UUID、文件哈希链是否连续；历史文件版本断裂豁免。
6. 填写校核记录表（R2）：记录缺陷项与结论。

判定标准：

• 常规文件：命名错误=0；重名未处理=0；缺失项=0；技术错误=0；格式问题≤3处；版本断裂=0。
• 历史文件：命名错误和版本断裂豁免，但 R3.1 必须完整（含迁移计划）。
• 校核结论：通过 / 不通过（附带缺陷清单）。

5.5.2 G2 审查方法论

审查输入：已通过校核的文件、校核记录、相关合规要求。

步骤：合规性检查（是否符合法律法规、公司制度、合同要求）；完整性检查（是否覆盖所有必要要素）；一致性检查（与其他相关文件是否矛盾）。

判定标准：严重不符合项=0；一般不符合项≤2且已制定整改计划；不符合项在 R4-B 中逐行记录。

审查输出：R4-A 审查主表 + R4-B 不符合项子表。

5.5.3 G3 命名方法论

• 哈希算法：全文统一使用 SHA-256（对文件正文内容的规范化纯文本计算，去除所有元数据、排版信息、页眉页脚、批注）。摘要长度为 64 位十六进制字符串。
• 命名正则：M2.2 中定义的 Class A / Class B 正则，由 deliverable.py 维护为唯一真相源。
• 命名校验：必须通过 deliverable.assert_naming_ok，否则拒绝落盘（save_doc/save_wb 抛 NamingError）。
• 文件夹命名：任务夹 <三字标题>_YYYY-MM-DD_HHMM，由 ensure_task_folder 自动生成，禁止手工拼接。
• 历史文件处理：使用 R3.1 差异记录表替代 R3，并在命名合规率 KPI 中豁免。

5.5.4 G4 版本控制方法论

版本号规则：

• 主版本（主.0.0）：重大技术修改、结论改变、结构变化、影响下游文件。
• 次版本（主.次.0）：新增功能、知识、能力（如新增章节、新增规则）。
• 补丁版本（主.次.修订）：错别字修正、格式微调、非实质性内容增删。

升级辅助机制：签入时若检测到文件结构重大变化（章节增删超过 30%、关键数据修改），系统提示用户确认是否升主版本。AI 可辅助分析变更影响并提供建议。

版本登记表：所有 skill/专家版本记录在 ~/.workbuddy/skills_registry.json，为唯一真相源。每次升版必须同步更新登记表，由 skill_upgrade.py 自动完成。

升版工具：skill 升版必须使用 skill_upgrade.py，专家升版必须使用 expert_upgrade.py，禁止手工修改版本号。历史版本目录归档为 .bak，但技术标准 docx 仅保留最新版。

版本变更记录（R5）：每次变更须填写 R5，包含 UUID、变更前后哈希、变更类型、变更说明。哈希计算范围明确为正文内容，格式转换不触发版本递增。

5.5.5 G5 工作流建模方法论

• 使用状态机模型定义文件生命周期，状态转移遵循 W1.2 规则。
• 每个场景（W2）可定义不同的状态路径，但必须遵守 M6 分级要求。
• 状态图使用 Mermaid 或 BPMN 描述，关键转移（如 released_pending → released）必须明确定义触发条件和操作人。
• 工作流模型中每个节点必须标注：触发条件、责任人、校验方式、时限。

5.5.6 G6 其他方法论

6.1 模板使用方法论

所有记录模板（R2–R8）必须包含 UUID 字段，用于追溯。模板字段分为「必填」与「选填」，必填项缺失即校核不通过。模板版本与体系版本同步更新，变更时须填写 R5。

6.2 四件套生成方法论

四件套（技术规范要求、摘要、变更履历、版本清单）由 ~/.workbuddy/_tools/fourpiece.emit() 一键生成。主题从任务文件夹名派生，时间戳继承任务夹，类型后缀自动追加。单报告版本清单取本次交付物清单（非全域登记表），升级/迭代取全域登记表快照。

6.3 工具链调用方法论

所有命名、路径、落盘操作必须通过 _tools 工具链，禁止直接文件系统操作。调用前需 sys.path.insert(0, '~/.workbuddy/_tools') 确保导入。交付后必须运行 check_deliverables.py 整目录校验，退出码 0 方为合规。

5.6 第五篇 全域文件记录规范化

5.6.1 R1 记录总则

• 所有记录必须包含 UUID、文件名、版本号、状态、时间戳、操作人。
• 哈希校验使用 SHA-256，摘要 64 位十六进制。
• 记录保存期限：A 级文件关联记录保存 ≥ 10 年，B 级 ≥ 5 年，C 级 ≥ 1 年。
• 记录不可篡改，任何修改须新增版本并保留前序版本（审计需求）。

5.6.2 R2 校核记录表

R2 校核记录表字段

5.6.3 R3 命名检查单

R3 命名检查单字段

5.6.4 R3.1 历史文件命名差异记录表

R3.1 历史文件命名差异记录表字段

5.6.5 R4 审查记录表（父子表）

4.1 审查主表（R4-A）

R4-A 审查主表字段

4.2 不符合项子表（R4-B）

R4-B 不符合项子表字段

统计不符合项数量时，按子表行数计算。审查不通过时，主表「审查结果」填「不通过」，子表至少一条记录。

5.6.6 R5 版本变更记录表

R5 版本变更记录表字段

哈希计算范围：文件正文内容的规范化纯文本（去除元数据、排版信息、页眉页脚、批注）。格式转换（如 DOCX 转 PDF）不视为内容变更，不触发版本递增。

5.6.7 R6 审计报告模板

R6 审计报告模板字段

5.6.8 R7 问题报告与改进表单

R7 问题报告与改进表单字段

5.6.9 R8 AI执行日志规范

R8 AI执行日志规范字段

质量闭环：采用基于风险的抽样方法，每月从各场景、各级别中分层抽样，高风险场景抽样比例不低于10%，其他不低于2%；最低抽检数量不少于20条，最高不超过200条。发现错误自动加入规则优化库（见 W4.3）；月度错误率 > 2% 时，标准委员会立即评审规则优化库并触发修订。

兜底条款：若当月 AI 执行日志总数不足 20 条，则全量抽检，并在审计报告中注明「样本量低于最低抽检数，已全量检查」。

5.7 附加模块 新技术适配

5.7.1 AI 生成文件管理规则

• 自动标记 AI-GEN，初始 ai_pending，人工确认通过后转 ai_confirmed，再转 draft（按级别进入后续流程）。
• 遵守命名规则（M2），分配 UUID。
• 未经确认不得用于正式用途。
• 人工确认不通过转 ai_rejected，人工接管修改后进入 draft，或直接废弃（转 obsolete）。
• AI 生成文件若为业务交付物，必须配套四件套（Class B）。

5.7.2 新兴技术适配

• 引入新工具或协作方式时，评估影响，通过变更流程更新规则。
• 实时协作可简化锁定，但版本记录更频繁。

6 校验方法

本载体的校验按下列四闸执行。

全域文件体系基本法校验闸门

参考文献

[1] 全域任务脑手架构宪法 V1.0.0

[2] 全域文件体系基本法 V1.0.0_2026-09-18_1545

[3] GB/T 1.1-2020 标准化工作导则 第1部分：标准化文件的结构和起草规则

[4] 全域文件体系基本法 V1.0.0

附录 A 六层主干与宪法条号对照表

六层主干与宪法条号对照表

附录 B 载体源清单索引

载体源清单索引