@dailephd/my-dev-kit-lab 0.3.2 → 0.3.4

package/README.md

@@ -2,9 +2,9 @@
 
 my-dev-kit-lab is the experiment, evidence, reporting, security-validation, and audit companion for my-dev-kit. It runs reproducible experiments that test whether my-dev-kit's graph-guided retrieval helps coding-agent workflows, collects metrics, renders reports, generates plots, captures screenshots, builds gallery outputs, performs automated CLI/package security validation, and runs the generic audit framework.
 
-The current published baseline is `v0.3.1`. `v0.3.0` introduced the generic audit framework and the first implemented code-rot detector family; `v0.3.1` added the language-aware code-rot substrate plus TypeScript/JavaScript support. The generic experiment-plugin framework was introduced in `v0.2.0`. The first plugin is `context-strategy-comparison`, which preserves the existing raw-full-file vs my-dev-kit-guided workflow through the plugin runner.
+The current published baseline is `v0.3.3`. `v0.3.0` introduced the generic audit framework and the first implemented code-rot detector family; `v0.3.1` added the language-aware code-rot substrate plus TypeScript/JavaScript support; `v0.3.2` added Python-aware code-rot support and a first security-validation audit adapter; `v0.3.3` adds Java/Kotlin source-facts support and JVM-aware code-rot detector integration. The generic experiment-plugin framework was introduced in `v0.2.0`. The first plugin is `context-strategy-comparison`, which preserves the existing raw-full-file vs my-dev-kit-guided workflow through the plugin runner.
 
-The checked-out package state is `v0.3.2` release-prepared on top of the published `v0.3.1` baseline: Python-aware code-rot support (a Python source-facts analyzer, Python project metadata, and Python-aware dead-code/duplicate-implementation/test-rot detector signals) and a security-validation audit adapter (`npm run audit -- --types security`, mapped security findings, and a `securitySummary` audit report field). Package metadata is bumped for release preparation, but `v0.3.2` is not published yet; Java, Kotlin, cross-language stability, Android validation, framework-aware profiles, and the `quality`/`project`/`all` audit types remain future roadmap work.
+`v0.3.3` is the previously published npm baseline. Java/Kotlin support is conservative static analysis only: dependency-free scanners, static Gradle/Maven metadata detection, and no compiler, classpath, Gradle, Maven, Android, or target-test execution. `v0.3.4` is release-prepared in this repository: package metadata has been bumped to `0.3.4`, adding mixed-language stability coverage, repeated-run report hardening, cross-platform/path normalization tests, CRLF/LF stability checks, and final documentation reconciliation. `v0.3.4` is not yet published to npm, not tagged, and no GitHub release has been created — local Windows validation has passed and a latest-Node cross-platform workflow is configured for ubuntu/macos/windows, but a fresh remote multi-OS run should be verified during publication.
 
 my-dev-kit is most useful when the repository is larger than the task. It helps coding agents work with large codebases through reusable structural indexing, graph-guided retrieval, targeted source slices, and auditable context selection. Results are scoped evidence; the project does not claim that my-dev-kit always saves tokens.
 
@@ -35,8 +35,9 @@ my-dev-kit is most useful when the repository is larger than the task. It helps
 - Plugin-aware JSON and HTML reports with plugin, target, variant, metric, artifact, warning, skip, and failure metadata
 - Security validation framework: dependency audit, package tarball inspection, CLI adversarial tests, static scans (CodeQL/Semgrep), bounded fuzz smoke, attack-scenario checks, and structured verdict/report output — runnable against any local project via `security:validate --target <path>`. `security:validate` remains the standalone, focused security-validation command; it is not replaced by the audit adapter below.
 - Generic audit framework, current published baseline: `npm run audit` runs heuristic, conservative code-rot detectors and writes text/JSON reports under `reports/audits/code-rot/` by default. `code-rot` and `security` are the currently implemented audit types (`--types code-rot`, `--types security`, or combined `--types code-rot,security`); `quality`, `project`, and `all` audit types are planned and fail cleanly instead of running. `npm run audit` supports `--target`, `--types`, and other flags — see [docs/COMMANDS.md](docs/COMMANDS.md). Audit does not modify target files and does not auto-fix issues.
