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.