## Context

The current one-page application has strong feature velocity but uneven robustness across viewport sizes and accessibility states. It also initializes analytics without an explicit user consent gate, which creates compliance and trust risks in stricter jurisdictions.

This change introduces responsive hardening, WCAG 2.2 AA baseline conformance, and explicit cookie-consent-controlled tracking behavior.

## Goals / Non-Goals

**Goals:**
- Ensure key UI flows work consistently across mobile, tablet, and desktop.
- Bring critical interactions and content presentation to WCAG 2.2 AA expectations.
- Add consent UI and persist consent state in cookies (with local state sync).
- Gate analytics script/event execution behind consent.

**Non-Goals:**
- Full legal-policy framework beyond consent capture basics.
- Rebuilding the full visual system from scratch.
- Country-specific geo-personalized consent variants in this phase.

## Decisions

### Decision: Define responsive guarantees around existing breakpoints and interaction surfaces
**Decision:** Formalize requirements for hero, feed cards, modal/dialog interactions, and header controls across common breakpoints and orientations.

**Rationale:**
- Targets user-visible breakage points first.
- Reduces regression risk while keeping implementation incremental.

**Alternatives considered:**
- Pixel-perfect per-device tailoring: rejected due to maintenance cost.

### Decision: Prioritize WCAG 2.2 AA for core paths and controls
**Decision:** Apply compliance to keyboard navigation, focus indicators, contrast, semantic labels, and non-text alternatives in primary user journeys.

**Rationale:**
- Maximizes accessibility impact where users spend time.
- Keeps scope realistic for immediate hardening.

**Alternatives considered:**
- Attempting broad AAA alignment: rejected as out-of-scope for this phase.

### Decision: Gate analytics on explicit consent and persist choice in cookie
**Decision:** Tracking initializes only after user consent; cookie stores consent state and optional local state mirrors for fast frontend read.

**Rationale:**
- Aligns with safer consent posture and user transparency.
- Supports returning-user behavior without backend session coupling.

**Alternatives considered:**
- Always-on tracking with notice-only banner: rejected for compliance risk.

## Risks / Trade-offs

- **[Risk] Responsive fixes can introduce visual drift across existing sections** -> Mitigation: validate at target breakpoints and keep changes token-based.
- **[Risk] Accessibility remediations may require widespread class/markup changes** -> Mitigation: focus first on critical interactions and reuse shared utility patterns.
- **[Trade-off] Consent gating can reduce analytics volume** -> Mitigation: explicit consent messaging and friction-minimized accept flow.

## Migration Plan

1. Add responsive and accessibility acceptance criteria for key components.
2. Implement consent banner, persistence logic, and analytics gating.
3. Refine UI semantics/focus/contrast and test keyboard-only navigation.
4. Validate across viewport matrix and accessibility checklist.

Rollback:
- Disable consent gate logic and revert to prior analytics init path while retaining non-breaking responsive/accessibility improvements.

## Open Questions

- Should consent expiration/renewal interval be introduced in this phase or follow-up?
- Should consent state include analytics-only granularity now, or remain a single accepted state?