Skip to content

docs: surface conflicting patterns instead of averaging them #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jan-kubica merged 1 commit into from
Aug 7, 2026
Merged

docs: surface conflicting patterns instead of averaging them #39

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions modules/engineering.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,15 @@
other or bind them with a compile-time check; never rely on discipline or a
hand-updated mirror test. A lookup whose miss means a bug must panic or emit
telemetry, never fall back silently to a default.
- Surface conflicts, do not average them. When two existing patterns contradict,
adopt one and never blend them into a hybrid. Precedence: documented convention
and enforced guards (lint rules, ratchet metrics, committed baselines), then the
most recent well-tested code, then the most widespread. If a convention and a
guard disagree, that disagreement is itself the finding: report it, do not
resolve it silently. Always report the conflict: the winner, the losing call
sites, and a concrete unification proposal (codemod, lint rule, ratchet metric).
Unifying is a scope decision, so propose it and let the user pick the moment; if
they defer, land the guard so the losing pattern can only shrink.

@coderabbitai coderabbitai Bot Aug 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Add a comma before so.

Line 40 joins two independent clauses. Write land the guard, so the losing pattern can only shrink to keep the guidance grammatically clear.

Proposed fix 
-  they defer, land the guard so the losing pattern can only shrink.
+  they defer, land the guard, so the losing pattern can only shrink.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
they defer, land the guard so the losing pattern can only shrink.
they defer, land the guard, so the losing pattern can only shrink.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~40-~40: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ... moment; if they defer, land the guard so the losing pattern can only shrink. - A...

(COMMA_COMPOUND_SENTENCE_2)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@modules/engineering.md` at line 40, Update the sentence containing “they
defer, land the guard” by inserting a comma before “so,” yielding “land the
guard, so the losing pattern can only shrink.”

Source: Linters/SAST tools

- Avoid boolean fields for states that may grow. Use a named discriminator or
domain type for values that answer "which kind/status/mode/type?" rather than
a permanent yes/no question; a two-value union, enum, or equivalent domain type
Expand Down
Loading