Acceptance Criteria

Testable Given/When/Then conditions that define "done" for every user story. · Required

Acceptance criteria are the most granular layer of your spec — the precise, verifiable behaviours a story must satisfy. They're generated alongside your stories, and they're what your test suite and your coding agent read to know exactly what to build.

Reading your criteria

VibeMap writes criteria in Behaviour-Driven Development (BDD) form:

Each story typically gets 3–8 criteria spread across three scenario categories — happy path (the successful flow), error scenarios (validation and failures), and edge cases (boundaries and unusual-but-valid inputs). Good coverage means all three are present, not just the happy path.

Work with them in the Criteria Breakdown view (Features tab), which shows the full hierarchy:

Feature
  User Story
    Criterion 1 (Given / When / Then)
    Criterion 2 (Given / When / Then)

Each criterion shows its type, priority, and status. You can also open any story to see its criteria in the detail panel.

The two derivation directions

This is where the spec stops being a straight line and becomes a loop. Criteria can be derived from two sources, and using both is how you reach full coverage:

• Derive from features — the standard path, run from the Criteria Breakdown tab (or the agent's "Derive acceptance criteria" action). Criteria come from features and their stories.
• Sync from pages — once pages exist, a second pass derives criteria from your page layouts, catching UI behaviours (empty states, navigation, form flows) that the feature-centric pass can't see. Run it from the Pages tab (or the agent's "Sync criteria from pages" chip).

💡 Tip: Run features → criteria first, generate pages, then sync pages → criteria. The coverage panel on the project Overview (and in Prepare for Dev) flags any story still missing criteria.

Editing criteria

Add custom criteria from a story's detail view; edit to tighten conditions (exact limits, timeouts, accessibility rules); delete anything out of scope. Deleted criteria are excluded from generated tests and the blueprint.

⚡ Power-user hints

• One behaviour per criterion. If a criterion has two "Then" outcomes, split it — each maps to exactly one test row.
• Add the non-functional ones the AI skips. Performance thresholds, a11y, rate limits — these rarely appear unless you write them, and they matter at handoff.
• Vocabulary drives test type. UI words (click, view, page) classify a criterion as e2e; data words (record, API, email) as integration. Word your Given/When/Then deliberately and the Tests tab classifies itself correctly.

↔ The traditional way

A QA lead or BA normally writes acceptance criteria by hand, story by story, and they're often skipped under deadline — which is how untested edge cases ship. VibeMap generates BDD criteria across happy, error, and edge scenarios for every story at once, and cross-checks them against your pages, so "definition of done" is complete before a line of code is written.

What's next

• See criteria projected into a ready-to-scaffold suite → Tests
• Give the schema and pages richer context → Generating Pages