@sniper.ai/core 2.0.0 → 3.1.0

package/framework/teams/feature-plan.yaml

@@ -1,61 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Feature Planning Team
-# Produces Feature Spec + Architecture Delta for an incremental feature
-# ─────────────────────────────────────────
-
-team_name: sniper-feature-plan-{feature_id}
-description: "Feature planning for {feature_title}"
-model_override: opus  # use Opus for architecture decisions
-
-teammates:
-  - name: feature-pm
-    compose:
-      process: product-manager
-      technical: null
-      cognitive: systems-thinker
-    tasks:
-      - id: feature-spec
-        name: "Feature Requirements Spec"
-        output: docs/features/{feature_id}/spec.md
-        template: .sniper/templates/feature-spec.md
-        description: >
-          Read the feature brief and produce a Feature Spec with functional requirements,
-          non-functional requirements, user stories, API changes, data model changes,
-          UI changes, and rollout strategy. Reference the existing architecture doc to
-          understand the current system context.
-        reads:
-          - "docs/features/{feature_id}/brief.md"
-          - "docs/architecture.md"
-          - "docs/conventions.md"
-        blocked_by: []
-
-  - name: feature-architect
-    compose:
-      process: architect
-      technical: backend
-      cognitive: systems-thinker
-    tasks:
-      - id: arch-delta
-        name: "Architecture Delta"
-        output: docs/features/{feature_id}/arch-delta.md
-        template: .sniper/templates/arch-delta.md
-        description: >
-          Read the feature spec and produce an Architecture Delta documenting what changes
-          to the system architecture this feature requires. Include new components, modified
-          components, new data models, new/modified API endpoints, infrastructure changes,
-          and patterns to follow from existing conventions. The delta will later be merged
-          back into the main architecture doc.
-        reads:
-          - "docs/features/{feature_id}/spec.md"
-          - "docs/architecture.md"
-          - "docs/conventions.md"
-        blocked_by: [feature-spec]
-        plan_approval: true
-
-coordination:
-  - between: [feature-pm, feature-architect]
-    topic: "Feature spec review — architect waits for PM's spec before starting architecture delta"
-
-review_gate:
-  checklist: .sniper/checklists/feature-review.md
-  mode: flexible

package/framework/teams/ingest.yaml

@@ -1,85 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Ingest Team
-# Reverse-engineers project artifacts from an existing codebase
-# ─────────────────────────────────────────
-
-team_name: sniper-ingest
-description: "Reverse-engineer project artifacts from an existing codebase"
-model_override: null  # use default model
-
-teammates:
-  - name: code-archaeologist
-    compose:
-      process: code-archaeologist
-      technical: null
-      cognitive: systems-thinker
-    tasks:
-      - id: project-brief
-        name: "Reverse-engineer Project Brief"
-        output: docs/brief.md
-        template: .sniper/templates/brief.md
-        description: >
-          Read the codebase and produce a project brief that captures what this project does,
-          what problem it solves, who uses it, and what its current scope is. Focus on the
-          business domain and product purpose, not implementation details. Read package.json,
-          README.md, entry points, route definitions, and UI components to understand the project.
-        reads:
-          - "package.json"
-          - "README.md"
-          - "src/"
-        blocked_by: []
-
-  - name: architecture-cartographer
-    compose:
-      process: architecture-cartographer
-      technical: backend
-      cognitive: systems-thinker
-    tasks:
-      - id: system-architecture
-        name: "Reverse-engineer System Architecture"
-        output: docs/architecture.md
-        template: .sniper/templates/architecture.md
-        description: >
-          Map the complete technical architecture from source code. Produce a system architecture
-          document with component diagrams, data models, API contracts, infrastructure topology,
-          and cross-cutting concerns. Document the system AS BUILT, including inconsistencies
-          and technical debt.
-        reads:
-          - "src/"
-          - "db/"
-          - "docker/"
-          - "infra/"
-          - "terraform/"
-          - ".github/"
-        blocked_by: []
-
-  - name: convention-miner
-    compose:
-      process: convention-miner
-      technical: null
-      cognitive: systems-thinker
-    tasks:
-      - id: conventions
-        name: "Extract Coding Conventions"
-        output: docs/conventions.md
-        template: .sniper/templates/conventions.md
-        description: >
-          Analyze the codebase to extract coding conventions: naming, code organization,
-          error handling, testing patterns, API patterns, imports, config, and logging.
-          Every convention must cite a real code example. Also update the ownership section
-          in .sniper/config.yaml to match the actual project directory structure.
-        reads:
-          - "src/"
-          - "tests/"
-          - ".eslintrc*"
-          - "tsconfig*"
-          - ".prettierrc*"
-          - "ruff.toml"
-          - "pyproject.toml"
-        blocked_by: []
-
-coordination: []  # all tasks are independent — parallel execution
-
-review_gate:
-  checklist: .sniper/checklists/ingest-review.md
-  mode: flexible

