From 34a0c1c5030b03fe77a511e31087b12f237e8602 Mon Sep 17 00:00:00 2001 From: wenshao Date: Fri, 24 Jul 2026 12:32:57 +0800 Subject: [PATCH 1/6] docs(triage): scale PR verification to the change, add real-run depth /triage already drives a real tmux before/after (installed vs dev build). But where it matters most that floor is not enough: a UI change's highlight/caret is invisible in capture-pane text, build/test numbers from a shared or symlinked tree can be environmental TS errors not the PR's, and a perf claim went unmeasured. Strengthen Stage 2b to scale the evidence to the change, pointing at harnesses the repo already ships: the terminal-capture skill (node-pty -> xterm.js -> pixel-accurate PNG) for UI/interaction changes with a named on-screen oracle; a clean build for the numbers cited as evidence (a symlinked node_modules surfaces spurious cross-package TS errors); instrumenting the real built code for a measured before/after on perf changes; and separating merge-blockers from standing follow-ups with a reproducible methodology note. Docs/refactor PRs stay N/A. --- .qwen/skills/triage/references/pr-workflow.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index 309415252d5..69489b3ce24 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -368,6 +368,34 @@ tmux kill-session -t "$S" - Cannot run after exhausting workarounds → FAIL, not skip. - Fork code: sandbox (strip write tokens/secrets). +**Scale the evidence to the change** — the tmux before/after above is the floor, +not the ceiling. Match the depth to what is actually under review: + +- **UI / styling / interaction changes** (color, highlight, cursor position, or + layout is the thing being reviewed): `capture-pane` text cannot show which + item is highlighted or where the caret block sits. Use the `terminal-capture` + skill (node-pty → xterm.js → pixel-accurate PNG; it needs + `npx playwright install chromium` — install on demand if absent). Whatever the + medium, name the **oracle**: the exact on-screen element that proves the + behavior ("the highlighted pill is the active tab; the filtered list is the + oracle for which tab is active"), and show the state before AND after the + action so the change is _visible_, not asserted. +- **Build / typecheck / test numbers you cite as evidence**: get them from a + clean state, not a shared or symlinked `node_modules` — a contaminated tree + surfaces spurious cross-package `TS2307`/`TS2353` errors that are + environmental, not the PR's. Report such errors as environmental and never as + a PR defect; a clean install is what makes the counts trustworthy. +- **Performance changes**: behavioral before/after is not enough — measure it. + Instrument the REAL built code (wrap the hot path, e.g. `node:fs`), run the + old path vs the new, and report concrete numbers (calls, disk walks, ms). + "Faster" must be a measurement, not a claim. + +A docs / types / refactor PR needs none of this — say `N/A` when nothing is +user-visible. When the verification was non-trivial, separate merge-BLOCKERS +from standing, non-blocking follow-ups (a pre-existing gap, a platform caveat, a +nit), and add a one-paragraph methodology note (environment, how you drove it) +so the maintainer can trust and reproduce it. + Post a single Stage 2 comment (must include `` at the top), in this order: code review findings → optional sequence diagram (2a-bis) → optional changed-files overview (2a-bis) → real-scenario testing result (below) → the bilingual `
` Chinese summary → signature + footer last (the same tail order as the Stage 1 template). Include the two enrichments only when 2a-bis says they earn their place; a small, focused PR is just findings + testing. **⛔ BEFORE POSTING: verify your comment contains the tmux output.** Read back through your draft — does it have a fenced code block with the actual terminal capture? If not, add it now. The maintainer cannot approve without seeing what actually happened. From 318283aa2098500ed66d04362002567850c9dd2a Mon Sep 17 00:00:00 2001 From: qwen-code-ci-bot Date: Fri, 24 Jul 2026 06:09:56 +0000 Subject: [PATCH 2/6] docs(triage): align Mandatory and BEFORE POSTING checks with N/A escape hatch (#7648) --- .qwen/skills/triage/references/pr-workflow.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index 69489b3ce24..710f42ca975 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -339,7 +339,7 @@ Two more escaping notes: `` shows HTML entities literally but GFM **still **Runs in the main working tree, not the worktree** — tmux needs the local build environment. -**Mandatory.** Unit tests don't substitute. Unrelated build failure ≠ excuse to skip. +**Mandatory** for PRs with user-visible behavioral changes. Unit tests don't substitute. Unrelated build failure ≠ excuse to skip. **⛔ The tmux output IS the review.** The maintainer reads your Stage 2 comment and decides approve/reject from it. You **must** paste the actual `capture-pane` terminal output inline in the comment — inside a fenced code block. Not a file path, not "see attached log", not a text summary. If you didn't inline the output, the review is worthless. @@ -398,7 +398,7 @@ so the maintainer can trust and reproduce it. Post a single Stage 2 comment (must include `` at the top), in this order: code review findings → optional sequence diagram (2a-bis) → optional changed-files overview (2a-bis) → real-scenario testing result (below) → the bilingual `
` Chinese summary → signature + footer last (the same tail order as the Stage 1 template). Include the two enrichments only when 2a-bis says they earn their place; a small, focused PR is just findings + testing. -**⛔ BEFORE POSTING: verify your comment contains the tmux output.** Read back through your draft — does it have a fenced code block with the actual terminal capture? If not, add it now. The maintainer cannot approve without seeing what actually happened. +**⛔ BEFORE POSTING: verify your comment contains the tmux output** (or the `N/A` substitution for docs/types/refactor PRs with nothing user-visible). Read back through your draft — does it have a fenced code block with the actual terminal capture? If not, add it now. The maintainer cannot approve without seeing what actually happened. ````markdown ## Before (installed build) From 5c26c92c07f86fcb2e9efa657c5a16f01bdcda74 Mon Sep 17 00:00:00 2001 From: qwen-code-ci-bot Date: Fri, 24 Jul 2026 08:05:08 +0000 Subject: [PATCH 3/6] docs(triage): add N/A escape hatch to the tmux-output mandate (#7648) --- .qwen/skills/triage/references/pr-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index 2a5e422ab14..d39c96b282f 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -392,7 +392,7 @@ maintainer can trigger it. Everything below applies to local invocation (no **Mandatory on local runs, for PRs with user-visible behavioral changes.** Unit tests don't substitute. Unrelated build failure ≠ excuse to skip. -**⛔ The tmux output IS the review.** The maintainer reads your Stage 2 comment and decides approve/reject from it. You **must** paste the actual `capture-pane` terminal output inline in the comment — inside a fenced code block. Not a file path, not "see attached log", not a text summary. If you didn't inline the output, the review is worthless. +**⛔ The tmux output IS the review** (for PRs with user-visible behavioral changes). The maintainer reads your Stage 2 comment and decides approve/reject from it. You **must** paste the actual `capture-pane` terminal output inline in the comment — inside a fenced code block — **or state `N/A` for docs/types/refactor PRs with nothing user-visible**. Not a file path, not "see attached log", not a text summary. If you didn't inline the output (or the N/A substitution), the review is worthless. Drive the real product in tmux, using the `tmux-real-user-testing` skill. Capture the terminal at key moments with `capture-pane` — these are the evidence that makes the review actionable. From e4f5fbe02d265b9a4c8da723950720e5fbb74255 Mon Sep 17 00:00:00 2001 From: qwen-code-ci-bot Date: Fri, 24 Jul 2026 08:52:18 +0000 Subject: [PATCH 4/6] docs(triage): restate CI boundary and fork-sandbox ref in scale-evidence block (#7648) --- .qwen/skills/triage/references/pr-workflow.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index d39c96b282f..f77eb7e8b45 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -422,14 +422,14 @@ tmux kill-session -t "$S" never attempt this; see 2b/2c scoping above.) - Fork code: sandbox (strip write tokens/secrets). -**Scale the evidence to the change** — the tmux before/after above is the floor, +**Scale the evidence to the change** (local runs only — never in unattended CI) — the tmux before/after above is the floor, not the ceiling. Match the depth to what is actually under review: - **UI / styling / interaction changes** (color, highlight, cursor position, or layout is the thing being reviewed): `capture-pane` text cannot show which item is highlighted or where the caret block sits. Use the `terminal-capture` skill (node-pty → xterm.js → pixel-accurate PNG; it needs - `npx playwright install chromium` — install on demand if absent). Whatever the + `npx playwright install chromium` — install on demand if absent; on fork PRs, sandbox per the fork-code bullet above). Whatever the medium, name the **oracle**: the exact on-screen element that proves the behavior ("the highlighted pill is the active tab; the filtered list is the oracle for which tab is active"), and show the state before AND after the From 986f2c4f206d82c06ef16520cf67ffff210d112d Mon Sep 17 00:00:00 2001 From: Qwen Code Date: Fri, 24 Jul 2026 10:33:35 +0000 Subject: [PATCH 5/6] docs(triage): align tmux summary table and SKILL.md with conditional mandate (#7648) --- .qwen/skills/triage/SKILL.md | 8 +++++--- .qwen/skills/triage/references/pr-workflow.md | 10 +++++----- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/.qwen/skills/triage/SKILL.md b/.qwen/skills/triage/SKILL.md index f5eecf91c02..47479b0b691 100644 --- a/.qwen/skills/triage/SKILL.md +++ b/.qwen/skills/triage/SKILL.md @@ -108,9 +108,11 @@ fetched via the API (`references/pr-workflow.md`, Stage 2b). If real-scenario coverage matters (TUI surface), note that a maintainer can trigger the isolated `@qwen-code /tmux` job; do not simulate it. -**Local invocation** (no `GITHUB_EVENT_NAME`): drive the real product in tmux -and paste the actual capture-pane output inline — not a file path, not "see -attached", not a summary. Without inlined terminal output, the review is +**Local invocation** (no `GITHUB_EVENT_NAME`): for PRs with user-visible +behavioral changes, drive the real product in tmux and paste the actual +capture-pane output inline — not a file path, not "see attached", not a +summary. For docs/types/refactor PRs with nothing user-visible, state `N/A`. +Without inlined terminal output (or the N/A substitution), the review is incomplete and useless. Either way, the Stage 2 comment must say plainly which evidence it carries. diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index f77eb7e8b45..55be5d31fdd 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -13,11 +13,11 @@ capture its ID: COMMENT_ID=$(gh api "repos/$REPO/issues/$PR_NUMBER/comments" -F body=@/tmp/stage-N.md --jq '.id') ``` -| Stage | Comment | -| ------- | ------------------------------------------------------------- | -| Stage 1 | Gate findings | -| Stage 2 | Code review + CI test evidence (+ tmux capture on local runs) | -| Stage 3 | Reflection + verdict | +| Stage | Comment | +| ------- | ------------------------------------------------------------------------------- | +| Stage 1 | Gate findings | +| Stage 2 | Code review + CI test evidence (+ tmux capture on local runs when user-visible) | +| Stage 3 | Reflection + verdict | **Terminal gate exception:** if any terminal exit triggers (Stage 0 core module hard block, Stage 1a template failure, Stage 1b problem-does-not-exist, From e50f242a075a06d034efce11f9dcb01cabda7285 Mon Sep 17 00:00:00 2001 From: qwen-code-ci-bot Date: Fri, 24 Jul 2026 12:00:56 +0000 Subject: [PATCH 6/6] docs(triage): extend BEFORE POSTING gate to check evidence depth per PR type (#7648) --- .qwen/skills/triage/references/pr-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.qwen/skills/triage/references/pr-workflow.md b/.qwen/skills/triage/references/pr-workflow.md index 55be5d31fdd..fe8b323cd24 100644 --- a/.qwen/skills/triage/references/pr-workflow.md +++ b/.qwen/skills/triage/references/pr-workflow.md @@ -452,7 +452,7 @@ so the maintainer can trust and reproduce it. Post a single Stage 2 comment (must include `` at the top), in this order: code review findings → optional sequence diagram (2a-bis) → optional changed-files overview (2a-bis) → CI test evidence (2b) → real-scenario testing result when one was driven locally (2c) → the bilingual `
` Chinese summary → signature + footer last (the same tail order as the Stage 1 template). Include the two enrichments only when 2a-bis says they earn their place; a small, focused PR is just findings + testing. -**⛔ BEFORE POSTING: verify the testing section carries real evidence.** Read back through your draft. In CI: does it quote actual check names and conclusions (and the failing job's log excerpt when red)? On a local run: does it have a fenced code block with the actual terminal capture (or the `N/A` substitution for docs/types/refactor PRs with nothing user-visible)? If not, fix that now — and never paper over a gap with the author's self-reported results. The maintainer cannot approve without seeing what actually happened. +**⛔ BEFORE POSTING: verify the testing section carries real evidence.** Read back through your draft. In CI: does it quote actual check names and conclusions (and the failing job's log excerpt when red)? On a local run: does it have a fenced code block with the actual terminal capture (or the `N/A` substitution for docs/types/refactor PRs with nothing user-visible)? Does the evidence depth match the PR type per “Scale the evidence” above — screenshots for UI changes, measurements for performance claims, clean-state numbers for build/test claims? If not, fix that now — and never paper over a gap with the author's self-reported results. The maintainer cannot approve without seeing what actually happened. ````markdown ## Before (installed build)