-- Language-aware code-rot support, current checked-out package state: normalized language/file-role inventory, a source-facts model and collector, a TypeScript/JavaScript analyzer, and a Python analyzer. Source facts feed the `dead-code-candidate`, `duplicate-implementation-candidate`, and `test-rot` detectors with parsed-import/export/declaration evidence for both languages. Python project metadata (presence of `pyproject.toml`, `requirements.txt`, `setup.py`/`setup.cfg`, `tox.ini`, `pytest.ini`, and a best-effort project name) is collected and reported as its own audit report field. Java and Kotlin remain inventory-classified but fallback-only; no analyzer is registered for them yet.
-- Security-validation audit adapter, current checked-out package state: `npm run audit -- --types security` runs security validation through the shared audit/report surface by calling the same `runSecurityValidation()` internals `security:validate` uses, maps security findings into audit-issue-shaped entries, and adds a `securitySummary` field (verdict, check counts, finding counts, and links to the original `reports/security/*.txt`/`*.json` report) to audit JSON/text reports. `npm run audit -- --types code-rot,security` runs both audit types together. The original `security:validate` command and its `reports/security/` output are unchanged.
+- Language-aware code-rot support, current published package state: normalized language/file-role inventory, a source-facts model and collector, TypeScript/JavaScript, Python, Java, and Kotlin analyzers, and conservative detector integrations for `dead-code-candidate`, `duplicate-implementation-candidate`, `test-rot`, and `docs-code-mismatch`. Python project metadata remains a top-level audit report field. Java/Kotlin support adds static JVM project metadata detection for Gradle/Maven/source-set shape and conservative source-facts evidence, but no compiler parsing, type resolution, classpath resolution, Gradle/Maven execution, Android validation, or target-project test execution. No `SourceFacts` schema change or new audit command was added for `v0.3.3`.
+- Security-validation audit adapter, current published package state: `npm run audit -- --types security` runs security validation through the shared audit/report surface by calling the same `runSecurityValidation()` internals `security:validate` uses, maps security findings into audit-issue-shaped entries, and adds a `securitySummary` field (verdict, check counts, finding counts, and links to the original `reports/security/*.txt`/`*.json` report) to audit JSON/text reports. `npm run audit -- --types code-rot,security` runs both audit types together. The original `security:validate` command and its `reports/security/` output are unchanged.
+- `v0.3.4` implementation state (release-prepared, not yet published): mixed-language fixture corpus, source-facts invariants, full-registry mixed-language detector stability tests, repeated-run audit report determinism checks, cross-platform/path normalization hardening, CRLF/LF parsing stability coverage, and final documentation reconciliation. Package metadata is bumped to `0.3.4`; it is not yet tagged or published.
 
 ---
 
@@ -207,12 +208,14 @@ See [docs/METRICS.md](docs/METRICS.md) for full metric definitions.
 
 ## Current baseline release positioning
 
-my-dev-kit-lab is at a working baseline. The raw-vs-indexed experiment pipeline is fully implemented and produces reproducible artifacts. Real-agent campaign support exists for Codex and Claude. The current published npm baseline is `v0.3.1`, which includes the generic audit framework, the code-rot detector family, and the language-aware code-rot substrate with TypeScript/JavaScript support, on top of the earlier experiment and automated security-validation work.
+my-dev-kit-lab is at a working baseline. The raw-vs-indexed experiment pipeline is fully implemented and produces reproducible artifacts. Real-agent campaign support exists for Codex and Claude. The previously published npm baseline is `v0.3.3`, which added Java/Kotlin analyzers, JVM metadata detection, Java/Kotlin detector support, and Java/Kotlin/Gradle/Maven docs-code-mismatch checks on top of the published `v0.3.2` baseline.
 
-Planned roadmap direction after the published baseline:
+`v0.3.4` is release-prepared in this repository: package metadata has been bumped to `0.3.4`. It hardens the existing language-aware audit path with mixed-language fixture coverage, detector and report determinism checks, cross-platform/path normalization coverage, CRLF/LF stability coverage, and documentation reconciliation. It does not add a new command. It is not yet published, not tagged, and no GitHub release has been created.
 
-- `v0.3.2`: Python code-rot support plus a first security-validation audit adapter, release-prepared and not yet published
-- `v0.3.3` through `v0.3.4`: Java/Kotlin and cross-language stability for the language-aware code-rot track
+Planned roadmap direction after the previously published baseline:
+
+- `v0.3.3`: Java/Kotlin code-rot support (published)
+- `v0.3.4`: cross-language stability for the language-aware code-rot track (release-prepared in this checkout; not yet published)
 - `v0.4.0` through `v0.4.2`: Android automated security validation, including an Android-specific extension of the security audit adapter
 - manual pentest: post-v1 / version TBD
 

package/dist/scripts/security/validate.js

@@ -1,10 +1,9 @@
 #!/usr/bin/env node
-import path from "node:path";
-import fs from "node:fs";
 import { runSecurityValidation } from "../../src/securityValidation/validate/runSecurityValidation.js";
 import { resolveValidationTarget, reportFilenamePrefix } from "../../src/securityValidation/validate/resolveTarget.js";
