codecheck

# Code Check Run all three code quality checks, read the reports, and propose fixes for any issues found. ## Steps ### 1. Detect the main branch Detect the main/default branch (typically `trunk` or `main`): ```bash git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \ | sed 's@^refs/remotes/origin/@@' ``` If that fails, check if `trunk` or `main` exists and use whichever is found. Store this as `<main-branch>` for later steps. ### 2. Run all three checks in parallel Run these Gradle tasks: ```bash ./gradlew detekt ./gradlew checkstyle ./gradlew lintWordPressRelease ``` Run all three in parallel to save time. Allow each to complete even if others fail. ### 3. Read the reports After the checks complete, read the generated report files: - **Detekt**: `WordPress/build/reports/detekt/detekt.html` - **Checkstyle**: `WordPress/build/reports/checkstyle/checkstyle.html` - **Lint**: `WordPress/build/reports/lint-results-wordpressRelease.html` Parse each report to extract the list of issues (file, line, rule, message). ### 4. Filter to relevant issues Focus on issues in files that were changed on the current branch. To determine changed files: ```bash git diff --name-only $(git merge-base <main-branch> HEAD)..HEAD ``` If no branch changes are detected (e.g., on trunk), report all issues found. ### 5. Present a summary Output a summary table or grouped list of issues organized by tool: - **Detekt issues** (count and details) - **Checkstyle issues** (count and details) - **Lint issues** (count and details) For each issue include the file path, line number, rule name, and the message. ### 6. Propose fixes For each issue, propose a specific fix. Group fixes by file. Show the current code and what it should be changed to. ### 7. Ask for approval Present the proposed fixes and ask the user which ones to apply before making any changes. ## Important Rules - Do NOT make any code changes until the user approves. - Respect the project's code style (120-char line limit, Kotlin conventions, no empty lines after opening braces). - Use TODO instead of FIXME in any comments. - Do not suppress warnings unless the user explicitly approves.