@sniper.ai/core 2.0.0 → 3.0.0

package/framework/templates/security.md

@@ -1,111 +0,0 @@
-# Security Assessment: {project_name}
-
-> **Version:** 1
-> **Status:** Draft
-> **Last Updated:** {date}
-> **Author:** Planning Team — Security Analyst
-> **Change Log:**
-> - v1 ({date}): Initial version
-
-## Security Overview
-<!-- sniper:managed:overview:start -->
-<!-- 2-3 sentence summary of the project's security posture and key concerns -->
-<!-- sniper:managed:overview:end -->
-
-## Authentication & Authorization
-
-<!-- sniper:managed:auth:start -->
-### Authentication Model
-<!-- OAuth 2.0 / JWT / Session-based / API Keys / Multi-factor -->
-
-### Authorization Model
-<!-- RBAC / ABAC / ACL — describe roles, permissions, and access levels -->
-
-### Session Management
-<!-- Token lifecycle, refresh strategy, revocation, concurrent sessions -->
-<!-- sniper:managed:auth:end -->
-
-## Data Security
-
-<!-- sniper:managed:data-security:start -->
-### Data Classification
-| Data Type | Classification | Storage | Encryption | Retention |
-|-----------|---------------|---------|------------|-----------|
-| | | | | |
-
-### Encryption Requirements
-- **At Rest:** <!-- AES-256, database-level, field-level -->
-- **In Transit:** <!-- TLS 1.3, certificate pinning -->
-- **Key Management:** <!-- KMS, rotation policy -->
-
-### PII Handling
-<!-- What PII is collected, how it's stored, who can access it, deletion policy -->
-<!-- sniper:managed:data-security:end -->
-
-## API Security
-
-<!-- sniper:managed:api-security:start -->
-### Input Validation
-<!-- Validation strategy, sanitization, schema enforcement -->
-
-### Rate Limiting
-<!-- Per-endpoint limits, burst handling, API key tiers -->
-
-### OWASP Top 10 Mitigations
-| Vulnerability | Risk Level | Mitigation |
-|--------------|-----------|------------|
-| Injection | | |
-| Broken Authentication | | |
-| Sensitive Data Exposure | | |
-| XML External Entities | | |
-| Broken Access Control | | |
-| Security Misconfiguration | | |
-| Cross-Site Scripting | | |
-| Insecure Deserialization | | |
-| Known Vulnerabilities | | |
-| Insufficient Logging | | |
-<!-- sniper:managed:api-security:end -->
-
-## Infrastructure Security
-
-<!-- sniper:managed:infra-security:start -->
-### Network Architecture
-<!-- VPC, subnets, security groups, WAF, CDN -->
-
-### Secrets Management
-<!-- Vault, environment variables, rotation policy -->
-
-### Logging & Monitoring
-<!-- Security event logging, alerting, SIEM integration -->
-<!-- sniper:managed:infra-security:end -->
-
-## Compliance Requirements
-<!-- sniper:managed:compliance:start -->
-<!-- Applicable frameworks: SOC 2, GDPR, HIPAA, PCI-DSS, etc. -->
-<!-- sniper:managed:compliance:end -->
-
-## Threat Model
-
-<!-- sniper:managed:threat-model:start -->
-### Attack Surface
-<!-- Entry points, trust boundaries, data flows -->
-
-### Key Threats
-| Threat | Likelihood | Impact | Mitigation |
-|--------|-----------|--------|------------|
-| | | | |
-<!-- sniper:managed:threat-model:end -->
-
-## Recommendations
-<!-- sniper:managed:recommendations:start -->
-<!-- Prioritized security recommendations for implementation -->
-1.
-2.
-3.
-<!-- sniper:managed:recommendations:end -->
-
-## Open Questions
-<!-- sniper:managed:open-questions:start -->
-1.
-2.
-<!-- sniper:managed:open-questions:end -->

package/framework/templates/sprint-review.md

