--- name: spring-verify description: Verify Java and Spring changes with existing Maven, tests, ArchUnit, lint, build, and optional SonarQube checks. Use before declaring completion, after failures, or when reviewing whether evidence covers the current code. --- # Verify and repair 1. Read [project context](../java-spring-updates/references/project-context.md) and [current evidence](rules/verification-current-evidence.md). Confirm which commands and reports cover the affected modules and required checks. Record a baseline before editing when practical; otherwise describe what can and cannot be attributed to the change. 2. If focused checks are configured, run `node /dist/cli.mjs verify --root --tier focused` after a coherent change; otherwise run the configured complete tier. Read `.springboot-agent/reports/latest.json` and the referenced diagnostics. A missing configuration or prerequisite is a verification gap. 3. For failures, use [failure and repair](references/failure-and-repair.md). Read the relevant repository rule and task-specific Java/Spring rule before the smallest repair. Stop after three unsuccessful repairs of the same failure, or earlier when the failure remains unchanged or the remedy exceeds task scope. 4. Rerun failed and affected checks, then `node /dist/cli.mjs verify --root --tier complete`. When the repository enables SonarQube, also run `--tier remote`; obtain its matching quality-gate result. 5. Run `node /dist/cli.mjs evidence --root ` after the last edit; this checks the complete tier. If remote checks are required, also check `evidence --tier remote`. Finish when required evidence matches the current inputs, or report the remaining failed, blocked, pending, skipped, or unconfigured checks. Inspect any changes to tests, architecture rules, lint exclusions, or build policy explicitly. For COBOL migration or repairs to translated Java, also load [migration evidence](../cobol-to-springboot/rules/migration-equivalence-evidence.md). Confirm required comparison suites are configured and report their provenance and gaps separately from build/design checks. ## Completion report State the changed behavior, checks that executed, remaining failures/gaps, and the report path. Preserve pre-existing failures in the overall status. Report a complete pass only when every required check has current passing evidence. Local hooks are feedback; the repository's required CI checks provide independent acceptance for the submitted revision.