@jjchill/probity-rules 0.4.4 → 0.4.5

package/CHANGELOG.md

@@ -1,5 +1,31 @@
 # Changelog
 
+## 0.4.5
+
+The Kotlin and KMP TDD judge no longer blocks a behavior-preserving
+extraction under green (#48).
+
+- **Moving tested logic into a helper is allowed as a refactor, not
+  only as green.** The 0.4.4 instruction for #46 described the move
+  only as a green step for a failing test. The judge then read it as
+  the sole way an extraction could pass, and required a fresh red for
+  a plain refactor. Removing duplicated logic from two use cases was
+  blocked with every test green: "the move-existing-logic allowance
+  requires ... a failing test needing this call path". The
+  instruction now names both phases. In green, the move serves a
+  failing test. In refactor, no failing test is needed when the most
+  recent relevant test or build run passed and none is outstanding.
+  It also says a move includes rewiring a caller to the helper, and
+  renaming the helper, its parameters or its result type. A helper
+  with logic that appears nowhere in the session, or a move that adds
+  a branch, still needs its own red.
+  Live judge on a replica of the recorded #48 session (green build,
+  both copies grepped, no failing test): adding the helper was allowed
+  2 of 6 times on 0.4.4 and 8 of 8 on 0.4.5. Rewiring a caller passed
+  on both. Controls stayed denied 8 of 8 on 0.4.5: a helper with new
+  logic under green, moved logic plus a new branch, and the three
+  0.4.4 controls.
+
 ## 0.4.4
 
 Fixes for a one-test Kotlin write that reached the AI judge and was

package/dist/internal/kotlin-tdd.js

@@ -10,7 +10,7 @@ const KOTLIN_TDD_ADDENDUM = `## Kotlin/JVM TDD clarification
 - Kotlin-specific exception to the generic placeholder guidance: when a targeted, relevant Kotlin test executes a \`TODO()\` placeholder and reports \`kotlin.NotImplementedError\`, that runtime failure is a clean red. Do not require a second run that reaches an assertion before replacing the placeholder. The implementation remains bounded by the assertions present in the relevant test source visible in the recent session.
 - A compile, unresolved-import, or signature failure is not a clean red. It authorizes only placeholder, signature, or scaffolding work needed to make the test runnable; it does not authorize implementing the asserted behavior.
 - One observed failing test may require one cohesive green write across multiple methods or branches when every changed method and branch is required by assertions present in that same relevant test source. No artificial test rerun is required between parts of that one atomic write. If the relevant assertions are not visible in the recent session, the red authorizes placeholder or scaffolding work only; do not infer that it authorizes production behavior.
-- Moving existing, tested logic is not new behavior. Suppose a green write moves logic that production code already has into a shared helper, including any small result type the helper needs, so that the code path an observed failing test needs can call it. That is the minimum green for that test, not over-implementation, as long as the same logic appears in the current file content or in a production file read or edited in the recent session. The behavior already exists and is covered; only its location changes. The helper keeps every branch the existing logic has, and the result cases for them, even when the new failing test asserts only one of them: those branches are moved, not added, and the first caller's tests cover them. Do not require the helper to be trimmed to what the new test asserts, and do not require the logic to be duplicated in the second caller instead. A helper holding logic that appears nowhere else in the session is still new behavior and needs its own red.
+- Moving existing, tested logic is not new behavior. A write that moves logic production code already has into a shared helper, or that replaces that logic in a caller with a call to such a helper, changes where the behavior lives, not what it is. It counts as a move when the same logic, branch for branch, appears in the current file content or in production code the recent session shows (read, grepped, or edited). Renaming the helper, its parameters, or its result type (for example a small sealed result replacing each caller's own) is part of the move. A move is allowed in two phases. In green, when an observed failing test needs a second caller to reach the logic, the move is the minimum green: the helper keeps every branch the existing logic has, even if the new test asserts only one, and do not require the logic to be duplicated instead. In refactor, no failing test is needed: when the most recent relevant test or build run in the session passed and no failing test is outstanding, the move is the refactor step, and demanding a new failing test for it is wrong. Either way, a helper holding logic that appears nowhere else in the session, or a move that adds a branch or behavior the existing logic lacks, is new behavior and needs its own red.
 - Git staging and git-index state are irrelevant. Judge only the recent session evidence, current file content, and pending action; do not require a test or production file to be staged.`;
 /**
  * Kotlin sessions commonly include Gradle output plus several source reads between

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jjchill/probity-rules",
-  "version": "0.4.4",
+  "version": "0.4.5",
   "description": "Versioned Probity rule presets and CLI tooling for the agent-skills catalog (test-driven-development, ports-and-adapters, acceptance-testing, spec-test parity, ubiquitous-language) — see hooks/PROBITY.md.",
   "license": "MIT",
   "repository": {