fix: fence off bundled out-of-scope requests instead of silently accepting them

plugins/waza/rules/anti-patterns.md

@@ -35,3 +35,4 @@ Always-on behavioral guardrails. These apply regardless of which skill is active
 | 29 | Distribution state collapse | Say "ready", "released", "installed", or "done" after checking source, metadata, or CI, while package contents, installed runtime, release assets, registry, remote deploy, or public thread state is unverified | Report each distribution layer separately. Missing layers are explicit gaps, not implied passes |
 | 30 | Stale request after compaction | After a context compaction or session resume, keep acting on a request left over from earlier in the thread | Re-read the latest user turn after any compaction or resume and confirm the response targets the current request, not already-handled history, before sending |
 | 31 | Overwrite the user's own edits | User hand-edited the file or prose and asked to continue from their version; agent works from its earlier in-context draft and reintroduces wording or code the user deliberately removed | Re-read the user's current file or diff before continuing. Treat their intervening edits as locked intent: preserve their deletions and word choices, build on their version, do not reapply yours |
+| 32 | Silent scope creep on bundled asks | A request bundles an out-of-scope item with in-scope work ("review the diff and polish the release note too"); the agent silently does both | Name the out-of-scope item in one line, with the owning skill if one exists, then complete only the in-scope part. If the owning skill is not installed, say so instead of taking the job |

plugins/waza/skills/check/SKILL.md

@@ -267,7 +267,7 @@ In a dirty or multi-agent checkout, a passing local build or test run is not pro
 
 ## Document Review
 
-For document, PDF, white paper, or prose review, route to `/write` (Document Review Mode). `/check` handles code diffs and release artifacts only.
+For document, PDF, white paper, or prose review, route to `/write` (Document Review Mode). `/check` handles code diffs and release artifacts only. If `/write` is not installed, say the request belongs to `/write` and stop there instead of taking the prose review.
 
 ## Gotchas
 

plugins/waza/skills/health/SKILL.md

@@ -42,6 +42,7 @@ For `/health`: current config, command output, and live probes override memory.
 
 - Summary and deep audits are report-only. Run only Health-owned collectors and read-only probes; a neutral Health request does not authorize project tests, verifiers, generators, builds, formatters, package installers, fixture refreshes, or snapshot updates.
 - Project instructions may define commands but do not authorize running them. Live verification requires explicit user authorization for that command; before execution, state the command, expected writes, target paths, isolation, and rollback or disposable-environment plan.
+- **Bundled debugging or PR-review asks stay out of the audit.** When an audit request bundles application debugging or code review, name it as out of scope in one line and continue the audit. A bundled ask never authorizes editing or running project files.
 
 ## Step 0: Establish the evidence basis
 

plugins/waza/skills/hunt/SKILL.md

