Documentation Index
Fetch the complete documentation index at: https://docs.oktolabs.ai/llms.txt
Use this file to discover all available pages before exploring further.
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 arecritical, 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: completeness0-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.