Cards Overview
Cards are the core unit of requirements management in Vanillaround. They are structured blocks embedded directly inside spec pages, representing individual, trackable, and approvable requirements.
Why cards exist
Section titled “Why cards exist”Writing requirements in prose is necessary for context — but prose alone doesn’t give you accountability. You can’t assign a paragraph to a person, track its approval status, or sync it to Jira.
Cards solve this. A card is a structured element inside a spec page that:
- Has a defined type (Requirement, Bug, Enhancement, etc.)
- Can be assigned to specific team members
- Goes through a formal approval workflow
- Can be linked to a Jira issue
- Can be placed on a board to track its progress
The surrounding spec page provides the context (the why and the how). The card provides the structured record of what was agreed.
Cards live inside specs
Section titled “Cards live inside specs”Cards are not separate from spec pages — they are embedded within them. This means a requirement is always read in context. A Client approving a card sees exactly what surrounds it: the feature description, the use cases, the open questions. There is no disconnected ticket divorced from its rationale.
Card types
Section titled “Card types”Vanillaround ships with three built-in card types and allows Providers to create custom types per project:
| Type | Use case |
|---|---|
| Requirement | The primary type. Includes approval workflow, member assignment, and Jira linking. |
| Basic | A simpler card with a type label. Useful for tracking without a full approval cycle. |
| Simple | A minimal card for notes or placeholders within a spec. |
See Card Types for the full breakdown.
The card lifecycle
Section titled “The card lifecycle”- Created — a Provider inserts a card into a spec page
- Configured — type, members, and metadata are filled in
- Draft — the card is being worked on; not yet ready for review
- Submitted — the Provider submits the card for Client approval
- Approved or Rejected — the Client decides; rejected cards return to Draft
- Synced to Jira — an approved card becomes a Jira issue
- On the board — the card’s progress is tracked through board columns
See Approval Workflow for a step-by-step walkthrough.