rsc-universal 0.1.1

package/skills/analyze/evals/cases.yaml

@@ -0,0 +1,74 @@
+skill: analyze
+
+# Prompts that MUST load the `analyze` skill. `analyze` is the rsc-sdd
+# pre-implementation GATE: it cross-reads constitution vs spec vs plan vs tasks
+# and REPORTS gaps, contradictions, duplication, ambiguity and scope drift. It
+# never edits the artifacts and never writes code — the user resolves each
+# finding. Several prompts deliberately avoid the word "analyze" to test that
+# the intent (a consistency cross-check before coding) is what triggers.
+should_trigger:
+  - prompt: "The spec, plan and task list are all written — before I start coding, can you check they actually agree with each other?"
+    why: "Cross-reading spec/plan/tasks for agreement right before implementation is the exact job of the pre-implementation gate."
+
+  - prompt: "Did we miss any requirement? I want to know which spec requirements have no task behind them."
+    why: "Requirement coverage (spec -> plan -> tasks) and surfacing GAPs is analysis #2; the user is asking for the coverage map without naming the skill."
+
+  - prompt: "The plan mentions a Redis cache and a webhook handler that I don't remember being in the spec — is that scope creep?"
+    why: "Plan/task work that satisfies no spec requirement is DRIFT — analysis #3; this is the backward-mapping check phrased as 'scope creep'."
+
+  - prompt: "Run the consistency gate over the SDD artifacts for the checkout feature."
+    why: "Explicit request for the consistency gate across the SDD artifacts; the core trigger for this phase."
+
+  - prompt: "Our constitution says Postgres only, but I think the plan picked a different database somewhere — can you cross-check before we build?"
+    why: "Constitution compliance (analysis #1) plus contradiction detection between constitution and plan, explicitly before building."
+
+  - prompt: "Sanity-check the spec against the plan and tasks for me — I don't want to find contradictions halfway through implementing."
+    why: "Pre-implementation contradiction detection across the artifacts is the gate's purpose; 'halfway through implementing' is the cost analyze exists to avoid."
+
+  - prompt: "Before implement, is everything aligned? Give me a coverage map of requirements to tasks."
+    why: "Asking for alignment plus a requirement-to-task coverage map immediately before the implement phase is precisely the analyze hand-off."
+
+# NEAR-MISS prompts that must NOT load `analyze`. Each routes to the genuinely
+# correct sibling that exists in this repo. The recurring trap: anything that
+# RESOLVES, BUILDS, or RUNS rather than reports, and anything that inspects code
+# rather than the SDD planning artifacts.
+should_not_trigger:
+  - prompt: "The login test is failing with a 500 and I can't tell why — help me find the root cause."
+    route_to: "secure-coding"
+    why: "A failing test / runtime fault is root-cause debugging on code, not a planning-artifact cross-check; analyze never opens source files. (Routes to the nearest existing repo skill for the auth fault.)"
+
+  - prompt: "Run the lint, type-check and test suite and tell me if the FastAPI service is ready to ship."
+    route_to: "fastapi"
+    why: "Running lint/types/tests on built code is the post-implementation verification gate via the stack skill — analyze is pre-implementation and runs nothing."
+
+  - prompt: "Write the technical implementation plan for the payments feature from this spec."
+    route_to: "fastapi"
+    why: "Authoring the plan/architecture is plan-phase work delegated to the stack skill; analyze checks an existing plan, it does not write one."
+
+  - prompt: "Review this pull request diff for correctness bugs and cleanups."
+    route_to: "secure-coding"
+    why: "Adversarial review of a code diff is code review, not a constitution/spec/plan/tasks consistency report on planning artifacts."
+
+  - prompt: "Audit my workspace and set up 01-TOOLS and 02-DOCS with a Knowledge map."
+    route_to: "harness"
+    why: "Bootstrapping the workspace control plane is the harness's job; analyze only reads the SDD artifacts the harness's 02-DOCS layer happens to store."
+
+  - prompt: "Profile why the Postgres query in the dashboard is slow and propose an index."
+    route_to: "postgresdb"
+    why: "Query performance and indexing is database engineering on real code/SQL, not a pre-implementation artifact cross-check."
+
+# Concrete tasks the skill should guide, with a rubric to grade WITH vs WITHOUT
+# the skill loaded. A correct skill-guided answer reports and routes; an
+# ungrounded answer typically starts editing artifacts or jumps to coding.
+capability:
+  - scenario: "I have constitution.md, a spec, a plan and a task list under 02-DOCS/wiki/sdd/ for a 'team invites' feature. The constitution says 'Postgres only, every endpoint rate-limited'. The spec requires email invites with a 5/min rate limit and invite expiry after 7 days. The plan adds a Redis-backed cache nobody asked for and is silent on rate limiting. The tasks cover sending invites and expiry but have no task for rate limiting and no done-check on the expiry task. Run the gate."
+    must_include:
+      - "Reports only and resolves nothing: explicitly does NOT edit the spec/plan/tasks and writes no code; hands each finding back to the user to resolve."
+      - "Reads the harness accompaniment dial from 02-DOCS/wiki/harness/user-profile.md and adapts report verbosity (or notes no profile and defaults to L2)."
+      - "Runs all six analyses (constitution compliance, coverage, scope drift, contradiction, duplication, ambiguity), not just coverage."
+      - "Flags the missing rate-limit task as a coverage GAP and as a CONSTITUTION violation (constitution requires every endpoint rate-limited) — marks it CRITICAL/HIGH and routes it to the tasks/plan phase."
+      - "Flags the Redis cache as scope DRIFT (no spec requirement behind it) and notes the resolution is the user's call: cut it or amend the spec."
+      - "Flags the expiry task's missing done-check as AMBIGUOUS and routes it to the tasks phase; flags any vague requirement to clarify."
+      - "Builds a requirement-coverage map (REQ -> plan section -> task -> status) marking covered / GAP / DRIFT / AMBIGUOUS."
+      - "Emits a verdict line (GATE: BLOCKED here, with CRITICAL/HIGH counts) and writes the report to 02-DOCS/wiki/sdd/analysis/<slug>.md indexed in the Knowledge map."
+      - "Ends by pointing to the next phase: route the blocking findings back to their owning phases, resolve, re-run analyze; only on PASS proceed to implement."

