Pushing to live
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: End-to-end coverage spans UI, API, and DB effects
|
||||
The system SHALL provide end-to-end tests that validate full workflows across UI, API, and persisted database outcomes, including browser-native Playwright coverage for user-visible behavior.
|
||||
|
||||
#### Scenario: Core user flow E2E
|
||||
- **WHEN** a core browsing flow is executed in E2E tests
|
||||
- **THEN** UI behavior, API responses, and DB side effects match expected outcomes
|
||||
|
||||
#### Scenario: Browser-native interaction E2E
|
||||
- **WHEN** a critical journey is executed via Playwright
|
||||
- **THEN** rendered UI, network/API behavior, and persisted outcomes remain consistent end-to-end
|
||||
- **AND** regressions in interaction behavior are caught before release
|
||||
|
||||
### Requirement: Edge-case workflows are covered
|
||||
The system SHALL include edge-case E2E tests for critical failure and boundary conditions, including UI-safe handling in browser flows.
|
||||
|
||||
#### Scenario: Failure-state E2E
|
||||
- **WHEN** an edge case is triggered (empty data, unavailable upstream, invalid permalink, etc.)
|
||||
- **THEN** system response remains stable and user-safe
|
||||
- **AND** no unhandled runtime errors occur
|
||||
|
||||
#### Scenario: UI failure-path resilience
|
||||
- **WHEN** edge-case flows are executed through Playwright user actions
|
||||
- **THEN** fallback messages and controls remain usable
|
||||
- **AND** the session remains navigable without fatal UI breakage
|
||||
@@ -0,0 +1,27 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Release quality gates are mandatory
|
||||
The system SHALL enforce mandatory CI quality gates before release, including Playwright UI/UX regression execution.
|
||||
|
||||
#### Scenario: Gate failure blocks release
|
||||
- **WHEN** any required gate fails
|
||||
- **THEN** release pipeline status is failed
|
||||
- **AND** deployment/archive promotion is blocked
|
||||
|
||||
#### Scenario: Playwright gate failure blocks release
|
||||
- **WHEN** Playwright smoke or required profile checks fail
|
||||
- **THEN** CI marks the quality gate as failed
|
||||
- **AND** release progression is blocked until failures are resolved
|
||||
|
||||
### Requirement: Required gates are explicit and versioned
|
||||
The system SHALL define an explicit set of required gates and versions for tooling, including browser-testing tooling for reproducible UI/UX checks.
|
||||
|
||||
#### Scenario: Gate manifest exists
|
||||
- **WHEN** pipeline configuration is evaluated
|
||||
- **THEN** required gates include tests, accessibility, security, performance, and Playwright UI regression checks
|
||||
- **AND** tool versions are pinned or documented for reproducibility
|
||||
|
||||
#### Scenario: Gate profiles are documented
|
||||
- **WHEN** CI quality-gate documentation is reviewed
|
||||
- **THEN** smoke and full regression profiles are explicitly described
|
||||
- **AND** required profile per pipeline stage is unambiguous
|
||||
@@ -0,0 +1,25 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Playwright regression suite covers core UI/UX capabilities
|
||||
The system SHALL provide a Playwright-based regression suite that validates critical UI and UX behavior across all shipped user-facing capabilities.
|
||||
|
||||
#### Scenario: Capability-mapped suite execution
|
||||
- **WHEN** regression tests are executed
|
||||
- **THEN** test cases are organized and traceable to capability-level requirements
|
||||
- **AND** failures identify the impacted capability and user journey
|
||||
|
||||
### Requirement: Regression suite validates themes, states, and breakpoints
|
||||
The system SHALL validate key controls and content for light, dark, and contrast themes, across mobile, tablet, and desktop breakpoints, including interactive states.
|
||||
|
||||
#### Scenario: Theme and breakpoint matrix coverage
|
||||
- **WHEN** the suite runs in full profile
|
||||
- **THEN** high-priority journeys execute across all supported themes and target viewport classes
|
||||
- **AND** assertions include default, hover, focus-visible, active, and visited states where applicable
|
||||
|
||||
### Requirement: Regression failures produce actionable diagnostics
|
||||
The system SHALL emit debugging artifacts for failed browser tests.
|
||||
|
||||
#### Scenario: Failure artifact collection
|
||||
- **WHEN** a Playwright test fails
|
||||
- **THEN** the run stores trace and screenshot evidence
|
||||
- **AND** artifacts are linked in CI output for triage
|
||||
@@ -0,0 +1,34 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Core layout is device-agnostic and responsive
|
||||
The system SHALL render key surfaces (header, hero, feed, modal, footer, policy modals, and floating controls) responsively across mobile, tablet, and desktop viewports while preserving readability, and SHALL verify these behaviors with browser-based regression tests.
|
||||
|
||||
#### Scenario: Mobile layout behavior
|
||||
- **WHEN** a user opens the site on a mobile viewport
|
||||
- **THEN** content remains readable without horizontal overflow
|
||||
- **AND** interactive controls including icon-only copy/back-to-top and policy modals 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
|
||||
|
||||
#### Scenario: Readability-focused typography and contrast updates
|
||||
- **WHEN** content is rendered in core reading surfaces
|
||||
- **THEN** typography and color choices improve baseline readability
|
||||
- **AND** updates remain compatible with responsive behavior across breakpoints
|
||||
|
||||
#### Scenario: Sticky shrinking glass header
|
||||
- **WHEN** user scrolls downward
|
||||
- **THEN** header remains sticky with slight height reduction, subtle elevation, and glass blur effect
|
||||
- **AND** controls remain readable and usable at all breakpoints
|
||||
|
||||
#### Scenario: Sticky footer does not overlap core reading zones
|
||||
- **WHEN** footer is sticky
|
||||
- **THEN** content remains readable and interactive controls are not obscured
|
||||
- **AND** mobile/tablet/desktop layouts stay overflow-safe
|
||||
|
||||
#### Scenario: Breakpoint regression matrix verification
|
||||
- **WHEN** Playwright responsive tests run across defined viewport classes
|
||||
- **THEN** no horizontal overflow, clipping, or unreachable controls are detected
|
||||
- **AND** sticky/floating controls retain expected behavior at each breakpoint
|
||||
@@ -0,0 +1,53 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Modal/footer exposes minimal icon-based share actions
|
||||
The system SHALL provide visible, accessible icon-only share actions for article permalinks on supported providers and SHALL verify interaction correctness with browser automation.
|
||||
|
||||
#### Scenario: Supported share providers
|
||||
- **WHEN** share controls are rendered
|
||||
- **THEN** icons for `X`, `WhatsApp`, and `LinkedIn` are displayed
|
||||
- **AND** activating an icon opens provider share flow with the article permalink
|
||||
|
||||
#### Scenario: Light-theme icon visibility
|
||||
- **WHEN** the site is in light mode
|
||||
- **THEN** share icons remain visibly distinguishable with accessible contrast
|
||||
- **AND** icon controls remain keyboard focusable
|
||||
|
||||
#### Scenario: Copy-link share action
|
||||
- **WHEN** a user activates the copy-to-clipboard share control
|
||||
- **THEN** the article permalink is written to clipboard
|
||||
- **AND** action succeeds without navigating away
|
||||
|
||||
#### Scenario: Share controls preserve state accessibility
|
||||
- **WHEN** interactive-state tests run across supported themes
|
||||
- **THEN** default, hover, focus-visible, and active states remain perceivable
|
||||
- **AND** accessible labels remain present for icon-only controls
|
||||
|
||||
### Requirement: Footer supports env-driven GitHub and contact links
|
||||
The system SHALL conditionally render GitHub and contact-email links from environment-backed configuration and keep their interactions stable across pointer and keyboard use.
|
||||
|
||||
#### Scenario: Config present
|
||||
- **WHEN** GitHub URL and contact email are configured
|
||||
- **THEN** footer renders both links as interactive controls
|
||||
|
||||
#### Scenario: Config absent
|
||||
- **WHEN** either value is missing
|
||||
- **THEN** corresponding footer control is hidden without breaking layout
|
||||
|
||||
#### Scenario: Contact link visible when configured
|
||||
- **WHEN** `CONTACT_EMAIL` is present in frontend config payload
|
||||
- **THEN** footer shows the contact email affordance
|
||||
- **AND** hover microcopy behavior remains enabled
|
||||
|
||||
### Requirement: Contact affordance provides randomized safe microcopy
|
||||
The contact link SHALL present randomized, policy-safe helper messages to encourage feedback, including keyboard-triggered visibility for accessibility.
|
||||
|
||||
#### Scenario: Randomized helper tooltip
|
||||
- **WHEN** user hovers or nears the contact affordance
|
||||
- **THEN** a tooltip-style helper message is shown from a predefined safe message pool
|
||||
- **AND** message language avoids profanity/offensive/racist/sexist/misogynistic content
|
||||
|
||||
#### Scenario: Keyboard-triggered helper tooltip
|
||||
- **WHEN** a keyboard user focuses the contact email affordance
|
||||
- **THEN** helper tooltip content becomes visible and readable
|
||||
- **AND** tooltip dismisses cleanly on blur without trapping focus
|
||||
@@ -0,0 +1,40 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Summary is rendered in a modal dialog using standard template
|
||||
The system SHALL render article summary content in a modal dialog using the required structure and SHALL preserve consistent behavior across entry paths validated by Playwright interaction tests.
|
||||
|
||||
#### Scenario: Open summary modal
|
||||
- **WHEN** a user triggers summary view for an article
|
||||
- **THEN** a modal dialog opens and displays content in this order: relevant image, TL;DR bullets, summary body, source and citation, and "Powered by Perplexity"
|
||||
- **AND** modal content corresponds to the selected article
|
||||
|
||||
#### Scenario: Close summary modal
|
||||
- **WHEN** a user closes the modal via close control or backdrop interaction
|
||||
- **THEN** the modal is dismissed cleanly
|
||||
- **AND** user returns to previous feed context without page navigation
|
||||
|
||||
#### Scenario: Permalink-driven modal open
|
||||
- **WHEN** page is loaded with a valid article permalink state
|
||||
- **THEN** the modal opens for the linked article without requiring manual click
|
||||
|
||||
#### Scenario: Keyboard dismissal and focus continuity
|
||||
- **WHEN** the modal is open and the user presses `Escape`
|
||||
- **THEN** the modal closes deterministically
|
||||
- **AND** focus returns to a stable, previously active control
|
||||
|
||||
### Requirement: Modal content preserves source link-out behavior
|
||||
The system SHALL provide source link-outs from the summary modal and keep share interactions stable.
|
||||
|
||||
#### Scenario: Source link-out from modal
|
||||
- **WHEN** a user clicks source/citation link in the modal
|
||||
- **THEN** the original source opens in a new tab/window
|
||||
- **AND** modal behavior remains stable for continued browsing
|
||||
|
||||
#### Scenario: Modal exposes share entry points
|
||||
- **WHEN** a summary modal is open for an article
|
||||
- **THEN** share controls for the article permalink are available from modal/footer share area
|
||||
|
||||
#### Scenario: Modal interaction regression coverage
|
||||
- **WHEN** Playwright modal-flow tests execute
|
||||
- **THEN** open/close/source/share interactions pass for hero-origin and feed-origin entry paths
|
||||
- **AND** regressions in modal ordering or interaction wiring are detected
|
||||
@@ -0,0 +1,24 @@
|
||||
## MODIFIED 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, including icon-only controls and policy-disclosure modals, and SHALL verify compliance through automated accessibility checks in CI and browser-driven interaction tests.
|
||||
|
||||
#### Scenario: Keyboard-only interaction flow
|
||||
- **WHEN** a keyboard-only user navigates policy modals and icon-only controls
|
||||
- **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** icon-only controls expose meaningful accessible labels
|
||||
|
||||
#### Scenario: Accessibility CI gate
|
||||
- **WHEN** pull request validation runs
|
||||
- **THEN** automated accessibility checks execute against key pages and flows
|
||||
- **AND** violations above configured severity fail the gate
|
||||
|
||||
#### Scenario: Playwright verifies interactive accessibility states
|
||||
- **WHEN** accessibility-focused Playwright tests execute
|
||||
- **THEN** focus-visible, keyboard traversal, and accessible-name assertions pass for critical controls
|
||||
- **AND** regressions in theme-specific contrast and state visibility are detected
|
||||
Reference in New Issue
Block a user