fix(triage): strengthen PR gate with batch detection, problem existence check, and red flag patterns#5723
Merged
Merged
Conversation
qwen-code-ci-bot
previously requested changes
Jun 22, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Hey @pomelo-nwu — the PR body doesn't follow the PR template. The body uses ## Background and ## What changed instead of the required headings: ## What this PR does, ## Why it's needed, ## Reviewer Test Plan, ## Risk & Scope, and ## Linked Issues.
Please update the PR description to match the template. The content is all there — it just needs to be structured under the right headings so reviewers can find what they need.
中文说明
嗨 @pomelo-niju — PR 正文没有按照 PR 模板 填写。当前使用的是 ## Background 和 ## What changed，但模板要求的标题是：## What this PR does、## Why it's needed、## Reviewer Test Plan、## Risk & Scope 和 ## Linked Issues。
请按照模板重新组织 PR 描述。内容都在，只需要放到正确的标题下，方便 reviewer 查阅。
— Qwen Code · qwen3.7-max
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
previously requested changes
Jun 23, 2026
wenshao
reviewed
Jun 23, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
Re-reviewed the latest head 9fabd3ee08b2483f1ab0b2ea1a2676b1291d4f7d. I did not find additional high-confidence issues beyond the existing open review threads.
Verification: GitHub checks are passing/skipped as expected; deterministic changed-file checks reported no findings; git diff --check passed. I am leaving this as a comment rather than an approval because the current review still has unresolved Critical threads around the batch-detection command and auto-close/escalation behavior.
- GPT-5 Codex via Qwen Code /review
wenshao
reviewed
Jun 23, 2026
Collaborator
|
@qwen-code /triage |
qwen-code-ci-bot
previously requested changes
Jun 23, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Hi @pomelo-nwu — thanks for the contribution! The PR body doesn't follow the PR template. Required headings are missing:
## What this PR does## Why it's needed## Reviewer Test Plan(with How to verify, Evidence, Tested on)## Risk & Scope## Linked Issues
The current body uses ## Background and ## What changed instead. Could you restructure to match the template? It helps reviewers (and the triage gate) evaluate the PR consistently.
The motivation and changes are clear from the description — this is just a formatting pass to align with the project's review workflow.
嗨 @pomelo-nwu — 感谢贡献！PR body 没有按照 PR 模板 填写，缺少以下必需标题：
## What this PR does## Why it's needed## Reviewer Test Plan（含 How to verify、Evidence、Tested on）## Risk & Scope## Linked Issues
当前使用的是 ## Background 和 ## What changed。请按模板结构调整一下，方便 reviewer 和 triage gate 统一评估。
动机和改动内容从描述里看得很清楚——只是格式上对齐一下项目的 review 流程。
— Qwen Code · qwen3.7-max
wenshao
previously approved these changes
Jun 23, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed the latest head c7b69e93. The follow-up commit resolves the earlier review threads: the Stage 0 batch-detection jq filter now parses timestamps with fromdateiso8601 / now - 604800 (verified working end-to-end against gh's gojq engine), --state open matches the "open PRs" prose, the Stage 3 reflection threshold is aligned to 3+, and the terminal-exit list now includes the problem-existence stop. The sub-stage renumbering (1b→1c, 1c→1d) has no dangling references elsewhere. No new blocking issues. The remaining open Suggestion threads (batch-handling phrasing, "no reproduction = no fix" absolutism) are non-blocking doc-wording calls at the author's discretion. LGTM! ✅
— claude-opus-4-8[1m] via Qwen Code /qreview
Collaborator
CI "failure" is a transient checkout race, not a code/test problem — just re-run the jobThe red Test (ubuntu-latest) job did not fail on a test. Looking at the job steps, it failed at step 2, The actual error (from the Checkout step):
GitHub regenerates Why this is infra, not your change:
Action: none on the PR. Just Re-run failed jobs — the merge ref is stable now, so checkout will succeed. No rebase or code change is needed. 中文版这个 CI "失败"是一次短暂的 checkout 竞态，不是代码/测试问题 —— 重跑该 job 即可红的 Test (ubuntu-latest) job 并不是测试挂了。看 job 的步骤，它挂在第 2 步 真正的报错（来自 Checkout 步骤）：
GitHub 在目标分支推进时会异步重新生成 为什么这是基础设施问题，而不是你的改动：
该怎么做： PR 这边无需任何改动。直接 Re-run failed jobs 即可 —— merge ref 现在已经稳定，checkout 会成功。不需要 rebase，也不需要改代码。 |
pomelo-nwu
force-pushed
the
fix/triage-gate-anti-noise
branch
from
June 23, 2026 05:25
eed53c7 to
d8397eb
Compare
qwen-code-ci-bot
previously requested changes
Jun 23, 2026
qwen-code-ci-bot
previously requested changes
Jun 23, 2026
qwen-code-ci-bot
previously requested changes
Jun 24, 2026
wenshao
reviewed
Jun 25, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
[Suggestion] Terminal gate exception (lines 22-24) is now stale
The "Terminal gate exception" paragraph says "if Stage 1a template check fails, submit exactly one CHANGES_REQUESTED review and stop" as the sole terminal gate. This PR adds two more terminal exits — Stage 0b Tier 1 (hard block) and Stage 1b (problem does not exist) — but neither is listed in this exception.
The terminal exits summary after the Stage 1 comment (lines 157-161) correctly enumerates all three, but the Comment Management section at the top still only accounts for Stage 1a. Consider updating lines 22-24 to enumerate all terminal exits, or referencing the summary at lines 157-161 as the authoritative list.
— qwen3.7-max via Qwen Code /review
wenshao
previously requested changes
Jun 26, 2026
Collaborator
Author
|
Pushed commit Fixed:
Moot — Stage 0 batch detection was removed entirely in commit Declined (by design):
Resolving all review threads now. 中文推送了 commit
Stage 0 batch detection 已在 正在 resolve 所有 review threads。 |
pomelo-nwu
dismissed stale reviews from qwen-code-ci-bot, qwen-code-ci-bot, qwen-code-ci-bot, qwen-code-ci-bot, qwen-code-ci-bot, qwen-code-ci-bot, and wenshao
June 29, 2026 06:20
Review threads resolved in commit 494e8f6
Collaborator
Author
|
@wenshao All review threads have been resolved and the CHANGES_REQUESTED reviews dismissed. The PR now needs one approval to merge. Could you re-review and approve if the changes look good? The latest commit
中文所有 review threads 已 resolve，CHANGES_REQUESTED reviews 已 dismiss。PR 现在只需要一个 approval 就能合并。能否 re-review 一下，如果改动没问题就 approve？ |
qwen-code-ci-bot
previously requested changes
Jun 29, 2026
Add Stage 0b that flatly rejects community-contributed refactor PRs touching core infrastructure (packages/core, auth, providers, models, config, tools, services). No exceptions — core refactors must be maintainer-initiated with prior design discussion. Triggered by PR #5089: 75-file refactor across core/auth/providers/models that should never have been accepted from a community contributor.
…approving The meta-principle: 'the direction looks correct' is the most dangerous sentence in triage — it means the gate understood intent but not impact. For core module changes, the gate must name every downstream consumer; if it cannot, escalate to maintainer. 100% confidence or escalate. Updated both pr-workflow.md (Stage 0b) and AGENTS.md (Working Principles).
Previous version asked the gate to 'assess whether it understands the impact' — too soft, AI will always rationalize that it understands enough. New version: non-maintainer + core paths = instant reject. No evaluation, no thinking, no exceptions. The gate is not qualified to judge core refactors. Period.
…dence for small
Large-scope core changes (10+ files / 500+ lines) are a hard block — no
evaluation, no exceptions. Small-scope core changes may proceed only if
the gate is 100% confident; any doubt triggers maintainer escalation.
Previous versions were either too soft ('assess your understanding') or
too blunt ('all non-maintainer core PRs rejected'). Two-tier approach
allows legitimate small bugfixes through while walling off refactors.
…lways returns empty for human contributors Co-authored-by: Qwen-Coder <[email protected]>
- Fix "Closing" vs "request changes" inconsistency in Stage 1b template (both EN and CN) — align with terminal exits list - Add Stage 0b to terminal exits list and terminal gate exception - Add gh pr review command to Tier 1 hard block (was missing delivery mechanism) - Clarify Tier 1 "500+ lines" as additions + deletions combined - Add maintainer-authored exception to Tier 1 hard block - Use concrete path patterns for core infrastructure definition - Fix dangling Stage 0 reference in Stage 3 reflection (Stage 0 was removed) - Scope AGENTS.md core rule to triage gate, add cross-package changes to definition
… to exits - Rename "Stage 0b" to "Stage 0" (no more Stage 0a since batch detection was removed) - Fix ambiguous "close" in Stage 1b → "leave for maintainer to decide" (agent recommends, maintainer executes gh pr close) - Add explicit stage labels to all terminal exits (Stage 0, 1a, 1b, 1c)
wenshao: a low-risk sweep (rename, import-path update, lint/format autofix, a repeated null-guard) can touch 10+ core files while changing a line or two each, yet the 'OR 10+ files' trigger hard-blocked it with 'open an issue to discuss', while a deep risky rewrite under 10 files slipped into the lenient Tier 2 path. Breadth was treated as risk; depth was ignored. Make the hard block fire on size alone (500+ changed lines), which still catches a deep rewrite concentrated in a few files. Route pure file-count breadth to maintainer escalation / Tier 2 judgement on the actual diff instead of an auto-reject. Co-Authored-By: Qwen-Coder <[email protected]>
…cross files - Stage 1b: replace vague 'leave for maintainer to decide' with concrete escalate-to-maintainer + stop (no Stage 2), matching the escalation vocabulary used in Stage 1c/Stage 3. - AGENTS.md: clarify that a file-breadth sweep is escalated for awareness and otherwise judged under Tier 2's 100%-confidence bar, aligning with pr-workflow.md's Breadth-ne-size paragraph (removes terminal-stop ambiguity). Co-Authored-By: Qwen-Coder <[email protected]>
…ate/size wording - Drop the `<If problem does not exist:>` Stage 1 comment branch: it is a terminal exit that submits a CHANGES_REQUESTED review and must not also post a Stage 1 comment, so the template branch was unreachable. - Reword the breadth-sweep case to "flag for the maintainer's awareness" so "escalate" consistently means stop/hand-off across the file. - Clarify AGENTS.md 500-line threshold as additions + deletions combined, matching pr-workflow.md. Co-authored-by: Qwen-Coder <[email protected]>
pomelo-nwu
force-pushed
the
fix/triage-gate-anti-noise
branch
from
July 1, 2026 23:33
b1ded00 to
d6cb1bc
Compare
Contributor
|
Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. 中文请勿对活跃的 PR 执行 rebase 或 force-push，因为这会使已有的评审评论失效。另外，供日后参考：作为集成流程的一部分，机器人始终会自动将所有改动压缩（squash）为单个提交。 |
…e-out, Tier 2 wording, AGENTS.md exemption - Add concrete gh pr review --request-changes command block with body template and <!-- qwen-triage stage=1b --> marker to Stage 1b, matching every other terminal gate's invocation pattern. - Add terminal-exit review carve-out to re-runs section: PR reviews cannot be edited via PATCH API, so on re-run check for existing CHANGES_REQUESTED review before re-submitting. - Fix Tier 2 precondition wording: 'Small-scope' → 'below 500-line threshold' and 'fewer files' → 'few files, or a breadth-sweep flagged above' so the breadth carve-out PRs are not excluded by the Tier 2 description alone. - Fix AGENTS.md 'No evaluation, no exceptions' → 'Skip evaluation entirely — the maintainer exemption above is the sole exception' to eliminate the apparent contradiction with the parenthetical maintainer exemption.
Collaborator
Author
|
Addressed all 4 open review threads in
All conversations resolved. CI was green before this push; awaiting re-run on the new head. 中文说明在 c6dc5d0 中处理了所有 4 个 review thread：
所有对话已 resolve。 |
pomelo-nwu
dismissed
qwen-code-ci-bot’s stale review
July 2, 2026 05:34
All review threads from this review have been resolved and addressed in c6dc5d0. Dismissing to allow re-review on new head.
Collaborator
|
@qwen-code /triage |
yiliang114
enabled auto-merge
July 3, 2026 16:25
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: the 2026-06-22 batch incident (20 PRs in a day, 11 noise) is a documented, observed event — not theoretical. The broken jq date filter ( Direction: squarely aligned. This PR improves the project's own triage gate — the tool eating its own dogfood. Gate philosophy, core module protection, and problem existence checks are all directly relevant to preventing the documented failure mode. Approach: scope feels right. 120+10 across 2 markdown files, focused on the stated goal. The Gate Philosophy section, Stage 0, Stage 1b, terminal exits list, and Stage 3 reflection questions each address a specific gap identified in the batch incident. No drive-by refactors or scope creep. The AGENTS.md addition mirrors pr-workflow.md Stage 0 — some duplication, but intentional (AGENTS.md for general guidance, pr-workflow.md for the workflow). Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：2026-06-22 批量事件（一天 20 个 PR，11 个噪音）是有记录的已观测事件，不是理论性假设。jq 日期过滤器 bug（ 方向：完全对齐。这个 PR 改进的是项目自身的 triage gate——自己吃自己的狗粮。Gate Philosophy、核心模块保护、问题存在性检查都直接针对已记录的失败模式。 方案：范围合理。2 个 markdown 文件，120+10 行，聚焦于声明的目标。Gate Philosophy、Stage 0、Stage 1b、terminal exits 列表、Stage 3 反思问题——每一项都针对批量事件中识别出的具体缺口。没有夹带无关改动。AGENTS.md 新增内容与 pr-workflow.md Stage 0 有一定重复，但是有意为之（AGENTS.md 用于通用指引，pr-workflow.md 用于工作流）。 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
Collaborator
Code ReviewThis is a prompt-only change (2 markdown files, no code paths). The structural review focuses on prompt correctness and control flow. The gate workflow is well-structured: Gate Philosophy → Stage 0 (core protection) → Stage 1 (1a template → 1b problem existence → 1c direction → 1d solution) → Stage 2 → Stage 3. Each stage has clear terminal exits, and the re-run mechanism correctly accounts for PR reviews being non-editable via the GitHub API. Two minor observations (non-blocking):
No correctness bugs, no security issues, no AGENTS.md violations. The control flow fixes (jq date filter, terminal exits list, re-run handling) are all sound. TestingN/A — prompt-only change to markdown files. No user-visible behavior to test via tmux. CI passes (Test ubuntu-latest ✓, Coverage ✓, Classify PR ✓). 中文说明代码审查纯 prompt 改动（2 个 markdown 文件，无代码路径）。结构审查聚焦于 prompt 正确性和控制流。 Gate 工作流结构清晰：Gate Philosophy → Stage 0（核心保护）→ Stage 1（1a 模板 → 1b 问题存在 → 1c 方向 → 1d 方案）→ Stage 2 → Stage 3。每个阶段都有明确的 terminal exits，re-run 机制正确处理了 PR reviews 不可编辑的 API 限制。 两个小观察（非阻塞）：
无正确性 bug，无安全问题，无 AGENTS.md 违规。控制流修复（jq 日期过滤器、terminal exits 列表、re-run 处理）都是正确的。 测试N/A — 纯 prompt 改动，无用户可见行为，无法通过 tmux 测试。CI 通过。 — Qwen Code · qwen3.7-max |
Collaborator
|
This PR closes a real gap. The 2026-06-22 batch incident was a clear failure mode — the gate asked "is the direction correct?" but never "does this problem exist?", and 11 noise PRs sailed through. The root cause analysis is honest, and the fix directly addresses it. The implementation is disciplined. Gate Philosophy sets the tone without being preachy. Stage 0's two-tier approach (hard block at 500+ lines, 100% confidence below) is the right balance — it doesn't auto-reject breadth-sweeps, which is the correct call. Stage 1b's problem existence check is the load-bearing change: it forces the gate to distinguish observed failures from theoretical hardening before evaluating direction. The terminal exits list and re-run handling are solid control flow fixes. The three new Stage 3 reflection questions ("did I verify the problem exists?", "is this part of a pattern?", "am I being a pushover?") are the kind of self-check that prevents future rubber-stamping incidents. Good instinct. Minor concerns noted in Stage 2 (inline The PR has been through multiple rounds of review already, all threads resolved, CI is green. Ready to ship. 中文说明这个 PR 补上了一个真实的缺口。2026-06-22 批量事件是一个明确的失败模式——gate 问"方向对不对"但从没问"这个问题存在吗"，11 个噪音 PR 全部通过。根因分析诚实，修复直接对症。 实现很克制。Gate Philosophy 定调但不过度说教。Stage 0 的两层方案（500+ 行硬拦，以下用 100% 信心评估）是正确的平衡——不因为文件多就自动拦截 breadth-sweep，这是对的选择。Stage 1b 的问题存在性检查是核心改动：它强制 gate 在评估方向之前，区分已观测故障和理论性加固。Terminal exits 列表和 re-run 处理是扎实的控制流修复。 Stage 3 新增的三个反思问题（"我验证了问题存在吗？""这是不是一系列 PR 中的一个？""我是不是太好说话了？"）是防止未来 rubber-stamping 的有效自查。直觉很好。 Stage 2 提到的小问题（inline PR 已经过多轮 review，所有 threads 已 resolve，CI 全绿。可以合并。 — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
approved these changes
Jul 3, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
Collaborator
|
Flow view for the updated triage gate: Direct image links: CDN · GitHub file This captures the intended process-level behavior: Stage 0 core module protection, Stage 1a template gate, Stage 1b problem-existence gate, Stage 1c/1d direction and approach review, then Stage 2/3 review and verdict. From the workflow perspective, this is the right direction: it moves triage earlier, makes the burden of proof explicit for community PRs, and keeps maintainer escalation available for core or unclear changes instead of spending full review cycles on PRs that are not ready to be reviewed. |
yiliang114
approved these changes
Jul 3, 2026
yiliang114
left a comment
yiliang114
left a comment
Collaborator
There was a problem hiding this comment.
Approving from the process-flow perspective. This strengthens the community PR gate in the right place: core changes are protected, theoretical fixes need evidence before deep review, and unclear or risky direction escalates to maintainers instead of being rubber-stamped.
The resulting flow is stricter, but still pragmatic: small, well-evidenced fixes can proceed, while high-risk or low-proof changes stop before consuming a full review cycle.
qwen-code-ci-bot
requested changes
Jul 3, 2026
|
|
||
| ```bash | ||
| # Check for existing terminal-exit review before re-submitting | ||
| EXISTING=$(gh api "repos/$REPO/pulls/$PR_NUMBER/reviews" \ |
Collaborator
There was a problem hiding this comment.
[Critical] The EXISTING filter is stage-agnostic — it matches ANY CHANGES_REQUESTED review from the bot regardless of which terminal exit produced it. If the author fixes a Stage 1a issue (template) but the re-run triggers Stage 1b (no reproduction), the new Stage 1b review is silently skipped. The author only sees the stale Stage 1a complaint.
Suggested change
| EXISTING=$(gh api "repos/$REPO/pulls/$PR_NUMBER/reviews" \ | |
| # Check for existing terminal-exit review, scoped by stage marker | |
| EXISTING=$(gh api "repos/$REPO/pulls/$PR_NUMBER/reviews" \ | |
| --jq '[.[] | select(.user.login=="qwen-code-ci-bot" and .state=="CHANGES_REQUESTED")] | length') | |
| # If a prior terminal review exists, dismiss it before re-evaluating | |
| if [ "$EXISTING" -gt 0 ]; then | |
| REVIEW_ID=$(gh api "repos/$REPO/pulls/$PR_NUMBER/reviews" \ | |
| --jq '[.[] | select(.user.login=="qwen-code-ci-bot" and .state=="CHANGES_REQUESTED")] | last | .id') | |
| gh api -X PUT "repos/$REPO/pulls/$PR_NUMBER/reviews/$REVIEW_ID/dismissals" \ | |
| -f message="Re-evaluating after author updates" | |
| fi |
— qwen3.7-max via Qwen Code /review
|
|
||
| Default posture: **skepticism**. Burden of proof is on the author. Distinguish **observed failures** (linked issue, reproduction, before/after) from **theoretical hardening** ("could theoretically send X" with no evidence it ever has). Volume ≠ value — an AI bot can produce 20 plausible PRs in a day. If being "too strict" feels uncomfortable, that is the gate working correctly. | ||
|
|
||
| ### Stage 0: Core Module Protection (two-tier check) |
Collaborator
There was a problem hiding this comment.
[Critical] "skip this check if the author is a known maintainer" has no deterministic verification mechanism — no gh api call, no allowlist, no collaborator permission check. The LLM agent must guess who qualifies based on context clues (profile bio, display name, comment history). This is the most protective gate in the workflow, and its bypass condition is undefined.
Suggested change
| ### Stage 0: Core Module Protection (two-tier check) | |
| **Tier 1 — Large-scope changes to core → HARD BLOCK.** Applies to non-maintainer PRs only. Check maintainer status: | |
| ```bash | |
| IS_MAINTAINER=$(gh api "repos/$REPO/collaborators/$PR_AUTHOR/permission" --jq '.permission' 2>/dev/null) | |
| # Only "admin" or "maintain" qualifies for exemption |
Skip Tier 1 if $IS_MAINTAINER is admin or maintain. Hard-block on size, not breadth:
_— qwen3.7-max via Qwen Code /review_
| ``` | ||
|
|
||
| Then **stop**. This is a wall, not a guideline. | ||
|
|
Collaborator
There was a problem hiding this comment.
[Critical] The breadth-sweep exception says "let it proceed to Stage 1" for PRs touching 10+ files with a line or two each. But 25 files × 25 lines = 625 lines, which exceeds the 500-line Tier 1 hard block ("reject immediately. No evaluation, no Stage 1"). An agent reading both paragraphs gets contradictory instructions: the breadth paragraph says "proceed to Stage 1" while Tier 1 says "reject, no Stage 1."
Suggested clarification: "The breadth exception applies only when total core-path lines stay under 500. A breadth sweep exceeding 500 total lines is still a Tier 1 hard block regardless of per-file line count."
— qwen3.7-max via Qwen Code /review
| Never create duplicates. For terminal-exit reviews (submitted via | ||
| `gh pr review --request-changes`), the GitHub API does not support editing PR | ||
| reviews. On re-run: check if a `CHANGES_REQUESTED` review from the bot already | ||
| exists — if it does, skip re-submitting (the existing review already gates the |
Collaborator
There was a problem hiding this comment.
[Suggestion] The workflow says "the GitHub API does not support editing PR reviews" and only provides re-run dedup logic (skip re-submitting). But there's no mechanism to dismiss stale CHANGES_REQUESTED reviews when the author addresses the concerns. The bot's review stays as a permanent gate until a human maintainer manually dismisses it. GitHub's API supports dismissal via PUT .../reviews/$REVIEW_ID/dismissals.
Consider adding dismissal logic to the re-run section so the bot cleans up its own stale reviews before re-evaluating.
— qwen3.7-max via Qwen Code /review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Adds two new checks to the PR triage gate and fixes several control flow bugs in the gate prompt (
pr-workflow.md):Bug fixes from review feedback:
"7 days ago"string comparison was always false) and--state all/--state openmismatch.Why it's needed
On 2026-06-22, a high-volume automated contributor submitted 20 PRs in a single day. 11 of them were validation noise — "reject fractional maxConnections", "require integer read_file ranges", "validate sessions list limit" — each individually plausible, each collectively a waste of maintainer attention. Our PR triage gate approved all of them.
The root cause: the gate asked "is the direction correct?" — a question every one of these PRs could pass, because "rejecting invalid values" sounds reasonable. It never asked the harder question: "does this problem actually exist?" Nobody ever passed
maxConnections: 1.5. The runtime already coerced or rejected these values. The PRs were schema hygiene dressed up as bug fixes, and the gate waved them through.This PR closes that gap: the gate now checks problem existence before direction, and detects batch patterns before individual review.
Reviewer Test Plan
This is a prompt-only change (no code paths affected). Verification is by reading the modified
pr-workflow.mdand confirming the gate logic is correct.How to verify
.qwen/skills/triage/references/pr-workflow.mdand confirm the Stage 0 jq command returns correct results (the old"7 days ago"string comparison was always false).Evidence (Before & After)
N/A — prompt-only change, no user-visible behavior.
Tested on
Environment (optional)
N/A
Risk & Scope
Linked Issues
Related to the 2026-06-22 batch incident (no specific issue filed).
中文说明
这个 PR 做了什么
在 PR triage gate 中新增两项检查，并修复 gate prompt（
pr-workflow.md）中的多个控制流 bug：来自 review 反馈的 bug 修复：
"7 days ago"字符串比较永远返回 false）以及--state all/--state open不一致。为什么需要
2026-06-22，一个高频自动贡献者在一天内提交了 20 个 PR。其中 11 个是验证噪音——"拒绝小数 maxConnections"、"要求整数 read_file 范围"、"验证 sessions list limit"——每个单独看都合理，合在一起是浪费 maintainer 时间。我们的 PR triage gate 全部放行。
根因：gate 问的是"方向对不对"——这些 PR 都能过，因为"拒绝非法值"听起来没毛病。但从未问更难的问题："这个问题实际存在吗？" 没人传过
maxConnections: 1.5，运行时已经 coerce 或拒绝了这些值。这些 PR 是把 schema 洁癖包装成 bug fix，gate 全部放行。这个 PR 补上了这个缺口：gate 现在在方向 review 之前检查问题存在性，在逐个 review 之前检测批量模式。
Reviewer 测试计划
纯 prompt 改动（不影响代码路径）。验证方式是阅读修改后的
pr-workflow.md确认 gate 逻辑正确。如何验证
.qwen/skills/triage/references/pr-workflow.md，确认 Stage 0 的 jq 命令能返回正确结果（旧的"7 days ago"字符串比较永远返回 false）。证据（改进前 vs 改进后）
N/A — 纯 prompt 改动，无用户可见行为变化。
测试环境
环境（可选）
N/A
风险与范围
关联 Issue
关联 2026-06-22 批量事件（未单独建 issue）。
Refs #3957