qodo: review standards, compliance gates, and a PR template by widgetii · Pull Request #2268 · OpenIPC/firmware

widgetii · 2026-08-16T12:49:19Z

Problem

Maintainers are spending review cycles rejecting pull requests that look plausible but are structurally wrong for this project. The objections are consistent, but they live in maintainers' heads and get re-typed by hand every time.

Three recently closed PRs, and what was actually wrong with each:

Add Sony IMX662 sensor to build system #2241 — hardcoded the contributor's own device-under-test sensor into general/overlay/etc/init.d/S70vendor and the shared load_hisilicon SNS_TYPE0 default. The overlay ships to every camera, so this changes the sensor on already-deployed cameras at upgrade time. It also added ~1200 lines of bring-up tooling under tools/imx662/ that no Config.in selects and CI never compiles, and repointed HISILICON_OPENSDK_SITE at a personal fork while Config.in:8 still named OpenIPC/openhisilicon.
gk7102: BR2_TARGET_OPTIMIZATION=-mno-unaligned-access #2260 — a toolchain flag on two boards, with a test plan whose boxes were never checked and no before/after evidence from a board.
Gk7201v200 support #2234 — 43 .ko files extracted from a camera's factory firmware, a kernel module rewriting vendor blob .bss at runtime, generated libhi_*.so facades committed as blobs, LD_PRELOAD in S95majestic, a kernel patch, and a single-board ircut script.

What this adds

Mirrors the Qodo Merge setup already in use on majestic — .pr_agent.toml points the review agent at two companion files:

File	Role
`best_practices.md`	19 judgement-based rules across 7 sections, each written from a PR that was actually closed
`pr_compliance_checklist.yaml`	12 binary pass/fail gates
`.github/PULL_REQUEST_TEMPLATE.md`	Problem / Hardware tested on / Evidence / Scope — the repo had no template, so contributors' tools have been inventing their own

The rules cover blast radius (generic config vs one bench), provenance (package SITE, version pins, blobs), repo boundaries (kernel → OpenIPC/linux, single board → OpenIPC/builder, probing tools → OpenIPC/ipctool, streamer bugs → majestic), no monkey-patching (LD_PRELOAD, runtime blob patching), hardware evidence, and dead code.

They judge substance, not style. .pr_agent.toml explicitly instructs the agent not to speculate about whether a change was AI-written, and not to flag writing style, comment density, or formatting. Those signals are unfalsifiable and punish thorough contributors. A change is judged on blast radius, provenance, evidence, and repo ownership.

Evidence

No hardware involved — this is review configuration and documentation, and it changes nothing in any image. Verified as follows.

Both files parse, and the gate schema matches majestic's key-for-key:

YAML OK: 12 gates, schema clean
TOML OK. sections: ['github_app', 'review_agent']
keys in majestic but not here: none

Retrospective test — each closed PR trips the rules it should, confirmed against the real diffs:

PR	Trips
#2241	SITE-is-a-fork, help-text mismatch, device-specific-in-overlay, unwired-sources, §1.1 §1.2 §2.1 §2.3 §3.3 §6.2
#2260	toolchain-flag-unmeasured, hardware-evidence, §1.3 §5.2
#2234	LD_PRELOAD, blobs-without-source, kernel-patch, single-board, runtime-patching, §2.4 §3.1 §3.2 §4.1 §4.2 §4.3

False-positive test — the more important one. Walked the same rules over merged #2267, #2248, and #2266. None trips a gate. Two carve-outs were needed to get there, and both are now written into the rules:

hisilicon-osdrv-hi3516cv200: add GC2023 MIPI sensor variant #2248 adds GC2023-over-MIPI by extending an existing case arm in a shared load_hisilicon. That is additive and changes no board's default, so it must pass — only a change to an existing SNS_TYPE*, default resolution, or default profile is a finding. Its new .ini is picked up by an existing files/sensor/config/*.ini install glob and needs no .mk change.
ci: parse-check every shell script that ships in the image #2266 touches only .github/ scripts, which run under bash on CI runners. The shell-convention gate is scoped to scripts that ship in the image (general/overlay/, general/package/*/files/) and excludes .github/ and contrib/.

Two corrections worth flagging

While verifying, two of my own draft rules turned out to be wrong and were fixed:

