Add Qodo review guidelines in .pr_agent.toml

[josephnef]

Summary

Qodo (free open-source tier) already reviews every PR here. Custom Rules / Review Standards are paid-only, but a repo-level .pr_agent.toml is honoured and takes precedence over wiki/org settings. This commits one that encodes the codebase's actual review rules so Qodo's issue-finding and compliance agents look for the things that have bitten this project:

• bounds checks and input caps in native 802.11/IP/UDP/TCP parsing (devourer callbacks, RxFrame, StaLink, wfb-ng)
• WfbngLink device-map / thread lifecycle rules and devourer's single-control-thread contract
• JNI signature and R8 @Keep / proguard requirements
• UI-thread blocking in VideoActivity
• tools/ script hygiene
• compliance: loopback-port module coupling, no hard-coded app paths, generated MAVLink tree, devourer CMake source list vs submodule, non-recursive submodules, clang-format 18.1.8

Inline comments are limited to High/Medium severity; all findings still appear in the summary. One pointer line added to CLAUDE.md.

Test plan

• TOML parses
• CI checks green (docs-only change)
• Next Qodo review on an open PR reflects the guidelines (e.g. /agentic_review on APFPV link mode: join the OpenIPC apfpv camera's open AP with devourer #129)

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Configure repository-level Qodo review guidelines

⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

AI Description

• Add Qodo guidelines for packet safety, threading, JNI, Android, and script reviews.
• Add compliance checks for module boundaries, paths, generated code, submodules, and formatting.
• Limit inline findings to High and Medium severity and link the configuration from CLAUDE.md.

Diagram

graph TD
  PR["Pull requests"] --> Qodo["Qodo app"] --> Config["Repo config"] --> Issues["Issue checks"] --> Findings["PR findings"]
  Config --> Compliance["Compliance checks"] --> Findings
  Docs["CLAUDE.md"] --> Config

Loading

High-Level Assessment

Repository-level configuration is the appropriate approach for supplying these guidelines to Qodo's free tier. Keeping the review policy in CLAUDE.md alone would document it for contributors but would not provide the configured guidance to Qodo.

Files changed (2) +58 / -0

Documentation (1) +1 / -0

CLAUDE.mdPoint contributors to Qodo guidelines +1/-0

Point contributors to Qodo guidelines

• Adds a conventions note identifying .pr_agent.toml as the repository-level location for Qodo review guidance.

CLAUDE.md

Other (1) +57 / -0

.pr_agent.tomlAdd Qodo review and compliance configuration +57/-0

Add Qodo review and compliance configuration

• Adds prioritized issue-finding guidance for native parsing, thread safety, JNI/R8, Android UI work, and shell scripts, plus checks for repository conventions. Configures agentic describe and review commands, disables push-trigger handling, and sets the inline-comment severity threshold to High/Medium.

.pr_agent.toml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Qodo ignores the inline severity limit 🐞 Bug ≡ Correctness

Description

inline_comments_severity_threshold is set to the integer 2 instead of the named severity value
needed to represent Medium. Qodo may reject or ignore the setting, so Low-severity findings can
still receive inline comments despite the documented intent.

Code

.pr_agent.toml[7]

+inline_comments_severity_threshold = 2

Evidence

The configuration comment promises inline comments only for High and Medium findings, but the
setting supplies a numeric integer rather than a named severity value. The setting is introduced
entirely by this PR.

.pr_agent.toml[5-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The inline comment threshold is configured as the numeric TOML value `2`, which does not reliably express the intended Medium severity threshold.
## Fix Focus Areas
- .pr_agent.toml[5-7]
## Recommended Fix
Set `inline_comments_severity_threshold` to the Qodo-supported named severity value for Medium, such as `"MEDIUM"`, while retaining the existing review-agent section.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Reviews reject valid video inputs ✓ Resolved

Description

The compliance rule says module traffic uses loopback UDP, but UDPReceiver binds the video socket
to INADDR_ANY on port 5600. Video sent from the phone's Wi-Fi interface is therefore a supported
non-loopback path that this rule would incorrectly flag.

Code

.pr_agent.toml[R40-42]

+- Modules (app, videonative, wfbngrtl8812, mavlink) communicate only over loopback UDP
+  (5600 video, 14550 MAVLink, 8000/8001 VPN) and the 10.5.0.0/24 TUN; new cross-module native
+  calls or new hard-coded ports without a named constant are violations.

Evidence

The added rule claims the modules communicate only over loopback UDP, while the video receiver binds
to every local interface and the project documentation explicitly advertises video from any sender
on the phone's Wi-Fi.

.pr_agent.toml[40-42]
app/videonative/src/main/cpp/UdpReceiver.cpp[103-108]
CLAUDE.md[100-102]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The compliance guideline incorrectly requires all module UDP communication to use loopback, although the video receiver intentionally accepts packets on all interfaces.
## Fix Focus Areas
- .pr_agent.toml[40-42]
- app/videonative/src/main/cpp/UdpReceiver.cpp[103-108]
- CLAUDE.md[100-102]
## Recommended Fix
Narrow the loopback requirement to the module channels that are actually loopback-only, and explicitly document that the video receiver on port 5600 may accept packets from the phone's Wi-Fi interface.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Native logs keep different tags ✓ Resolved

Description

The compliance guideline requires the pixelpilot tag for Java and C++, but native components
define tags such as FecChangeController, SignalQualityCalculator, TXFrame, and wfb-ng.
Reviews following this rule would report established native logging as noncompliant or fail to
distinguish the repository's actual tag conventions.

Code

.pr_agent.toml[50]

+- Log tag is "pixelpilot" in Java and C++ (devourer logs under "devourer").

Evidence

The added rule states that the log tag is pixelpilot in Java and C++, but the cited native files
define and emit different tags. The inaccurate rule is introduced by this PR.

.pr_agent.toml[50-50]
app/wfbngrtl8812/src/main/cpp/FecChangeController.h[6-8]
app/wfbngrtl8812/src/main/cpp/SignalQualityCalculator.h[9-12]
app/wfbngrtl8812/src/main/cpp/wfb_log.h[4-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new compliance rule says all Java and C++ logs use `pixelpilot`, but several existing native components intentionally use component-specific tags and `wfb-ng`.
## Fix Focus Areas
- .pr_agent.toml[50-50]
- CLAUDE.md[105-105]
- app/wfbngrtl8812/src/main/cpp/FecChangeController.h[6-8]
- app/wfbngrtl8812/src/main/cpp/wfb_log.h[4-23]
## Recommended Fix
Change the guideline to reflect the actual convention: `pixelpilot` is used across Java and most project-owned C++, while devourer and existing wfb-ng/component logging retain their established tags.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. MAVLink reviews assume unsupported C++20 ✓ Resolved

Description

The compliance guideline declares all native code to be C++20, but the MAVLink target does not set a
C++ standard or add a C++20 compile option. Qodo could therefore approve C++20-only changes for that
target even though its build configuration does not guarantee C++20 support.

Code

.pr_agent.toml[51]

+- Native code is C++20, formatted with scripts/format_sources.sh (clang-format 18.1.8).

Evidence

The added rule says native code is C++20, while the MAVLink target definition contains no C++
standard setting; other targets explicitly set C++20, showing that the omission is target-specific
rather than a repository-wide convention.

.pr_agent.toml[51-51]
app/mavlink/src/main/cpp/CMakeLists.txt[20-39]
app/wfbngrtl8812/src/main/cpp/CMakeLists.txt[95-124]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new guideline labels all native code as C++20, but the MAVLink CMake target has no C++20 standard setting.
## Fix Focus Areas
- .pr_agent.toml[51-51]
- app/mavlink/src/main/cpp/CMakeLists.txt[20-39]
- app/wfbngrtl8812/src/main/cpp/CMakeLists.txt[95-124]
## Recommended Fix
Either scope the guideline to targets that explicitly request C++20, or update the MAVLink target to set `CXX_STANDARD 20` and then keep the repository-wide statement.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can move or hide resolved findings to focus on what still needs action

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