Cards
You can use cards as the executable work units in Pulse. A card carries status, owner, dependencies, links back to spec evidence, comments, Q&A, attachments, conclusions, and validation records.
What is a card
A card is the smallest delivery object an agent should implement or validate. Cards can be created directly, derived from specs, assigned to sprints, and linked to spec evidence.
Card types
| Type | Use it for |
|---|
normal | Standard implementation work. |
test | Test-only work. Test cards can bypass the normal task validation gate. |
bug | A defect. Bug cards require bug-specific fields and should preserve root-cause learning. |
Bug card specifics
Bug severity is explicit: blocker, critical, major, minor, or trivial. A bug card should include reproduction steps, expected behavior, actual behavior, suspected area, and a failing test scenario before moving into implementation.
States
| State | Meaning |
|---|
not_started | Ready but not picked up. |
started | Claimed or started. |
in_progress | Active implementation. |
validation | Waiting for reviewer validation. |
on_hold | Blocked or intentionally paused. |
done | Complete. |
cancelled | Should not proceed. |
not_started -> started -> in_progress -> validation -> done.
Card priority
Use priority to communicate sequencing pressure, not importance theater. Supported values are critical, high, medium, and low.
Card knowledge, mockups, and architecture
Cards can copy knowledge, Q&A, mockups, and architecture from the spec or attach their own. Copy from spec when the context is already approved. Attach directly when the implementation discovers card-specific evidence.
Dependencies between cards
Use dependencies when one card cannot be completed until another lands. Dependencies should be concrete: API exists, schema migrated, test fixture added, deployment flag available.
Task conclusions
Before a normal card can move into validation, the implementer must supply an execution conclusion: completeness 0-100, drift 0-100, and written justification. This turns the handoff into evidence rather than a status flip.
Validation records
Task validation is append-only. okto_pulse_submit_task_validation checks confidence, completeness, drift, and threshold violations, then routes the card to done or keeps it in validation.
Traceability
Use traceability links so a card can prove what it implements:
okto_pulse_link_task_to_scenario
okto_pulse_link_task_to_rule
okto_pulse_link_task_to_contract
okto_pulse_link_task_to_tr
Related pages
Last modified on May 8, 2026