-import { renderTextReport, renderJsonReport } from "../../src/securityValidation/report/renderSecurityReport.js";
 import { buildSecurityReportFromSummary } from "../../src/securityValidation/report/buildSecurityReport.js";
+import { renderTextReport } from "../../src/securityValidation/report/renderSecurityReport.js";
+import { writeSecurityReportFiles } from "../../src/securityValidation/report/writeSecurityReportFiles.js";
 import { parseSecurityValidateArgs, normalizeSecurityValidateConfig, applyProfileDefaultChecksIfApplicable, } from "../../src/securityValidation/validate/cliOptions.js";
 import { resolveAttackProfile } from "../../src/securityValidation/attackScenarios/attackProfile.js";
 import { findingsBreachFailOnThreshold } from "../../src/securityValidation/validate/verdict.js";
@@ -90,25 +89,16 @@ const report = buildSecurityReportFromSummary(summary, {
     failOnBreached,
 });
 const textReport = renderTextReport(report);
-const jsonReport = renderJsonReport(report);
 // Determine output directory
 const reportsDir = config.out;
-if (!fs.existsSync(reportsDir)) {
-    fs.mkdirSync(reportsDir, { recursive: true });
-}
 // Determine report filename prefix
 const prefix = args.reportPrefix ?? reportFilenamePrefix(target);
-const txtPath = path.join(reportsDir, `${prefix}-security-validation.txt`);
-const jsonPath = path.join(reportsDir, `${prefix}-security-validation.json`);
-const writtenPaths = [];
-if (config.formats.includes("text")) {
-    fs.writeFileSync(txtPath, textReport, "utf8");
-    writtenPaths.push(txtPath);
-}
-if (config.formats.includes("json")) {
-    fs.writeFileSync(jsonPath, jsonReport, "utf8");
-    writtenPaths.push(jsonPath);
-}
+const { textPath: txtPath, jsonPath, writtenPaths } = writeSecurityReportFiles({
+    outDir: reportsDir,
+    prefix,
+    report,
+    formats: config.formats,
+});
 // Print report to stdout
 console.log(textReport);
 console.log(`\nReports written:`);

package/dist/src/audits/codeRot/detectors/deadCodeCandidateDetector.js

@@ -3,6 +3,7 @@ import { readBoundedFileText } from "../utils/boundedRead.js";
 import { baseNameNoExt, isGenericOrTestPrefixedDeclarationName } from "../utils/filePatternUtils.js";
 import { deduplicateIssuesById, makeCodeRotIssue } from "../utils/issueFactories.js";
 import { collectRelativeImportBasenames, getParsedSourceFacts, indexSourceFactsByPath } from "../utils/sourceFactsLookup.js";
+import { isJvmLifecycleOrConventionalDeclarationName, jvmImportSimpleName } from "../utils/jvmSourceFactsUtils.js";
 // ---------------------------------------------------------------------------
 // v0.3.0 Batch 4 — dead-code candidate detector.
 //
@@ -52,6 +53,7 @@ export const DEAD_CODE_CANDIDATE_DETECTOR = {
         }
         if (ctx.config.include.includes("cli") || ctx.config.include.includes("architecture")) {
             issues.push(...findPossiblyUnreferencedPythonDeclarations(ctx));
+            issues.push(...findPossiblyUnreferencedJvmDeclarations(ctx));
         }
         return deduplicateIssuesById(issues);
     },
@@ -344,6 +346,100 @@ function findPossiblyUnreferencedPythonDeclarations(ctx) {
     }
     return issues;
 }
