santhoshj/clawfort
1
0
Fork 0
Code Issues 64 Pull Requests Actions Packages Projects Releases Wiki Activity

bulk commit changes!

Browse Source
This commit is contained in:
Santhosh Janardhanan
2026-02-13 02:32:06 -05:00
parent c8f98c54c9
commit bf4a40f533
152 changed files with 2210 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
openspec/changes/archive/2026-02-13-p07-tech-robustness/.openspec.yaml Normal file
View File

@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-02-12

71
openspec/changes/archive/2026-02-13-p07-tech-robustness/design.md Normal file
View File

@@ -0,0 +1,71 @@
## 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?

27
openspec/changes/archive/2026-02-13-p07-tech-robustness/proposal.md Normal file
View File

@@ -0,0 +1,27 @@
## Why
The product needs stronger technical quality and trust signals across devices and accessibility contexts. Improving responsiveness, WCAG 2.2 AA conformance, and compliant consent handling reduces usability risk and supports broader adoption.
## What Changes
- Make the site fully device-agnostic and responsive across mobile, tablet, and desktop breakpoints.
- Bring key user flows to WCAG 2.2 AA standards (contrast, focus visibility, keyboard navigation, semantics, and non-text content).
- Add a cookie consent banner with clear consent messaging and persistence.
- Record consent in browser cookies (with local state sync where applicable) and apply analytics only after consent is given.
## Capabilities
### New Capabilities
- `responsive-device-agnostic-layout`: Ensure core pages/components adapt reliably across viewport sizes and input modes.
- `wcag-2-2-aa-accessibility`: Enforce WCAG 2.2 AA requirements for interactive and content-rendering paths.
- `cookie-consent-tracking-gate`: Provide consent capture and persistence for analytics/tracking behavior.
### Modified Capabilities
- None.
## Impact
- **Frontend/UI:** Layout, spacing, typography, and interaction behavior updated for responsive and accessible presentation.
- **Accessibility:** ARIA semantics, keyboard focus flow, and contrast/focus treatments refined.
- **Analytics/Consent:** Consent banner and tracking gate logic added; cookie persistence introduced.
- **QA/Validation:** Accessibility and responsiveness verification scope expands (manual + automated checks where available).

14
openspec/changes/archive/2026-02-13-p07-tech-robustness/specs/cookie-consent-tracking-gate/spec.md Normal file
View File

@@ -0,0 +1,14 @@
## ADDED Requirements
### Requirement: Consent banner captures and persists tracking consent
The system SHALL display a cookie consent banner and persist user consent decision in cookies before enabling analytics tracking.
#### Scenario: Consent capture and persistence
- **WHEN** a user interacts with the consent banner and accepts
- **THEN** consent state is stored in a cookie
- **AND** stored consent is honored on subsequent visits
#### Scenario: Tracking gated by consent
- **WHEN** consent has not been granted
- **THEN** analytics/tracking scripts and events do not execute
- **AND** tracking begins only after consent state indicates acceptance

14
openspec/changes/archive/2026-02-13-p07-tech-robustness/specs/responsive-device-agnostic-layout/spec.md Normal file
View File

@@ -0,0 +1,14 @@
## ADDED Requirements
### Requirement: Core layout is device-agnostic and responsive
The system SHALL render key surfaces (header, hero, feed, modal, footer) responsively across mobile, tablet, and desktop viewports.
#### Scenario: Mobile layout behavior
- **WHEN** a user opens the site on a mobile viewport
- **THEN** content remains readable without horizontal overflow
- **AND** interactive controls remain reachable and usable
#### Scenario: Desktop and tablet adaptation
- **WHEN** a user opens the site on tablet or desktop viewports
- **THEN** layout reflows according to breakpoint design rules
- **AND** no key content or controls are clipped

14
openspec/changes/archive/2026-02-13-p07-tech-robustness/specs/wcag-2-2-aa-accessibility/spec.md Normal file
View File

@@ -0,0 +1,14 @@
## ADDED Requirements
### Requirement: Core user flows comply with WCAG 2.2 AA baseline
The system SHALL meet WCAG 2.2 AA accessibility requirements for primary interactions and content presentation.
#### Scenario: Keyboard-only interaction flow
- **WHEN** a keyboard-only user navigates the page
- **THEN** all primary interactive elements are reachable and operable
- **AND** visible focus indication is present at each step
#### Scenario: Contrast and non-text alternatives
- **WHEN** users consume text and non-text UI content
- **THEN** color contrast meets AA thresholds for relevant text and controls
- **AND** meaningful images and controls include accessible labels/alternatives

28
openspec/changes/archive/2026-02-13-p07-tech-robustness/tasks.md Normal file
View File

@@ -0,0 +1,28 @@
## 1. Responsive Hardening
- [x] 1.1 Audit and fix layout breakpoints for header, hero, feed cards, modal, and footer
- [x] 1.2 Ensure no horizontal overflow or clipped controls on supported viewport sizes
## 2. WCAG 2.2 AA Accessibility Baseline
- [x] 2.1 Implement/verify keyboard operability for primary controls and dialogs
- [x] 2.2 Add/verify visible focus indicators and semantic labels for interactive elements
- [x] 2.3 Improve contrast and non-text alternatives to meet AA expectations on core flows
## 3. Cookie Consent and Tracking Gate
- [x] 3.1 Implement consent banner UI with explicit analytics consent action
- [x] 3.2 Persist consent state in cookies and synchronize frontend state
- [x] 3.3 Gate analytics script/event initialization until consent is granted
## 4. Returning User Consent Behavior
- [x] 4.1 Restore prior consent state from cookie on returning visits
- [x] 4.2 Ensure tracking remains disabled without stored accepted consent
## 5. Verification and Documentation
- [x] 5.1 Validate responsive behavior on mobile/tablet/desktop matrices
- [x] 5.2 Run accessibility checks and manual keyboard-only walkthrough for critical journeys
- [x] 5.3 Validate consent gating and analytics behavior before/after acceptance
- [x] 5.4 Update README/docs with accessibility and consent behavior notes