ub-governance

UB 治理

概述

在采用此技能的当前代码库或项目中，将此技能用作治理负责人。

对于由工作流支持的日常工作，此技能应保持精简；只有在所选模式或范围确有需要时，才启用更严格的控制。

内嵌契约

这些规则是此技能的基础契约，正确应用时不得依赖任何辅助文档。

1. 默认使用 lean 配置，除非用户明确要求使用 advanced 并说明理由。
2. 仅使用以下治理门禁状态：pass、fail、blocked。
3. 每项有明确范围的例外都必须包含 owner、rationale、created_at、 expires_at 和 follow_up。
4. 对于由工作流支持的普通 Level 1 工作，将工作流产物视为默认的持久化运营记录。
5. 仅当决策的影响超出单个计划、涉及整个代码库、风险较高，或明确受 Level 2 治理时，才升级到 ADR 和声明管理机制。
6. 将阻断性治理决策与确定性产物关联起来。

运行模式

1. repository mode：代码库卫生、CI 和发布治理、分支或规则集策略、确定性工具
2. testing mode：以行为优先的 TDD 治理和低信号测试反模式审查
3. evidence mode：证据生命周期、ADR 对齐、声明验证和门禁就绪情况
4. core-contract mode：共享配置、门禁、例外和报告语义
5. full governance audit mode：按一个确定性顺序运行代码库、测试和证据检查

测试信号模型

常规指导中使用描述性名称。 将数字 ID 保留为工具和兼容性所需的稳定内部代码。

阻断信号：

1. Type Redundancy (TG001)：运行时测试重述类型系统保证
2. Interaction Without Outcome (TG002)：断言交互，却没有断言可观察结果
3. Pass-Through Test (TG003)：针对简单 getter 或 setter 直通行为的测试
4. Happy-Path-Only Suite (TG004)：反复关注成功路径，却不体现边界或错误情况

仅警告信号：

1. Internal-Detail Bias (TG005)：可能优先验证内部细节，而非公开行为

功能真实性信号采用按风险分级的指导，而非自动新增门禁：

1. Local Source Mocking (TG006)：测试替换了参与待审查行为的本地应用源码
2. Uncontracted Test Double (TG007)：模拟对象、桩、伪实现、测试夹具或路由拦截没有明显的边界理由或契约证据
3. Mock-Dominant Test (TG008)：测试大部分内容是替身设置或调用断言，而非可观察结果
4. Missing Functional Guard (TG009)：存在风险的行为缺少面向公开接口的功能、集成、契约、组件或 E2E 检查
5. Mutation Survivor on Changed Logic (TG010)：当变异测试证据已纳入范围时，变更的关键逻辑存在尚未审查的存活变异体
6. Snapshot/Coverage-Only Proof (TG011)：行为变更仅依赖快照、渲染冒烟测试、覆盖率或“不抛出异常”的证明

按触发条件加载参考资料

严格按以下加载层级执行。 如果某个触发条件未激活，即使参考资料存在，也不要读取。

• [phase:decision-boundary] 在判断工作流产物是否充分，或是否需要升级至 ADR 和声明时，读取 references/decision-memory-and-claims.md。
• [phase:testing-mode] 在审查测试策略或应用测试反模式模型时，读取 references/testing-policy-and-signals.md。
• [phase:testing-mode] 当任务涉及 TDD 执行顺序、优先回归测试的缺陷修复或测试工作流规范时，读取 references/execution-playbook.md。
• [phase:command-or-audit] 用户询问如何运行检查，或正在执行审计路径时，读取 references/governance-commands.md。
• [edge:glossary-or-normalization] 仅在需要词汇表帮助或措辞规范化时，读取 references/vocabulary.md。
• [edge:repository-mode] 仅在实际涉及仓库治理时，读取 references/repository-baseline.md、 references/github-implementation-playbook.md 和 references/release-please-playbook.md。
• [edge:evidence-level-2] 仅在明确启用 Level 2 或重证据治理时，读取 references/evidence-baseline.md、references/evidence-lifecycle.md、references/evidence-artifact-taxonomy.md、 references/ci-artifact-contract.md 和 references/stack-baseline.md。
• [edge:schema-or-data] 仅在编写或验证这些具体产物时，读取 references/high-risk-paths.yaml、 references/agent-validation-record.schema.json、 references/adr-registry.schema.json、 references/claim-register.schema.json 和 references/adr-template-madr.md。
• [edge:authoring-conventions] 仅在调整路由或共享编写结构时，读取 ../ub-authoring/references/authoring-conventions.md。

