Introduce quality rules for Groovy migration

[PerfectSlayer]

What Does This Do

This PR introduces quality rules to migrate away from Groovy and a new skill /review-groovy-migration to help reviewing the existing migration.

Motivation

This will help automate migration code reviews and should steer the generated code toward better quality, in particular for people without Claude Code history, or for modules with few JUnit code to get inspiration from.

Additional Notes

I expect to keep refining the rules using the human review comments and follow up PR content.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)
  • Get more information in this doc

Jira ticket: [PROJ-IDENT]

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:7567bdeeee

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve int sampling API types

This BLOCKER pattern matches any int ...priority/int ...mechanism, including method signatures and locals that mirror the tracer APIs; for example AgentSpanContext.getSamplingPriority() and AgentSpan.setSamplingPriority(int, int) are explicitly int in internal-api. Because the new skill says to apply BLOCKER rules unconditionally and offers to auto-fix them, reviewing a migrated test that implements or calls those APIs can be pushed toward byte types and either stop compiling or no longer exercise the real API contract. Narrow this rule to constants-only locals, or exclude API signatures/arguments that are intentionally int.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Require converters that accept unqualified constants

The example converter named here does not support the proposed unqualified table values: PrioritySamplingConverter only converts strings that start with PrioritySampling. and returns UNSET/SAMPLER_KEEP unchanged otherwise (utils/junit-utils/.../PrioritySamplingConverter.java:16-32). So applying this rule to a table that uses @ConvertWith(PrioritySamplingConverter.class) changes working rows like PrioritySampling.UNSET into values the converter will not convert, causing argument-conversion failures. Limit the rule to TableTest converters that actually accept unqualified tokens, or update the referenced converter first.

Useful? React with 👍 / 👎.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.98 s	13.87 s	[+0.1%; +1.5%] (maybe worse)
startup:insecure-bank:tracing:Agent	12.94 s	12.91 s	[-0.4%; +1.0%] (no difference)
startup:petclinic:appsec:Agent	16.60 s	17.14 s	[-7.1%; +0.9%] (no difference)
startup:petclinic:iast:Agent	17.32 s	17.41 s	[-1.5%; +0.5%] (no difference)
startup:petclinic:profiling:Agent	17.38 s	17.28 s	[-0.2%; +1.3%] (no difference)
startup:petclinic:sca:Agent	17.40 s	17.27 s	[+0.1%; +1.5%] (maybe worse)
startup:petclinic:tracing:Agent	16.48 s	16.69 s	[-2.4%; -0.2%] (maybe better)

Commit:0e488344 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[amarziali]

thanks for having retrofitted part of the feedback you had during recent test migration. that will help for the next one

[PerfectSlayer]

That should address all comments. I will merge it later Today

[PerfectSlayer]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-16 11:29:07 UTC ℹ️ Start processing command /merge

---

2026-06-16 11:29:18 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

---

2026-06-16 11:32:11 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-06-16 12:51:19 UTC ℹ️ MergeQueue: This merge request was merged