Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Verify repository context and domain distinctions before changing behavior
Before every repository task, identify the repository by its Git remote, read its latest knowledge profile and the relevant current canonical documentation, then verify domain distinctions against target-branch callers. Before completion or handoff, automatically reconcile newly verified, durable repository or integration facts with dated evidence. Leave unchanged profiles alone; keep proposals and unresolved assumptions explicitly marked.
Bad example
| 1 | {"repository":"service-folder","claim":"accountId and customerId are interchangeable","source":"previous chat"} |
Explanation (EN)
A folder name and a remembered conclusion do not establish repository identity or identifier semantics. A proposed change may still be unmerged.
Objašnjenje (HR)
Naziv mape i zaključak iz starog razgovora ne potvrđuju identitet repozitorija ni značenje ID-eva. Predložena promjena možda još nije mergeana.
Good example
| 1 | {"repository":"github.com/example/billing","claim":"invoice.customerId refers to the billing customer, not the login account","status":"confirmed","source":"https://github.com/example/billing/blob/abc123/docs/identity.md","revision":"abc123","checkedAt":"2026-10-05"} |
Explanation (EN)
Repository identity, explicit semantics and a checked source provide a starting point. Read current documentation and verify callers before relying on the recorded claim.
Objašnjenje (HR)
Identitet repozitorija, jasno značenje i provjeren izvor daju polazište. Prije oslanjanja na zapis pročitaj aktualnu dokumentaciju i provjeri pozivatelje.
Notes (EN)
Apply before substantive repository work and again when repository or feature scope changes. Read orientation sources and relevant feature/service slices, not every unrelated document. A loaded profile is not evidence that its linked documentation was read. Missing profiles, unavailable sources and conflicting code/docs must be reported precisely. Keep repo-specific facts in the private central knowledge store, separate from reusable public rules. Source revisions describe what was checked, not a deployment guarantee. Update durable knowledge when explicitly requested or through an authorized learning workflow. Each new ticket or distinct implementation, debugging or review objective starts this lifecycle, even in the same chat. Refresh only the repository profile at task start; reuse it during continuation turns. Standing authorization permits selective maintenance at completion or handoff without another confirmation. Save only non-obvious repository/external-system facts that can change a future decision or prevent a recurring mistake, supported by primary documentation, canonical project docs, code/callers or verified mentor evidence. Skip routine edits, temporary test setup, task diaries, generic advice and already-recorded facts. Read the latest profile before writing, reconcile concepts and stable IDs, preserve unrelated entries, use revision-checked updates and verify persistence. Update verification dates only for sources actually checked, without implying unrelated claims were reverified. Report failed saves accurately; this does not refresh the general coding-rule baseline or authorize background scans, company docs edits, production access or Git publication.
Bilješke (HR)
Primijeni prije rada u repozitoriju te pri promjeni repozitorija ili područja zadatka. Pročitaj orijentacijske izvore i relevantne dokumente značajke i servisa. Učitan profil nije dokaz da je dokumentacija pročitana. Navedi nedostajuće profile, nedostupne izvore i neslaganja koda i dokumentacije. Činjenice o repozitoriju čuvaj u privatnom centralnom znanju, odvojeno od javnih općih pravila. Provjerena verzija ne potvrđuje produkcijski deploy. Trajno znanje mijenjaj na izričit zahtjev ili kroz odobreni postupak učenja. Svaki novi ticket ili zaseban cilj implementacije, debugiranja ili reviewa pokreće ovaj postupak, čak i u istom chatu. Na početku osvježi samo profil repozitorija; tijekom nastavka istog taska koristi učitani kontekst. Trajno odobrenje dopušta selektivnu dopunu pri završetku ili predaji zadatka bez nove potvrde. Spremi samo specifične, netrivijalne činjenice o repozitoriju ili vanjskom sustavu koje utječu na buduću odluku ili sprečavaju ponovljenu grešku, uz provjerene izvore. Preskoči rutinske izmjene, privremeni testni setup, dnevnik taska, opće savjete i već zapisane činjenice. Prije upisa pročitaj aktualni profil, uskladi pojmove i stabilne ID-eve, očuvaj ostale zapise, provjeri reviziju i spremljen rezultat. Datume provjere mijenjaj samo za zaista pročitane izvore, bez impliciranja da su druge tvrdnje ponovno potvrđene. Prijavi neuspjeli upis; postupak ne osvježava opća pravila niti odobrava pozadinske preglede, izmjene dokumentacije firme, produkcijski pristup ili Git objavu.
Exceptions / Tradeoffs (EN)
Non-repository conversation does not require this lookup. A missing profile does not prohibit independent work: read available canonical docs and code, state the gap and ask only if it blocks a decision. Explicit user scope and access restrictions take precedence; this rule never authorizes production access or publication.
Iznimke / Tradeoffi (HR)
Razgovor nevezan za repozitorij ne zahtijeva učitavanje. Nedostajući profil ne blokira neovisan rad: pročitaj dostupnu dokumentaciju i kod, navedi prazninu i pitaj samo ako ona blokira odluku. Korisnikova ograničenja opsega i pristupa imaju prednost; pravilo ne odobrava produkcijski pristup ni objavu.