specpipe 1.0.1 → 1.0.2

package/templates/.claude/hooks/sensitive-guard.sh

@@ -1,227 +0,0 @@
-#!/usr/bin/env bash
-# sensitive-guard.sh — PreToolUse hook for Claude Code
-#
-# Blocks access to sensitive files: .env, private keys, credentials, tokens.
-# Supports .agentignore for project-specific patterns.
-#
-# Exit codes:
-#   0 — access allowed
-#   2 — access blocked (sensitive file)
-#
-# Environment:
-#   SENSITIVE_GUARD_EXTRA — additional pipe-separated filename patterns to block
-
-set -euo pipefail
-
-# Windows note: this hook requires bash (WSL or Git Bash).
-# On Windows without bash, Claude Code will fail to run this hook and skip it silently.
-# Install WSL or Git Bash and ensure `bash` is in PATH to activate protection.
-
-# ─── Read hook payload from stdin ───────────────────────────────────
-
-INPUT=$(cat)
-[[ -z "$INPUT" ]] && exit 0
-
-# Check Node.js availability — security hook should warn loudly if disabled
-if ! command -v node &>/dev/null; then
-    echo "WARNING: sensitive-guard disabled — Node.js not found. Sensitive files are NOT protected." >&2
-    exit 0
-fi
-
-# Extract file path and/or command using inline Node.js
-PARSED=$(printf '%s' "$INPUT" | node -e "
-  try {
-    const d = JSON.parse(require('fs').readFileSync(0, 'utf-8'));
-    const fp = d.tool_input?.file_path || d.tool_input?.path || '';
-    const cmd = d.tool_input?.command || '';
-    const pat = d.tool_input?.pattern || '';
-    process.stdout.write(fp + '\n' + cmd + '\n' + pat);
-  } catch { process.exit(0); }
-" 2>/dev/null) || exit 0
-
-FILE_PATH=$(printf '%s' "$PARSED" | sed -n '1p')
-COMMAND=$(printf '%s' "$PARSED" | sed -n '2p')
-PATTERN=$(printf '%s' "$PARSED" | sed -n '3p')
-
-# ─── Sensitive filename patterns ────────────────────────────────────
-
-# Returns 0 (true) if the path matches a sensitive pattern
-is_sensitive() {
-    local filepath="$1"
-    local basename
-    basename=$(basename "$filepath" 2>/dev/null) || return 1
-
-    # Exact filenames (basename match)
-    case "$basename" in
-        .env|.env.local|.env.development|.env.production|.env.staging|.env.test)
-            return 0 ;;
-        .npmrc|.pypirc|.netrc)
-            return 0 ;;
-        id_rsa|id_ecdsa|id_ed25519|id_dsa)
-            return 0 ;;
-        serviceAccountKey.json|service-account*.json)
-            return 0 ;;
-        config.json)
-            # config.json only sensitive inside .docker/
-            [[ "$filepath" == *".docker/config.json"* ]] && return 0
-            ;;
-    esac
-
-    # Extension patterns
-    case "$basename" in
-        *.pem|*.key|*.p12|*.pfx|*.jks|*.keystore|*.truststore)
-            return 0 ;;
-        *_rsa|*_ecdsa|*_ed25519|*_dsa)
-            return 0 ;;
-    esac
-
-    # Substring patterns (case-insensitive via bash)
-    local lower
-    lower=$(echo "$basename" | tr '[:upper:]' '[:lower:]')
-    case "$lower" in
-        *credential*|*secret*|*private_key*|*privatekey*)
-            return 0 ;;
-        firebase-adminsdk*)
-            return 0 ;;
-    esac
-
-    # .env.* but NOT .env.example or .env.sample or .env.template
-    if [[ "$basename" =~ ^\.env\. ]]; then
-        case "$basename" in
-            .env.example|.env.sample|.env.template) return 1 ;;
-            *) return 0 ;;
-        esac
-    fi
-
-    # Extra patterns from env var
-    if [[ -n "${SENSITIVE_GUARD_EXTRA:-}" ]]; then
-        if printf '%s\n' "$filepath" | grep -qE "$SENSITIVE_GUARD_EXTRA"; then
-            return 0
-        fi
-    fi
-
-    return 1
-}
-
-# ─── Check .agentignore ────────────────────────────────────────────
-
-check_agentignore() {
-    local filepath="$1"
-    local ignorefile=""
-
-    # Look for ignore files in project root
-    for candidate in .agentignore .aiignore .cursorignore; do
-        if [[ -f "$candidate" ]]; then
-            ignorefile="$candidate"
-            break
-        fi
-    done
-
-    [[ -z "$ignorefile" ]] && return 1
-
-    # Simple line-by-line match (not full gitignore glob, but covers common cases)
-    local relpath
-    # Normalize separators to forward slash before stripping prefix (handles Git Bash on Windows)
-    local normalized_fp normalized_pwd
-    normalized_fp=$(printf '%s' "$filepath" | tr '\\' '/')
-    normalized_pwd=$(pwd | tr '\\' '/')
-    relpath=$(printf '%s' "$normalized_fp" | sed "s|^${normalized_pwd}/||") 2>/dev/null || relpath="$filepath"
-
-    while IFS= read -r pattern || [[ -n "$pattern" ]]; do
-        # Skip comments and empty lines
-        [[ -z "$pattern" || "$pattern" == \#* ]] && continue
-        # Simple glob match
-        if [[ "$relpath" == $pattern ]] || [[ "$(basename "$relpath")" == $pattern ]]; then
-            return 0
-        fi
-    done < "$ignorefile"
-
-    return 1
-}
-
-# ─── Check file path access ────────────────────────────────────────
-
-block_with_message() {
-    local filepath="$1"
-    echo "Blocked: '$filepath' is a sensitive file (secrets, keys, or credentials). Access denied to protect sensitive data. Use .env.example for templates instead." >&2
-    exit 2
-}
-
-warn_with_message() {
-    local filepath="$1"
-    echo "Warning: '$filepath' is a sensitive file. If the user approved this access, proceed. Otherwise, ask the user for permission first via AskUserQuestion before reading sensitive files." >&2
-    # Warn only — exit 0 allows the command to proceed
-    # This enables the flow: Block Read → Claude asks user → User approves → Claude uses bash cat
-    exit 0
-}
-
-# ─── Fast-path: skip obviously safe files ──────────────────────────
-
-fast_path_safe() {
-    local ext="${1##*.}"
-    case "$ext" in
-        md|ts|tsx|js|jsx|css|scss|html|svg|json|yaml|yml|toml|xml|txt|sh|py|rb|rs|go|java|kt|swift|c|cpp|h|hpp|cs|vue|svelte|astro)
-            # But json could be sensitive — check name
-            if [[ "$ext" == "json" ]]; then
-                return 1  # not fast-path safe, need full check
-            fi
-            return 0 ;;
-    esac
-    return 1
-}
-
-# ─── Check direct file access (Read/Write/Edit) → BLOCK ────────────
-
-if [[ -n "$FILE_PATH" ]]; then
-    if ! fast_path_safe "$FILE_PATH"; then
-        if is_sensitive "$FILE_PATH" || check_agentignore "$FILE_PATH"; then
-            block_with_message "$FILE_PATH"
-        fi
-    fi
-fi
-
-# ─── Check bash commands → WARN only (allows approved access) ──────
-
-if [[ -n "$COMMAND" ]]; then
-    # Extract .env file references from commands
-    SENSITIVE_IN_CMD=$(printf '%s\n' "$COMMAND" | grep -oE '[\./[:alnum:]_-]*\.env[\.[:alnum:]_-]*' | head -5) || true
-
-    if [[ -n "$SENSITIVE_IN_CMD" ]]; then
-        while IFS= read -r match; do
-            case "$match" in
-                *.example|*.sample|*.template) continue ;;
-            esac
-            if is_sensitive "$match"; then
-                warn_with_message "$match"
-            fi
-        done <<< "$SENSITIVE_IN_CMD"
-    fi
-
-    # Check for key/cert file references in commands → also warn only
-    KEY_IN_CMD=$(printf '%s\n' "$COMMAND" | grep -oE '[[:alnum:]_./-]*\.(pem|key|p12|pfx|jks|keystore)' | head -3) || true
-    if [[ -n "$KEY_IN_CMD" ]]; then
-        while IFS= read -r match; do
-            warn_with_message "$match"
-        done <<< "$KEY_IN_CMD"
-    fi
-
-    # Check for SSH keys, credentials, service accounts in commands
-    SENSITIVE_NAMES=$(printf '%s\n' "$COMMAND" | grep -oiE '(id_rsa|id_ecdsa|id_ed25519|id_dsa|serviceAccountKey\.json|service-account[[:alnum:]_-]*\.json|\.npmrc|\.pypirc|\.netrc)' | head -3) || true
-    if [[ -n "$SENSITIVE_NAMES" ]]; then
-        while IFS= read -r match; do
-            warn_with_message "$match"
-        done <<< "$SENSITIVE_NAMES"
-    fi
-
-    # Check for credential/secret keywords in file arguments
-    CRED_FILES=$(printf '%s\n' "$COMMAND" | grep -oiE '[[:alnum:]_./-]*(credential|secret|private_key|privatekey)[[:alnum:]_./-]*' | head -3) || true
-    if [[ -n "$CRED_FILES" ]]; then
-        while IFS= read -r match; do
-            warn_with_message "$match"
-        done <<< "$CRED_FILES"
-    fi
-fi
-
-# ─── All checks passed ─────────────────────────────────────────────
-
-exit 0

