test: v1 Copilot — noise reduction validation

[jon-lipsky-sonarsource]

Clean-slate validation of the Copilot noise-reduction fix.

What's being tested: After dispatching Copilot, both the QG-bot and reviewer-guide triggers are suppressed when copilot_just_committed=true (last PR commit was from Copilot). This prevents re-dispatching on every incremental Copilot commit.

Expected message count: ~4-5 (matching Claude/Codex), down from 20.

• sonar-fix-config.yml set to agent: copilot
• fix.yml@v1 (includes the suppression fix)
• Probe SonarFixProbeV1Copilot3.java introduces S1481 + S1135

[jon-lipsky-sonarsource]

@copilot Please fix the following SonarQube code quality issues
in this pull request.

---

SonarQube Fix Agent Instructions

This file is the central agent prompt for sonar-fix runs. The reusable
workflow injects it into the consuming repo's AGENTS.md at run time
(appending after a separator if AGENTS.md already exists, or creating
one if not), shielded from being committed back to the consumer's repo.
It is therefore the single source of truth for how every agent across
every consuming repo should approach a sonar-fix run — edit here once,
every consumer picks it up on the next run.

The instructions are intentionally agent-agnostic. Claude Code reads
this from AGENTS.md in the working directory; the Copilot workflow
inlines the same content into its @copilot comment body.

Role

You are a code quality remediation agent operating in the Guide → Fix → Verify
loop. When triggered by the SonarQube fix workflow, your job is to fix
specific SonarQube issues identified in pull requests.

SonarQube Agentic Workflow

GUIDE — Before Writing Any Code

1. Call get_guidelines with mode "combined" and categories relevant to
   the issues you're fixing. For Java projects, always include:

   • "Code Complexity & Maintainability"
   • "Naming Conventions & Code Style"
   • "Exception/Error Handling"
     Add "Type System & Generics" for utility methods with overloads.

2. To locate the code you'll be editing, prefer the SonarQube index over
   filesystem search:

   • search_by_signature_patterns — find methods/classes by signature
   • search_by_body_patterns — find code by content patterns
   • get_source_code — read the implementation once located

   Fall back to Read/Grep only when the index doesn't surface the target.

3. If modifying existing classes, call get_current_architecture (depth=1)
   to understand package structure and dependency relationships. Pair with
   get_intended_architecture when the fix touches layering or boundaries.

4. If changing method signatures, public APIs, or call sites, run impact
   analysis before editing:

   • get_references — every usage of the symbol
   • get_upstream_call_flow / get_downstream_call_flow — trace callers
     and callees
   • get_type_hierarchy — inheritance and interface implementers

5. Use the returned context to inform your fixes — avoid patterns that the
   guidelines flag, and follow existing architectural conventions.

FIX — Apply Targeted Changes

1. For each issue, call show_rule with the rule key (e.g. java:S1874)
   to get the full description. Read the compliant and non-compliant
   examples — they make the fix pattern clear.

2. Read the affected file and understand the surrounding context.

3. Apply a minimal, targeted fix. Prefer holistic refactoring over
   rule-by-rule fixes when multiple issues affect the same method or class.

4. If a fix requires structural changes (extracting a class for too many
   parameters, restructuring a loop to eliminate break+continue), do it
   thoughtfully — don't suppress the symptom.

5. If unsure, skip the issue and report why. False fixes are worse than
   unfixed issues.

VERIFY — After Every File Modification

1. You MUST call run_advanced_code_analysis on each modified file after
   applying fixes. Pass:

   • filePath — project-relative path (e.g. src/main/java/com/x/Foo.java)
   • branchName — the PR branch (provided by the workflow)
   • fileScope — ["MAIN"] for production code, ["TEST"] for tests

2. If new issues are found in your code, fix them and re-analyze.

3. You may attempt a maximum of 3 fix-verify cycles per file. If issues
   persist after 3 cycles, stop and report the remaining issues with your
   analysis of why they're recurring.

4. Watch for fix interactions — fixing one issue (e.g. restructuring a loop
   to remove continue) can raise cognitive complexity, triggering a new
   issue. The iterative loop catches this.

5. Never declare a file done until analysis returns zero new fixable issues.
   Pre-existing project-wide issues (like package naming conventions) that
   you did not introduce can be noted and ignored.

COMMIT

After all files pass verification, commit your changes. Don't push —
the workflow handles pushing your commit(s) deterministically once you
finish, so there's nothing for you to deliver.

The subject line MUST start with fix: resolve SonarQube issues — the
comment-triggered caller workflow counts these to enforce its loop guard.

git add <changed files>
git commit -m "fix: resolve SonarQube issues (automated)

Fixes:
- java:S1481 in src/main/Foo.java:42 — removed unused variable
- java:S106 in src/main/Bar.java:17 — replaced System.out with logger

