This is an automated email from the ASF dual-hosted git repository.
terrymanu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 1bcf1101ad8 Strengthen project commitment gates in issue and PR review
(#39912)
1bcf1101ad8 is described below
commit 1bcf1101ad8bef3059674a463b740bda562887ee
Author: Liang Zhang <[email protected]>
AuthorDate: Mon Sep 21 11:39:39 2026 +0800
Strengthen project commitment gates in issue and PR review (#39912)
---
.codex/harness/agents/cases.toml | 81 ++++++++++++++++++++++
.codex/skills/analyze-issue/SKILL.md | 54 ++++++++++-----
.../analyze-issue/references/output-contract.md | 20 ++++--
.codex/skills/review-pr/SKILL.md | 45 +++++++-----
4 files changed, 162 insertions(+), 38 deletions(-)
diff --git a/.codex/harness/agents/cases.toml b/.codex/harness/agents/cases.toml
index 02a12b2b044..954c948ae3b 100644
--- a/.codex/harness/agents/cases.toml
+++ b/.codex/harness/agents/cases.toml
@@ -2756,3 +2756,84 @@ forbidden_summary_terms = ["Strictly compliant"]
policy_binding_profile = "coding-standards-audit"
policy_assertions = [{source = "standalone-audit", statements = ["When the
scope contains a Java declaration with at least two covered declaration
annotations, read the [Java declaration annotation order
rules](rules/java-annotation-order.md) through EOF.", "Remain read-only
throughout the audit.", "Check every constrained file and every physical line
in scope without sampling.", "An existing-code violation of an applicable
written standard is sufficient to report non-compliance."]}, {so [...]
critical = true
+
+[[cases]]
+id = "issue_enhancement_requires_acceptance_before_pr"
+group = "issue project commitment"
+description = "Keeps a popular enhancement request from becoming an accepted
project commitment before a maintainer decision."
+phase = "issue problem validity and project commitment gate"
+ordinary_loop = false
+profile = "analyze-issue"
+semantic_policy_assertions = true
+prompt = "Draft the default maintainer reply for a ShardingSphere feature
request. The requested database-upper-layer behavior is plausible but not
currently supported. The issue is open, labeled as an enhancement, highly
popular, has an available contributor and a ready patch, but official docs,
maintained contracts, and public maintainer comments do not accept the new
behavior boundary yet. The facts are sufficient for classification, and no
reproduction details are needed. Classify th [...]
+decision = "proceed"
+required_actions = []
+allowed_actions = []
+forbidden_actions = ["edit_code", "edit_non_code", "mutate_git",
"mutate_remote"]
+required_reasons = []
+required_summary_terms = ["enhancement", "maintainer", "discussion", "accept"]
+forbidden_summary_terms = ["Contributors are welcome", "submit a PR", "Out of
Scope", "status: invalid"]
+policy_binding_profile = "analyze-issue"
+policy_assertions = [{source = "analyze-issue", statements = ["When project
responsibility or acceptance of a new commitment remains a maintainer choice,
classify the request as an `Enhancement` that requires maintainer discussion
rather than declaring it accepted or out of scope.", "An open issue, labels,
popularity, available contributors, or submitted code do not establish project
acceptance, and an exact existing behavior or special case does not authorize a
broader generalization.", [...]
+critical = true
+
+[[cases]]
+id = "issue_out_of_scope_requires_direct_ownership_evidence"
+group = "issue project commitment"
+description = "Closes a request as out of scope only when official evidence
assigns the behavior to another owner."
+phase = "issue problem validity and project commitment gate"
+ordinary_loop = false
+profile = "analyze-issue"
+semantic_policy_assertions = true
+prompt = "Draft the default maintainer reply for an issue asking
ShardingSphere to implement database-engine physical WAL replication and
storage compaction. Official project positioning states that ShardingSphere is
an upper-layer Database Plus platform and does not create a database,
maintained contracts assign this behavior to the database engine, and there is
no contrary public maintainer decision. The issue already contains enough
evidence to decide project responsibility. Classify [...]
+decision = "proceed"
+required_actions = []
+allowed_actions = []
+forbidden_actions = ["edit_code", "edit_non_code", "mutate_git",
"mutate_remote"]
+required_reasons = []
+required_summary_terms = ["Out of Scope", "database engine"]
+required_summary_term_groups = [["close", "closing", "closed"]]
+forbidden_summary_terms = ["status: volunteer wanted", "Contributors are
welcome", "Needs More Info", "stack trace"]
+policy_binding_profile = "analyze-issue"
+policy_assertions = [{source = "analyze-issue", statements = ["Classify `Out
of Scope / Won't Fix` only when official project positioning, maintained
contracts, or an explicit public maintainer decision proves that another owner
is responsible or that the request conflicts with the project boundary.",
"Identify the official project-positioning, maintained-contract, or explicit
public maintainer evidence that assigns the behavior to another owner or
conflicts with the project boundary.", [...]
+critical = true
+
+[[cases]]
+id = "public_pr_small_diff_unaccepted_commitment_needs_discussion"
+group = "review-pr project commitment"
+description = "Rejects a locally correct small diff that introduces an
unaccepted cross-dialect behavior commitment."
+phase = "review-pr problem and project commitment gate"
+ordinary_loop = true
+profile = "review-pr"
+semantic_policy_assertions = true
+prompt = "Complete a public-PR Code Correctness Review. A five-line fallback
is locally correct and fully tested, but it makes Proxy accept and rewrite a
previously unsupported vendor administration command for every dialect. The
linked issue is open, popular, labeled as an enhancement, and has willing
contributors, but official docs, maintained contracts, and public maintainer
comments do not accept this new cross-dialect semantic commitment.
Current-candidate Checkstyle and Spotless pa [...]
+decision = "proceed"
+required_actions = []
+allowed_actions = ["inspect_local", "run_bounded_adversarial_review"]
+forbidden_actions = ["edit_code", "edit_non_code", "run_local_checks",
"run_pre_handoff_review", "propose_commit_message", "mutate_git",
"mutate_remote"]
+required_reasons = []
+required_summary_terms = ["### Result", "Review Result: Not Mergeable",
"Feedback Mode: Needs Discussion", "Blocking Issues", "project", "commitment",
"### Coverage"]
+forbidden_summary_terms = ["Review Result: Mergeable", "Feedback Mode: Change
Request"]
+policy_binding_profile = "review-pr"
+policy_assertions = [{source = "review-pr", statements = ["An open or labeled
issue, popularity, contributor effort, available code, passing tests, or a
small diff do not establish project acceptance.", "When evidence disproves the
problem, expected behavior, applicable project ownership, or an asserted
accepted commitment, or when a new commitment still requires a maintainer
decision, record a `Needs Discussion` condition.", "If admissible evidence
disproves the problem model, expected [...]
+critical = true
+
+[[cases]]
+id = "public_pr_accepted_behavior_overdesign_is_change_request"
+group = "review-pr project commitment"
+description = "Treats unjustified implementation surface for an accepted
behavior as a change request rather than a direction dispute."
+phase = "review-pr problem and project commitment gate"
+ordinary_loop = true
+profile = "review-pr"
+semantic_policy_assertions = true
+prompt = "Complete a public-PR Code Correctness Review. Official documentation
and an explicit public maintainer decision accept one local metadata-validation
behavior owned by an existing class. The PR implements it through a new public
SPI, a result hierarchy, and three forwarding types, although the existing
owner can express the behavior directly and no real stable variation, external
consumer, compatibility contract, or reuse exists. The full path and strongest
counter-evidence conf [...]
+decision = "proceed"
+required_actions = []
+allowed_actions = ["inspect_local", "run_bounded_adversarial_review"]
+forbidden_actions = ["edit_code", "edit_non_code", "run_local_checks",
"run_pre_handoff_review", "propose_commit_message", "mutate_git",
"mutate_remote"]
+required_reasons = []
+required_summary_terms = ["### Result", "Review Result: Not Mergeable",
"Feedback Mode: Change Request", "Blocking Issues", "public SPI", "###
Coverage"]
+forbidden_summary_terms = ["Review Result: Mergeable", "Feedback Mode: Needs
Discussion"]
+policy_binding_profile = "review-pr"
+policy_assertions = [{source = "review-pr", statements = ["When the behavior
is accepted but the patch adds unsupported generalization, public surface,
parallel models, or abstractions without a real stable boundary, treat the
excess as a finding candidate under the implementation rules; patch size or
novelty alone is not evidence of overdesign.", "`Necessity`: the requested
change is required for safety, correctness, or an applicable repository design
or contract rule in the selected fo [...]
+critical = true
diff --git a/.codex/skills/analyze-issue/SKILL.md
b/.codex/skills/analyze-issue/SKILL.md
index 18450000eb1..20c63b91263 100644
--- a/.codex/skills/analyze-issue/SKILL.md
+++ b/.codex/skills/analyze-issue/SKILL.md
@@ -21,7 +21,7 @@ detailed Reference Analysis unless the user explicitly
requests it.
The default maintainer reply must:
- Start by addressing the issue author when the author is known, for example
`Hi @user, thanks for the question.`
-- State the supportability decision in the first paragraph: supported, not
supported, bug, enhancement, invalid usage, duplicate, or needs more
information.
+- State the supportability decision in the first paragraph: supported, not
supported, bug, enhancement, invalid usage, duplicate, out of scope, or needs
more information or maintainer discussion.
- Explain the reason from the ShardingSphere project point of view using
official docs, repository code, or issue evidence.
- Give the next action: correct usage, label/close recommendation, required
missing facts, or PR/design expectations.
- Read like a community member helping in the issue thread, not an external
analyst summarizing the issue.
@@ -71,7 +71,7 @@ Use only the following sources:
- Apache ShardingSphere official documentation.
- Apache ShardingSphere official repository code and tests.
- Target GitHub issue content (body, comments, and linked PRs in the same
repository).
-- Same-repository GitHub issues/PRs needed to verify a duplicate or prior fix
relationship.
+- Same-repository GitHub issues/PRs needed to verify a duplicate, prior fix,
explicit project-responsibility decision, or accepted behavior boundary.
Do not use blogs, third-party tutorials, or forum posts as evidence.
@@ -127,16 +127,23 @@ Before classifying an issue as `Duplicate`, check the
evidence against at least
For `Duplicate`, the maintainer reply should link the original PR/issue,
recommend `type: duplicate`, and close as duplicate unless the reporter can
still reproduce on a version that includes the fix.
-## Reasonability Gate
+## Problem Validity and Project Commitment Gate
-Run this gate before asking for more reproduction details:
-1. Is the request about configuration, usage, rule semantics, SQL support
boundaries, or expected feature behavior?
-2. Do official docs or repository code already define the behavior boundary
clearly enough?
-3. Would the requested behavior require a new semantic contract rather than
fixing a mismatch?
+Run this gate before asking for more reproduction details, accepting a new
behavior, or inviting implementation:
+1. Does the evidence establish a real problem and a coherent expected
behavior, or do official docs and repository code already identify invalid or
unsupported usage?
+2. Is the requested behavior owned by ShardingSphere's database upper layer
rather than by a database engine, driver, application, or external operational
tool?
+3. Would the resolution preserve an existing supported contract or add a
project commitment such as new semantics, configuration, API or SPI,
compatibility, topology, database, dialect, or cross-module support?
+4. What is the narrowest user-visible behavior justified by the reported
scenario, and does the proposed solution add hypothetical reuse, unsupported
generalization, or commitments beyond that behavior?
+5. Do official project positioning, maintained contracts, or an explicit
public maintainer decision accept every new commitment?
-If the answer supports invalid usage or unsupported behavior, classify as
`Misunderstanding / Invalid Usage` or `Question` and answer directly.
-Do not default to `Needs More Info` only because the issue lacks a full SQL,
database version, or stack trace when the current evidence is already enough to
judge supportability.
-Use `Needs More Info` only when missing facts block the supportability
decision or root-cause classification.
+If the evidence supports invalid or unsupported usage, classify the issue as
`Misunderstanding / Invalid Usage` or `Question` and answer directly.
+Classify `Out of Scope / Won't Fix` only when official project positioning,
maintained contracts, or an explicit public maintainer decision proves that
another owner is responsible or that the request conflicts with the project
boundary.
+When project responsibility or acceptance of a new commitment remains a
maintainer choice, classify the request as an `Enhancement` that requires
maintainer discussion rather than declaring it accepted or out of scope.
+When the problem is valid but the proposed solution is broader than the
evidenced behavior, retain the supported issue classification and require a
narrower behavior contract instead of rejecting the problem.
+An open issue, labels, popularity, available contributors, or submitted code
do not establish project acceptance, and an exact existing behavior or special
case does not authorize a broader generalization.
+Do not invite a PR or recommend `status: volunteer wanted` until public
evidence establishes ShardingSphere ownership and acceptance of the requested
behavior boundary.
+Do not default to `Needs More Info` only because the issue lacks a full SQL,
database version, or stack trace when the current evidence is already enough to
judge supportability or project responsibility.
+Use `Needs More Info` only when missing facts block the supportability,
project-responsibility, or root-cause classification.
## GitHub Access Preflight
@@ -201,9 +208,11 @@ Mention topology in the default maintainer reply only when
it changes the suppor
- Bug
- Duplicate
- Enhancement
-5. If behavior changes are needed, explain scope and compatibility impact.
+ - Out of Scope / Won't Fix
+5. Separate the problem classification from acceptance of the proposed
solution.
+6. If behavior changes are needed, explain project responsibility, the
narrowest accepted behavior, compatibility impact, and every new project
commitment.
-Always complete root-cause analysis before recommendations.
+Complete root-cause analysis before Bug recommendations; for Question,
Misunderstanding / Invalid Usage, and Out of Scope / Won't Fix, establish the
decisive supportability or ownership evidence without inventing a code-level
root cause.
## Evidence Method
@@ -241,8 +250,9 @@ Before final conclusion, provide issue type and label
recommendations:
- Question: recommend `type: question`
- Misunderstanding / Invalid Usage: recommend `type: question`, `status:
invalid`
- Bug: recommend `type: bug`, optionally with module/database labels (for
example `in: SQL parse`, `db: SQLServer`)
-- Enhancement: recommend `type: enhancement`, and optionally `status:
volunteer wanted` to invite community contribution
+- Enhancement: recommend `type: enhancement`; recommend `status: volunteer
wanted` only after public evidence establishes project acceptance of the
requested behavior boundary
- Duplicate: recommend `type: duplicate`, optionally with module/database
labels when the duplicate scope is clear
+- Out of Scope / Won't Fix: recommend closure with only an existing project
label supported by repository or target-issue evidence; do not invent a label
When type is Bug/Enhancement/Duplicate, add module/database labels when
evidence is sufficient:
- Parser-related -> `in: SQL parse`
@@ -297,15 +307,22 @@ Default to maintainer replies shaped by the issue type:
5. Enhancement
- Acknowledge the requested behavior as new or changed capability.
-- Explain design questions, compatibility impact, and expected tests before
accepting implementation.
-- Invite community contribution when suitable.
-- Recommend `type: enhancement` and optionally `status: volunteer wanted`.
+- State that classification as an Enhancement does not by itself accept
implementation or expand the supported contract.
+- Explain ShardingSphere ownership, the narrowest requested behavior, new
project commitments, compatibility impact, and expected tests before accepting
implementation.
+- When acceptance remains a maintainer choice, request that decision and do
not invite implementation yet.
+- Invite community contribution and recommend `status: volunteer wanted` only
after public evidence establishes acceptance of the behavior boundary.
+- Recommend `type: enhancement`.
6. Needs More Info
- Ask only for facts that block classification or root-cause judgment.
- Use one concise consolidated list and set a 7-14 day follow-up window.
- Recommend `status: need more info`.
+7. Out of Scope / Won't Fix
+- Identify the official project-positioning, maintained-contract, or explicit
public maintainer evidence that assigns the behavior to another owner or
conflicts with the project boundary.
+- Explain why local usefulness, popularity, available implementation, or a
superficially small change does not establish a ShardingSphere commitment.
+- Recommend closure without inviting a PR, and use only an existing label
supported by repository or target-issue evidence.
+
For explicit Maintainer Reply + Reference Analysis and Reference Analysis Only
modes, use the detailed four-/five-section structures in the output reference.
@@ -323,8 +340,10 @@ In the maintainer reply portion:
- Do not start with `Problem Understanding`, `Root Cause`, `Problem Analysis`,
or `Problem Conclusion`.
- Do not expose `OBS-*` / `INF-*` evidence IDs unless the user explicitly asks
for evidence IDs in the reply.
- Do not write from a detached observer perspective such as `the reporter
wants` or `the issue asks`.
-- Do not over-request reproduction details after the Reasonability Gate has
enough evidence to classify unsupported or invalid usage.
+- Do not over-request reproduction details after the Problem Validity and
Project Commitment Gate has enough evidence to classify unsupported, invalid,
or out-of-scope behavior.
- Do not recommend a PR for invalid usage unless reframed as a clearly
justified enhancement.
+- Do not present an Enhancement classification, issue label, contributor
interest, or available patch as proof that the project accepted a new behavior.
+- Do not generalize an exact existing behavior or special case into a wider
database, dialect, topology, module, API, or SPI commitment without direct
acceptance evidence.
- For questions, invite broader community participation when it can help the
issue author or improve documentation.
Before final output, run this self-check:
@@ -401,6 +420,7 @@ If lint fails, mark analysis as incomplete.
- Do not recommend behavior that conflicts with official ShardingSphere
conventions.
- Do not provide certainty when evidence is insufficient.
+- Do not accept or invite implementation of a new project commitment before
its ownership and narrow behavior boundary are established by public evidence.
- Do not output a neutral machine-style report when the user asked for a reply
to an issue author.
- Do not append Reference Analysis unless the user explicitly requests it.
- Source and workaround restrictions are governed by Source Policy and
Response Strategy by Type.
diff --git a/.codex/skills/analyze-issue/references/output-contract.md
b/.codex/skills/analyze-issue/references/output-contract.md
index 8b370ccb073..f08c1d48f51 100644
--- a/.codex/skills/analyze-issue/references/output-contract.md
+++ b/.codex/skills/analyze-issue/references/output-contract.md
@@ -66,7 +66,16 @@ Please verify with a version that includes #<fix-pr>. I
suggest labeling this as
```markdown
Hi @user, thanks for the suggestion.
This is not supported today and should be handled as an enhancement rather
than a bug.
-Before implementation, we need to define <semantic contract>, <compatibility
impact>, and <test scope>. I suggest labeling this as `type: enhancement`.
+Classifying this as an enhancement does not by itself accept implementation or
expand the supported contract.
+Before implementation, establish <ShardingSphere responsibility>, <narrow
behavior boundary>, <new project commitments>, <compatibility impact>, and
<test scope>. If public evidence does not yet establish acceptance, please
continue the design discussion rather than submitting a PR. I suggest labeling
this as `type: enhancement`.
+```
+
+### Out of Scope / Won't Fix
+
+```markdown
+Hi @user, thanks for the suggestion.
+This request is outside the current ShardingSphere project responsibility
because <official project-positioning, maintained-contract, or explicit
maintainer evidence> assigns the behavior to <owner>.
+The usefulness or availability of an implementation does not establish a
ShardingSphere support commitment. I suggest closing this request without
inviting a PR.
```
### Needs More Info
@@ -96,8 +105,7 @@ Please provide these details within <7-14 days>. If there is
no update, we may c
terminal transcripts. Keep command evidence in inline code or short fenced
blocks.
-Use this four-section shape for Question, Misunderstanding / Invalid Usage, and
-Duplicate:
+Use this four-section shape for Question, Misunderstanding / Invalid Usage,
Duplicate, and Out of Scope / Won't Fix:
```markdown
### Problem Understanding
@@ -114,7 +122,7 @@ Duplicate:
### Problem Analysis
-- **Issue Type:** Question / Misunderstanding / Invalid Usage / Duplicate
+- **Issue Type:** Question / Misunderstanding / Invalid Usage / Duplicate /
Out of Scope / Won't Fix
- **Evidence:** ...
- **Label Recommendation:** ...
@@ -129,6 +137,7 @@ Duplicate:
- **Merged In:** commit/milestone/version if known (Duplicate only)
- **Recommended Labels:** ...
- **Next Action:** ...
+- **Project Responsibility:** External owner / Conflicts with project boundary
(Out of Scope / Won't Fix only)
```
Use this five-section shape for Bug and Enhancement:
@@ -170,6 +179,8 @@ Use this five-section shape for Bug and Enhancement:
- **Next Action:** ...
- **Compatibility:** Behavior/Config/API-SPI/SQL
- **Regression Scope:** ...
+- **Project Responsibility:** ShardingSphere / External owner / Maintainer
decision required (Enhancement only)
+- **Commitment Status:** Existing contract / Accepted new contract /
Maintainer decision required (Enhancement only)
```
## Codex Chat Delivery
@@ -195,6 +206,7 @@ Use this five-section shape for Bug and Enhancement:
- Every conclusion cites at least one `OBS-*` or `INF-*` evidence ID, and every
`INF-*` derives from one or more observations.
- `Problem Conclusion` includes all fields required by the selected shape.
+- Enhancement and Out of Scope / Won't Fix conclusions include their
conditional project-responsibility and commitment fields.
- Documentation evidence has concrete URLs; code evidence has repository paths
or class names.
- Labels, severity, topology, commands, class names, method names, SQL, YAML,
diff --git a/.codex/skills/review-pr/SKILL.md b/.codex/skills/review-pr/SKILL.md
index 027be748742..edf6ac6ffba 100644
--- a/.codex/skills/review-pr/SKILL.md
+++ b/.codex/skills/review-pr/SKILL.md
@@ -40,9 +40,7 @@ fact—not CI—as the incomplete reason.
## Canonical Assessment
-Resolve one review basis before discovery: the effective candidate, applicable
-requirements, selected review focus, and admissible evidence. Run the Review
-Workflow against that basis and produce one mode-independent assessment:
+Resolve one review basis before discovery: the effective candidate, applicable
requirements, accepted behavior and project commitments, selected review focus,
and admissible evidence. Run the Review Workflow against that basis and produce
one mode-independent assessment:
confirmed findings consolidated by fix boundary, needs-discussion conditions,
incomplete-evidence gaps, and Completion Gate state.
@@ -85,6 +83,21 @@ unchanged basis.
Standalone review is read-only and does not activate `code-implementation` or
acquire write authority. Before judging the effective candidate, read
[implementation
rules](../code-implementation/references/rules/implementation.md),
[non-regression
rules](../code-implementation/references/rules/non-regression.md), and
[verification rules](../code-implementation/references/verification.md) through
EOF. Also read [testing
rules](../code-implementation/references/rules/testing.md) when tests [...]
Before judging reviewed code or Maven POM changes, read [coding
standards](../coding-standards/SKILL.md) through EOF and use its Implementation
Guidance Mode.
+## Problem and Project Commitment Gate
+
+Complete this gate before implementation-detail discovery; it establishes the
review basis but does not waive the Finding Proof, Mandatory Style
Verification, Completion, or convergence gates.
+
+1. Reconstruct the problem and expected behavior from the PR, linked issue
when present, official documentation, maintained contracts, current code, and
tests.
+2. Classify the requested outcome as preserving an accepted contract or adding
a project commitment such as new semantics, configuration, API or SPI,
compatibility, topology, database, dialect, or cross-module support.
+3. For Apache ShardingSphere, establish that ShardingSphere owns the behavior
and that official project positioning, maintained contracts, or an explicit
public maintainer decision accepts every new commitment; for an authorized
downstream repository, apply equivalent target-project evidence available
within the user-authorized repository boundary.
+4. Identify the narrowest accepted user-visible behavior and compare it with
the patch's public contract, shared abstractions, compatibility surface,
documentation, and tests.
+5. Check whether the change creates precedent or consistency pressure beyond
the accepted behavior; an exact existing behavior or special case does not
authorize broader generalization.
+
+An open or labeled issue, popularity, contributor effort, available code,
passing tests, or a small diff do not establish project acceptance.
+When evidence disproves the problem, expected behavior, applicable project
ownership, or an asserted accepted commitment, or when a new commitment still
requires a maintainer decision, record a `Needs Discussion` condition.
+When the behavior is accepted but the patch adds unsupported generalization,
public surface, parallel models, or abstractions without a real stable
boundary, treat the excess as a finding candidate under the implementation
rules; patch size or novelty alone is not evidence of overdesign.
+When a decisive acceptance or ownership fact is unavailable after every
admissible route, apply the Review Incomplete Proof Gate instead of converting
uncertainty into `Needs Discussion`.
+
## Scope and Evidence
Read [evidence-access.md](references/evidence-access.md) and complete its
GitHub Access Preflight before any GitHub request. It owns public-read
selection, current-head identity, authoritative file scope, local-style
evidence, failure attribution, CI, external behavior, and evidence hygiene.
Apply its Local Style Verification Evidence to every public-PR or PR-backed
local-candidate Formal Review.
@@ -128,8 +141,7 @@ A candidate may become a blocking issue only when all five
conditions hold:
inspect setup, wrappers, earlier calls, generators, and consuming runtime.
3. `Counter-evidence`: check the strongest evidence that could disprove the
finding, especially author or maintainer replies and version-specific facts.
-4. `Necessity`: the requested change is required for safety or correctness in
- the selected focus, not merely cleaner or preferable.
+4. `Necessity`: the requested change is required for safety, correctness, or
an applicable repository design or contract rule in the selected focus, not
merely cleaner or preferable.
5. `Scope`: this PR causes the problem, exposes it through behavior it owns, or
must address it to satisfy the linked issue.
@@ -146,7 +158,7 @@ If authoritative scope cannot be established, state the
exact unavailable scope
## Behavior Clusters and Risk Triage
-Map every substantive file to the smallest meaningful behavior cluster and
identify each cluster's root cause, owner, entry paths, consumers, contracts,
changed decisions, and validation points. Account explicitly for churn-only
files.
+Map every substantive file to the smallest meaningful behavior cluster and
identify each cluster's root cause, owner, entry paths, consumers, contracts,
project-commitment delta, changed decisions, and validation points. Account
explicitly for churn-only files.
Triage functional boundaries, ownership and shared contracts, compatibility
and rollback, test validity, concurrency and performance, security and
operations, dependencies, packaging, and generated artifacts. Read only the
triggered sections of [high-risk-review.md](references/high-risk-review.md).
Also read [sql-parser-review.md](references/sql-parser-review.md) for SQL
grammar, visitors, parser tests, syntax documentation, dialect behavior, or
parser baselines.
@@ -155,14 +167,15 @@ Triage functional boundaries, ownership and shared
contracts, compatibility and
Apply this workflow to the canonical review basis without letting output mode
or a previous result influence the assessment:
1. Complete `Repository Code Policy References`, then establish the
authoritative effective-candidate scope and applicable requirements.
-2. Confirm the selected review focus and admissible evidence.
-3. Build behavior clusters and complete the mandatory risk triage.
-4. Discover candidates across the complete scope through three lenses: root
cause and behavior; blast radius and contracts; tests, runtime, and operations.
-5. Apply the Finding Proof Gate to every candidate. Keep discovery notes
+2. Complete the Problem and Project Commitment Gate and establish the accepted
behavior boundary.
+3. Confirm the selected review focus and admissible evidence.
+4. Build behavior clusters and complete the mandatory risk triage.
+5. Discover candidates across the complete scope through three lenses: root
cause and behavior; blast radius and contracts; tests, runtime, and operations.
+6. Apply the Finding Proof Gate to every candidate. Keep discovery notes
private and classify every candidate before publication.
-6. Complete the Mandatory Style Verification Gate for a public PR or PR-backed
local candidate.
-7. Consolidate findings by independent fix boundary and identify any gap that
could change the blocker set.
-8. Review the latest delta and run a full-scope convergence pass. If it finds
a new independent candidate, return to step 5; otherwise freeze the assessment
after the Completion Gate.
+7. Complete the Mandatory Style Verification Gate for a public PR or PR-backed
local candidate.
+8. Consolidate findings by independent fix boundary and identify any gap that
could change the blocker set.
+9. Review the latest delta and run a full-scope convergence pass. If it finds
a new independent candidate, return to step 6; otherwise freeze the assessment
after the Completion Gate.
If an outcome-sensitive decisive fact passes the Review Incomplete Proof Gate,
return the mode-appropriate incomplete result.
Otherwise continue the review or request a split; do not produce a complete
verdict from a partial review.
@@ -192,9 +205,7 @@ evaluation:
1. If the gate fails because a gap satisfies the Review Incomplete Proof Gate,
use `Review Incomplete`, even when some blockers are already confirmed.
2. If the Mandatory Style Verification Gate is incomplete for any applicable
PR-impact file, use `Review Incomplete`, even when some blockers are already
confirmed.
3. If Checkstyle or Spotless fails on an applicable PR-impact file, use `Not
Mergeable` with `Feedback Mode: Change Request`.
-4. If admissible evidence disproves the problem model, expected behavior,
ownership,
- protocol or SQL semantics, compatibility assumption, or solution direction,
- use `Not Mergeable` with `Feedback Mode: Needs Discussion`.
+4. If admissible evidence disproves the problem model, expected behavior,
ownership, protocol or SQL semantics, compatibility assumption, accepted
project commitment, or solution direction, or establishes that a new project
commitment still requires a maintainer decision, use `Not Mergeable` with
`Feedback Mode: Needs Discussion`.
5. If at least one candidate passes the Finding Proof Gate, use `Not Mergeable`
with `Feedback Mode: Change Request`.
6. Otherwise use `Mergeable` for the selected focus.
@@ -254,7 +265,7 @@ For each blocking issue include:
Do not add patch-level changes after selecting Needs Discussion.
Do not include placeholder headings.
-In `### Coverage`, report the candidate type, reviewed baseline or head,
authoritative requirements and files accounted for, behavior clusters,
completed discovery lenses, unresolved gaps, and CI scope.
+In `### Coverage`, report the candidate type, reviewed baseline or head,
authoritative requirements and files accounted for, accepted behavior and
project-commitment basis, behavior clusters, completed discovery lenses,
unresolved gaps, and CI scope.
For every public PR or PR-backed local candidate, also report the effective
candidate SHA, each style-verification scope and command, each exit code, every
covered applicable PR-impact file, and every `Not Applicable` check with its
basis.
For a standalone local candidate, identify the task baseline and attributed
local delta; for a PR-backed candidate, identify authorized local commits,
index changes, or working-tree changes separately from the public PR state.
In Code Correctness Review, state that the result is code-scope only and CI
was not reviewed while distinguishing the completed local style verification
from CI.