The bot's finding on gk7102: BR2_TARGET_OPTIMIZATION=-mno-unaligned-access #2260 was factually incorrect. It claimed BR2_TARGET_OPTIMIZATION="-mno-unaligned-access" clobbers -Os -pipe and de-optimises every package. It does not. That kconfig string is appended to TOOLCHAIN_WRAPPER_OPTS (buildroot-2023.02.1/toolchain/toolchain-wrapper.mk:22), while the -O level comes independently from BR2_OPTIMIZE_* (buildroot-2023.02.1/package/Makefile.in:114-133); Buildroot's own help text says "gcc optimization level is defined in build options". §1.3 now describes the real mechanism — a whole-image codegen change needing measurement — and tells reviewers not to repeat the clobbering claim.
A "full 40-char SHA" gate would have failed hisilicon-opensdk: bump ff20187b → 2d637e35 (V4 mic tone on cold boot, osal timer teardown) #2267, i.e. this repo's own most recent merged commit. The tree is not uniform: 15 packages pin 40 characters, hisilicon-opensdk has always pinned 8, and several track HEAD. The gate is now "a bump must not make the pin less specific", which still catches Add Sony IMX662 sensor to build system #2241's 8→7 regression without failing ordinary bumps.

Scope

No kernel patches under general/package/all-patches/linux/
No files specific to a single retail camera model
No probing or bring-up tooling
Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a board-specific value
No package sources changed
No LD_PRELOAD, and no binaries
No code added — nothing to build; the four files affect review only and do not enter any image

Notes for reviewers

These run automatically. The Qodo Merge app is already installed here and already auto-reviews new PRs — it commented on Add Sony IMX662 sensor to build system #2241 within 59 seconds of it being opened, well before this config existed. [github_app] pr_commands sets which commands run when a PR is opened, reopened, or marked ready for review; it does not decide whether they run. This PR therefore changes what the existing automatic review says, not when it fires. (An earlier draft of this description claimed review was manual-only. That was wrong.)
They do not re-run on later pushes. handle_push_trigger defaults to off, so a PR is reviewed on open, not on each new commit. Set handle_push_trigger = true plus push_commands if that is wanted.
Nothing here blocks a merge. Qodo posts comments and a compliance label; it is not a required status check. Turning a gate into a hard block needs branch protection, which is a separate decision — see the alternative Qodo itself raised in its review of this PR.
No GitHub Actions workflow is added.
The two lists are deliberately split the way majestic splits them: pr_compliance_checklist.yaml holds only binary, objectively checkable gates; anything needing judgement lives in best_practices.md.
Wording is meant to be argued with. If a gate would have blocked a PR you consider good, that is a defect in the gate — say so and it gets narrowed.

🤖 Generated with Claude Code

Mirrors the three-file Qodo Merge setup already in use on majestic: .pr_agent.toml points the review agent at best_practices.md (judgement calls) and pr_compliance_checklist.yaml (binary gates). Rules were derived from PRs that were actually closed: #2241 device-under-test sensor hardcoded into general/overlay/ S70vendor and a shared load_hisilicon default; 1200 lines of unwired tools/imx662/; HISILICON_OPENSDK_SITE repointed at a personal fork while Config.in still named OpenIPC/openhisilicon #2260 toolchain flag with an unrun test plan and no hardware evidence #2234 vendor .ko files extracted from factory firmware, runtime patching of blob .bss, generated facade .so blobs, LD_PRELOAD in S95majestic, a kernel patch, and a single-board script They judge blast radius, provenance, evidence, and repo ownership. They deliberately do not judge writing style: .pr_agent.toml instructs the agent not to speculate about AI authorship or flag comment density and formatting, which is unfalsifiable and false-positives on thorough contributors. Checked against merged #2267, #2248, and #2266 so ordinary work does not trip a gate. Two carve-outs came out of that: adding a sensor to a load script is additive and passes (#2248 extends a case arm and changes no default), and the shell-convention gate is scoped to scripts that ship in the image, not .github/ or contrib/ (#2266). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

qodo-free-for-open-source-projects · 2026-08-16T12:50:24Z

PR Summary by Qodo

Add Qodo review standards, compliance gates, and PR template

✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add Qodo agent configuration to guide reviews toward project-specific standards
• Document review standards and repo-boundary rules derived from previously closed PRs
• Introduce hard compliance gates and a PR template to require hardware evidence and scope

Diagram

graph TD
  A(("Contributor")) --> B["PR template (.github)" ] --> C["GitHub Pull Request"] --> D["Qodo review agent"] --> E["best_practices.md"]
  D --> F["pr_compliance_checklist.yaml"]
  D --> G[".pr_agent.toml"]

High-Level Assessment

The following are alternative approaches to this PR:

1. Enforce gates via GitHub Actions (blocking status checks)

➕ Prevents merges that violate hard gates without requiring manual /agentic_review
➕ Creates consistent enforcement independent of reviewer attention
➕ Can provide deterministic, auditable pass/fail results
➖ Higher maintenance burden and potential for false positives blocking legitimate work
➖ Harder to scope checks to only changed lines without sophisticated tooling
➖ May slow contributor iteration if checks are too strict early on

2. Keep only a PR template + CONTRIBUTING.md (no agent-specific config)

➕ Tool-agnostic guidance; works for all contributors regardless of Qodo usage
➕ Less coupling to a specific review agent schema and features
➕ Easier for humans to interpret and discuss
➖ Does not convert standards into repeatable gates; reviewers still re-type objections
➖ Lower compliance rates when guidance is optional and not enforced

3. Encode all rules as compliance gates (no separate best_practices.md)

➕ Single source of truth for agent behavior
➕ More consistent application (less reviewer judgment variance)
➖ Hard to formalize nuanced, context-dependent guidance without over-blocking
➖ More churn in YAML schema as standards evolve

Recommendation: The PR’s split approach is the best default: keep binary, objective checks in pr_compliance_checklist.yaml and keep judgment calls in best_practices.md, with .pr_agent.toml explicitly constraining the agent away from style/AI-authorship speculation. Consider adding optional (non-blocking) GitHub Action reporting later if maintainers want enforcement without relying on manual /agentic_review.

Files changed (4) +691 / -0

Documentation (2) +408 / -0

PULL_REQUEST_TEMPLATE.mdAdd PR template requiring problem, hardware, evidence, and scope +56/-0

Add PR template requiring problem, hardware, evidence, and scope

• Introduces a structured PR template with explicit sections for symptom/problem, hardware tested, before/after evidence, and a scope checklist. The checklist nudges contributors away from kernel patches, single-board work, unwired sources, LD_PRELOAD, and unpinned/non-reproducible sources.

.github/PULL_REQUEST_TEMPLATE.md

best_practices.mdDocument firmware review standards derived from previously closed PRs +352/-0

Document firmware review standards derived from previously closed PRs

• Adds a comprehensive set of review standards organized around blast radius, provenance, repo boundaries, anti-monkey-patching rules, evidence expectations, and dead-code/scope control. Includes concrete examples of rejected patterns and clarifications to avoid known misinterpretations (e.g., toolchain flag mechanics, version pin specificity).

best_practices.md

Other (2) +283 / -0

.pr_agent.tomlConfigure Qodo review agent commands and review/compliance guidance +91/-0

Configure Qodo review agent commands and review/compliance guidance

• Adds Qodo configuration enabling /agentic_describe and /agentic_review, sets inline comment severity threshold, and provides detailed project-specific guidance emphasizing blast radius, provenance, repo boundaries, evidence requirements, and dead code avoidance. Explicitly instructs the agent to avoid style policing and AI-authorship speculation.

.pr_agent.toml

pr_compliance_checklist.yamlAdd 12 objective compliance gates for PR review +192/-0

Add 12 objective compliance gates for PR review

• Defines a set of binary pass/fail compliance checks (e.g., no LD_PRELOAD, no unrebuildable binaries, no personal-fork SITE, non-loosening version pins, no device-specific defaults in shared config, no kernel patches in-tree). Scopes checks carefully (e.g., shipped scripts vs .github) and documents success/failure criteria to reduce false positives.

pr_compliance_checklist.yaml

qodo-free-for-open-source-projects · 2026-08-16T12:52:32Z

Code Review by Qodo

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

1. ~~Wrong toolchain flag claim~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