package/templates/.claude/settings.json

@@ -1,68 +0,0 @@
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/path-guard.sh"
-          },
-          {
-            "type": "command",
-            "command": "bash \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/sensitive-guard.sh"
-          }
-        ]
-      },
-      {
-        "matcher": "Read|Write|Edit|MultiEdit|Grep",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/sensitive-guard.sh"
-          }
-        ]
-      },
-      {
-        "matcher": "Edit|MultiEdit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/comment-guard.js"
-          }
-        ]
-      },
-      {
-        "matcher": "Glob",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/glob-guard.js"
-          }
-        ]
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "Write|Edit|MultiEdit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/file-guard.js"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/self-review.sh"
-          }
-        ]
-      }
-    ]
-  }
-}

package/templates/docs/WORKFLOW.md

@@ -1,325 +0,0 @@
-# Development Workflow Reference
-
-> Spec-first development: every change follows SPEC (with acceptance scenarios) → CODE + TESTS → BUILD PASS.
-
----
-
-## 1. Workflow Types
-
-### New Project (Greenfield)
-
-When: Brand-new project — no codebase yet (empty repo, no package manager / `src/`).
-
-```
-Step 1 → /sp-explore "what you're building"
-          Detects greenfield → ALSO decides app-type + stack (versions researched,
-          current — not recalled from memory) and emits a Bootstrap Brief.
-          Output: docs/explore/<feature>.md (with ## Bootstrap Brief)
-
-Step 2 → /sp-scaffold
-          Reads the Bootstrap Brief → generator-first runnable skeleton:
-          core/ + ONE pattern-demonstrating module + co-located tests.
-          Smoke-gated (install → build → start/smoke must be GREEN, ≥1 real test —
-          this resolves TEST_CMD for /sp-build). Writes ARCHITECTURE.md + ADRs.
-          Hands off ONLY when it actually runs; otherwise BLOCKED.
-
-Step 3 → /sp-plan → /sp-build
-          Normal New Feature flow, now on a runnable base. /sp-build's Foundation
-          Gate confirms the harness exists before the first RED.
-```
-
-### Explore Before Planning
-
-When: Requirements are unclear, multiple approaches are possible, or it's a brownfield feature with existing code to understand first.
-
-```
-Step 1 → /sp-explore "feature description"
-          Clarifies: why the feature is needed, desired behavior, boundaries,
-          edge cases, business rules, permissions, UI expectations.
-          Asks questions as a Client Technical Lead — one topic at a time.
-          Output: docs/explore/<feature>.md
-
-Step 2 → /sp-plan "feature description"
-          Auto-detects docs/explore/<feature>.md → skips redundant codebase
-          discovery, uses explore findings as direct input for the spec.
-          Continue with the normal New Feature flow from Step 2.
-```
-
-### New Feature
-
-When: Building something that doesn't exist yet (no code, no spec).
-
-```
-Step 1 → /sp-plan "description of feature"
-          Generates: docs/specs/<feature>/<feature>.md (spec with acceptance scenarios)
-          Runs Scope Challenge: reuse check, complexity smell (8+ files = flag),
-          framework built-in search, distribution check.
-          Adds "What Already Exists" and "Not in Scope" sections to the spec.
-          Answers validation questions with effort scales (human: X / CC: Y).
-          At the end, suggests /sp-spec-render if you want a scannable HTML view.
-          Review before proceeding.
-
-Step 1.5 → (Optional) /sp-spec-render <feature>
-          Generates <feature>.html next to the .md — sidebar TOC, story cards,
-          collapsible Given/When/Then, dark/light theme. Useful when the spec
-          is long and you want to scan it visually or share it with stakeholders.
-          Source .md remains canonical; .html is regenerable, never hand-edit.
-          For non-spec markdown (investigation, explore, RFC, retro, README),
-          use /sp-md-render <file.md> instead — same idea, generic content.
-
-Step 2 → (Optional) /sp-challenge docs/specs/<feature>/<feature>.md
-          Adversarial review: spawns hostile reviewers to find flaws.
-          Recommended for complex features, auth, data pipelines.
-          Skip for simple CRUD or small features.
-
-Step 3 → Implement in chunks. After each chunk:
-          /sp-build
-          Checks 8 edge case categories (null, empty, invalid types, boundary,
-          error paths, race conditions, large data, special chars).
-          Draws Coverage Map before writing tests: traces code paths + user flows,
-          marks [GAP], [GAP][→E2E], [GAP][→EVAL] (with pass@1/pass@3 guidance).
-          Regression rule enforced.
-          Repeat until chunk is green.
-
-Step 4 → /sp-review (before merge)
-          Checks API/Backend patterns (rate limiting, timeouts, CORS, error leakage).
-          Extra layer for AI-generated code: regressions, trust boundaries, cost escalation.
-
-Step 4.5 → (Optional) /sp-voices
-          Multi-LLM second opinion: sends the diff (or spec) to 2–3 different LLMs,
-          synthesizes consensus + disagreements. Use when: high-stakes change
-          (auth/payment/data), mixed-confidence findings from /sp-review, or
-          you want cross-model verification before merge. Skip for routine changes.
-
-Step 5 → /sp-commit
-```
-
-### Update Existing Feature
-
-When: Changing behavior, adding options, refactoring logic.
-
-```
-Step 1 → /sp-plan docs/specs/<feature>/<feature>.md "description of changes"
-          Mode C handles everything: snapshot → classification → change report → apply.
-          Do NOT manually edit the spec before running /sp-plan — it creates the
-          snapshot first, then applies changes. Manual edits bypass snapshot protection.
-          At the end, suggests /sp-spec-render to refresh <feature>.html if you
-          have an HTML view (it's stale after this update).
-
-Step 2 → Implement code changes.
-          /sp-build
-          Fix until green.
-
-Step 4 → /sp-review → /sp-commit
-```
-
-### Bug Fix
-
-When: Something is broken and needs fixing.
-
-```
-Step 0 → (OPTIONAL) /sp-investigate "description of the bug"
-          Use ONLY when: bug is complex, ambiguous, production outage, data
-          corruption, regression with unclear cause, or user wants diagnosis
-          before any code change. Skip for trivial/obvious bugs.
-          Read-only: traces data flow, maps blast radius, lists hypotheses
-          with confidence levels. Writes docs/investigate/<slug>-<date>.md.
-          No code changes — hands off the report to /sp-fix.
-
-Step 1 → /sp-fix "description" (or /sp-fix docs/investigate/<slug>-<date>.md)
-          Auto-detects investigation file if passed → skips redundant discovery.
-          Draws Bug Path Diagram to confirm hypothesis ([GAP] must be locatable).
-          Regression rule: if diff broke existing behavior with no test → CRITICAL test required.
-          Writes failing test → fixes code → confirms green → runs full suite.
-
-Step 2 → /sp-commit
-
-Optional → If the bug reveals an undocumented edge case, update the spec.
-```
-
-### Remove Feature
-
-When: Deleting a feature, removing deprecated code.
-
-```
-Step 1 → /sp-plan docs/specs/<feature>/<feature>.md "remove stories S-XXX"
-          Mode C creates a snapshot (removing stories = M2 = Major),
-          then marks stories and AS as removed in the spec.
-          (Or if removing the entire feature: archive the directory.)
-
-Step 2 → Delete production code and related test code.
-
-Step 3 → Run the full test suite with the project's native test command.
-          Fix any cascading breakage.
-
-Step 4 → /sp-commit
-```
-
----
-
-## 2. Decision Tree
-
-Use this to decide which workflow to follow:
-
-```
-Is there a runnable project yet (package manager / src / build)?
-├─ No → New Project (Greenfield). /sp-explore (greenfield) → /sp-scaffold → then /sp-plan.
-└─ Yes ↓
-
-Is this a brand new feature (no existing spec or code)?
-├─ Yes
-│   ├─ Are requirements clear and approach decided?
-│   │   ├─ Yes → New Feature workflow. Start with /sp-plan.
-│   │   │   └─ Is the feature complex (auth, data pipeline, multi-service)?
-│   │   │       ├─ Yes → Run /sp-challenge after /sp-plan, before coding.
-│   │   │       └─ No → Skip /sp-challenge, go straight to implementation.
-│   │   └─ No → Explore Before Planning. Start with /sp-explore.
-│   │           Then /sp-plan using the explore output.
-└─ No
-    ├─ Is this a bug fix?
-    │   ├─ Yes → Bug Fix workflow.
-    │   │   ├─ Complex / outage / ambiguous cause / data corruption?
-    │   │   │   ├─ Yes → /sp-investigate first, then /sp-fix.
-    │   │   │   └─ No  → /sp-fix directly.
-    │   └─ No
-    │       ├─ Are you removing/deprecating code?
-    │       │   ├─ Yes → Remove Feature workflow.
-    │       │   └─ No → Update Feature workflow. Start with /sp-plan.
-    │       │
-    │       └─ Is the change very small (< 5 lines, behavior unchanged)?
-    │           └─ Yes → Skip spec update. Just /sp-build and /sp-commit.
-```
-
----
-
-## 3. Prompt Templates
-
-Copy-paste these when working with your agent.
-
-### Template A — Implement + Test Together
-
-```
-I just implemented [brief description].
-Files changed: [list files]
-
-Based on:
-- Spec: docs/specs/<feature>/<feature>.md (section §X)
-- Acceptance scenarios: docs/specs/<feature>/<feature>.md (section ## Stories)
-
-Write tests for the part I just implemented.
-Only tests related to this change — not the entire feature.
-Build and run until all pass.
-If the spec seems incomplete, note what's missing but don't change it.
-```
-
-### Template B — Update Feature + Tests
-
-```
-I'm about to change [description of change].
-Affected files: [list]
-
-1. /sp-plan docs/specs/<feature>/<feature>.md "description of changes"
-   (handles snapshot + spec update + acceptance scenarios)
-2. Implement the code change
-3. Update tests to match
-4. Build and run → fix until green
-```
-
-### Template C — Test-First Bug Fix
-
-```
-Bug: [description]
-Steps to reproduce: [steps]
-Expected: [correct behavior]
-Actual: [broken behavior]
-
-1. Write a test that reproduces this bug (must fail currently)
-2. Fix the production code to make the test pass
-3. Run the full test suite — nothing else should break
-4. Update the spec if this is an undocumented edge case
-```
-
-### Template D — Remove Feature
-
-```
-Removing: [feature name]
-Files to delete: [list]
-
-1. /sp-plan docs/specs/<feature>/<feature>.md "remove stories S-XXX, S-YYY"
-   (handles snapshot + marks stories and AS as removed)
-2. Delete production code
-3. Delete test code
-4. Run full test suite → fix cascading breaks
-```
-
----
-
-## 4. Token Cost Guide
-
-| Workflow | Estimated Tokens | When |
-|----------|-----------------|------|
-| `/sp-explore` | 10–20k | Before /sp-plan when requirements are unclear |
-| `/sp-scaffold` | 15–40k + real install/build time | Greenfield only — once, to stand up a runnable skeleton before the first spec |
-| `/sp-build` (incremental) | 5–10k | Daily, after each code chunk |
-| `/sp-investigate` (complex bug) | 8–15k | OPTIONAL before /sp-fix — complex/outage only |
-| `/sp-fix` (single bug) | 3–5k | As bugs arise |
-| `/sp-commit` | 2–4k | Each commit |
-| `/sp-review` (diff-based) | 10–20k | Before merge |
-| `/sp-plan` (new feature) | 20–40k | Start of new feature |
-| `/sp-challenge` (adversarial) | 15–30k | After /sp-plan, for complex features |
-| `/sp-spec-render` (HTML view) | 3–8k | User-invoked after `/sp-plan` if HTML view wanted, or to refresh stale `.html` |
-| `/sp-md-render` (HTML view, any md) | 3–8k | User-invoked for non-spec markdown — investigation, explore, RFC, retro, README |
-| `/sp-voices` (multi-LLM review) | 10–30k + external API cost | Optional — after /sp-review for high-stakes changes |
-| `/sp-humanize` (rephrase text) | 2–6k | User-invoked — rephrase plan/notes/AI output into send-ready text. Outside the dev cycle |
-| Full audit (manual) | 100k+ | Before release, quarterly |
-
-**Rule of thumb:** Daily work uses templates + `/sp-build` → low token cost.
-Save `/sp-plan` and full audits for significant milestones.
-
----
-
-## 5. CI Integration Checklist
-
-Use this as a PR review checklist (enforce manually or via CI):
-
-- [ ] **Spec updated?** If production behavior changed, `docs/specs/<feature>/` should have changes.
-- [ ] **Acceptance scenarios updated?** If spec behavior changed, AS in spec should reflect it.
-- [ ] **Tests pass?** The project's test command exits 0.
-- [ ] **No dead tests?** Removed production code → removed corresponding tests.
-- [ ] **Coverage not decreased?** (Optional, per-team decision.)
-- [ ] **No secrets in diff?** No API keys, tokens, passwords in committed code.
-- [ ] **Commit messages conventional?** `type(scope): description` format.
-
----
-
-## 6. Spec-Test-Code Sync Rules
-
-| Change | Must Also Update |
-|--------|-----------------|
-| Production code behavior changed | Spec (including acceptance scenarios) + tests |
-| Spec updated | Acceptance scenarios + tests (if behavior changed) |
-| Code removed | Remove related tests. Mark spec and AS as removed. |
-| Bug fix | Add test. Update spec if edge case was undocumented. |
-
-**Never acceptable:**
-- Code changed, spec not updated (spec drift)
-- Code changed, tests not updated (untested code)
-- Spec changed, acceptance scenarios or tests not updated (AS drift)
-- Code removed, dead tests remain (orphaned tests)
-
-**Acceptable shortcut** for changes under 5 lines with no behavior change:
-- Code + tests together, skip spec update (same PR).
-
----
-
-## 7. Common Pitfalls
-
-| Pitfall | Symptom | Prevention |
-|---------|---------|------------|
-| **Spec drift** | Code does X, spec says Y | Always update spec before coding |
-| **Dead tests** | Tests pass but test removed functionality | Delete tests when removing features |
-| **Over-testing** | 50 tests for simple CRUD, slow suite | Focus on behavior, not implementation details |
-| **Mock abuse** | Tests pass with mocks, fail in production | Use real implementations; mock only external services |
-| **Big-bang testing** | All tests written after all code is done | Test incrementally after each chunk |
-| **Ignoring flaky tests** | Tests pass sometimes, fail sometimes | Fix immediately — flaky tests erode trust |
-| **Testing private methods** | Tests break on refactor | Test public API and behavior only |

