Title: feat(filters): Angular CLI output optimization for ng build, ng serve, and modern ng test

Summary

RTK already does a great job reducing noisy CLI output before it reaches an AI coding agent's context. Angular projects look like a useful next area for first-class support because Angular CLI commands can produce build, compiler, test-runner, and dev-server output that is highly repetitive for an agent.

I found the existing issue for Angular Karma support: #2849 (Angular Karma ng test built-in filter/rewrite support). Rather than duplicate that scope, this issue proposes broader Angular CLI coverage focused on:

• ng build
• ng serve
• modern ng test output (Vitest)
• consistent rewrite/routing for common Angular invocation forms

Why this is useful

For an AI coding agent, the high-value Angular signal is usually much smaller than the raw CLI output:

• build success/failure
• compiler errors
• warnings
• budget violations
• bundle summary
• failing tests and relevant stack traces
• dev-server URL
• rebuild success/failure

The goal would be to preserve that signal while removing repetitive banners, progress output, and unchanged/pass noise.

Proposed commands

1. rtk ng build

Possible compact failure output:

ANGULAR BUILD FAILED

Errors: 2
  src/app/customer/customer.component.ts:42
    TS2339: Property 'customerName' does not exist

  src/app/services/api.service.ts:18
    TS2345: Argument of type ...

Warnings: 3
  1 budget warning

[full output: rtk recall <id>]

For successful builds, retain a concise summary such as:

• project/configuration
• build success
• initial/lazy bundle sizes
• budget warnings
• duration if available

2. rtk ng test

Angular's current default testing stack uses Vitest, while many existing projects still use Karma.

For Vitest, RTK could retain the existing failure-focused philosophy:

TESTS FAILED

Files: 39 passed, 3 failed
Tests: 381 passed, 6 failed

FAILURES
  customer.component.spec.ts
  customer.service.spec.ts
  ...

[full output: rtk recall <id>]

This would complement the existing Karma issue (#2849) rather than replace it.

3. rtk ng serve

This is a long-running command, so a streaming filter would be preferable rather than a post-process filter.

For example:

ANGULAR DEV SERVER

✓ Listening: http://localhost:4200/

✓ Build succeeded
  Initial: 2.1 MB

Change detected → rebuilding...

✗ BUILD FAILED
  src/app/customer/customer.component.ts:42
  TS2339: Property 'customerName' does not exist

Change detected → rebuilding...

✓ Build succeeded
  2.1 MB

The intent is to preserve meaningful rebuild/build failures while suppressing repeated dev-server and bundler noise.

Invocation / rewrite coverage

It would be useful for the routing layer to recognize common Angular CLI forms such as:

ng build
ng test
ng serve

yarn ng build
yarn ng test
npm run ng -- build

node_modules/.bin/ng build
node_modules/.bin/ng test

The existing Angular Karma issue already calls out path-based .bin/ng test and package-script invocation as important cases.

Implementation direction

This seems to fit RTK's existing architecture without introducing a new model or filtering layer.

Possible approach:

• add an Angular CLI command module/filter under the existing JS ecosystem
• route ng subcommands to dedicated handlers/filters
• use buffered filtering for ng build
• use a test-specific filter for ng test, with separate handling for Vitest/Karma as needed
• use a streaming filter for long-running ng serve
• preserve exit codes and full-output recovery via the existing recall mechanism
• add fixture-based tests for success, warnings, compiler failures, test failures, and repeated rebuild output

Suggested initial scope

1. rtk ng build
2. modern rtk ng test (Vitest)
3. rtk ng serve

Keep Angular Karma work under #2849.

Acceptance criteria

• ng build can be transparently routed through RTK and produce a compact, information-preserving result
• modern ng test (Vitest) can be routed through RTK with failures prioritized
• ng serve supports streaming output filtering without hiding important rebuild failures
• common ng / yarn ng / .bin/ng forms are recognized where appropriate
• full output remains recoverable when filtering or truncation occurs
• existing Angular Karma work in feat(filters): Angular Karma (ng test) built-in filter and rewrite support #2849 remains the source of truth for Karma-specific behavior
• non-Angular commands are unaffected

I think Angular is a good ecosystem extension for RTK because the opportunity is not just removing lines; the CLI output has enough structure to produce much more useful agent-facing summaries while keeping the underlying commands unchanged.