@sniper.ai/core 3.4.0 → 4.1.0

package/README.md

@@ -9,7 +9,7 @@ Framework core for [SNIPER](https://sniperai.dev) -- provides agents, personas,
 
 SNIPER is an AI-powered project lifecycle framework for orchestrating Claude Code agent teams through structured phases. It takes projects from discovery through implementation using parallel agent teams, review gates, and domain-specific knowledge packs.
 
-A full lifecycle runs through: **Discover** (research and analysis), **Define** (PRD and requirements), **Design** (architecture), **Solve** (story sharding), **Implement** (code with worktree isolation), **Review** (multi-faceted code review), and **Retro** (learnings and velocity). Each phase spawns specialized agents defined by protocol state machines.
+A full lifecycle runs through: **Discover** (research and analysis), **Define** (PRD and requirements), **Design** (architecture), **Solve** (story sharding), **Implement** (code with worktree isolation), **Review** (multi-faceted code review), and **Retro** (learnings and memory). Each phase spawns specialized agents defined by protocol state machines.
 
 ## Overview
 
@@ -24,13 +24,13 @@ npm install @sniper.ai/core
 ## Contents
 
 ```
-├── agents/             # Agent definitions (11 agents)
+├── agents/             # Agent definitions (13 agents)
 ├── personas/
 │   └── cognitive/      # Cognitive mixins (3 mixins)
-├── skills/             # Slash command definitions (4 skills)
+├── skills/             # Slash command definitions (5 skills)
 ├── protocols/          # Protocol state machines (7 protocols)
-├── templates/          # Artifact templates (14 templates)
-├── checklists/         # Quality gate checklists (9 checklists)
+├── templates/          # Artifact templates (15 templates)
+├── checklists/         # Quality gate checklists (13 checklists)
 ├── hooks/              # Claude Code hook definitions (2 files)
 ├── schemas/            # Runtime data schemas (13 schemas)
 ├── config.template.yaml
@@ -39,7 +39,7 @@ npm install @sniper.ai/core
 
 ## Agents
 
-11 agent definitions, each with YAML frontmatter specifying write scope or isolation mode:
+13 agent definitions, each with YAML frontmatter specifying write scope or isolation mode:
 
 | Agent | Description |
 |-------|-------------|
@@ -53,7 +53,9 @@ npm install @sniper.ai/core
 | `qa-engineer` | Writes tests, analyzes coverage, validates acceptance criteria |
 | `code-reviewer` | Multi-faceted code review (scope, standards, risk scoring) |
 | `gate-reviewer` | Runs automated checks at phase boundaries |
-| `retro-analyst` | Post-protocol retrospectives and velocity tracking |
+| `retro-analyst` | Post-protocol retrospectives and learning capture |
+| `doc-writer` | Incrementally updates project documentation after implementation |
+| `memory-curator` | Curates and maintains project memory (conventions, anti-patterns, decisions) |
 
 ## Cognitive Mixins
 
@@ -83,14 +85,15 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
 
 ## Skills
 
-4 slash commands available in Claude Code:
+5 slash commands available in Claude Code:
 
 | Command | Description |
 |---------|-------------|
 | `/sniper-flow` | Execute a SNIPER protocol (auto-detects scope or use `--protocol <name>`) |
 | `/sniper-init` | Initialize SNIPER v3 in a new or existing project |
+| `/sniper-learn` | Submit, review, or deprecate project learnings |
 | `/sniper-review` | Manually trigger a review gate for the current phase |
-| `/sniper-status` | Show current protocol progress and cost |
+| `/sniper-status` | Show current protocol progress |
 
 ## Templates
 
@@ -109,14 +112,12 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
 | `workspace-config.yaml` | YAML | Workspace configuration |
 | `knowledge-manifest.yaml` | YAML | Knowledge base manifest |
 | `checkpoint.yaml` | YAML | Protocol checkpoint state |
-| `cost.yaml` | YAML | Token cost tracking |
 | `live-status.yaml` | YAML | Live protocol status |
-| `velocity.yaml` | YAML | Velocity calibration data |
-| `signal-record.yaml` | YAML | Signal event record |
+| `signal-record.yaml` | YAML | Signal event record (deprecated) |
 
 ## Checklists
 
-11 quality gate checklists:
+13 quality gate checklists:
 
 | Checklist | Used by |
 |-----------|---------|
@@ -124,9 +125,10 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
 | `define` | full, feature protocols |
 | `design` | full, feature protocols |
 | `solve` | full, feature protocols |
-| `plan` | (deprecated — use define + design) |
 | `implement` | full, feature, patch, refactor, hotfix protocols |
 | `review` | full, feature, patch, refactor protocols |
+| `retro` | full, feature, refactor protocols |
+| `plan` | (deprecated — use define + design + solve) |
 | `multi-faceted-review` | Multi-model review mode |
 | `ingest-scan` | ingest protocol (scan phase) |
 | `ingest-document` | ingest protocol (document phase) |

package/agents/analyst.md

@@ -25,6 +25,12 @@ You are a SNIPER analyst agent. You research, analyze, and produce discovery art
 - Ground every finding in evidence — cite file paths, line numbers, or URLs
 - Distinguish facts from assumptions explicitly
 - Flag unknowns as open questions rather than guessing
-- Respect token budgets annotated in templates
 - Do NOT make architectural decisions — surface options with tradeoffs for the architect
 - The discovery brief is research output, not a specification — frame it as findings and constraints, not design
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects discovery output, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Scope of competitive analysis (direct competitors only vs. adjacent markets)
+- Depth of codebase analysis (surface scan vs. deep audit)
+- Conflicting stakeholder signals requiring prioritization

package/agents/architect.md

@@ -17,7 +17,7 @@ You are a SNIPER architect agent. You design system architecture and produce tec
 
 ## Output Artifacts
 
-- `.sniper/artifacts/{protocol_id}/plan.md` — Architecture plan for this protocol run (use `architecture.md` template, 4000 token budget)
+- `.sniper/artifacts/{protocol_id}/plan.md` — Architecture plan for this protocol run (use `architecture.md` template)
   - The `{protocol_id}` (e.g., `SNPR-20260307-a3f2`) is provided by the orchestrator when spawning you
   - This is a per-run snapshot; the master `docs/architecture.md` is updated separately by the doc-writer
 
@@ -39,3 +39,11 @@ You are a SNIPER architect agent. You design system architecture and produce tec
 - Do NOT implement — produce designs only
 - Do NOT add requirements — design against the approved PRD, nothing more
 - Flag any requirement that cannot be met within the current stack
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the architecture, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Multiple viable patterns exist for a component (e.g., event-driven vs. request-response)
+- Technology choice not specified in the PRD or config
+- Trade-off between simplicity and extensibility
+- Integration approach with external systems

package/agents/backend-dev.md

@@ -41,3 +41,10 @@ Before marking a task complete, verify:
 - Do NOT modify frontend code, infrastructure, or CI/CD files
 - Do NOT merge your own worktree — the orchestrator handles merges
 - Do NOT push to remote or create pull requests — the orchestrator handles integration
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the implementation, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Existing API doesn't support what the story requires (extend vs. new endpoint)
+- Database schema design with multiple valid approaches
+- Story acceptance criteria conflict with existing code patterns

package/agents/code-reviewer.md

@@ -71,3 +71,10 @@ After completing the code review, reconcile the PRD with the implementation:
 - Do NOT nitpick style when conventions aren't established
 - Write the review report to `.sniper/artifacts/{protocol_id}/review-report.md` (the `{protocol_id}` is provided by the orchestrator)
 - Only modify `.sniper/artifacts/{protocol_id}/prd.md` during spec reconciliation — never modify project source code or the discovery brief
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the review outcome, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Code works but violates a convention — block or allow with a note?
+- Implementation deviates from spec intentionally — accept the deviation or require a rewrite?
+- Risk finding is borderline between severity levels

package/agents/frontend-dev.md

@@ -41,3 +41,10 @@ Before marking a task complete, verify:
 - Do NOT modify backend code, database schemas, or infrastructure files
 - Do NOT merge your own worktree — the orchestrator handles merges
 - Do NOT push to remote or create pull requests — the orchestrator handles integration
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the implementation, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Component architecture choices (single component vs. compound pattern)
+- State management approach not specified in the architecture doc
+- UX/accessibility trade-offs not covered by the spec

package/agents/fullstack-dev.md

@@ -42,3 +42,11 @@ Before marking a task complete, verify:
 - Do NOT modify infrastructure, CI/CD, or deployment files
 - Do NOT merge your own worktree — the orchestrator handles merges
 - Do NOT push to remote or create pull requests — the orchestrator handles integration
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the implementation, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Existing API doesn't support what the story requires (extend vs. new endpoint)
+- Multiple valid approaches to implement a feature
+- Story acceptance criteria conflict with existing code patterns
+- Dependency choice not specified in the architecture doc

package/agents/lead-orchestrator.md

@@ -49,3 +49,12 @@ When a workspace is detected (`.sniper-workspace/` exists in a parent directory)
 - Spawn agents with `mode: "plan"` when the protocol specifies `plan_approval: true`
 - Prefer TaskCreate + Task tool over direct SendMessage for work assignments
 - When a gate fails, DO NOT advance — reassign failed checks to appropriate agents
+
+## Structured Decision Prompts
+
+Agents may present Structured Decision Prompts (SDPs) to the user during execution. When this happens:
+
+1. **Do NOT treat an SDP pause as a stall or failure** — the agent is waiting for user input
+2. **Pass decisions forward** — when spawning agents, include the current decisions log (`.sniper/artifacts/{protocol_id}/decisions.yaml`) so agents don't re-ask settled questions
+3. **Include in interactive review** — when presenting phase summaries during interactive review, list all decisions made during the phase so the user has full visibility
+4. **Initialize the decisions log** — during protocol initialization, create `.sniper/artifacts/{protocol_id}/decisions.yaml` from the decisions template

package/agents/product-manager.md

@@ -41,7 +41,7 @@ Use the EARS (Easy Approach to Requirements Syntax) patterns:
 ## Output Artifacts
 
 - `.sniper/artifacts/{protocol_id}/prd.md` — Product requirements for this protocol run (use `prd.md` template)
-- `.sniper/artifacts/{protocol_id}/stories/*.md` — Individual stories (use `story.md` template, 1500 token budget each)
+- `.sniper/artifacts/{protocol_id}/stories/*.md` — Individual stories (use `story.md` template)
   - The `{protocol_id}` (e.g., `SNPR-20260307-a3f2`) is provided by the orchestrator when spawning you
   - These are per-run snapshots that preserve the plan history
 
@@ -52,3 +52,11 @@ Use the EARS (Easy Approach to Requirements Syntax) patterns:
 - Stories must reference the architecture document for technical context
 - Do NOT include implementation details — describe WHAT, not HOW
 - Flag any requirement without a clear acceptance test
+
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects requirements or story decomposition, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- User story has multiple valid interpretations
+- Feature scope is ambiguous (include edge case X or defer it?)
+- Story granularity trade-offs (one large story vs. several small ones)
+- Priority conflicts between competing requirements

package/agents/retro-analyst.md

@@ -11,10 +11,9 @@ You are a SNIPER retro analyst agent. You run automated retrospectives after pro
 
 1. **Protocol Analysis** — Review what happened during the completed protocol execution
 2. **Pattern Extraction** — Identify what worked well and what didn't
-3. **Metric Collection** — Gather token usage, duration, agent count, and gate results
+3. **Metric Collection** — Gather duration, agent count, and gate results
 4. **Recommendation Generation** — Suggest concrete improvements for next time
 5. **Retro Report** — Write structured retro to `.sniper/retros/`
-6. **Velocity Tracking** — Record execution metrics to `.sniper/memory/velocity.yaml` for budget calibration
 
 ## Invocation
 
@@ -25,9 +24,9 @@ The orchestrator provides you with the `protocol_id` (e.g., `SNPR-20260307-a3f2`
 
 1. Read `.sniper/checkpoints/{protocol_id}-*` for the completed protocol's checkpoint history
 2. Read `.sniper/gates/` for gate results (pass/fail patterns)
-3. Read `.sniper/cost.yaml` for token usage data
-4. Read `.sniper/artifacts/{protocol_id}/meta.yaml` for protocol metadata
-5. Analyze: What took the most tokens? Which gates failed first? Were there re-runs?
+3. Read `.sniper/artifacts/{protocol_id}/meta.yaml` for protocol metadata
+4. Read `.sniper/artifacts/{protocol_id}/decisions.yaml` for Structured Decision Prompt outcomes
+5. Analyze: Which gates failed first? Were there re-runs? Were recommendations overridden?
 6. Write retro report to `.sniper/retros/{protocol_id}.yaml`
 
 ## Retro Report Schema
@@ -41,7 +40,6 @@ duration_phases:
     gate_attempts: <count>
     gate_result: pass | fail
 metrics:
-  total_tokens: <number>
   total_agents_spawned: <number>
   gate_pass_rate: <percentage>
 findings:
@@ -58,7 +56,7 @@ findings:
 - Be specific — cite actual data, not vague observations
 - Focus on actionable improvements, not blame
 - Write to `.sniper/retros/` only — never modify project code
-- Keep the report concise — under 1000 tokens
+- Keep the report concise
 - Compare against previous retros if they exist to track trends
 
 ## Learning Extraction
@@ -110,6 +108,33 @@ After extracting new learnings, check effectiveness of previously applied learni
    Flag for human review by adding to findings.
 5. If confidence drops below 0.2 after adjustment, set `status: deprecated`.
 
+## Structured Decision Prompts
+
+When you encounter ambiguity or a fork that materially affects the retrospective, present a Structured Decision Prompt per the `structured-decisions` cognitive mixin. Common triggers:
+- Contradictory signals about whether a pattern is beneficial or harmful
+- Ambiguous gate failures that could be attributed to multiple root causes
+- Uncertainty about whether to create a learning from a borderline finding
+
+## Decision Analysis
+
+During the retrospective, analyze Structured Decision Prompt outcomes:
+
+1. Read `.sniper/artifacts/{protocol_id}/decisions.yaml`
+2. Count total decisions, recommendation acceptance rate, and escape hatch usage
+3. For decisions where the user overrode the recommendation:
+   - Check if the non-recommended choice led to downstream issues (gate failures, rework)
+   - If the override was successful, create a learning capturing the user's preference pattern (`confidence: 0.85`, `source.type: human`)
+   - If the override led to issues, note it as a `needs_improvement` finding
+4. Include decision summary in the retro report:
+   ```yaml
+   decisions_analyzed:
+     total: <count>
+     recommendation_accepted: <count>
+     recommendation_overridden: <count>
+     escape_hatch_used: <count>
+     override_success_rate: <percentage>
+   ```
+
 ## Signal Analysis
 
 During the retrospective, analyze external signals from both legacy and new stores:
@@ -132,25 +157,3 @@ During the retrospective, analyze external signals from both legacy and new stor
        recurrence: <count>
    ```
 
-## Velocity Tracking
-
-After writing the retro report, update velocity data:
-
-1. Read `.sniper/memory/velocity.yaml` (create if it doesn't exist)
-2. Append a new execution record:
-   ```yaml
-   - protocol: <protocol_name>
-     completed_at: <ISO 8601>
-     wall_clock_seconds: <duration>
-     tokens_used: <total_tokens>
-     tokens_per_phase:
-       <phase_name>: <tokens>
-   ```
-3. After 5+ executions of the same protocol, compute `calibrated_budgets`:
-   - Collect all `tokens_used` values for that protocol
-   - Calculate the p75 (75th percentile) value
-   - Set `calibrated_budgets.<protocol>` to that value
-4. Update `rolling_averages.<protocol>` with exponential moving average:
-   - Formula: `new_avg = 0.3 * latest_tokens + 0.7 * previous_avg`
-   - If no previous average, use the latest value
-5. Write updated velocity data back to `.sniper/memory/velocity.yaml`

package/checklists/define.yaml

@@ -21,8 +21,3 @@ checks:
     description: PRD explicitly defines what is out of scope
     check: grep:.sniper/artifacts/{protocol_id}/prd.md:"## Out of Scope"
     blocking: true  # Out of scope must be explicit — this is where scope creep dies
-
-  - id: token_budget
-    description: PRD is concise (under 12000 chars)
-    check: wc:.sniper/artifacts/{protocol_id}/prd.md:<12000
-    blocking: false

package/checklists/design.yaml

@@ -36,8 +36,3 @@ checks:
     description: No unresolved open questions remain
     check: "!grep:.sniper/artifacts/{protocol_id}/plan.md:\\*\\*TBD\\*\\*|\\*\\*TODO\\*\\*|\\*\\*OPEN\\*\\*"
     blocking: false
-
-  - id: token_budget
-    description: Architecture plan within character budget (~4000 tokens = 16000 chars)
-    check: wc:.sniper/artifacts/{protocol_id}/plan.md:<16000
-    blocking: false

package/checklists/plan.yaml

@@ -26,8 +26,3 @@ checks:
     description: No unresolved open questions remain
     check: "!grep:.sniper/artifacts/{protocol_id}/plan.md:\\*\\*TBD\\*\\*|\\*\\*TODO\\*\\*|\\*\\*OPEN\\*\\*"
     blocking: false
-
-  - id: token_budget
-    description: Architecture plan within character budget (~4000 tokens = 16000 chars)
-    check: wc:.sniper/artifacts/{protocol_id}/plan.md:<16000
-    blocking: false

package/checklists/retro.yaml

@@ -7,9 +7,3 @@ checks:
     type: file_exists
     path: ".sniper/retros/{protocol_id}.yaml"
     blocking: true
-
-  - id: velocity_updated
-    description: Velocity data updated
-    type: file_exists
-    path: ".sniper/memory/velocity.yaml"
-    blocking: true

package/config.template.yaml

@@ -44,16 +44,6 @@ routing:
   # Default protocol when auto-detect is ambiguous
   default: feature
 
-  # Protocol token budgets (override protocol defaults)
-  budgets:
-    full: 2000000
-    feature: 800000
-    patch: 200000
-    ingest: 1000000
-    explore: 500000
-    refactor: 600000
-    hotfix: 100000
-
 # Trigger tables — map file patterns to agents or protocols
 # Example:
 #   - pattern: "src/api/**"
@@ -64,12 +54,6 @@ routing:
 #     protocol: full
 triggers: []
 
-# Cost enforcement
-cost:
-  warn_threshold: 0.7       # Warn at 70% of budget
-  soft_cap: 0.9              # Soft cap at 90% — agents must justify continuing
-  hard_cap: 1.0              # Hard cap at 100% — stop execution
-
 # Review configuration
 review:
   multi_model: false           # Enable multi-model review for gate checks
@@ -161,5 +145,4 @@ learning:
 visibility:
   live_status: true          # Maintain .sniper/live-status.yaml
   checkpoints: true          # Write phase checkpoints
-  cost_tracking: true        # Track token usage
   # auto_retro: true         # DEPRECATED — use retro phase in protocols instead

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sniper.ai/core",
-  "version": "3.4.0",
+  "version": "4.1.0",
   "description": "SNIPER framework core — agents, skills, protocols, checklists, templates, and hooks",
   "type": "module",
   "exports": {

package/personas/cognitive/structured-decisions.md

@@ -0,0 +1,41 @@
+# Structured Decision Prompts
+
+When you encounter a question, ambiguity, or fork where the user's intent is unclear and the decision materially affects the outcome, surface it as a **Structured Decision Prompt (SDP)** instead of silently assuming or dumping free-form text.
+
+## Format
+
+Present decisions exactly like this:
+
+```markdown
+Decision needed: {title}
+
+{1-3 sentences of context — what you're working on, what triggered the question}
+
+1. {Option label} — {1-2 sentence description with trade-offs}
+2. {Option label} — {1-2 sentence description with trade-offs}
+...
+★ Recommended: Option {N} — {rationale}
+
+{N+1}. Custom response / discuss further
+```
+
+Then **stop and wait** for the user to select an option before continuing.
+
+## After Resolution
+
+Record the decision in `.sniper/artifacts/{protocol_id}/decisions.yaml` (append to the `decisions` array). Downstream agents read this file to avoid re-asking settled questions.
+
+## When NOT to Use SDPs
+
+- **Trivial decisions** with obvious answers — use your judgment and move on
+- **Already answered** by project conventions, CLAUDE.md, learnings, PRD, architecture doc, or a prior decision in `decisions.yaml`
+- **Implementation details** that don't affect the user-facing outcome
+- **Style preferences** already codified in linter config or conventions
+
+## Guidelines
+
+- **2-4 options** plus the escape hatch. More than 5 causes decision fatigue.
+- **Always recommend.** The user hired you for your judgment — give it.
+- **Be concrete.** "Use Redis for caching" not "Consider a caching layer."
+- **Include trade-offs** in each option so the user can make an informed choice.
+- **Batch related decisions** if multiple arise close together — present them in a single prompt rather than interrupting repeatedly.

package/protocols/explore.yaml

@@ -1,6 +1,5 @@
 name: explore
 description: Exploratory analysis — understand a codebase or problem space
-budget: 500000  # 500K tokens
 
 phases:
   - name: discover

package/protocols/feature.yaml

@@ -1,6 +1,5 @@
 name: feature
 description: Incremental feature — define, design, solve, implement, review, retro
-budget: 800000  # 800K tokens
 
 phases:
   - name: define
@@ -75,5 +74,4 @@ phases:
       human_approval: false
     outputs:
       - .sniper/retros/{protocol_id}.yaml
-      - .sniper/memory/velocity.yaml
       - .sniper/memory/learnings/

package/protocols/full.yaml

@@ -1,6 +1,5 @@
 name: full
 description: Complete project lifecycle — discovery through review
-budget: 2000000  # 2M tokens
 
 phases:
   - name: discover
@@ -91,7 +90,6 @@ phases:
       human_approval: false
     outputs:
       - .sniper/retros/{protocol_id}.yaml
-      - .sniper/memory/velocity.yaml
       - .sniper/memory/learnings/
 
   - name: curate

package/protocols/hotfix.yaml

@@ -1,6 +1,5 @@
 name: hotfix
 description: Critical fix — fastest path to production
-budget: 100000  # 100K tokens
 
 phases:
   - name: implement

package/protocols/ingest.yaml

@@ -1,6 +1,5 @@
 name: ingest
 description: Codebase ingestion — scan, document, extract conventions
-budget: 1000000  # 1M tokens
 
 phases:
   - name: scan

package/protocols/patch.yaml

@@ -1,6 +1,5 @@
 name: patch
 description: Quick fix — implement and review only
-budget: 200000  # 200K tokens
 
 phases:
   - name: implement

package/protocols/refactor.yaml

@@ -1,6 +1,5 @@
 name: refactor
 description: Code improvement — analyze, refactor, and review
-budget: 600000  # 600K tokens
 
 phases:
   - name: analyze
@@ -50,5 +49,4 @@ phases:
       human_approval: false
     outputs:
       - .sniper/retros/{protocol_id}.yaml
-      - .sniper/memory/velocity.yaml
       - .sniper/memory/learnings/

package/schemas/checkpoint.schema.yaml

@@ -92,22 +92,6 @@ properties:
             - draft
             - complete
           description: Whether the artifact is a draft or complete.
-  token_usage:
-    type: object
-    description: Token consumption metrics for this phase.
-    properties:
-      phase_tokens:
-        type: integer
-        minimum: 0
-        description: Tokens consumed during this phase.
-      cumulative_tokens:
-        type: integer
-        minimum: 0
-        description: Total tokens consumed across all phases up to and including this one.
-      budget_remaining:
-        type: number
-        minimum: 0
-        description: Remaining token budget.
   commits:
     type: array
     description: Git commits made during this phase, used for logical revert.

package/schemas/decision-prompt.schema.yaml

@@ -0,0 +1,86 @@
+$schema: "https://json-schema.org/draft/2020-12/schema"
+$id: "https://sniper.ai/schemas/decision-prompt"
+title: Decision Prompt
+description: Schema for Structured Decision Prompts (SDPs) — the format agents use to present questions, ambiguities, and decision points to the user with concrete options and a recommendation.
+type: object
+required:
+  - id
+  - phase
+  - agent
+  - context
+  - options
+  - recommendation
+properties:
+  id:
+    type: string
+    pattern: "^D-[a-z]+-\\d{3}$"
+    description: "Unique decision ID in format D-{phase}-{seq} (e.g., D-design-001)."
+  phase:
+    type: string
+    description: Protocol phase where the decision arose.
+  agent:
+    type: string
+    description: Agent requesting the decision.
+  context:
+    type: string
+    description: "1-3 sentences explaining what the agent is working on and what triggered the question."
+  options:
+    type: array
+    minItems: 2
+    maxItems: 4
+    items:
+      type: object
+      required:
+        - label
+        - description
+      properties:
+        label:
+          type: string
+          description: Short option name (e.g., "JWT with refresh tokens").
+        description:
+          type: string
+          description: "1-2 sentence explanation including trade-offs."
+      additionalProperties: false
+  recommendation:
+    type: object
+    required:
+      - option_index
+      - rationale
+    properties:
+      option_index:
+        type: integer
+        minimum: 0
+        description: 0-based index into the options array.
+      rationale:
+        type: string
+        description: Why this option is recommended given the project context.
+    additionalProperties: false
+  escape_hatch:
+    type: string
+    default: "Custom response / discuss further"
+    description: Label for the free-form input option (always rendered as the last numbered choice).
+
+  # Resolution (filled after user responds)
+  resolution:
+    type: object
+    properties:
+      selected_option:
+        type: [integer, "null"]
+        description: "0-based index of the selected option, or null if escape hatch was used."
+      selected_label:
+        type: string
+        description: "Label of the selected option (copied from options array for readability). Null if escape hatch."
+      options_snapshot:
+        type: array
+        items:
+          type: string
+        description: "Labels of all options at the time of resolution, for audit trail readability."
+      custom_response:
+        type: string
+        description: "Free-form text if the user chose the escape hatch. Null otherwise."
+      timestamp:
+        type: string
+        format: date-time
+        description: When the decision was resolved.
+    additionalProperties: false
+additionalProperties: false

package/schemas/live-status.schema.yaml

@@ -126,23 +126,6 @@ properties:
           type: string
           format: date-time
           description: ISO 8601 timestamp of when the gate review completed.
-  cost:
-    type: object
-    description: Current cost snapshot.
-    properties:
-      tokens_used:
-        type: integer
-        minimum: 0
-        description: Total tokens consumed so far.
-      budget:
-        type: number
-        minimum: 0
-        description: Total token budget.
-      percent:
-        type: number
-        minimum: 0
-        maximum: 100
-        description: Percentage of budget consumed.
   next_action:
     type: string
     description: Description of the next expected action or step.

package/schemas/protocol.schema.yaml

@@ -6,7 +6,6 @@ type: object
 required:
   - name
   - description
-  - budget
   - phases
 properties:
   name:
@@ -15,10 +14,6 @@ properties:
   description:
     type: string
     description: Human-readable description of the protocol's purpose.
-  budget:
-    type: integer
-    minimum: 1
-    description: Maximum token budget for the entire protocol execution.
   phases:
     type: array
     minItems: 1

package/schemas/retro.schema.yaml

@@ -82,18 +82,4 @@ properties:
         type: array
         items: { type: string }
         description: IDs of learnings created from this retro's findings.
-  velocity:
-    type: object
-    description: Velocity metrics for this execution, used for budget calibration.
-    properties:
-      wall_clock_seconds:
-        type: number
-        minimum: 0
-        description: Total wall clock time for the protocol execution in seconds.
-      tokens_per_phase:
-        type: object
-        description: Token usage broken down by phase name.
-        additionalProperties:
-          type: integer
-          minimum: 0
 additionalProperties: false

package/skills/sniper-flow/SKILL.md

@@ -46,8 +46,9 @@ After auto-detection, check trigger tables: run `git diff --name-only` and match
 
 1. **Generate protocol ID:** `SNPR-YYYYMMDD-XXXX` where XXXX is a random 4-char hex suffix (e.g., `SNPR-20260307-a3f2`). No registry parsing needed.
 2. **Create artifact directory:** `mkdir -p .sniper/artifacts/{protocol_id}/`
-3. **Write metadata:** Create `.sniper/artifacts/{protocol_id}/meta.yaml` with id, protocol, description, status: in_progress, started timestamp.
-4. **Append to registry:** Add a row to `.sniper/artifacts/registry.md`. If registry doesn't exist, create it with a header row first.
+3. **Initialize decisions log:** Copy `decisions.yaml` template to `.sniper/artifacts/{protocol_id}/decisions.yaml`
+4. **Write metadata:** Create `.sniper/artifacts/{protocol_id}/meta.yaml` with id, protocol, description, status: in_progress, started timestamp.
+5. **Append to registry:** Add a row to `.sniper/artifacts/registry.md`. If registry doesn't exist, create it with a header row first.
 
 ## 3. Phase Execution Loop
 
@@ -57,8 +58,7 @@ For each phase in the protocol, execute these 5 steps:
 
 1. Read protocol YAML for the current phase definition
 2. Read `.sniper/config.yaml` for agent config, ownership, commands
-3. Check `.sniper/memory/velocity.yaml` for calibrated budget — use it if available, otherwise use configured budget. Log which source is used.
-4. Compose agents per [Reference: Agent Composition](#reference-agent-composition)
+3. Compose agents per [Reference: Agent Composition](#reference-agent-composition)
 
 ### Execute
 
@@ -79,11 +79,10 @@ phase: <phase>
 timestamp: <ISO 8601>
 status: completed | failed
 agents: [status per agent]
-token_usage: [phase + cumulative]
 commits: [git SHAs produced]
 ```
 
-Update `.sniper/live-status.yaml` with current phase, agent statuses, and cost percentage.
+Update `.sniper/live-status.yaml` with current phase and agent statuses.
 
 After the `solve` phase completes, populate the `stories` array in `.sniper/live-status.yaml` by reading story files from `.sniper/artifacts/{protocol_id}/stories/`. During `implement`, update each story's status (`in_progress` → `completed`) as agents finish work on it.
 
@@ -107,25 +106,15 @@ After the `solve` phase completes, populate the `stories` array in `.sniper/live
 
 1. Write final checkpoint
 2. Update `.sniper/live-status.yaml` with `status: completed`
-3. Update `.sniper/artifacts/{protocol_id}/meta.yaml` with final status, token usage, commits, agents used
+3. Update `.sniper/artifacts/{protocol_id}/meta.yaml` with final status, commits, agents used
 4. Update `.sniper/artifacts/registry.md` entry from `in_progress` to `completed`
-5. Present summary: phases completed, gate results, token usage, learnings created
+5. Present summary: phases completed, gate results, learnings created
 6. **Backward compatibility:** If the protocol has `auto_retro: true` but no `retro` phase in its phases list (custom protocols), spawn retro-analyst as a single-agent phase before completing
 
-## Cost Tracking
-
-Maintain `.sniper/cost.yaml` throughout execution. At each checkpoint:
-- `warn_threshold` → log warning, continue
-- `soft_cap` → pause, ask user whether to continue
-- `hard_cap` → checkpoint and stop gracefully
-
-Read thresholds from `.sniper/config.yaml` cost section.
-
 ## Rules
 
 - ALWAYS generate a protocol ID and create `.sniper/artifacts/{protocol_id}/` before spawning any agent
 - ALWAYS checkpoint between phases
-- ALWAYS respect token budgets
 - ALWAYS present the plan for interactive review when `interactive_review: true`
 - NEVER skip a gate — every phase transition goes through its gate
 - NEVER advance past a failed blocking gate check
@@ -145,6 +134,7 @@ For each agent in the phase, build the full prompt by layering these sources. Ea
 | 3. Domain knowledge | `.sniper/knowledge/manifest.yaml` → referenced files (from agent's `knowledge_sources` frontmatter) | SKIP — no knowledge section |
 | 4. Workspace conventions | `.sniper-workspace/config.yaml` → `shared.conventions` and `shared.anti_patterns` | SKIP — no workspace section |
 | 5. Learnings | `.sniper/memory/learnings/` → scoped, confidence-ranked, top 10 | SKIP — no learnings |
+| 6. Decisions | `.sniper/artifacts/{protocol_id}/decisions.yaml` → prior decisions | SKIP — no decisions yet |
 
 **Learning Composition (Layer 5):**
 
@@ -163,7 +153,7 @@ After composing learnings into the prompt, record the current protocol ID in eac
 
 **Backward compatibility:** If `.sniper/memory/signals/` contains files but `.sniper/memory/learnings/` is empty or doesn't exist, fall back to the old Layer 5 behavior (read signals, top 10 by `affected_files` and `relevance_tags`). Log a warning: "Legacy signals detected. Run `/sniper-learn --review` to migrate."
 
-The composed prompt = base definition + concatenated mixin content + `## Domain Knowledge` section + `## Workspace Conventions` section + `## Anti-Patterns (Workspace)` section + `## Learnings` section (formatted as `- [HIGH] {learning}. Anti-pattern: {anti_pattern}. Instead: {correction}.` or `- [MEDIUM] {learning}.`).
+The composed prompt = base definition + concatenated mixin content + `## Domain Knowledge` section + `## Workspace Conventions` section + `## Anti-Patterns (Workspace)` section + `## Learnings` section (formatted as `- [HIGH] {learning}. Anti-pattern: {anti_pattern}. Instead: {correction}.` or `- [MEDIUM] {learning}.`) + `## Prior Decisions` section (from `decisions.yaml`, so agents don't re-ask settled questions).
 
 Replace all `{protocol_id}` placeholders in the composed prompt with the actual protocol ID.
 
@@ -201,25 +191,60 @@ For agents working in worktrees (after all implementation agents complete):
 When a phase has `interactive_review: true`:
 
 1. Read produced artifacts from `.sniper/artifacts/` or `.sniper/artifacts/{protocol_id}/` as appropriate
-2. Present a structured summary appropriate to the phase:
+2. Read `.sniper/artifacts/{protocol_id}/decisions.yaml` for any Structured Decision Prompts resolved during this phase
+3. Present a structured summary appropriate to the phase:
    - **discover:** findings, constraints, codebase landscape, open questions
    - **define:** requirements, success criteria, scope boundaries, out-of-scope items
    - **design:** key architectural decisions, component overview, data model, trade-offs
    - **solve:** story list, dependencies, acceptance criteria summary
-3. Offer options:
+4. If decisions were made during the phase, include a **Decisions** section listing each decision: the question, the selected option, and the rationale
+5. Offer options:
    - **Approve** — continue to next phase
    - **Request changes** — describe changes (architect/PM will revise, then re-present)
    - **Edit directly** — user modifies plan files, says "done", re-validate via gate
-4. Only advance after explicit user approval
+6. Only advance after explicit user approval
+
+## Reference: Structured Decision Prompts
+
+Agents may present Structured Decision Prompts (SDPs) when they encounter ambiguity or decision points during execution. This is expected behavior, not an error.
+
+**How SDPs work during phase execution:**
+
+1. An agent encounters a question where the user's intent is unclear and the decision materially affects the outcome
+2. The agent presents numbered options with a recommendation and an escape hatch (custom response / discuss further)
+3. The user selects an option by number or types a custom response
+4. The agent records the decision in `.sniper/artifacts/{protocol_id}/decisions.yaml` and continues
+5. At the phase's interactive review, the decisions log is included in the summary
+
+**Decision record format:**
+```yaml
+decisions:
+  - id: D-design-001
+    phase: design
+    agent: architect
+    context: "Authentication strategy for the API"
+    selected_option: 0
+    selected_label: "JWT with refresh tokens"
+    options_snapshot:
+      - "JWT with refresh tokens"
+      - "Session-based auth"
+      - "OAuth2 with external provider"
+    custom_response: null
+    timestamp: 2026-03-11T14:30:00Z
+```
+
+**Downstream context:** When spawning agents, include the current decisions log (Layer 6 in Agent Composition) so agents don't re-ask settled questions.
+
+**Learning from decisions:** When a user picks a non-recommended option or uses the escape hatch, the feedback is a candidate for the learning system. If the choice reveals a preference pattern, create a learning with `source.type: human`, `confidence: 0.85`, scoped to relevant agents and phases.
 
 ## Reference: Retrospective (Legacy)
 
 > **Note:** The retro is now a first-class phase in protocols (full, feature, refactor). This reference is retained for backward compatibility with custom protocols using `auto_retro: true`.
 
 When `auto_retro: true` and no `retro` phase exists in the protocol:
-1. Spawn `retro-analyst` as a single-agent phase with: protocol ID, checkpoint history, gate results, cost data
-2. The retro-analyst writes a report to `.sniper/retros/{protocol_id}.yaml`, extracts learnings to `.sniper/memory/learnings/`, updates `.sniper/memory/velocity.yaml`, and checks effectiveness of previously applied learnings
-3. Run the retro gate checklist (retro report exists + velocity updated)
+1. Spawn `retro-analyst` as a single-agent phase with: protocol ID, checkpoint history, gate results
+2. The retro-analyst writes a report to `.sniper/retros/{protocol_id}.yaml`, extracts learnings to `.sniper/memory/learnings/`, and checks effectiveness of previously applied learnings
+3. Run the retro gate checklist (retro report exists)
 
 ## Reference: Review Gate Feedback Capture
 

package/skills/sniper-init/SKILL.md

@@ -76,7 +76,6 @@ Create the following directory structure:
   memory/
     learnings/             ← Unified learning store (replaces signals/)
     signals/               ← Legacy — kept for backward compat, migrated by memory-curator
-    velocity.yaml
     archive/               ← Deprecated learnings archived here
 .claude/
   agents/                  ← Copied from @sniper.ai/core/agents/

package/skills/sniper-status/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sniper-status
-description: Show current SNIPER protocol progress and cost
+description: Show current SNIPER protocol progress
 arguments: []
 ---
 
@@ -15,7 +15,6 @@ Display the current state of SNIPER in this project.
 Read the following files (skip if they don't exist):
 - `.sniper/config.yaml` — Project configuration
 - `.sniper/live-status.yaml` — Active protocol progress
-- `.sniper/cost.yaml` — Token usage tracking
 
 If `.sniper/config.yaml` doesn't exist, display: "SNIPER is not initialized. Run `/sniper-init` first."
 
@@ -34,21 +33,10 @@ Format and display:
 - Agent status per active phase
 - Gate results for completed phases
 
-**Cost Summary** (if tracking enabled):
-- Tokens used vs budget
-- Budget percentage with visual bar
-- Warning if approaching soft/hard cap
-
 **Recent Activity**:
 - Last 3 checkpoints with timestamps
 - Last gate result
 
-**Velocity Trends** (if velocity data exists):
-- Read `.sniper/memory/velocity.yaml`
-- Show last 5 executions per protocol with tokens used
-- Show calibrated budget vs configured budget comparison
-- Show trend direction: ↑ (increasing usage), ↓ (decreasing usage), → (stable)
-
 ### 3. Format Output
 
 Use clear formatting:
@@ -63,17 +51,9 @@ Phase:    implement [===========-----] 68%
 
 Gates:
   plan:      PASS (2025-01-15)
-
-Cost: 245K / 800K tokens (31%)
-[======--------------] 31%
-
-Velocity:
-  feature: 612K avg (calibrated: 750K, configured: 800K) →
-  patch:   145K avg (calibrated: 180K, configured: 200K) ↓
 ```
 
 ## Rules
 
 - Read-only — this skill never modifies any files
 - If no protocol is active, show config summary only
-- If cost tracking is disabled, skip cost section

package/templates/architecture.md

@@ -1,23 +1,16 @@
 # Architecture
-<!-- Budget: 4000 tokens max -->
 
 ## Context
-<!-- ~400 tokens: Technical context, constraints, existing system landscape -->
 
 ## Decisions
-<!-- ~800 tokens: Key architectural decisions with rationale -->
 <!-- For each decision: Context | Options Considered | Decision | Consequences -->
 
 ## Components
-<!-- ~1000 tokens: Component breakdown with responsibilities -->
 <!-- For each component: Name | Responsibility | Dependencies | Owner -->
 
 ## Data Model
-<!-- ~600 tokens: Core entities and relationships -->
 
 ## API Contracts
-<!-- ~800 tokens: Key API interfaces including error cases -->
 <!-- For each endpoint: Method | Path | Request | Response | Errors -->
 
 ## Infrastructure
-<!-- ~400 tokens: Deployment, scaling, monitoring considerations -->

package/templates/checkpoint.yaml

@@ -19,9 +19,4 @@ artifacts_produced: []
 # - path: .sniper/artifacts/spec.md
 #   status: draft | complete
 
-token_usage:
-  phase_tokens: 0
-  cumulative_tokens: 0
-  budget_remaining: 0
-
 notes: ""

package/templates/custom-protocol.yaml

@@ -13,10 +13,6 @@ name: my-protocol
 # description (required): What this protocol accomplishes.
 description: Describe the goal of your custom protocol
 
-# budget (required): Maximum token budget for the entire execution.
-# Common ranges: 100K (hotfix), 800K (feature), 2M (full lifecycle)
-budget: 500000
-
 # phases (required): Ordered list of phases. Each phase runs sequentially.
 # The protocol engine executes phases top-to-bottom, gating between each.
 phases:
@@ -94,10 +90,10 @@ phases:
       - .sniper/artifacts/{protocol_id}/review-report.md
 
   # ── Phase 4: Retro (recommended) ──────────────────────────
-  # Runs the retro-analyst to extract learnings, update velocity, and check
+  # Runs the retro-analyst to extract learnings and check
   # learning effectiveness. Replaces the old auto_retro flag.
   - name: retro
-    description: Retrospective — extract learnings and update velocity
+    description: Retrospective — extract learnings
     agents:
       - retro-analyst
     spawn_strategy: single
@@ -106,7 +102,6 @@ phases:
       human_approval: false
     outputs:
       - .sniper/retros/{protocol_id}.yaml
-      - .sniper/memory/velocity.yaml
       - .sniper/memory/learnings/
 
   # ── Phase 5: Curate (optional) ────────────────────────────

package/templates/decisions.yaml

@@ -0,0 +1,5 @@
+# Decision log for protocol {protocol_id}
+# Agents append to this file when a Structured Decision Prompt (SDP) is resolved.
+# Downstream agents read this file to understand constraints already established.
+
+decisions: []

package/templates/discovery-brief.md

@@ -1,23 +1,16 @@
 # Discovery Brief
-<!-- Budget: 3000 tokens max -->
 <!-- This is research output, not a specification. Frame as findings and constraints, not design decisions. -->
 
 ## Context
-<!-- ~300 tokens: What exists today, what triggered this investigation -->
 
 ## Findings
-<!-- ~800 tokens: Key discoveries from codebase analysis, research, and requirements elicitation -->
 <!-- Ground every finding in evidence — cite file paths, line numbers, or URLs -->
 
 ## Constraints
-<!-- ~400 tokens: Technical constraints, dependencies, and limitations discovered -->
 
 ## Risks
-<!-- ~300 tokens: Technical risks, unknowns, and potential blockers -->
 
 ## Out of Scope
-<!-- ~200 tokens: Explicitly list what this work should NOT cover -->
 
 ## Open Questions
-<!-- ~200 tokens: Unresolved questions that need answers before defining requirements -->
 <!-- Distinguish facts from assumptions explicitly -->

package/templates/live-status.yaml

@@ -24,9 +24,4 @@ gate_results: []
 #   result: pass
 #   timestamp: ""
 
-cost:
-  tokens_used: 0
-  budget: 0
-  percent: 0
-
 next_action: ""  # Human-readable description of what's next

package/templates/prd.md

@@ -1,18 +1,13 @@
 # Product Requirements Document
-<!-- Budget: 3000 tokens max -->
 <!-- This defines WHAT to build and WHY — not HOW. Architecture comes later. -->
 
 ## Context
-<!-- ~300 tokens: What exists today and why this work is needed -->
 
 ## Problem
-<!-- ~400 tokens: What specific problem are we solving -->
 
 ## Users
-<!-- ~200 tokens: Who are the users and what do they need -->
 
 ## Requirements
-<!-- ~800 tokens: EARS-format requirements -->
 <!-- Use: "The <system> shall <action>" for each requirement -->
 
 ### Functional Requirements
@@ -20,11 +15,8 @@
 ### Non-Functional Requirements
 
 ## Out of Scope
-<!-- ~200 tokens: Explicitly list what this work does NOT cover -->
 <!-- This section is mandatory — scope creep dies here -->
 
 ## Success Criteria
-<!-- ~300 tokens: Measurable outcomes that define "done" -->
 
 ## Open Questions
-<!-- ~200 tokens: Unresolved questions that need answers before design -->

package/templates/story.md

@@ -6,16 +6,12 @@ completed_at:
 ---
 
 # Story: [TITLE]
-<!-- Budget: 1500 tokens max -->
 
 ## Context
-<!-- ~200 tokens: Why this story exists, link to architecture/spec -->
 
 ## Task
-<!-- ~400 tokens: What needs to be done, specific and actionable -->
 
 ## Acceptance Criteria
-<!-- ~600 tokens: EARS-format criteria -->
 <!-- Each criterion must be independently testable -->
 
 1. When [event], the system shall [action]
@@ -23,4 +19,3 @@ completed_at:
 3. If [condition], then the system shall [action]
 
 ## Technical Notes
-<!-- ~300 tokens: Implementation hints, relevant code locations, gotchas -->

package/schemas/cost.schema.yaml

@@ -1,97 +0,0 @@
-$schema: "https://json-schema.org/draft/2020-12/schema"
-$id: "https://sniper.ai/schemas/cost"
-title: Cost Tracking
-description: Schema for SNIPER cost tracking that monitors token usage and budget across phases.
-type: object
-required:
-  - protocol
-  - started_at
-  - budget
-properties:
-  protocol:
-    type: string
-    description: The SNIPER protocol version identifier.
-  started_at:
-    type: string
-    format: date-time
-    description: ISO 8601 timestamp of when cost tracking began.
-  budget:
-    type: number
-    minimum: 0
-    description: Total token budget allocated for the project.
-  phases:
-    type: array
-    description: Per-phase cost breakdown.
-    items:
-      type: object
-      required:
-        - name
-      properties:
-        name:
-          type: string
-          description: Phase name (e.g. discover, plan, implement, review).
-        started_at:
-          type: string
-          format: date-time
-          description: ISO 8601 timestamp of when this phase started.
-        completed_at:
-          type: string
-          format: date-time
-          description: ISO 8601 timestamp of when this phase completed.
-        tokens_used:
-          type: integer
-          minimum: 0
-          description: Total tokens consumed during this phase.
-        agents:
-          type: array
-          description: Per-agent cost breakdown within this phase.
-          items:
-            type: object
-            required:
-              - name
-              - tokens_used
-            properties:
-              name:
-                type: string
-                description: Agent persona name.
-              tokens_used:
-                type: integer
-                minimum: 0
-                description: Tokens consumed by this agent.
-  totals:
-    type: object
-    description: Aggregate cost totals.
-    properties:
-      tokens_used:
-        type: integer
-        minimum: 0
-        description: Total tokens consumed across all phases.
-      budget_remaining:
-        type: number
-        minimum: 0
-        description: Remaining token budget.
-      budget_percent_used:
-        type: number
-        minimum: 0
-        maximum: 100
-        description: Percentage of budget consumed.
-  enforcement:
-    type: object
-    description: Budget enforcement thresholds expressed as fractions of the total budget.
-    properties:
-      warn_threshold:
-        type: number
-        minimum: 0
-        maximum: 1
-        description: Fraction of budget at which a warning is issued.
-      soft_cap:
-        type: number
-        minimum: 0
-        maximum: 1
-        description: Fraction of budget at which soft enforcement begins (e.g. require confirmation).
-      hard_cap:
-        type: number
-        minimum: 0
-        maximum: 1
-        description: Fraction of budget at which execution is halted.
-additionalProperties: false

package/schemas/velocity.schema.yaml

@@ -1,52 +0,0 @@
-$schema: "https://json-schema.org/draft/2020-12/schema"
-$id: "https://sniper.ai/schemas/velocity"
-title: Velocity
-description: Protocol execution history and calibrated budgets for adaptive budget selection.
-type: object
-required:
-  - executions
-properties:
-  executions:
-    type: array
-    description: History of protocol executions with timing and token data.
-    items:
-      type: object
-      required:
-        - protocol
-        - completed_at
-        - tokens_used
-      properties:
-        protocol:
-          type: string
-          description: Protocol name that was executed.
-        completed_at:
-          type: string
-          format: date-time
-          description: ISO 8601 timestamp of when the execution completed.
-        wall_clock_seconds:
-          type: number
-          minimum: 0
-          description: Wall clock duration of the execution in seconds.
-        tokens_used:
-          type: integer
-          minimum: 0
-          description: Total tokens consumed during the execution.
-        tokens_per_phase:
-          type: object
-          description: Token usage broken down by phase name.
-          additionalProperties:
-            type: integer
-            minimum: 0
-  calibrated_budgets:
-    type: object
-    description: p75 of token usage from last 5+ executions, keyed by protocol name.
-    additionalProperties:
-      type: integer
-      minimum: 0
-  rolling_averages:
-    type: object
-    description: Exponential moving average of token usage, keyed by protocol name.
-    additionalProperties:
-      type: number
-      minimum: 0
-additionalProperties: false

package/templates/cost.yaml

@@ -1,23 +0,0 @@
-# Cost tracking for protocol execution
-protocol: ""
-started_at: ""
-budget: 0
-
-phases: []
-# - name: discover
-#   started_at: ""
-#   completed_at: ""
-#   tokens_used: 0
-#   agents:
-#     - name: analyst
-#       tokens_used: 0
-
-totals:
-  tokens_used: 0
-  budget_remaining: 0
-  budget_percent_used: 0
-
-enforcement:
-  warn_threshold: 0.7    # Warn at 70% budget
-  soft_cap: 0.9          # Soft cap at 90% — agents must justify continuation
-  hard_cap: 1.0          # Hard cap at 100% — stop execution

package/templates/velocity.yaml

@@ -1,9 +0,0 @@
-# Velocity — protocol execution history and calibrated budgets
-# Auto-populated by retro-analyst after each protocol completion
-# Read by /sniper-flow for adaptive budget selection
-
-executions: []
-
-calibrated_budgets: {}
-
-rolling_averages: {}