Process: re-enable frontend CI gate when web UI becomes active

[frankbria]

Problem

When the Phase 3 web UI became actively developed, the `frontend-tests` CI job was still disabled from the Phase 2 CLI-first refactor. This meant every PR that modified a web UI component could silently break its test — CI never caught it.

The result: 5 test suites failed, accumulated across at least 4 separate PRs over ~2 weeks:

Broken test	Broken by	Root cause
`QuickActions.test.tsx`	#493	Context-aware refactor changed all button labels
`TaskCard.test.tsx`	#524	`title` attribute replaced by Radix Tooltip
`TaskDetailModal.test.tsx`	#524	Dependency label changed from "2 dependencies"
`BlockerCard.test.tsx`	#531	Success message reworded
`TaskBoardView.test.tsx`	#499	Empty state redesigned with CTA

Fixed in PR #537 (re-enables the job, fixes all 5 tests, excludes Playwright e2e from Jest).

Recommendation

Add a rule to the development process (or CLAUDE.md): when a phase/feature area transitions from "inactive" to "active", check that its CI gate is enabled before the first PR lands.

In particular: if a CI job has a DISABLED: comment, re-enable it before doing active feature work in that area.

Prevention

Consider adding a CI check that detects commented-out jobs and warns when the corresponding code area is being modified. Or simply delete the disable comment and let CI fail early.

[traycerai]

Warning

Ticket Assist will be discontinued on May 1, 2026. After that date, the feature will no longer be available. We suggest installing the Traycer IDE Extension for continued AI-powered, spec-driven development. Thank you for choosing Traycer!

Plan

Observations

The frontend-tests CI job in file:.github/workflows/test.yml (lines 250–294) is fully commented out with a DISABLED: block. The five failing test files already exist in file:web-ui/__tests__/ and are well-written, but they were written against the current component implementations — meaning the tests themselves are already correct and the components already match them. The only work is:

1. Re-enabling the CI job.
2. Excluding Playwright e2e from Jest's testMatch (the test:e2e script in package.json uses Playwright, but jest.config.js has a broad testMatch that could pick up Playwright spec files).
3. Adding a process note to CLAUDE.md.

Approach

Re-enable the commented-out frontend-tests job, tighten Jest's testPathIgnorePatterns to exclude any Playwright files, wire frontend-tests into the test-summary job's needs array and its summary table, and add a one-paragraph process rule to CLAUDE.md. No source component changes are needed — the tests already match the current component code.

---

Implementation Steps

1. Re-enable the frontend-tests job in file:.github/workflows/test.yml

Uncomment the entire frontend-tests block (lines 250–294). The restored job should look like:

frontend-tests:
  name: Frontend Unit Tests
  runs-on: ubuntu-latest
  needs: code-quality

  steps:
    - Checkout code
    - Set up Node.js (node-version: ${{ env.NODE_VERSION }}, cache: 'npm', cache-dependency-path: 'web-ui/package-lock.json')
    - Install dependencies (working-directory: web-ui, run: npm ci)
    - Run Jest tests with coverage (working-directory: web-ui, run: npm run test:coverage)
    - Check coverage threshold (65%) — keep the existing shell block
    - Upload coverage reports (codecov-action@v4, flags: frontend)

Remove the DISABLED: comment block above it entirely.

---

2. Exclude Playwright test files from Jest in file:web-ui/jest.config.js

The current testMatch is broad (**/__tests__/**/*.[jt]s?(x)). Add a testPathIgnorePatterns entry to the customJestConfig object to prevent Jest from picking up any Playwright spec files (e.g., files under tests/e2e/ or files matching *.spec.ts that live outside __tests__):

• Add testPathIgnorePatterns to customJestConfig with entries for:
  • <rootDir>/node_modules/
  • <rootDir>/../tests/e2e/
  • Any playwright.config.* files

This ensures npm run test:coverage only runs Jest unit tests, not Playwright specs.

---

3. Update the test-summary job in file:.github/workflows/test.yml

• Add frontend-tests to the needs array of the test-summary job (currently needs: [backend-tests, code-quality, check-hardcoded-urls]).
• Add a row for Frontend Tests to the summary table step:

  echo "| Frontend Tests | ${{ needs.frontend-tests.result }} |" >> $GITHUB_STEP_SUMMARY
  

• Add needs.frontend-tests.result to the failure condition check in the same step.
• Remove the hardcoded "| Frontend Tests | skipped (v2 CLI-first) |" line.

---

4. Add a process rule to file:CLAUDE.md

In the "What NOT to do" section (around line 486), add a new bullet:

Don't leave a CI gate disabled when its feature area becomes active. If a CI job has a DISABLED: or # COMMENTED OUT: block, re-enable it before the first PR lands in that area. Specifically: when a phase transitions from "inactive" to "active", verify that frontend-tests (and any other gated jobs) are uncommented and wired into test-summary.

Also update the "Quality checks" section (around line 500) to note that npm run test:coverage in web-ui/ is now enforced by CI on every PR, not just manually.

---

Summary of changes

File	Change
file:.github/workflows/test.yml	Uncomment frontend-tests job; add it to test-summary needs and summary table
file:web-ui/jest.config.js	Add testPathIgnorePatterns to exclude Playwright e2e files
file:CLAUDE.md	Add process rule about re-enabling CI gates when a phase goes active

No source component files need to change — the five test suites already match the current component implementations.

Import In IDE

🤖 Prompt for AI Agents

## Observations

The `frontend-tests` CI job in `file:.github/workflows/test.yml` (lines 250–294) is fully commented out with a `DISABLED:` block. The five failing test files already exist in `file:web-ui/__tests__/` and are well-written, but they were written against the **current** component implementations — meaning the tests themselves are already correct and the components already match them. The only work is:
1. Re-enabling the CI job.
2. Excluding Playwright e2e from Jest's `testMatch` (the `test:e2e` script in `package.json` uses Playwright, but `jest.config.js` has a broad `testMatch` that could pick up Playwright spec files).
3. Adding a process note to `CLAUDE.md`.

## Approach

Re-enable the commented-out `frontend-tests` job, tighten Jest's `testPathIgnorePatterns` to exclude any Playwright files, wire `frontend-tests` into the `test-summary` job's `needs` array and its summary table, and add a one-paragraph process rule to `CLAUDE.md`. No source component changes are needed — the tests already match the current component code.

---

## Implementation Steps

### 1. Re-enable the `frontend-tests` job in `file:.github/workflows/test.yml`

Uncomment the entire `frontend-tests` block (lines 250–294). The restored job should look like:

```
frontend-tests:
  name: Frontend Unit Tests
  runs-on: ubuntu-latest
  needs: code-quality

  steps:
    - Checkout code
    - Set up Node.js (node-version: ${{ env.NODE_VERSION }}, cache: 'npm', cache-dependency-path: 'web-ui/package-lock.json')
    - Install dependencies (working-directory: web-ui, run: npm ci)
    - Run Jest tests with coverage (working-directory: web-ui, run: npm run test:coverage)
    - Check coverage threshold (65%) — keep the existing shell block
    - Upload coverage reports (codecov-action@v4, flags: frontend)
```

Remove the `DISABLED:` comment block above it entirely.

---

### 2. Exclude Playwright test files from Jest in `file:web-ui/jest.config.js`

The current `testMatch` is broad (`**/__tests__/**/*.[jt]s?(x)`). Add a `testPathIgnorePatterns` entry to the `customJestConfig` object to prevent Jest from picking up any Playwright spec files (e.g., files under `tests/e2e/` or files matching `*.spec.ts` that live outside `__tests__`):

- Add `testPathIgnorePatterns` to `customJestConfig` with entries for:
  - `<rootDir>/node_modules/`
  - `<rootDir>/../tests/e2e/`
  - Any `playwright.config.*` files

This ensures `npm run test:coverage` only runs Jest unit tests, not Playwright specs.

---

### 3. Update the `test-summary` job in `file:.github/workflows/test.yml`

- Add `frontend-tests` to the `needs` array of the `test-summary` job (currently `needs: [backend-tests, code-quality, check-hardcoded-urls]`).
- Add a row for Frontend Tests to the summary table step:
  ```
  echo "| Frontend Tests | ${{ needs.frontend-tests.result }} |" >> $GITHUB_STEP_SUMMARY
  ```
- Add `needs.frontend-tests.result` to the failure condition check in the same step.
- Remove the hardcoded `"| Frontend Tests | skipped (v2 CLI-first) |"` line.

---

### 4. Add a process rule to `file:CLAUDE.md`

In the **"What NOT to do"** section (around line 486), add a new bullet:

> **Don't leave a CI gate disabled when its feature area becomes active.** If a CI job has a `DISABLED:` or `# COMMENTED OUT:` block, re-enable it before the first PR lands in that area. Specifically: when a phase transitions from "inactive" to "active", verify that `frontend-tests` (and any other gated jobs) are uncommented and wired into `test-summary`.

Also update the **"Quality checks"** section (around line 500) to note that `npm run test:coverage` in `web-ui/` is now enforced by CI on every PR, not just manually.

---

### Summary of changes

| File | Change |
|---|---|
| `file:.github/workflows/test.yml` | Uncomment `frontend-tests` job; add it to `test-summary` `needs` and summary table |
| `file:web-ui/jest.config.js` | Add `testPathIgnorePatterns` to exclude Playwright e2e files |
| `file:CLAUDE.md` | Add process rule about re-enabling CI gates when a phase goes active |

No source component files need to change — the five test suites already match the current component implementations.

---

Execution Information

Branch: main
Commit: 6483895

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

🔗 Related PRs

#76 - Add dismissible warning banner to QualityGateStatus component [merged]
#93 - fix(e2e): Fix dashboard and metrics tests for tab-based UI rendering [merged]
#176 - feat: Create project selection home page [merged]
#211 - feat(dashboard): Add PhaseProgress component for phase visualization [merged]
#243 - fix(state): load tasks from API for returning users (#231) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!