API

Author: rezwana-karim

specs/002-harden-checkout-tenancy/checklists/api.md

@@ -0,0 +1,37 @@
+<!--
+  Checklist: API Requirements Quality
+  Generated by speckit.checklist on 2025-11-14
+  Purpose: Unit-tests-for-English that validate the API & backend requirements' clarity, completeness, consistency, measurability and traceability
+-->
+
+# API Requirements Quality Checklist
+
+Purpose: Validate that API-related requirements in `specs/002-harden-checkout-tenancy` are complete, unambiguous, measurable, and traceable before implementation.
+
+Feature: Harden Checkout, Tenancy, and Newsletter
+Created: 2025-11-14
+Author: automated speckit.checklist run
+
+Notes: This checklist tests the *requirements text* (not the implementation). Each item references the spec where relevant (e.g., FR identifiers). If a requirement is missing or ambiguous, mark the item and update spec/plan/tasks accordingly.
+
+## Requirement Completeness
+- [ ] CHK001 - Are authentication requirements for checkout fully specified, including which endpoints require a session and exact auth failure responses? [Completeness, Spec §FR-001]
+- [ ] CHK002 - Is the server-side pricing recalculation scope fully enumerated (line items, discounts, shipping, taxes, rounding rules, currency behavior)? [Completeness, Spec §FR-002]
+- [ ] CHK003 - Are all API endpoints that must include `X-Request-Id` and correlation propagation identified in the spec/plan? [Completeness, Spec §FR-021]
+- [ ] CHK004 - Are CSV export behaviors fully specified (stream threshold, async enqueue conditions, notification channels) and linked to an export failure/retry policy? [Completeness, Spec §FR-016]
+
+## Requirement Clarity
+- [ ] CHK005 - Is the payment pre-validation requirement precise about what constitutes a valid intent/token (authorization vs capture) and when validation occurs? [Clarity, Spec §FR-003]
+- [ ] CHK006 - Are error response shapes and HTTP status mappings explicitly defined for common failures (validation, auth, rate-limit, conflict, internal)? [Clarity, Spec §FR-008]
+- [ ] CHK007 - Is the canonical redirect behavior specified with HTTP status code, canonical link header conventions, and SEO considerations (308 vs 301, rel=canonical)? [Clarity, Spec §FR-005]
+- [ ] CHK008 - Are rate-limiting thresholds for newsletter and checkout clearly quantified (requests/min per IP/store) and behavior on exceed (Retry-After header) defined? [Clarity, Spec §FR-019, assumption in spec]
+
+## Requirement Consistency
+- [ ] CHK009 - Do authentication requirements align across spec/plan/tasks (no conflicting statements about anonymous checkout or default store fallbacks)? [Consistency, Spec §FR-001/FR-006]
+- [ ] CHK010 - Are tenant-scoping semantics consistently described (session.storeId vs domain-resolver) and not contradictory across plan and tasks? [Consistency, Spec §FR-005/FR-009]
+- [ ] CHK011 - Are the cache invalidation semantics (tags and revalidateTag signature) consistently used in plan and tasks (e.g., `revalidateTag(tag, 'max')`)? [Consistency, Plan P5]
+
+## Acceptance Criteria Quality
+- [ ] CHK012 - Are acceptance criteria measurable and tied to concrete checks (e.g., SC-003 specifies server-side recalculation validated by E2E across browsers)? [Measurability, Spec Success Criteria SC-003]
+- [ ] CHK013 - Do success criteria include pass/fail thresholds for non-functional requirements (LCP/CLS/API p95) with explicit measurement contexts? [Measurability, Spec SC-010]
+- [ ] CHK014 - Are rollback/compensation criteria specified for partial failures during checkout (what exact DB state indicates