核心工作流

1. 根据仓库事实，识别请求的治理模式和评估范围。
2. 选择配置：默认使用 lean，只有在有明确理由时才使用 advanced。
3. 对常规的工作流支撑任务，优先采用 Level 1 快速路径，并将持久记录保存在工作流产物中。
4. 仅在决策范围、风险或明确的治理运行要求时升级。
5. 运行所选模式的控制项，并确保输出具有确定性。
6. 仅通过规范的例外约定应用有界例外。
7. 输出可追溯的关卡结果，并附上产物路径。

快速示例

1. 这个身份验证变更需要 ADR 或声明工作吗？ 使用 evidence mode 和决策边界参考资料，判断常规工作流产物是否充分，或者该变更是否确实影响整个仓库、风险较高或属于 Level 2。
2. 这些测试是否主要检查 mock 调用，却没有断言用户可见的结果？ 使用 testing mode，应用测试信号模型；只有当测试套件断言交互，却未验证外部可观察结果时，才将可能的 TG002 问题视为阻塞项。
3. 请展示宿主仓库对 README、AGENTS 和技能架构的维护检查。 不要通过治理流程处理。这些检查属于宿主仓库自身的维护／检查范围。

不适用场景

• 不要将此技能用于工作流需求接收、PRD 梳理、路线图生成、冲刺准备或可恢复的计划编排；这些任务应交由 ub-workflow 处理。
• 如果任务涉及代码变更，而非治理策略或关卡语义，不要将此技能作为框架特定实现指导的主要入口。
• 如果任务实际归 ub-quality 负责，不要将此技能用作通用的文档规范化层。

模式工作流

仓库模式

1. 验证仓库基线产物和确定性工具策略
2. 验证 CI、权限和合并关卡控制项
3. 使用 Conventional Commits 和 release-please 验证发布策略

测试模式

1. 检测技术栈和测试运行器
2. 将已报告的缺陷视为回归优先事项，先处理再接受代码修复
3. 将 TG001 至 TG004 设为阻断项，将 TG005 仅设为警告项
4. 将 TG006 至 TG011 作为功能真实性指导，仅在风险、证据等级或明确的门禁范围有此要求时升级处理
5. 对行为变更工作，要求遵循行为优先的 TDD 流程
6. 保持测试指导清晰易读、关注边界且具有确定性，不要将建议性指导变成新门禁

证据模式

1. 对 changeType、evidenceLevel 和 profile 进行分类
2. 在范围要求时检测高风险路径影响
3. 选择与决策范围相符的最轻量且持久的记录
4. 对于普通的 Level 1 工作，将由工作流支持的计划产物作为默认操作记录
5. 仅在涉及 Level 2、仓库范围内的持久决策或明确的高风险治理时，升级至 ADR 对齐
6. 仅当阻断理由依赖声明时，要求验证声明登记表
7. 验证所选路径所需的产物及其时效性

核心契约模式

1. 应用规范的配置文件、门禁、例外和报告语义
2. 规范状态用语和报告契约的用法
3. 拒绝重复或相互冲突的架构定义

全面治理审计模式

1. 执行 repository mode
2. 执行 testing mode
3. 执行 evidence mode
4. 将输出整合到规范的报告章节中

规则

• 保持默认设置精简，并明确启用高级控制。
• 不要暗示仓库 ADR 机制是普通 Level 1 工作流支持工作所默认采用的记录方式。
• 例外元数据必须范围有限、明确且有时限。
• 当主技能已内嵌简短规则时，不要在多个文件中重复定义规范契约。
• 仓库维护工具不等同于精简治理指导。

输出要求

生成非简单的治理输出时，包含：

1. environment_note
2. scope_note
3. decision_note
4. gate_note
5. exception_note
6. validation_note

适用时添加特定模式的章节：

1. 测试模式使用 quality_gate_note
2. 证据模式使用 evidence_inventory 和 claim_note

完成检查清单

• 明确选择的模式。
• 明确选择的配置文件（lean 或 advanced）。
• 明确说明普通 Level 1 快速路径与 Level 2 升级路径。
• 必需的确定性产物已提供，或明确标记为缺失。
• 门禁结果可追溯且可复现。
• 例外使用规范字段，并保持范围有限。
• 治理指导保持自包含且内部一致。