Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Verify no external consumers before renaming or removing an API endpoint
Before renaming or deleting an HTTP endpoint, search beyond the current repo for its route string: sibling repos, org-wide code search, and native/mobile apps. Raw fetch URL strings are invisible to typecheck and build, so grep for the literal path. If an external caller exists, migrate it in the same change or defer the rename with an alias — never ship a dangling rename.
Bad example
| 1 | // rename pages/api/tickers-watchlist.ts -> tickers-portfolio.ts |
| 2 | // update only the callers found by typecheck in THIS repo |
Explanation (EN)
Typecheck only sees typed imports in the same repo; another app calling the endpoint via a raw URL string breaks silently in production.
Objašnjenje (HR)
Good example
| 1 | // before renaming, grep the org for the literal route string: |
| 2 | // gh search code 'tickers-watchlist' --owner <org> |
| 3 | // grep -rn 'tickers-watchlist' ../sibling-repo-a ../sibling-repo-b |
| 4 | // only rename once every hit is accounted for (or keep an alias) |
Explanation (EN)
An org-wide literal-string search catches consumers that no compiler can see; each hit is migrated in the same change or the rename is deferred.
Objašnjenje (HR)
Notes (EN)
State the check and its result in the PR description so reviewers do not have to re-ask. Include repos not covered by org code search (e.g. mobile apps in another org).
Exceptions / Tradeoffs (EN)
Endpoints provably private to one app (e.g. session-guarded BFF routes verified unused elsewhere) still deserve the grep, but no alias is needed.