package/skills/angular/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: angular
+description: "Use when building, refactoring, reviewing, or debugging an Angular app (Angular 20/21+: standalone components, signals, zoneless change detection, the @if/@for/@defer built-in control flow, inject() DI, resource()/httpResource(), RxJS interop, NgRx SignalStore, the ng CLI). Triggers: 'why isn't my view updating', migrating NgModules to standalone, replacing *ngFor with @for, decorator inputs vs input() signals, 'monta una app Angular', 'componente standalone con signals', 'com passo a zoneless', going zoneless / removing Zone.js, app.config.ts providers, toSignal/toObservable interop, ng generate/ng update. NOT React (that is react), NOT Next.js (that is nextjs), NOT a plain TypeScript language question (that is typescript)."
+tags: [angular, frontend, web, signals, typescript, spa]
+recommends: [typescript, testing-web, secure-coding]
+origin: risco
+---
+
+# Angular — Standalone, Signals, Zoneless (Angular 20/21+)
+
+> Build Angular the way it ships in 2026: standalone components, signals as the reactivity model, zoneless change detection, built-in control flow, and `inject()` DI. Treat NgModules, `*ngFor`, and `@Input()` decorators as legacy you only touch to migrate.
+
+## When to use
+
+- Creating or editing Angular components, directives, services, guards, resolvers, interceptors, or routes.
+- Anything touching `angular.json`, the `ng` CLI, `main.ts` bootstrap, `app.config.ts`, or `provide*()` providers.
+- Deciding signals vs RxJS, or migrating decorators/NgModules to standalone + signals.
+- Wiring data fetching with `httpResource()`/`resource()` or `HttpClient` + RxJS.
+- Debugging zoneless change detection, `OnPush`, or "view not updating" bugs.
+- State with NgRx SignalStore or plain signal services; reactive/typed forms; route-bound signal inputs.
+
+## When NOT to use
+
+- **AngularJS (1.x)** — out of scope entirely. This skill is Angular 2+ only; the APIs do not map.
+- **React** → that is the `react` skill. NOT React (that is react).
+- **Next.js App Router** → `../nextjs/SKILL.md`.
+- **Vue/Nuxt, Svelte, SolidJS, Astro** → `vue-nuxt`, `svelte`, `solid-js`, `../astro/SKILL.md`.
+- **Pure TypeScript language question** (generics, narrowing, tsconfig) with no Angular dimension → `../typescript/SKILL.md`.
+- **A standalone NestJS API** → `../nestjs/SKILL.md`. A generic Node service → `nodejs`. Angular Universal SSR itself stays here.
+- **Cross-framework Playwright e2e strategy** → `testing-web` / `e2e-testing`. Angular's own `ng test` (Vitest) setup stays here.
+
+## Decide first
+
+| Situation | Do this | Why |
+|-----------|---------|-----|
+| Greenfield app / new feature | Zoneless + signals + standalone by default. `ng new` (Angular 21) already excludes Zone.js. | The defaults shipped stable in v20-v21; fight them and you write more code that the framework now does for you. |
+| Brownfield NgModule + decorator app | Migrate incrementally with schematics; do not rewrite. Keep Zone.js until you flip it on purpose. | A working app that uses `*ngIf` is not a bug. Churn introduces risk for no user value. |
+| "View not updating" complaint | Jump to the change-detection section: signal not read in template, `OnPush` without a signal, or stale Zone.js assumption. | Zoneless means a mutation that no signal observes will never repaint — the fix is structural, not a `detectChanges()` call. |
+
+## The modern baseline
+
+No NgModules. Bootstrap a standalone root component and configure providers in `app.config.ts`.
+
+```typescript
+// main.ts
+import { bootstrapApplication } from '@angular/platform-browser';
+import { App } from './app/app';
+import { appConfig } from './app/app.config';
+
+bootstrapApplication(App, appConfig);
+```
+
+```typescript
+// app/app.config.ts
+import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';
+import { provideRouter } from '@angular/router';
+import { provideHttpClient, withFetch } from '@angular/common/http';
+import { routes } from './app.routes';
+
+export const appConfig: ApplicationConfig = {
+  providers: [
+    provideZonelessChangeDetection(), // no Zone.js; CD driven by signals + events
+    provideRouter(routes),
+    provideHttpClient(withFetch()),
+  ],
+};
+```
+
+- Rule: one `bootstrapApplication` call, providers in `app.config.ts`. Why: NgModule bootstrap (`platformBrowserDynamic().bootstrapModule(AppModule)`) is the legacy path — more files, slower to reason about.
+- Rule: components are `standalone` by default (the `standalone` flag is implied in v20+; do not write `standalone: true` in new code, and never write `standalone: false`). Why: standalone is the framework default now; the flag is noise.
+
+**Bad → Good**
+
+```typescript
+// Bad — NgModule wiring for a single component
+@NgModule({ declarations: [UserCard], imports: [CommonModule], exports: [UserCard] })
+export class UserCardModule {}
+
+// Good — standalone component imports only what it uses
+@Component({
+  selector: 'app-user-card',
+  imports: [DatePipe],
+  template: `<p>{{ joined() | date }}</p>`,
+})
+export class UserCard {
+  joined = input.required<Date>();
+}
+```
+
+## Signals as the reactivity model
+
+`signal()` holds state, `computed()` derives it, `effect()` runs side effects, `linkedSignal()` resets writable state when a source changes.
+
+```typescript
+import { signal, computed, effect, linkedSignal } from '@angular/core';
+
+const qty = signal(1);
+const price = signal(9.99);
+const total = computed(() => qty() * price());        // derived — recomputes lazily
+const draftQty = linkedSignal(() => qty());            // writable, resets when qty changes
+
+effect(() => console.log('total changed:', total())); // side effect ONLY (logging, DOM, sync)
+```
+
+- Rule: derive with `computed()`, never with `effect()`. Why: an `effect()` that writes a signal to "compute" a value creates a hidden dependency graph that loops or fires extra times — `computed()` is pull-based and memoized.
+- Rule: `effect()` is for side effects (logging, `localStorage`, imperative DOM, 3rd-party libs), not for keeping two signals in sync. Why: synced state belongs in `computed()` or `linkedSignal()`.
+
+Component I/O is signal-based: `input()`, `input.required()`, `output()`, `model()` for two-way.
+
+**Bad → Good**
+
+```typescript
+// Bad — decorator I/O, mutable, no type-safety on required
+@Input() userId!: string;
+@Output() saved = new EventEmitter<User>();
+
+// Good — signal inputs/outputs
+userId = input.required<string>();          // read as userId()
+saved = output<User>();                     // emit with saved.emit(user)
+name = model('');                           // two-way: [(name)]="..."
+```
+
+## Templates: built-in control flow
+
+Use `@if` / `@for` / `@switch` / `@defer`. The legacy `*ngIf` / `*ngFor` / `*ngSwitch` structural directives are deprecated.
+
+```html
+@if (user(); as u) {
+  <h1>{{ u.name }}</h1>
+} @else {
+  <app-spinner />
+}
+
+@for (item of items(); track item.id) {
+  <li>{{ item.label }}</li>
+} @empty {
+  <li>No items</li>
+}
+
+@defer (on viewport) {
+  <app-heavy-chart [data]="rows()" />
+} @placeholder {
+  <div class="skeleton"></div>
+}
+```
+
+- Rule: every `@for` **must** declare `track`. Why: it is required syntax (the template won't compile without it) and it controls DOM reuse — `track item.id` over `track $index` when items have stable identity, or the DOM thrashes on reorder.
+- Rule: reach for `@defer` to lazy-load heavy sub-trees and enable incremental hydration. Why: it ships less JS up front without manual `loadComponent` plumbing.
+
+**Bad → Good**
+
+```html
+<!-- Bad — legacy structural directive, no tracking -->
+<li *ngFor="let item of items">{{ item.label }}</li>
+
+<!-- Good — built-in control flow with track -->
+@for (item of items(); track item.id) { <li>{{ item.label }}</li> }
+```
+
+## Data fetching
+
+Default to signal-based resources; reach for `HttpClient` + RxJS only when you need streams, cancellation, or operator composition.
+
+```typescript
+import { httpResource } from '@angular/common/http';
+import { resource } from '@angular/core';
+
+// httpResource — declarative GET wired to HttpClient; reactive to its URL signal
+users = httpResource<User[]>(() => `/api/users?team=${this.team()}`);
+// template: @if (users.isLoading()) {…} @else { @for (u of users.value(); track u.id) {…} }
+// users.error()  -> error signal;  users.reload() -> refetch
+
+// resource — any async loader (not just HTTP)
+profile = resource({
+  params: () => ({ id: this.userId() }),
+  loader: ({ params }) => fetchProfile(params.id),
+});
+```
+
+- Rule: `httpResource()`/`resource()` give you `value()`, `isLoading()`, `error()`, `reload()` for free — prefer them over a manual `subscribe` that you have to clean up. Why: less boilerplate, no leak, refetches automatically when its source signals change.
+- Rule: when you genuinely need a stream (websocket, debounced search, retry/switchMap), keep `HttpClient` + RxJS and bridge to a signal with `toSignal()`. Why: signals are not streams; do not fake backpressure with effects. See `references/signals-rxjs.md`.
+
+## DI & services
+
+```typescript
+@Injectable({ providedIn: 'root' })
+export class UserApi {
+  private http = inject(HttpClient);          // field initializer — no constructor needed
+  list = () => this.http.get<User[]>('/api/users');
+}
+```
+
+- Rule: inject with `inject()`, not constructor parameters. Why: `inject()` works in field initializers and composes into plain functions (guards, factories); constructor DI is the legacy ergonomic.
+- Rule: `providedIn: 'root'` for app-wide singletons. Why: tree-shakable — unused services drop from the bundle.
+- Rule: HTTP cross-cutting concerns are functional interceptors: `provideHttpClient(withInterceptors([authInterceptor]))`. Why: class interceptors with `HTTP_INTERCEPTORS` are the older multi-provider pattern.
+
+## Routing
+
+```typescript
+// app.routes.ts
+export const routes: Routes = [
+  { path: 'users', loadComponent: () => import('./users/users-list').then(m => m.UsersList) },
+  { path: 'users/:id', loadComponent: () => import('./users/user-detail').then(m => m.UserDetail),
+    canActivate: [authGuard] },
+];
+
+export const authGuard: CanActivateFn = () => inject(AuthService).isLoggedIn();
+```
+
+Enable route-bound signal inputs with `withComponentInputBinding()` in `provideRouter`, then read route params as signal inputs:
+
+```typescript
+provideRouter(routes, withComponentInputBinding());
+// in UserDetail: id = input.required<string>();  // bound from the :id segment
+```
+
+- Rule: lazy-load routes with `loadComponent` (or `loadChildren` with a routes array). Why: smaller initial bundle, no NgModule needed.
+- Rule: guards/resolvers are functions (`CanActivateFn`, `ResolveFn`) using `inject()`. Why: class-based guards are deprecated.
+
+## State
+
+- Local/feature state → a signal service (`@Injectable` holding `signal`/`computed`). Simple, no library.
+- App-wide state → **NgRx SignalStore** (`signalStore`, `withState`, `withComputed`, `withMethods`, `withProps`) — signals-native, pairs cleanly with `resource()`.
+
+```typescript
+export const CartStore = signalStore(
+  { providedIn: 'root' },
+  withState({ items: [] as Item[] }),
+  withComputed(({ items }) => ({ count: computed(() => items().length) })),
+  withMethods((store) => ({ add: (i: Item) => patchState(store, s => ({ items: [...s.items, i] })) })),
+);
+```
+
+- Note: **Signal Forms** is experimental (prototype since Angular 21.0.0-next.2). For production forms use reactive/typed forms (`FormGroup`/`FormControl` with typed values). Why: do not ship a prototype API to users.
+
+## CLI workflow
+
+```bash
+ng new my-app                  # Angular 21: zoneless + standalone + Vitest by default
+ng generate component user-card # standalone by default; no --standalone flag needed
+ng generate service user-api
+ng build                       # production build
+ng test                        # Vitest (default runner in v21; Karma is deprecated)
+ng update @angular/core @angular/cli  # version bumps + automated migrations
+```
+
+## Testing
+
+Use Vitest + `TestBed`. Provide zoneless CD in tests and set signal inputs via `componentRef`.
+
+```typescript
+import { TestBed } from '@angular/core/testing';
+import { provideZonelessChangeDetection } from '@angular/core';
+
+it('renders the user name', async () => {
+  TestBed.configureTestingModule({
+    providers: [provideZonelessChangeDetection()],
+  });
+  const fixture = TestBed.createComponent(UserCard);
+  fixture.componentRef.setInput('joined', new Date('2026-01-01'));
+  await fixture.whenStable();                       // not detectChanges() — let CD settle
+  expect(fixture.nativeElement.textContent).toContain('2026');
+});
+```
+
+- Rule: set signal inputs with `fixture.componentRef.setInput('name', value)`, never by poking the instance field. Why: `setInput` flows through the input pipeline and marks the view dirty.
+- Rule: prefer `await fixture.whenStable()` over manual `detectChanges()` loops under zoneless. Why: it waits for the scheduler to flush instead of forcing a single synchronous pass.
+
+## Anti-patterns
+
+| Bad | Why it's wrong | Good |
+|-----|----------------|------|
+| `@NgModule` in new code | Standalone is the default; modules add ceremony and slow analysis | Standalone component with an `imports: []` array |
+| `*ngIf` / `*ngFor` / `*ngSwitch` | Legacy structural directives; deprecated | `@if` / `@for (… ; track id)` / `@switch` |
+| `@Input()` / `@Output()` decorators | No required-input safety, not signal-reactive | `input()` / `input.required()` / `output()` / `model()` |
+| `effect(() => this.total.set(a()*b()))` | Effect-to-derive-state loops and double-fires | `total = computed(() => a()*b())` |
+| `@for` without `track` | Won't compile; if forced, DOM thrashes on reorder | `track item.id` (stable identity) |
+| `subscribe()` in a component with no teardown | Memory leak; runs after the view is destroyed | `toSignal()` or `takeUntilDestroyed()` |
+| `ChangeDetectorRef.detectChanges()` to "fix" a stale view | Masks the real cause under zoneless | Read the value through a signal so CD tracks it |
+| Nested `subscribe()` inside `subscribe()` | Callback pyramid, lost cancellation | `switchMap`/`concatMap`, one subscription |
+| Constructor DI only (`constructor(private x: X)`) | Legacy ergonomic; can't compose into functions | `private x = inject(X)` |
+
+## References
+
+- `references/signals-rxjs.md` — signals-vs-RxJS decision matrix, `toSignal`/`toObservable` interop recipes, `effect` pitfalls (infinite loops, untracked reads), `linkedSignal`/`resource()` patterns, `takeUntilDestroyed`.
+- `references/migration.md` — incremental migration checklist + schematics: NgModule→standalone, control-flow migration, decorator-input→signal-input, Zone.js→zoneless go-live, Karma/Jasmine→Vitest.
+
+`scripts/verify.sh` is a heuristic copy-banlist lint — it greps your Angular sources for the banned patterns above. It is a hint, not a compiler.

package/skills/angular/evals/README.md

@@ -0,0 +1,3 @@
+# angular evals
+
+Trigger and capability checks for modern Angular work.

package/skills/angular/evals/cases.yaml

@@ -0,0 +1,38 @@
+skill: angular
+
+should_trigger:
+  - prompt: "Migrate this Angular app from NgModules to standalone components."
+    why: "Standalone migration is central modern Angular work."
+  - prompt: "Why is my Angular view not updating in zoneless mode?"
+    why: "Zoneless change detection and signals are Angular-specific."
+  - prompt: "Replace *ngFor with @for and track expressions."
+    why: "Built-in control flow migration belongs to Angular."
+  - prompt: "Use input() signals instead of decorator @Input in this component."
+    why: "Signal inputs are Angular-specific."
+  - prompt: "Monta una app Angular con componente standalone y signals."
+    why: "Spanish Angular standalone/signals request triggers this skill."
+
+should_not_trigger:
+  - prompt: "Fix a React hook state bug."
+    route_to: "react"
+    why: "React hooks are not Angular."
+  - prompt: "Implement a Next.js server component."
+    route_to: "nextjs"
+    why: "Next.js App Router/RSC is a separate stack."
+  - prompt: "Explain TypeScript conditional types."
+    route_to: "typescript"
+    why: "Pure TypeScript without Angular belongs to TypeScript."
+  - prompt: "Build a NestJS backend module."
+    route_to: "nestjs"
+    why: "NestJS is backend DI; Angular is frontend framework."
+
+capability:
+  - scenario: "A brownfield Angular app uses NgModules, decorator inputs and Zone.js; the user wants a safe modern migration."
+    must_include:
+      - "Detects Angular version and brownfield vs greenfield before changing architecture."
+      - "Migrates incrementally to standalone components rather than rewriting everything."
+      - "Uses signals/input() and built-in @if/@for/@defer control flow where appropriate."
+      - "Explains zoneless change detection and avoids detectChanges() as a default patch."
+      - "Keeps providers in app.config.ts/provide* APIs for modern bootstrap."
+      - "Uses RxJS interop deliberately with toSignal/toObservable when needed."
+      - "Routes pure TypeScript or backend NestJS questions to those skills."

package/skills/angular/references/migration.md

@@ -0,0 +1,81 @@
+# Incremental migration — legacy Angular → standalone, signals, zoneless
+
+Migrate a working app in small reversible steps. Each step has an official schematic; run them
+one at a time, commit, and verify the app still builds and tests pass before the next.
+
+## Order of operations
+
+1. Update Angular first, then migrate. `ng update @angular/core @angular/cli` runs the
+   bundled migrations for the version you land on. Do not migrate APIs on an old major.
+2. Standalone components/directives/pipes.
+3. Built-in control flow (`*ngIf`/`*ngFor` → `@if`/`@for`).
+4. Signal inputs/outputs.
+5. Zoneless (last — it has the widest blast radius).
+6. Test runner (Karma/Jasmine → Vitest), independently of the above.
+
+## 1. NgModule → standalone
+
+```bash
+ng generate @angular/core:standalone
+```
+
+Run it three times, choosing each mode in turn:
+- *Convert all components, directives and pipes to standalone*
+- *Remove unnecessary NgModule classes*
+- *Bootstrap the application using standalone APIs* (rewrites `main.ts` to `bootstrapApplication`)
+
+After the last pass you should have an `app.config.ts` with `provideRouter`,
+`provideHttpClient`, etc. Delete the now-empty `AppModule`.
+
+## 2. Control flow: *ngIf / *ngFor → @if / @for
+
+```bash
+ng generate @angular/core:control-flow
+```
+
+This rewrites templates automatically. Review every converted `@for`: the schematic inserts a
+`track` expression (often `track $index` as a safe default). Replace `$index` with a stable key
+(`track item.id`) wherever items have identity, so the DOM reuses nodes on reorder. Once
+converted you can drop `CommonModule` imports that only existed for the directives.
+
+## 3. Decorator inputs/outputs → signals
+
+```bash
+ng generate @angular/core:signal-input-migration
+ng generate @angular/core:output-migration
+ng generate @angular/core:signal-queries-migration   # @ViewChild/@ContentChild -> viewChild()/contentChild()
+```
+
+What changes for callers inside the class:
+- `this.userId` (a value) becomes `this.userId()` (a signal read). The migration updates
+  template and class reads, but check any code that assigned to the field — signal inputs are
+  read-only; lift writable state into a separate `signal()` or use `model()` for two-way.
+- `@Output() saved = new EventEmitter()` → `saved = output()`, emit with `saved.emit(x)`.
+
+## 4. Zone.js → zoneless go-live checklist
+
+Flip this last, after signals and control flow are in place.
+
+- [ ] Add `provideZonelessChangeDetection()` to the app providers (and to test providers).
+- [ ] Remove `provideZoneChangeDetection()` if present.
+- [ ] Delete the `zone.js` import from `polyfills`/`main.ts`; remove `zone.js` from
+      `package.json` and the `polyfills` entry in `angular.json`.
+- [ ] Audit every component for state read in the template that is **not** a signal — under
+      zoneless, a plain field mutated outside an event handler will not repaint. Convert it to a
+      `signal()`, or ensure the change originates from a tracked source (signal, async pipe,
+      template event, router).
+- [ ] Replace any `setTimeout`/`Promise`/3rd-party-callback that mutates view state with a
+      signal write, or call `ChangeDetectorRef.markForCheck()` from inside it.
+- [ ] Search for `ChangeDetectorRef.detectChanges()` "fix-it" calls and the `NgZone.run()`
+      escape hatch — both are smells that some state isn't a signal yet.
+- [ ] Run the app and click through; watch for views that update only on the *next* unrelated
+      interaction (the classic zoneless-miss symptom).
+
+## 5. Karma/Jasmine → Vitest
+
+New Angular 21 projects use Vitest by default. For an existing project, switch the test builder
+to the Vitest-based runner in `angular.json` and migrate specs: Jasmine's `spyOn`/`jasmine.
+createSpy` map to Vitest's `vi.fn`/`vi.spyOn`, and `expect().toHaveBeenCalled()` etc. are
+compatible. Keep `TestBed`; only the runner and the mocking API change. Add
+`provideZonelessChangeDetection()` to test module providers and prefer `await
+fixture.whenStable()` over manual `detectChanges()` loops.

package/skills/angular/references/signals-rxjs.md

@@ -0,0 +1,92 @@
+# Signals vs RxJS — when to use which, and how to bridge
+
+Signals and RxJS coexist in modern Angular. Signals are the default for UI state and
+synchronous derivation; RxJS still owns asynchronous *streams* of events over time.
+
+## Decision matrix
+
+| You have… | Use | Why |
+|-----------|-----|-----|
+| A piece of UI state read in a template | `signal()` | Pull-based, glitch-free, drives zoneless CD directly |
+| A value derived from other state | `computed()` | Memoized, lazy, no manual subscription |
+| One async fetch tied to inputs | `httpResource()` / `resource()` | Gives `value/isLoading/error/reload`, auto-refetch, no leak |
+| A stream over time (websocket, key events, intervals) | RxJS `Observable` | Signals are values-now, not events-over-time |
+| Debounce / throttle / retry / cancel-in-flight | RxJS (`debounceTime`, `switchMap`, `retry`) | These are stream operators; signals have no time dimension |
+| A writable copy that resets when a source changes | `linkedSignal()` | Purpose-built; avoids an effect-to-sync anti-pattern |
+
+Rule of thumb: **state → signals, events → observables.** When in doubt, start with a signal;
+escalate to RxJS only when you need an operator that models time.
+
+## Interop
+
+`toSignal()` and `toObservable()` are the two bridges (`@angular/core/rxjs-interop`).
+
+```typescript
+import { toSignal, toObservable, takeUntilDestroyed } from '@angular/core/rxjs-interop';
+
+// Observable -> Signal: subscribe is managed for you; unsubscribes on destroy.
+private search = signal('');
+results = toSignal(
+  toObservable(this.search).pipe(
+    debounceTime(300),
+    switchMap(q => this.api.search(q)),  // switchMap cancels the prior request
+  ),
+  { initialValue: [] as Result[] },
+);
+```
+
+- `toSignal(obs$, { initialValue })` — read `results()` in the template; the subscription is
+  cleaned up automatically when the injection context is destroyed.
+- `toObservable(sig)` — turn a signal into a stream so you can apply operators. It emits on the
+  microtask queue, not synchronously.
+- `takeUntilDestroyed()` — for the rare hand-rolled subscription, this completes it when the
+  component/service is destroyed. Use it instead of a manual `Subscription` + `ngOnDestroy`.
+
+## effect() pitfalls
+
+`effect()` is for side effects, not derivation. Common ways it goes wrong:
+
+```typescript
+// Pitfall 1 — infinite loop: an effect that writes a signal it also reads.
+effect(() => this.count.set(this.count() + 1)); // re-runs forever
+
+// Pitfall 2 — using an effect to derive state. Use computed() instead.
+effect(() => this.total.set(this.qty() * this.price())); // double-fires, hidden graph
+// Fix:
+total = computed(() => this.qty() * this.price());
+
+// Pitfall 3 — wanting to write without creating a dependency: wrap in untracked().
+effect(() => {
+  const id = this.userId();           // tracked dependency
+  untracked(() => this.log.push(id)); // read/write here is NOT a dependency
+});
+```
+
+- An effect runs once on creation and again whenever any signal it *reads* changes.
+- Reading a signal inside `untracked(() => …)` does not register it as a dependency.
+- If you find yourself calling `.set()` from inside an effect to feed the template, you almost
+  certainly want `computed()` or `linkedSignal()`.
+
+## resource() / httpResource() patterns
+
+```typescript
+// Dependent fetch: the resource re-runs when team() changes.
+team = signal('eng');
+users = httpResource<User[]>(() => `/api/users?team=${this.team()}`);
+
+// Mutate then refresh:
+async addUser(u: User) {
+  await firstValueFrom(this.http.post('/api/users', u));
+  this.users.reload();
+}
+
+// Loading / error in the template:
+// @if (users.isLoading()) { <app-spinner/> }
+// @else if (users.error()) { <p>Failed</p> }
+// @else { @for (u of users.value(); track u.id) { … } }
+```
+
+- A `resource()` cancels the previous load when its `params` change (it passes an `AbortSignal`
+  to the loader) — use it for `fetch` cancellation without writing RxJS.
+- `httpResource()` is GET-oriented and reactive. For POST/PUT/DELETE keep `HttpClient` and call
+  `reload()` after the mutation.