US-1212

Usage-based Billing

PLANNED

AI drafted the designLast verified 4 min ago

User story

meteringbilling

Channels & integrations · auto-detected from this story

In-app

Acceptance criteria

0 / 2 verified

Each scenario is run as a Playwright test by the QA agent

Scenario 1: Usage is metered Not run

Givena billable action

Whenit occurs

Thena usage record is written with an idempotency key

Scenario 2: Invoice reflects usage Not run

Givenmetered usage within a billing period

Whenthe period closes

Thenan invoice is generated from the aggregated usage

Spec quality · craft learnings applied

7/10 passing

Generalisable rules the agent applies to every spec — they grow from review feedback & flaky scenarios, and act as a self-improving linter.

Assert one outcome per scenarioAtomicity

Each scenario asserts a single outcome

One trigger per scenarioAtomicity

Every scenario has exactly one trigger

Keep implementation out of Given/When/ThenClarity

Scenarios describe behaviour, not implementation

Make every outcome machine-checkableTestability

Outcomes are concrete and observable

Bound time-sensitive outcomesTestability

Time-sensitive outcomes carry a bound

Pair every happy path with a failure pathCoverage

No failure or edge-case scenario — add the unhappy path

Happy-path-only specs ship bugs; the failure modes are where the real spec lives.

Assert the negative spaceCoverage

No scenario states what must not happen

Say what must NOT happen (no double-charge, no email when muted) — bugs hide in the unstated.

State actor, capability and benefitClarity

Story names actor, capability and benefit

One promise per storyScope

The story promises more than one capability — consider splitting

If the “I want …” clause has an “and” joining two capabilities, split it into two stories.

Keep the slice thinScope

2 scenarios — a thin, shippable slice

Learnings applied · from the library