package/framework/teams/perf.yaml

@@ -1,33 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Performance Audit Team
-# Structured performance analysis
-# ─────────────────────────────────────────
-
-# Phase 1 (Profiling) is run by the lead directly as a single-agent phase.
-# Unlike tests and security which use 2-agent teams, performance analysis
-# is more sequential — the optimization plan depends on a coherent profiling
-# analysis, so a single profiler keeps the analysis consistent.
-#
-# Phase 2 (Optimization Planning) is run by the lead directly.
-# Phase 3 (Execution) uses the standard sprint infrastructure.
-#
-# This team YAML is used by /sniper-audit --target performance.
-
-team_name: sniper-perf-audit-{audit_id}
-description: "Performance Audit: {audit_title}"
-model_override: null
-
-# Personas used by the single-agent phases:
-personas:
-  profiling:
-    process: perf-profiler
-    technical: backend
-    cognitive: systems-thinker
-
-# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
-
-coordination: []
-
-review_gate:
-  checklist: .sniper/checklists/perf-review.md
-  mode: flexible

package/framework/teams/plan.yaml

@@ -1,86 +0,0 @@
-team_name: sniper-plan
-phase: plan
-model_override: opus
-
-teammates:
-  - name: product-manager
-    compose:
-      process: product-manager
-      technical: api-design
-      cognitive: systems-thinker
-      domain: null
-    tasks:
-      - id: prd
-        name: "Product Requirements Document"
-        output: "docs/prd.md"
-        template: ".sniper/templates/prd.md"
-        reads: ["docs/brief.md", "docs/personas.md", "docs/risks.md"]
-        description: >
-          Write a comprehensive PRD covering: problem statement, user stories,
-          feature requirements (P0/P1/P2), success metrics, constraints,
-          and out-of-scope items. This is the single source of truth for what to build.
-
-  - name: architect
-    compose:
-      process: architect
-      technical: backend
-      cognitive: security-first
-      domain: null
-    tasks:
-      - id: architecture
-        name: "System Architecture Document"
-        output: "docs/architecture.md"
-        template: ".sniper/templates/architecture.md"
-        reads: ["docs/prd.md", "docs/brief.md", "docs/risks.md"]
-        blocked_by: [prd]
-        plan_approval: true
-        description: >
-          Design the complete system architecture. Include: component diagram,
-          data models, API contracts, infrastructure topology, technology choices
-          with rationale, and non-functional requirements.
-
-  - name: ux-designer
-    compose:
-      process: ux-designer
-      technical: frontend
-      cognitive: user-empathetic
-      domain: null
-    tasks:
-      - id: ux-spec
-        name: "UX Specification"
-        output: "docs/ux-spec.md"
-        template: ".sniper/templates/ux-spec.md"
-        reads: ["docs/prd.md", "docs/personas.md"]
-        blocked_by: [prd]
-        description: >
-          Define the UX: information architecture, screen inventory,
-          key user flows (with decision trees), component hierarchy,
-          interaction patterns, and responsive breakpoints.
-
-  - name: security-analyst
-    compose:
-      process: architect
-      technical: security
-      cognitive: security-first
-      domain: null
-    tasks:
-      - id: security
-        name: "Security & Compliance Requirements"
-        output: "docs/security.md"
-        template: ".sniper/templates/security.md"
-        reads: ["docs/prd.md", "docs/risks.md"]
-        blocked_by: [prd]
-        description: >
-          Define security architecture: auth model, data encryption strategy,
-          compliance requirements (with specific regulations), threat model,
-          and security testing requirements.
-
-coordination:
-  - between: [architect, security-analyst]
-    topic: "Align security architecture with system architecture"
-  - between: [architect, ux-designer]
-    topic: "Align frontend component boundaries with backend API contracts"
-
-review_gate:
-  checklist: ".sniper/checklists/plan-review.md"
-  mode: strict

