The Flech brain — specs, decisions, learnings, tech & incidents, linked. The agent retrieves from this when authoring a new spec.
Any real-time/websocket delivery feature must include an explicit offline → deliver-on-reconnect acceptance scenario, or it regresses under deploys.
External webhook integrations re-deliver; always add a duplicate-delivery scenario and an idempotency decision.
When users can change delivery preferences, add a scenario asserting changes are recorded and respected immediately.
Limit features should scope quotas per tenant and add a noisy-neighbour scenario.
Delivery / latency outcomes must carry a time bound (within N s) or the QA agent can't assert them.
Scenarios describe behaviour, not mechanism — tech names couple the spec to today's design.
Multiple Thens hide multiple tests; split so each can pass or fail on its own.
The failure modes are where the real spec lives.
Real-time delivery needs persistent connections at scale across regions.
Stripe re-delivers webhook events; naive handlers double-charge.
Duplicate notifications within a short window annoy users.
Sticky LB; ~50k conns/region; reconnect storms on deploy.
At-least-once delivery; consumers must be idempotent.
Presence + dedupe windows (TTL-based idempotency).
System of record; outbox pattern for webhooks.
Queued notifications dropped during a rolling deploy.
p99 event→toast exceeded 2s.
Re-delivered Stripe events charged twice.
Real-time alerts when critical events occur.
Reconcile Stripe webhook events.
Persisted filter views on lists.
Checkout & subscriptions.
Sessions, SSO & password reset.
Per-tenant request limits.