test(mwpw-184989): seed regressions to validate multi-page agent

[sanrai]

Throwaway validation PR. Seeds TWO deliberate regressions: (1) card titles truncated to one line (visual, should be flagged on the card pages + gallery), (2) OR filter returns zero results via tag.id->tag.name (functional, should be flagged on the left/top filter pages). The multi-page agent should run all 5 pages and flag these. Will be closed.

[github-actions]

🤖 Agent QA review — multi-page, interactive + visual diff (advisory, non-blocking)

Reviewed 1 page(s) on the live site with the PR build injected. Overall: FAIL.

FAIL — A-left-hub · 0.07% pixels changed · https://business.adobe.com/customer-success-stories.html

VERDICT: FAIL

QA Report – PR #536 OR-Filter Assertion

Target URL: https://business.adobe.com/customer-success-stories.html

---

Test Steps & Observations

STEP A – Baseline Count:

• Evaluated .consonant-FiltersInfo-results on page load.
• Baseline: 344 results

STEP B – Expand First Group:

• Found and clicked the "Products" group header button to expand it.
• Group expanded successfully; checkboxes became available in the DOM.

STEP C – Click First Checkbox (Acrobat):

• Clicked the first checkbox in the Products group, labeled "Acrobat".
• Checkbox was clicked via element.click() (confirmed by element ID 4x24/82so).

STEP D – Count After One Filter:

• Evaluated .consonant-FiltersInfo-results after selecting "Acrobat".
• Result: 0 results ← THIS IS THE BUG

STEP E – Click Second Checkbox (Acrobat Sign):

• Clicked the second checkbox, labeled "Acrobat Sign" (ID 4x24/kw5f).
• Count after two filters was not captured within the turn budget, but given Step D returned 0, the OR behavior is already broken.

---

Summary

State	Count
Baseline (no filters)	344 results
After selecting "Acrobat"	0 results
After selecting "Acrobat Sign"	Not captured

---

Reason for FAIL

After selecting a single valid filter checkbox ("Acrobat" in the Products group), the result count dropped to 0 results instead of narrowing to a non-zero subset of the 344 baseline results. This is the described bug: a single-filter selection should return a non-zero narrowed count, but instead returns zero — indicating the OR-filter logic is broken in this PR build. The OR-widening behavior (STEP E) cannot be validated because the foundation (non-zero single-filter result) already fails.

Per-page screenshots + diffs in the workflow run.

[github-actions]

AI Code Review

Issues Found

1. Incorrect Tag Matching Logic (Correctness Bug)

File: react/src/js/components/Consonant/Helpers/Helpers.js

- const tagIds = new Set(card.tags.map(tag => tag.id));
+ const tagIds = new Set(card.tags.map(tag => tag.name));

Problem: The active filters almost certainly store filter criteria by id (not name). The code downstream checks whether tagIds contains values from the active filters. If active filters use tag.id for matching (which is standard), changing the Set to use tag.name will cause all tag-based filtering to fail silently — cards will never match filters, or filters will match incorrectly if names happen to collide.

Action: Verify what values activeFilters stores for comparison. If they store id values (the typical pattern), revert this change. If name matching is intentional, ensure activeFilters was updated consistently to also store names — check all filter-building code paths.

---

2. CSS Line Clamp Reduction (Potential Content Truncation / Data Loss in UI)

File: less/components/consonant/cards/card.less

- .line-clamp(2);
+ .line-clamp(1);

This is lower severity, but if card titles are expected to wrap to 2 lines, reducing to 1 will silently truncate titles in the UI. This is a functional regression if titles commonly exceed one line, potentially hiding critical content from users. Confirm this is intentional.

[github-actions]

AI Code Review

Issues Found

Critical Bug: Filter Logic Broken (Helpers.js)

Line: const tagIds = new Set(card.tags.map(tag => tag.name));

Changing tag.id to tag.name will break tag matching. The active filters almost certainly store filter values by id, not name. The comparison downstream (checking if tagIds contains filter tag identifiers) will fail silently — cards that should be filtered out will pass through, or cards that should appear will be excluded.

Action: Verify what property the active filter tags use for matching. If filters reference tag.id, this must be reverted to tag.id. If a migration to tag.name is intentional, the filter panel/active filter state must also be updated atomically in this same PR to use name as the identifier — otherwise filter functionality is broken.

---

Potential Issue: CSS Change (card.less)

