feat: event.schema v1.1——补 6 类治理审计事件（ADR-0016）

[randypanding]

ADR-0016（决策 4，解决 agent-registry #20）

问题（复核属实）：event.schema v1 仅 5 类事件。而治理体系多处声明依赖事件流审计：

• AR-6 要求 handoff 完成才销毁——但 handoff 交接无事件，销毁审计只能靠 retrospective 自述；
• AR-4 ask_risky/ask_per_action 审批、incident_cell 条件预授权——审批流无事件不可追溯；
• 凭据使用（gh-app-token 1h 令牌）无事件——AR-4 最小权限无审计数据；
• 预算熔断、ephemeral 销毁、judge 仲裁/回避同理。

修复：v1.1 新增 6 类事件（顶层枚举 5→11，只增不改，v1 消费方向后兼容）：

事件	payload 要点	审计语义
handoff_step	item/side/status(started,done,failed)/by/reason	AR-6 销毁前置逐项凭证
approval	action/decision(requested,granted,denied,timeout)/asked_by/decided_by	审批流全链路（含预授权规则 id）
credential_used	kind/ref/scope/ok/reason（禁记值）	AR-4 凭据使用留痕
budget_consumed	pool/usd/cumulative/exhausted	预算熔断信号
team_lifecycle	transition(created,archived,destroyed,frozen)/handoff_ref	AR-6 生命周期时序
judge_verdict	dispute/outcome/recused/judge	AR-8 独立性审计

红队建议的 requested/granted/denied 三型拆分并入 approval.decision 枚举——顶层类型爆炸无审计收益。schema 落盘本仓（L0）、issue 报在 agent-registry（#20，L1）——治理分工见 REPOS.yaml。

本地验证：YAML 解析通过（11 events / 11 defs）。

[coderabbitai]

Warning

Review limit reached

@randypanding, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 28 minutes

Limit details: You’ve used all 3 included reviews currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2cb5cbff-0bad-4eeb-9e86-1f91ffdd160c

📥 Commits

Reviewing files that changed from the base of the PR and between 0ffe714 and 62d5550.

📒 Files selected for processing (1)

• standards/agent/event.schema.yaml

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Extend event schema with governance audit events

✨ Enhancement 🕐 20-40 Minutes

AI Description

• Adds six governance events covering handoffs, approvals, credentials, budgets, team lifecycle, and
 verdicts.
• Bumps schema identity to v1.1 while preserving all five existing event names.
• Documents audit semantics for AR-4, AR-6, and AR-8 controls.

Diagram

