ub-governance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UB Governance

Overview

概述

Use this skill as the owner for governance in the current repository or project where it is adopted.

This skill should stay lean for ordinary workflow-backed work and should only activate heavier controls when the selected mode or scope actually requires them.

在当前仓库或已采用该治理的项目中，将此 skill 作为治理的归属方。

对于普通的工作流支撑型工作，此 skill 应保持精简，只有在所选模式或范围确实需要时，才启用更重的控制措施。

Embedded Contract

内嵌契约

These rules are the base contract of this skill and must not depend on a secondary document to be applied correctly.

Default to the
```
lean
```
profile unless the user explicitly requests
```
advanced
```
with rationale.
Use only these governance gate states:
```
pass
```
,
```
fail
```
,
```
blocked
```
.
Every bounded exception must include
```
owner
```
,
```
rationale
```
,
```
created_at
```
,
```
expires_at
```
, and
```
follow_up
```
.
For ordinary Level 1 workflow-backed work, treat workflow artifacts as the default durable operational record.
Escalate to ADR and claim machinery only when the decision is durable beyond one initiative, repository-wide, high-risk, or explicitly governed at Level 2.
Keep blocking governance decisions tied to deterministic artifacts.

以下规则是本 skill 的基础契约，必须能够脱离次级文档而正确应用。

除非用户明确要求并给出理由，否则默认使用
```
lean
```
档位。
仅使用以下治理 gate 状态：
```
pass
```
、
```
fail
```
、
```
blocked
```
。
每个有界异常都必须包含
```
owner
```
、
```
rationale
```
、
```
created_at
```
、
```
expires_at
```
和
```
follow_up
```
。
对于普通的 Level 1 工作流支撑型工作，将工作流制品视为默认的持久化操作记录。
仅当决策的持久性超出一个 initiative、影响全仓库、属高风险，或在 Level 2 中被明确治理时，才升级到 ADR 与 claim 机制。
将阻断型治理决策与确定性制品绑定。

Operating Modes

运行模式

```
repository mode
```
: repository hygiene, CI and release governance, branch or ruleset policy, deterministic tooling
```
testing mode
```
: behavior-first TDD governance and low-signal testing anti-pattern review
```
evidence mode
```
: evidence lifecycle, ADR alignment, claim verification, and gate readiness
```
core-contract mode
```
: shared profile, gate, exception, and report semantics
```
full governance audit mode
```
: run repository, testing, and evidence checks in one deterministic sequence

```
repository mode
```
：仓库整洁度、CI 与发布治理、分支或 ruleset 策略、确定性工具链
```
testing mode
```
：行为优先的 TDD 治理与低信号测试反模式审查
```
evidence mode
```
：证据生命周期、ADR 对齐、claim 校验与 gate 就绪度
```
core-contract mode
```
：共享的档位、gate、异常与报告语义
```
full governance audit mode
```
：在一个确定性序列中执行仓库、测试与证据检查

Testing Signal Model

测试信号模型

Use descriptive names in normal guidance. Keep the numeric IDs as stable internal codes for tooling and compatibility.

Blocking signals:

```
Type Redundancy
```
(
```
TG001
```
): runtime tests that restate type-system guarantees
```
Interaction Without Outcome
```
(
```
TG002
```
): interaction assertions without observable outcome assertions
```
Pass-Through Test
```
(
```
TG003
```
): trivial getter or setter pass-through tests
```
Happy-Path-Only Suite
```
(
```
TG004
```
): repeated happy-path focus without boundary or error representation

Warning-only signal:

```
Internal-Detail Bias
```
(
```
TG005
```
): probable verification of internal details over public behavior

Functional-realism signals use risk-scaled guidance rather than automatic new gates:

```
Local Source Mocking
```
(
```
TG006
```
): a test replaces local application source involved in the behavior under review
```
Uncontracted Test Double
```
(
```
TG007
```
): a mock, stub, fake, fixture, or route intercept has no visible boundary reason or contract evidence
```
Mock-Dominant Test
```
(
```
TG008
```
): the test is mostly double setup or call assertions instead of observable outcomes
```
Missing Functional Guard
```
(
```
TG009
```
): risky behavior lacks a public-surface functional, integration, contract, component, or E2E check
```
Mutation Survivor on Changed Logic
```
(
```
TG010
```
): changed critical logic has unreviewed surviving mutants when mutation evidence is already in scope
```
Snapshot/Coverage-Only Proof
```
(
```
TG011
```
): behavior change relies only on snapshots, render smoke, coverage, or does-not-throw proof

