CLI-247 Post tool use

[kirill-knize-sonarsource]

No description provided.

[sonar-review-alpha]

Summary

This PR implements the claude-post-tool-use hook handler, which triggers SQAA (SonarQube Static Analysis Analysis) on files after an agent edits or writes them.

Previously, the hook command was a no-op stub. This PR replaces it with a functional handler that:

• Reads tool metadata (tool name and file path) from stdin
• Validates the tool is Edit or Write and the file exists
• Checks authentication is set up for SonarCloud
• Calls the existing SQAA API to analyze the file
• Outputs results (issues/errors) as JSON for the agent to see

The implementation is defensive by design—it silently returns without output if authentication is missing, the file doesn't exist, the tool is not Edit/Write, or analysis fails. This prevents hook failures from blocking agent workflows.

What reviewers should know

Start with the main implementation: src/cli/commands/hook/agent-post-tool-use.ts is the entry point. The agentPostToolUse function orchestrates the flow: parse stdin → validate conditions → call SQAA API → format and output results.

Understand the defensive design: The function uses early returns to skip processing without output. This is intentional—see the comments around each condition (tool name, file existence, auth). The handler should never crash a hook.

Review the command registration: src/cli/command-tree.ts shows how the function is wired into the CLI. Note the change from optional to required --project option.

Focus on tests for behavior clarity: The unit tests in tests/unit/hook-post-tool-use.test.ts comprehensively cover both happy-path (analysis succeeds) and edge cases (no auth, missing file, unparseable stdin). The integration tests in tests/integration/specs/hook/hook-agent-post-tool-use.test.ts verify end-to-end behavior. These tests document the expected behavior better than comments do.

Note the result format: The output is wrapped in hookSpecificOutput with hookEventName: 'PostToolUse' and additionalContext containing formatted issue/error text. This is how the agent receives feedback from the hook.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[hashicorp-vault-sonar-prod]

CLI-247

[sonar-review-alpha]

Conclusion: The hook implementation itself is clean and the unit test suite is thorough. One logic duplication worth fixing, and the quality gate needs addressing before merge.

SonarQube Cloud status: Coverage on new code is at 69.1%, below the required 80% threshold. The integration test added in this PR targets an analyze sqaa edge case (unregistered project with --branch) rather than exercising the new agent-post-tool-use hook — so coverage of agent-post-tool-use.ts comes entirely from unit tests. See the reviewer guide above for details.

🗣️ Give feedback

[sonar-review-alpha]

Logic duplication: formatSqaaResult reimplements the same logic as displaySqaaResults in src/cli/commands/analyze/sqaa.ts (line 162). Both iterate over issues with the same [idx+1] message (line startLine) structure and handle the errors array the same way. They've already diverged: displaySqaaResults puts the rule on a separate Rule: X line, while this version inlines it as [rule].

If the output format needs to change (e.g. adding severity, effort, or a new field), both functions must be updated. Extract shared formatting logic — for example a buildSqaaIssueLines(issues, errors): string[] helper in a shared module — and have each caller apply its own output target on top.

• Mark as noise

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
86.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

LGTM! ✅

The logic duplication flagged in the previous round (the formatSqaaResult formatter re-implementing the same structure as displaySqaaResults) is still open and unresolved.

🗣️ Give feedback