ci-code-review

Provide a code review for the given pull request.

Follow these steps:

1. Eligibility Check (Sonnet): Check if the PR (a) is closed, (b) is automated/trivial. If so, stop.

2. PR Analysis (Fable): View the PR and return:

   • Summary of the change and its purpose
   • List of new functions, types, enums, or abstractions introduced
   • For each new abstraction: its name, stated purpose (from comments/docs), and intended usage contract

3. Parallel Deep Review (4 Fable agents):

   Pass the PR summary and new abstractions list to each agent.

   a. Semantic Consistency Agent: For each new function/type/enum introduced:

   • Read its definition, documentation, and any comments describing when/how it should be used
   • Find ALL usages of that abstraction within the PR
   • Verify each usage matches the documented intent
   • Flag misuse: e.g., error-handling functions called for wrong error types, validation functions bypassed, enums used inconsistently
   • Pay special attention to: panic/error functions (when should they trigger?), unsafe blocks, security-sensitive operations

   b. Deep Bug Analysis Agent: Read the full context of modified files (not just diff lines).

   • Understand the data flow and control flow around changes
   • Check for logic errors, edge cases, off-by-one errors, resource leaks
   • Verify error handling is appropriate for each failure mode
   • Check that invariants are maintained across the changes

   c. Tech Debt Removal Agent:

   • Understand new abstractions that are introduced, new functions/types/enums
   • Identify possible future usecases for these things and understand whether abstractions meet future requirements
   • See which paradigms of Rust (or other language) development are used and whether they apply here
   • Identify possible improvements that would benefit long term maintainability of the code
   • Be an enjoyer of abstractions: generics, traits, dyn, enums, etc.

   d. Security Reviewer Agent:

   • Identify whether changes to the protocol do not break soundness
   • Identify possible attack vectors that are introduced with these changes
   • Check for input validation gaps at trust boundaries (user input, network data, file I/O, IPC)
   • Verify authentication/authorization checks are not bypassed or weakened
   • Look for injection risks: SQL, command, path traversal, template injection, deserialization
   • Check cryptographic usage: hardcoded secrets, weak algorithms, nonce reuse, timing side-channels
   • Verify resource limits: unbounded allocations, missing timeouts, denial-of-service vectors
   • Check concurrency: TOCTOU races, lock ordering, shared mutable state without synchronization

4. Validate Issues (MANDATORY — do not skip):

   After collecting all issues from the 4 agents, validate every issue scored >= 50.

   For each issue from the agents:

   • For complex logic/semantic issues, reason through whether the bug is real and exploitable.
   • For issues you can verify mechanically (e.g., a failing test), prefer direct verification (run the test).

   Score each issue 0-100 AFTER validation:

   • 0: False positive, doesn't stand up to scrutiny, or pre-existing issue
   • 25: Might be real, but couldn't verify. Stylistic issues without explicit guidance.
   • 50: Verified real issue, but minor/nitpick. Not important relative to PR scope.
   • 75: Verified real issue that will impact functionality. Insufficient existing approach.
   • 100: Confirmed real issue that will happen frequently. Direct evidence confirms it.

5. Post comments to PR: Always post a single review to the PR so the author has confirmation that the review ran, regardless of whether issues were found.

   • When there are validated issues with score >= 50, include them in the comments array.
   • When there are none, post the review with an empty comments array and a body that briefly states no issues were found (1-2 sentences, same tone as the comment guidelines below — concise, senior-engineer voice, no scores/severity labels/ceremony).