Changing .line-clamp(2) to .line-clamp(1) truncates card titles to a single line. This is a visual regression risk — any card with a two-line title will have content silently cut off with no way for the user to see the full title. Confirm this is intentional and that truncated titles are accessible (e.g., via title attribute or tooltip).

[github-actions]

AI Code Review

Critical Issues

tag.id → tag.name in getFilteredCards (Helpers.js)

Severity: High — Correctness Bug / Broken Logic

- const tagIds = new Set(card.tags.map(tag => tag.id));
+ const tagIds = new Set(card.tags.map(tag => tag.name));

Problem: Filter matching almost certainly relies on comparing tag identifiers (IDs) against filter criteria. Tag names are human-readable strings (e.g., "Adobe Photoshop") while activeFilters/activePanels would contain IDs (e.g., "caas:product/photoshop"). This change will break all filtering — cards that should match filters will no longer match, causing filtered results to return nothing or incorrect sets.

Action: Revert to tag.id unless there is explicit evidence that activeFilters stores tag names instead of IDs, and verify the downstream has() checks use the same property consistently.

---

line-clamp(2) → line-clamp(1) (card.less, three-fourth.less)

Severity: Medium — Data Loss / UX Breakage

Reducing the clamp from 2 lines to 1 line truncates card titles to a single line. For cards with longer titles, meaningful content will be hidden with no way for users to see it. This is a functional regression — it's not a style preference, it affects readability and accessibility of card titles.

Action: Confirm this is intentional per design spec. If so, verify &:only-child max-height calculation in three-fourth.less (still set to 1.375rem * 4) is updated to match the new 1-line clamp — it's now inconsistent.

[github-actions]

AI Code Review

Critical Issues

1. Correctness Bug / Broken Filtering Logic — Helpers.js

- const tagIds = new Set(card.tags.map(tag => tag.id));
+ const tagIds = new Set(card.tags.map(tag => tag.name));

This changes the filter matching key from tag.id to tag.name. The active filters (populated from activeFilters/activePanels) almost certainly store filter values by id, not name. Matching filter IDs against tag names will cause mismatches, breaking all tag-based filtering (cards will either never match or match incorrectly). This is the likely root cause of the "zero results after filtering" bug the QA step is testing for — but the fix goes the wrong direction unless the filter values were also changed to use name everywhere, which is not shown in this diff.

Verify: Confirm that activeFilters / activePanels values are populated with tag.name (not tag.id) throughout the codebase. If they still use id, this change will completely break filtering.

---

2. Visual Regression / Data Truncation — card.less, three-fourth.less

- .line-clamp(2);
+ .line-clamp(1);

Reducing line clamp from 2 to 1 truncates card titles and content to a single line. This is a functional regression if titles are expected to wrap (e.g., long titles silently truncated in production UI). Combined with the :only-child rule in three-fourth.less setting max-height: 1.375rem * 4, the single-line clamp is inconsistent with the max-height allowing 4 lines — the CSS becomes contradictory for the only-child case.

[github-actions]

AI Code Review

Critical Issues

1. Breaking Bug: Filter matching changed from tag.id to tag.name — Helpers.js

- const tagIds = new Set(card.tags.map(tag => tag.id));
+ const tagIds = new Set(card.tags.map(tag => tag.name));

Filter logic compares card tags against activeFilters, which are keyed by tag ID (e.g., "caas:products/acrobat"). Switching to tag.name (e.g., "Acrobat") means the set intersection will never match, causing all filtered results to return zero cards for any active filter.

This is likely the bug the new QA test in agent-review.mjs is designed to detect ("Zero or 'No results' after one normal filter is THE BUG") — but the fix goes in the wrong direction. The change introduces the bug rather than fixing it.

Action: Revert to tag.id unless activeFilters has been simultaneously changed to match by name (no such change is present in this diff).

---

2. Hardcoded page selection overrides all filter logic — agent-review.mjs

- if (selected.length === 0) selected = [PAGES[0]];
+ selected = [PAGES[0]]; // TEMP: single-page validation (revert before scaling)

This unconditionally forces only PAGES[0] regardless of what files changed, making the CI review permanently incomplete for all other page types. If merged without reverting, PRs touching B-top-panel, C-search, etc. will never be QA-tested. The comment says "revert before scaling" but there is no enforcement mechanism.

Action: Do not merge with this hardcoded override. Revert to the conditional fallback.