.pr_agent.toml claims setting BR2_TARGET_OPTIMIZATION “silently drops the -Os -pipe” defaults, but
best_practices.md in this same PR explicitly says BR2_TARGET_OPTIMIZATION is separate from the -O
level (BR2_OPTIMIZE_*) and warns reviewers not to make the clobbering claim. This contradiction will
bias the review agent and humans toward factually incorrect findings on future PRs touching
toolchain flags.

Code

.pr_agent.toml[R38-41]

+2. Buildroot defaults replaced instead of extended. BR2_TARGET_OPTIMIZATION and its peers
+   are whole-value assignments: setting one to a single new flag silently drops the -Os
+   -pipe that every package was built with. The symptom is a size and performance
+   regression across the entire image, with nothing in the diff naming it.

Evidence

The agent guidance asserts BR2_TARGET_OPTIMIZATION drops -Os -pipe, while the repo’s own
best-practices text (added in this PR) explicitly states the -O level is controlled separately by
BR2_OPTIMIZE_* and warns not to claim clobbering—so both statements cannot be true simultaneously.

.pr_agent.toml[38-41]
best_practices.md[92-93]

Agent prompt

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

## Issue description
`.pr_agent.toml` instructs reviewers that `BR2_TARGET_OPTIMIZATION` assignments drop `-Os -pipe`, but `best_practices.md` added in the same PR states the `-O` level comes from `BR2_OPTIMIZE_*` and explicitly says not to claim clobbering. This internal contradiction will produce incorrect automated reviews.
### Issue Context
- Update the guidance so `.pr_agent.toml` matches the more precise explanation already present in `best_practices.md`.
- Avoid asserting that `-pipe` (or any specific baseline flags) are universally present unless you can ground it in this repo’s actual Buildroot config.
### Fix Focus Areas
- .pr_agent.toml[38-41]
- best_practices.md[92-93]

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

2. ~~Undefined bashism enforcement~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

The “Shipped scripts follow tree conventions” compliance gate requires scripts to “avoid bashisms”
but does not define which constructs are disallowed nor how they’re detected, while the repo’s CI
coverage is explicitly syntax-only and does not report “a bashism that ash accepts”. As a hard
compliance gate, this creates objectively-unclear enforcement and risks inconsistent pass/fail
outcomes across reviewers/automation.

Code

pr_compliance_checklist.yaml[R165-168]

+      parse-checks every shipped script against busybox ash, but it is deliberately
+      syntax-only — a bashism that parses still fails on the device, so review covers it.
+    success_criteria: >
+      Shell scripts that ship in the image parse under busybox ash and avoid bashisms,

Evidence
The compliance checklist introduces the vague “avoid bashisms” requirement, but the repository’s own
CI script states it is syntax-only and that bashisms accepted by ash are not reported—demonstrating
the gate is not currently defined/enforced in an objective way.
pr_compliance_checklist.yaml[160-176]
.github/scripts/test_shell_parse.sh[21-33]
.github/workflows/shell-tests.yml[49-56]

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 rule for shipped shell scripts includes an undefined requirement to “avoid bashisms”, but the repo’s current CI enforcement is syntax-only and explicitly does not audit bashisms. As a binary compliance gate, the rule should either (a) define an explicit, checkable set of prohibited patterns or (b) remove/relax the bashism language to match what’s enforced.
### Issue Context
- `test_shell_parse.sh` intentionally targets BusyBox `ash` with `ASH_BASH_COMPAT` and is syntax-only.
- If you want a true “no bashisms” rule, you need a concrete definition + enforcement (e.g., `checkbashisms` with a curated allowlist, or ShellCheck configured for ash + a prohibited-feature list).
### Fix Focus Areas
- pr_compliance_checklist.yaml[160-176]
- .github/scripts/test_shell_parse.sh[21-33]
- .github/workflows/shell-tests.yml[49-56]

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

3. ~~Stale Buildroot path references~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

best_practices.md hard-codes Buildroot file paths under buildroot-2023.02.1/, but this repo’s
Makefile downloads Buildroot 2024.02.10 into output/buildroot-$(BR_VER). These stale paths make the
standards harder to verify and maintain because readers won’t find the referenced files in a normal
workspace.

Code

best_practices.md[R81-83]

