docs: 增加轻量项目治理模式 (#30)

AGENTS.md

@@ -1,10 +1,10 @@
 # Agent 开发规则
 
-本仓库采用 DevHarness 工作流：Gitea 工单是单次任务需求、变化、实现、测试、提交和验收的事实来源，Gitea Wiki 是长期开发文档的事实来源，Git 是代码与版本绑定资料的变更记录。`docs/` 默认保存核心 Wiki 的只读镜像，`docs/task/` 只保存人工明确要求的专项或历史兼容快照。人负责确认方案与验收，Agent 负责检查、实现、测试和留下证据。
+本仓库采用 DevHarness 工作流：需要工单的任务以 Gitea 工单作为需求、变化、实现、测试、提交和验收的事实来源；符合轻量模式直接实施条件的任务以用户确认范围、Git 提交和结果报告留痕。Gitea Wiki 是长期开发文档的事实来源，Git 是代码与版本绑定资料的变更记录。`docs/` 默认保存核心 Wiki 的只读镜像，`docs/task/` 只保存人工明确要求的专项或历史兼容快照。人负责确认目标与必要验收，Agent 负责检查、实现、测试和留下与风险相称的证据。
 
 开始工作前先阅读任务涉及目录中的 `AGENTS.md`。目录越深的规则越具体，但不得削弱上级安全规则。
 
-[项目档案](docs/00-project-profile.md) 按需阅读，不作为每次任务的固定前置。出现下列情况之一时必须读：需要环境、配置或凭据来源；需要确认目录边界；需要判断子项目与交付单元划分；需要 DevHarness 来源与基线；需要项目专用验收要求。只为查命令不必打开项目档案。
+[项目档案](docs/00-project-profile.md) 按需阅读，不作为每次任务的固定前置。首次接手项目、治理模式不清楚，或出现下列情况之一时必须读：需要环境、配置或凭据来源；需要确认目录边界；需要判断子项目与交付单元划分；需要 DevHarness 来源与基线；需要项目专用验收要求。同一会话已经确认且没有变化时不重复读取；只为查命令不必打开项目档案。
 
 ## 常用命令
 
@@ -24,7 +24,7 @@
 
 ## 1. 永久规则
 
-- 不把密码、令牌、Cookie、私钥、个人数据或生产数据写入代码、日志、工单、Wiki 和文档。
+- 不把密码、令牌、Cookie、私钥、真实个人数据或生产数据写入代码、日志、工单、Wiki 和文档。明确为虚构的测试数据无需形式化脱敏，但必须能与真实数据区分；来源不明时按真实数据处理。
 - 不执行未经用户明确授权的发布、付款、删除数据、破坏性迁移或其他不可逆操作。
 - 保留用户已有和任务无关的工作区改动，不擅自重置、覆盖或混入提交。
 - 发现需求与安全规则、已确认方案或现有数据冲突时，先停止实施并说明影响。
@@ -34,24 +34,20 @@
 
 ## 2. 哪些改动需要工单
 
-新功能、缺陷修复、重构以及任何用户可感知或改变程序行为的修改，必须先建立单元任务工单。
+项目治理模式记录在[项目档案](docs/00-project-profile.md)。内部、单人、低风险项目优先使用轻量模式；任务真实风险高于项目模式时，只升级该任务。
 
-以下小改动可以直接提交，不要求工单：
+- 轻量模式：文案、注释、格式、局部样式或布局、预期行为明确的小 Bug，以及不改变接口、数据结构、权限和安全边界的单模块低风险调整可以直接实施。完整独立需求、新页面或跨模块功能，以及涉及 API、数据结构、权限、安全、迁移或范围不明确的变化必须建单。
+- 标准模式：纯文档措辞、格式化、内部标识符改名和确定不改变行为的小整理可以直接实施；新功能、缺陷修复、重构及用户可感知的行为变化必须建单。
+- 高风险模式：只读诊断和不改变行为的文档整理可直接进行；正式行为变化必须建单并等待人工确认。
 
-- 只改错别字、注释或文档措辞；
-- 只做格式化、导入排序或不跨文件的内部变量改名；
-- 补充类型标注或文档字符串且不改变行为；
-- 删除已经确认无人使用的死代码。
-- 只修改用户看到的界面显示文案，并且满足本文件“工单与设计证据双门禁”的全部豁免条件。
-
-除严格符合界面显示文案豁免的修改外，只要涉及接口、数据库、状态、权限、安全、并发、用户界面，或者无法确定是否改变行为，就必须建工单。代码组件名、类名、变量、国际化键、API 字段和数据库字段不是显示文案，不适用豁免。
+直接实施项无需为了留痕补建工单；只做必要的工作区与安全检查、受影响范围的最小测试并报告结果。涉及权限、安全、支付、真实个人或生产数据、迁移、并发、删除和不可逆操作时始终按高风险处理。无法判断时先澄清或建单，不按代码行数判断风险。
 
 ## 3. 需求到实施
 
 1. 先复述目标，阅读相关代码、日志和文档，区分事实与假设。
 2. 给出目标、非目标、方案、影响范围、风险、回退方式、验证方法和文档影响。
-3. 方案没有得到用户明确确认前，只做只读诊断和方案整理，不实施正式代码。
-4. 方案确认后，先建立单元任务工单，再修改代码。
+3. 需要方案确认的任务在用户明确确认前，只做只读诊断和方案整理；轻量模式下目标与预期行为已经明确的直接实施项不增加单独方案门禁。
+4. 需要工单时，方案确认后先建单再修改；符合直接实施条件时不建单。
 5. 建立新工单不要求其他工单已经完成；开始实施前检查工单声明的前置工单。真实依赖未满足时保持“待实施”，允许并行时必须写明原因。
 6. 开始实施前检查分支和工作区，明确哪些现有改动不属于本任务。
 7. 严格按工单范围实现；新发现的问题先记录，不顺手混入当前任务。
@@ -60,7 +56,7 @@
 
 工单正文保存用户确认的任务基线；根因、范围、方案、风险或阻塞发生重要变化时追加评论。完成实现后用一条评论集中记录最终差异、测试、未验证内容、提交哈希和文档影响；用户验收后再追加验收时间与结论，不重复覆盖或抄写已有证据。
 
-Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明确授权，不得默认绕过建单。
+需要建单而 Gitea 不可用时，输出完整工单草稿并说明阻塞。不得把直接实施豁免扩展到本应建单的任务。
 
 ### Gitea 交互与工单最小读取
 
@@ -80,14 +76,15 @@ Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明
 - 每个核心页面写入后必须在线回读并取得 revision。页面缺失、回读失败或没有 revision 时停止初始化，不得开始产品代码。
 - 产品编码前必须运行 `python dev_scripts/harness.py sync --verify`；全部成功才表示线上 Wiki 和核心镜像初始化完成。
 
-### 工单与设计证据双门禁
+### 按治理模式选择最小设计证据
 
-- 纯界面显示文案只有在不改变业务含义、流程、权限、状态、接口、数据、法律/安全/支付/单位等高风险含义、国际化键、程序标识符、布局和可访问性，且没有任何不确定时，才免工单和原型；修改后执行最小界面检查。
-- 新页面、独立用户功能、重大交互或导航变化，必须先用 Quant-UX 或其他合适工具制作可审阅原型；用户确认原型、文字需求和覆盖范围后，才能建立或放行实现工单并编写生产代码。
+- 轻量模式的小 Bug、局部样式或布局、复用现有规范的组件调整无需完整原型；一句话、现有界面或标注截图足以确认时停止增加设计材料。
+- 完整独立需求、新页面、重大交互或导航变化需要工单；只有存在明显交互不确定性、用户明确要求，或返工成本显著时，才制作 Quant-UX 或其他可审阅原型。
+- 标准模式的新页面、独立用户功能和重大交互使用可审阅原型；小范围 UI 使用最低成本的文字、截图或低保真证据。
+- 高风险任务按影响补充技术设计、数据和权限边界、回退方案及人工确认；非 UI 任务不制作无意义的 UI 原型。
 - 上述完整原型形成待审核版本后，默认直接通过 Quant-UX 或其他设计工具的线上链接审核，不要求每次导出本地 HTML。工单必须记录可访问链接、版本/revision 或确认日期、审核版本识别方式、确认人、确认时间和覆盖范围；线上链接无法访问或无法区分版本时停止审核，等待用户确认等效方案。
 - 只有用户明确要求 `导出原型 #N`、`导出全部原型`，或项目专用规则明确要求离线交付时，才导出到 `prototypes/<工单号>/<版本>/index.html`。已确认的本地快照不得原位覆盖；版本目录内资源使用相对路径，导出后检查入口、主要交互和资源完整性，但不自动提交。
-- 现有界面的小范围样式或布局调整使用标注截图、低保真图或明确复用的现有规范；新组件记录状态、错误和边界。两者只要不符合纯文案豁免就必须建单。
-- 后端、接口、数据处理和定时任务不强制 UI 原型，但必须先确认架构、API、数据、状态或流程设计；恢复既有确认行为的 Bug 可以复用原设计、截图、复现步骤或已有验收证据。
+- 后端、接口、数据处理和定时任务不强制 UI 原型；仅在存在设计选择或中高风险时确认必要的架构、API、数据、状态或流程设计。恢复既有确认行为的 Bug 可以复用原设计、截图、复现步骤或已有验收证据。
 - 需要设计证据的工单记录链接或路径、版本/revision 或日期、状态、确认人、确认时间和覆盖范围；没有 UI 原型时记录替代技术设计或原因。
 - 页面结构、主要流程、状态、权限、异常处理或验收结果变化时，必须更新原型或文字需求并重新确认后再继续正式编码。
 - 草稿原型可以用于讨论；写入 Git/Wiki、多人协作或单独实施时建立设计任务。草稿和经明确授权的隔离技术验证都不得直接作为生产实现。
@@ -124,7 +121,7 @@ Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明
 
 ### 效率与范围控制
 
-本节只用于减少无关工作和重复检查，不得削弱安全规则、已确认方案、工单范围、必要测试、必要的长期文档同步、Git 提交和人工验收要求。
+本节只用于减少无关工作和重复检查，不得削弱安全规则、已确认目标、需要工单时的工单范围、必要测试、必要的长期文档同步和 Git 提交要求。
 
 #### 严格控制范围
 
@@ -156,7 +153,7 @@ Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明
 
 ## 4. 工单层级
 
-- 单元任务是唯一正式实施单位，记录方案、范围、验收标准、过程和测试结果。
+- 需要工单时，单元任务是正式实施单位，记录方案、范围、验收标准、过程和测试结果；直接实施项不进入 Epic/MVP 层级。
 - Epic 和 MVP 只维护目标、风险、汇总及 `- [ ] #编号` / `- [x] #编号` 子工单索引，不复制单元任务全文。
 - 新任务先建单元工单，再把编号同步到所属 MVP 和 Epic。
 - 详细层级、状态和模板入口见 [开发工作流](docs/01-workflow.md) 与 [业务规则和术语](docs/03-business-rules-and-glossary.md)。
@@ -172,8 +169,8 @@ Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明
 
 ## 6. Git 与验证
 
-- 提交只包含当前工单相关文件。
-- 实现提交信息引用工单号，例如：`fix: 修复登录超时 (#123)`。
+- 提交只包含当前任务相关文件。
+- 有工单时提交信息引用工单号，例如：`fix: 修复登录超时 (#123)`；直接实施项不制造工单号。
 - 不为流程制造空提交。
 - 优先运行项目档案中记录的格式检查、静态检查、单元测试和必要的集成测试。
 - 不能验证的真机、生产、迁移或并发行为必须写入工单；存在明确要求的任务快照时再同步记录。
@@ -183,6 +180,8 @@ Gitea 不可用时，输出完整工单草稿并说明阻塞。未经用户明
 
 ## 7. 完成和验收
 
+直接实施项完成最小测试、必要文档影响处理和 Git 提交后报告结果即可，不创建工单状态或补写验收记录。以下流程适用于有工单的任务：
+
 1. 逐项完成验收、测试和实现提交，在工单追加最终证据评论，记录最终方案、差异、结果、提交、遗留问题和文档影响。
 2. 工单保持“待验收”，用户没有明确验收通过前不得关闭。
 3. 有长期文档影响时，读取确认 Wiki，运行 `python dev_scripts/harness.py sync --check` 检查核心镜像，并把页面 revision 和镜像提交哈希写回工单；没有长期文档影响时不运行 Wiki 同步。
@@ -226,7 +225,7 @@ MVP 内所有单元任务通过后才能做 MVP 集成验收；MVP 通过后才
 
 <!-- 在项目初始化时填写不可违反的技术、安全和业务约束。复杂子项目请在其目录中增加 AGENTS.md。 -->
 
-- 长期开发文档以 Gitea Wiki 为事实来源，单次任务证据以 Gitea 工单为事实来源；`docs/` 默认保存显式映射生成的核心只读镜像，`docs/task/` 是人工明确要求的专项或历史兼容快照，可能不完整或不是最新状态。
+- 长期开发文档以 Gitea Wiki 为事实来源；需要工单的任务证据以 Gitea 工单为事实来源，直接实施项以 Git 提交和结果报告留痕。`docs/` 默认保存显式映射生成的核心只读镜像，`docs/task/` 是人工明确要求的专项或历史兼容快照，可能不完整或不是最新状态。
 - 核心 Wiki 与镜像的固定顺序是：修改 Wiki → 读取确认 → 导出核心 `docs` → 校验差异 → 提交镜像。
 - 默认不创建任务归档；`archive`、`导出任务归档` 或 `导出全部任务归档` 必须由用户明确提出或项目专用规则明确要求，且不得自动传播删除或重命名。
 - 同步配置只允许写入 `docs/` 下的 Markdown；发现镜像有未提交修改时必须停止。

README.md

@@ -4,7 +4,7 @@ DevHarness 是一个以 Gitea 工单管理任务过程、以 Gitea Wiki 管理
 
 它约束的是开发过程，不限制项目使用 Python、Go、JavaScript 或其他技术栈。
 
-## 工作闭环
+## 需要工单的任务闭环
 
 ```text
 讨论需求或缺陷
@@ -18,21 +18,23 @@ DevHarness 是一个以 Gitea 工单管理任务过程、以 Gitea Wiki 管理
   -> 关闭工单并更新父工单；长期事实变化时才同步 Wiki
 ```
 
+轻量模式下符合直接实施条件的小 Bug、局部 UI 和单模块低风险调整不走上述工单闭环：确认目标 → 最小修改 → 受影响范围测试 → 提交并报告结果。
+
 ## 快速开始
 
 1. 复制或克隆本仓库，并修改仓库名称。
 2. 创建 Gitea 远端仓库并推送当前引导提交，启用工单和 Wiki。
 3. 配置 `wiki-docs.json` 和安全访问方式；优先使用已配置的 Gitea MCP，MCP 不可用时才使用 Gitea API 并记录原因。令牌只通过环境变量或 MCP 安全配置提供。
 4. 按 [新项目文档初始化](docs/07-new-project-documentation-setup.md) 查询线上 Wiki；`Home` 不存在时先创建并回读 `Home`，取得 revision 后再创建其他核心页面。
-5. 把项目不可违反的安全规则写入根目录或子项目的 `AGENTS.md`。
-6. 使用 `.gitea/issue_template/` 中的模板创建第一个 Epic、MVP 和单元任务。本地 `docs/` 的存在不能证明线上 Wiki 已初始化。
+5. 在项目档案选择治理模式；内部、单人、低风险项目优先选择轻量，并把不可违反的安全规则写入根目录或子项目的 `AGENTS.md`。
+6. 需要工单时使用 `.gitea/issue_template/` 中的模板；小型项目不要求预先创建 Epic 或 MVP。本地 `docs/` 的存在不能证明线上 Wiki 已初始化。
 7. 开始产品代码前运行：
 
    ```powershell
    python dev_scripts/harness.py sync --verify
    ```
 
-新仓库在 Gitea 尚未建立前允许一次不关联工单的引导提交。远端和工单系统配置完成后，所有改变程序行为的工作都必须先有单元任务工单。
+新仓库在 Gitea 尚未建立前允许一次不关联工单的引导提交。远端和工单系统配置完成后，按项目治理模式和任务真实风险判断是否需要工单；完整独立需求和中高风险变化必须建单。
 
 ## 目录
 
@@ -53,8 +55,8 @@ dev_scripts/wiki_docs.py          Gitea Wiki 客户端与镜像生成库
 ## 设计原则
 
 - 人决定目标、范围和验收结果，Agent 负责检查、实现和验证。
-- Gitea 工单是单次任务唯一事实来源；Wiki 保存长期有效事实，Git 保存代码和版本绑定资料，`docs/` 默认保存核心镜像。
+- 需要工单的任务以 Gitea 工单为单次任务事实来源；轻量直接实施项以 Git 提交和结果报告留痕。Wiki 保存长期有效事实，`docs/` 默认保存核心镜像。
 - 默认不创建任务归档；`archive`、`export` 和 `export --all` 只作为人工显式触发的兼容能力。
 - 一个单元工单只解决一个可独立测试和回退的问题。
 - 实现提交与必要的核心文档镜像提交分开，便于审查与追溯。
-- 凭据、个人数据和生产数据不得进入代码、工单或归档。
+- 凭据、真实个人数据和生产数据不得进入代码、工单或归档；明确虚构的测试数据无需形式化脱敏。

dev_scripts/harness.py

@@ -68,6 +68,7 @@ CORE_DOCUMENT_REQUIREMENTS = {
     ),
     "docs/00-project-profile.md": (
         "## 基本信息",
+        "## 项目治理模式",
         "## DevHarness 来源与基线",
         "## 子项目与交付单元",
         "## 技术栈与运行环境",
@@ -78,11 +79,11 @@ CORE_DOCUMENT_REQUIREMENTS = {
     "docs/01-workflow.md": (
         "## Gitea 交互与工单最小读取",
         "## 新项目 Wiki 初始化门禁",
-        "## 工单与设计证据双门禁",
+        "## 按治理模式选择最小门禁",
+        "### 不可裁剪底线",
         "### 先判断是否需要工单",
         "### 再判断设计证据",
         "### 线上原型审核与按需导出",
-        "### 记录和重新确认",
         "## 面向初级维护者的修改边界",
         "## 每个任务的文档影响",
         "## 需求记录与流转",
@@ -125,6 +126,7 @@ CORE_DOCUMENT_REQUIREMENTS = {
     ),
     "docs/07-new-project-documentation-setup.md": (
         "## 初始化顺序",
+        "#### 选择治理模式",
         "#### 需求总览启用条件",
         "### 2. 选择建设基线",
         "#### 工程基线裁剪",
@@ -330,11 +332,11 @@ def check_agent_efficiency_rules(errors: list[str], root: Path = ROOT) -> None:
         "#### 渐进执行和修复",
         "#### 复用已验证事实",
         "#### 明确停止条件",
-        "单元任务是唯一正式实施单位",
+        "需要工单时，单元任务是正式实施单位",
         "高风险修改必须停止",
         "用户没有明确验收通过前不得关闭",
         "只有长期事实变化时才修改 Wiki",
-        "Gitea 工单是单次任务需求、变化、实现、测试、提交和验收的事实来源",
+        "需要工单的任务以 Gitea 工单作为需求、变化、实现、测试、提交和验收的事实来源",
         "默认不创建任务归档",
         "### Gitea 交互与工单最小读取",
         "查询、创建、更新、评论、状态变更及关闭操作",
@@ -344,18 +346,19 @@ def check_agent_efficiency_rules(errors: list[str], root: Path = ROOT) -> None:
         "### 新项目 Wiki 初始化门禁",
         "`Home` 不存在时必须先创建 `Home`",
         "不得把模板自带的本地 `docs/` 当作新项目 Wiki 已初始化的证据",
-        "提交只包含当前工单相关文件",
+        "提交只包含当前任务相关文件",
         "不得仅为设置编码重复启动一层 PowerShell",
         "文件解码和控制台输出分别处理",
         "不得默认使用 `-ExecutionPolicy Bypass`",
-        "### 工单与设计证据双门禁",
-        "新页面、独立用户功能、重大交互或导航变化",
+        "### 按治理模式选择最小设计证据",
+        "轻量模式的小 Bug、局部样式或布局",
+        "明确为虚构的测试数据无需形式化脱敏",
+        "完整独立需求、新页面、重大交互或导航变化",
         "`prototypes/<工单号>/<版本>/index.html`",
         "默认直接通过 Quant-UX 或其他设计工具的线上链接审核",
         "已确认的本地快照不得原位覆盖",
         "`导出原型 #N`",
         "`导出全部原型`",
-        "代码组件名、类名、变量、国际化键、API 字段和数据库字段不是显示文案",
         "### 自然语言快捷指令",
         "`只分析`",
         "`建工单`",
@@ -391,7 +394,7 @@ def check_repository_readme(errors: list[str], root: Path = ROOT) -> None:
         "`Home` 不存在时先创建并回读 `Home`",
         "本地 `docs/` 的存在不能证明线上 Wiki 已初始化",
         "python dev_scripts/harness.py sync --verify",
-        "Gitea 工单是单次任务唯一事实来源",
+        "需要工单的任务以 Gitea 工单为单次任务事实来源",
         "默认不创建任务归档",
     )
     for section in missing_sections(content, required):

docs/00-project-profile.md

@@ -2,8 +2,8 @@
 generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件)
 wiki_page: Project-Profile
 wiki_url: https://git.ilapage.cn/OPC/dev_harness/wiki/Project-Profile.-
-wiki_revision: 76d42d222f6ab3aa0836cc2d036f81344049a470
-synchronized_at: 2026-08-25T00:40:26Z
+wiki_revision: 5323a382fc19433c19441587120d5a0ee6447a24
+synchronized_at: 2026-09-02T02:08:46Z
 <!-- gitea-wiki-mirror:end -->
 
 # 项目档案
@@ -23,6 +23,17 @@ synchronized_at: 2026-08-25T00:40:26Z
 | 主要维护者 | `ila` |
 | 文档适用范围 | 默认分支当前版本；具体镜像 revision 见每个本地文件头 |
 
+## 项目治理模式
+
+| 项目 | 当前值 |
+|---|---|
+| 当前治理模式 | 标准；DevHarness 模板自身的流程变更需要工单和验收 |
+| 新项目建议 | 内部、单人、低风险项目优先选择轻量模式 |
+| 选择理由 | 模板维护会影响多个项目；使用模板的新项目应按自身风险裁剪 |
+| 升级规则 | 单个任务的真实风险高于项目默认模式时，仅该任务升级到更高模式 |
+
+治理模式只裁剪工单、原型、测试和文档流程，不得取消凭据、真实个人数据、生产数据、不可逆操作和真实测试证据等安全底线。项目初始化时应把本节改成目标项目的真实选择和理由。
+
 ## DevHarness 来源与基线
 
 每个采用 DevHarness 的业务项目都必须填写本节。它记录的是所采用的 DevHarness 上游版本，不是业务项目自己的提交。不得使用“最新版本”“当前 main”等动态描述代替完整提交哈希。

docs/01-workflow.md

@@ -2,8 +2,8 @@
 generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件)
 wiki_page: Development-Workflow
 wiki_url: https://git.ilapage.cn/OPC/dev_harness/wiki/Development-Workflow.-
-wiki_revision: fb52a69363b53f3bce6d5f2bdc016aead0c19f90
-synchronized_at: 2026-09-02T01:36:08Z
+wiki_revision: 323a720e0946aa04d8c0a28f1a1bffca45313c23
+synchronized_at: 2026-09-02T02:08:49Z
 <!-- gitea-wiki-mirror:end -->
 
 # 开发工作流
@@ -37,68 +37,44 @@ synchronized_at: 2026-09-02T01:36:08Z
 
 Gitea 暂时不可用时可以准备工单和 Wiki 草稿，但不得把本地草稿宣称为线上事实，也不得绕过此门禁开始产品功能开发。
 
-## 工单与设计证据双门禁
+## 按治理模式选择最小门禁
 
-开始正式实现前依次判断“是否需要工单”和“需要什么设计证据”。原型确认不能代替方案、工单、安全检查或技术验证；工单存在也不能绕过原型确认。
+项目在 Project-Profile 选择轻量、标准或高风险模式。内部、单人、低风险项目优先使用轻量模式；单个任务风险高于项目默认模式时，只升级该任务，不抬高全部日常工作。不得为了流程完整而增加没有实际作用的工单、原型、文档或测试。
+
+### 不可裁剪底线
+
+任何治理模式都必须遵守：
+
+- 不把密码、令牌、Cookie、私钥、真实个人数据或生产数据写入代码、日志、工单、Wiki 和文档；
+- 手机号等明确为虚构的测试数据无需形式化脱敏，但必须能与真实用户数据区分；来源不明时按真实个人数据处理；
+- 发布、删除数据、破坏性迁移和其他不可逆操作必须得到明确授权；
+- 测试结果必须真实，未执行或无法覆盖的验证必须说明；
+- 任务涉及权限、安全、支付、真实个人/生产数据、迁移、并发、删除或不可逆操作时，按高风险处理并等待人工确认。
 
 ### 先判断是否需要工单
 
-只有纯界面显示文案同时满足以下全部条件时，才可以免工单、免原型：
+| 治理模式 | 可直接实施 | 必须建单 |
+|---|---|---|
+| 轻量 | 文案、注释、格式、局部样式或布局；预期行为明确的小 Bug；不改变接口、数据结构、权限和安全边界的单模块低风险调整 | 完整独立需求、新页面或跨模块功能；API、数据结构、权限、安全、迁移；范围或预期不明确的变化 |
+| 标准 | 纯文档措辞、格式化、内部标识符改名和确定不改变行为的小整理 | 新功能、缺陷修复、重构及用户可感知的行为变化 |
+| 高风险 | 只读诊断和不会改变行为的文档整理 | 任何正式行为变化；按风险补充人工确认和验证 |
 
-- 只修改用户看到的组件显示名称、按钮文字、标题、提示语或其他文案；
-- 不改变业务含义、操作流程、权限、状态、接口、数据和验收结果；
-- 不涉及法律条款、安全提示、支付、金额、单位或其他高风险含义；
-- 不修改国际化键、代码组件名、类名、变量、API 字段、数据库字段或其他程序标识符；
-- 不造成明显布局、截断、换行、可访问性或支持平台问题；
-- 有任何不确定时不使用豁免。
-
-豁免修改只执行与受影响界面相称的最小检查，确认文字正确且没有明显布局或可访问性问题，然后停止。只要任一条件不满足，或涉及用户行为、样式布局、交互和导航，就建立单元任务工单。
+直接实施项无需为了留痕补建工单，也无需填写工单模板；开始前只做必要的工作区和安全检查，完成最小测试后报告结果。无法确定是否符合直接实施条件时，先澄清或建单，不用代码行数代替风险判断。
 
 ### 再判断设计证据
 
-| 修改类型 | 最低设计证据 | 正式编码门禁 |
-|---|---|---|
-| 纯显示文案且满足全部豁免条件 | 无原型 | 完成最小界面检查即可 |
-| 现有界面的小范围样式或布局调整 | 标注截图或低保真线框图；没有设计不确定性时说明复用的现有规范 | 工单确认设计证据后编码 |
-| 新组件但复用现有设计体系 | 组件状态、错误和边界说明；按需提供低保真图 | 工单确认状态和复用边界后编码 |
-| 新页面、独立用户功能、重大交互或导航变化 | Quant-UX 或其他合适工具制作的可审阅原型 | 用户确认原型和文字需求后才能编写生产代码 |
-| 后端、接口、数据处理或定时任务 | 架构、API、数据、状态或流程设计 | 用户确认技术方案后编码，不制作无意义的 UI 原型 |
-| 恢复既有确认行为的 Bug | 原设计、已确认截图、复现步骤或现有验收证据 | 确认是恢复而不是改变行为后修复 |
-
-采用最低成本、足以让用户确认的证据，不为了形式制作高保真原型。草稿原型可以用于需求讨论；草稿需要写入 Git/Wiki、多人协作或单独实施时，应建立设计任务。草稿原型和临时技术验证都不能直接作为生产实现。
+- 轻量模式的小 Bug、局部样式或布局、复用现有规范的组件调整无需完整原型；能用一句话、现有界面或标注截图确认时即停止增加设计材料。
+- 完整独立需求、新页面、重大交互或导航变化需要工单；只有存在明显交互不确定性、用户明确要求，或返工成本显著时，才制作 Quant-UX 或其他可审阅原型。
+- 标准模式对新页面、独立用户功能和重大交互使用可审阅原型；小范围 UI 使用最低成本的文字、截图或低保真证据。
+- 高风险任务按影响补充技术设计、数据和权限边界、回退方案及人工确认；非 UI 任务不制作无意义的 UI 原型。
+- 恢复既有确认行为的 Bug 可以复用原设计、截图、复现步骤或已有验收证据。
 
 ### 线上原型审核与按需导出
 
-新页面、独立用户功能、重大交互或导航变化使用 Quant-UX 或等效工具形成待审核版本后，默认直接通过线上原型审核，不要求每次导出本地 HTML：
+需要完整原型时，默认通过 Quant-UX 或等效工具的可访问线上链接审核，记录可识别的版本和确认范围。只有用户明确发出 `导出原型 #N`、`导出全部原型`，或项目专用规则要求离线交付时，才导出到 `prototypes/<工单号>/<版本>/index.html`；不得把本地快照变成第二份可编辑事实来源。
 
-- 可编辑设计源保存在 Quant-UX 或原设计工具；工单和 Wiki 只保存链接、版本与确认记录，不复制为第二份可编辑事实来源。
-- 线上链接必须能被确认人访问，并能通过版本、revision、复制版本或确认日期识别本次审核对象；无法访问或无法区分版本时停止审核，等待用户确认等效方案。
-- 提交审核前检查主要页面、流程、状态和交互可访问，并删除令牌、真实账号、个人信息和生产数据。
-- 页面结构、主要流程、状态、权限、异常处理或验收结果变化时，更新线上原型并重新确认；不得用旧确认覆盖新版本。
-- 纯显示文案、小范围现有 UI 调整、非 UI 需求和恢复既有行为的 Bug 仍只使用双门禁表规定的最低证据，不强制建立完整线上原型。
+页面结构、主要流程、权限、状态或异常处理发生影响验收的变化时，才更新设计证据并重新确认。设计工具无法生成用户明确要求的离线 HTML 时，记录限制并等待等效方案；线上版本可访问且可识别时不阻塞线上审核。
 
-只有用户明确发出 `导出原型 #N`、`导出全部原型`，或项目专用规则明确要求离线交付时，才导出本地 HTML：
-
-- 指定工单的快照放入 `prototypes/<工单号>/<版本>/index.html`；全部导出时也按工单和版本分目录，先在工单明确导出范围。
-- 图片、样式、脚本和字体使用版本目录内的相对路径；需要网络资源才能显示时不得标记为可离线浏览。
-- 已确认的本地快照不得原位覆盖；新版本使用新目录，已有快照继续作为历史审核证据。
-- 导出后检查入口、主要交互和资源完整性；浏览器限制直接打开时，在工单记录最小本地静态服务命令和访问地址，不新增项目专用服务脚本。
-- 导出指令只生成或更新请求范围内的快照并报告结果，不自动提交；用户未明确要求时不得顺带导出其他原型。
-- 设计工具无法生成用户要求的可用 HTML 时，在工单记录限制并停止该导出或离线交付，等待用户确认等效方案；线上原型仍可访问且版本明确时，不因此阻塞线上审核。
-
-### 记录和重新确认
-
-需要设计证据的工单必须记录：
-
-- 原型或设计的线上链接、对应事实来源，以及链接可访问性；
-- 版本、revision、复制版本或确认日期，以及审核版本的识别方式；
-- 状态：无、草稿、已确认或已废弃；
-- 只有显式导出时才记录本地 HTML 路径、版本和资源检查结果；
-- 确认人和确认时间；
-- 本次确认覆盖的页面、组件、流程和边界；
-- 不需要 UI 原型时采用的技术设计，或无需任何原型的原因。
-
-页面结构、主要流程、状态、权限、异常处理或验收结果变化时，先更新原型或文字需求并重新确认，再继续正式编码。只读技术检查可以在确认前进行；确需可行性代码验证时，必须由用户明确同意，隔离为不可进入生产的技术验证，不得悄悄扩展成正式实现。
 ## 一次任务怎样完成
 
 ### 1. 讨论

docs/07-new-project-documentation-setup.md

@@ -2,8 +2,8 @@
 generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件)
 wiki_page: New-Project-Documentation-Setup
 wiki_url: https://git.ilapage.cn/OPC/dev_harness/wiki/New-Project-Documentation-Setup.-
-wiki_revision: 49985341fad6947b93c3b83ee6046dc56c1110e6
-synchronized_at: 2026-08-24T08:55:52Z
+wiki_revision: 032c2e3479f6a30812eba4af31ea264820a94ac4
+synchronized_at: 2026-09-02T02:08:51Z
 <!-- gitea-wiki-mirror:end -->
 
 # 新项目文档初始化
@@ -26,6 +26,17 @@ synchronized_at: 2026-08-24T08:55:52Z
 
 把项目专用红线写入根目录或子目录 `AGENTS.md`。
 
+#### 选择治理模式
+
+在 Project-Profile 记录轻量、标准或高风险模式及选择理由：
+
+- 内部、单人、低风险、没有真实个人/生产数据和不可逆操作的项目，优先选择轻量模式；
+- 多人协作、对外交付、跨模块接口较多或需要稳定审计时选择标准模式；
+- 涉及权限、安全、支付、真实个人/生产数据、迁移、并发、删除或不可逆操作时选择高风险模式；
+- 不确定时先选择满足当前真实风险的最低模式；后续只在风险实际增加时升级，不为可能发生的情况预设额外门禁。
+
+治理模式只裁剪工单、原型、测试和文档流程，不覆盖安全底线。使用虚构手机号等测试数据时记录其为虚构数据即可，无需为了形式执行脱敏流程；来源不明或来自真实用户时必须按真实个人数据保护。
+
 #### 需求总览启用条件
 
 从模板创建项目时保留 Product-Requirements-Overview 这一核心页面。仅有探索性想法时可以只记录已确认目标和待确认项；形成 MVP、长期需求超过少量工单或开始制作原型时，必须建立并持续维护需求索引，把需求领域、状态、主题 Wiki、工单、原型和验收入口关联起来。不要复制完整工单或聊天记录。

tests/test_harness_docs.py

@@ -76,13 +76,13 @@ class CoreDocumentTests(unittest.TestCase):
         self.assertIn("### 原型确认记录", required)
         self.assertIn("## 更新时机", required)
 
-    def test_workflow_requires_ticket_and_design_evidence_gates(self) -> None:
+    def test_workflow_requires_governance_modes_and_minimum_gates(self) -> None:
         required = CORE_DOCUMENT_REQUIREMENTS["docs/01-workflow.md"]
-        self.assertIn("## 工单与设计证据双门禁", required)
+        self.assertIn("## 按治理模式选择最小门禁", required)
+        self.assertIn("### 不可裁剪底线", required)
         self.assertIn("### 先判断是否需要工单", required)
         self.assertIn("### 再判断设计证据", required)
         self.assertIn("### 线上原型审核与按需导出", required)
-        self.assertIn("### 记录和重新确认", required)
 
     def test_workflow_requires_online_wiki_initialization_gate(self) -> None:
         workflow = CORE_DOCUMENT_REQUIREMENTS["docs/01-workflow.md"]
@@ -118,6 +118,7 @@ class CoreDocumentTests(unittest.TestCase):
 
     def test_project_profile_requires_dev_harness_baseline(self) -> None:
         required = CORE_DOCUMENT_REQUIREMENTS["docs/00-project-profile.md"]
+        self.assertIn("## 项目治理模式", required)
         self.assertIn("## DevHarness 来源与基线", required)
 
     def test_new_project_setup_requires_baseline_selection(self) -> None:
@@ -127,6 +128,7 @@ class CoreDocumentTests(unittest.TestCase):
         self.assertIn("### 2. 选择建设基线", required)
         self.assertIn("#### 判断案例", required)
         self.assertIn("### 3. 识别子项目与交付单元", required)
+        self.assertIn("#### 选择治理模式", required)
         self.assertIn("#### 需求总览启用条件", required)
 
     def test_local_development_requires_powershell_utf8_boundaries(self) -> None: