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
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
The normal gated path is
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.