@sniper.ai/core 2.0.0 → 3.0.0

package/framework/checklists/memory-review.md

@@ -1,30 +0,0 @@
-# Memory Review Checklist
-
-Gate mode: **flexible** (memory entries are informational, auto-advance)
-
-## Conventions (`.sniper/memory/conventions.yaml`)
-- [ ] Every convention has a non-empty `rule` field with a clear, imperative statement
-- [ ] Every convention has a `rationale` explaining why it exists
-- [ ] Every convention has at least one role in `applies_to`
-- [ ] Every convention has `enforcement` set to one of: review_gate, spawn_prompt, both
-- [ ] No two conventions have identical or contradictory rules
-- [ ] Convention IDs are unique and follow the `conv-XXX` pattern
-
-## Anti-Patterns (`.sniper/memory/anti-patterns.yaml`)
-- [ ] Every anti-pattern has a non-empty `description`
-- [ ] Every anti-pattern has a `fix_pattern` describing the correct approach
-- [ ] Every anti-pattern has `severity` set to one of: high, medium, low
-- [ ] Every anti-pattern has at least one role in `applies_to`
-- [ ] Anti-pattern IDs are unique and follow the `ap-XXX` pattern
-
-## Decisions (`.sniper/memory/decisions.yaml`)
-- [ ] Every decision has `title`, `context`, and `decision` fields filled
-- [ ] Every decision has at least one alternative in `alternatives_considered`
-- [ ] Every decision has `status` set to one of: active, superseded, deprecated
-- [ ] Superseded decisions reference the replacing decision in `superseded_by`
-- [ ] Decision IDs are unique and follow the `dec-XXX` pattern
-
-## Overall
-- [ ] No duplicate entries across conventions, anti-patterns, and decisions
-- [ ] All source references are valid (type and ref fields populated)
-- [ ] Candidate entries have sufficient evidence to remain as candidates

package/framework/checklists/perf-review.md

@@ -1,33 +0,0 @@
-# Performance Audit Review Checklist
-
-Use this checklist to review artifacts produced during a performance audit lifecycle.
-
-## Profile Report (`docs/audits/PERF-{NNN}/profile-report.md`)
-
-- [ ] **Actual bottlenecks:** Findings are based on code analysis, not premature optimization guesses
-- [ ] **Specific locations:** Each bottleneck includes file:line or file:function references
-- [ ] **Categorized:** Bottlenecks are categorized (N+1, missing index, sync I/O, etc.)
-- [ ] **Impact assessed:** Severity based on path frequency and latency contribution
-- [ ] **Critical paths traced:** Request handling chains are fully traced
-- [ ] **Existing optimizations noted:** Current caching and indexing acknowledged
-
-## Optimization Plan (`docs/audits/PERF-{NNN}/optimization-plan.md`)
-
-- [ ] **Expected improvement stated:** Each recommendation includes specific improvement description
-- [ ] **Trade-offs documented:** Caching complexity, consistency risks, etc. are noted
-- [ ] **Quick wins identified:** Low-effort, high-impact optimizations separated
-- [ ] **Benchmark requirements:** Each optimization has a corresponding benchmark requirement
-- [ ] **Priority matrix sensible:** Impact/effort ratio drives the ordering
-
-## Stories (`docs/audits/PERF-{NNN}/stories/`)
-
-- [ ] **Paired with benchmarks:** Each optimization story has a companion benchmark story
-- [ ] **Quick wins first:** Low-effort optimizations are prioritized
-- [ ] **Self-contained:** Each story can be implemented and verified independently
-- [ ] **Measurable:** Success criteria include specific performance metrics
-
-## Overall
-
-- [ ] **Data-driven:** No premature optimization — all changes backed by profiling evidence
-- [ ] **Consistency:** Profile, plan, and stories tell a coherent story
-- [ ] **Verification plan:** Clear strategy for measuring improvement after implementation

package/framework/checklists/plan-review.md