package/framework/teams/refactor.yaml

@@ -1,34 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Refactor Team
-# Structured large-scale code refactoring
-# ─────────────────────────────────────────
-
-# Note: Phase 1 (Impact Analysis) and Phase 2 (Migration Planning) are run by
-# the lead directly as single-agent phases. Phase 3 (Execution) uses the
-# standard sprint infrastructure with refactor stories.
-#
-# This team YAML is used for reference by the /sniper-audit --target refactor
-# command to understand the team structure and review gate.
-
-team_name: sniper-refactor-{refactor_id}
-description: "Refactoring: {refactor_title}"
-model_override: null
-
-# Personas used by the single-agent phases:
-personas:
-  impact_analysis:
-    process: impact-analyst
-    technical: null
-    cognitive: devils-advocate
-  migration_planning:
-    process: migration-architect
-    technical: backend
-    cognitive: systems-thinker
-
-# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
-
-coordination: []
-
-review_gate:
-  checklist: .sniper/checklists/refactor-review.md
-  mode: flexible

package/framework/teams/retro.yaml

@@ -1,30 +0,0 @@
-team_name: sniper-retro
-phase: retro
-
-teammates:
-  - name: retro-analyst
-    compose:
-      process: retro-analyst
-      technical: null
-      cognitive: systems-thinker
-      domain: null
-    tasks:
-      - id: sprint-retrospective
-        name: "Sprint Retrospective Analysis"
-        output: ".sniper/memory/retros/sprint-{N}-retro.yaml"
-        template: ".sniper/templates/retro.yaml"
-        reads:
-          - "docs/stories/"
-          - "docs/reviews/"
-          - ".sniper/memory/conventions.yaml"
-          - ".sniper/memory/anti-patterns.yaml"
-        description: >
-          Analyze the completed sprint to extract learnings. Review all story
-          implementations for recurring code patterns, examine review gate
-          results for systematic issues, and calibrate estimation accuracy.
-          Cross-reference findings against existing memory to avoid duplicates.
-          Produce a structured retrospective with actionable findings.
-
-coordination: []
-
-review_gate: null

package/framework/teams/review-pr.yaml

@@ -1,73 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER PR Review Team
-# Multi-perspective pull request review
-# ─────────────────────────────────────────
-
-team_name: sniper-review-pr-{pr_number}
-description: "PR review for #{pr_number}"
-model_override: null
-
-teammates:
-  - name: code-reviewer
-    compose:
-      process: code-reviewer
-      technical: null
-      cognitive: devils-advocate
-    tasks:
-      - id: code-review
-        name: "Code Quality Review"
-        output: docs/reviews/PR-{pr_number}-review.md (code quality section)
-        description: >
-          Review the PR diff for code quality: logic errors, naming clarity,
-          pattern adherence, error handling, complexity, DRY violations, and
-          architecture compliance. Reference docs/conventions.md for project
-          patterns. Each finding must include severity, file:line, description,
-          and suggested fix.
-        reads:
-          - "PR diff"
-          - "docs/conventions.md"
-          - "docs/architecture.md"
-        blocked_by: []
-
-  - name: security-reviewer
-    compose:
-      process: code-reviewer
-      technical: null
-      cognitive: security-first
-    tasks:
-      - id: security-review
-        name: "Security Review"
-        output: docs/reviews/PR-{pr_number}-review.md (security section)
-        description: >
-          Review the PR diff for security issues: OWASP top 10, input validation,
-          authentication checks, authorization checks, secrets handling, SQL injection,
-          XSS, CSRF, insecure dependencies. Each finding must include severity,
-          file:line, description, and suggested fix.
-        reads:
-          - "PR diff"
-          - "docs/security.md"
-        blocked_by: []
-
-  - name: test-reviewer
-    compose:
-      process: qa-engineer
-      technical: null
-      cognitive: systems-thinker
-    tasks:
-      - id: test-review
-        name: "Test Coverage Review"
-        output: docs/reviews/PR-{pr_number}-review.md (test coverage section)
-        description: >
-          Review the PR for test quality and coverage: missing tests for new code
-          paths, uncovered edge cases, test naming, mock patterns, assertion quality.
-          Each finding must include severity and suggested test additions.
-        reads:
-          - "PR diff"
-          - "docs/conventions.md"
-        blocked_by: []
-
-coordination: []  # all reviewers work in parallel
-
-review_gate:
-  checklist: null  # reviews don't have their own review gate
-  mode: auto

