REVIEW RULES
Set a higher standard for every finding.
Use a clear review agreement: evidence, impact, a useful next step, and a human decision. These guidelines complement your existing checks.
Rule 1: Show a concrete failure path
A finding should identify the condition that triggers the issue, explain what the changed code does, and describe the observable effect. “This could be unsafe” is a starting question, not a complete review.
- Point to the relevant changed line or nearby context.
- Explain why an existing validation or authorization guard does not prevent the issue.
- Separate verified behavior from assumptions that still need checking.
Rule 2: Review the change in context
Check the pull request’s purpose and current revision. Consider intentional removals, expected errors, and boundaries enforced by callers. When context is missing, ask for it instead of inventing a requirement.
AntiCode built-in checks inspect only the supplied diff. They do not read every file, private specification or repository history.
Rule 3: Prioritize correctness before preference
Discuss security, incorrect results, broken behavior, and demonstrated performance regressions first. Keep formatting and naming debates in a separate convention checklist or formatter.
- Critical/high: investigate plausible severe impact promptly; validate before acting.
- Medium: assess affected users, conditions, and release scope.
- Low: useful refinements can be tracked without obscuring more consequential issues.
Rule 4: Keep sensitive values out of discussion
Do not reproduce live tokens, passwords, personal data, or customer records in comments and examples. If you find a real secret, follow your incident process and rotate it with the relevant provider. Deleting a line is not sufficient containment.
Rule 5: Test the proposed fix
A suggested change is advice. Verify the fix against the failure case, run the relevant existing tests, and check for a regression in neighboring behavior. Do not merge solely because the assistant returned no findings.
Rule 6: Record decisions without hiding evidence
Accept or dismiss findings with a reason in your team’s normal review conversation. Personal triage does not resolve another reviewer’s queue or change the source. Enterprise shared triage records team assignments and decisions separately, without claiming a fix was independently verified.
What AntiCode enforces today
CodHub supports read-only repository discovery and bounded pull-request sync. Built-in checks are available only for SHA-1 repositories when CodHub supplies a complete diff with matching file, addition and deletion counts. Missing counts, incomplete diffs and SHA-256 reviews are rejected without replacing previous findings.
Repository access and exact revision identity are checked before a saved review is presented as current. Your severity and path preferences filter your view; they do not prove an issue fixed or establish a repository-wide policy. The template below is a human review agreement, not executable AntiCode configuration.
CodHub AI reviews, automatic reviews, comment delivery, CI ingestion, coding proposals and repository scans are not enabled in this release. Historical GitHub workflows do not establish those capabilities for CodHub. AntiCode does not execute repository code, approve or merge pull requests.
# Team review agreement
- Describe the user-visible intent of the change.
- Identify the trigger and impact of each suspected bug.
- Cite the current revision and relevant source location.
- Keep credentials and personal data out of examples.
- Test the fix and preserve human approval before merge.