@@ -1,52 +0,0 @@
-# Planning Review Checklist
-
-Gate mode: **STRICT** (human MUST approve before Phase 3)
-
-## PRD (`docs/prd.md`)
-- [ ] Problem statement includes evidence (not just assertions)
-- [ ] User stories follow "As a [persona], I want, so that" format
-- [ ] P0 requirements are minimal — only what's critical for v1
-- [ ] Every requirement has testable acceptance criteria
-- [ ] Non-functional requirements have specific measurable targets
-- [ ] Success metrics have numbers (not vague "improve X")
-- [ ] Out-of-scope explicitly names features users might expect
-- [ ] No duplicate requirements
-
-## Architecture (`docs/architecture.md`)
-- [ ] Every technology choice includes: what, why, alternatives considered
-- [ ] Component diagram shows clear boundaries and interfaces
-- [ ] Data models include field types, constraints, indexes, relationships
-- [ ] API contracts are specific enough for independent frontend/backend implementation
-- [ ] Infrastructure specifies sizing, scaling triggers, cost estimates
-- [ ] Cross-cutting concerns addressed (auth, logging, errors, config)
-- [ ] Non-functional targets have implementation strategies
-- [ ] Security architecture aligns with `docs/security.md`
-
-## UX Specification (`docs/ux-spec.md`)
-- [ ] Information architecture maps all pages/views
-- [ ] Screen inventory covers all user-facing screens
-- [ ] User flows include error paths, not just happy paths
-- [ ] Component specs include all states (default, hover, active, disabled, loading, error)
-- [ ] Responsive breakpoints specify actual layout changes
-- [ ] Accessibility requirements name specific WCAG criteria
-- [ ] UX flows align with PRD user stories
-
-## Security Requirements (`docs/security.md`)
-- [ ] Authentication model specified (OAuth, JWT, session, etc.)
-- [ ] Authorization model specified (RBAC, ABAC, etc.)
-- [ ] Data encryption strategy covers at-rest and in-transit
-- [ ] Compliance requirements name specific regulations
-- [ ] Threat model identifies top attack vectors
-- [ ] Security testing requirements are defined
-
-## Cross-Document Consistency
-- [ ] Architecture API contracts match UX component data needs
-- [ ] Security requirements are implementable within architecture choices
-- [ ] PRD requirements are fully coverable by architecture design
-- [ ] No orphaned requirements (in PRD but not in architecture)
-
-## Approval
-**Reviewer:** _______________
-**Date:** _______________
-**Decision:** APPROVED / NEEDS REVISION
-**Feedback:**

package/framework/checklists/refactor-review.md

@@ -1,33 +0,0 @@
-# Refactor Review Checklist
-
-Use this checklist to review artifacts produced during a refactoring lifecycle.
-
-## Impact Analysis (`docs/refactors/REF-{NNN}/scope.md`)
-
-- [ ] **Complete inventory:** All instances of the pattern being changed are counted
-- [ ] **Files listed:** Every affected file is listed, not estimated
-- [ ] **Risk assessment:** Risks are specific, not generic boilerplate
-- [ ] **Compatibility concerns:** API consumers and downstream dependencies are identified
-- [ ] **Effort estimate:** Effort is justified by actual file/instance counts
-
-## Migration Plan (`docs/refactors/REF-{NNN}/plan.md`)
-
-- [ ] **Strategy justified:** Migration strategy choice (big-bang/incremental/strangler) has clear rationale
-- [ ] **Order makes sense:** Steps follow dependency order (e.g., shared code before consuming code)
-- [ ] **Coexistence plan:** Describes how old and new patterns coexist during migration
-- [ ] **Verification at each step:** Each step has specific tests or checks
-- [ ] **Rollback plan:** Each step can be reversed independently
-- [ ] **No data loss risk:** Database migrations are reversible or have a safety net
-
-## Stories (`docs/refactors/REF-{NNN}/stories/`)
-
-- [ ] **Coverage:** Stories cover all instances from the pattern inventory
-- [ ] **Order matches plan:** Story dependencies follow the migration plan order
-- [ ] **Self-contained:** Each story can be implemented and verified independently
-- [ ] **Tests included:** Each story includes test updates for the migrated code
-
-## Overall
-
-- [ ] **Consistency:** Scope, plan, and stories tell a coherent story
-- [ ] **Completeness:** No instances of the old pattern will remain after all stories complete
-- [ ] **Safety:** At no point during the migration will the system be in a broken state

package/framework/checklists/security-review.md

@@ -1,34 +0,0 @@
-# Security Audit Review Checklist
-
-Use this checklist to review artifacts produced during a security audit lifecycle.
-
-## Threat Model (`docs/audits/SEC-{NNN}/threat-model.md`)
-
-- [ ] **Complete attack surface:** All entry points from the architecture doc are mapped
-- [ ] **Trust boundaries identified:** Authentication and authorization boundaries are clearly documented
-- [ ] **Data classified:** Sensitive data types are identified with storage and flow documentation
-- [ ] **STRIDE applied systematically:** All six categories evaluated for each component
-- [ ] **Dependencies assessed:** High-risk packages identified with CVE status
-- [ ] **Threats prioritized:** Top threats ranked by likelihood x impact with justification
-
-## Vulnerability Report (`docs/audits/SEC-{NNN}/vulnerability-report.md`)
-
-- [ ] **Evidence-based findings:** Each vulnerability includes specific file:line and code pattern
-- [ ] **Severity justified:** Severity ratings account for context (auth requirements, exposure)
-- [ ] **OWASP categorized:** Findings mapped to OWASP Top 10 categories
-- [ ] **Remediation included:** Each finding has a concrete fix with code example
-- [ ] **Patterns identified:** Systemic issues (not just individual instances) are flagged
-- [ ] **Positive findings noted:** Existing security practices are acknowledged
-
-## Stories (`docs/audits/SEC-{NNN}/stories/`)
-
-- [ ] **Severity-ordered:** Critical remediation stories come before high, medium, low
-- [ ] **Systemic first:** Middleware and validation layer fixes before individual fixes
-- [ ] **Secure code:** Remediation code follows secure coding practices
-- [ ] **Test coverage:** Each story includes security test requirements
-
-## Overall
-
-- [ ] **Consistency:** Threat model and vulnerability report align (threats have corresponding findings)
-- [ ] **Completeness:** All critical and high findings have remediation stories
-- [ ] **Practicality:** Recommendations are actionable within the project's constraints

package/framework/checklists/sprint-review.md

@@ -1,41 +0,0 @@
-# Sprint Review Checklist
-
-Gate mode: **STRICT** (human MUST review code before merge)
-
-## Code Quality
-- [ ] All code passes linting (no warnings or errors)
-- [ ] All code passes static type checking (language-appropriate strict mode)
-- [ ] No type escape hatches introduced (e.g. `any` in TS, `Any` in Python, `interface{}` in Go)
-- [ ] No hardcoded secrets, API keys, or credentials
-- [ ] Error handling on all async operations
-- [ ] Follows existing codebase patterns and conventions
-
-## Testing
-- [ ] All stories have corresponding tests
-- [ ] Tests pass (0 failures)
-- [ ] Test coverage meets project minimum threshold
-- [ ] Integration tests cover API endpoints
-- [ ] Edge cases and error paths are tested
-- [ ] No flaky tests introduced
-
-## Acceptance Criteria
-- [ ] Every acceptance criterion from every sprint story is verified
-- [ ] Deviations from acceptance criteria are documented and justified
-
-## Architecture Compliance
-- [ ] Code follows the architecture patterns from `docs/architecture.md`
-- [ ] API contracts match the spec (endpoints, payloads, status codes)
-- [ ] Data models match the schema design
-- [ ] File ownership boundaries respected (no cross-boundary edits)
-
-## Security
-- [ ] No new security vulnerabilities introduced (OWASP Top 10)
-- [ ] Input validation on all user-facing endpoints
-- [ ] Authentication and authorization enforced where required
-- [ ] Sensitive data encrypted and handled properly
-
-## Approval
-**Reviewer:** _______________
-**Date:** _______________
-**Decision:** APPROVED / NEEDS REVISION
-**Feedback:**