@@ -1,32 +0,0 @@
-# Sprint {number} Review
-
-> **Date:** {date}
-> **Stories Completed:** {count}/{total}
-> **Team:** {teammate list}
-
-## Stories Delivered
-| Story | Status | Notes |
-|-------|--------|-------|
-| | Complete / Partial / Blocked | |
-
-## Test Results
-- **Tests passed:** {count}
-- **Tests failed:** {count}
-- **Coverage:** {percentage}
-
-## Code Quality
-- Linting: Pass / Fail
-- Type checking: Pass / Fail
-- Security scan: Pass / Fail
-
-## Technical Debt Introduced
-<!-- Any shortcuts taken, refactoring needed, or known issues -->
-
-## Blockers Encountered
-<!-- What blocked progress and how it was resolved -->
-
-## Lessons Learned
-<!-- What went well, what didn't, what to change next sprint -->
-
-## Next Sprint Candidates
-<!-- Suggested stories for the next sprint -->

package/framework/templates/story.md

@@ -1,53 +0,0 @@
-# Story {epic}.{number}: {title}
-
-> **Version:** 1
-> **Last Updated:** {date}
-> **Epic:** {epic title} (`docs/epics/{epic}.md`)
-> **Complexity:** S | M | L | XL
-> **Priority:** P{0|1|2}
-> **File Ownership:** {directories this story touches}
-> **Dependencies:** {story dependencies or "None"}
-> **Change Log:**
-> - v1 ({date}): Initial version
-
-## Description
-<!-- sniper:managed:description:start -->
-<!-- What this story implements, in user-facing terms -->
-<!-- sniper:managed:description:end -->
-
-## Embedded Context
-
-<!-- sniper:managed:embedded-context:start -->
-### From PRD
-<!-- COPY the relevant requirements and user stories from docs/prd.md -->
-
-### From Architecture
-<!-- COPY the relevant architecture sections (data models, API contracts, patterns) -->
-
-### From UX Spec
-<!-- COPY relevant screen descriptions, user flows, component specs (if frontend story) -->
-<!-- sniper:managed:embedded-context:end -->
-
-## Acceptance Criteria
-<!-- sniper:managed:acceptance-criteria:start -->
-<!-- Testable assertions in Given/When/Then format -->
-1. **Given** ... **When** ... **Then** ...
-2. **Given** ... **When** ... **Then** ...
-<!-- sniper:managed:acceptance-criteria:end -->
-
-## Test Requirements
-<!-- sniper:managed:test-requirements:start -->
-- [ ] Unit tests:
-- [ ] Integration tests:
-- [ ] E2E tests (if applicable):
-<!-- sniper:managed:test-requirements:end -->
-
-## Implementation Notes
-<!-- sniper:managed:implementation-notes:start -->
-<!-- Specific patterns, libraries, or approaches to use -->
-<!-- sniper:managed:implementation-notes:end -->
-
-## Out of Scope
-<!-- sniper:managed:out-of-scope:start -->
-<!-- What this story does NOT include, to prevent scope creep -->
-<!-- sniper:managed:out-of-scope:end -->

package/framework/templates/threat-model.md