package/templates/rules/specpipe-guards.md

@@ -1,40 +0,0 @@
-These are the always-on operating rules for working in this repository with specpipe.
-On Claude Code the guardrails are enforced by hooks; on other agents this whole document
-is an always-on rule you must self-enforce.
-
-## Spec-first cycle
-
-Every change follows: **SPEC (with acceptance scenarios) → CODE + TESTS → BUILD PASS**.
-
-- Specs live in `docs/specs/<feature>/<feature>.md`; acceptance scenarios (Given/When/Then)
-  are embedded under `## Stories`.
-- Never write code before the spec exists. Never auto-modify a spec from code.
-- The spec is the source of truth — if code contradicts it, the code is wrong.
-
-## Guardrails
-
-- **Don't explore large directories.** Never grep/list/read inside `node_modules/`,
-  build/dist artifacts, or `.git/` internals — scope to specific paths.
-- **Never touch secrets.** Do not read or write `.env*`, private keys, credentials, or
-  token stores. Respect any `.agentignore` patterns.
-- **Never drop real code.** Don't replace implementation with placeholder comments like
-  `// ... existing code ...`. Reproduce the full code when editing.
-- **Avoid broad globs.** No `**/*.ts` at the project root; scope globs to a directory.
-- **Keep files focused.** Don't let a source file grow past a few hundred lines — split.
-
-## Testing
-
-- Run the project's native test command (`npx vitest run`, `pytest`, `cargo test`,
-  `go test ./...`, `swift test`, …). Compile/typecheck before running tests.
-- Max 3 fix loops on a failure, then stop and report.
-- **Never edit production code to make a test pass** — ask first.
-- No mocks/fakes/stubs to pass builds; real implementations only. Test doubles are for
-  external services (APIs, DBs) that can't run locally.
-
-## Conventions
-
-- Commits: conventional — `type(scope): description` (`feat`, `fix`, `docs`, `refactor`,
-  `test`, `chore`, `perf`, `build`, `ci`).
-- File names: kebab-case, descriptive enough to understand purpose from the path.
-- Never `git push --force` to `main`/`master`; never commit `.env`, certs, or keys.
-- Self-review before finishing: tests pass, no secrets, no debug code, matches the spec.