package/framework/checklists/story-review.md

@@ -1,30 +0,0 @@
-# Story Review Checklist
-
-Gate mode: **FLEXIBLE** (auto-advance, async review)
-
-## Epic Structure (`docs/epics/*.md`)
-- [ ] Epics number between 6-12 (enough granularity, not too fragmented)
-- [ ] No overlap between epics — each requirement maps to exactly one epic
-- [ ] Epic dependencies form a DAG (no circular dependencies)
-- [ ] Each epic has clear scope boundaries (in/out)
-- [ ] Architecture context is EMBEDDED in each epic, not just referenced
-- [ ] Complexity estimates are realistic
-
-## Story Quality (`docs/stories/*.md`)
-- [ ] Each story is self-contained — a developer can implement from the story file alone
-- [ ] PRD context is EMBEDDED (copied), not just referenced
-- [ ] Architecture context is EMBEDDED (data models, API contracts, patterns)
-- [ ] UX context is EMBEDDED for frontend stories
-- [ ] Acceptance criteria use Given/When/Then format
-- [ ] Every acceptance criterion is testable
-- [ ] Test requirements are specified (unit, integration, e2e)
-- [ ] File ownership is assigned (which directories the story touches)
-- [ ] Dependencies on other stories are declared
-- [ ] Complexity estimate (S/M/L/XL) is assigned
-- [ ] No story is XL — if so, it should be split
-
-## Coverage
-- [ ] All P0 PRD requirements are covered by stories
-- [ ] All P1 PRD requirements are covered by stories
-- [ ] All architecture components have at least one implementing story
-- [ ] Story dependency chains allow reasonable sprint planning

package/framework/checklists/test-review.md

@@ -1,32 +0,0 @@
-# Test & Coverage Review Checklist
-
-Use this checklist to review artifacts produced during a test audit lifecycle.
-
-## Coverage Report (`docs/audits/TST-{NNN}/coverage-report.md`)
-
-- [ ] **Coverage data sourced:** Coverage numbers come from actual test runner output, not estimates
-- [ ] **Critical gaps identified:** Uncovered code paths in high-risk areas (auth, payments, data handling) are flagged
-- [ ] **Risk-based ranking:** Gaps are ranked by production impact, not just by coverage percentage
-- [ ] **Integration boundaries mapped:** Cross-module interaction points are checked against architecture components
-- [ ] **Pattern analysis present:** Testing consistency (assertion styles, mocks, naming) is assessed
-
-## Flaky Report (`docs/audits/TST-{NNN}/flaky-report.md`)
-
-- [ ] **Root causes identified:** Each flaky test has a specific root cause, not just "flaky"
-- [ ] **Evidence provided:** Flakiness is demonstrated with evidence (dual-run results or code pattern analysis)
-- [ ] **No retry-only fixes:** Suggested fixes address root causes, not just add retries
-- [ ] **Systemic issues flagged:** Patterns causing multiple flaky tests are identified
-- [ ] **Quick wins separated:** Low-effort fixes are clearly distinguished from larger refactors
-
-## Stories (`docs/audits/TST-{NNN}/stories/`)
-
-- [ ] **Priority order:** Critical gap fixes and quick-win flake fixes come first
-- [ ] **Scoped improvements:** Each story handles one logical test improvement
-- [ ] **Follows conventions:** Suggested tests follow the project's existing test patterns
-- [ ] **Actionable:** Each story has specific file:line references and concrete test approaches
-
-## Overall
-
-- [ ] **Consistency:** Coverage report and flaky report don't contradict each other
-- [ ] **Completeness:** All critical gaps and systemic flake issues have corresponding stories
-- [ ] **Practicality:** Recommendations are achievable (not "rewrite all tests from scratch")