@@ -1,71 +0,0 @@
-# Threat Model: {title}
-
-> **Audit ID:** SEC-{NNN}
-> **Status:** Analyzing
-> **Date:** {date}
-> **Author:** Threat Modeler
-
-## Attack Surface Map
-<!-- sniper:managed:attack-surface:start -->
-<!-- All entry points with authentication requirements -->
-
-| Entry Point | Type | Auth Required | Auth Method | Notes |
-|------------|------|--------------|-------------|-------|
-| | API / Webhook / Upload / Admin / WebSocket | Yes/No | JWT/Session/API Key/None | |
-
-<!-- sniper:managed:attack-surface:end -->
-
-## Trust Boundaries
-<!-- sniper:managed:trust-boundaries:start -->
-<!-- Where authenticated/unauthenticated, internal/external, user/admin boundaries exist -->
-
-### Boundary: {name}
-- **Separates:** {trusted side} ↔ {untrusted side}
-- **Enforced by:** {mechanism — middleware, firewall, etc.}
-- **Data crossing:** {what data crosses this boundary}
-
-<!-- sniper:managed:trust-boundaries:end -->
-
-## Data Classification
-<!-- sniper:managed:data-classification:start -->
-
-| Data Type | Classification | Stored In | Encrypted at Rest | Encrypted in Transit | Retention |
-|-----------|---------------|-----------|-------------------|---------------------|-----------|
-| | PII / Credentials / Financial / Internal | | Yes/No | Yes/No | |
-
-<!-- sniper:managed:data-classification:end -->
-
-## Threat Inventory (STRIDE)
-<!-- sniper:managed:threat-inventory:start -->
-
-### {Component/Flow Name}
-
-| Category | Threat | Likelihood | Impact | Risk | Mitigation |
-|----------|--------|-----------|--------|------|------------|
-| Spoofing | | H/M/L | H/M/L | | |
-| Tampering | | H/M/L | H/M/L | | |
-| Repudiation | | H/M/L | H/M/L | | |
-| Info Disclosure | | H/M/L | H/M/L | | |
-| Denial of Service | | H/M/L | H/M/L | | |
-| Elevation of Privilege | | H/M/L | H/M/L | | |
-
-<!-- sniper:managed:threat-inventory:end -->
-
-## Dependency Risk
-<!-- sniper:managed:dependency-risk:start -->
-
-| Package | Version | Known CVEs | Maintained | Risk Level |
-|---------|---------|------------|------------|------------|
-| | | Yes/No | Yes/No | High/Medium/Low |
-
-<!-- sniper:managed:dependency-risk:end -->
-
-## Priority Threats
-<!-- sniper:managed:priority-threats:start -->
-<!-- Top 5 threats ranked by likelihood x impact -->
-
-| Rank | Threat | Component | Likelihood x Impact | Recommended Action |
-|------|--------|-----------|--------------------|--------------------|
-| 1 | | | | |
-
-<!-- sniper:managed:priority-threats:end -->

package/framework/templates/ux-spec.md

@@ -1,71 +0,0 @@
-# UX Specification: {project_name}
-
-> **Version:** 1
-> **Status:** Draft
-> **Last Updated:** {date}
-> **Author:** Planning Team — UX Designer
-> **Source:** `docs/prd.md`, `docs/personas.md`
-> **Change Log:**
-> - v1 ({date}): Initial version
-
-## 1. Information Architecture
-<!-- sniper:managed:information-architecture:start -->
-<!-- Page hierarchy and navigation structure -->
-<!-- sniper:managed:information-architecture:end -->
-
-## 2. Screen Inventory
-<!-- sniper:managed:screen-inventory:start -->
-| Screen | Purpose | User Stories | Key Components |
-|--------|---------|-------------|----------------|
-| | | | |
-<!-- sniper:managed:screen-inventory:end -->
-
-## 3. User Flows
-
-<!-- sniper:managed:user-flows:start -->
-### 3.1 {Flow Name}
-<!-- Step-by-step with decision points, error paths -->
-```
-Step 1: User does X
-  → Success: Go to Step 2
-  → Error: Show error message, stay on current screen
-Step 2: ...
-```
-<!-- sniper:managed:user-flows:end -->
-
-## 4. Component Hierarchy
-<!-- sniper:managed:component-hierarchy:start -->
-<!-- Reusable UI components and their variants -->
-
-### 4.1 {Component Name}
-- **States:** default, hover, active, disabled, loading, error
-- **Props/Variants:**
-- **Accessibility:**
-<!-- sniper:managed:component-hierarchy:end -->
-
-## 5. Interaction Patterns
-<!-- sniper:managed:interaction-patterns:start -->
-<!-- Loading states, transitions, empty states, error states -->
-
-### Loading States
-### Empty States
-### Error States
-### Confirmation Dialogs
-<!-- sniper:managed:interaction-patterns:end -->
-
-## 6. Responsive Strategy
-<!-- sniper:managed:responsive:start -->
-| Breakpoint | Width | Layout Changes |
-|-----------|-------|---------------|
-| Mobile | < 768px | |
-| Tablet | 768-1024px | |
-| Desktop | > 1024px | |
-<!-- sniper:managed:responsive:end -->
-
-## 7. Accessibility Requirements
-<!-- sniper:managed:accessibility:start -->
-- **WCAG Level:** AA
-- **Keyboard Navigation:**
-- **Screen Reader Support:**
-- **Color Contrast:**
-<!-- sniper:managed:accessibility:end -->

