Quarkus Code One Task Group

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Implement one bucket of Quarkus tasks from a plan’s task group end to end: capture a single pre-change quality baseline, classify every test class into a container-free unit stage or a container stage, run iru-quarkus-code-one-task once per task, then validate the whole bucket once, cheapest checks first.

Purpose

iru-quarkus-code-one-task-group is the Quarkus counterpart to iru-java-springboot-code-one-task-group. It works for a Quarkus service in Java or Kotlin, on Maven or Gradle (Kotlin or Groovy DSL, wrapper preferred), single-module or hexagonal multi-module, all detected once at runtime. It is built on the language-level gate skills (iru-java-test, iru-java-coverage, iru-java-code-quality, iru-java-javadoc, iru-kotlin-code-quality, iru-kotlin-kdoc, iru-check-license), each run through an iru-gate-runner agent so no raw report lands in its context.

Four Quarkus facts shape the validation order:

  • A test’s annotation decides whether it can start a container. Plain JUnit and @QuarkusComponentTest never do; @QuarkusTest starts Dev Services for every capable extension without a configured URL, and @QuarkusIntegrationTest runs the packaged artifact. Step 1 classifies every test class once, with line-anchored grep patterns, into a unit stage and a container stage.

  • The 80% coverage gate is measured from the unit stage alone. Container-stage tests raise an aggregate that is only reported, never gated.

  • The container stage is serialized repository-wide behind an atomic mkdir-based .integration-test.lock, shared with every other container-backed group skill in the catalog.

  • The unit stage runs with Dev Services disabled, so a misclassified container test fails fast at application start-up instead of silently starting a container outside the lock.

A bucket can be fully gated on a machine with no Docker at all: when Docker is unavailable the container stage is reported as unverified, never silently skipped. The skill uses a medium model on purpose, since the plan carries the hard reasoning.

Purpose group

Quarkus Development Tooling

Plugin

Shipped by the iru-quarkus plugin of the ai-catalog marketplace (install with /plugin install iru-quarkus@ai-catalog; see Plugins).

Invocation

/iru-quarkus-code-one-task-group <bucket text>

Inputs

Argument Required Description Default

Bucket text

Yes

Every quarkus-tagged task/sub-task in the bucket with its own text, the group’s Parallelizable verdict, and any relevant "Current code state" context.

None — always invoked with a specific bucket’s text, by iru-code-one-task-group.

Outputs

  • Source, test, and (for Kotlin) build changes per task, produced via iru-quarkus-code-one-task.

  • License headers, Javadoc (Java) and KDoc plus Dokka (Kotlin) kept current across every touched file, checked once for the bucket.

  • For hexagonal builds only, a module-boundary check (enforcer banned dependencies, ArchUnit).

  • Unit-stage tests achieving at least 80% line coverage for changed classes, measured with JaCoCo (with quarkus-jacoco component-test data merged from a separate file where present) or Kover.

  • A container-stage result (Maven verify -DskipITs=false, or Gradle test plus quarkusIntTest): passed, failed and fixed, or unverified with the reason (Docker unavailable, lock held by another group).

  • An aggregate coverage figure reported for information only.

  • implementation_plan.md with each task’s checkbox checked, first with a "group validation pending" note and then with the final unit-stage coverage and container-stage outcome.

  • A report to the caller covering the test classification, module-boundary result, static analysis, coverage exceptions, container stage, and lock behavior.

Execution flow

flowchart TD A[Start /iru-quarkus-code-one-task-group] --> B["Step 0: read the container\nserialization rules"] B --> C["Step 1: detect build, languages, layout,\ncoverage engine, Docker; classify every\ntest class into unit or container stage;\ncapture one quality baseline"] C --> D{"Bucket Parallelizable?"} D -- yes --> E["Step 2: run iru-quarkus-code-one-task\nfor every task concurrently\n(unit-stage tests only)"] D -- no --> F["Step 2: run iru-quarkus-code-one-task\none task at a time"] E --> G["Confirm or backfill each task's box;\nre-run classification"] F --> G G --> H["Step 3.1-3.2: license headers,\nJavadoc and KDoc"] H --> I{"Hexagonal build?"} I -- yes --> J["Step 3.3: module-boundary checks"] I -- no --> K["Step 3.4: scoped unit-stage tests\nwith Dev Services disabled"] J --> K K -- start-up failure --> K2["Reclassify to container stage"] K2 --> K K --> L["Step 3.5: unit-stage coverage gate 80%"] L -- below gate --> L2["Add unit tests via owning task"] L2 --> K L --> M["Step 3.6-3.7: full unit-stage suite,\nstatic analysis vs. baseline"] M --> N{"Docker available and\ncontainer stage non-empty?"} N -- no --> R["Report container stage\nunverified or empty"] N -- yes --> O["Step 3.8a: acquire .integration-test.lock\n(wait, break stale, or time out)"] O --> P["Step 3.8: run container stage once"] P --> Q["Step 3.8b: release lock;\nStep 3.9: aggregate coverage for information"] Q --> S["Step 4: finalize progress notes;\nnotify user"] R --> S S --> T["Step 5: report bucket outcome\nto the caller"]

Dependencies

Invokes

  • Quarkus Code One Task — Step 2, once per task (concurrently or sequentially), via the iru-isolated-skill-executor agent; it implements the task, writes tests, runs unit-stage tests only, and checks off its own checkbox.

Each of the following runs via the iru-gate-runner agent:

  • Java Code Quality — Step 1 baseline and Step 3.7 regression check for Java classes.

  • Kotlin Code Quality — Step 1 baseline and Step 3.7 regression check for Kotlin classes (detekt and ktlint).

  • Check License — Step 3.1, license headers for every touched file.

  • Java Javadoc — Step 3.2, Javadoc for Java classes.

  • Kotlin KDoc — Step 3.2, KDoc and Dokka for Kotlin classes.

  • Java Test — Steps 3.4 and 3.6, scoped and full unit-stage tests, and the container stage in Step 3.8 when installed.

  • Java Coverage — Step 3.5, the unit-stage coverage gate, and Step 3.9, aggregate coverage.

Invoked by

Related agents

  • iru-isolated-skill-executor — one per task in Step 2, so each task’s transcript stays out of this skill’s context.

  • iru-gate-runner — every baseline, validation, container-stage, and aggregate coverage run (Steps 1 and 3).

Source

SKILL.md on GitHub — the file this page was generated from.