CodeRabbit: disable repo-level auto-review (overrides org 'no auto-reviews')

[sydlexius]

Problem

This repo's CodeRabbit config sets:

reviews:
  auto_review:
    enabled: true

CodeRabbit resolves configuration in this precedence order: PR-level instructions > the repo's .coderabbit.yaml/.yml > org dashboard settings > defaults. Because this repo-level file sets auto_review.enabled: true, it overrides the org-level "no auto-reviews" setting - so CodeRabbit auto-reviews PRs here even though the org is configured not to.

(Surfaced during an org-wide sweep: mxlrcgo-svc, media-automation, and stillwater all had this override. media-automation is being fixed in a PR.)

Proposed change

Set auto_review.enabled: false so the repo honors the org default. Reviews can still be triggered explicitly with @coderabbitai review (manual trigger is unaffected by this flag).

While editing, consider auditing two related keys against your intent:

• reviews.request_changes_workflow - if true, CR posts blocking CHANGES_REQUESTED reviews; false makes them advisory.
• reviews.profile - assertive maximizes nitpicks; chill reduces low-value findings.

Acceptance

• auto_review.enabled: false committed to the CodeRabbit config
• Confirm PRs no longer auto-trigger a CodeRabbit review (manual @coderabbitai review still works)

[coderabbitai]

🔗 Related PRs

#531 - Skip full CI for docs-only PRs, add markdown lint workflow [merged]
#736 - chore: add CodeRabbit review configuration [merged]
#802 - fix: enable CodeRabbit draft PR reviews and approval workflow [merged]
#857 - feat: M33 contextual help icons, sidebar light theme, and violation badge setting [merged]
#1262 - ci(docs): add docs-drift PR guard + CodeRabbit instructions [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[sydlexius]

Follow-up after an org-wide sweep and a reference fix.

Current values in this repo's .coderabbit.yaml:

reviews:
  auto_review:
    enabled: true              # <- overrides the org "no auto-reviews"
  request_changes_workflow: true   # CR posts blocking CHANGES_REQUESTED reviews
  profile: assertive               # maximizes nitpicks

Reference implementation: media-automation made exactly this change in sydlexius/media-automation#165 (merged) - auto_review.enabled: false, with a yaml comment recording the precedence rationale. Copy-paste template if you go that way.

But this one is a genuine decision, not a rubber-stamp. CR's own "Related PRs" on this issue surfaced #802 ("enable CodeRabbit draft PR reviews and approval workflow") - so auto-review here appears to have been turned on deliberately. Unlike media-automation (where manual @coderabbitai review was the explicit goal), stillwater is the heavily CR-integrated project, and you may legitimately want to keep auto-review on. The org-vs-repo conflict is real either way; the question is which one you want to win for this repo:

• Keep auto-review -> no change here; instead exempt this repo at the org level (or accept that repo config wins).
• Match the org default -> set auto_review.enabled: false; manual @coderabbitai review still works. Consider request_changes_workflow: false (advisory, non-blocking) and profile: chill while you're in there.

No CR coding plan requested - this is a one-line config change, so a plan adds no value over the above.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read current .coderabbit.yaml
cat .coderabbit.yaml 2>/dev/null || echo "File not found at root"

echo "---"

# Check PR `#802` title and body for context
gh pr view 802 --repo sydlexius/stillwater --json title,body,mergedAt | jq '{title, mergedAt, body: (.body | .[0:600])}'

echo "---"

# Check .github/copilot-instructions.md for CR-related instructions
cat .github/copilot-instructions.md 2>/dev/null | grep -i "coderabbit\|review" | head -20

Length of output: 8876

---

---

@sydlexius — the evidence strongly favors keeping auto-review on for stillwater. Here's why:

The deliberate intent is unambiguous across three independent signals:

1. PR #802 had an explicit test plan: "Next PR opened as draft gets a CR review automatically" — drafts: true + auto_review.enabled: true was the stated goal, not a side-effect.

2. .github/copilot-instructions.md mandates: "Always request coderabbitai as a reviewer on every PR you open or update." If auto-review were disabled, every Copilot-generated PR would need a manual @coderabbitai review trigger to honor that instruction — defeating the automation loop.

3. The depth of the config itself: 10+ path-based instruction blocks, all lint tools enabled, auto_incremental_review: true, auto_pause_after_reviewed_commits: 0 — this is not a passive install. Someone invested significant effort here.

On request_changes_workflow: true and profile: assertive: Both were deliberate from PR #802. Leave them. Blocking APPROVE/CHANGES_REQUESTED is what makes CR a real gate here, not decoration.

Resolution: The org-vs-repo conflict is real but not a problem — repo config wins, and that's the right outcome for stillwater. If the org sweep is about consistent governance, the cleaner fix is to add a repo-level exemption at the org side (or just document that stillwater intentionally overrides). No change to .coderabbit.yaml is warranted.

Unlike media-automation, where disabling auto-review was the goal, here it would break the workflow that was purposely built in PR #802.

This is the Way.

---

🧠 Learnings used

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 0
File: :0-0
Timestamp: 2026-03-29T18:28:09.700Z
Learning: In sydlexius/stillwater, keep PRs focused on a single concern. CI/workflow changes (e.g., auto-triggering CodeRabbit review on Copilot PRs) must not be mixed into feature or fix PRs. They belong in separate PRs.

---

