@leing2021/super-pi 0.30.4 → 0.30.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leing2021/super-pi",
-  "version": "0.30.4",
+  "version": "0.30.5",
   "private": false,
   "type": "module",
   "description": "Pi-native Compound Engineering package for iterative development workflows",

package/rules/common/code-smells.md

@@ -32,6 +32,14 @@ Each entry reads *what it is* → *how to fix*. Match against the diff, not the
 - **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.
 - **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
 
+## Dependency-axis tags (reinvented-wheel check)
+
+The 12 smells above cover structure; these three catch **rebuilding what already exists**. Same binding rules apply (repo overrides, always a judgement call, default P2). One line per finding: location, what to cut, what replaces it.
+
+- **`stdlib:`** — hand-rolled code the language's standard library already ships. → name the function that replaces it (e.g. a manual loop building a dict vs `dict(zip(keys, values))`; hand-rolled path joining vs `pathlib`).
+- **`native:`** — a dependency or custom code doing what the platform already provides. → name the native feature (e.g. moment.js for one format call vs `Intl.DateTimeFormat`; a JS date-picker lib vs `<input type="date">`; app-level uniqueness checks vs a DB constraint).
+- **`dependency:`** — a new package added for what a few lines or an already-installed dependency can do. → inline it or use the existing dep; add the new one only when the hand-rolled version grows real complexity.
+
 ## What is deliberately NOT here
 
 These are Fowler's file-level smells, **excluded from the review baseline** because they read against a whole file, not a diff — weak signal in a diff-based review. They belong in architecture audit (`references/module-design.md`) and `03-work` REFACTOR, not in `04-review` Standards axis:

package/rules/common/coding-style.md

@@ -32,6 +32,34 @@ Rationale: Immutable data prevents hidden side effects, makes debugging easier,
 - Avoid speculative generality
 - Start simple, then refactor when the pressure is real
 
+### The Ladder
+
+Before writing code, stop at the **first rung that holds**:
+
+1. Does this need to exist at all? → No: skip it, say so in one line (YAGNI)
+2. Already in this codebase? → Reuse it. Search before writing; re-implementing what exists a few files over is the most common slop
+3. stdlib does it? → Use it
+4. Platform-native feature covers it? → Use it (native input over a picker lib, CSS over JS, DB constraint over app code)
+5. Already-installed dependency solves it? → Use it. Never add a new one for what a few lines can do
+6. Can it be one line? → One line
+7. Only then: the minimum code that works
+
+Meta-rules:
+- The ladder runs **after** understanding the problem, not instead of it. Lazy about writing, never about reading — trace every file the change touches first.
+- Bug fix = **root cause**, not symptom. The root-cause fix is usually the smaller diff: one guard in the shared function beats a guard in every caller.
+
+Never simplify away: trust-boundary validation, error handling that prevents data loss, security, accessibility, anything explicitly requested.
+
+### Debt marker
+
+When deliberately cutting a corner with a known ceiling (global lock, O(n²) scan, naive heuristic), mark it:
+
+```
+// debt: global lock, upgrade when per-account throughput matters
+```
+
+Name the ceiling and the trigger. A `debt:` marker with no upgrade condition is rot risk, not minimalism. Audit with `rg 'debt:'`.
+
 ## File Organization
 
 MANY SMALL FILES > FEW LARGE FILES: