diff --git a/docs/01-workflow.md b/docs/01-workflow.md index 13de68e..49e8323 100644 --- a/docs/01-workflow.md +++ b/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: 323a720e0946aa04d8c0a28f1a1bffca45313c23 -synchronized_at: 2026-09-02T02:08:49Z +wiki_revision: b82dc79b2d74b83c4e255600beceb7c1e292c9a4 +synchronized_at: 2026-09-02T02:13:59Z # 开发工作流 @@ -299,11 +299,11 @@ python dev_scripts/harness.py export --all # 全量导出已有归档 - `同步文档` 或任务归档导出发现目标镜像有未提交改动时停止，不覆盖现有修改。 - `导出原型 #N` 和 `导出全部原型` 必须由用户明确提出或项目专用规则明确要求；其他指令不隐式导出原型。 - `导出任务归档` 和 `导出全部任务归档` 必须由用户明确提出，其他快捷指令不隐式执行。 -- Gitea 工单是单次任务唯一事实来源，不导出全文；`docs/task/` 只保存人工明确要求的专项或历史兼容快照。 +- 需要工单的任务以 Gitea 工单为单次任务事实来源，不导出全文；符合轻量模式直接实施条件的任务以用户确认范围、Git 提交和结果报告留痕，不补建工单。`docs/task/` 只保存人工明确要求的专项或历史兼容快照。 ## 什么时候重新确认方案 -以下变化必须先更新工单，再由用户确认： +以下变化必须重新确认；已有工单时先更新工单，直接实施项遇到这些变化时不再符合豁免，先建单再继续： - 交付结果或用户操作发生变化； - 增加或删除接口、数据库字段或迁移； diff --git a/docs/03-business-rules-and-glossary.md b/docs/03-business-rules-and-glossary.md index 9dee4b7..81e2d17 100644 --- a/docs/03-business-rules-and-glossary.md +++ b/docs/03-business-rules-and-glossary.md @@ -2,8 +2,8 @@ generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件) wiki_page: Business-Rules-and-Glossary wiki_url: https://git.ilapage.cn/OPC/dev_harness/wiki/Business-Rules-and-Glossary.- -wiki_revision: f94f1f8020f1059aff2d69e1ca86e048f47c8f9b -synchronized_at: 2026-08-25T00:40:33Z +wiki_revision: 0f860d9e97c0cdc7d2253a3f013d24fd8bd02609 +synchronized_at: 2026-09-02T02:14:01Z # 业务规则与术语 @@ -18,7 +18,9 @@ synchronized_at: 2026-08-25T00:40:33Z |---|---|---| | Epic | 完整产品目标和长期路线 | 可以直接实施的单个任务 | | MVP | 第一个可交付范围及集成边界 | 任意里程碑名称 | -| 单元任务 | 唯一正式实施单位，可独立测试和回退 | 临时聊天待办 | +| 治理模式 | 项目采用的轻量、标准或高风险流程级别 | 可以覆盖安全底线的开关 | +| 直接实施项 | 轻量模式允许不建单的小范围低风险修改 | 可以扩展为完整需求或高风险修改 | +| 单元任务 | 需要工单时的正式实施单位，可独立测试和回退 | 所有小修改都必须创建的流程记录 | | 关键原始需求 | 能表达用户目的、场景和限制的少量原话或脱敏摘要 | 完整聊天记录 | | 正式任务需求 | 用户确认后写入单元工单的目标、非目标、方案和验收标准 | Agent 未确认的理解 | | 需求变化记录 | 实施期间影响范围或验收的变化、原因及用户确认 | 每一句普通讨论 | diff --git a/docs/07-new-project-documentation-setup.md b/docs/07-new-project-documentation-setup.md index fa5454d..0410487 100644 --- a/docs/07-new-project-documentation-setup.md +++ b/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: 032c2e3479f6a30812eba4af31ea264820a94ac4 -synchronized_at: 2026-09-02T02:08:51Z +wiki_revision: e35a6ef160d21ddfeb043860d85fc8074bcc26fa +synchronized_at: 2026-09-02T02:14:04Z # 新项目文档初始化 @@ -129,7 +129,7 @@ synchronized_at: 2026-09-02T02:08:51Z 创建远端仓库并完成允许的初始引导提交，开启工单和 Wiki；必须先有远端仓库，才能填写该仓库的线上 Wiki。配置项目已有的 Gitea MCP 和安全凭据；优先使用 MCP，MCP 不可用或不支持所需写操作时才回退到 Gitea API，并在初始化工单记录原因。凭据只通过环境或 MCP 安全配置提供。 -任何产品功能开发在引导提交后都必须先有单元任务工单，并且必须通过第 8 步的线上 Wiki 初始化门禁。 +引导提交后按已选治理模式判断是否需要工单：轻量模式的明确小 Bug、局部 UI 和单模块低风险调整可以直接实施；完整独立需求、新页面、跨模块功能和中高风险变化必须先有单元任务工单。开始产品代码前仍须通过第 8 步的线上 Wiki 初始化门禁。 ### 5. 修改镜像配置 diff --git a/docs/09-product-requirements-overview.md b/docs/09-product-requirements-overview.md index e98760d..f7d741d 100644 --- a/docs/09-product-requirements-overview.md +++ b/docs/09-product-requirements-overview.md @@ -2,8 +2,8 @@ generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件) wiki_page: Product-Requirements-Overview wiki_url: https://git.ilapage.cn/OPC/dev_harness/wiki/Product-Requirements-Overview.- -wiki_revision: 591f550c3a23da2bf2a4a1d53ea6208417137961 -synchronized_at: 2026-08-26T08:11:18Z +wiki_revision: 60a169e4e8e3c396c4c4c35544be48a17548d19c +synchronized_at: 2026-09-02T02:14:07Z # 产品需求总览 @@ -62,22 +62,21 @@ synchronized_at: 2026-08-26T08:11:18Z 先选择最低成本、足以确认需求的设计证据： -| 修改类型 | 是否建单 | 原型或替代证据 | +| 修改类型 | 轻量模式 | 最低设计证据 | |---|---|---| -| 纯界面显示文案，且不改变语义、流程、权限、状态、接口、高风险文字、国际化键、程序标识符、布局或可访问性 | 否 | 无原型，只做最小界面检查 | -| 现有界面的小范围样式或布局调整 | 是 | 标注截图、低保真图或明确复用的现有规范 | -| 新组件但沿用现有设计体系 | 是 | 组件状态和边界说明，按需提供低保真图 | -| 新页面、独立用户功能、重大交互或导航变化 | 是 | Quant-UX 或其他工具制作并经用户确认的可审阅原型 | -| 后端、接口、数据或定时任务 | 是 | 架构、API、数据、状态或流程设计，不强制 UI 原型 | -| 恢复既有确认行为的 Bug | 是 | 原设计、截图、复现步骤或已有验收证据 | +| 文案、局部样式或布局、复用现有规范的组件调整 | 可直接实施 | 现有界面、一句话或按需标注截图；不制作完整原型 | +| 预期行为明确的小 Bug | 可直接实施 | 复现步骤、原设计或已有验收证据 | +| 不改变接口、数据结构、权限和安全边界的单模块低风险调整 | 可直接实施 | 明确目标和最小验证方法 | +| 完整独立需求、新页面或跨模块功能 | 建单 | 先用文字确认；有明显交互不确定性、返工成本显著或用户要求时才制作可审阅原型 | +| API、数据结构、权限、安全、迁移或其他中高风险任务 | 建单并按风险升级 | 必要的架构、数据、权限、状态、回退或验证设计；不强制无意义的 UI 原型 | -“文字豁免”只指用户看到的显示文案，不包括代码组件名、类名、变量、API 字段、数据库字段或国际化键。任何条件不明确时都要建单。 +标准模式对新功能、缺陷修复、重构和用户可感知行为变化建单；新页面、独立用户功能和重大交互使用可审阅原型。高风险模式的正式行为变化必须建单并等待人工确认。 -新增页面、独立用户功能、重大交互或导航变化的顺序固定为：确认文字需求 → 制作可审阅原型 → 用户确认原型和覆盖范围 → 建立或放行实现工单 → 编写生产代码。原型发生影响页面结构、主要流程、状态、权限、异常处理或验收结果的变化时，必须重新确认。 +原型只在足以降低真实不确定性时建立。已确认设计发生影响页面结构、主要流程、状态、权限、异常处理或验收结果的变化时才重新确认；轻量直接实施项一旦扩展为完整需求或中高风险变化，先建单再继续。 ### 线上原型与按需 HTML 快照 -需要完整原型门禁的新页面、独立用户功能、重大交互或导航变化，默认直接通过 Quant-UX 或等效设计工具的线上版本审核。可编辑设计源仍以原设计工具为准，工单记录可访问链接、版本/revision、复制版本或确认日期、审核版本识别方式、确认人、确认时间和覆盖范围。 +需要完整原型的新页面、独立用户功能、重大交互或导航变化，默认直接通过 Quant-UX 或等效设计工具的线上版本审核。可编辑设计源仍以原设计工具为准，工单记录可访问链接、版本/revision、复制版本或确认日期、审核版本识别方式、确认人、确认时间和覆盖范围。 线上链接无法访问或无法区分审核版本时停止审核，等待用户确认等效方案；不能为了节省时间把不稳定链接直接当作已确认原型。页面结构、流程、状态、权限、异常处理或验收结果变化时更新线上版本并重新确认。 diff --git a/tests/test_harness_docs.py b/tests/test_harness_docs.py index 6b38ff1..cdf9efb 100644 --- a/tests/test_harness_docs.py +++ b/tests/test_harness_docs.py @@ -121,6 +121,23 @@ class CoreDocumentTests(unittest.TestCase): self.assertIn("## 项目治理模式", required) self.assertIn("## DevHarness 来源与基线", required) + def test_lightweight_governance_keeps_only_real_safety_boundaries(self) -> None: + workflow = (ROOT / "docs/01-workflow.md").read_text(encoding="utf-8") + setup = (ROOT / "docs/07-new-project-documentation-setup.md").read_text( + encoding="utf-8" + ) + requirements = ( + ROOT / "docs/09-product-requirements-overview.md" + ).read_text(encoding="utf-8") + self.assertIn("预期行为明确的小 Bug", workflow) + self.assertIn("无需为了留痕补建工单", workflow) + self.assertIn("明确为虚构的测试数据无需形式化脱敏", workflow) + self.assertIn("内部、单人、低风险", setup) + self.assertIn("不为可能发生的情况预设额外门禁", setup) + self.assertIn("局部样式或布局", requirements) + self.assertIn("可直接实施", requirements) + self.assertIn("真实个人/生产数据", setup) + def test_new_project_setup_requires_baseline_selection(self) -> None: required = CORE_DOCUMENT_REQUIREMENTS[ "docs/07-new-project-documentation-setup.md"