+`BR2_TARGET_OPTIMIZATION` is appended to `TOOLCHAIN_WRAPPER_OPTS`
+(`buildroot-2023.02.1/toolchain/toolchain-wrapper.mk`), so it is injected into every
+compilation unit the board builds — kernel modules, vendor SDK glue, busybox, majestic,

Evidence

best_practices.md cites buildroot-2023.02.1/... as the location of relevant implementation
details, but the repo’s Makefile defines BR_VER=2024.02.10 and uses output/buildroot-$(BR_VER) as
the extracted Buildroot directory.

best_practices.md[81-93]
Makefile[1-2]

Agent prompt

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

## Issue description
`best_practices.md` references Buildroot internals under `buildroot-2023.02.1/...`, but the repo’s build flow downloads Buildroot `$(BR_VER)` (currently `2024.02.10`) under `output/buildroot-$(BR_VER)`. The hard-coded versioned paths are stale/non-portable.
### Issue Context
The goal is not to lock to a specific Buildroot release in docs; it’s to help reviewers find the right file in this repository’s actual build layout.
### Fix Focus Areas
- best_practices.md[81-93]
- Makefile[1-2]

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

4. ~~SHA pin rules conflict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The PR template requires package sources be pinned to a full 40-character SHA or a tag, but both
best_practices.md and pr_compliance_checklist.yaml state the repo has established exceptions (e.g.,
hisilicon-opensdk uses 8-char SHAs; some packages track HEAD) and that preserving the established
format is not a finding. This inconsistency will confuse contributors and reviewers and can cause
unnecessary churn in version pins.

Code

.github/PULL_REQUEST_TEMPLATE.md[54]

+- [ ] Package sources come from an OpenIPC repository, pinned to a full 40-character SHA or a tag

Evidence

The template mandates full 40-char SHAs, but both the best-practices and compliance checklist
explicitly document that the repository is not uniform (40-char, 8-char, and HEAD all exist) and
that keeping a package’s established pin format is not itself a finding.

.github/PULL_REQUEST_TEMPLATE.md[54-55]
best_practices.md[126-130]
pr_compliance_checklist.yaml[60-69]

Agent prompt

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

## Issue description
`.github/PULL_REQUEST_TEMPLATE.md` asserts a universal “full 40-character SHA or tag” rule, but the standards/gates introduced in the same PR explicitly allow established short-SHA/HEAD conventions for specific packages. Align the template with the documented policy.
### Issue Context
The template is user-facing and will be treated as canonical by contributors; it should reflect the nuanced rule: keep or increase specificity vs the previous value, and prefer 40-char for newly added packages.
### Fix Focus Areas
- .github/PULL_REQUEST_TEMPLATE.md[54-55]
- best_practices.md[126-130]
- pr_compliance_checklist.yaml[60-69]