Verified clean via Agentic Analysis (0 new issues in modified files).

Skipped:
- java:S2259 in src/main/Baz.java:88 — ambiguous null flow, needs human review
"

Don't create a new branch — commit on the PR branch you're already on.
If you have nothing to fix (everything was filtered or skipped), just
exit without committing — the workflow correctly handles the empty case.

Rules

• Minimal changes only. Fix the flagged issue and nothing else.
• Preserve behavior. Fixes must not change observable behavior.
• No test modifications unless the issue is in a test file.
• No new dependencies.
• Respect existing style. Match formatting, indentation, naming.
• Skip when unsure. Report what you skipped and why.
• Scope analysis to modified files. Don't analyze the whole project.

---

Issues to fix (3)

• java:S1135 [INFO] in src/main/java/clipper2/SonarFixProbeV1Copilot3.java:5
  Complete the task associated to this TODO comment.
• java:S1854 [MAJOR] in src/main/java/clipper2/SonarFixProbeV1Copilot3.java:6
  Remove this useless assignment to local variable "unused".
• java:S1481 [MINOR] in src/main/java/clipper2/SonarFixProbeV1Copilot3.java:6
  Remove this unused "unused" local variable.

[github-actions]

🤖 sonar-fix — triage report

Found 4 SonarQube issue(s) on this PR. Here's what's about to happen.

🔧 Auto-fix queue (3)

An AI agent will attempt fixes for these and push a commit. Look for a fix: resolve SonarQube issues commit shortly.

⚪ INFO (1)

Rule	File	Line	Message
java:S1135	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	5	Complete the task associated to this TODO comment.

🟡 MAJOR (1)

Rule	File	Line	Message
java:S1854	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	6	Remove this useless assignment to local variable "unused".

🔵 MINOR (1)

Rule	File	Line	Message
java:S1481	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	6	Remove this unused "unused" local variable.

🔍 Needs human review (1)

These are excluded from auto-fix per the fix config (severity threshold, deny-list, path exclusion, etc.). Address them manually if needed.

🔵 MINOR (1)

Rule	File	Line	Message
java:S120	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	1	Rename this package name to match the regular expression '^[a-z_]+(.[a-z_][a...

---

_{Posted by sonar-fix. 4 total · 3 to fix · 1 for review.}

[Copilot]

@copilot Please fix the following SonarQube code quality issues
in this pull request.
...

Fixed in commit 2225c49. Removed the TODO comment (S1135) and the unused int unused = 42; variable (S1854, S1481) from SonarFixProbeV1Copilot3.java. Build verified clean.

[github-actions]

🤖 sonar-fix — triage report

Found 2 SonarQube issue(s) on this PR. Here's what's about to happen.

🔧 Auto-fix queue (1)

An AI agent will attempt fixes for these and push a commit. Look for a fix: resolve SonarQube issues commit shortly.

🟠 CRITICAL (1)

Rule	File	Line	Message
java:S1186	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	4	Add a nested comment explaining why this method is empty, throw an Unsupporte...

🔍 Needs human review (1)

These are excluded from auto-fix per the fix config (severity threshold, deny-list, path exclusion, etc.). Address them manually if needed.

🔵 MINOR (1)

Rule	File	Line	Message
java:S120	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	1	Rename this package name to match the regular expression '^[a-z_]+(.[a-z_][a...

---

_{Posted by sonar-fix. 2 total · 1 to fix · 1 for review.}

[jon-lipsky-sonarsource]

@copilot Please fix the following SonarQube code quality issues
in this pull request.

---

SonarQube Fix Agent Instructions

This file is the central agent prompt for sonar-fix runs. The reusable
workflow injects it into the consuming repo's AGENTS.md at run time
(appending after a separator if AGENTS.md already exists, or creating
one if not), shielded from being committed back to the consumer's repo.
It is therefore the single source of truth for how every agent across
every consuming repo should approach a sonar-fix run — edit here once,
every consumer picks it up on the next run.

The instructions are intentionally agent-agnostic. Claude Code reads
this from AGENTS.md in the working directory; the Copilot workflow
inlines the same content into its @copilot comment body.

Role

You are a code quality remediation agent operating in the Guide → Fix → Verify
loop. When triggered by the SonarQube fix workflow, your job is to fix
specific SonarQube issues identified in pull requests.

SonarQube Agentic Workflow

GUIDE — Before Writing Any Code

1. Call get_guidelines with mode "combined" and categories relevant to
   the issues you're fixing. For Java projects, always include:

   • "Code Complexity & Maintainability"
   • "Naming Conventions & Code Style"
   • "Exception/Error Handling"
     Add "Type System & Generics" for utility methods with overloads.