package/framework/teams/review-release.yaml

@@ -1,70 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Release Readiness Team
-# Multi-perspective release assessment
-# ─────────────────────────────────────────
-
-team_name: sniper-review-release-{version}
-description: "Release readiness assessment for {version}"
-model_override: null
-
-teammates:
-  - name: release-manager
-    compose:
-      process: release-manager
-      technical: null
-      cognitive: systems-thinker
-    tasks:
-      - id: changelog
-        name: "Changelog & Version Recommendation"
-        output: docs/releases/{version}-readiness.md (changelog and version sections)
-        description: >
-          Read the git log since the last release. Categorize all changes as features,
-          fixes, breaking changes, internal, or docs. Determine the correct semver
-          version bump. Produce a clear, user-facing changelog.
-        reads:
-          - "git log"
-          - "package.json"
-        blocked_by: []
-
-  - name: breaking-change-analyst
-    compose:
-      process: code-reviewer
-      technical: null
-      cognitive: devils-advocate
-    tasks:
-      - id: breaking-changes
-        name: "Breaking Change Analysis"
-        output: docs/releases/{version}-readiness.md (breaking changes and migration sections)
-        description: >
-          Analyze all changes since the last release for breaking changes: API changes,
-          schema changes, configuration changes, behavior changes. For each breaking
-          change, write a migration step. Err on the side of flagging as breaking.
-        reads:
-          - "git diff"
-          - "docs/architecture.md"
-        blocked_by: []
-
-  - name: doc-reviewer
-    compose:
-      process: doc-writer
-      technical: null
-      cognitive: user-empathetic
-    tasks:
-      - id: doc-review
-        name: "Documentation Status"
-        output: docs/releases/{version}-readiness.md (documentation section)
-        description: >
-          Check if documentation is up to date with the changes in this release.
-          Compare changed source files with their corresponding documentation.
-          Flag any docs that need updating before release.
-        reads:
-          - "git log"
-          - "docs/"
-          - "README.md"
-        blocked_by: []
-
-coordination: []  # all reviewers work in parallel
-
-review_gate:
-  checklist: null  # release reviews produce a report, not a gate
-  mode: auto

package/framework/teams/security.yaml

@@ -1,59 +0,0 @@
-# ─────────────────────────────────────────
-# SNIPER Security Audit Team
-# Structured security analysis
-# ─────────────────────────────────────────
-
-# Phase 1 (Analysis) spawns 2 agents in parallel:
-#   - threat-modeler: maps attack surface and models threats via STRIDE
-#   - vuln-scanner: finds application-level vulnerabilities via code analysis
-#
-# Phase 2 (Planning) is run by the lead to generate remediation stories.
-# Phase 3 (Execution) uses the standard sprint infrastructure.
-#
-# This team YAML is used by /sniper-audit --target security.
-
-team_name: sniper-security-audit-{audit_id}
-description: "Security Audit: {audit_title}"
-model_override: null
-
-teammates:
-  - name: threat-modeler
-    compose:
-      process: threat-modeler
-      technical: security
-      cognitive: systems-thinker
-    tasks:
-      - id: threat-modeling
-        name: "Threat Modeling"
-        description: >
-          Map the application's attack surface using STRIDE methodology. Identify
-          trust boundaries, data flows, and potential threat vectors. Produce a
-          structured threat model with risk ratings and recommended mitigations.
-        output: threat-model.md
-        blocked_by: []
-        plan_approval: false
-
-  - name: vuln-scanner
-    compose:
-      process: vuln-scanner
-      technical: security
-      cognitive: devils-advocate
-    tasks:
-      - id: vulnerability-scanning
-        name: "Vulnerability Scanning"
-        description: >
-          Perform application-level vulnerability analysis via code review.
-          Check for OWASP Top 10 issues, insecure dependencies, hardcoded
-          secrets, and missing security controls. Produce a vulnerability
-          report with severity ratings and remediation guidance.
-        output: vulnerability-report.md
-        blocked_by: []
-        plan_approval: false
-
-# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
-
-coordination: []
-
-review_gate:
-  checklist: .sniper/checklists/security-review.md
-  mode: flexible

