get-shit-done-cc 1.0.0

package/get-shit-done/workflows/execute-phase.md

@@ -0,0 +1,1261 @@
+<purpose>
+Execute a phase prompt (PLAN.md) and create the outcome summary (SUMMARY.md).
+</purpose>
+
+<required_reading>
+Read STATE.md before any operation to load project context.
+</required_reading>
+
+<process>
+
+<step name="load_project_state" priority="first">
+Before any operation, read project state:
+
+```bash
+cat .planning/STATE.md 2>/dev/null
+```
+
+**If file exists:** Parse and internalize:
+
+- Current position (phase, plan, status)
+- Accumulated decisions (constraints on this execution)
+- Deferred issues (context for deviations)
+- Blockers/concerns (things to watch for)
+- Brief alignment status
+
+**If file missing but .planning/ exists:**
+
+```
+STATE.md missing but planning artifacts exist.
+Options:
+1. Reconstruct from existing artifacts
+2. Continue without project state (may lose accumulated context)
+```
+
+**If .planning/ doesn't exist:** Error - project not initialized.
+
+This ensures every execution has full project context.
+</step>
+
+<step name="identify_plan">
+Find the next plan to execute:
+- Check roadmap for "In progress" phase
+- Find plans in that phase directory
+- Identify first plan without corresponding SUMMARY
+
+```bash
+cat .planning/ROADMAP.md
+# Look for phase with "In progress" status
+# Then find plans in that phase
+ls .planning/phases/XX-name/*-PLAN.md 2>/dev/null | sort
+ls .planning/phases/XX-name/*-SUMMARY.md 2>/dev/null | sort
+```
+
+**Logic:**
+
+- If `01-01-PLAN.md` exists but `01-01-SUMMARY.md` doesn't → execute 01-01
+- If `01-01-SUMMARY.md` exists but `01-02-SUMMARY.md` doesn't → execute 01-02
+- Pattern: Find first PLAN file without matching SUMMARY file
+
+**Decimal phase handling:**
+
+Phase directories can be integer or decimal format:
+
+- Integer: `.planning/phases/01-foundation/01-01-PLAN.md`
+- Decimal: `.planning/phases/01.1-hotfix/01.1-01-PLAN.md`
+
+Parse phase number from path (handles both formats):
+
+```bash
+# Extract phase number (handles XX or XX.Y format)
+PHASE=$(echo "$PLAN_PATH" | grep -oE '[0-9]+(\.[0-9]+)?-[0-9]+')
+```
+
+SUMMARY naming follows same pattern:
+
+- Integer: `01-01-SUMMARY.md`
+- Decimal: `01.1-01-SUMMARY.md`
+
+Confirm with user if ambiguous.
+
+**Check workflow config for gate behavior:**
+
+```bash
+cat .planning/config.json 2>/dev/null
+```
+
+Parse the config:
+
+- If `mode: "yolo"` → auto-approve execution
+- If `mode: "interactive"` → prompt user
+- If `mode: "custom"` → check `gates.execute_next_plan`
+
+**If auto-approved:**
+
+```
+⚡ Auto-approved: Execute {phase}-{plan}-PLAN.md
+[Plan X of Y for Phase Z]
+
+Starting execution...
+```
+
+Proceed directly to parse_segments.
+
+**If prompting:**
+
+Present:
+
+```
+Found plan to execute: {phase}-{plan}-PLAN.md
+[Plan X of Y for Phase Z]
+
+Proceed with execution?
+```
+
+Wait for confirmation.
+</step>
+
+<step name="record_start_time">
+Record execution start time for performance tracking:
+
+```bash
+PLAN_START_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+PLAN_START_EPOCH=$(date +%s)
+```
+
+Store in shell variables for duration calculation at completion.
+</step>
+
+<step name="parse_segments">
+**Intelligent segmentation: Parse plan into execution segments.**
+
+Plans are divided into segments by checkpoints. Each segment is routed to optimal execution context (subagent or main).
+
+**1. Check for checkpoints:**
+
+```bash
+# Find all checkpoints and their types
+grep -n "type=\"checkpoint" .planning/phases/XX-name/{phase}-{plan}-PLAN.md
+```
+
+**2. Analyze execution strategy:**
+
+**If NO checkpoints found:**
+
+- **Fully autonomous plan** - spawn single subagent for entire plan
+- Subagent gets fresh 200k context, executes all tasks, creates SUMMARY, commits
+- Main context: Just orchestration (~5% usage)
+
+**If checkpoints found, parse into segments:**
+
+Segment = tasks between checkpoints (or start→first checkpoint, or last checkpoint→end)
+
+**For each segment, determine routing:**
+
+```
+Segment routing rules:
+
+IF segment has no prior checkpoint:
+  → SUBAGENT (first segment, nothing to depend on)
+
+IF segment follows checkpoint:human-verify:
+  → SUBAGENT (verification is just confirmation, doesn't affect next work)
+
+IF segment follows checkpoint:decision OR checkpoint:human-action:
+  → MAIN CONTEXT (next tasks need the decision/result)
+```
+
+**3. Execution pattern:**
+
+**Pattern A: Fully autonomous (no checkpoints)**
+
+```
+Spawn subagent → execute all tasks → SUMMARY → commit → report back
+```
+
+**Pattern B: Segmented with verify-only checkpoints**
+
+```
+Segment 1 (tasks 1-3): Spawn subagent → execute → report back
+Checkpoint 4 (human-verify): Main context → you verify → continue
+Segment 2 (tasks 5-6): Spawn NEW subagent → execute → report back
+Checkpoint 7 (human-verify): Main context → you verify → continue
+Aggregate results → SUMMARY → commit
+```
+
+**Pattern C: Decision-dependent (must stay in main)**
+
+```
+Checkpoint 1 (decision): Main context → you decide → continue in main
+Tasks 2-5: Main context (need decision from checkpoint 1)
+No segmentation benefit - execute entirely in main
+```
+
+**4. Why this works:**
+
+**Segmentation benefits:**
+
+- Fresh context for each autonomous segment (0% start every time)
+- Main context only for checkpoints (~10-20% total)
+- Can handle 10+ task plans if properly segmented
+- Quality impossible to degrade in autonomous segments
+
+**When segmentation provides no benefit:**
+
+- Checkpoint is decision/human-action and following tasks depend on outcome
+- Better to execute sequentially in main than break flow
+
+**5. Implementation:**
+
+**For fully autonomous plans:**
+
+```
+Use Task tool with subagent_type="general-purpose":
+
+Prompt: "Execute plan at .planning/phases/{phase}-{plan}-PLAN.md
+
+This is an autonomous plan (no checkpoints). Execute all tasks, create SUMMARY.md in phase directory, commit with message following plan's commit guidance.
+
+Follow all deviation rules and authentication gate protocols from the plan.
+
+When complete, report: plan name, tasks completed, SUMMARY path, commit hash."
+```
+
+**For segmented plans (has verify-only checkpoints):**
+
+```
+Execute segment-by-segment:
+
+For each autonomous segment:
+  Spawn subagent with prompt: "Execute tasks [X-Y] from plan at .planning/phases/{phase}-{plan}-PLAN.md. Read the plan for full context and deviation rules. Do NOT create SUMMARY or commit - just execute these tasks and report results."
+
+  Wait for subagent completion
+
+For each checkpoint:
+  Execute in main context
+  Wait for user interaction
+  Continue to next segment
+
+After all segments complete:
+  Aggregate all results
+  Create SUMMARY.md
+  Commit with all changes
+```
+
+**For decision-dependent plans:**
+
+```
+Execute in main context (standard flow below)
+No subagent routing
+Quality maintained through small scope (2-3 tasks per plan)
+```
+
+See step name="segment_execution" for detailed segment execution loop.
+</step>
+
+<step name="segment_execution">
+**Detailed segment execution loop for segmented plans.**
+
+**This step applies ONLY to segmented plans (Pattern B: has checkpoints, but they're verify-only).**
+
+For Pattern A (fully autonomous) and Pattern C (decision-dependent), skip this step.
+
+**Execution flow:**
+
+````
+1. Parse plan to identify segments:
+   - Read plan file
+   - Find checkpoint locations: grep -n "type=\"checkpoint" PLAN.md
+   - Identify checkpoint types: grep "type=\"checkpoint" PLAN.md | grep -o 'checkpoint:[^"]*'
+   - Build segment map:
+     * Segment 1: Start → first checkpoint (tasks 1-X)
+     * Checkpoint 1: Type and location
+     * Segment 2: After checkpoint 1 → next checkpoint (tasks X+1 to Y)
+     * Checkpoint 2: Type and location
+     * ... continue for all segments
+
+2. For each segment in order:
+
+   A. Determine routing (apply rules from parse_segments):
+      - No prior checkpoint? → Subagent
+      - Prior checkpoint was human-verify? → Subagent
+      - Prior checkpoint was decision/human-action? → Main context
+
+   B. If routing = Subagent:
+      ```
+      Spawn Task tool with subagent_type="general-purpose":
+
+      Prompt: "Execute tasks [task numbers/names] from plan at [plan path].
+
+      **Context:**
+      - Read the full plan for objective, context files, and deviation rules
+      - You are executing a SEGMENT of this plan (not the full plan)
+      - Other segments will be executed separately
+
+      **Your responsibilities:**
+      - Execute only the tasks assigned to you
+      - Follow all deviation rules and authentication gate protocols
+      - Track deviations for later Summary
+      - DO NOT create SUMMARY.md (will be created after all segments complete)
+      - DO NOT commit (will be done after all segments complete)
+
+      **Report back:**
+      - Tasks completed
+      - Files created/modified
+      - Deviations encountered
+      - Any issues or blockers"
+
+      Wait for subagent to complete
+      Capture results (files changed, deviations, etc.)
+      ```
+
+   C. If routing = Main context:
+      Execute tasks in main using standard execution flow (step name="execute")
+      Track results locally
+
+   D. After segment completes (whether subagent or main):
+      Continue to next checkpoint/segment
+
+3. After ALL segments complete:
+
+   A. Aggregate results from all segments:
+      - Collect files created/modified from all segments
+      - Collect deviations from all segments
+      - Collect decisions from all checkpoints
+      - Merge into complete picture
+
+   B. Create SUMMARY.md:
+      - Use aggregated results
+      - Document all work from all segments
+      - Include deviations from all segments
+      - Note which segments were subagented
+
+   C. Commit:
+      - Stage all files from all segments
+      - Stage SUMMARY.md
+      - Commit with message following plan guidance
+      - Include note about segmented execution if relevant
+
+   D. Report completion
+
+**Example execution trace:**
+
+````
+
+Plan: 01-02-PLAN.md (8 tasks, 2 verify checkpoints)
+
+Parsing segments...
+
+- Segment 1: Tasks 1-3 (autonomous)
+- Checkpoint 4: human-verify
+- Segment 2: Tasks 5-6 (autonomous)
+- Checkpoint 7: human-verify
+- Segment 3: Task 8 (autonomous)
+
+Routing analysis:
+
+- Segment 1: No prior checkpoint → SUBAGENT ✓
+- Checkpoint 4: Verify only → MAIN (required)
+- Segment 2: After verify → SUBAGENT ✓
+- Checkpoint 7: Verify only → MAIN (required)
+- Segment 3: After verify → SUBAGENT ✓
+
+Execution:
+[1] Spawning subagent for tasks 1-3...
+→ Subagent completes: 3 files modified, 0 deviations
+[2] Executing checkpoint 4 (human-verify)...
+════════════════════════════════════════
+CHECKPOINT: Verification Required
+Task 4 of 8: Verify database schema
+I built: User and Session tables with relations
+How to verify: Check src/db/schema.ts for correct types
+════════════════════════════════════════
+User: "approved"
+[3] Spawning subagent for tasks 5-6...
+→ Subagent completes: 2 files modified, 1 deviation (added error handling)
+[4] Executing checkpoint 7 (human-verify)...
+User: "approved"
+[5] Spawning subagent for task 8...
+→ Subagent completes: 1 file modified, 0 deviations
+
+Aggregating results...
+
+- Total files: 6 modified
+- Total deviations: 1
+- Segmented execution: 3 subagents, 2 checkpoints
+
+Creating SUMMARY.md...
+Committing...
+✓ Complete
+
+````
+
+**Benefits of this pattern:**
+- Main context usage: ~20% (just orchestration + checkpoints)
+- Subagent 1: Fresh 0-30% (tasks 1-3)
+- Subagent 2: Fresh 0-30% (tasks 5-6)
+- Subagent 3: Fresh 0-20% (task 8)
+- All autonomous work: Peak quality
+- Can handle large plans with many tasks if properly segmented
+
+**When NOT to use segmentation:**
+- Plan has decision/human-action checkpoints that affect following tasks
+- Following tasks depend on checkpoint outcome
+- Better to execute in main sequentially in those cases
+</step>
+
+<step name="load_prompt">
+Read the plan prompt:
+```bash
+cat .planning/phases/XX-name/{phase}-{plan}-PLAN.md
+````
+
+This IS the execution instructions. Follow it exactly.
+
+**If plan references CONTEXT.md:**
+The CONTEXT.md file provides phase-level objectives, constraints, and success indicators gathered before planning. This context informs implementation decisions throughout execution.
+</step>
+
+<step name="previous_phase_check">
+Before executing, check if previous phase had issues:
+
+```bash
+# Find previous phase summary
+ls .planning/phases/*/SUMMARY.md 2>/dev/null | sort -r | head -2 | tail -1
+```
+
+If previous phase SUMMARY.md has "Issues Encountered" != "None" or "Next Phase Readiness" mentions blockers:
+
+Use AskUserQuestion:
+
+- header: "Previous Issues"
+- question: "Previous phase had unresolved items: [summary]. How to proceed?"
+- options:
+  - "Proceed anyway" - Issues won't block this phase
+  - "Address first" - Let's resolve before continuing
+  - "Review previous" - Show me the full summary
+    </step>
+
+<step name="execute">
+Execute each task in the prompt. **Deviations are normal** - handle them automatically using embedded rules below.
+
+1. Read the @context files listed in the prompt
+
+2. For each task:
+
+   **If `type="auto"`:**
+
+   - Work toward task completion
+   - **If CLI/API returns authentication error:** Handle as authentication gate (see below)
+   - **When you discover additional work not in plan:** Apply deviation rules (see below) automatically
+   - Continue implementing, applying rules as needed
+   - Run the verification
+   - Confirm done criteria met
+   - Track any deviations for Summary documentation
+   - Continue to next task
+
+   **If `type="checkpoint:*"`:**
+
+   - STOP immediately (do not continue to next task)
+   - Execute checkpoint_protocol (see below)
+   - Wait for user response
+   - Verify if possible (check files, env vars, etc.)
+   - Only after user confirmation: continue to next task
+
+3. Run overall verification checks from `<verification>` section
+4. Confirm all success criteria from `<success_criteria>` section met
+5. Document all deviations in Summary (automatic - see deviation_documentation below)
+   </step>
+
+<authentication_gates>
+
+## Handling Authentication Errors During Execution
+
+**When you encounter authentication errors during `type="auto"` task execution:**
+
+This is NOT a failure. Authentication gates are expected and normal. Handle them dynamically:
+
+**Authentication error indicators:**
+
+- CLI returns: "Error: Not authenticated", "Not logged in", "Unauthorized", "401", "403"
+- API returns: "Authentication required", "Invalid API key", "Missing credentials"
+- Command fails with: "Please run {tool} login" or "Set {ENV_VAR} environment variable"
+
+**Authentication gate protocol:**
+
+1. **Recognize it's an auth gate** - Not a bug, just needs credentials
+2. **STOP current task execution** - Don't retry repeatedly
+3. **Create dynamic checkpoint:human-action** - Present it to user immediately
+4. **Provide exact authentication steps** - CLI commands, where to get keys
+5. **Wait for user to authenticate** - Let them complete auth flow
+6. **Verify authentication works** - Test that credentials are valid
+7. **Retry the original task** - Resume automation where you left off
+8. **Continue normally** - Don't treat this as an error in Summary
+
+**Example: Vercel deployment hits auth error**
+
+```
+Task 3: Deploy to Vercel
+Running: vercel --yes
+
+Error: Not authenticated. Please run 'vercel login'
+
+[Create checkpoint dynamically]
+
+════════════════════════════════════════
+CHECKPOINT: Authentication Required
+════════════════════════════════════════
+
+Task 3 of 8: Authenticate Vercel CLI
+
+I tried to deploy but got authentication error.
+
+What you need to do:
+Run: vercel login
+
+This will open your browser - complete the authentication flow.
+
+I'll verify after: vercel whoami returns your account
+
+Type "done" when authenticated
+════════════════════════════════════════
+
+[Wait for user response]
+
+[User types "done"]
+
+Verifying authentication...
+Running: vercel whoami
+✓ Authenticated as: user@example.com
+
+Retrying deployment...
+Running: vercel --yes
+✓ Deployed to: https://myapp-abc123.vercel.app
+
+Task 3 complete. Continuing to task 4...
+```
+
+**In Summary documentation:**
+
+Document authentication gates as normal flow, not deviations:
+
+```markdown
+## Authentication Gates
+
+During execution, I encountered authentication requirements:
+
+1. Task 3: Vercel CLI required authentication
+   - Paused for `vercel login`
+   - Resumed after authentication
+   - Deployed successfully
+
+These are normal gates, not errors.
+```
+
+**Key principles:**
+
+- Authentication gates are NOT failures or bugs
+- They're expected interaction points during first-time setup
+- Handle them gracefully and continue automation after unblocked
+- Don't mark tasks as "failed" or "incomplete" due to auth gates
+- Document them as normal flow, separate from deviations
+  </authentication_gates>
+
+<deviation_rules>
+
+## Automatic Deviation Handling
+
+**While executing tasks, you WILL discover work not in the plan.** This is normal.
+
+Apply these rules automatically. Track all deviations for Summary documentation.
+
+---
+
+**RULE 1: Auto-fix bugs**
+
+**Trigger:** Code doesn't work as intended (broken behavior, incorrect output, errors)
+
+**Action:** Fix immediately, track for Summary
+
+**Examples:**
+
+- Wrong SQL query returning incorrect data
+- Logic errors (inverted condition, off-by-one, infinite loop)
+- Type errors, null pointer exceptions, undefined references
+- Broken validation (accepts invalid input, rejects valid input)
+- Security vulnerabilities (SQL injection, XSS, CSRF, insecure auth)
+- Race conditions, deadlocks
+- Memory leaks, resource leaks
+
+**Process:**
+
+1. Fix the bug inline
+2. Add/update tests to prevent regression
+3. Verify fix works
+4. Continue task
+5. Track in deviations list: `[Rule 1 - Bug] [description]`
+
+**No user permission needed.** Bugs must be fixed for correct operation.
+
+---
+
+**RULE 2: Auto-add missing critical functionality**
+
+**Trigger:** Code is missing essential features for correctness, security, or basic operation
+
+**Action:** Add immediately, track for Summary
+
+**Examples:**
+
+- Missing error handling (no try/catch, unhandled promise rejections)
+- No input validation (accepts malicious data, type coercion issues)
+- Missing null/undefined checks (crashes on edge cases)
+- No authentication on protected routes
+- Missing authorization checks (users can access others' data)
+- No CSRF protection, missing CORS configuration
+- No rate limiting on public APIs
+- Missing required database indexes (causes timeouts)
+- No logging for errors (can't debug production)
+
+**Process:**
+
+1. Add the missing functionality inline
+2. Add tests for the new functionality
+3. Verify it works
+4. Continue task
+5. Track in deviations list: `[Rule 2 - Missing Critical] [description]`
+
+**Critical = required for correct/secure/performant operation**
+**No user permission needed.** These are not "features" - they're requirements for basic correctness.
+
+---
+
+**RULE 3: Auto-fix blocking issues**
+
+**Trigger:** Something prevents you from completing current task
+
+**Action:** Fix immediately to unblock, track for Summary
+
+**Examples:**
+
+- Missing dependency (package not installed, import fails)
+- Wrong types blocking compilation
+- Broken import paths (file moved, wrong relative path)
+- Missing environment variable (app won't start)
+- Database connection config error
+- Build configuration error (webpack, tsconfig, etc.)
+- Missing file referenced in code
+- Circular dependency blocking module resolution
+
+**Process:**
+
+1. Fix the blocking issue
+2. Verify task can now proceed
+3. Continue task
+4. Track in deviations list: `[Rule 3 - Blocking] [description]`
+
+**No user permission needed.** Can't complete task without fixing blocker.
+
+---
+
+**RULE 4: Ask about architectural changes**
+
+**Trigger:** Fix/addition requires significant structural modification
+
+**Action:** STOP, present to user, wait for decision
+
+**Examples:**
+
+- Adding new database table (not just column)
+- Major schema changes (changing primary key, splitting tables)
+- Introducing new service layer or architectural pattern
+- Switching libraries/frameworks (React → Vue, REST → GraphQL)
+- Changing authentication approach (sessions → JWT)
+- Adding new infrastructure (message queue, cache layer, CDN)
+- Changing API contracts (breaking changes to endpoints)
+- Adding new deployment environment
+
+**Process:**
+
+1. STOP current task
+2. Present clearly:
+
+```
+⚠️ Architectural Decision Needed
+
+Current task: [task name]
+Discovery: [what you found that prompted this]
+Proposed change: [architectural modification]
+Why needed: [rationale]
+Impact: [what this affects - APIs, deployment, dependencies, etc.]
+Alternatives: [other approaches, or "none apparent"]
+
+Proceed with proposed change? (yes / different approach / defer)
+```
+
+3. WAIT for user response
+4. If approved: implement, track as `[Rule 4 - Architectural] [description]`
+5. If different approach: discuss and implement
+6. If deferred: log to ISSUES.md, continue without change
+
+**User decision required.** These changes affect system design.
+
+---
+
+**RULE 5: Log non-critical enhancements**
+
+**Trigger:** Improvement that would enhance code but isn't essential now
+
+**Action:** Add to .planning/ISSUES.md automatically, continue task
+
+**Examples:**
+
+- Performance optimization (works correctly, just slower than ideal)
+- Code refactoring (works, but could be cleaner/DRY-er)
+- Better naming (works, but variables could be clearer)
+- Organizational improvements (works, but file structure could be better)
+- Nice-to-have UX improvements (works, but could be smoother)
+- Additional test coverage beyond basics (basics exist, could be more thorough)
+- Documentation improvements (code works, docs could be better)
+- Accessibility enhancements beyond minimum
+
+**Process:**
+
+1. Create .planning/ISSUES.md if doesn't exist (use `~/.claude/get-shit-done/templates/issues.md`)
+2. Add entry with ISS-XXX number (auto-increment)
+3. Brief notification: `📋 Logged enhancement: [brief] (ISS-XXX)`
+4. Continue task without implementing
+
+**No user permission needed.** Logging for future consideration.
+
+---
+
+**RULE PRIORITY (when multiple could apply):**
+
+1. **If Rule 4 applies** → STOP and ask (architectural decision)
+2. **If Rules 1-3 apply** → Fix automatically, track for Summary
+3. **If Rule 5 applies** → Log to ISSUES.md, continue
+4. **If genuinely unsure which rule** → Apply Rule 4 (ask user)
+
+**Edge case guidance:**
+
+- "This validation is missing" → Rule 2 (critical for security)
+- "This validation could be better" → Rule 5 (enhancement)
+- "This crashes on null" → Rule 1 (bug)
+- "This could be faster" → Rule 5 (enhancement) UNLESS actually timing out → Rule 2 (critical)
+- "Need to add table" → Rule 4 (architectural)
+- "Need to add column" → Rule 1 or 2 (depends: fixing bug or adding critical field)
+
+**When in doubt:** Ask yourself "Does this affect correctness, security, or ability to complete task?"
+
+- YES → Rules 1-3 (fix automatically)
+- NO → Rule 5 (log it)
+- MAYBE → Rule 4 (ask user)
+
+</deviation_rules>
+
+<deviation_documentation>
+
+## Documenting Deviations in Summary
+
+After all tasks complete, Summary MUST include deviations section.
+
+**If no deviations:**
+
+```markdown
+## Deviations from Plan
+
+None - plan executed exactly as written.
+```
+
+**If deviations occurred:**
+
+```markdown
+## Deviations from Plan
+
+### Auto-fixed Issues
+
+**1. [Rule 1 - Bug] Fixed case-sensitive email uniqueness constraint**
+
+- **Found during:** Task 4 (Follow/unfollow API implementation)
+- **Issue:** User.email unique constraint was case-sensitive - Test@example.com and test@example.com were both allowed, causing duplicate accounts
+- **Fix:** Changed to `CREATE UNIQUE INDEX users_email_unique ON users (LOWER(email))`
+- **Files modified:** src/models/User.ts, migrations/003_fix_email_unique.sql
+- **Verification:** Unique constraint test passes - duplicate emails properly rejected
+- **Commit:** abc123f
+
+**2. [Rule 2 - Missing Critical] Added JWT expiry validation to auth middleware**
+
+- **Found during:** Task 3 (Protected route implementation)
+- **Issue:** Auth middleware wasn't checking token expiry - expired tokens were being accepted
+- **Fix:** Added exp claim validation in middleware, reject with 401 if expired
+- **Files modified:** src/middleware/auth.ts, src/middleware/auth.test.ts
+- **Verification:** Expired token test passes - properly rejects with 401
+- **Commit:** def456g
+
+### Deferred Enhancements
+
+Logged to .planning/ISSUES.md for future consideration:
+
+- ISS-001: Refactor UserService into smaller modules (discovered in Task 3)
+- ISS-002: Add connection pooling for Redis (discovered in Task 6)
+
+---
+
+**Total deviations:** 4 auto-fixed (1 bug, 1 missing critical, 1 blocking, 1 architectural with approval), 3 deferred
+**Impact on plan:** All auto-fixes necessary for correctness/security/performance. No scope creep.
+```
+
+**This provides complete transparency:**
+
+- Every deviation documented
+- Why it was needed
+- What rule applied
+- What was done
+- User can see exactly what happened beyond the plan
+
+</deviation_documentation>
+
+<step name="checkpoint_protocol">
+When encountering `type="checkpoint:*"`:
+
+**Critical: Claude automates everything with CLI/API before checkpoints.** Checkpoints are for verification and decisions, not manual work.
+
+**Display checkpoint clearly:**
+
+```
+════════════════════════════════════════
+CHECKPOINT: [Type]
+════════════════════════════════════════
+
+Task [X] of [Y]: [Action/What-Built/Decision]
+
+[Display task-specific content based on type]
+
+[Resume signal instruction]
+════════════════════════════════════════
+```
+
+**For checkpoint:human-verify (90% of checkpoints):**
+
+```
+I automated: [what was automated - deployed, built, configured]
+
+How to verify:
+1. [Step 1 - exact command/URL]
+2. [Step 2 - what to check]
+3. [Step 3 - expected behavior]
+
+[Resume signal - e.g., "Type 'approved' or describe issues"]
+```
+
+**For checkpoint:decision (9% of checkpoints):**
+
+```
+Decision needed: [decision]
+
+Context: [why this matters]
+
+Options:
+1. [option-id]: [name]
+   Pros: [pros]
+   Cons: [cons]
+
+2. [option-id]: [name]
+   Pros: [pros]
+   Cons: [cons]
+
+[Resume signal - e.g., "Select: option-id"]
+```
+
+**For checkpoint:human-action (1% - rare, only for truly unavoidable manual steps):**
+
+```
+I automated: [what Claude already did via CLI/API]
+
+Need your help with: [the ONE thing with no CLI/API - email link, 2FA code]
+
+Instructions:
+[Single unavoidable step]
+
+I'll verify after: [verification]
+
+[Resume signal - e.g., "Type 'done' when complete"]
+```
+
+**After displaying:** WAIT for user response. Do NOT hallucinate completion. Do NOT continue to next task.
+
+**After user responds:**
+
+- Run verification if specified (file exists, env var set, tests pass, etc.)
+- If verification passes or N/A: continue to next task
+- If verification fails: inform user, wait for resolution
+
+See ~/.claude/get-shit-done/references/checkpoints.md for complete checkpoint guidance.
+</step>
+
+<step name="verification_failure_gate">
+If any task verification fails:
+
+STOP. Do not continue to next task.
+
+Present inline:
+"Verification failed for Task [X]: [task name]
+
+Expected: [verification criteria]
+Actual: [what happened]
+
+How to proceed?
+
+1. Retry - Try the task again
+2. Skip - Mark as incomplete, continue
+3. Stop - Pause execution, investigate"
+
+Wait for user decision.
+
+If user chose "Skip", note it in SUMMARY.md under "Issues Encountered".
+</step>
+
+<step name="record_completion_time">
+Record execution end time and calculate duration:
+
+```bash
+PLAN_END_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
+PLAN_END_EPOCH=$(date +%s)
+
+DURATION_SEC=$(( PLAN_END_EPOCH - PLAN_START_EPOCH ))
+DURATION_MIN=$(( DURATION_SEC / 60 ))
+
+if [[ $DURATION_MIN -ge 60 ]]; then
+  HRS=$(( DURATION_MIN / 60 ))
+  MIN=$(( DURATION_MIN % 60 ))
+  DURATION="${HRS}h ${MIN}m"
+else
+  DURATION="${DURATION_MIN} min"
+fi
+```
+
+Pass timing data to SUMMARY.md creation.
+</step>
+
+<step name="create_summary">
+Create `{phase}-{plan}-SUMMARY.md` as specified in the prompt's `<output>` section.
+Use ~/.claude/get-shit-done/templates/summary.md for structure.
+
+**File location:** `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
+
+**Title format:** `# Phase [X] Plan [Y]: [Name] Summary`
+
+The one-liner must be SUBSTANTIVE:
+
+- Good: "JWT auth with refresh rotation using jose library"
+- Bad: "Authentication implemented"
+
+**Include performance data:**
+
+- Duration: `$DURATION`
+- Started: `$PLAN_START_TIME`
+- Completed: `$PLAN_END_TIME`
+- Tasks completed: (count from execution)
+- Files modified: (count from execution)
+
+**Next Step section:**
+
+- If more plans exist in this phase: "Ready for {phase}-{next-plan}-PLAN.md"
+- If this is the last plan: "Phase complete, ready for transition"
+  </step>
+
+<step name="update_current_position">
+Update Current Position section in STATE.md to reflect plan completion.
+
+**Format:**
+
+```markdown
+Phase: [current] of [total] ([phase name])
+Plan: [just completed] of [total in phase]
+Status: [In progress / Phase complete]
+Last activity: [today] - Completed {phase}-{plan}-PLAN.md
+
+Progress: [progress bar]
+```
+
+**Calculate progress bar:**
+
+- Count total plans across all phases (from ROADMAP.md or ROADMAP.md)
+- Count completed plans (count SUMMARY.md files that exist)
+- Progress = (completed / total) × 100%
+- Render: ░ for incomplete, █ for complete
+
+**Example - completing 02-01-PLAN.md (plan 5 of 10 total):**
+
+Before:
+
+```markdown
+## Current Position
+
+Phase: 2 of 4 (Authentication)
+Plan: Not started
+Status: Ready to execute
+Last activity: 2025-01-18 - Phase 1 complete
+
+Progress: ██████░░░░ 40%
+```
+
+After:
+
+```markdown
+## Current Position
+
+Phase: 2 of 4 (Authentication)
+Plan: 1 of 2 in current phase
+Status: In progress
+Last activity: 2025-01-19 - Completed 02-01-PLAN.md
+
+Progress: ███████░░░ 50%
+```
+
+**Step complete when:**
+
+- [ ] Phase number shows current phase (X of total)
+- [ ] Plan number shows plans complete in current phase (N of total-in-phase)
+- [ ] Status reflects current state (In progress / Phase complete)
+- [ ] Last activity shows today's date and the plan just completed
+- [ ] Progress bar calculated correctly from total completed plans
+      </step>
+
+<step name="extract_decisions_and_issues">
+Extract decisions, issues, and concerns from SUMMARY.md into STATE.md accumulated context.
+
+**Decisions Made:**
+
+- Read SUMMARY.md "## Decisions Made" section
+- If content exists (not "None"):
+  - Add each decision to STATE.md Decisions table
+  - Format: `| [phase number] | [decision summary] | [rationale] |`
+
+**Deferred Issues:**
+
+- Read SUMMARY.md to check if new issues were logged to ISSUES.md
+- If new ISS-XXX entries created:
+  - Update STATE.md "Deferred Issues" section
+
+**Blockers/Concerns:**
+
+- Read SUMMARY.md "## Next Phase Readiness" section
+- If contains blockers or concerns:
+  - Add to STATE.md "Blockers/Concerns Carried Forward"
+    </step>
+
+<step name="update_session_continuity">
+Update Session Continuity section in STATE.md to enable resumption in future sessions.
+
+**Format:**
+
+```markdown
+Last session: [current date and time]
+Stopped at: Completed {phase}-{plan}-PLAN.md
+Resume file: [path to .continue-here if exists, else "None"]
+```
+
+**Size constraint note:** Keep STATE.md under 150 lines total.
+</step>
+
+<step name="issues_review_gate">
+Before proceeding, check SUMMARY.md content:
+
+**Check workflow config for gate behavior:**
+
+- If `mode: "yolo"` → auto-approve (but still log issues)
+- If `mode: "interactive"` → prompt user
+
+If "Issues Encountered" is NOT "None":
+
+**If auto-approved:**
+
+```
+⚡ Auto-approved: Issues acknowledgment
+⚠️ Note: Issues were encountered during execution:
+- [Issue 1]
+- [Issue 2]
+(Logged - continuing in yolo mode)
+```
+
+Continue without waiting.
+
+**If prompting:**
+Present issues and wait for acknowledgment.
+</step>
+
+<step name="update_roadmap">
+Update the roadmap file:
+
+```bash
+ROADMAP_FILE=".planning/ROADMAP.md"
+```
+
+**If more plans remain in this phase:**
+
+- Update plan count: "2/3 plans complete"
+- Keep phase status as "In progress"
+
+**If this was the last plan in the phase:**
+
+- Mark phase complete: status → "Complete"
+- Add completion date
+  </step>
+
+<step name="git_commit_plan">
+Commit plan completion (SUMMARY + PROJECT-STATE + ROADMAP + modified code files):
+
+**Critical: Stage only files this plan actually modified.**
+
+NEVER use:
+
+- `git add .`
+- `git add -A`
+- `git add src/` or any broad directory add
+
+**1. Stage planning artifacts:**
+
+```bash
+git add .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+git add .planning/STATE.md
+```
+
+**2. Stage roadmap file:**
+
+```bash
+if [ -f .planning/ROADMAP.md ]; then
+  git add .planning/ROADMAP.md
+else
+  git add .planning/ROADMAP.md
+fi
+```
+
+**3. Stage only code files from the modified-files list**
+
+**4. Verify staging before commit:**
+
+```bash
+git status
+# Confirm only expected files are staged
+```
+
+**5. Commit:**
+
+```bash
+git commit -m "$(cat <<'EOF'
+feat({phase}-{plan}): [one-liner from SUMMARY.md]
+
+- [Key accomplishment 1]
+- [Key accomplishment 2]
+- [Key accomplishment 3]
+EOF
+)"
+```
+
+For commit message conventions and git workflow patterns, see ~/.claude/get-shit-done/references/git-integration.md
+</step>
+
+<step name="offer_next">
+**Check workflow config for gate behavior:**
+
+- If `mode: "yolo"` → auto-continue to next action
+- If `mode: "interactive"` → prompt user
+
+**If more plans in this phase:**
+
+**If auto-approved:**
+
+```
+Plan {phase}-{plan} complete.
+Summary: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+
+[X] of [Y] plans complete for Phase Z.
+
+⚡ Auto-continuing: Execute next plan ({phase}-{next-plan})
+```
+
+Loop back to identify_plan step automatically.
+
+**If prompting:**
+
+```
+Plan {phase}-{plan} complete.
+Summary: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+
+[X] of [Y] plans complete for Phase Z.
+
+What's next?
+1. Execute next plan (/gsd:execute-plan .planning/phases/XX-name/{phase}-{next-plan}-PLAN.md)
+2. Review what was built
+3. Done for now
+```
+
+**If phase complete (last plan done):**
+
+First, check if this is also the last phase in the milestone (milestone complete):
+
+```bash
+# Count total phases in ROADMAP.md
+TOTAL_PHASES=$(grep -c "^### Phase [0-9]" .planning/ROADMAP.md)
+
+# Get current phase number from the just-completed plan
+CURRENT_PHASE=$(echo "{phase}" | grep -oE '^[0-9]+')
+
+# Check if current phase == total phases
+if [[ "$CURRENT_PHASE" -eq "$TOTAL_PHASES" ]]; then
+  # Milestone complete
+  MILESTONE_COMPLETE=true
+fi
+```
+
+**If milestone complete (final phase of roadmap done):**
+
+```
+🎉 MILESTONE COMPLETE!
+
+Plan {phase}-{plan} complete.
+Summary: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+
+Phase [Z]: [Name] COMPLETE - all [Y] plans finished.
+
+════════════════════════════════════════
+All [N] phases complete!
+This milestone is 100% done.
+════════════════════════════════════════
+
+What's next?
+1. Complete milestone (/gsd:complete-milestone) - Archive and start fresh
+2. Add another phase (/gsd:add-phase) - Extend this milestone
+3. Review accomplishments - See what was built
+4. Done for now
+```
+
+**If phase complete but more phases remain:**
+
+```
+Plan {phase}-{plan} complete.
+Summary: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+
+Phase [Z]: [Name] COMPLETE - all [Y] plans finished.
+
+What's next?
+1. Discuss Phase [X+1] context (/gsd:discuss-phase [X+1])
+2. Plan Phase [X+1] in detail (/gsd:plan-phase [X+1])
+3. Review phase accomplishments
+4. Done for now
+```
+
+</step>
+
+</process>
+
+<success_criteria>
+
+- All tasks from PLAN.md completed
+- All verifications pass
+- SUMMARY.md created with substantive content
+- STATE.md updated (position, decisions, issues, session)
+- ROADMAP.md updated
+  </success_criteria>