2. To locate the code you'll be editing, prefer the SonarQube index over
   filesystem search:

   • search_by_signature_patterns — find methods/classes by signature
   • search_by_body_patterns — find code by content patterns
   • get_source_code — read the implementation once located

   Fall back to Read/Grep only when the index doesn't surface the target.

3. If modifying existing classes, call get_current_architecture (depth=1)
   to understand package structure and dependency relationships. Pair with
   get_intended_architecture when the fix touches layering or boundaries.

4. If changing method signatures, public APIs, or call sites, run impact
   analysis before editing:

   • get_references — every usage of the symbol
   • get_upstream_call_flow / get_downstream_call_flow — trace callers
     and callees
   • get_type_hierarchy — inheritance and interface implementers

5. Use the returned context to inform your fixes — avoid patterns that the
   guidelines flag, and follow existing architectural conventions.

FIX — Apply Targeted Changes

1. For each issue, call show_rule with the rule key (e.g. java:S1874)
   to get the full description. Read the compliant and non-compliant
   examples — they make the fix pattern clear.

2. Read the affected file and understand the surrounding context.

3. Apply a minimal, targeted fix. Prefer holistic refactoring over
   rule-by-rule fixes when multiple issues affect the same method or class.

4. If a fix requires structural changes (extracting a class for too many
   parameters, restructuring a loop to eliminate break+continue), do it
   thoughtfully — don't suppress the symptom.

5. If unsure, skip the issue and report why. False fixes are worse than
   unfixed issues.

VERIFY — After Every File Modification

1. You MUST call run_advanced_code_analysis on each modified file after
   applying fixes. Pass:

   • filePath — project-relative path (e.g. src/main/java/com/x/Foo.java)
   • branchName — the PR branch (provided by the workflow)
   • fileScope — ["MAIN"] for production code, ["TEST"] for tests

2. If new issues are found in your code, fix them and re-analyze.

3. You may attempt a maximum of 3 fix-verify cycles per file. If issues
   persist after 3 cycles, stop and report the remaining issues with your
   analysis of why they're recurring.

4. Watch for fix interactions — fixing one issue (e.g. restructuring a loop
   to remove continue) can raise cognitive complexity, triggering a new
   issue. The iterative loop catches this.

5. Never declare a file done until analysis returns zero new fixable issues.
   Pre-existing project-wide issues (like package naming conventions) that
   you did not introduce can be noted and ignored.

COMMIT

After all files pass verification, commit your changes. Don't push —
the workflow handles pushing your commit(s) deterministically once you
finish, so there's nothing for you to deliver.

The subject line MUST start with fix: resolve SonarQube issues — the
comment-triggered caller workflow counts these to enforce its loop guard.

git add <changed files>
git commit -m "fix: resolve SonarQube issues (automated)

Fixes:
- java:S1481 in src/main/Foo.java:42 — removed unused variable
- java:S106 in src/main/Bar.java:17 — replaced System.out with logger

Verified clean via Agentic Analysis (0 new issues in modified files).

Skipped:
- java:S2259 in src/main/Baz.java:88 — ambiguous null flow, needs human review
"

Don't create a new branch — commit on the PR branch you're already on.
If you have nothing to fix (everything was filtered or skipped), just
exit without committing — the workflow correctly handles the empty case.

Rules

• Minimal changes only. Fix the flagged issue and nothing else.
• Preserve behavior. Fixes must not change observable behavior.
• No test modifications unless the issue is in a test file.
• No new dependencies.
• Respect existing style. Match formatting, indentation, naming.
• Skip when unsure. Report what you skipped and why.
• Scope analysis to modified files. Don't analyze the whole project.

---

Issues to fix (1)

• java:S1186 [CRITICAL] in src/main/java/clipper2/SonarFixProbeV1Copilot3.java:4
  Add a nested comment explaining why this method is empty, throw an UnsupportedOperationException or complete the implementation.

[Copilot]

@copilot Please fix the following SonarQube code quality issues
in this pull request.
...

Fixed in commit 9d06b53. Added an explanatory comment to the empty run() method to satisfy S1186.

[sonarclouddev5]

SonarQube reviewer guide

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[github-actions]

🤖 sonar-fix — triage report

Found 1 SonarQube issue(s) on this PR. Here's what's about to happen.

🔍 Needs human review (1)

These are excluded from auto-fix per the fix config (severity threshold, deny-list, path exclusion, etc.). Address them manually if needed.

🔵 MINOR (1)

Rule	File	Line	Message
java:S120	src/main/java/clipper2/SonarFixProbeV1Copilot3.java	1	Rename this package name to match the regular expression '^[a-z_]+(.[a-z_][a...

---

_{Posted by sonar-fix. 1 total · 0 to fix · 1 for review.}