graph TD
  A["Agent Runtime"] --> B["Event Schema v1.1"] --> C[("Append-only Stream")] --> D["AR-4 Audit"]
  C --> E["AR-6 Lifecycle"]
  C --> F["Budget Controls"]
  C --> G["AR-8 Audit"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Discriminated payload union

• ➕ Machine-enforces the payload definition associated with each event name.
• ➕ Supports conditional required fields such as failure reasons and destruction handoff references.
• ➖ Requires a broader, compatibility-sensitive redesign using oneOf or if/then rules.
• ➖ Could reject previously accepted v1 records because payload definitions are currently descriptive.

2. Separate approval event types

• ➕ Makes requested, granted, denied, and timeout transitions directly filterable.
• ➕ Avoids inspecting the approval payload when routing events.
• ➖ Expands the top-level event namespace without adding audit information.
• ➖ Duplicates approval fields and complicates consumers handling one logical workflow.

Recommendation: The additive six-event extension is the best v1.1 approach because it closes the identified audit gaps while preserving existing event names and keeping approval states within one coherent event contract. A discriminated payload union would improve machine validation, but should be introduced separately after compatibility expectations and conditional required fields are defined.

Files changed (1) +94 / -5

Enhancement (1) +94 / -5

event.schema.yamlAdd six governance audit event definitions +94/-5

Add six governance audit event definitions

• Bumps the event schema identifier to v1.1 and expands the event enum from five to eleven values. Defines payload structures and audit semantics for handoffs, approvals, credential usage, budget consumption, team lifecycle transitions, and judge verdicts while retaining every existing event name.

standards/agent/event.schema.yaml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Payload definitions never validate ✓ Resolved 🐞 Bug ≡ Correctness

Description

The six new event values still use the root's generic payload: {type: object} rather than their
corresponding $defs, and payload is not required. Consequently, records such as
{"event":"approval","ts":"...","trace_id":"..."} or an approval with arbitrary payload fields
validate without consulting the new approval schema.

Code

standards/agent/event.schema.yaml[R23-26]

+      - handoff_step
+      - approval
+      - credential_used
+      - budget_consumed

Relevance

●●● Strong

Deterministic schema wiring omission directly defeats the PR’s stated audit-validation intent.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The root only requires event, ts, and trace_id; payload is an optional generic object, while
the event-specific schemas exist only as unreferenced $defs. Governance explicitly requires
runtime events to conform to this schema.

standards/agent/event.schema.yaml[13-35]
standards/agent/event.schema.yaml[82-153]
governance/GOVERNANCE.yaml[170-177]
governance/GOVERNANCE.yaml[221-226]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly accepted governance event names are not bound to their event-specific payload definitions. The root schema accepts an absent or arbitrary object payload without evaluating any new `$def`.

## Issue Context
Governance declares this schema as the enforced runtime event contract, so definitions under `$defs` must be referenced from the root validation path. Preserve support for all eleven event types.

## Fix Focus Areas
- standards/agent/event.schema.yaml[13-153]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Audit payloads accept empties ✓ Resolved 🐞 Bug ≡ Correctness

Description

Every newly added payload definition has only optional properties, so even after wiring the
$defs into the root, {} remains valid for all six governance events. The schema also fails to
enforce its stated conditional requirements, including reasons for failures, cards for per_card
consumption, and handoff references for destruction.

Code

standards/agent/event.schema.yaml[R88-91]

+    properties:
+      item: {type: string, description: "team.schema lifecycle.handoff 枚举值（artifacts-pr/memory-distill/…）"}
+      side: {enum: [team_side, stewardship_side], description: "执行侧（team-collaboration PART 2 lifecycle.handoff）"}
+      status: {enum: [started, done, failed], description: "failed 须附 reason"}

Relevance

●●● Strong

PR #13 accepted enforcing governance requirements as JSON Schema conditions rather than descriptions
alone.

PR-#13

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Each new definition declares properties without a required list. Several descriptions explicitly
say fields are mandatory under particular states, but there are no conditional constraints; this is
the same schema-enforcement failure pattern previously accepted in PR #13.

standards/agent/event.schema.yaml[88-106]
standards/agent/event.schema.yaml[107-142]
standards/agent/event.schema.yaml[143-153]
PR-#13

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
All six new governance payload definitions accept empty objects and do not enforce conditional audit fields described as mandatory.

## Issue Context
Add appropriate `required` arrays for each event definition and JSON Schema `if`/`then` constraints for conditional requirements such as failed status requiring `reason`, `ok: false` requiring `reason`, `pool: per_card` requiring `card`, and `transition: destroyed` requiring `handoff_ref`.

## Fix Focus Areas
- standards/agent/event.schema.yaml[82-153]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Unknown handoffs validate ✓ Resolved 🐞 Bug ≡ Correctness

Description

handoff_step.item accepts any string even though it claims to carry a `team.schema
lifecycle.handoff` enum value. This allows an unknown or misspelled item to be recorded as completed
and counted toward the destruction audit without corresponding to any required handoff action.

Code

standards/agent/event.schema.yaml[89]

+      item: {type: string, description: "team.schema lifecycle.handoff 枚举值（artifacts-pr/memory-distill/…）"}

Relevance

●●● Strong

Closed enum enforcement is a deterministic correctness fix matching the authoritative team schema.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The event field is merely type: string, while the authoritative team schema uses a closed
enumeration for lifecycle handoff actions and states that every listed action must complete before
destruction.

standards/agent/event.schema.yaml[85-93]
standards/agent/team.schema.yaml[130-134]
governance/GOVERNANCE.yaml[170-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`handoff_step.item` accepts arbitrary strings rather than the authoritative handoff vocabulary referenced by its description.

## Issue Context
Align the event field with the current `team.schema.yaml` handoff enum, preferably through a shared schema definition if vocabulary duplication would otherwise create drift.

## Fix Focus Areas
- standards/agent/event.schema.yaml[88-93]
- standards/agent/team.schema.yaml[130-134]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 7 rules

Review mode: ⚖️ Balanced: 这是公共事件 schema 的行为/契约扩展，涉及审计、凭据、审批、预算与生命周期语义；虽集中在单文件，但风险足以需要完整单次评审，尚未达到应多轮冗余评审的缺陷密度。

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