Dev Sprint

---
name: dev-sprint
description: Run multi-step Capsem development in Sprinty. Use for features, refactors, migrations, release preparation, or any work spanning several commits and verification gates.
---

# Development Sprint

Sprinty is the sole active sprint ledger. Git owns source and permanent
history; Sprinty owns the goal, dependency graph, work items, notes, evidence,
coverage, gates, and closeout. Do not create repository planning directories
or parallel Markdown trackers.

## Start or resume

Call `mcp__sprinty.info()` first on every new session or continuation.

- If a matching active sprint exists, bind it with
  `mcp__sprinty.sprint_resume()` using the explicit repository `git_dir` and
  its worktree-scoped, ignored `data_dir`.
- If no matching sprint exists, call `mcp__sprinty.sprint_new()` with the
  concrete goal, explicit `git_dir`, ignored `data_dir`, and durable context
  notes.
- Show the dashboard URL to the user. Use `overview()` for sprint shape and
  `next()` for the current work window; do not reconstruct state from memory.

Never start a replacement sprint because the work is difficult or context was
compacted. Resume the existing ledger and inspect its artifacts.

## Select the release channel from product intent

Nightly builds from `main` serve development. Qualification for general
availability uses **stable**, including the intended binary, runtime and
official image catalog. Capsem 0.7.1 GA qualification therefore uses stable.

Record the intended channel in Sprinty before publication or product proof.
A `main` checkout, a development worktree, or an older local installation does
not change stable qualification into nightly work. Keep catalog discovery,
caching, launch and installed-product checks on the selected channel; do not
switch channels to work around missing publication. Follow `RELEASE.md` and
`/release-process` for release authority and exact-source proof.

## Plan the dependency graph

Use `mcp__sprinty.subsprint_new()` for independently reviewable features or
phases. Each subsprint names:

- the outcome and why it matters;
- ordered dependencies;
- explicit goals;
- executable or manual gates that prove the complete behavior.

Use `mcp__sprinty.item_add()` before editing files or mutating another system.
An item owns one revertable outcome and records:

- a specific title and complete description;
- exact code locations;
- dependency edges;
- focused tests, type checks, builds, or manual evidence gates.

Adjacent notes are not a substitute for a dedicated item when work has its
own files, risk, or outcome. Split broad items instead of hiding multiple
commits behind one checkbox.

For Capsem release, VM, network, model, MCP, credential broker,
package-manager, doctor, benchmark, or security acceptance work, load
`/ironbank` and include its black-box proof in the owning item before coding.

## Keep durable evidence in Sprinty

- Use notes for short discoveries, decisions, blockers, and user checkpoints.
- Use artifacts for audits, manifests, proof matrices, command output
  summaries, or handoffs that must survive compaction.
- Attach each artifact to the item or items it proves.
- Keep coverage honest: name unit/contract, functional, adversarial, E2E/VM,
  telemetry, and performance evidence, and explicitly record categories that
  do not apply.

Do not treat a benchmark as functional proof or a Rust unit test as proof of a
user-visible VM path. Ironbank gates cannot be closed with status-only replay,
row-exists checks, internal-only expectations, or skipped tests.

## Build with project rules

Prioritize writing the implementation across the requested scope. During the
edit loop use TDD and the minimum focused checks needed for changed behavior;
do not start broad contract, workspace, VM, install or benchmark runs as a
routine habit. Direct bounded commands do not take a machine lease by default.
Keep coding independent work while local checks run. Separate implementation
dependencies from qualification holds so pending broad proof does not stall
later work that can be implemented safely.

Load the relevant project skills before coding:

- `/dev-debugging` for reproduce-first bug investigation;
- `/dev-testing` for RED, GREEN, and refactor discipline;
- `/dev-rust-patterns` for Rust, async, and cross-platform work;
- `/dev-mitm-proxy`, `/dev-mcp`, `/build-images`, and other owning skills for
  their subsystems;
- `/ironbank` for release-critical black-box acceptance.

Keep config ownership crisp:

- Read `config/README.md` and `tests/README.md` before changing config source,
  generated config, or config fixtures.
- Checked-in config files are source contracts. Generated hashes and
  manifests belong under `cache/target/` and are produced by the same
  `capsem-admin` rail CI and release use.
- Developer skills live in repository-level `skills/`; product configuration
  must not mirror them.
- Prefer functional names that state ownership over temporary or origin-story
  names.

## Commit at functional milestones

Commit when one logical item or milestone is complete, its focused evidence is
green, and the tree is not half-migrated. Each commit must be self-contained
and revertable.

- Stage files explicitly; never use broad staging.
- Follow the repository conventional subject and author rules.
- Update `CHANGELOG.md` in the same commit only for user-visible behavior.
- Preserve a clean status before moving to the next item.

After the commit, call `mcp__sprinty.item_done()` with the exact commit id, a
SemVer changelog verb and line, and evidence for every manual gate. Sprinty
runs executable gates itself where configured. Do not close an item against
uncommitted work or a commit that does not contain its files.

## Verify proportionally, then verify completely

Every implementation item gets its necessary focused TDD/regression proof.
Full qualification belongs at the end of each major phase, covering the whole
phase outcome, and at final merge/release readiness. Do not repeat broad gates
per item or commit. Track qualification separately and never claim a phase is
qualified from a small local check. Public-contract and publication approvals
remain explicit decisions.

The proof matrix should consider:

- unit and contract tests;
- production-facing functional behavior;
- malformed input, denial, timeout, race, and leak adversaries;
- real CLI, service, MCP, network, package, or VM paths when crossed;
- session database or external-state evidence when auditability is claimed;
- performance measurements only when performance is part of the claim.

Run direct commands through the repository's bounded-command wrapper. Read the
current gate digest before claiming a gate passes. Keep release holds active
until focused checks and the final required gates are green.

## Close

Before closeout:

1. Use `overview()` and `next()` to prove no item or subsprint remains open.
2. Reconcile notes, artifacts, coverage, changelog entries, and commit ids.
3. Run the final required gates on the exact final source state.
4. Verify the worktree is clean and no temporary compatibility path remains.
5. Call `mcp__sprinty.sprint_close()` only after Sprinty accepts the complete
   evidence ledger.

If work is blocked, keep the owning item open and record the exact external
condition. Do not shrink the goal or declare completion around the blocker.