Sprints & cards
The execution domain. Once a spec isvalidated, 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, andassign_tasks_to_sprint. - Sprint evaluation (4) — submit / list / get / delete sprint evaluation (the
review → closedgate). - 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.
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 forreview → 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.
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
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.