+// v0.3.3 Batch 2 -- conservative, declaration-level Java/Kotlin dead-code
+// candidate check. Same spirit and lowest severity/confidence tier as
+// findPossiblyUnreferencedPythonDeclarations() above, adapted for the two
+// key differences in what Java/Kotlin source facts can safely support:
+//
+//   - Method/constructor declarations (DeclarationFactKind "method") are
+//     EXCLUDED ENTIRELY, for both languages. There is no call-tracking
+//     evidence in this project's source-facts model for any language
+//     (`references` stays empty everywhere -- see javaAnalyzer.ts's and
+//     kotlinAnalyzer.ts's own header comments), so a method-level check
+//     would have zero real evidence behind it and would flag nearly every
+//     method with equal (lack of) signal -- pure noise. This mirrors the
+//     existing Python check's own "methods are excluded entirely" rule
+//     exactly (see above), just extended to two more languages. This also
+//     conservatively covers Java constructors without needing a dedicated
+//     constructor detector, since javaAnalyzer.ts represents constructors
+//     as kind "method" too.
+//   - Kotlin top-level `fun` declarations (kind "function") ARE
+//     considered, the direct analogue of Python's module-level `def` --
+//     but Java has no equivalent (every Java method lives inside a
+//     class/interface/enum), so only class/interface/enum kinds are
+//     considered for Java.
+//
+// `exported` already folds Java's public/protected/private/package-private
+// and Kotlin's public/internal/protected/private visibility into a single
+// boolean (see both analyzers' "Visibility mapping" header comments) --
+// exported (public) declarations are skipped entirely here, since a public
+// API is expected to be used from outside the scanned file set and this
+// scan has no way to see that.
+function findPossiblyUnreferencedJvmDeclarations(ctx) {
+    if (!ctx.sourceFacts)
+        return [];
+    const index = indexSourceFactsByPath(ctx.sourceFacts);
+    // Cross-file "this simple name was imported somewhere" signal, combined
+    // across Java and Kotlin since either language can import the other in a
+    // mixed JVM project -- the strongest signal this conservative scan can
+    // offer, same role as Python's importedNamesAcrossProject above.
+    const importedSimpleNamesAcrossProject = new Set();
+    for (const facts of index.values()) {
+        if ((facts.language !== "java" && facts.language !== "kotlin") || facts.parseStatus !== "parsed")
+            continue;
+        for (const imp of facts.imports) {
+            importedSimpleNamesAcrossProject.add(jvmImportSimpleName(imp.source));
+        }
+    }
+    const issues = [];
+    for (const facts of index.values()) {
+        if (facts.language !== "java" && facts.language !== "kotlin")
+            continue;
+        if (facts.role !== "source" || facts.parseStatus !== "parsed")
+            continue;
+        for (const decl of facts.declarations) {
+            if (decl.kind === "method")
+                continue; // methods/constructors -- see header comment
+            if (facts.language === "java" && decl.kind === "function")
+                continue; // never produced by javaAnalyzer.ts, defensive
+            if (decl.exported)
+                continue; // public (Java) / public-by-default-or-explicit (Kotlin)
+            if (isJvmLifecycleOrConventionalDeclarationName(decl.name))
+                continue;
+            if (importedSimpleNamesAcrossProject.has(decl.name))
+                continue;
+            const languageLabel = facts.language === "java" ? "Java" : "Kotlin";
+            issues.push(makeCodeRotIssue({
+                auditType: "code-rot",
+                detectorId: DETECTOR_ID,
+                idCues: [`unreferenced-${facts.language}-declaration`, facts.relativePath, decl.kind, decl.name],
+                title: `${languageLabel} ${decl.kind} "${decl.name}" in "${facts.relativePath}" has no detected cross-file import (weak signal)`,
+                description: `"${decl.name}" (${decl.kind}) is declared in "${facts.relativePath}" and is not exported/public, and does not appear as an imported simple name in any other scanned Java/Kotlin file. This is a deterministic static source-facts signal from a conservative, non-semantic scan -- no compiler/classpath analysis was performed, and no Gradle/Maven execution was performed, so this cannot see reflection-based access, dependency-injection wiring, framework/plugin discovery, or usage from outside the scanned project. It may indicate a candidate for removal but is not proof. Confirm manually before removing.`,
+                severity: "info",
+                confidence: "low",
+                falsePositiveRisk: "high",
+                category: "dead-code-candidate",
+                recommendedAction: "Confirm the declaration is genuinely unused before removing it.",
+                suggestedFixStrategy: `Remove "${decl.name}" from "${facts.relativePath}" if confirmed unused, or reference it from another module.`,
+                validationCommands: ["npm run audit -- --types code-rot --include cli"],
+                releaseBlocking: false,
+                implementationBlocking: false,
+                autoFixEligible: false,
+                evidence: [
+                    {
+                        kind: "reference",
+                        message: `Source facts: the ${languageLabel} analyzer parsed this file and found no other scanned Java/Kotlin file importing the simple name "${decl.name}". Static-analysis limitation -- confidence reduced because this scan cannot see reflection/DI usage, framework discovery, or usage outside the scanned file set, and no compiler/classpath analysis was performed.`,
+                        filePath: facts.relativePath,
+                        source: DETECTOR_ID,
+                        confidence: "low",
+                    },
+                ],
+                affectedFiles: [facts.relativePath],
+            }));
+        }
+    }
+    return issues;
+}
 function findOldOrDeprecatedFilesNotInDocs(ctx, docsConcat) {
     const issues = [];
     for (const file of ctx.inventory.files) {

package/dist/src/audits/codeRot/detectors/docsCodeMismatchDetector.js

@@ -1,5 +1,6 @@
 import fs from "node:fs";
 import path from "node:path";
+import { collectJvmProjectMetadata } from "../../core/jvmProjectMetadata.js";
 import { currentClaimPatternFor, plannedClaimPatternFor, FULL_RELEASE_GATE_FOR_SCOPED_CHECKS_PATTERN, isNegatedNearby, } from "../utils/docClaimPatterns.js";
 import { deduplicateIssuesById, makeCodeRotIssue } from "../utils/issueFactories.js";
 import { splitLines } from "../utils/textLines.js";
@@ -27,20 +28,95 @@ const FEATURE_CHECKS = [
         featureId: "security-validation",
         label: "security validation",
         subjectPattern: "security validation",
-        isImplemented: (sot) => sot.security.hasSecurityValidationSourceDir && sot.security.hasSecurityValidateScript,
+        isImplemented: (ctx) => ctx.sourceOfTruth.security.hasSecurityValidationSourceDir && ctx.sourceOfTruth.security.hasSecurityValidateScript,
     },
     {
         featureId: "experiment-framework",
         label: "experiment framework",
         subjectPattern: "experiment (?:framework|plugin)",
-        isImplemented: (sot) => sot.experiment.hasExperimentsSourceDir && sot.experiment.hasExperimentListScript,
+        isImplemented: (ctx) => ctx.sourceOfTruth.experiment.hasExperimentsSourceDir && ctx.sourceOfTruth.experiment.hasExperimentListScript,
+    },
+    // v0.3.3 Batch 3 -- Gradle/Maven/Android feature-claim checks, using only
+    // static JVM metadata (see jvmProjectMetadata.ts). Never runs Gradle,
+    // Maven, or any Android tooling.
+    {
+        featureId: "gradle-support",
+        label: "Gradle",
+        subjectPattern: "Gradle",
+        isImplemented: (ctx) => ctx.jvmMetadata.hasGradleBuild || ctx.jvmMetadata.hasGradleSettings,
+    },
+    {
+        featureId: "maven-support",
+        label: "Maven",
+        subjectPattern: "Maven",
+        isImplemented: (ctx) => ctx.jvmMetadata.hasMavenPom,
+    },
+    {
+        featureId: "android-validation",
+        label: "Android validation",
+        // Negative lookbehind excludes "(non-Android)"-style negated mentions
+        // (this project's own docs legitimately describe things as
+        // "the general (non-Android) ... adapter", which is a claim about the
+        // *adapter*, not about Android -- without this guard, "is implemented"
+        // appearing later in the same sentence about the adapter would
+        // falsely match as an Android claim).
+        subjectPattern: "(?<!non-)Android(?: validation| support)?",
+        // Android automated validation is not implemented anywhere in this
+        // project (see the v0.3.x/v0.4.x roadmap) -- this is a permanently
+        // false signal, not a metadata lookup, so a claim that it is
+        // implemented/current is always a genuine mismatch until a future
+        // version actually builds it. This does not implement any Android
+        // detection itself (no AndroidManifest.xml/Gradle-Android-plugin/
+        // Compose/AGP/SDK/emulator awareness) -- it only reuses the existing
+        // current-vs-planned claim mechanism for a feature this project
+        // already knows, out of band, does not exist.
+        isImplemented: () => false,
     },
 ];
+// v0.3.3 Batch 3 -- backtick-quoted-only Java/Kotlin FQCN-shaped symbol
+// scan (T1-T4). Requiring the mention to be inside an inline code span
+// (`` `com.example.Foo` ``) is what keeps this conservative: ordinary prose
+// mentioning a capitalized word is extremely common and would be far too
+// noisy to scan directly, but a backtick-quoted, fully-dotted,
+// lowercase-package-then-Capitalized-name token is specifically how a
+// real symbol reference is conventionally written in markdown docs.
+const BACKTICK_SPAN_PATTERN = /`([^`]+)`/g;
+const JVM_FQCN_PATTERN = /^[a-z][\w]*(?:\.[a-z][\w]*)*\.[A-Z]\w*$/;
+// Reused by both the symbol-claim check and the Gradle/Maven command-claim
+// check below: a broader set of future/negative-boundary hedge phrases than
+// docClaimPatterns.ts's own HEDGE_PATTERN (which is narrowly scoped to
+// "not yet published"-style wording) -- this project's own docs
+// legitimately say things like "Android support is planned" or "does not
+// support Gradle yet", which must never be treated as a current-state claim.
+const JVM_FUTURE_OR_NEGATIVE_HEDGE_PATTERN = /\b(planned|future|deferred|not yet|out of scope|does not support|doesn't support|will support|not implemented|not supported)\b/i;
+const GRADLE_COMMAND_PATTERN = /\b(?:\.\/)?gradlew(?:\.bat)?\b|\bgradle\b/i;
+const MAVEN_COMMAND_PATTERN = /\bmvnw(?:\.cmd)?\b|\bmvn\b/i;
+// Declaration kinds treated as safe, implementation-weight symbol claims --
+// same conservative kind allowlist Batch 2's duplicate/dead-code checks
+// already use (methods/variables/constants excluded as too noisy/ambiguous
+// for a name-only, no-package-tracking cross-check).
+const JVM_SYMBOL_DECLARATION_KINDS = new Set(["class", "interface", "enum", "function"]);
+function collectKnownJvmDeclarationNames(ctx) {
+    const names = new Set();
+    if (!ctx.sourceFacts)
+        return names;
+    for (const file of ctx.sourceFacts.files) {
+        if (file.language !== "java" && file.language !== "kotlin")
+            continue;
+        if (file.parseStatus !== "parsed")
+            continue;
+        for (const decl of file.declarations) {
+            if (JVM_SYMBOL_DECLARATION_KINDS.has(decl.kind))
+                names.add(decl.name);
+        }
+    }
+    return names;
+}
 export const DOCS_CODE_MISMATCH_DETECTOR = {
     id: DETECTOR_ID,
     auditType: "code-rot",
     title: "Documentation/code mismatch",
-    description: "Detects deterministic mismatches between documentation claims and source-of-truth data: feature-implementation claims and full-release-gate-for-scoped-checks wording.",
+    description: "Detects deterministic mismatches between documentation claims and source-of-truth data: feature-implementation claims, full-release-gate-for-scoped-checks wording, and (v0.3.3) Java/Kotlin symbol claims plus Gradle/Maven feature/command claims against static JVM metadata.",
     supportedIncludeAreas: ["docs", "architecture", "cli", "package"],
     shouldSkip: (ctx) => {
         if (!ctx.config.include.includes("docs")) {
@@ -50,6 +126,13 @@ export const DOCS_CODE_MISMATCH_DETECTOR = {
     },
     run: (ctx) => {
         const issues = [];
+        // v0.3.3 Batch 3 -- computed once per run, same "cheap, static,
+        // presence-only" treatment as pythonMetadata/jvmMetadata elsewhere in
+        // this codebase (see testRotDetector.ts). Never runs Gradle/Maven/any
+        // JVM tooling.
+        const jvmMetadata = collectJvmProjectMetadata(ctx.target.rootPath, ctx.inventory);
+        const featureCtx = { sourceOfTruth: ctx.sourceOfTruth, jvmMetadata };
+        const knownJvmDeclarationNames = collectKnownJvmDeclarationNames(ctx);
         for (const docFile of ctx.inventory.docsFiles) {
             const content = readBoundedText(ctx.target.rootPath, docFile.relativePath, docFile.sizeBytes);
             if (content === null)
@@ -58,9 +141,12 @@ export const DOCS_CODE_MISMATCH_DETECTOR = {
             for (let i = 0; i < lines.length; i++) {
                 const line = lines[i];
                 for (const feature of FEATURE_CHECKS) {
+                    if (feature.featureId === "security-validation" && isAndroidScopedSecurityValidationClaim(line)) {
+                        continue;
+                    }
                     const currentMatch = currentClaimPatternFor(feature.subjectPattern).test(line);
                     const plannedMatch = plannedClaimPatternFor(feature.subjectPattern).test(line);
-                    const implemented = feature.isImplemented(ctx.sourceOfTruth);
+                    const implemented = feature.isImplemented(featureCtx);
                     if (currentMatch && plannedMatch) {
                         // Same line claims both current and planned for the same
                         // subject -- genuinely ambiguous, reported as low-confidence
@@ -78,11 +164,120 @@ export const DOCS_CODE_MISMATCH_DETECTOR = {
                 if (FULL_RELEASE_GATE_FOR_SCOPED_CHECKS_PATTERN.test(line) && !isNegatedNearby(line)) {
                     issues.push(makeFullReleaseGateIssue(docFile.relativePath, i + 1, line));
                 }
+                if (!JVM_FUTURE_OR_NEGATIVE_HEDGE_PATTERN.test(line)) {
+                    issues.push(...findJvmSymbolClaimMismatches(docFile.relativePath, i + 1, line, jvmMetadata, knownJvmDeclarationNames));
+                    issues.push(...findJvmBuildCommandClaimMismatches(docFile.relativePath, i + 1, line, jvmMetadata));
+                }
             }
         }
         return deduplicateIssuesById(issues);
     },
 };
+// v0.3.3 Batch 3 -- T1/T2/T3/T4. Gated on the project having ANY real
+// Java/Kotlin source at all (jvmMetadata.hasJavaSource/hasKotlinSource) --
+// without this gate, a project with no JVM code whatsoever (e.g. this repo
+// itself) would have every backtick-quoted FQCN-shaped mention trivially
+// "fail" to match anything, which would be pure noise rather than a real
+// signal. Matches by simple declaration name only (see
+// collectKnownJvmDeclarationNames()'s header comment) -- this cannot verify
+// the claimed package prefix actually matches, only that some declaration
+// with that name exists somewhere in the scanned Java/Kotlin source, which
+// is why this is always a "weak signal" candidate, never a proof.
+function findJvmSymbolClaimMismatches(relativePath, lineNumber, line, jvmMetadata, knownJvmDeclarationNames) {
+    if (!jvmMetadata.hasJavaSource && !jvmMetadata.hasKotlinSource)
+        return [];
+    const issues = [];
+    BACKTICK_SPAN_PATTERN.lastIndex = 0;
+    for (const match of line.matchAll(BACKTICK_SPAN_PATTERN)) {
+        const candidate = match[1];
+        if (!JVM_FQCN_PATTERN.test(candidate))
+            continue;
+        const simpleName = candidate.slice(candidate.lastIndexOf(".") + 1);
+        if (knownJvmDeclarationNames.has(simpleName))
+            continue;
+        issues.push(makeCodeRotIssue({
+            auditType: "code-rot",
+            detectorId: DETECTOR_ID,
+            idCues: [relativePath, "jvm-symbol-claim-mismatch", String(lineNumber), candidate],
+            title: `Docs mention a Java/Kotlin symbol not found in static source facts: "${candidate}"`,
+            description: `${relativePath}:${lineNumber} mentions \`${candidate}\`, but no scanned Java/Kotlin declaration named "${simpleName}" was found. This is a static source-facts signal from a conservative, name-only scan -- it cannot verify the claimed package prefix, only that no declaration with this simple name exists anywhere in the scanned Java/Kotlin file set, so this is a candidate docs-code mismatch (weak signal), not proof.`,
+            severity: "info",
+            confidence: "low",
+            falsePositiveRisk: "high",
+            category: "docs-feature-mismatch",
+            recommendedAction: `Confirm "${candidate}" exists (it may be defined outside the scanned source set) before treating this as stale documentation.`,
+            suggestedFixStrategy: `Update ${relativePath} to reference an existing Java/Kotlin symbol, or add the missing declaration.`,
+            validationCommands: ["npm run audit -- --types code-rot --include docs"],
+            releaseBlocking: false,
+            implementationBlocking: false,
+            autoFixEligible: false,
+            evidence: [
+                {
+                    kind: "file",
+                    message: `Static source-facts check did not find a Java/Kotlin declaration named "${simpleName}" in the scanned file set.`,
+                    filePath: relativePath,
+                    line: lineNumber,
+                    excerpt: line.trim().slice(0, 200),
+                    source: DETECTOR_ID,
+                    confidence: "low",
+                },
+            ],
+            affectedFiles: [relativePath],
+        }));
+    }
+    return issues;
+}
+// v0.3.3 Batch 3 -- T6/T7/T8/T9. Only matches a Gradle/Maven command token
+// inside a backtick-quoted inline code span, for the same "conventionally
+// how a real command example is written" reasoning as the symbol check
+// above. This never claims the command would actually succeed -- only that
+// docs present a command example implying a build tool this project's
+// static metadata does not show any trace of.
+function findJvmBuildCommandClaimMismatches(relativePath, lineNumber, line, jvmMetadata) {
+    const issues = [];
+    BACKTICK_SPAN_PATTERN.lastIndex = 0;
+    for (const match of line.matchAll(BACKTICK_SPAN_PATTERN)) {
+        const candidate = match[1];
+        if (GRADLE_COMMAND_PATTERN.test(candidate) && !jvmMetadata.hasGradleBuild && !jvmMetadata.hasGradleSettings && !jvmMetadata.hasGradleWrapper) {
+            issues.push(makeBuildCommandIssue(relativePath, lineNumber, line, candidate, "Gradle", "no Gradle execution was performed"));
+        }
+        if (MAVEN_COMMAND_PATTERN.test(candidate) && !jvmMetadata.hasMavenPom) {
+            issues.push(makeBuildCommandIssue(relativePath, lineNumber, line, candidate, "Maven", "no Maven execution was performed"));
+        }
+    }
+    return issues;
+}
+function makeBuildCommandIssue(relativePath, lineNumber, line, commandExcerpt, toolLabel, executionNote) {
+    return makeCodeRotIssue({
+        auditType: "code-rot",
+        detectorId: DETECTOR_ID,
+        idCues: [relativePath, `${toolLabel.toLowerCase()}-command-claim-mismatch`, String(lineNumber), commandExcerpt],
+        title: `Docs include a ${toolLabel} command example, but no ${toolLabel} metadata was found: "${commandExcerpt}"`,
+        description: `${relativePath}:${lineNumber} shows the command \`${commandExcerpt}\`, but no ${toolLabel} build/config metadata was found in the project (see jvmProjectMetadata.ts's static presence checks). This is a candidate docs-code mismatch (weak signal), not proof -- ${executionNote}, so this scan cannot confirm the command would actually run.`,
+        severity: "info",
+        confidence: "low",
+        falsePositiveRisk: "high",
+        category: "docs-feature-mismatch",
+        recommendedAction: `Confirm ${toolLabel} metadata exists (it may live outside the scanned inventory) before treating this as stale documentation.`,
+        suggestedFixStrategy: `Update ${relativePath} to remove or correct the ${toolLabel} command example, or add the corresponding ${toolLabel} project files.`,
+        validationCommands: ["npm run audit -- --types code-rot --include docs"],
+        releaseBlocking: false,
+        implementationBlocking: false,
+        autoFixEligible: false,
+        evidence: [
+            {
+                kind: "file",
+                message: `Static source-facts/metadata check did not find ${toolLabel} build metadata; ${executionNote}.`,
+                filePath: relativePath,
+                line: lineNumber,
+                excerpt: line.trim().slice(0, 200),
+                source: DETECTOR_ID,
+                confidence: "low",
+            },
+        ],
+        affectedFiles: [relativePath],
+    });
+}
 function makeCurrentButMissingIssue(relativePath, lineNumber, excerpt, feature) {
     return makeCodeRotIssue({
         auditType: "code-rot",
@@ -217,3 +412,6 @@ function readBoundedText(root, relativePath, sizeBytes) {
         return null;
     }
 }
+function isAndroidScopedSecurityValidationClaim(line) {
+    return /\bAndroid\b[^.\n]{0,60}\bsecurity validation\b/i.test(line) || /\bsecurity validation\b[^.\n]{0,30}\bfor Android\b/i.test(line);
+}

package/dist/src/audits/codeRot/detectors/duplicateImplementationDetector.js

@@ -2,6 +2,7 @@ import { readBoundedFileText } from "../utils/boundedRead.js";
 import { firstPathSegment, GENERIC_INFRA_BASENAMES, baseNameNoExt, isGenericOrTestPrefixedDeclarationName, } from "../utils/filePatternUtils.js";
 import { deduplicateIssuesById, makeCodeRotIssue } from "../utils/issueFactories.js";
 import { indexSourceFactsByPath } from "../utils/sourceFactsLookup.js";
+import { isJvmCommonLowSignalDeclarationName } from "../utils/jvmSourceFactsUtils.js";
 // ---------------------------------------------------------------------------
 // v0.3.0 Batch 4 — duplicate/parallel implementation candidate detector.
 //
@@ -250,6 +251,16 @@ function findDuplicateDeclarationCandidates(ctx) {
             const nameLower = decl.name.toLowerCase();
             if (isGenericOrTestPrefixedDeclarationName(nameLower))
                 continue;
+            // v0.3.3 Batch 2 -- Java/Kotlin-specific common/low-signal name
+            // suppression (Main, App, Config, Service, Controller, test*, ...).
+            // Gated to java/kotlin so existing TS/JS/Python behavior is
+            // unaffected -- a TS/JS file exporting `class Service {}` (a very
+            // ordinary, non-generic name in that ecosystem) must keep being
+            // considered, unlike the JVM ecosystem where these names are
+            // conventionally near-meaningless boilerplate labels.
+            if ((facts.language === "java" || facts.language === "kotlin") && isJvmCommonLowSignalDeclarationName(nameLower)) {
+                continue;
+            }
             // v0.3.2 Batch 2 -- the key is scoped by `facts.analyzerId` (not
             // `facts.language`) so a Python declaration is only ever compared
             // against other Python declarations, never against a same-named
@@ -264,7 +275,14 @@ function findDuplicateDeclarationCandidates(ctx) {
             // TypeScript/JavaScript duplicate behavior" regression this batch
             // must not introduce. Scoping by `analyzerId` fixes the real
             // cross-language bug (Python vs TS/JS) without touching TS/JS's own
-            // existing behavior at all.
+            // existing behavior at all. v0.3.3 Batch 2 -- this same scoping is
+            // why Java ("java-analyzer") and Kotlin ("kotlin-analyzer") never
+            // group with each other, TS/JS, or Python: they are two distinct
+            // analyzers with two distinct ids, deliberately not unified into one
+            // "JVM" scope in this batch (a same-named Java class and Kotlin
+            // class are not the same declaration in the same language, and
+            // conflating them risks a false "duplicate" signal across languages
+            // that don't even share syntax).
             const key = `${facts.analyzerId}:${decl.kind}:${nameLower}`;
             const entry = byKey.get(key) ?? { name: decl.name, kind: decl.kind, paths: new Set() };
             entry.paths.add(facts.relativePath);