@mrciphersmith/keryx 0.3.5 → 0.3.6

package/src/gdskills/bundled/stacks/java-kotlin-spring/governance/scout.json

@@ -0,0 +1,39 @@
+[
+  {
+    "query": "Use when a Gradle or Maven build for a Java/Kotlin Spring Boot project fails -- compile errors, dependency/version conflicts, Spring context startup failures (missing bean, ambiguous bean, circular dependency), Kotlin/Java interop issues, checkstyle/ktlint/detekt findings, and a failing test run.",
+    "decision": "create",
+    "topMatch": "django/django-build-fix",
+    "recordedAt": "2026-09-25T18:06:23.531Z",
+    "skillName": "java-kotlin-spring-build-fix"
+  },
+  {
+    "query": "Use when reviewing a Java or Kotlin Spring Boot change for framework-specific risks -- field injection, @Transactional self-invocation, entities leaked across the API boundary, N+1 query patterns, missing Bean Validation, and overly permissive Spring Security configuration. Read-only, no edits.",
+    "decision": "fork",
+    "topMatch": "java-kotlin-spring/java-kotlin-spring-implementation",
+    "recordedAt": "2026-09-25T18:06:23.850Z",
+    "skillName": "java-kotlin-spring-code-review",
+    "justification": "top match java-kotlin-spring/java-kotlin-spring-implementation is this same pack's implementation skill, sharing Spring-specific domain vocabulary (constructor injection, @Transactional, Spring Data JPA, Bean Validation) because review necessarily checks for the same pitfalls implementation should avoid, not because the two are redundant; decision is fork since they cover disjoint workflows (writing new code vs. read-only review of an existing diff)."
+  },
+  {
+    "query": "Use when writing a controller, service, or repository class in a Java or Kotlin backend built on Spring Boot -- wiring dependencies through a class's own constructor, splitting request handling across layers, marshaling a request payload into a validated object, deciding where a transaction boundary starts, and authoring a Spring Data repository method. Covers writing/extending production code, not an existing diff's risks (that's the pack's own review skill) or fixing a broken build (that's its own build-fix skill).",
+    "decision": "create",
+    "topMatch": "java-kotlin-spring/java-kotlin-spring-code-review",
+    "recordedAt": "2026-09-25T18:06:24.162Z",
+    "skillName": "java-kotlin-spring-implementation"
+  },
+  {
+    "query": "Use when writing or reviewing a versioned database schema migration for a Spring Boot project using Flyway or Liquibase -- new migration file naming/ordering, never editing an already-applied migration, and verifying with flywayMigrate/flywayValidate or the project's configured equivalent.",
+    "decision": "create",
+    "topMatch": "quality/deprecation-path",
+    "recordedAt": "2026-09-25T18:06:24.476Z",
+    "skillName": "java-kotlin-spring-migrate"
+  },
+  {
+    "query": "Use when a Java or Kotlin Spring Boot test suite needs writing, extending, or fixing -- JUnit 5, Mockito/MockK, the narrowest Spring test slice (@WebMvcTest/@DataJpaTest/@SpringBootTest), MockMvc, Awaitility instead of Thread.sleep, and Testcontainers for repository tests.",
+    "decision": "fork",
+    "topMatch": "java-kotlin-spring/java-kotlin-spring-implementation",
+    "recordedAt": "2026-09-25T18:06:24.794Z",
+    "skillName": "java-kotlin-spring-testing",
+    "justification": "top match java-kotlin-spring/java-kotlin-spring-implementation is this same pack's implementation skill, sharing Spring-specific domain vocabulary (Spring Boot, JPA repository, service layer) because tests necessarily exercise the same layered architecture implementation builds, not because the two are redundant; decision is fork since they cover disjoint workflows (writing production code vs. writing JUnit5/MockMvc/Testcontainers tests for it)."
+  }
+]

package/src/gdskills/bundled/stacks/java-kotlin-spring/pack.json

