@leing2021/super-pi 0.23.4 → 0.23.5

package/README.md

@@ -89,7 +89,7 @@ New conversation overhead: **~2,600 tokens** (1.3% of 200K context).
 
 Progressive loading: only needed skills loaded on-demand.
 
-Full evaluation → [`docs/token-cost-evaluation.md`](docs/token-cost-evaluation.md)
+Full evaluation → see Token Cost section above.
 
 ---
 

package/package.json

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

package/rules/common/development-workflow.md

@@ -13,6 +13,7 @@ The Feature Implementation Workflow describes the development pipeline: research
    - **Check package registries:** Search npm, PyPI, crates.io, and other registries before writing utility code. Prefer battle-tested libraries over hand-rolled solutions.
    - **Search for adaptable implementations:** Look for open-source projects that solve 80%+ of the problem and can be forked, ported, or wrapped.
    - Prefer adopting or porting a proven approach over writing net-new code when it meets the requirement.
+   - **Source-driven trigger:** When implementation depends on a framework/library API, version-specific behavior, or a recommended pattern, verify against official documentation and cite key sources in the output. Pure logic, renaming, or in-project pattern reuse does not require external citation.
 
 1. **Plan First**
    - Use **planner** agent to create implementation plan

package/skills/01-brainstorm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 01-brainstorm
-description: "Brainstorm requirements with three modes: CE discovery, Startup Diagnostic, Builder Mode."
+description: "Discover requirements through structured multi-round dialog. Use when the request is ambiguous, needs discovery, or describes a new idea/product."
 ---
 
 # Brainstorm

package/skills/02-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 02-plan
-description: "Turn requirements into a plan. Optional CEO-style strategic review after."
+description: "Turn requirements into an execution-ready plan with TDD-gated implementation units. Use when a brainstorm artifact exists and is ready for planning."
 ---
 
 # Plan
@@ -43,7 +43,8 @@ Every unit follows **RED → GREEN → REFACTOR**:
 2. Read relevant brainstorm from `docs/brainstorms/`
 3. Run solution search (keywords → grep frontmatter → read top 3)
 4. Gather repository context
-5. If plan exists: use `plan_diff` `compare` → review with user → `patch`
+5. **Source-driven check:** For each unit that involves framework/library APIs, add a note: "Verify against official docs before implementing."
+6. If plan exists: use `plan_diff` `compare` → review with user → `patch`
 6. If no plan: write new plan under `docs/plans/` using `references/plan-template.md`
 7. Structure work using `references/implementation-unit-template.md`
 8. Verify every unit follows TDD gates

package/skills/03-work/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 03-work
-description: Execute plan-driven work in a controlled Phase 1 workflow.
+description: "Execute plan units with parallel subagents, TDD enforcement, and checkpoint resume. Use when a plan path is ready for implementation."
 ---
 
 # Work
@@ -39,6 +39,24 @@ Every step follows **RED → GREEN → REFACTOR**:
 - Missing evidence test passed after implementation
 - Tests added only after code
 
+## Stop-the-line rule (Hard gate)
+
+When any unexpected failure occurs during execution:
+
+1. **STOP** adding features or making changes
+2. **PRESERVE** evidence (error output, repro steps)
+3. **DIAGNOSE** root cause — reproduce, localize, reduce
+4. **FIX** the root cause, not the symptom
+5. **GUARD** with a regression test
+6. **RESUME** only after verification passes
+
+Anti-rationalization — when a gate fails or evidence is missing:
+- Do not rationalize, downgrade, or explain away the failure.
+- Stop, report the blocker with evidence, and either fix the root cause or ask for direction.
+- Do not continue unrelated implementation after failed verification.
+
+This is a hard gate — do not push past a failing test or broken build to continue implementation. Errors compound.
+
 ## Workflow
 
 1. **Load context**: consume latest handoff before any broad file reads — `context_handoff load` or read `.context/compound-engineering/handoffs/latest.md`. If found, use `activeFiles`, `blocker`, `verification`, `activeRules` as starting point. If not found, proceed normally.
@@ -48,7 +66,8 @@ Every step follows **RED → GREEN → REFACTOR**:
 5. Use `task_splitter` for dependency analysis
 6. Execute: **inline mode** by default, `ce_parallel_subagent` for independent units
 7. Follow TDD per unit: RED → minimal code → GREEN → refactor → unit-level **verification**
-8. Record progress via `references/progress-update-format.md`
+8. **Source-driven gate:** Before implementing framework/library-specific code, verify the API or pattern against official documentation. Flag unverified patterns as UNVERIFIED in output.
+9. Record progress via `references/progress-update-format.md`
 9. Save `session_checkpoint` after each unit
 10. On failure: `session_checkpoint` `fail` → `retry` → follow strategy
 11. Provide completion report (see `references/completion-report.md`)

package/skills/04-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 04-review
-description: "Review code with structured findings. Optional browser QA and regression tests."
+description: "Review code changes across five axes with evidence-first findings. Use after implementation is complete and before committing."
 ---
 
 # Review

package/skills/04-review/references/reviewer-selection.md

@@ -10,6 +10,8 @@ Use the `review_router` tool to determine which reviewers to apply based on diff
 
 ## Reviewer personas
 
+All reviewers evaluate changes across five axes: correctness, readability, architecture, security, performance. Base reviewers cover axes 1–3 by default; conditional reviewers add depth on specific axes.
+
 ### Base reviewers (always active)
 
 - **correctness-reviewer**: Logical correctness, intended behavior, edge cases.
@@ -19,6 +21,6 @@ Use the `review_router` tool to determine which reviewers to apply based on diff
 ### Conditional reviewers (routed by `review_router`)
 
 - **security-reviewer**: Triggered when auth, permissions, tokens, sessions, or crypto files change. Reviews for injection, auth bypass, credential leakage.
-- **performan04-reviewer**: Triggered when query, cache, database, or streaming files change. Reviews for N+1, unnecessary allocation, missing indexes.
+- **performance-reviewer**: Triggered when query, cache, database, or streaming files change. Reviews for N+1, unnecessary allocation, missing indexes.
 - **integration-reviewer**: Triggered when CI/CD, Docker, package.json, or config files change. Reviews for dependency conflicts, build breakage, deployment issues.
 - **thoroughness-reviewer**: Triggered for large diffs (5+ files or 300+ lines). Reviews for incomplete refactors, missed callers, inconsistent changes.

package/skills/05-learn/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 05-learn
-description: Capture solved problems as reusable solution artifacts.
+description: "Capture solved problems as searchable solution artifacts. Use after a workflow loop completes or a non-trivial problem is solved."
 ---
 
 # Learn

package/skills/06-next/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 06-next
-description: "Inspect workflow state and recommend the single best next Compound Engineering skill. Use --verbose for a full status report."
+description: "Inspect workflow artifacts and recommend the single best next skill. Use when unsure what to run next."
 ---
 
 # Next

package/skills/07-worktree/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 07-worktree
-description: Create and manage git worktrees for isolated feature development.
+description: "Create and manage git worktrees for isolated feature development. Use when starting a feature that needs branch isolation."
 ---
 
 # Worktree

package/skills/08-help/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 08-help
-description: Explain when to use each Compound Engineering Phase 1 skill and how they connect.
+description: "Explain Phase 1 skills and their connections. Use when learning the workflow or deciding which skill applies."
 ---
 
 # Help