Skip to main content

Sprints & cards

The execution domain. Once a spec is validated, work splits into sprints (logical delivery slices) and cards (single execution units). Pulse exposes 26 of its 216 MCP tools for this stage:
  • Sprint lifecycle (8) — create / update / move / get / get_context / list, AI-assisted suggest_sprints, and assign_tasks_to_sprint.
  • Sprint evaluation (4) — submit / list / get / delete sprint evaluation (the review → closed gate).
  • Card lifecycle (7) — create / get / get_task_context / get_task_conclusions / update / move / delete.
  • Card dependencies (3)add_card_dependency / remove_card_dependency / get_card_dependencies.
  • Listing, blockers, analytics (4)list_cards_by_status, list_blockers, get_traceability_report, get_analytics.
This page covers sprint scoping, sprint quality evaluation, and the card lifecycle. The task validation gate (submit_task_validation) and the test theater anti-pattern (update_test_scenario_status) live on the Validation gates page. Card Q&A and comments live on Comments & questions; card knowledge and attachments on Knowledge & attachments; copy-from-spec mockups and architecture on Architecture & mockups. Source-of-truth citations: okto-pulse-feature-inventory.md:256–271 (card lifecycle), :457–475 (sprint tools), :395–410 (analytics + blockers + traceability), :967–981 (status enums), :982–1021 (governance gates).

Sprint vs. card

A sprint is not a time-box. It is a scope contract: “these N cards go together; close the sprint when they are validated.” Sprints scope a release more than a calendar.

Status flow and gates

Sprint close re-validates every test scenario marked passed on cards in the sprint. A scenario marked passed without the structured evidence recorded by update_test_scenario_status is treated as theater — sprint close fails and the scenario regresses to pending until evidence is supplied. See the Validation gates page for the evidence schema.

Sprint tool index

Lifecycle (6)

create_sprint, update_sprint, move_sprint, get_sprint, get_sprint_context, list_sprints.

Suggest & assign (2)

suggest_sprints (AI-assisted slicing), assign_tasks_to_sprint.

Evaluation (4)

submit_sprint_evaluation, list_sprint_evaluations, get_sprint_evaluation, delete_sprint_evaluation.

Q&A (3)

ask_sprint_question, answer_sprint_question, delete_sprint_question. See Comments & questions for full Q&A coverage across stages.

Sprint lifecycle

okto_pulse_create_sprint

Source: server.py:11272. Create a sprint under a spec. Most agents use suggest_sprints first and create from the suggestion’s payload.

okto_pulse_update_sprint

Source: server.py:11345. Update sprint fields.

okto_pulse_move_sprint

Source: server.py:11426. Advance status. The review → closed gate enforces sprint evaluation and test-scenario evidence recheck.

okto_pulse_get_sprint

Source: server.py:11472. Get a sprint by ID.

okto_pulse_get_sprint_context

Source: server.py:11520. Rich bundle: sprint + parent spec + all assigned cards + KG context. Use this before activating or closing a sprint.

okto_pulse_list_sprints

Source: server.py:11646. List sprints on a board or spec.

okto_pulse_assign_tasks_to_sprint

Source: server.py:11682. Assign one or more cards to a sprint. Cards can move between sprints (e.g. when a sprint slips, deferred cards roll forward).

okto_pulse_suggest_sprints

Source: server.py:12128. AI-assisted: slice a validated spec into one or more reviewable deliveries. Returns sprint candidates with title, objective, expected outcome, and recommended card list.

Sprint evaluation

The sprint evaluation is the quality gate for review → closed. It captures a written retrospective with structured ratings (a sprint cannot close silently).

Card tool index

Lifecycle (5)

create_card, get_card, update_card, move_card, delete_card.

Context bundles (2)

get_task_context (rich pre-implementation bundle), get_task_conclusions (post-close summary).

Dependencies (3)

add_card_dependency, remove_card_dependency, get_card_dependencies.

Listing & analytics (4)

list_cards_by_status, list_blockers, get_traceability_report, get_analytics.

Card lifecycle

okto_pulse_create_card

Source: server.py:1550. Create a card. Card type controls downstream gates: normal (default), test (test scaffolding), bug (test-first gate).

okto_pulse_get_card

Source: server.py:1799. Get full card details.

okto_pulse_get_task_context

Source: server.py:1880. The single most-called tool inside an implementation session. Returns card + spec + business rules + test scenarios + decisions + KG context — everything an implementer agent needs to start work without re-reading the spec from scratch.
Always call get_task_context before moving a card to in_progress. The KG context block surfaces decisions another agent recorded on a similar card; reading them often cuts implementation time substantially.

okto_pulse_get_task_conclusions

Source: server.py:2090. Get conclusion text + completeness score (0–100) + drift score (0–100) for a card that has reached validation or done.

okto_pulse_update_card

Source: server.py:2145. Update card fields, including conclusion, completeness, drift, and bug_severity. The conclusion fields are required before move_card can transition validation → done.

okto_pulse_move_card

Source: server.py:2291. Advance card status. Forward gates are server-enforced.

okto_pulse_delete_card

Source: server.py:2396. Permanently delete a card. Use archive_tree (see Architecture & mockups) for soft-delete.

Dependencies

A card whose depends_on set contains an unfinished card is reported in list_blockers. The card itself can still move forward if its dependencies are satisfied — this is hard data, not a hard gate.

Listing, blockers, traceability, analytics

These four tools span sprints, cards, and the spec contract — they answer board-level health questions and are commonly the first calls a planning agent makes.

okto_pulse_list_cards_by_status

Source: server.py:2544. List cards filtered by status, type, sprint, or spec.

okto_pulse_list_blockers

Source: server.py:8199. List cards currently blocked — status=on_hold or with unresolved dependencies. Pulse classifies both shapes the same way; an agent reviewing blockers does not need to query both lists.

okto_pulse_get_traceability_report

Source: server.py:10713. Full lineage: spec → BRs → TRs → scenarios → cards → validations. The single best call for “what evidence have we produced for this spec?” — runs entirely inside Pulse, no KG round-trip needed.

okto_pulse_get_analytics

Source: server.py:7893. Board-level metrics: velocity (cards/sprint), quality (validation pass rate, drift average), coverage (AC → scenario %), and per-agent breakdowns.

Permissions

For task validation gate permissions (Permissions.VALIDATOR_*), see Validation gates.

Errors


Next steps

Validation gates

submit_task_validation, update_test_scenario_status (anti-theater evidence), and the Validator preset.

Specs

Author the contract a sprint and its cards execute against.

Comments & questions

Card Q&A and free-form comments / choice polls.

ADLC pipeline

Where sprints and cards sit in the end-to-end flow.
Last modified on May 17, 2026