package/framework/templates/vulnerability-report.md

@@ -1,56 +0,0 @@
-# Vulnerability Report: {title}
-
-> **Audit ID:** SEC-{NNN}
-> **Status:** Analyzing
-> **Date:** {date}
-> **Author:** Vulnerability Scanner
-
-## Findings Summary
-<!-- sniper:managed:findings-summary:start -->
-
-| Severity | Count |
-|----------|-------|
-| Critical | |
-| High | |
-| Medium | |
-| Low | |
-| **Total** | |
-
-<!-- sniper:managed:findings-summary:end -->
-
-## Vulnerability Inventory
-<!-- sniper:managed:vulnerabilities:start -->
-
-### VULN-001: {title}
-- **Severity:** Critical / High / Medium / Low
-- **Category:** {OWASP Top 10 category, e.g., A01:2021 Broken Access Control}
-- **Location:** `path/to/file.ts:42`
-- **Description:** {what the vulnerability is}
-- **Evidence:** {the specific code pattern that creates the vulnerability}
-- **Impact:** {what an attacker could achieve by exploiting this}
-- **Remediation:** {how to fix it}
-```
-// Example fix
-```
-
-<!-- sniper:managed:vulnerabilities:end -->
-
-## Patterns of Concern
-<!-- sniper:managed:patterns:start -->
-<!-- Systemic issues that appear across multiple locations -->
-
-### {Pattern Name}
-- **Occurrences:** {count} locations
-- **Description:** {what the pattern is and why it's concerning}
-- **Locations:** {list of file:line references}
-- **Systemic Fix:** {how to address this across the codebase}
-
-<!-- sniper:managed:patterns:end -->
-
-## Positive Findings
-<!-- sniper:managed:positive:start -->
-<!-- Security practices that are done well and should be maintained -->
-
-- {Positive finding — e.g., "Consistent use of parameterized queries in `src/db/` layer"}
-
-<!-- sniper:managed:positive:end -->

package/framework/templates/workspace-brief.md

@@ -1,52 +0,0 @@
-# Workspace Feature Brief: {feature_title}
-
-> **ID:** WKSP-{XXXX}
-> **Version:** 1
-> **Status:** Draft
-> **Last Updated:** {date}
-> **Author:** Workspace Orchestrator
-
-## Feature Description
-<!-- sniper:managed:description:start -->
-{One-paragraph description of the cross-repo feature}
-<!-- sniper:managed:description:end -->
-
-## Affected Repositories
-<!-- sniper:managed:affected-repos:start -->
-| Repository | Role | Why Affected | Work Scope |
-|-----------|------|-------------|------------|
-| | | | |
-<!-- sniper:managed:affected-repos:end -->
-
-## New Interfaces
-<!-- sniper:managed:new-interfaces:start -->
-| Interface | Type | Between | Description |
-|-----------|------|---------|-------------|
-| | REST API / Shared Type / Event | repo-a ↔ repo-b | |
-<!-- sniper:managed:new-interfaces:end -->
-
-## Modified Interfaces
-<!-- sniper:managed:modified-interfaces:start -->
-| Contract | Current Version | Change Description | Breaking? |
-|----------|----------------|-------------------|-----------|
-| | | | |
-<!-- sniper:managed:modified-interfaces:end -->
-
-## Dependency Ordering
-<!-- sniper:managed:dependency-ordering:start -->
-Based on the workspace dependency graph:
-
-### Wave 1
-- **{repo}** — {what it produces that others need}
-
-### Wave 2
-- **{repo}** — {depends on Wave 1 outputs}
-
-### Wave 3
-- **{repo}** — {depends on Wave 2 outputs}
-<!-- sniper:managed:dependency-ordering:end -->
-
-## Risks & Considerations
-<!-- sniper:managed:risks:start -->
-- {risk or consideration}
-<!-- sniper:managed:risks:end -->

package/framework/templates/workspace-plan.md

@@ -1,50 +0,0 @@
-# Cross-Repo Implementation Plan: {feature_title}
-
-> **Feature:** WKSP-{XXXX}
-> **Version:** 1
-> **Status:** Draft
-> **Last Updated:** {date}
-> **Author:** Workspace Orchestrator
-> **Contracts:** {list of contract files}
-
-## Per-Repo Work Breakdown
-<!-- sniper:managed:repo-breakdown:start -->
-
-### {repo-name} (Wave {N})
-**Repo Feature ID:** SNPR-{XXXX}
-**Stories:**
-| Story | Description | Contract Refs |
-|-------|-------------|---------------|
-| | | |
-
-**Dependencies from other repos:** {what this repo needs from previous waves}
-**Produces for other repos:** {what this repo provides to subsequent waves}
-
-<!-- sniper:managed:repo-breakdown:end -->
-
-## Sprint Wave Ordering
-<!-- sniper:managed:wave-ordering:start -->
-| Wave | Repositories | Parallel? | Depends On |
-|------|-------------|-----------|------------|
-| 1 | | Yes | — |
-| 2 | | | Wave 1 |
-| 3 | | | Wave 2 |
-<!-- sniper:managed:wave-ordering:end -->
-
-## Integration Validation Criteria
-<!-- sniper:managed:validation-criteria:start -->
-### Between Wave 1 and Wave 2
-- [ ] {contract item to validate}
-
-### Between Wave 2 and Wave 3
-- [ ] {contract item to validate}
-
-### Final Integration
-- [ ] {end-to-end check}
-<!-- sniper:managed:validation-criteria:end -->
-
-## Rollback Plan
-<!-- sniper:managed:rollback:start -->
-If integration validation fails at any wave boundary:
-1. {step}
-<!-- sniper:managed:rollback:end -->

package/framework/workflows/discover-only.md

@@ -1,39 +0,0 @@
-# Discovery-Only Workflow
-
-Run just the discovery phase for research and analysis.
-
-## When to Use
-- Exploring a new project idea before committing
-- Market research or competitive analysis
-- Validating feasibility before full planning
-- User research for an existing product
-
-## Execution
-
-### Step 1: Initialize (if not already done)
-```
-/sniper-init
-```
-Minimal config — just project name and description needed.
-
-### Step 2: Run Discovery
-```
-/sniper-discover
-```
-- Spawns 3-teammate discovery team
-- Produces: project brief, risk assessment, user personas
-- Auto-advances (flexible gate)
-
-### Step 3: Review Artifacts
-```
-/sniper-review
-```
-Review the discovery artifacts. Decide whether to:
-- Proceed to full planning (`/sniper-plan`)
-- Iterate on discovery (re-run `/sniper-discover` with feedback)
-- Shelve the project (no further action needed)
-
-## Notes
-- Discovery artifacts are useful standalone — no need to continue the lifecycle
-- Domain pack context improves discovery quality significantly
-- The analyst teammate benefits from web search for competitive research

package/framework/workflows/full-lifecycle.md

@@ -1,56 +0,0 @@
-# Full Lifecycle Workflow
-
-Run the complete SNIPER lifecycle from discovery through implementation.
-
-## When to Use
-- New greenfield projects
-- Major product rewrites
-- Projects requiring full planning and governance
-
-## Execution Order
-
-### Step 1: Initialize
-```
-/sniper-init
-```
-Configure project name, type, stack, and domain pack.
-
-### Step 2: Discover (Phase 1)
-```
-/sniper-discover
-```
-- Spawns 3-teammate discovery team (analyst, risk-researcher, user-researcher)
-- Produces: `docs/brief.md`, `docs/risks.md`, `docs/personas.md`
-- Gate: FLEXIBLE (auto-advance, review async)
-
-### Step 3: Plan (Phase 2)
-```
-/sniper-plan
-```
-- Spawns 4-teammate planning team (PM, architect, UX, security)
-- Uses Opus model for higher quality output
-- Produces: `docs/prd.md`, `docs/architecture.md`, `docs/ux-spec.md`, `docs/security.md`
-- Gate: STRICT — human MUST approve before proceeding
-
-### Step 4: Solve (Phase 3)
-```
-/sniper-solve
-```
-- Single agent (scrum master) — NOT a team
-- Produces: `docs/epics/*.md`, `docs/stories/*.md`
-- Gate: FLEXIBLE (auto-advance, review async)
-
-### Step 5: Sprint (Phase 4 — repeating)
-```
-/sniper-sprint
-```
-- Select stories for the sprint
-- Spawns implementation team based on story requirements
-- Produces: source code, tests
-- Gate: STRICT — human reviews code before merge
-- Repeat for each sprint until all stories are complete
-
-## Recovery
-- If any phase produces poor output, re-run the phase command
-- Completed files persist on disk — only the conversation resets
-- Sprint failures only affect the current sprint's stories

package/framework/workflows/quick-feature.md

@@ -1,44 +0,0 @@
-# Quick Feature Workflow
-
-Fast-track a single feature without full lifecycle planning.
-
-## When to Use
-- Adding a feature to an existing codebase
-- Feature is well-understood and doesn't need discovery or planning
-- Architecture already exists
-- Just need implementation + tests
-
-## Prerequisites
-- Existing codebase with established patterns
-- Clear feature requirements (from user, issue, or brief description)
-- Architecture document or existing code to follow patterns from
-
-## Execution
-
-### Step 1: Write a Story
-Either:
-- Write a story file manually at `docs/stories/quick-{name}.md`
-- Or describe the feature to the lead and have it generate a story using the template
-
-The story must include:
-- Feature description and acceptance criteria
-- File ownership (which directories to modify)
-- Test requirements
-- Any relevant context from existing architecture
-
-### Step 2: Sprint with Single Story
-```
-/sniper-sprint
-```
-Select only the quick feature story. The command will:
-1. Spawn only the teammates needed for this story
-2. Skip unnecessary roles (e.g., no QA if it's a small change)
-3. Execute the implementation
-
-### Step 3: Review
-Gate: STRICT — always review code before merge, even for quick features.
-
-## Notes
-- Skips Phases 1-3 entirely
-- Best for S/M complexity features
-- For L/XL features, use the full lifecycle — the planning is worth it

package/framework/workflows/sprint-cycle.md

@@ -1,47 +0,0 @@
-# Sprint Cycle Workflow
-
-Execute a single implementation sprint with an Agent Team.
-
-## When to Use
-- Stories already exist in `docs/stories/`
-- Architecture and planning are complete
-- Ready to implement a batch of stories
-
-## Prerequisites
-- `docs/architecture.md` exists and is approved
-- Story files exist in `docs/stories/`
-- Config state shows phase is `solve` (completed) or `sprint`
-
-## Execution
-
-### Step 1: Select Stories
-The `/sniper-sprint` command will:
-1. List all stories from `docs/stories/` that are not yet implemented
-2. Prompt you to select stories for this sprint (or accept a suggested batch)
-3. Determine which teammates are needed based on story file ownership
-
-### Step 2: Team Composition
-Based on selected stories, the command:
-1. Reads `.sniper/teams/sprint.yaml` for available teammate definitions
-2. Selects only the teammates needed (e.g., skip infra-dev if no infra stories)
-3. Composes spawn prompts with story context embedded
-4. Assigns file ownership boundaries from `config.yaml`
-
-### Step 3: Sprint Execution
-1. Creates team `sniper-sprint-{N}`
-2. Creates tasks with dependencies (QA blocked until implementation done)
-3. Spawns teammates with their composed prompts
-4. Lead enters delegate mode — coordinates, does not code
-5. Facilitates API contract alignment between backend/frontend
-6. Monitors progress, intervenes on blocks
-
-### Step 4: Sprint Review
-1. All tasks must be marked complete
-2. Run `/sniper-review` to check the sprint review checklist
-3. Present code diff summary and test results to human
-4. Gate: STRICT — human must approve
-
-### Step 5: Post-Sprint
-1. Update config state (increment sprint number, mark stories as complete)
-2. Clean up the agent team
-3. Proceed to next sprint or declare MVP complete