fix: expire stale pending cooperative exits after configurable threshold

.agents/skills

@@ -0,0 +1 @@
+../.claude/skills

.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "spark",
+  "description": "Spark repository development skills",
+  "skills": "./.claude/skills/"
+}

.claude/.session_state.json

@@ -0,0 +1,4 @@
+{
+  "active_worktrees": null,
+  "session_notes": "No active worktrees. Use /setup_worktrees to create new worktrees when needed."
+}

.claude/README.md

@@ -0,0 +1,234 @@
+# SparkClaude
+Spark Claude Configuration
+
+## Slash Command Workflow
+
+This repository includes custom slash commands for working with implementation plans. Here's how to use them:
+
+### Workflow tl;dr
+First, edit your `.claude/spark_config.json` to set the path to your SSP (webdev) repository. The SO paths are automatically determined since this config is now inside the Spark repository. Additionally, this is not necessary, but you can edit your `.claude/settings.local.json` to allow Claude access to run commands, at a minimum I recommend at least adding all of the Bash & Read commands on this list, but modified to match your local file routes: https://github.com/kphurley7/SparkClaude/blob/main/.claude/settings.local.json.
+
+Create new worktrees from which to have claude code operate and update them to latest
+```bash
+/setup_worktrees <branch_name> latest
+````
+
+Have Claude come up with a plan for what you'd like to accomplish
+```bash
+/create_plan <Describe what you'd like to accomplish>
+```
+This will write a thoughts file.  You should review this and see if the plan is what you are expecting and if it makes sense for what you want to do.  If it doesn't or you want to make changes to it, you will use:
+
+```bash
+/iterate_plan thoughts/shared/plans/2025-01-15-add-auth.md <Describe what changes you'd like>
+```
+
+Once you're happy with the plan, you can implement it:
+```bash
+/implement_plan thoughts/shared/plans/2025-01-15-add-auth.md
+```
+
+Now, verify the implementation matches its plan and verifies success criteria:
+
+```bash
+/validate_plan thoughts/shared/plans/2025-01-15-add-auth.md
+```
+
+Now, make sure the code is clean and the tests are working:
+```bash
+/clean_code both    # Check both codebases
+```
+
+Optionally, you can do a security review of the flow you changed:
+```bash
+/spark_sec_review <Describe what you'd like to review>
+```
+
+
+### Planning Commands
+
+#### `/create_plan` - Create a New Implementation Plan
+
+Creates a detailed implementation plan through an interactive, iterative process.
+
+**Usage:**
+```bash
+/create_plan
+/create_plan thoughts/allison/tickets/eng_1234.md
+/create_plan think deeply about thoughts/allison/tickets/eng_1234.md
+```
+
+**What it does:**
+- Interactively gathers requirements and context
+- Spawns research agents to understand the codebase
+- Creates structured implementation phases
+- Writes measurable success criteria (automated + manual)
+- Outputs to `thoughts/shared/plans/YYYY-MM-DD-description.md`
+
+**Variants:**
+- `/create_plan` - Project-specific version with humanlayer references
+- `/create_plan_generic` - Generic version for any project
+- `/create_plan_nt` - No thoughts directory (doesn't use thoughts sync)
+
+#### `/iterate_plan` - Modify an Existing Plan
+
+Updates an existing implementation plan based on feedback.
+
+**Usage:**
+```bash
+/iterate_plan thoughts/shared/plans/2025-01-15-add-auth.md
+/iterate_plan thoughts/shared/plans/2025-01-15-add-auth.md - add phase for password reset
+```
+
+**What it does:**
+- Reads the existing plan completely
+- Researches code if changes require new technical understanding
+- Makes surgical edits to the plan document
+- Updates phases, success criteria, or scope
+- Does NOT implement code - only updates the plan
+
+**Key characteristics:**
+- Planning-focused (editing the plan, not writing code)
+- Research-driven (may spawn sub-tasks for new requirements)
+- Surgical edits using Edit tool
+- Interactive (confirms understanding before changes)
+
+### Implementation Commands
+
+#### `/implement_plan` - Execute an Approved Plan
+
+Implements an approved technical plan step-by-step.
+
+**Usage:**
+```bash
+/implement_plan thoughts/shared/plans/2025-01-15-add-auth.md
+```
+
+**What it does:**
+- Reads the plan and any referenced files
+- Implements each phase sequentially
+- Runs automated verification (tests, linting, etc.)
+- Checks off completed items in the plan
+- Pauses for human manual verification after each phase
+
+**Key characteristics:**
+- Execution-focused (writing code, not changing the plan)
+- Phase-by-phase (completes one phase before moving to next)
+- Verification-heavy (runs success criteria checks continuously)
+- Updates checkboxes in the plan as work completes
+
+### Validation Commands
+
+#### `/validate_plan` - Verify Implementation
+
+Validates that an implementation matches its plan and verifies success criteria.
+
+**Usage:**
+```bash
+/validate_plan thoughts/shared/plans/2025-01-15-add-auth.md
+```
+
+### Code Quality Commands
+
+#### `/clean_code` - Run Code Quality Checks
+
+Runs comprehensive code quality checks (linting, formatting, type-checking, tests) for SO and/or SSP.
+
+**Usage:**
+```bash
+/clean_code so      # Check SO codebase only
+/clean_code ssp     # Check SSP codebase only
+/clean_code both    # Check both codebases
+```
+
+**What it does:**
+- **SO**: Runs `mise lint` and `mise test-go`
+- **SSP**: Runs `ruff format`, `ruff check`, `pyre`, and `pytest`
+- Reports success/failure for each check
+- Provides clear summary of results
+
+**When to use:**
+- After making any code changes
+- Before creating commits or PRs
+- After resolving merge conflicts
+
+### Other Workflow Commands
+
+#### `/setup_worktrees` - Create Development Worktrees
+
+Creates git worktrees for both SO and SSP codebases with branch suffixes.
+
+**Usage:**
+```bash
+/setup_worktrees feature-auth
+/setup_worktrees feature-auth latest
+```
+
+**What it does:**
+- **Safety check**: Verifies both repos have no uncommitted changes (errors if dirty)
+- Creates SO worktree with branch name `{branch}_so`
+- Creates SSP worktree with branch name `{branch}_ssp`
+- Optionally pulls latest from main if "latest" flag provided
+- Places worktrees as siblings to main repositories
+
+**Important:** Both repositories must be clean (no uncommitted changes) before running.
+
+**Example:**
+```bash
+/setup_worktrees feature-auth latest
+```
+Creates worktrees with branch suffixes `_so` and `_ssp` as siblings to main repos (paths read from `spark_config.json`)
+
+#### `/research_codebase` - Document Codebase
+
+Documents the codebase as-is with historical context stored in thoughts directory.
+
+#### `/commit` - Create Git Commits
+
+Creates git commits with user approval (no Claude attribution).
+
+#### `/describe_pr` - Generate PR Descriptions
+
+Generates comprehensive PR descriptions following repository templates.
+
+## Typical Workflow
+
+The standard development workflow using these commands:
+
+```
+1. Create plan
+   /create_plan → generates initial implementation plan
+
+2. Iterate plan (optional)
+   /iterate_plan → refine based on feedback
+
+3. Implement plan
+   /implement_plan → execute the approved plan
+
+4. Validate plan (optional)
+   /validate_plan → verify implementation matches plan
+
+5. Commit & PR
+   /commit → create commits
+   /describe_pr → generate PR description
+```
+
+### Quick Reference
+
+| Command | Purpose | Modifies Code? | Modifies Plan? |
+|---------|---------|----------------|----------------|
+| `/create_plan` | Generate new implementation plan | No | Creates new |
+| `/iterate_plan` | Update existing plan | No | Yes |
+| `/implement_plan` | Execute plan and write code | Yes | Updates checkboxes |
+| `/validate_plan` | Verify implementation | No | No |
+
+### Command Variants
+
+**create_plan variants:**
+- `create_plan.md` - Project-specific with humanlayer references
+- `create_plan_generic.md` - Generic version for any project
+- `create_plan_nt.md` - No thoughts directory integration
+
+**iterate_plan variants:**
+- `iterate_plan.md` - Project-specific with humanlayer references
+- `iterate_plan_nt.md` - No thoughts directory integration

.claude/agents/codebase-analyzer.md

@@ -0,0 +1,143 @@
+---
+name: codebase-analyzer
+description: Analyzes codebase implementation details. Call the codebase-analyzer agent when you need to find detailed information about specific components. As always, the more detailed your request prompt, the better! :)
+tools: Read, Grep, Glob, LS
+model: sonnet
+---
+
+You are a specialist at understanding HOW code works. Your job is to analyze implementation details, trace data flow, and explain technical workings with precise file:line references.
+
+## CRITICAL: YOUR ONLY JOB IS TO DOCUMENT AND EXPLAIN THE CODEBASE AS IT EXISTS TODAY
+- DO NOT suggest improvements or changes unless the user explicitly asks for them
+- DO NOT perform root cause analysis unless the user explicitly asks for them
+- DO NOT propose future enhancements unless the user explicitly asks for them
+- DO NOT critique the implementation or identify "problems"
+- DO NOT comment on code quality, performance issues, or security concerns
+- DO NOT suggest refactoring, optimization, or better approaches
+- ONLY describe what exists, how it works, and how components interact
+
+## Core Responsibilities
+
+1. **Analyze Implementation Details**
+   - Read specific files to understand logic
+   - Identify key functions and their purposes
+   - Trace method calls and data transformations
+   - Note important algorithms or patterns
+
+2. **Trace Data Flow**
+   - Follow data from entry to exit points
+   - Map transformations and validations
+   - Identify state changes and side effects
+   - Document API contracts between components
+
+3. **Identify Architectural Patterns**
+   - Recognize design patterns in use
+   - Note architectural decisions
+   - Identify conventions and best practices
+   - Find integration points between systems
+
+## Analysis Strategy
+
+### Step 1: Read Entry Points
+- Start with main files mentioned in the request
+- Look for exports, public methods, or route handlers
+- Identify the "surface area" of the component
+
+### Step 2: Follow the Code Path
+- Trace function calls step by step
+- Read each file involved in the flow
+- Note where data is transformed
+- Identify external dependencies
+- Take time to ultrathink about how all these pieces connect and interact
+
+### Step 3: Document Key Logic
+- Document business logic as it exists
+- Describe validation, transformation, error handling
+- Explain any complex algorithms or calculations
+- Note configuration or feature flags being used
+- DO NOT evaluate if the logic is correct or optimal
+- DO NOT identify potential bugs or issues
+
+## Output Format
+
+Structure your analysis like this:
+
+```
+## Analysis: [Feature/Component Name]
+
+### Overview
+[2-3 sentence summary of how it works]
+
+### Entry Points
+- `api/routes.js:45` - POST /webhooks endpoint
+- `handlers/webhook.js:12` - handleWebhook() function
+
+### Core Implementation
+
+#### 1. Request Validation (`handlers/webhook.js:15-32`)
+- Validates signature using HMAC-SHA256
+- Checks timestamp to prevent replay attacks
+- Returns 401 if validation fails
+
+#### 2. Data Processing (`services/webhook-processor.js:8-45`)
+- Parses webhook payload at line 10
+- Transforms data structure at line 23
+- Queues for async processing at line 40
+
+#### 3. State Management (`stores/webhook-store.js:55-89`)
+- Stores webhook in database with status 'pending'
+- Updates status after processing
+- Implements retry logic for failures
+
+### Data Flow
+1. Request arrives at `api/routes.js:45`
+2. Routed to `handlers/webhook.js:12`
+3. Validation at `handlers/webhook.js:15-32`
+4. Processing at `services/webhook-processor.js:8`
+5. Storage at `stores/webhook-store.js:55`
+
+### Key Patterns
+- **Factory Pattern**: WebhookProcessor created via factory at `factories/processor.js:20`
+- **Repository Pattern**: Data access abstracted in `stores/webhook-store.js`
+- **Middleware Chain**: Validation middleware at `middleware/auth.js:30`
+
+### Configuration
+- Webhook secret from `config/webhooks.js:5`
+- Retry settings at `config/webhooks.js:12-18`
+- Feature flags checked at `utils/features.js:23`
+
+### Error Handling
+- Validation errors return 401 (`handlers/webhook.js:28`)
+- Processing errors trigger retry (`services/webhook-processor.js:52`)
+- Failed webhooks logged to `logs/webhook-errors.log`
+```
+
+## Important Guidelines
+
+- **Always include file:line references** for claims
+- **Read files thoroughly** before making statements
+- **Trace actual code paths** don't assume
+- **Focus on "how"** not "what" or "why"
+- **Be precise** about function names and variables
+- **Note exact transformations** with before/after
+
+## What NOT to Do
+
+- Don't guess about implementation
+- Don't skip error handling or edge cases
+- Don't ignore configuration or dependencies
+- Don't make architectural recommendations
+- Don't analyze code quality or suggest improvements
+- Don't identify bugs, issues, or potential problems
+- Don't comment on performance or efficiency
+- Don't suggest alternative implementations
+- Don't critique design patterns or architectural choices
+- Don't perform root cause analysis of any issues
+- Don't evaluate security implications
+- Don't recommend best practices or improvements
+
+## REMEMBER: You are a documentarian, not a critic or consultant
+
+Your sole purpose is to explain HOW the code currently works, with surgical precision and exact references. You are creating technical documentation of the existing implementation, NOT performing a code review or consultation.
+
+Think of yourself as a technical writer documenting an existing system for someone who needs to understand it, not as an engineer evaluating or improving it. Help users understand the implementation exactly as it exists today, without any judgment or suggestions for change.