Learnt from: CR
Repo: sydlexius/stillwater PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2026-03-31T01:04:15.892Z
Learning: Always request `coderabbitai` as a reviewer on every PR that is opened or updated

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 1325
File: web/templates/settings.templ:6417-6455
Timestamp: 2026-05-06T21:53:50.858Z
Learning: Repo: sydlexius/stillwater — In web/templates/settings.templ, dynamic hydration for auto-update metadata (LastAutoApplied row, skip-this-version button, and skipped-versions list) is intentionally deferred and tracked in issue `#1327`. Until `#1327` is closed, treat SSR-only rendering of these elements as acceptable and do not re-flag missing hydration in related PRs.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 1845
File: web/templates/settings_sections.templ:0-0
Timestamp: 2026-06-04T08:04:35.706Z
Learning: Repo: sydlexius/stillwater — In web/templates/settings_sections.templ (and any future extracted Section* components), when new `settings.*` i18n keys are added for transient UI elements (button labels, spinner text, etc.) that should not appear in the generated settings reference docs, add those keys to the `noiseKeysExact` denylist in the gen-settings-reference generator. Similarly, severity/log-level labels belong under `common.*` keys (e.g., `common.trace`, `common.debug`, `common.warn`) which are automatically excluded from the docs scraper. Confirmed via `make generate-docs` producing byte-identical `settings-by-tab.md` and `_settings-anchors.txt` output (established in PR `#1845` commit e200b455).

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 0
File: :0-0
Timestamp: 2026-03-29T18:28:09.700Z
Learning: In sydlexius/stillwater, squash all development and fixup commits into clean, logical commits before the first push when opening a PR. Incremental fixup commits hide the full changeset from reviewers and cause whack-a-mole review cycles.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 0
File: :0-0
Timestamp: 2026-03-29T18:28:09.700Z
Learning: In sydlexius/stillwater, when addressing review comments, read all open comments, plan all fixes, and address them in a single commit. Do not address comments incrementally across multiple commits.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 883
File: web/templates/dashboard.templ:331-400
Timestamp: 2026-04-05T06:04:22.815Z
Learning: In sydlexius/stillwater (`web/templates/dashboard.templ`), the `DashboardActivityRow` / `DashboardActivityFeed` templates render intentionally read-only summaries of recent metadata changes. The undo/revert workflow is handled at the fix endpoint level (`handleFixViolation` captures pre-fix state and registers undo entries with the UndoStore). Adding an expandable old/new field diff view and a revert button directly in the activity feed rows is a planned follow-up enhancement and should not be flagged as missing in PR reviews.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 604
File: api/bruno/auth/create-token.bru:20-21
Timestamp: 2026-03-22T23:19:30.689Z
Learning: For Bruno API test scaffolding under api/bruno/ (*.bru files) in sydlexius/stillwater, allow initial "coverage scaffolding" PRs to include hardcoded payload literals (e.g., "test-token", placeholder UUIDs, fixed query values) without flagging them for parameterization or idempotency issues. Payload parameterization (e.g., using {{tokenName}} instead of a literal string) is deferred to follow-up work and should not be flagged during initial scaffolding PRs. Only enforce parameterization once the test is no longer in initial scaffolding mode.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 1597
File: web/templates/settings.templ:5038-5043
Timestamp: 2026-05-21T05:38:58.070Z
Learning: Repo: sydlexius/stillwater — In web/templates/settings.templ (ProviderKeyCard gear panel), several user-visible strings (“Base URL”, “Rate (req/s)”, “Coming soon”, mirror hints, some “Save” labels) intentionally remain hardcoded because they pre-date the consolidation in PR `#1597`; the full i18n sweep is tracked in issue `#1598`. For future reviews of this panel, do not block the PR on these strings; reference `#1598` instead and suggest keys for the follow-up.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 1282
File: internal/updater/updater.go:1126-1133
Timestamp: 2026-05-02T04:40:04.510Z
Learning: In sydlexius/stillwater, `updater.Config.AutoUpdate` is persisted to the DB but intentionally NOT acted on by `StartScheduler` in the current codebase. The scheduler only calls `Check()`; the auto-apply flow (wiring scheduler to call `Apply()` when `AutoUpdate` is true) requires a confirmation flow, last-applied status, and skip-version affordance before it is safe to ship, and is tracked in issue `#1284`. Do not flag the absence of an auto-apply call in `StartScheduler` as a bug; it is a deliberate deferral.

---

Learnt from: sydlexius
Repo: sydlexius/stillwater PR: 1841
File: web/templates/testdata/section_servers_populated.golden.html:0-0
Timestamp: 2026-06-04T02:37:43.253Z
Learning: Repo: sydlexius/stillwater — PR `#1841` (commit d3af0318) resolved the `window.event` fragility in the `__templ_stillwaterManagedAfterRequest_*` inline handler. The handler was extracted into a globally-loaded module `web/static/js/conflict-gate.js` (loaded by the layout, present on every page) and exposed as `window.swStillwaterManagedAfterRequest`. The HTMX callsite now reads `hx-on:htmx:after-request="swStillwaterManagedAfterRequest(this, event)"` — `event` is threaded explicitly, `window.event` is no longer used. Issue `#1842` was closed as superseded. Future reviews should use `swStillwaterManagedAfterRequest(this, event)` as the canonical callsite pattern for this toggle on both the Settings page and the global ConflictBanner CTA.