package/framework/checklists/workspace-review.md

@@ -1,34 +0,0 @@
-# Workspace Feature Review Checklist
-
-Gate mode: **strict** (cross-repo features require approval before implementation)
-
-## Workspace Feature Brief
-- [ ] All affected repositories are identified with clear justification
-- [ ] Repositories not affected are explicitly excluded with reasoning
-- [ ] New interfaces are documented with type (REST/Type/Event) and participating repos
-- [ ] Modified interfaces reference existing contract versions
-- [ ] Wave ordering respects the dependency graph — no repo sprints before its dependencies
-- [ ] Repos in the same dependency tier are grouped for parallel execution
-- [ ] Risks and considerations are identified for cross-repo coordination
-
-## Interface Contracts
-- [ ] Every new cross-repo interface has a formal contract
-- [ ] Every contract has full request/response schemas for all endpoints
-- [ ] Error responses are defined, not just success cases
-- [ ] Shared types specify exactly one owning repository
-- [ ] Event contracts specify producer and consumer(s) with payload schemas
-- [ ] Contract versions follow semver (breaking changes = major bump)
-- [ ] Contracts are self-contained — implementable without reading other repo code
-
-## Cross-Repo Implementation Plan
-- [ ] Per-repo work breakdown covers all affected repositories
-- [ ] Each repo's stories reference specific contract items
-- [ ] Sprint wave ordering matches the dependency ordering in the brief
-- [ ] Integration validation criteria are defined for each wave boundary
-- [ ] Rollback plan exists for contract validation failures
-
-## Overall
-- [ ] No circular dependencies in the wave ordering
-- [ ] Workspace memory conventions are consistent across repos
-- [ ] All contract files are valid YAML
-- [ ] Feature numbering follows WKSP-XXXX pattern

package/framework/claude-md.template

@@ -1,37 +0,0 @@
-# SNIPER Project
-
-## Framework
-This project uses SNIPER (Spawn, Navigate, Implement, Parallelize, Evaluate, Release).
-See `.sniper/config.yaml` for project settings.
-
-## Quick Reference
-- Framework workflows: `.sniper/workflows/`
-- Persona layers: `.sniper/personas/`
-- Team definitions: `.sniper/teams/`
-- Artifact templates: `.sniper/templates/`
-- Quality gates: `.sniper/checklists/`
-- Project artifacts: `docs/`
-- Domain context: `.sniper/domain-packs/{pack-name}/`
-
-## Commands
-- `/sniper-init` — Initialize SNIPER in a new project
-- `/sniper-discover` — Phase 1: Discovery & Analysis (parallel team)
-- `/sniper-plan` — Phase 2: Planning & Architecture (parallel team)
-- `/sniper-solve` — Phase 3: Epic Sharding & Story Creation (sequential)
-- `/sniper-sprint` — Phase 4: Implementation Sprint (parallel team)
-- `/sniper-review` — Run review gate for current phase
-- `/sniper-compose` — Create a spawn prompt from persona layers
-- `/sniper-status` — Show lifecycle status and artifact state
-
-## Agent Teams Rules
-When spawning teammates, always:
-1. Read the relevant team YAML from `.sniper/teams/`
-2. Compose spawn prompts using `/sniper-compose` with the layers specified in the YAML
-3. Assign file ownership boundaries from `config.yaml` ownership rules
-4. Create tasks with dependencies from the team YAML
-5. Enter delegate mode (Shift+Tab) — the lead coordinates, it does not code
-6. Require plan approval for tasks marked `plan_approval: true`
-7. When a phase completes, run `/sniper-review` before advancing
-
-## Code Standards
-See `.sniper/config.yaml` → stack section for language/framework specifics.