Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Split company tasks and PRs at safe behavioral boundaries
P0 requirement for company/client repositories only; personal repositories are exempt. When decomposing a task or splitting an existing diff, group changes by a complete behavior and its correctness dependencies, not by file, layer or line count. Every mergeable PR must be safe on its declared base if later PRs never ship. Extract an independently valuable bug fix first; keep inseparable redesign pieces, their tests and required CI support together. Review the dependency chain before choosing boundaries.
Bad example
| 1 | { |
| 2 | "A": { |
| 3 | "goal": "Change search membership", |
| 4 | "remainingMismatch": "Cache still uses the old membership rule", |
| 5 | "tests": "Moved to B" |
| 6 | }, |
| 7 | "B": { |
| 8 | "goal": "Change cache membership", |
| 9 | "dependsOn": "A" |
| 10 | }, |
| 11 | "splitReason": "Make both diffs equally small" |
| 12 | } |
Explanation (EN)
A requires a future PR to repair its inconsistent behavior. The file-based split reduces line count but does not produce a safe or independently understandable change.
Objašnjenje (HR)
A zahtijeva buduci PR da popravi nedosljedno ponasanje. Podjela po datotekama smanjuje broj linija, ali ne daje siguran ni samostalno razumljiv rezultat.
Good example
| 1 | { |
| 2 | "A": { |
| 3 | "goal": "Include an omitted identifier in the existing query", |
| 4 | "safeWithoutB": true, |
| 5 | "verification": "Regression test using current cache behavior" |
| 6 | }, |
| 7 | "B": { |
| 8 | "goal": "Unify membership while rebuilding the cache", |
| 9 | "includes": [ |
| 10 | "Shared membership function and all affected callers", |
| 11 | "Recovery implementation", |
| 12 | "Regression and integration tests", |
| 13 | "CI service required to execute those tests" |
| 14 | ], |
| 15 | "dependsOn": "A", |
| 16 | "safeIfLaterWorkStops": true |
| 17 | } |
| 18 | } |
Explanation (EN)
A has value and is correct without the redesign. B contains one coherent behavioral change with its verification. The explicit dependency is safe rather than a promise to fix A later.
Objašnjenje (HR)
A donosi vrijednost i ispravan je bez redizajna. B obuhvaca jednu povezanu promjenu ponasanja i njezinu provjeru. Ovisnost je sigurna, a ne obecanje da ce se A naknadno popraviti.
Notes (EN)
Applicability gate: establish repository ownership from the verified Git remote, never the local folder name. Apply this P0 rule to company/client work for organizations the user works for. Repositories owned by FrankoSolomun are personal and excluded unless the user explicitly identifies the work as company/client work. Other verified organizational/work repositories follow the company default; do not infer company ownership solely from an unfamiliar personal owner. If ownership is unresolved, resolve that context before enforcing this rule. Apply before creating implementation subtasks or branches, when a diff grows beyond its original scope, and when splitting a large PR. Inspect the real ticket outcomes, current callers, read/write contracts, shared invariants, existing tests, rollout constraints and any stacked PRs. Procedure: (1) list observable outcomes and correctness dependencies; (2) group changes that must ship together to preserve those invariants; (3) extract the smallest independently useful fix only if correct on the current base; (4) record for each proposed task its outcome, included and excluded scope, exact base/dependencies, verification and merge order; (5) ask whether deploying this PR while delaying or cancelling all successors leaves the system correct, and whether a reviewer can explain its purpose and validate it using the declared base; (6) move the boundary if either answer is no. Keep tests and the CI support needed to run them with the behavior they verify. Treat changed-line count and review effort as signals to remove unrelated work or find genuine boundaries, never as an arbitrary quota. Recheck the boundaries after implementation changes. A short task plan is enough; do not add process documents to a repository automatically. Distinct from splitting unrelated refactors: this rule checks whether a split of related work preserves correctness.
Bilješke (HR)
Uvjet primjene: utvrdi vlasnika repozitorija iz provjerenog Git remotea, nikad iz naziva lokalne mape. Ovo P0 pravilo vrijedi za poslovne repozitorije firmi i klijenata za koje korisnik radi. Repozitoriji pod FrankoSolomun su osobni i izuzeti, osim ako korisnik izricito navede da je rijec o poslovnom radu. Ostali potvrdeni organizacijski/poslovni repozitoriji smatraju se poslovnima; nepoznati osobni vlasnik sam po sebi ne dokazuje poslovni kontekst. Ako vlasnistvo nije jasno, razjasni kontekst prije primjene. Primijeni prije stvaranja implementacijskih podzadataka ili branchova, kad promjene prerastu pocetni opseg i pri dijeljenju velikog PR-a. Provjeri stvarne ciljeve taska, pozivatelje, ugovore citanja i pisanja, zajednicke uvjete ispravnosti, testove, ogranicenja isporuke i povezane PR-ove. Postupak: (1) popisi rezultate i ovisnosti potrebne za ispravnost; (2) grupiraj ono sto mora zajedno u produkciju; (3) izdvoji najmanji samostalno koristan fix samo ako je ispravan na trenutnoj bazi; (4) za svaki task navedi rezultat, ukljuceni i iskljuceni opseg, bazu i ovisnosti, provjeru i redoslijed mergea; (5) provjeri ostaje li sustav ispravan ako svi kasniji PR-ovi budu odgodeni ili otkazani te moze li reviewer razumjeti i provjeriti ovaj PR uz navedenu bazu; (6) ako ne moze, promijeni granicu podjele. Testovi i CI podrska ostaju uz ponasanje koje provjeravaju. Broj linija i napor reviewa jesu signali za preispitivanje opsega, a ne proizvoljna kvota. Ponovi provjeru nakon promjene implementacije. Dovoljan je kratak plan, bez automatskog dodavanja procesnih dokumenata u repo.
Exceptions / Tradeoffs (EN)
Personal repositories, including FrankoSolomun-owned repositories, are exempt: do not require task decomposition or block their review/delivery under this rule. Stacked PRs are valid when each is correct on its explicit prerequisite base and earlier PRs do not require later ones to repair correctness; review the stack together for integration while presenting each incremental diff. Behavior-preserving preparatory refactors can be separate when they have a concrete consumer, no speculative abstraction and their own verification. A coordinated rollout or feature-gated intermediate state may be justified when independent deployment is impossible, but document and verify that constraint and do not call it independently shippable. A cohesive larger PR is preferable to unsafe artificial fragments; remove unnecessary work before splitting essential correctness pieces.
Iznimke / Tradeoffi (HR)
Osobni repozitoriji, ukljucujuci one pod FrankoSolomun, izuzeti su: ovo pravilo ne zahtijeva njihovu podjelu u taskove niti blokira njihov review ili isporuku. Stackani PR-ovi su prihvatljivi ako je svaki ispravan na izricito navedenoj bazi i raniji PR ne treba kasniji za popravak ispravnosti; provjeri integraciju cijelog niza uz zasebne inkrementalne diffove. Pripremni refaktor bez promjene ponasanja moze biti zaseban uz konkretnog potrosaca, vlastitu provjeru i bez spekulativnih apstrakcija. Koordinirana isporuka ili medustanje iza feature flaga mogu biti opravdani ako neovisna isporuka nije moguca, uz dokumentirano i provjereno ogranicenje. Veci povezan PR bolji je od umjetnih nesigurnih dijelova; prije rezanja bitnih dijelova ukloni nepotreban opseg.