package/framework/teams/solve.yaml

@@ -1,48 +0,0 @@
-team_name: null
-phase: solve
-
-agent:
-  compose:
-    process: scrum-master
-    technical: null
-    cognitive: systems-thinker
-    domain: null
-  reads:
-    - "docs/prd.md"
-    - "docs/architecture.md"
-    - "docs/ux-spec.md"
-    - "docs/security.md"
-
-  tasks:
-    - id: epic-sharding
-      name: "Epic Sharding"
-      output: "docs/epics/"
-      template: ".sniper/templates/epic.md"
-      description: >
-        Break the PRD into 6-12 epics. Each epic file must include:
-        - Scope and clear boundaries (what's in, what's out)
-        - Relevant sections from architecture doc (EMBEDDED, not just referenced)
-        - Dependencies on other epics
-        - Acceptance criteria for the epic as a whole
-        - Estimated total story points
-
-    - id: story-creation
-      name: "Story Creation"
-      output: "docs/stories/"
-      template: ".sniper/templates/story.md"
-      blocked_by: [epic-sharding]
-      description: >
-        For each epic, create 3-8 stories. Each story file must include:
-        - Full context from PRD + Architecture (EMBEDDED in the story file)
-        - Acceptance criteria as testable assertions
-        - Test requirements (unit, integration, e2e as applicable)
-        - File ownership (which directories this story's implementation touches)
-        - Dependencies on other stories
-        - Complexity estimate (S/M/L/XL)
-
-        CRITICAL: Stories must be self-contained. A teammate reading ONLY the story
-        file must have enough context to implement it without reading any other docs.
-
-review_gate:
-  checklist: ".sniper/checklists/story-review.md"
-  mode: flexible

package/framework/teams/sprint.yaml

@@ -1,68 +0,0 @@
-team_name: "sniper-sprint-{number}"
-phase: sprint
-
-available_teammates:
-  - name: backend-dev
-    compose:
-      process: developer
-      technical: backend
-      cognitive: systems-thinker
-      domain: null
-    owns_from_config: backend
-    model: sonnet
-
-  - name: frontend-dev
-    compose:
-      process: developer
-      technical: frontend
-      cognitive: user-empathetic
-      domain: null
-    owns_from_config: frontend
-    model: sonnet
-
-  - name: infra-dev
-    compose:
-      process: developer
-      technical: infrastructure
-      cognitive: systems-thinker
-      domain: null
-    owns_from_config: infrastructure
-    model: sonnet
-
-  - name: ai-dev
-    compose:
-      process: developer
-      technical: ai-ml
-      cognitive: performance-focused
-      domain: null
-    owns_from_config: ai
-    model: opus
-
-  - name: qa-engineer
-    compose:
-      process: qa-engineer
-      technical: backend
-      cognitive: devils-advocate
-      domain: null
-    owns_from_config: tests
-    model: sonnet
-
-sprint_rules:
-  - "Each teammate reads their assigned story file(s) COMPLETELY before writing any code"
-  - "Backend and frontend must agree on API contracts via inter-agent messaging BEFORE implementing"
-  - "All new code must include tests — no story is complete without passing tests"
-  - "QA engineer is blocked until implementation stories are complete"
-  - "Every teammate messages the team lead when their task is complete"
-  - "If any teammate is blocked for > 10 minutes, message the lead immediately"
-
-coordination:
-  - between: [backend-dev, frontend-dev]
-    topic: "API contracts — agree on endpoints, payloads, and auth before coding"
-  - between: [backend-dev, ai-dev]
-    topic: "AI pipeline integration points — data flow, WebSocket events, API boundaries"
-  - between: [backend-dev, qa-engineer]
-    topic: "Share testable endpoints as they're completed"
-
-review_gate:
-  checklist: ".sniper/checklists/sprint-review.md"
-  mode: strict