@leing2021/super-pi 0.30.4 → 0.30.6

package/README.md

@@ -109,12 +109,13 @@ Super Pi is not a fork or wrapper. It extracts useful methods from the projects
 | Project | What Super Pi adopted |
 |---------|------------------------|
 | [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) | "Use when" skill trigger conditions, source-driven verification, stop-the-line hard gate, anti-rationalization, and the five-axis review baseline. Adopted as embedded micro-patterns only — no new skills, tools, commands, or agents. |
-| [everything-claude-code](https://github.com/affaan-m/everything-claude-code) | Checkpoint resume, continuous learning loops, and token-conscious agent workflow design. |
+| [everything-claude-code (ECC)](https://github.com/affaan-m/ECC) | Checkpoint resume, continuous learning loops, and token-conscious agent workflow design. (Repo renamed; original link dead.) |
 | [humanlayer/12-factor-agents](https://github.com/humanlayer/12-factor-agents) | Context window ownership, compacting resolved errors, retry caps, and pre-fetching obvious prerequisites. Adopted as lightweight context hygiene rules inside the existing Phase 1 pipeline. |
-| [superpowers](https://github.com/obra/superpowers) | Strict TDD gates, design checklists, review discipline, and the idea that agents need hard gates instead of gentle suggestions. |
-| [compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin) | The five-step think → plan → build → review → learn loop and the knowledge-compounding backbone. |
+| [superpowers](https://github.com/obra/superpowers) | Strict TDD gates, design checklists, review discipline, the rationalization table (excuse → reality), and the idea that agents need hard gates instead of gentle suggestions. |
+| [compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin) | The five-step think → plan → build → review → learn loop, the knowledge-compounding backbone, and solution retirement (knowledge must be able to leave, not only accumulate). |
 | [gstack](https://github.com/garrytan/gstack) | YC-style forcing questions, CEO Review cognitive frameworks, browser QA patterns, failure maps, and evidence-first validation. |
 | [mattpocock/skills](https://github.com/mattpocock/skills) | Context glossary (`CONTEXT.md`), lightweight ADR (three-condition threshold + "What qualifies" catalog), feedback-loop-first debug discipline, deep-module vocabulary (module/interface/depth/seam/adapter/leverage/locality + internal seams + rejected framings), interview discipline (facts-vs-decisions, one-question-at-a-time), the review Spec axis, and the out-of-scope knowledge base. Absorbed as self-contained `skills/references/` content — no external path deps, no issue-tracker deps, no standalone skills grafted (super-pi's existing 01-brainstorm/domain-language/module-design already cover the active disciplines). |
+| [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) | The Ladder (7-rung minimalism decision chain: need-to-exist → codebase reuse → stdlib → platform-native → installed dep → one line → minimum), the `debt:` marker convention (name the ceiling and upgrade trigger), and dependency-axis review tags (`stdlib:` / `native:` / `dependency:`) flowing into the 04-review Standards axis. Embedded into `rules/common/` — no intensity tiers, no hooks/MCP, no standalone skills. |
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leing2021/super-pi",
-  "version": "0.30.4",
+  "version": "0.30.6",
   "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:

package/skills/03-work/SKILL.md

@@ -55,6 +55,15 @@ Anti-rationalization — when a gate fails or evidence is missing:
 - Stop, report the blocker with evidence, and either fix the root cause or ask for direction.
 - Do not continue unrelated implementation after failed verification.
 
+Common rationalizations and their reality:
+
+| Excuse | Reality |
+|--------|---------|
+| "Close enough — the gate almost passed" | A failed gate means not done. Fix it or stop and report; those are the only exits. |
+| "One more retry will converge" | Past the 3-failure cap, retries do not converge — the failure is structural. Ask for direction. |
+| "The fix is tiny, skip re-verification" | Unverified fixes are how regressions land. Every fix ends with verification. |
+| "This failure is a special case" | No evidence, no exception. Treat it like every other failure. |
+
 This is a hard gate — do not push past a failing test or broken build to continue implementation. Errors compound.
 
 ## Error compaction after recovery

package/skills/05-learn/SKILL.md

@@ -37,7 +37,7 @@ See [shared pipeline instructions](../references/pipeline-config.md) for model r
 - Every solution MUST include YAML frontmatter per `references/solution-schema.yaml` (title, category, severity, tags, applies_when).
 - Use `references/category-map.md` to map the problem to the correct solution category.
 - Check for overlap with nearby solution docs before creating a new artifact.
-- Use `references/overlap-rules.md` to decide whether to create, update, or consolidate.
+- Use `references/overlap-rules.md` to decide whether to create, update, consolidate, or retire.
 - Use **`pattern_extractor`** to identify recurring patterns across existing artifacts before writing a new solution.
 - Structure the document with `assets/solution-template.md`.
 - Determine storage level:

package/skills/05-learn/references/overlap-rules.md

@@ -5,3 +5,13 @@ Use these overlap levels when deciding whether to create a new solution doc or u
 - **High** — same problem, same root cause, and same solution approach. Update the existing doc.
 - **Moderate** — related problem area but a different angle or solution. Create a new doc and cross-link it.
 - **Low** — only loosely related. Create a distinct doc.
+
+## Retirement
+
+When an existing solution is discovered stale — the described code/API no longer exists, or the fix has been superseded:
+
+- **Superseded** — fold into the replacing solution (keep the old tags searchable there) and delete the old one.
+- **Dead reference** — delete. Git is the archive; no tombstones.
+- **Scope narrowed** — update `applies_when` instead of deleting.
+
+Never leave an artifact describing code that no longer exists — stale solutions pollute every future search.