openclaw - 💡(How to fix) Fix Clarify AGENTS.md review policy for config/default additions as review metrics and merge risk [2 pull requests]

Goal

Update AGENTS.md so OpenClaw-specific ClawSweeper review policy treats new or changed config/default surfaces as review metrics and merge-risk material when they can affect existing users, upgrade behavior, operator action, provider routing, plugin behavior, persisted preferences, setup, startup, or fallback behavior.

This is an OpenClaw repository policy clarification. It should steer review behavior through ClawSweeper's generic reviewMetrics shape and existing review fields such as mergeRiskLabels, risks, bestSolution, mergeRiskOptions, and labelJustifications.

Background

The current AGENTS.md already says plugin APIs, provider routing, auth/session state, persisted preferences, config loading, migrations, setup, startup checks, and fallback behavior are compatibility/upgrade-sensitive. It also says config breaks, removed fallbacks, fail-closed changes, or new operator action should be treated as merge risk even with green CI.

That policy should also cover new config/default additions. Adding a new option, default, required setting, strict mode, validation path, provider route, startup check, workflow behavior, or operator action can change the effective contract even when nothing is removed.

When practical, the review should make the count and direction visible through reviewMetrics, such as “adds 2 config/default surfaces,” “changes 1 default,” or “removes 1 fallback/config surface.” When that metric indicates concrete merge risk, the concern should also appear in risks and the appropriate merge-risk fields.

Proposed AGENTS.md update

In ## ClawSweeper Review Policy, update the existing compatibility/upgrade-sensitive bullet to explicitly include additions.

Suggested wording:

- Plugin APIs, provider routing, auth/session state, persisted preferences, config loading, config/default additions, migrations, setup, startup checks, and fallback behavior are compatibility/upgrade-sensitive. Treat config breaks, new config/default surfaces, removed fallbacks, fail-closed changes, stricter validation, or new operator action as merge risk even with green CI when they can affect existing users, upgrades, provider/plugin behavior, or maintainer operations.

Add a follow-up sentence:

- For PRs that add, remove, or change config/default surfaces with possible compatibility, upgrade, provider/plugin, operator, setup, startup, or fallback impact, ClawSweeper review should emit a `reviewMetrics` entry when practical. The metric should name the count and direction of the changes, such as added, changed, or removed config/default surfaces, and explain why the metric matters before merge. When the metric indicates concrete merge risk, also surface the concern in `risks`, use `mergeRiskLabels` when the risk matches the label rubric, make `bestSolution` name the desired pre-merge state, and ensure `labelJustifications` explain the specific reason rather than restating the label.

Acceptance criteria

• AGENTS.md explicitly says config/default additions can be compatibility/upgrade-sensitive merge risk.
• The wording covers additions without implying every config-looking change is automatically risky.
• For affected PRs, OpenClaw policy steers ClawSweeper to emit reviewMetrics entries that name the count and direction of config/default surface changes when known, such as “adds 2 config/default surfaces,” “changes 1 default,” or “removes 1 fallback/config surface.”
• The metric reason explains why the count matters for merge review, such as compatibility, upgrade behavior, provider/plugin behavior, operator action, setup/startup behavior, or fallback behavior.
• When the metric indicates concrete merge risk, the concern is also surfaced in risks and existing merge-risk fields where appropriate.
• The policy keeps ClawSweeper using generic review metrics and existing review fields rather than introducing an OpenClaw-specific schema concept.
• The policy distinguishes ordinary implementation changes from changes that affect existing users, upgrade behavior, provider/plugin behavior, operator action, or maintainer operations.
• The change remains under ## ClawSweeper Review Policy.

Non-goals

• Do not add an OpenClaw-specific ClawSweeper schema field.
• Do not change ClawSweeper labels in this issue.
• Do not require every config-looking PR to get a merge-risk label.
• Do not require perfect deterministic counting when the public/config boundary is ambiguous.
• Do not duplicate generic ClawSweeper prompt rules in OpenClaw beyond the OpenClaw-specific policy.