在常规指引中使用描述性名称。保留数字 ID 作为工具与兼容性使用的稳定内部编码。

阻断型信号：

```
Type Redundancy
```
（
```
TG001
```
）：重复陈述类型系统保证的运行时测试
```
Interaction Without Outcome
```
（
```
TG002
```
）：只有交互断言而没有可观测结果断言
```
Pass-Through Test
```
（
```
TG003
```
）：平凡的 getter 或 setter 直通测试
```
Happy-Path-Only Suite
```
（
```
TG004
```
）：反复只关注 happy path，缺少边界或错误场景表达

仅告警信号：

```
Internal-Detail Bias
```
（
```
TG005
```
）：可能过度验证内部细节而忽视公开行为

功能真实性信号采用风险分级的指引，而非自动新增 gate：

```
Local Source Mocking
```
（
```
TG006
```
）：测试替换了所审查行为涉及的本应用源码
```
Uncontracted Test Double
```
（
```
TG007
```
）：mock、stub、fake、fixture 或路由拦截没有可见的边界理由或契约证据
```
Mock-Dominant Test
```
（
```
TG008
```
）：测试主要由 double 设置或调用断言构成，而不是可观测结果
```
Missing Functional Guard
```
（
```
TG009
```
）：高风险行为缺少面向公开表面的功能、集成、契约、组件或 E2E 检查
```
Mutation Survivor on Changed Logic
```
（
```
TG010
```
）：在变异证据已在范围内的情况下，变更的关键逻辑仍存在未经审查的存活变异体
```
Snapshot/Coverage-Only Proof
```
（
```
TG011
```
）：行为变更仅依赖快照、渲染冒烟、覆盖率或不抛异常证明

Load References By Trigger

按触发条件加载引用

Use these load tiers literally. If a trigger is not active, do not read the reference just because it exists.

```
[phase:decision-boundary]
```
Read
```
references/decision-memory-and-claims.md
```
when deciding whether workflow artifacts are sufficient or ADR and claim escalation is required.
```
[phase:testing-mode]
```
Read
```
references/testing-policy-and-signals.md
```
when reviewing testing policy or applying the testing anti-pattern model.
```
[phase:testing-mode]
```
Read
```
references/execution-playbook.md
```
when the task is about TDD execution order, regression-first bug fixing, or testing workflow hygiene.
```
[phase:command-or-audit]
```
Read
```
references/governance-commands.md
```
when the user asks how to run checks or an audit path is being executed.
```
[edge:glossary-or-normalization]
```
Read
```
references/vocabulary.md
```
only when glossary help or wording normalization matters.

[edge:repository-mode]

Read

references/repository-baseline.md

references/github-implementation-playbook.md

, and

references/release-please-playbook.md

only when repository governance is actually in scope.

[edge:evidence-level-2]

Read

references/evidence-baseline.md

references/evidence-lifecycle.md

references/evidence-artifact-taxonomy.md

references/ci-artifact-contract.md

, and

references/stack-baseline.md

only when explicit Level 2 or evidence-heavy governance is active.

[edge:schema-or-data]

Read

references/high-risk-paths.yaml

references/agent-validation-record.schema.json

references/adr-registry.schema.json

references/claim-register.schema.json

, and

references/adr-template-madr.md

only when those concrete artifacts are being authored or validated.

[edge:authoring-conventions]

Read

../ub-authoring/references/authoring-conventions.md

only when adjusting routing or shared authoring structure.

严格按以下加载层级执行。若某触发条件未激活，不要仅因为引用存在就读取它。

