chore: enhance prejudge output with specific failure reasons#14
Conversation
There was a problem hiding this comment.
Pull request overview
Enhances the prejudge CLI output to include more specific failure reasons when a commit is rejected during analysis, improving diagnosability of “false” outcomes.
Changes:
- Print a specific reason when fix commits are missing in the target project.
- Print a specific reason when required CONFIGs are not enabled in any scanned architecture config.
- Print a specific reason when the LLM judge determines vulnerable code is not present.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| print("false, fix commits missing") | ||
| return |
There was a problem hiding this comment.
analyze_and_report docstring states the output is just true/false, but this branch now prints false, ... on stdout. If callers parse stdout as a strict boolean (consistent with judge_llm.py / judge_agent.py printing exactly true/false), this becomes a breaking CLI change. Consider keeping stdout strictly true/false and emitting the reason to stderr (or behind a flag), and update the docstring accordingly.
| if not is_enabled: | ||
| # CONFIG not enabled in any architecture | ||
| print("false") | ||
| print("false, arch not supported") |
There was a problem hiding this comment.
This failure reason is misleading: the condition here is that none of the required CONFIGs are enabled in any of the scanned arch config files, not that the commit/patch targets an unsupported architecture. Consider changing the message to reflect “CONFIG not enabled” (or similar) so users don’t misdiagnose the cause.
| print("false, arch not supported") | |
| print("false, CONFIG not enabled") |
| # Output final result based on agent's decision | ||
| print("true" if agent_result else "false") | ||
|
|
||
| print("true" if agent_result else "false, vulnerable code not found") |
There was a problem hiding this comment.
This changes the final stdout from a strict boolean to a boolean+reason string. To avoid breaking integrations that expect exactly true/false, consider preserving machine-readable stdout (e.g., true/false only) and placing the human-readable reason on stderr or behind an --explain/--verbose option; also update the docstring that still claims the output is only true/false.
No description provided.