--- name: workflow-core description: 定义设计与实现一致性流程的设计文件优先级、内部关系、证据规则、标准交接、质量门禁职责和最终输出要求。 metadata: version: 1.1.17 --- # 核心工作流 > **领导速读：** 定义整套齐衡如何认定权威设计、记录语义关系、治理修改并计算最终结论。 ## 一、管理视角 - **何时使用：** 需要理解或执行齐衡底层一致性机制时。 - **主要输入：** 设计文件、项目信息、检查状态记录、操作记录、验证结果和证据。 - **主要输出：** 统一事实源、角色边界、证据规则和终态产物要求。 - **职责边界：** 说明文字只是视图，不能覆盖结构化事实。 ## 二、执行方法 使用本技能理解套件级工作机制。 ### 基本原则 - 设计文件优先于当前实现。 - 公开测试只是示例，不是完整契约。 - 每项修复都必须对应设计文件中有明确依据的设计要求。 - 子智能体只有产出被下游消费的证据时才有价值。 - 最终成功必须具备验证证据、残余风险分类和终态产物。 - `reports/ontology-snapshot.json` 是对象、关系、生命周期和来源的语义事实源。 - 报告只能汇总本体；说明文字不得静默创建或覆盖语义事实。 ### 本体运行模型 - `profile-builder` 识别仓库结构、设计文件目录、直接相关基线和按相关度排序的相关文件。 - `spec-reader`、`semantic-conflict-auditor` 和 `contract-oracle` 建立有来源依据、已处理冲突的需求与场景。 - `spec-quality-reviewer` 与 `architecture-reviewer` 分别检查规格和架构质量；`contract-oracle` 只负责确认设计要求。 - `impact-analyst` 在实现前、漂移或修复后确定失效决定与最小安全重跑计划。 - `impl-inspector` 通过 `ObserveImplementation` 记录既有代码，或创建缺口。 - `repair-planner` 提议带类型的 `RepairAction` 对象。 - `code-repairer` 只执行已批准且路径受限的动作。 - `validation-runner` 附加 `Validation` 与 `Evidence`。 - `code-quality-reviewer` 和 `test-quality-reviewer` 分别裁决实现质量与测试质量；`validation-runner` 只执行验证并记录事实。 - `adversarial-challenger` 针对高风险声明记录可证伪 `Challenge` 与可复现 `Counterexample`。 - `evidence-auditor` 核验 `Claim` 是否当前有效，并与冻结 `Candidate` 的持久证据连接。 - `final-reviewer` 根据不变量计算 `PASS`，不依据角色信心。 - `ci-gatekeeper` 判断持续集成检查集合是否充分；`repository-gatekeeper` 在一致性签署后独立作出仓库准入决定。 ### 质量评审边界 - `workflow-harness` 冻结候选版本，拥有可执行门禁图、依赖状态、证据哈希和最终完整性检查。 - `quality-review-orchestrator` 管理从规格导入到提交前准入、与候选版本绑定的门禁图。 - 规格及适用的系统/架构门禁在实现前清理设计基线。 - `quality-ci-gate` 在实现前规划必要检查，并在提交前边界核验证据。 - 代码和开发者测试门禁由风险变化触发，可随实现或测试变化重复运行。 - 实现后，设计实现一致性闭环持续检查和修复，直至收敛或阻断。 - 修复只使依赖决定失效；仅重跑受影响门禁。 - `quality-consistency-gate` 在证据审计后签署设计实现一致性终态。 - `quality-repository-gate` 仅在执行框架返回 `READY_FOR_ADMISSION` 后运行；记录准入决定后，完整检查必须返回 `READY`。 质量技能是条件门禁，不是装饰阶段。记录每项专业评审为何适用或为何跳过。复用本体对象、哈希、命令和 `Evidence`，不得创建平行事实源。将适用评审决定保存在 `reports/quality/`，包含候选版本身份和证据引用，供后续门禁消费真实发现。 每个主责角色都输出 `dic.agent-handoff.v1`；门禁计划通过 `agent`、`contributors` 与 `requiredHandoffs` 区分裁决责任、协作责任和强制交接。 设计实现一致性、专业质量和仓库准入是三项独立结果。设计实现一致性 `PASS` 只证明当前实现与设计证据一致，既不证明所有质量领域通过，也不授予准入。编排角色保留三项结果并派生交付决定。 ### 可审计动作 使用 `schemas/ontology-action.schema.json` 描述可审计变更。每个动作记录执行者、目标、前置条件、后置条件、允许路径和证据；创建动作时设置 `expectedSnapshotRevision`。 捆绑命令行可用时，执行前运行 `action-check`，动作达到记录状态后运行 `action-record`。不得以不同内容复用动作标识。 每个已完成动作都包含 `parameters.ontologyPatch`，只使用该动作类型允许的对象、关系和生命周期效果。记录后执行 `ontology-reconcile`，不得直接修改快照。协调过程必须幂等并保持全部结构不变量。 每条新记录都要先协调，再记录下一动作。新账本条目形成带序号的哈希链，并绑定记录时使用的快照修订；终态评审前执行 `ontology-ledger-check`。 ### 验证与证据 只有生命周期当前且 `properties.status` 为 `PASS` 时，验证才算成功。每个 `Validation` 记录 `executedAt`，并在 `inputs` 中保存每个已消费 `DesignSource` 和 `ImplementationUnit` 的对象标识及当前 SHA-256。执行 `ontology-validation-check`；旧测试结果不得批准新的设计或实现字节。 每个必要 `Evidence` 对象必须关联真实的项目相对产物，并带 `provenance.contentHash` 和 `ContentAddressed` 接口。签署前执行 `ontology-evidence-check`。 仅当 `ImplementationUnit` 生命周期当前、项目相对文件真实存在且 SHA-256 与来源信息一致时，实现才算当前有效。既有代码使用 `ObserveImplementation`；只有已批准修复创建或修改的代码使用 `ApplyRepair`。签署前执行 `ontology-implementation-check`。 ### 终态完整性 将 `snapshotRevision` 视为完整性边界。终态评审前执行 `ontology-drift`；受跟踪来源变化会阻断 `PASS`。使用 `ontology-plan` 把设计、实现和证据完整性问题转换为最小建议角色阶段重跑。 最终文字只是供人阅读的报告，不能替代底层记录。通过 `ontology-report` 生成 `reports/ontology-report.md`，通过 `ontology-attest` 创建最终证明文件 `reports/ontology-attestation.json`，发布结果前立即执行 `ontology-attestation-check`。该文件把最终状态与准确的检查状态版本、操作记录哈希、设计文件哈希、证据文件哈希、实现文件哈希、已检查规则和验证输入清单绑定。 把最终证明文件的 `contentHash` 保存到证据目录之外，再通过 `--expected-hash` 核验。 围绕内容寻址的 `Candidate` 建模每项交付决定。专业执行记录为由 `EVALUATES` 关联的 `GateRun`，终态 `Decision` 通过 `DECIDES` 绑定。有效声明需要 `SUPPORTED_BY` 证据；未解决 `Challenge` 阻断 `PASS`。使用 `Policy`、`Waiver` 和 `Risk` 显式表达治理例外，不得隐藏在说明文字中。 ### 必要持久化产物 ```text reports/project-profile.json reports/harness-plan.json reports/harness-run.json reports/harness-report.md reports/ontology-snapshot.json reports/ontology-actions.jsonl reports/ontology-report.md reports/ontology-attestation.json reports/final-consistency-report.md reports/FINAL_RESULT.json result/output.md logs/trace/ ``` 不得硬编码本地路径、Shell 语法或单一项目结构。