ⓘ 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 add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Addresses the three findings from Qodo's review of this PR: 1. (high) .pr_agent.toml told the agent that BR2_TARGET_OPTIMIZATION "silently drops the -Os -pipe", contradicting best_practices.md in the same PR, which says the -O level comes independently from BR2_OPTIMIZE_* and warns reviewers not to make that claim. The toml half was left over from an earlier draft. Both now describe the same mechanism: the string is appended to TOOLCHAIN_WRAPPER_OPTS in toolchain/toolchain-wrapper.mk and reaches every compilation unit, which is why it needs measurement — not because it drops -Os. 2. (medium) best_practices.md cited buildroot-2023.02.1/... paths. Buildroot is not vendored: .gitignore excludes buildroot-*/ and the Makefile downloads BR_VER (2024.02.10) into output-<board>/buildroot-$(BR_VER)/. References are now version- agnostic and say where to find the files. Mechanism re-verified against 2024.02.10 upstream: toolchain-wrapper.mk:22 and Makefile.in:117-135,173 are unchanged from what the rule describes. 3. (medium) The PR template demanded a full 40-character SHA while best_practices.md and the checklist both allow a package's established format (hisilicon-opensdk pins 8 chars, several track HEAD). Template now matches: a bump must not lose specificity, and a new package should pin 40 characters. Also adds .github/workflows/qodo-gate.yml, mirroring OpenIPC/devourer. Branch protection alone cannot hold a PR for a review that has not been posted yet — Qodo answers a minute or two after open, so a green-CI merge can race past it. The gate stays red until Qodo has reviewed the PR once and every thread it opened is resolved. Not pinned to head, so responding to review does not start a re-review treadmill; handle_push_trigger stays off for the same reason and /review summons one on demand. Making it binding needs the check added to branch protection on master. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fourth review finding: the "Shipped scripts follow tree conventions" gate required scripts to "avoid bashisms" without defining the term, which is not a binary check and so does not belong in the compliance file at all — it contradicts that file's own premise that gates are objective. Worse, on this target the rule would flag working code. The shipped busybox is built with CONFIG_ASH_BASH_COMPAT=y (general/package/busybox/busybox.config:1138), so `function name()` and friends are valid on the device, and four scripts that run on real hardware are rejected by dash: both hi3516cv6xx and hi3519dv500 load_hisilicon, msc313e auto_run.sh, infinity6e zoom.sh. This is already documented at length in .github/scripts/test_shell_parse.sh, which deliberately checks against ash and nothing stricter. The gate now keeps only what is mechanical — modprobe over insmod, open_* naming — and explicitly tells reviewers not to raise portability there, since shell-tests.yml already covers syntax. The judgement half moves to best_practices.md §7.1, which names the constructs busybox ash genuinely lacks (arrays, declare/typeset, ${var^^}, ${!var}, herestrings), requires the reviewer to say which one applies, and records why dash is the wrong bar. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

qodo-free-for-open-source-projects · 2026-08-16T14:20:14Z

❌ PR-Agent failed to apply 'local' repo settings

The configuration file needs to be a valid TOML, please fix it.

Error message:
Forbidden directive: preload

Configuration content:

The gate looked only for a review OBJECT by the bot. Qodo creates one when it has inline comments to hang on the diff, so every PR it finds something in has one — which is why this passed on #2268 and on every devourer PR checked. A clean PR gets no review object at all. On #2269 Qodo reported "Bugs (0), Rule violations (0), Requirement gaps (0)" as a plain issue comment and created nothing else, so the gate failed with "no Qodo review on this PR yet" and could never go green — the check blocked hardest precisely when there was nothing to fix. Accept either signal: a review object, or an issue comment headed "Code Review by Qodo". The header is matched specifically rather than "any comment by the bot", because Qodo also posts "Qodo is busy working" (a placeholder written before it has read anything), "PR Summary by Qodo" (/describe output), and the "failed to apply 'local' repo settings" error. Counting those would pass a PR the agent never reviewed. Verified against the live API: #2269 now 0 objects + 1 comment -> PASS, #2268 1 + 1 -> PASS, and the three noise comments are all rejected. Thread resolution is unaffected: a zero-finding PR opens no threads, so the unresolved count is 0 and the gate falls through to PASS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

widgetii requested review from cronyx, flyrouter and viktorxda as code owners August 16, 2026 12:49

qodo-free-for-open-source-projects Bot reviewed Aug 16, 2026

View reviewed changes

Comment thread .pr_agent.toml Outdated

Comment thread best_practices.md Outdated

Comment thread .github/PULL_REQUEST_TEMPLATE.md Outdated

Comment thread pr_compliance_checklist.yaml Outdated

widgetii and others added 2 commits August 16, 2026 16:02

widgetii enabled auto-merge (squash) August 16, 2026 13:30

widgetii merged commit e0453c7 into master Aug 16, 2026
111 checks passed

widgetii mentioned this pull request Aug 16, 2026

qodo: unbreak the config loader, and stop the gate blocking clean PRs #2269

Merged

3 tasks

widgetii mentioned this pull request Aug 16, 2026

qodo-gate: re-evaluate when Qodo posts its review comment #2272

Merged

3 tasks

Navigation Menu

Uh oh!

Uh oh!

qodo: review standards, compliance gates, and a PR template - #2268

qodo: review standards, compliance gates, and a PR template#2268
widgetii merged 3 commits into
masterfrom
qodo-review-rules

widgetii commented Aug 16, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

widgetii commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

What this adds

Evidence

Two corrections worth flagging

Scope

Notes for reviewers

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

widgetii commented Aug 16, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Aug 16, 2026 •

edited

Loading