opc/dev_harness

Table of Contents

业务规则与术语

本页用途
核心术语
工单状态
稳定业务规则
新项目需要补充什么

业务规则与术语

本页用途

解释 DevHarness 中容易混淆的术语、状态和不可破坏的流程规则。新项目复制模板后，应把项目自身的业务术语、状态和关键约束补充到本页。

核心术语

术语	含义	不要误解为
Epic	完整产品目标和长期路线	可以直接实施的单个任务
MVP	第一个可交付范围及集成边界	任意里程碑名称
单元任务	唯一正式实施单位，可独立测试和回退	临时聊天待办
关键原始需求	能表达用户目的、场景和限制的少量原话或脱敏摘要	完整聊天记录
正式任务需求	用户确认后写入单元工单的目标、非目标、方案和验收标准	Agent 未确认的理解
需求变化记录	实施期间影响范围或验收的变化、原因及用户确认	每一句普通讨论
事实来源	某类信息被正式维护的位置	多处内容可以随意覆盖
Wiki 主源	长期开发文档首先修改的位置	本地 docs 的备份副本
docs 镜像	从 Wiki 单向生成的浏览副本	可以直接编辑并反向同步的文档
待验收	实现和测试已完成，等待用户确认	已完成并可关闭
未验证部分	本次无法真实覆盖的行为	可以省略的测试备注

工单状态

状态	含义	可以进入下一状态的条件
待确认	目标或方案仍需用户选择	用户明确确认方案
待实施	方案已确认但尚未修改，或真实前置依赖尚未满足	前置依赖已满足或明确允许并行，且工作区和范围检查完成
进行中	正在实现、测试或同步文档	验收标准逐项检查完成
阻塞	实施过程中出现计划外、当前无法解除的问题	阻塞解除并更新工单
待验收	代码、测试、归档和证据已完成	用户明确验收
已完成	用户已验收并完成父任务同步	无

稳定业务规则

没有确认方案和单元任务工单，不修改产品行为。
一个单元任务只解决一个可独立验证和回退的问题。
建立后续工单不要求已有工单全部完成；实施前必须检查工单声明的前置依赖。
前置工单未完成且存在实际依赖时保持“待实施”；允许并行时必须写明原因。
需求、接口、数据、安全边界或验收标准变化时先更新工单。
工单只保存关键原始需求、确认后的正式需求和重要变化，不保存完整聊天或 Agent 内部推理。
长期有效的产品需求和业务规则进入 Wiki；Gitea 工单全文不导出到本地。
长期文档必须先修改 Wiki，再导出本地镜像。
测试结果必须真实；未执行的验证必须明确记录。
用户未明确验收前，工单保持开启。
初级程序员可以理解和验证低风险修改，但高风险决策仍由 Agent 分析并等待人工确认。

新项目需要补充什么

复制模板后，至少补充：

项目的用户和核心目标；
业务名词及容易混淆的概念；
主要对象和状态；
关键状态流转；
必须始终满足的业务规则；
数据保留、权限和安全边界；
典型输入、输出和失败示例。

业务规则必须由项目负责人确认，Agent 可以整理和举例，但不能根据代码自行臆造。