```
[phase:decision-boundary]
```
在判断工作流制品是否充分、或是否需要 ADR 与 claim 升级时，读取
```
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

。

Core Workflow

核心工作流

Detect the requested governance mode and evaluated scope from repository truth.
Select profile:
```
lean
```
by default,
```
advanced
```
only with explicit rationale.
For ordinary workflow-backed work, prefer the Level 1 fast path and keep the durable record in workflow artifacts.
Escalate only when the decision scope, risk, or explicit governance run requires it.
Run the selected mode's controls and keep outputs deterministic.
Apply bounded exceptions only through the canonical exception contract.
Emit a traceable gate outcome with artifact paths.

基于仓库真实情况识别所请求的治理模式与评估范围。
选择档位：默认
```
lean
```
，仅在有明确理由时使用
```
advanced
```
。
对于普通的工作流支撑型工作，优先走 Level 1 快路径，并将持久化记录保留在工作流制品中。
仅当决策范围、风险或显式治理运行要求时才升级。
执行所选模式下的控制措施，并保持输出的确定性。
严格通过规范的异常契约来应用有界异常。
输出带有制品路径的可追溯 gate 结果。

Quick Examples

快速示例

```
Does this auth change need an ADR or claim work?
```
Use
```
evidence mode
```
and the decision-boundary reference to decide whether ordinary workflow artifacts are sufficient or whether the change is truly repository-wide, high-risk, or Level 2.
```
Are these tests mostly checking mock calls without user-visible outcome assertions?
```
Use
```
testing mode
```
, apply the test-signal model, and treat likely
```
TG002
```
findings as blocking only when the suite is asserting interaction without externally observable outcome.
```
Show me the host repository's maintenance checks for README, AGENTS, and skill schema.
```
Do not route that through governance. Those checks belong to the host repository's own maintenance/check surface.

```
Does this auth change need an ADR or claim work?
```
使用
```
evidence mode
```
以及决策边界引用，判断普通工作流制品是否足够，或该变更是否真正属于全仓库范围、高风险或 Level 2。
```
Are these tests mostly checking mock calls without user-visible outcome assertions?
```
使用
```
testing mode
```
，应用测试信号模型，并将可能的
```
TG002
```
发现仅在测试套件确实在断言交互而缺乏外部可观测结果时视为阻断。
```
Show me the host repository's maintenance checks for README, AGENTS, and skill schema.
```
不要通过治理来路由此类请求。那些检查属于宿主仓库自身的维护/检查界面。

When Not To Use

何时不要使用

Do not use this skill for workflow intake, PRD shaping, roadmap generation, sprint preparation, or resumable initiative orchestration; defer those to
```
ub-workflow
```
.
Do not use this skill as the primary surface for framework-specific implementation guidance when the task is about code changes rather than governance policy or gate semantics.
Do not use this skill as a generic documentation-normalization layer when
```
ub-quality
```
is the actual owner of the task.

不要将本 skill 用于工作流接收、PRD 打磨、路线图生成、sprint 准备或可恢复的 initiative 编排；这些应交由
```
ub-workflow
```
处理。
当任务关于代码变更而非治理策略或 gate 语义时，不要将本 skill 作为框架特定实现指引的主要入口。
当
```
ub-quality
```
才是该任务的归属方时，不要将本 skill 作为通用的文档规范化层。

Mode Workflows

模式工作流

Repository Mode

verify repository baseline artifacts and deterministic tooling policy
verify CI, permissions, and merge-gate controls
verify release policy with Conventional Commits and
```
release-please
```

校验仓库基线制品与确定性工具链策略
校验 CI、权限与合并 gate 控制
使用 Conventional Commits 与
```
release-please
```
校验发布策略

Testing Mode

detect stack and test runner
treat reported defects as regression-first work before code fixes are accepted
enforce
```
TG001
```
through
```
TG004
```
as blocking and
```
TG005
```
as warning-only
apply
```
TG006
```
through
```
TG011
```
as functional-realism guidance, escalating only when risk, evidence level, or explicit gate scope justifies it
require behavior-first TDD flow for behavior-changing work
keep testing guidance readable, boundary-aware, and deterministic without turning advisory guidance into new gates

识别技术栈与测试运行器
在接受代码修复之前，将报告的缺陷视为回归优先的工作处理
将
```
TG001
```
至
```
TG004
```
作为阻断项强制执行，
```
TG005
```
仅作告警
将
```
TG006
```
至
```
TG011
```
作为功能真实性指引应用，仅在风险、证据层级或显式 gate 范围正当时才升级
对涉及行为变更的工作要求行为优先的 TDD 流程
保持测试指引可读、边界感知且确定，不将建议性指引变成新的 gate

Evidence Mode

classify
```
changeType
```
,
```
evidenceLevel
```
, and
```
profile
```
detect high-risk path impact when the scope requires it
choose the lightest durable record that matches the decision scope
treat workflow-backed initiative artifacts as the default operational record for ordinary Level 1 work
escalate to ADR alignment only when Level 2, repository-wide durable decisions, or explicit high-risk governance applies
require claim-register validation only when blocking rationale depends on claims
validate required artifacts and freshness for the selected path

分类
```
changeType
```
、
```
evidenceLevel
```
与
```
profile
```
在范围要求时检测高风险路径影响
选择与决策范围匹配的最轻量持久化记录
将工作流支撑的 initiative 制品视为普通 Level 1 工作的默认操作记录
仅当 Level 2、全仓库范围的持久化决策或显式高风险治理适用时，才升级到 ADR 对齐
仅当阻断性理由依赖 claim 时，才要求 claim-register 校验
为所选路径校验必需制品及其新鲜度

Core-Contract Mode

apply canonical profile, gate, exception, and report semantics
normalize status language and report contract usage
reject duplicate or conflicting schema definitions

应用规范的档位、gate、异常与报告语义
规范化状态语言与报告契约用法
拒绝重复或冲突的 schema 定义

Full Governance Audit Mode

execute
```
repository mode
```
execute
```
testing mode
```
execute
```
evidence mode
```
consolidate output under canonical report sections

执行
```
repository mode
```
执行
```
testing mode
```
执行
```
evidence mode
```
在规范的报告章节下合并输出

Rules

规则

Keep defaults lean and activate advanced controls explicitly.
Do not imply that repository ADR machinery is the default record for ordinary Level 1 workflow-backed work.
Exception metadata must stay bounded, explicit, and time-limited.
Do not duplicate canonical contract definitions across files when the main skill already embeds the short rule.
Repository-maintenance tooling is not automatically the same thing as lean governance guidance.

保持默认精简，并显式激活高级控制措施。
不要暗示仓库 ADR 机制是普通 Level 1 工作流支撑型工作的默认记录。
异常元数据必须保持有界、明确且有时限。
当主 skill 已内嵌简短规则时，不要在多个文件中重复规范契约定义。
仓库维护工具链并不自动等同于精简的治理指引。

Output Requirements

输出要求

When producing non-trivial governance output, include:

```
environment_note
```
```
scope_note
```
```
decision_note
```
```
gate_note
```
```
exception_note
```
```
validation_note
```

Add mode-specific sections when applicable:

```
quality_gate_note
```
for testing mode
```
evidence_inventory
```
and
```
claim_note
```
for evidence mode

在产出非平凡治理输出时，包含：

```
environment_note
```
```
scope_note
```
```
decision_note
```
```
gate_note
```
```
exception_note
```
```
validation_note
```

在适用时添加模式专属章节：

测试模式下的
```
quality_gate_note
```
证据模式下的
```
evidence_inventory
```
与
```
claim_note
```

Completion Checklist

完成检查清单

Selected mode is explicit.
Profile choice is explicit (
```
lean
```
or
```
advanced
```
).
The ordinary Level 1 fast path versus Level 2 escalation path is explicit.
Required deterministic artifacts are present or explicitly missing.
Gate result is traceable and reproducible.
Exceptions use the canonical fields and remain bounded.
Governance guidance stays self-contained and internally consistent.

所选模式是明确的。
档位选择是明确的（
```
lean
```
或
```
advanced
```
）。
普通的 Level 1 快路径与 Level 2 升级路径之间的选择是明确的。
必需的确定性制品已存在，或已明确指出缺失。
Gate 结果可追溯且可复现。
异常使用规范字段并保持有界。
治理指引保持自包含且内部一致。