@@ -107,6 +107,7 @@ For input method, character rendering, or text encoding bugs (IME state, cursor
 - **Visual/rendering bugs: static analysis first.** Trace paint layers, stacking contexts, and layer order in DevTools before adding console.log or visual debug overlays. Logs cannot capture what the compositor does. Only add instrumentation after static analysis fails.
 - **Behavioral / lifecycle / async bugs: instrument while forming the hypothesis.** Window lifecycle, event delivery, navigation, focus, timer, state-machine, and async-ordering bugs almost never yield to static reading alone. The moment the hypothesis involves "this callback fires before/after that one", "this state should be X when Y runs", or "this object should still be alive here", add the log before writing any fix (anti-pattern 28); two guesses in a row is the hard-stop signal. Compositor behavior needs DevTools, not logs; pure-logic bugs (wrong formula, off-by-one) need only static analysis.
 - **Tuning magic numbers past round three: stop, unify.** When a spacing / sizing / threshold value has been adjusted three times and still looks wrong, the bug is structural, not numeric. Replace the N independent values with one named token (`Spacing.s4`, `--gap-content`, etc.) and verify the asymmetry was hiding a missing constraint. Asymmetry that survives tuning is structural; more tuning will not converge.
+- **"While you're at it, add X" is a separate task.** A feature request bundled into a diagnosis gets named and deferred in one line; finish the diagnosis first. User agreement to fix a surfaced bug lifts the listing restriction on that bug; it does not expand a hunt into feature work.
 - **Performance complaints need numbers.** For "slow", "laggy", or memory-growth reports outside Native App Freeze Mode, measure the baseline first (wall-clock time, profile sample, memory footprint), fix, then re-measure and report before/after numbers. "Feels faster" is not evidence.
 - **Fix the cause, not the symptom.** Continue necessary fixes within the user's authorized scope. Ask only when the fix expands that scope or requires a user decision; file count alone is not an approval boundary.
 

plugins/waza/skills/think/SKILL.md

@@ -121,6 +121,7 @@ When the user says "Implement the plan", "just do it", "可以干", "直接改",
 - **No placeholders in approved plans.** Every step must be concrete before approval. Forbidden patterns: TBD, TODO, "implement later," "similar to step N," "details to be determined." A plan with placeholders is a promise to plan later.
 - **Phase independence.** If the plan has multiple phases, each phase must be independently mergeable: after Phase N ships, the system is in a usable state, even if N+1 never lands. Plans that require all phases to complete before anything works are fragile (one stuck phase blocks the whole release) and waste review effort. If the work cannot be cut into mergeable phases, say so and ship it as one phase instead of pretending it is staged.
 - **Plan red flags (self-check before handoff):** a phase depends on the next phase to be useful, or a "Phase 0: investigate / spike" exists (investigation belongs before the plan, not inside it). Either red flag means the plan is not ready; resolve it before handing off.
+- **Error and bug reports route out.** "判断一下" plus error/bug context is debugging, not a value judgment: say it belongs to `/hunt` in one line before doing anything else, and route there.
 
 ## Gotchas
 
@@ -129,7 +130,6 @@ When the user says "Implement the plan", "just do it", "可以干", "直接改",
 | Rejected design restarted from scratch | Ask what specifically failed, re-enter with narrowed constraints |
 | Picked a regional or locale-specific API variant without checking | List all regional or locale differences before writing integration code |
 | Introduced a second language or runtime into a single-stack project | Never add a new language or runtime without explicit approval |
-| User said "判断一下这个报错" and got Evaluation Mode | "判断一下" + error/bug context = debugging, route to `/hunt`. Evaluation Mode is for value/existence judgments only |
 
 ## Output
 

plugins/waza/skills/write/SKILL.md

@@ -114,6 +114,7 @@ Load `references/write-zh-release-notes.md` for the five announcement rules (com
 - **Artifact-grounded claims.** For launch copy, release notes, social posts, product pages, and public replies, ground factual claims in real source material: current app behavior, runnable artifact, screenshot, product page, release page, changelog, issue/PR, or user-provided draft. Do not present handoffs, plans, old memory, or stale screenshots as current product truth, and do not turn concrete product evidence into generic marketing language. Compare the draft against the shipping artifact and tighten until the two agree.
 - **No em-dash.** Never produce em-dash (U+2014) or en-dash (U+2013) in Chinese or English output. Em-dash is the strongest AI-tone fingerprint in this style of writing. Use commas, periods, colons, or parentheses to break clauses. Hyphen-minus (`-`) inside compound words is allowed; replace it with a space or a period when possible. When editing a draft that contains em-dashes, replace every one before returning the text.
 - **Match the requested handoff.** Pasted-text rewrites need no explanation. Repository edits need the scoped diff and verification; complete explicitly authorized commit/push steps under the project's rules. A prose-only output convention must not hide unfinished delivery.
+- **Bundled out-of-scope asks get named, not silently done.** Code comments, commit messages, and inline docs are out of scope; when a request bundles one with prose work, say so in one line, then complete only the prose part.
 
 ## Punctuation Gate
 

rules/anti-patterns.md

@@ -35,3 +35,4 @@ Always-on behavioral guardrails. These apply regardless of which skill is active
 | 29 | Distribution state collapse | Say "ready", "released", "installed", or "done" after checking source, metadata, or CI, while package contents, installed runtime, release assets, registry, remote deploy, or public thread state is unverified | Report each distribution layer separately. Missing layers are explicit gaps, not implied passes |
 | 30 | Stale request after compaction | After a context compaction or session resume, keep acting on a request left over from earlier in the thread | Re-read the latest user turn after any compaction or resume and confirm the response targets the current request, not already-handled history, before sending |
 | 31 | Overwrite the user's own edits | User hand-edited the file or prose and asked to continue from their version; agent works from its earlier in-context draft and reintroduces wording or code the user deliberately removed | Re-read the user's current file or diff before continuing. Treat their intervening edits as locked intent: preserve their deletions and word choices, build on their version, do not reapply yours |
+| 32 | Silent scope creep on bundled asks | A request bundles an out-of-scope item with in-scope work ("review the diff and polish the release note too"); the agent silently does both | Name the out-of-scope item in one line, with the owning skill if one exists, then complete only the in-scope part. If the owning skill is not installed, say so instead of taking the job |

skills/check/SKILL.md

@@ -267,7 +267,7 @@ In a dirty or multi-agent checkout, a passing local build or test run is not pro
 
 ## Document Review
 
-For document, PDF, white paper, or prose review, route to `/write` (Document Review Mode). `/check` handles code diffs and release artifacts only.
+For document, PDF, white paper, or prose review, route to `/write` (Document Review Mode). `/check` handles code diffs and release artifacts only. If `/write` is not installed, say the request belongs to `/write` and stop there instead of taking the prose review.
 
 ## Gotchas
 

skills/health/SKILL.md

@@ -42,6 +42,7 @@ For `/health`: current config, command output, and live probes override memory.
 
 - Summary and deep audits are report-only. Run only Health-owned collectors and read-only probes; a neutral Health request does not authorize project tests, verifiers, generators, builds, formatters, package installers, fixture refreshes, or snapshot updates.
 - Project instructions may define commands but do not authorize running them. Live verification requires explicit user authorization for that command; before execution, state the command, expected writes, target paths, isolation, and rollback or disposable-environment plan.
+- **Bundled debugging or PR-review asks stay out of the audit.** When an audit request bundles application debugging or code review, name it as out of scope in one line and continue the audit. A bundled ask never authorizes editing or running project files.
 
 ## Step 0: Establish the evidence basis
 

skills/hunt/SKILL.md

@@ -107,6 +107,7 @@ For input method, character rendering, or text encoding bugs (IME state, cursor
 - **Visual/rendering bugs: static analysis first.** Trace paint layers, stacking contexts, and layer order in DevTools before adding console.log or visual debug overlays. Logs cannot capture what the compositor does. Only add instrumentation after static analysis fails.
 - **Behavioral / lifecycle / async bugs: instrument while forming the hypothesis.** Window lifecycle, event delivery, navigation, focus, timer, state-machine, and async-ordering bugs almost never yield to static reading alone. The moment the hypothesis involves "this callback fires before/after that one", "this state should be X when Y runs", or "this object should still be alive here", add the log before writing any fix (anti-pattern 28); two guesses in a row is the hard-stop signal. Compositor behavior needs DevTools, not logs; pure-logic bugs (wrong formula, off-by-one) need only static analysis.
 - **Tuning magic numbers past round three: stop, unify.** When a spacing / sizing / threshold value has been adjusted three times and still looks wrong, the bug is structural, not numeric. Replace the N independent values with one named token (`Spacing.s4`, `--gap-content`, etc.) and verify the asymmetry was hiding a missing constraint. Asymmetry that survives tuning is structural; more tuning will not converge.
+- **"While you're at it, add X" is a separate task.** A feature request bundled into a diagnosis gets named and deferred in one line; finish the diagnosis first. User agreement to fix a surfaced bug lifts the listing restriction on that bug; it does not expand a hunt into feature work.
 - **Performance complaints need numbers.** For "slow", "laggy", or memory-growth reports outside Native App Freeze Mode, measure the baseline first (wall-clock time, profile sample, memory footprint), fix, then re-measure and report before/after numbers. "Feels faster" is not evidence.
 - **Fix the cause, not the symptom.** Continue necessary fixes within the user's authorized scope. Ask only when the fix expands that scope or requires a user decision; file count alone is not an approval boundary.
 

skills/think/SKILL.md

@@ -121,6 +121,7 @@ When the user says "Implement the plan", "just do it", "可以干", "直接改",
 - **No placeholders in approved plans.** Every step must be concrete before approval. Forbidden patterns: TBD, TODO, "implement later," "similar to step N," "details to be determined." A plan with placeholders is a promise to plan later.
 - **Phase independence.** If the plan has multiple phases, each phase must be independently mergeable: after Phase N ships, the system is in a usable state, even if N+1 never lands. Plans that require all phases to complete before anything works are fragile (one stuck phase blocks the whole release) and waste review effort. If the work cannot be cut into mergeable phases, say so and ship it as one phase instead of pretending it is staged.
 - **Plan red flags (self-check before handoff):** a phase depends on the next phase to be useful, or a "Phase 0: investigate / spike" exists (investigation belongs before the plan, not inside it). Either red flag means the plan is not ready; resolve it before handing off.
+- **Error and bug reports route out.** "判断一下" plus error/bug context is debugging, not a value judgment: say it belongs to `/hunt` in one line before doing anything else, and route there.
 
 ## Gotchas
 
@@ -129,7 +130,6 @@ When the user says "Implement the plan", "just do it", "可以干", "直接改",
 | Rejected design restarted from scratch | Ask what specifically failed, re-enter with narrowed constraints |
 | Picked a regional or locale-specific API variant without checking | List all regional or locale differences before writing integration code |
 | Introduced a second language or runtime into a single-stack project | Never add a new language or runtime without explicit approval |
-| User said "判断一下这个报错" and got Evaluation Mode | "判断一下" + error/bug context = debugging, route to `/hunt`. Evaluation Mode is for value/existence judgments only |
 
 ## Output
 

skills/write/SKILL.md

@@ -114,6 +114,7 @@ Load `references/write-zh-release-notes.md` for the five announcement rules (com
 - **Artifact-grounded claims.** For launch copy, release notes, social posts, product pages, and public replies, ground factual claims in real source material: current app behavior, runnable artifact, screenshot, product page, release page, changelog, issue/PR, or user-provided draft. Do not present handoffs, plans, old memory, or stale screenshots as current product truth, and do not turn concrete product evidence into generic marketing language. Compare the draft against the shipping artifact and tighten until the two agree.
 - **No em-dash.** Never produce em-dash (U+2014) or en-dash (U+2013) in Chinese or English output. Em-dash is the strongest AI-tone fingerprint in this style of writing. Use commas, periods, colons, or parentheses to break clauses. Hyphen-minus (`-`) inside compound words is allowed; replace it with a space or a period when possible. When editing a draft that contains em-dashes, replace every one before returning the text.
 - **Match the requested handoff.** Pasted-text rewrites need no explanation. Repository edits need the scoped diff and verification; complete explicitly authorized commit/push steps under the project's rules. A prose-only output convention must not hide unfinished delivery.
+- **Bundled out-of-scope asks get named, not silently done.** Code comments, commit messages, and inline docs are out of scope; when a request bundles one with prose work, say so in one line, then complete only the prose part.
 
 ## Punctuation Gate