@@ -0,0 +1,40 @@
+{
+  "id": "java-kotlin-spring",
+  "family": "framework",
+  "modules": ["java-kotlin-spring-rules", "java-kotlin-spring-skills"],
+  "detectionMarkers": ["spring-boot", "spring"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 335, Wave 4 batch 3"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": ["java-kotlin-spring-implementation"],
+    "test": ["java-kotlin-spring-testing"],
+    "review": ["java-kotlin-spring-code-review"],
+    "build-fix": ["java-kotlin-spring-build-fix"],
+    "migrate": ["java-kotlin-spring-migrate"]
+  },
+  "agentProfile": {
+    "displayName": "Java/Kotlin + Spring",
+    "auditFocus": [
+      "field-level @Autowired injection instead of constructor injection with final fields (Java) or val properties (Kotlin)",
+      "a public method calling another @Transactional method on `this` within the same class, relying on the self-invocation proxy that Spring's AOP-based transaction management cannot intercept",
+      "a controller/service returning a JPA entity directly instead of a DTO, leaking persistence internals and lazy-loading traps across the API boundary",
+      "a lazy-loaded association accessed in a loop with no @EntityGraph/fetch join, producing an N+1 query pattern",
+      "a request DTO with no Bean Validation (jakarta.validation) annotations, or a controller that trusts unvalidated input",
+      "a SecurityFilterChain/authorization rule that is overly permissive, or CSRF disabled on a session-based (cookie-authenticated) endpoint with no compensating control"
+    ],
+    "buildCommands": [
+      "./gradlew build (or mvn verify, matching the project's build tool)",
+      "./gradlew test (or mvn test)",
+      "./gradlew check (or the project's configured lint/static-analysis task, when configured)"
+    ],
+    "fixGuardrails": [
+      "Never switch field @Autowired injection back in to work around a wiring error instead of fixing the constructor/bean definition.",
+      "Never widen a SecurityFilterChain rule (e.g. permitAll on a protected path) just to make a 403 disappear.",
+      "Never disable a failing test or a Bean Validation constraint to reach a green build.",
+      "Never add a broad exception handler that swallows the root cause instead of fixing it."
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/java-kotlin-spring/rules/coding-style.mdc

@@ -0,0 +1,67 @@
+---
+extends: common
+paths: ["**/*.java", "**/*.kt", "**/*.kts"]
+metadata:
+  origin: authored
+---
+
+# Java/Kotlin + Spring coding style
+
+Narrows `core-common-rules`' stack-agnostic style rules to current Spring
+Boot 3.x idiom, for both Java and Kotlin sources. Applies only to
+`*.java`/`*.kt`/`*.kts` files — everything not Spring/Java/Kotlin-specific
+still comes from the common rules this file `extends`.
+
+## Dependency injection
+
+- Prefer constructor injection over field injection: a Java `@Service`
+  declares its dependencies as `private final` fields set in the
+  constructor (no `@Autowired` needed on the constructor once there is
+  only one), or a Kotlin class declares them as constructor `val`
+  properties. Field-level `@Autowired` is discouraged — it hides the
+  dependency graph, prevents the field from being `final`/`val`, and
+  makes the class impossible to construct without the Spring container in
+  a plain unit test.
+- A class with more than 4-5 constructor dependencies is a signal the
+  class has too many responsibilities, not a reason to fall back to field
+  injection to make the constructor shorter.
+
+## Layered architecture
+
+- Keep the controller/service/repository layers distinct: a
+  `@RestController` parses/validates the request and delegates to a
+  `@Service`; business logic and transaction boundaries live in the
+  service layer; a `@Repository`/Spring Data interface is the only layer
+  that talks to persistence. Do not put query logic in a controller or
+  HTTP concerns in a service.
+- Expose a request/response DTO at the API boundary, never a JPA `@Entity`
+  directly — an entity carries lazy associations and persistence-specific
+  fields that leak internal structure and can trigger
+  `LazyInitializationException` when serialized outside a transaction.
+
+## Naming and structure
+
+- Java: standard `PascalCase` for types, `camelCase` for members/methods,
+  packages lowercase with no underscores.
+- Kotlin: `PascalCase` for classes, `camelCase` for functions/properties;
+  prefer a `data class` for a DTO/value-holder instead of a plain class
+  with manually written `equals`/`hashCode`/`toString`.
+- Kotlin null-safety: model an optional field as a nullable type (`String?`)
+  and handle it with `?.`/`?:`/`requireNotNull`, not `!!` — a `!!` on
+  anything that can plausibly be null at runtime (a request field, a
+  lookup result) reintroduces the NPE the type system exists to prevent.
+
+## Bean Validation and DTOs
+
+- Annotate request DTO fields with `jakarta.validation` constraints
+  (`@NotNull`, `@NotBlank`, `@Size`, `@Email`, etc.) and mark the
+  controller parameter `@Valid`/`@Validated` — validation belongs on the
+  DTO at the boundary, not re-implemented as manual `if` checks inside
+  the service.
+
+## Formatting
+
+- Follow the project's configured formatter (`spotless`, `ktlint`,
+  google-java-format, or whatever `build.gradle(.kts)`/`pom.xml` already
+  wires up) rather than hand-formatting around it; do not introduce a
+  second formatter into a project that has already standardized on one.

package/src/gdskills/bundled/stacks/java-kotlin-spring/rules/patterns.mdc

@@ -0,0 +1,65 @@
+---
+extends: common
+paths: ["**/*.java", "**/*.kt", "**/*.kts"]
+metadata:
+  origin: authored
+---
+
+# Java/Kotlin + Spring patterns
+
+Narrows `core-common-rules`' stack-agnostic design guidance to idiomatic
+Spring Boot 3.x design and its common anti-patterns, for both Java and
+Kotlin. Applies only to `*.java`/`*.kt`/`*.kts` files.
+
+## Transaction boundaries and the self-invocation pitfall
+
+- `@Transactional` is placed on the outermost service method that defines
+  the unit of work, not scattered on every repository call.
+- Spring's declarative transactions are proxy-based (AOP): a call from
+  one method to another `@Transactional` method **on the same class**,
+  through `this`, bypasses the proxy entirely — the annotation is
+  silently ignored, no new transaction starts and no rollback happens on
+  that inner call. Split the self-invoking method out into a separate
+  bean the caller depends on (constructor-injected), so the call crosses
+  a real proxy boundary, instead of calling `this.otherTransactionalMethod()`.
+- Keep a `@Transactional` method free of unrelated I/O (HTTP calls,
+  file access) that would hold the transaction/connection open longer
+  than necessary.
+
+## Spring Data JPA query patterns
+
+- Watch for N+1: iterating a collection and accessing a lazy association
+  per item issues one query per item. Fix with `@EntityGraph` on the
+  repository method, a JPQL `JOIN FETCH`, or a projection that selects
+  only the fields actually needed — do not switch every association to
+  `FetchType.EAGER` as a blanket fix, which just moves the N+1 into every
+  unrelated query that loads the entity.
+- Prefer a derived query method or `@Query` with named parameters over
+  building JPQL/native SQL by string concatenation.
+- Use a projection (an interface or DTO) for a read path that only needs
+  a subset of an entity's fields, instead of loading the full entity
+  graph and mapping it down in the service layer.
+
+## Dependency injection and bean design
+
+- Define an interface at the consumer boundary (the package/module that
+  calls through it) when a component genuinely has more than one
+  implementation or needs to be mocked across module boundaries; do not
+  add an interface with a single Spring-managed implementation "for
+  testability" when constructor injection with a concrete class already
+  gives a test the same seam via a test double.
+- Favor constructor injection producing an immutable, fully-initialized
+  bean over setter injection or field injection, which both allow a bean
+  to exist in a partially-configured state.
+
+## Anti-patterns to flag
+
+- A "god service" that accumulates unrelated business logic across
+  multiple domains — split by bounded responsibility, mirroring the
+  controller/service/repository layering above.
+- Catching a broad `Exception`/`RuntimeException` in a service method
+  only to log and swallow it, instead of letting it propagate to a
+  `@ControllerAdvice`/`@ExceptionHandler` that maps it to the right HTTP
+  response.
+- A `@RestController` method containing business/query logic directly
+  instead of delegating to a service — controllers should stay thin.

package/src/gdskills/bundled/stacks/java-kotlin-spring/rules/security.mdc

@@ -0,0 +1,69 @@
+---
+extends: common
+paths: ["**/*.java", "**/*.kt", "**/*.kts"]
+metadata:
+  origin: authored
+---
+
+# Java/Kotlin + Spring security
+
+Narrows `core-common-rules`' stack-agnostic security rules to Spring Boot
+3.x-specific, OWASP-relevant risks. Broadly scoped to all Java/Kotlin
+sources for data-access and secrets guidance below, with extra emphasis
+on controller/security-config files for the HTTP-facing rules.
+
+## Spring Security configuration
+
+- Configure security with a `SecurityFilterChain` `@Bean` returned from a
+  `@Configuration` class (`http.build()` on an `HttpSecurity` you have
+  customized) — this is the current Spring Boot 3.x idiom. Do not extend
+  `WebSecurityConfigurerAdapter`; it was removed in Spring Security 6 /
+  Spring Boot 3 and any code still referencing it is targeting an old
+  major version.
+- Scope authorization rules explicitly (`authorizeHttpRequests` with
+  path/role matchers) rather than leaving a catch-all `permitAll()` that
+  was only meant for one endpoint during development.
+
+## CSRF
+
+- A stateless, token-authenticated API (bearer JWT/OAuth2, no session
+  cookie) legitimately disables CSRF protection (`csrf(AbstractHttpConfigurer::disable)`)
+  because CSRF exploits ambient cookie auth, which does not apply here —
+  state this reasoning explicitly when disabling it.
+- A session-cookie-authenticated endpoint (browser form login, `JSESSIONID`)
+  must keep CSRF protection enabled; disabling it there reopens the exact
+  attack the stateless-API exception does not apply to.
+
+## SQL and data access
+
+- Use Spring Data JPA derived queries or parameterized `@Query`
+  (JPQL/native, with named or positional bind parameters), never
+  string-concatenated or `String.format`-built SQL/JPQL with any
+  user-influenced value — parameterization is the injection defense, not
+  an input-validation substitute for it.
+- The same applies to `JdbcTemplate`/`NamedParameterJdbcTemplate`: use its
+  parameter-binding API, never interpolate a value into the SQL string.
+
+## Input validation as the DTO boundary defense
+
+- Validate untrusted input at the DTO boundary with `jakarta.validation`
+  annotations plus `@Valid`/`@Validated` on the controller method — this
+  is the primary injection/malformed-input defense point for request
+  data, on top of (not instead of) parameterized queries downstream.
+
+## Secrets and configuration
+
+- Never hard-code a credential, API key, or signing secret in source or
+  in `application.yml`/`application.properties` committed to the repo —
+  load it from environment variables, a config server, or the secret
+  store the project already uses (Spring's externalized configuration
+  supports both cleanly).
+- Do not log a request/response body that may carry credentials, tokens,
+  or PII at `INFO`/`DEBUG` level without redaction.
+
+## Dependency hygiene
+
+- Run the project's configured dependency-vulnerability check (OWASP
+  Dependency-Check plugin, `./gradlew dependencyCheckAnalyze`, or
+  whatever the build already wires up) when introducing or bumping a
+  dependency, rather than skipping it because "it's just a minor bump."

package/src/gdskills/bundled/stacks/java-kotlin-spring/rules/testing.mdc

@@ -0,0 +1,80 @@
+---
+extends: common
+paths: ["**/*.java", "**/*.kt", "**/*.kts"]
+metadata:
+  origin: authored
+---
+
+# Java/Kotlin + Spring testing
+
+Narrows `core-common-rules`' stack-agnostic testing rules to JUnit 5 +
+Spring Boot Test conventions, for both Java and Kotlin. Applies only to
+`*.java`/`*.kt`/`*.kts` files.
+
+## Layout and naming
+
+- Tests live under `src/test/java` or `src/test/kotlin`, mirroring the
+  package of the class under test, named `<Type>Test` (unit) or
+  `<Type>IT`/`<Type>IntegrationTest` (integration) — match whichever
+  convention the project already uses.
+- Prefer a plain, dependency-free unit test (construct the class
+  directly, pass mocks/fakes to the constructor) for logic that does not
+  need the Spring container; reserve `@SpringBootTest` for genuine
+  integration coverage — a full context load per test class is slow and
+  is not a substitute for testing a service's logic in isolation.
+
+## Test slices
+
+- Use the narrowest Spring test slice that covers what is being tested:
+  `@WebMvcTest` for a controller (with `MockMvc`), `@DataJpaTest` for a
+  repository, `@SpringBootTest` only when the interaction across the
+  whole wired context is actually what is under test.
+- For a repository/integration test that needs a real database, prefer
+  Testcontainers over an in-memory substitute (H2 standing in for
+  Postgres/MySQL) when the project already uses Testcontainers — an
+  in-memory DB can silently pass a query that the real production
+  database would reject or execute differently.
+
+## Mocking
+
+- Mock/stub only the collaborators the class under test actually depends
+  on (Mockito's `@Mock`/`@InjectMocks`, or MockK for Kotlin) — do not
+  reach for `@MockitoBean`/`@SpringBootTest` just to avoid constructing a
+  plain dependency by hand when the class was designed for constructor
+  injection. `@MockitoBean` is the current annotation for mocking a bean
+  inside a Spring test slice; Spring Boot's own `@MockBean` is deprecated
+  since Boot 3.4 and removed in 4.x, so only reach for it on a project
+  still pinned below 3.4.
+- Assert on behavior/interactions relevant to the test (`verify(...)`),
+  not on incidental implementation details that would make the test
+  brittle to a harmless refactor.
+
+## Assertions and determinism
+
+- Use the project's already-configured assertion library (AssertJ,
+  JUnit's own assertions, or Kotlin's `kotlin.test`) — do not introduce a
+  second one into a project that has standardized.
+- Never synchronize with `Thread.sleep`/`delay` to wait for an async
+  result — use Awaitility (`await().atMost(...).until(...)`), a
+  `CompletableFuture`/coroutine join, or a `CountDownLatch`, so the test
+  is deterministic and not flaky under CI load.
+- A test covering validation should assert on the specific constraint
+  violation/exception type, not just that "some" exception was thrown.
+
+## Fixtures and lifecycle
+
+- Prefer a builder or a test-fixture factory method for constructing
+  entities/DTOs with sensible defaults, overriding only the fields the
+  test cares about, over duplicating a large constructor call in every
+  test method.
+- Use `@BeforeEach`/`@AfterEach` (or Kotlin's equivalents) for
+  per-test setup/teardown; reserve `@BeforeAll`/`@AfterAll` for
+  genuinely expensive, safely-shared setup (a Testcontainers instance).
+
+## Coverage expectations
+
+- New behavior gets a new test in the same change; a bug fix gets a
+  regression test that fails before the fix and passes after.
+- Run the project's build-tool test task (`./gradlew test` or `mvn test`)
+  for any change touching test files, and its integration-test task
+  separately when one is configured, before reporting done.

package/src/gdskills/bundled/stacks/java-kotlin-spring/skills/java-kotlin-spring-build-fix/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: java-kotlin-spring-build-fix
+description: "Use when a Gradle or Maven build for a Java/Kotlin Spring Boot project fails -- compile errors, dependency/version conflicts, Spring context startup failures (missing bean, ambiguous bean, circular dependency), Kotlin/Java interop issues, checkstyle/ktlint/detekt findings, and a failing test run."
+triggers:
+  - "./gradlew build is failing"
+  - "mvn compile is failing with a dependency conflict"
+  - "Spring context fails to start -- no qualifying bean"
+  - "resolve this circular bean dependency in Spring"
+  - "ktlint is failing on this Kotlin file"
+  - "this Spring Boot test run is failing to build"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Java/Kotlin + Spring build fix
+
+Resolve a Gradle/Maven build failure for a Java or Kotlin Spring Boot
+project — a compile error, a dependency/version conflict, a Spring
+context startup failure (missing/ambiguous bean, circular dependency), a
+Kotlin/Java interop issue, a checkstyle/ktlint/detekt finding, or a
+failing test run — with the smallest change that fixes the actual root
+cause. `rules/coding-style.mdc` and `rules/security.mdc` govern what a
+"correct" fix looks like; this skill never reaches for a suppression
+instead of a fix.
+
+## Workflow
+
+### Step 1: Reproduce and classify
+
+```bash
+./gradlew build      # or: mvn verify
+```
+
+Run the project's configured static-analysis task if present
+(`./gradlew check`, `checkstyle`, `ktlint`, `detekt`). Read the exact
+error text and classify it:
+
+- **Compile error** (undefined symbol, type mismatch, wrong arg count,
+  Kotlin/Java interop nullability mismatch).
+- **Dependency/version conflict** (Gradle/Maven resolution failure,
+  transitive version clash, a missing dependency declaration).
+- **Spring context startup failure** — `NoSuchBeanDefinitionException`
+  (no qualifying bean), `NoUniqueBeanDefinitionException` (ambiguous
+  bean, needs `@Qualifier`/`@Primary`), or a circular bean dependency
+  (`BeanCurrentlyInCreationException`).
+- **Static-analysis finding** (checkstyle/ktlint/detekt rule violation).
+- **Failing test run** (a test failure surfaced through the build task).
+
+### Step 2: Fix by category
+
+**Dependency/version conflict:** check the build tool's own dependency
+tree (`./gradlew dependencies` or `mvn dependency:tree`) to see what is
+actually pulling in the conflicting version before bumping anything by
+hand. Align on the version the project's dependency-management/BOM
+(`spring-boot-dependencies`, a Gradle platform) already declares when one
+exists, rather than pinning an arbitrary version that happens to compile.
+
+**Missing/ambiguous bean:** for "no qualifying bean," check that the
+class is actually component-scanned (package location, `@Component`/
+`@Service`/`@Repository`/`@Configuration` present) and that any required
+`@ConditionalOn...` conditions are met. For "no unique bean," add
+`@Qualifier`/`@Primary` to disambiguate rather than deleting one of the
+legitimate implementations.
+
+**Circular bean dependency:** find the actual cycle (two beans each
+requiring the other in their constructors) and break it by extracting
+the shared behavior into a third bean, or by refactoring so one
+dependency is no longer needed at construction time — do not reach for
+`@Lazy` as a first resort; it defers the problem rather than fixing the
+design that created the cycle, though it is an acceptable last resort
+when the cycle is genuinely unavoidable and the reason is stated in the
+report.
+
+**Kotlin/Java interop:** a platform type (`String!`) flowing from Java
+into Kotlin that later NPEs, or a Kotlin nullable type mismatching a
+Java `@NonNull`/`@Nullable` annotation — fix by making the Kotlin side's
+nullability match what the Java API actually guarantees (check for
+JSR-305/`@NonNull` annotations on the Java side), not by adding a blanket
+`!!` at the interop boundary.
+
+**Static-analysis finding:** fix the underlying issue the finding names.
+Never add a suppression (`// noinspection`, `@SuppressWarnings`, a
+ktlint/detekt `// ktlint-disable`/baseline entry) whose only purpose is
+to make the checker stop complaining without addressing what it found.
+
+**Failing test run:** read the actual assertion failure or stack trace;
+fix the root cause in test or source per the failure's own evidence — do
+not delete or `@Disabled` the test to reach a green build.
+
+### Step 3: Verify
+
+```bash
+./gradlew build      # or: mvn verify
+./gradlew test        # or: mvn test
+```
+
+Re-run the project's static-analysis task if it was part of the original
+failure. All must exit 0 before reporting done.
+
+### Step 4: Report
+
+```
+Fixed: NoUniqueBeanDefinitionException for PaymentGateway (two implementations)
+  - Root cause: StripeGateway and MockGateway both @Component-scanned with no @Primary
+  - Added @Primary to StripeGateway; ./gradlew build/test both pass
+```
+
+State the root cause in one sentence, not just "fixed the error."
+
+## Rules
+
+- Find and fix the smallest change that addresses the actual root cause —
+  never widen a fix beyond what the failure requires.
+- NEVER add a suppression annotation/comment/baseline entry to silence a
+  static-analysis finding instead of fixing what it found.
+- NEVER delete or `@Disabled` a failing test to reach a green build.
+- NEVER pin an arbitrary dependency version to make a conflict disappear
+  without checking the dependency tree/BOM first.
+- Reach for `@Lazy` on a circular bean dependency only as a last resort,
+  with the reason stated in the report — prefer breaking the actual cycle.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add `@SuppressWarnings` here so the linter stops complaining" | Silences the finding without fixing the issue it caught; check what it actually found instead |
+| "I'll just mark the failing test `@Disabled` for now" | Hides a real regression or a genuinely broken feature; fix the root cause or say explicitly why the test itself is wrong |
+| "I'll add `@Lazy` to break this bean cycle, it's the fastest fix" | Defers bean initialization instead of fixing the design that created a two-way dependency; acceptable only as a stated last resort, not the default |
+| "I'll bump this dependency to whatever version compiles" | Picks a version by trial and error instead of checking what the project's BOM/dependency tree actually resolves to, risking a different conflict later |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- `./gradlew build`/`mvn verify` and the test task both exit 0.
+- The project's static-analysis task (if configured) exits 0.
+- The change is the smallest one that addresses the stated root cause —
+  no unrelated files touched.
+- The report states the root cause in one sentence, not just "build now
+  passes."

package/src/gdskills/bundled/stacks/java-kotlin-spring/skills/java-kotlin-spring-build-fix/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "Our CI just started failing on ./gradlew assemble -- the log points to two different versions of jackson-databind on the classpath. How do I track down which dependency is pulling in the wrong one?",
+      "After adding a second implementation of PaymentGateway, the app won't boot anymore and the stack trace mentions NoUniqueBeanDefinitionException. What's going on?",
+      "mvn verify is failing with a circular bean dependency",
+      "Our lint step is red because of a ktlint violation in OrderMapper.kt -- can you clean it up?",
+      "`./gradlew test` won't even compile -- there's a type mismatch somewhere in the OrderServiceTest sources. Can you track it down?",
+      "NoSuchBeanDefinitionException on startup, fix this Spring build"
+    ],
+    "negative": [
+      "npm install is failing with a peer dependency conflict",
+      "cargo build is failing for this Rust crate",
+      "go build is failing with an undefined symbol",
+      "Implement a new feature in this Spring service",
+      "Review this Spring diff for concurrency bugs",
+      "Write JUnit tests for this Spring controller"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-suppresswarnings-suppression",
+      "prompt": "checkstyle is flagging an unused import in my Java code after a refactor. How should I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer removes the actual unused import that checkstyle flagged, rather than suppressing the finding with @SuppressWarnings or a checkstyle-disable comment.",
+          "pass_criteria": [
+            "States that the fix is to remove the specific unused import statement, not merely 'clean up imports' in the abstract.",
+            "Does not rely on @SuppressWarnings or a checkstyle-disable comment/baseline entry as the fix for this finding.",
+            "Either names re-running checkstyle to confirm the finding clears, or does not suggest skipping verification."
+          ],
+          "fail_criteria": [
+            "Recommends adding @SuppressWarnings or a checkstyle-disable comment/baseline entry to silence the unused-import finding instead of removing the import."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "That means the refactor left an import statement that nothing in the file references anymore. The fix is simply to delete that import line -- most IDEs will highlight it directly, or you can match it against checkstyle's reported line number. There's no suppression needed here; an unused import is dead weight with no runtime cost either way, so removing it is strictly better than silencing the finding. Re-run checkstyle afterward to confirm it's clear and that the refactor didn't leave any other unused imports nearby.",
+        "known_wrong": "Easiest fix is to add `@SuppressWarnings(\"unused\")` above the class, or add a checkstyle-disable comment around the import block -- that stops checkstyle from flagging it without you needing to hunt down which specific import is unused. You can leave the import in place in case the code changes again later and needs it back.",
+        "vague": "Clean up the imports so checkstyle stops complaining about this file.",
+        "subtle_wrong": "Rather than deleting the import outright, add a checkstyle-disable comment (`// CHECKSTYLE:OFF: UnusedImports`) around that line -- that way if a later change in this file ends up needing the same import again, it's already there and won't need to be re-added. It keeps the diff smaller than fully removing and potentially re-adding the import later."
+      },
+      "anti_patterns": ["@SuppressWarnings"]
+    },
+    {
+      "id": "circular-bean-dependency",
+      "prompt": "Spring fails to start with BeanCurrentlyInCreationException -- OrderService and PaymentService each require the other in their constructors. How do I fix this?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies this as a genuine circular bean dependency and fixes it by breaking the cycle -- extracting the shared behavior into a third bean, or refactoring so one side no longer needs the other at construction time -- treating @Lazy only as a stated last resort rather than the default fix.",
+          "pass_criteria": [
+            "Identifies the actual cycle: OrderService and PaymentService each depend on the other through their constructors.",
+            "Proposes breaking the cycle as the primary fix direction -- extracting shared behavior into a third bean, or removing the unnecessary constructor-time dependency on one side -- not just deferring it.",
+            "Treats @Lazy (if mentioned at all) as an explicitly-stated last resort for a case where the cycle is genuinely unavoidable, not as the default or preferred fix."
+          ],
+          "fail_criteria": [
+            "Recommends @Lazy on one of the constructor dependencies as the fix, presented as the default or preferred solution rather than an explicitly-flagged last resort for an unavoidable cycle."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This means OrderService's constructor needs a PaymentService, and PaymentService's constructor needs an OrderService -- Spring can't construct either one first because each is waiting on the other. The real fix is to break the cycle rather than paper over it: look at what each side actually calls on the other, and pull that shared behavior into a third bean that both OrderService and PaymentService depend on instead of depending on each other directly. Often one side only needs a narrow slice of the other's behavior (e.g. OrderService only needs PaymentService to charge a card, PaymentService only needs OrderService to look up an order) -- extracting those specific operations into a shared collaborator usually removes the cycle entirely. Reach for @Lazy on one of the constructor parameters only if you've confirmed the cycle really is structurally unavoidable and say so explicitly in the fix -- it defers when the proxy is resolved rather than fixing the design that created the two-way dependency, so it should be the fallback, not the first move.",
+        "known_wrong": "The fastest fix is to add `@Lazy` to the PaymentService parameter in OrderService's constructor -- that breaks the immediate circular-creation error because Spring injects a proxy instead of eagerly resolving the real bean, and you don't have to restructure anything. This is the standard way to handle a circular dependency in Spring, so I'd just do that and move on.",
+        "vague": "You've got a circular dependency between these two services -- restructure things so they don't need each other directly.",
+        "subtle_wrong": "Add `@Lazy` to the PaymentService constructor parameter in OrderService -- that's the standard, low-risk way to resolve `BeanCurrentlyInCreationException` without a bigger refactor, since Spring just defers resolving the real bean until it's first used. If you want to clean the design up later you could look at extracting shared logic into a third bean, but for getting the context started again, @Lazy here is the right call."
+      },
+      "anti_patterns": ["@Lazy"]
+    }
+  ]
+}