dev-booster 1.18.0 → 1.18.1

package/template/.devbooster/hub/knowledge/angular-patterns.md

@@ -0,0 +1,185 @@
+# Angular Patterns for Modern Applications
+
+> **Purpose:** Provide practical defaults for modern Angular applications.
+> **Primary official sources:** [Angular Overview](https://angular.dev/overview) · [Version Compatibility](https://angular.dev/reference/versions) · [Angular CLI](https://angular.dev/cli)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing abstractions, configuration, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+Practical defaults for current Angular applications. Prefer APIs documented at [angular.dev](https://angular.dev/) and verify framework, CLI, TypeScript, and RxJS support before an upgrade.
+
+## Contents
+
+- [1. Standalone composition and providers](#1-standalone-composition-and-providers)
+- [2. Dependency injection scopes](#2-dependency-injection-scopes)
+- [3. Signals and RxJS boundaries](#3-signals-and-rxjs-boundaries)
+- [4. Templates and change detection](#4-templates-and-change-detection)
+- [5. Reactive forms and validation](#5-reactive-forms-and-validation)
+- [6. HTTP interceptors and errors](#6-http-interceptors-and-errors)
+- [7. Lazy routes and guards](#7-lazy-routes-and-guards)
+- [8. Version, CLI, and TypeScript alignment](#8-version-cli-and-typescript-alignment)
+
+## 1. Standalone composition and providers
+
+**Problem:** New features depend on large shared modules, making dependencies and lazy-loading boundaries unclear.
+
+**Fix:** Use standalone components, directives, and pipes. Import only the template dependencies a component needs. Register application-wide services with `bootstrapApplication` and `ApplicationConfig`; register route-specific providers on the route when their lifetime should match that route subtree.
+
+```ts
+bootstrapApplication(AppComponent, {
+  providers: [provideRouter(routes), provideHttpClient()],
+});
+
+@Component({
+  standalone: true,
+  imports: [RouterLink],
+  template: `<a routerLink="/settings">Settings</a>`,
+})
+export class NavComponent {}
+```
+
+**Verify first:** Confirm that a provider is not already registered by a library or a parent injector. Duplicate registrations can create separate service instances.
+
+Sources: [Components](https://angular.dev/guide/components), [Dependency Injection](https://angular.dev/guide/di), [Routing providers](https://angular.dev/guide/routing/define-routes).
+
+## 2. Dependency injection scopes
+
+**Symptom:** State unexpectedly resets, leaks across users of a feature, or differs between eagerly and lazily loaded views.
+
+**Fix:** Choose scope intentionally.
+
+| Need | Provider location |
+| --- | --- |
+| One instance for the application | `@Injectable({ providedIn: 'root' })` |
+| One instance per component subtree | component `providers` |
+| One instance for a route and its child routes | route `providers` |
+
+Use `inject()` in an injection context when it makes dependencies clearer; use constructor injection where it improves the class API or compatibility with existing patterns. Avoid service locators and manually constructed services—Angular must create injected services to resolve their dependencies and lifecycle correctly.
+
+Source: [Hierarchical injectors](https://angular.dev/guide/di/hierarchical-dependency-injection).
+
+## 3. Signals and RxJS boundaries
+
+**Problem:** UI state and asynchronous streams are represented interchangeably, causing duplicate subscriptions or unclear ownership.
+
+**Fix:** Use signals for synchronous state consumed by templates or derived with `computed`. Keep RxJS for event streams, cancellation, timing, multicasting, and other asynchronous composition. Convert only at a clear boundary:
+
+- Use `toSignal()` when a template or signal-based state needs an Observable value.
+- Use `toObservable()` when signal changes need an Observable pipeline.
+- Prefer the `async` pipe for Observable values used only in a template.
+
+```ts
+readonly query = signal('');
+readonly normalizedQuery = computed(() => this.query().trim().toLowerCase());
+
+readonly results = toSignal(
+  this.search.search(this.normalizedQuery()),
+  { initialValue: [] },
+);
+```
+
+**Verify first:** `toSignal()` subscribes to its source. Do not call it repeatedly for the same stream, and provide an initial value unless the `undefined` state is explicitly valid. Model loading, empty, and error states rather than treating absence as an error.
+
+Sources: [Signals](https://angular.dev/guide/signals), [RxJS interop](https://angular.dev/ecosystem/rxjs-interop).
+
+## 4. Templates and change detection
+
+**Fix:** Use built-in control flow for new templates when it improves readability. Track stable identity in repeated collections.
+
+```html
+@if (user(); as currentUser) {
+  <h1>{{ currentUser.name }}</h1>
+} @else {
+  <p>Sign in to continue.</p>
+}
+
+@for (item of items(); track item.id) {
+  <app-item [item]="item" />
+} @empty {
+  <p>No items.</p>
+}
+```
+
+Signals read in an `OnPush` component template are tracked by Angular; when they change, Angular marks the component for update. Use `ChangeDetectionStrategy.OnPush` as a performance-oriented default for components with clear input and state boundaries. Do not mutate objects or arrays in place when consumers rely on reference changes; create updated values instead.
+
+**Verify first:** If a view is stale, identify whether its state changes through a signal, an input reference, an event, or an Observable consumed with `async` before adding manual change-detection calls.
+
+Sources: [Control flow](https://angular.dev/guide/templates/control-flow), [Signals in `OnPush` components](https://angular.dev/guide/signals#reading-signals-in-onpush-components), [Skipping component subtrees](https://angular.dev/best-practices/skipping-subtrees).
+
+## 5. Reactive forms and validation
+
+**Problem:** Validation is spread through templates, values are weakly typed, or submission accepts stale/invalid data.
+
+**Fix:** Use reactive forms for non-trivial forms. Define validators with the controls, show errors after an interaction or submission attempt, and check the form state before submitting. Prefer typed controls and `NonNullableFormBuilder` when `null` is not a meaningful form value.
+
+```ts
+readonly form = this.formBuilder.nonNullable.group({
+  email: ['', [Validators.required, Validators.email]],
+  password: ['', [Validators.required, Validators.minLength(12)]],
+});
+
+submit(): void {
+  if (this.form.invalid) {
+    this.form.markAllAsTouched();
+    return;
+  }
+  this.accountService.register(this.form.getRawValue());
+}
+```
+
+For server validation, map known field errors to the relevant control with `setErrors`; keep unexpected failures as form-level or page-level errors. Async validators must complete and should avoid issuing redundant requests.
+
+Sources: [Reactive forms](https://angular.dev/guide/forms/reactive-forms), [Form validation](https://angular.dev/guide/forms/form-validation).
+
+## 6. HTTP interceptors and errors
+
+**Fix:** Configure `HttpClient` with functional interceptors. Keep interceptors narrow: add authentication or tracing headers, normalize a cross-cutting response concern, or apply a documented retry policy. Re-throw errors after any contextual handling so the caller can decide how to present recovery.
+
+```ts
+export const authInterceptor: HttpInterceptorFn = (request, next) => {
+  const token = inject(AuthService).token();
+  const authorized = token
+    ? request.clone({ setHeaders: { Authorization: `Bearer ${token}` } })
+    : request;
+
+  return next(authorized).pipe(
+    catchError((error: HttpErrorResponse) => {
+      inject(ErrorReporter).report(error);
+      return throwError(() => error);
+    }),
+  );
+};
+```
+
+Register order deliberately: request processing follows interceptor order, while responses travel back through the chain. Handle request-specific messages near the calling feature; reserve interceptors for reusable transport policy. Do not retry non-idempotent requests without an explicit server-side safety guarantee.
+
+Sources: [HTTP interceptors](https://angular.dev/guide/http/interceptors), [Making requests](https://angular.dev/guide/http/making-requests).
+
+## 7. Lazy routes and guards
+
+**Fix:** Lazy-load feature routes with `loadChildren` and standalone screens with `loadComponent`. Use functional guards for navigation policy and return a `UrlTree` or `RedirectCommand` for redirects rather than navigating imperatively from a guard.
+
+```ts
+export const routes: Routes = [
+  {
+    path: 'reports',
+    loadChildren: () => import('./reports/reports.routes').then((m) => m.REPORT_ROUTES),
+    canActivate: [() => inject(AuthService).isAuthenticated() || inject(Router).parseUrl('/login')],
+  },
+];
+```
+
+**Verify first:** Client-side guards are not authorization. Enforce access control on the server or API as well. Confirm the intended guard type: `canMatch` affects route matching, while `canActivate` controls activation after a route is selected.
+
+Sources: [Define routes](https://angular.dev/guide/routing/define-routes), [Route guards](https://angular.dev/guide/routing/route-guards), [Lazy loading](https://angular.dev/guide/ngmodules/lazy-loading).
+
+## 8. Version, CLI, and TypeScript alignment
+
+**Problem:** An Angular update fails with peer-dependency or compiler errors, or a generated project differs from repository conventions.
+
+**Verify first:** Check the official [version compatibility table](https://angular.dev/reference/versions) for the supported Node.js, TypeScript, and RxJS ranges of the target Angular version. Check the installed CLI with `ng version`; use the workspace’s package manager and lockfile rather than globally installed tooling as the source of truth.
+
+**Fix:** Upgrade Angular packages and the Angular CLI using the official [Update Guide](https://angular.dev/update-guide), selecting the current and target versions. Make the required TypeScript and Node.js changes before addressing application-level migration output. Run the repository’s build, tests, and lint commands after each upgrade step.
+
+Source: [Angular CLI](https://angular.dev/tools/cli), [Version compatibility](https://angular.dev/reference/versions), [Update Guide](https://angular.dev/update-guide).

package/template/.devbooster/hub/knowledge/dependency-guide.md

@@ -0,0 +1,175 @@
+# 📦 Dependency Guide
+
+> **Purpose:** Decision model for safe dependency updates and audit interpretation
+> **Primary official sources:** [npm CLI documentation](https://docs.npmjs.com/cli/) · [Yarn documentation](https://yarnpkg.com/) · [pnpm documentation](https://pnpm.io/)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing abstractions, configuration, lockfile, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+---
+
+## Table of Contents
+
+1. [Safe-Update Decision Model](#safe-update-decision-model)
+2. [Eligible vs Non-Eligible — Examples](#eligible-vs-non-eligible)
+3. [Method for Analyzing Dependency Usage](#method-for-analyzing-dependency-usage)
+4. [Audit Interpretation Rules](#audit-interpretation-rules)
+5. [Package Manager Behavior](#package-manager-behavior)
+6. [Validation Hierarchy](#validation-hierarchy)
+
+---
+
+## Safe-Update Decision Model
+
+### Conditions for considering an update "safe"
+
+A dependency is eligible for a safe update **only when ALL of the following conditions are true**:
+
+1. **Same major version** — the update stays within the same major version (including a patch or minor update) and the upstream release notes do not identify an incompatible change
+2. **No coupled migration** — it is not part of a known migration family that requires source code adaptation
+3. **Role understood** — the dependency's role is known: runtime, build, types, or security
+4. **Validation path exists** — the project exposes a validation path capable of detecting obvious fallout (lint, build, typecheck)
+5. **No forced operations** — the update does not require lockfile override, `resolutions`, codemod, global rewrite, or behavior not supported by the package manager
+
+### Golden rule
+If any condition fails, the update goes to deeper analysis.
+
+---
+
+## Eligible vs Non-Eligible
+
+### Eligible (safe update)
+| Category | Example | Reason |
+|---|---|---|
+| Same-major minor | `next 16.1.x → 16.2.x` | Eligible for release-note review and validation; not inherently free of breaking behavior |
+| Coupled packages | `react + react-dom` | Update together within compatible major versions |
+| Security priority | `axios 1.x → 1.y` | Same-major security update; confirm the advisory path and release notes |
+| Bounded same-major | `@tanstack/react-query 5.x → 5.y` | Same-major update with targeted validation |
+
+### Non-Eligible (requires deep analysis)
+| Dependency | Reason |
+|---|---|
+| `tailwindcss 3 → 4` | Breaking change, config migration |
+| `Chakra UI 2 → 3` | Breaking change, component rewrite |
+| `TypeScript 5 → 7` | Two majors, high risk |
+| `ESLint 9 → 10` | Config breaking change |
+| `Zustand 4 → 5` | API breaking change |
+| `date-fns 2 → 4` | Two majors, breaking changes |
+
+---
+
+## Method for Analyzing Dependency Usage
+
+### Four layers of evidence
+
+Before recommending an update or removal, use these 4 layers:
+
+1. **Runtime import evidence**
+   - Search the code for imports/requires and API calls
+   ```bash
+   rg -n --glob '*.{js,jsx,ts,tsx,mjs,cjs}' \
+     "from ['\"]package-name['\"]|import ['\"]package-name['\"]|require\(['\"]package-name['\"]|import\(['\"]package-name['\"]" src/
+   ```
+   - Also check aliases, generated code, and configuration files; source searches alone are not conclusive.
+
+2. **Framework/config evidence**
+   - Inspect: framework config, PostCSS/Tailwind, ESLint, scripts, Docker, CI
+   - The dependency may be in use even without a direct import in source
+
+3. **Type-system evidence**
+   - Inspect `tsconfig.json`, exported types
+   - Packages that only provide types (e.g., `@types/*`) have no runtime import
+
+4. **Dependency provenance**
+   - Use `yarn why <package>` / `npm ls <package>` / `pnpm why <package>`
+   - Check whether it's a direct or transitive dependency
+
+### Result classification
+
+| Classification | Meaning | Action |
+|---|---|---|
+| **Runtime confirmed** | Direct import/call in source | Do not remove |
+| **Tooling confirmed** | Used by scripts/config/build | Do not remove without checking scripts |
+| **Indirect only** | Required by framework/chain | Check if framework still needs it |
+| **Removal candidate** | No direct or indirect evidence | Remove with validation |
+
+### Generic example
+A package like `sharp` may be listed in `package.json` but have no direct import in source — it may be used internally by the framework (e.g., Next.js uses `sharp` for image optimization). **In this case, even without a direct import, do not remove it without confirming whether the framework still uses it.**
+
+---
+
+## Audit Interpretation Rules
+
+### Rules for interpreting `npm audit` / `yarn audit`
+
+1. **Audit count ≠ business risk**
+   - A package may emit multiple advisories and paths
+   - The number of findings is not the number of independent risks
+
+2. **Root upgrade does not patch nested framework copy**
+   - Root `sharp@0.35` can coexist with `next#sharp@0.34`
+   - Root `postcss@8.5` can coexist with `next#postcss@8.4`
+   - Updating the root does not necessarily resolve the nested copy
+
+3. **Always cross-reference audit output with provenance**
+   ```bash
+   yarn why <package>
+   npm ls <package>
+   ```
+   Inspect the upstream package's `package.json` when necessary.
+
+4. **Classify risk separately**
+   - Findings in toolchain (eslint, webpack, etc.) may be **build-time risk**, not runtime
+   - Do not ignore — classify exposure and remediation separately
+
+5. **Do not add resolutions/overrides just to lower audit count**
+   - Overriding an internal framework range is a policy decision
+   - Requires compatibility validation and explicit approval
+
+---
+
+## Package Manager Behavior
+
+### Yarn Classic (1.x)
+
+| Command | Important behavior |
+|---|---|
+| `yarn outdated` | Exit code `1` when there are updates — **not an error**, it's a sign of findings |
+| `yarn audit --level moderate` | Returns a severity bitmask: info `1`, low `2`, moderate `4`, high `8`, critical `16`; `--level` filters displayed findings but does not change the exit code |
+| `yarn outdated` | Lists current, wanted, and latest versions; it does not diagnose lockfile synchronization |
+| Peer warnings | May exist even with lint/build passing (e.g., React 18 peer range in libs) |
+
+If `package.json` changes, run `yarn install` serially to update `yarn.lock`. In CI, use the project's frozen/immutable lockfile policy to detect unexpected lockfile changes.
+
+### Mandatory serialization
+**Never** run two commands that write to the lockfile in parallel:
+```bash
+# ❌ WRONG: parallel
+yarn add package-a & yarn add package-b
+
+# ✅ CORRECT: serialized
+yarn add package-a
+yarn add package-b
+```
+
+Serialize `install`, `add`, `remove`, and equivalents to avoid:
+- Lockfile races
+- Non-deterministic state
+- Loss of updates
+
+---
+
+## Validation Hierarchy
+
+### Available validation matrix
+
+| Validation | What it proves | Limitation |
+|---|---|---|
+| `lint` | Lint config works, no errors | Does not exercise runtime |
+| `build` | The configured production build pipeline (for example, bundling and framework configuration) | Type checking, route coverage, and generated output depend on the project's toolchain and settings; does not verify external APIs or UX |
+| Dedicated typecheck | Type errors (faster than build) | May not exist as a separate script |
+| Automated tests | Regression of behavior | May not exist |
+| Manual smoke test | UX and integration | Requires human execution |
+
+---

package/template/.devbooster/hub/knowledge/eslint-migration.md

@@ -0,0 +1,206 @@
+# 🧹 ESLint Migration
+
+> **Purpose:** Migration guidance and common issues for ESLint 9+ and flat config
+> **Primary official sources:** [ESLint configuration migration guide](https://eslint.org/docs/latest/use/configure/migration-guide) · [ESLint configuration files](https://eslint.org/docs/latest/use/configure/configuration-files) · [Next.js ESLint plugin](https://nextjs.org/docs/app/api-reference/config/eslint)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing abstractions, configuration, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+---
+
+## Table of Contents
+
+1. [ESLint 9 — Flat Config by Default](#eslint-9--flat-config-by-default)
+2. [Basic JavaScript + React Hooks Config](#basic-javascript--react-hooks-config)
+3. [Configuration for Next.js](#configuration-for-nextjs)
+4. [ESLint-level Masking](#eslint-level-masking)
+5. [Inline Suppressions](#inline-suppressions)
+6. [reportUnusedDisableDirectives](#reportunuseddisabledirectives)
+7. [Resolutions Affecting the Toolchain](#resolutions-affecting-the-toolchain)
+8. [Legacy Config Mode in ESLint 9](#legacy-config-mode-in-eslint-9)
+
+---
+
+## ESLint 9 — Flat Config by Default
+
+### Status
+Flat config (`eslint.config.*`) is the default configuration format in ESLint 9. Legacy `.eslintrc.*` configuration can still be used in ESLint 9 by setting `ESLINT_USE_FLAT_CONFIG=false`, but that mode is deprecated and is removed in ESLint 10.
+
+### Supported config files
+| File | Type |
+|---|---|
+| `eslint.config.js` | ESM or CommonJS, based on `package.json` |
+| `eslint.config.mjs` | ESM |
+| `eslint.config.cjs` | CommonJS |
+| `eslint.config.ts` | TypeScript; requires `jiti` or enabled native Node.js TypeScript support |
+| `eslint.config.mts` | TypeScript ESM; requires the same TypeScript support |
+| `eslint.config.cts` | TypeScript CommonJS; requires the same TypeScript support |
+
+For Node.js, TypeScript config files require `jiti` or Node's explicitly enabled native TypeScript support. Node 22.13+ alone is not sufficient without the documented TypeScript-stripping and ESLint feature flags.
+
+### Migration checklist
+1. Create `eslint.config.*` at the project root.
+2. Use `@eslint/migrate-config` as a starting point where applicable, then review the result.
+3. Move `.eslintignore` patterns into a flat-config `ignores` object; flat config does not load `.eslintignore` automatically.
+4. For Next.js 16+, replace `next lint` with the ESLint CLI.
+5. Run `eslint .` and use `eslint --inspect-config <file>` to verify important files receive the intended rules.
+6. Update incompatible plugins or use the documented compatibility utilities where necessary.
+7. Remove `.eslintrc.*` and `.eslintignore` only after the flat configuration is verified in local development and CI.
+
+---
+
+## Basic JavaScript + React Hooks Config
+
+This example is for JavaScript and JSX only. To lint TypeScript, add a TypeScript parser/configuration such as the [official typescript-eslint flat-config setup](https://typescript-eslint.io/getting-started/); merely adding `*.ts` or `*.tsx` file patterns does not parse TypeScript.
+
+```js
+// eslint.config.js
+import { defineConfig } from "eslint/config";
+import js from "@eslint/js";
+import pluginReactHooks from "eslint-plugin-react-hooks";
+
+export default defineConfig([
+  {
+    files: ["**/*.{js,jsx,mjs,cjs}"],
+    plugins: { js },
+    extends: ["js/recommended"],
+    rules: {
+      semi: "error",
+      "no-unused-vars": "warn",
+    },
+  },
+  {
+    files: ["**/*.jsx"],
+    plugins: { "react-hooks": pluginReactHooks },
+    rules: {
+      "react-hooks/rules-of-hooks": "error",
+      "react-hooks/exhaustive-deps": "warn",
+    },
+  },
+]);
+```
+
+---
+
+## Configuration for Next.js
+
+For a TypeScript Next.js application, use the documented Next.js flat configs. Omit `nextTs` for a JavaScript-only project.
+
+```js
+// eslint.config.mjs
+import { defineConfig, globalIgnores } from "eslint/config";
+import nextVitals from "eslint-config-next/core-web-vitals";
+import nextTs from "eslint-config-next/typescript";
+
+export default defineConfig([
+  ...nextVitals,
+  ...nextTs,
+  globalIgnores([
+    ".next/**",
+    "out/**",
+    "build/**",
+    "next-env.d.ts",
+  ]),
+]);
+```
+
+---
+
+## ESLint-level Masking
+
+### Problem
+Broad disables and ignore patterns can hide problems, but scoped exceptions are sometimes appropriate for generated code, fixtures, or unsupported environments.
+
+### Risky patterns
+```js
+// Broad global rule disables require a documented reason.
+const config = {
+  rules: {
+    "react-hooks/exhaustive-deps": "off",
+    "@typescript-eslint/no-explicit-any": "off",
+  },
+};
+```
+
+### Handling
+- Prefer the narrowest rule override, file pattern, or inline suppression that addresses the specific case.
+- Keep test source linted by default; ignore only generated fixtures, vendor assets, or other verified non-source inputs.
+- Document why an exception is needed and review it when dependencies or code change.
+
+---
+
+## Inline Suppressions
+
+### Problem
+Comments that suppress ESLint or TypeScript rules need review. Some are legitimate, but each should have a narrow scope and an explanation where the reason is not obvious.
+
+### Most common patterns
+```ts
+// @ts-ignore
+// @ts-expect-error — reports an error if no longer needed
+// @ts-nocheck — disables type checking for the entire file
+// eslint-disable-next-line react-hooks/exhaustive-deps
+```
+
+### How to handle during audit
+1. Count and classify suppressions by type.
+2. Replace `@ts-ignore` with `@ts-expect-error` when an expected error must remain; fix the type when practical.
+3. Do not remove `@ts-nocheck` without reviewing the full file, especially generated code or third-party declarations.
+4. For `exhaustive-deps`, determine whether the dependency can be added safely before suppressing the rule.
+
+---
+
+## reportUnusedDisableDirectives
+
+### Problem
+Disable comments that no longer suppress a finding remain as clutter and can conceal whether an exception is still needed.
+
+*Source: [ESLint configuration files — Report Unused Disable Directives](https://eslint.org/docs/latest/use/configure/configuration-files#report-unused-disable-directives)*
+
+### Fix
+```js
+// eslint.config.js
+import { defineConfig } from "eslint/config";
+
+export default defineConfig([
+  {
+    linterOptions: {
+      reportUnusedDisableDirectives: "error",
+    },
+  },
+]);
+```
+
+### Why use it
+- Detects suppressions that are no longer needed.
+- Helps clean up code as rules evolve.
+- The default is `"warn"`; using `"error"` makes cleanup enforceable in CI.
+
+---
+
+## Resolutions Affecting the Toolchain
+
+### Problem
+Yarn `resolutions`, npm `overrides`, and `pnpm.overrides` can alter transitive dependencies used by development tools. A broad or incompatible override can break ESLint and related tooling.
+
+### Handling
+1. Remove overrides that are no longer needed.
+2. Document the dependency path and reason for every retained override.
+3. Inspect the dependency tree with the package manager in use:
+```bash
+npm ls ajv
+yarn why ajv
+pnpm why ajv
+```
+4. Run linting and the relevant test/build commands after changing an override.
+
+---
+
+## Legacy Config Mode in ESLint 9
+
+### Status
+In ESLint 9, `ESLINT_USE_FLAT_CONFIG=false` can temporarily enable legacy `.eslintrc.*` configuration. ESLint marks that mode as deprecated; it is not available in ESLint 10.
+
+### Guidance
+Use legacy mode only as a time-bounded compatibility measure while migrating. Verify plugin and shareable-config compatibility in the actual project, then move to flat config before upgrading to ESLint 10.

package/template/.devbooster/hub/knowledge/index.md

@@ -0,0 +1,91 @@
+# 📚 Dev Booster — Knowledge Base
+
+> Consolidated knowledge base for Dev Booster.
+> Each article documents a problem pattern + validated solution.
+
+---
+
+## How to Use
+
+1. Identify the concrete technical decision or problem pattern (e.g., framework behavior, migration concern, ESLint rule name, error message, or symptom).
+2. Check the index below to locate the relevant article and section.
+3. Use `read_file` with `start_line`/`end_line` to read **only** the necessary local section.
+4. **Always read the official source linked by that section before choosing or applying a solution.** Use the local entry for field-validated context and the official source for current API, version, constraints, and migration guidance.
+5. Inspect the actual project: installed versions, local rules, existing abstractions, configuration, conventions, and relevant tests.
+6. Preserve a valid established project convention. Do not replace it only because another official approach is also valid; recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+### Example
+
+User reports: `TS2345: Type 'string' is not assignable to type 'number'`
+
+1. Identify the pattern → TypeScript strict error on a discriminated union or runtime type mismatch.
+2. Check the index → `typescript-patterns.md` table entry confirms it covers "null safety, discriminated UI states, runtime validation".
+3. Read the relevant section → `read_file` with `start_line`/`end_line` to get only the "null-safety" section of `typescript-patterns.md`.
+4. Read the official source → open the [TypeScript Handbook section on Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html) to verify current API behavior.
+5. Inspect the project → check `tsconfig.json` strict flags, existing type guards in the codebase, and whether the error is in a new area or a pre-typed module.
+6. Decide → if the project already uses a consistent pattern (e.g. Zod schemas + inferred types), preserve it. Only suggest a different approach if the current one is incompatible, unsafe, or the user explicitly requests a change.
+
+---
+
+### If Not Found in the Base
+
+Use the relevant **official source** below. Prefer primary documentation, official changelogs, and official migration guides over blog posts, search snippets, or unverified answers.
+
+| Area | Trusted sources |
+|---|---|
+| React | [React documentation](https://react.dev), [useEffect](https://react.dev/reference/react/useEffect), [useState](https://react.dev/reference/react/useState), [useMemo](https://react.dev/reference/react/useMemo), [You Might Not Need an Effect](https://react.dev/learn/you-might-not-need-an-effect) |
+| React Hooks linting | [eslint-plugin-react-hooks](https://www.npmjs.com/package/eslint-plugin-react-hooks) |
+| Next.js | [Next.js documentation](https://nextjs.org/docs), [Next.js 16 upgrade guide](https://nextjs.org/docs/app/guides/upgrading/version-16), [TypeScript configuration](https://nextjs.org/docs/app/api-reference/config/next-config-js/typescript), [Image configuration](https://nextjs.org/docs/app/api-reference/components/image#configuration-options) |
+| Historical Next.js behavior | [Next.js 15 ESLint configuration](https://nextjs.org/docs/15/app/api-reference/config/next-config-js/eslint) |
+| ESLint | [ESLint configuration files](https://eslint.org/docs/latest/use/configure/configuration-files), [ESLint migration to flat config](https://eslint.org/docs/latest/use/configure/migration-guide) |
+| TypeScript | [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/), [TSConfig reference](https://www.typescriptlang.org/tsconfig/), [TypeScript release notes](https://devblogs.microsoft.com/typescript/) |
+| npm | [npm CLI documentation](https://docs.npmjs.com/cli/), [npm audit](https://docs.npmjs.com/cli/commands/npm-audit), [peer dependency settings](https://docs.npmjs.com/cli/using-npm/config#strict-peer-deps) |
+| Yarn Classic | [Yarn Classic documentation](https://classic.yarnpkg.com/en/docs/), [yarn audit](https://classic.yarnpkg.com/en/docs/cli/audit/), [yarn outdated](https://classic.yarnpkg.com/en/docs/cli/outdated/), [yarn why](https://classic.yarnpkg.com/en/docs/cli/why/) |
+| pnpm | [pnpm documentation](https://pnpm.io/), [pnpm audit](https://pnpm.io/cli/audit), [pnpm why](https://pnpm.io/cli/why), [pnpm workspaces](https://pnpm.io/workspaces) |
+| Node.js | [Node.js API documentation](https://nodejs.org/docs/latest/api/), [Node.js package guidance](https://nodejs.org/en/learn/getting-started/packages) |
+| Monorepos | [npm workspaces](https://docs.npmjs.com/cli/using-npm/workspaces), [Yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/), [pnpm workspaces](https://pnpm.io/workspaces), [Turborepo documentation](https://turbo.build/docs), [Nx documentation](https://nx.dev/docs) |
+| tRPC | [tRPC documentation](https://trpc.io/docs), [Context](https://trpc.io/docs/server/context), [Procedures](https://trpc.io/docs/server/procedures), [Error handling](https://trpc.io/docs/server/error-handling) |
+| TanStack Query | [TanStack Query documentation](https://tanstack.com/query/latest/docs/framework/react/overview), [Query keys](https://tanstack.com/query/latest/docs/framework/react/guides/query-keys), [SSR and hydration](https://tanstack.com/query/latest/docs/framework/react/guides/ssr) |
+| Prisma + PostgreSQL | [Prisma documentation](https://www.prisma.io/docs/orm), [Prisma Migrate](https://www.prisma.io/docs/orm/prisma-migrate), [PostgreSQL documentation](https://www.postgresql.org/docs/), [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html) |
+| NestJS | [NestJS documentation](https://docs.nestjs.com/), [Modules](https://docs.nestjs.com/modules), [Validation](https://docs.nestjs.com/techniques/validation), [Exception filters](https://docs.nestjs.com/exception-filters) |
+| Vite | [Vite Guide](https://vite.dev/guide/), [Environment variables](https://vite.dev/guide/env-and-mode), [Vite config](https://vite.dev/config/) |
+| Tailwind CSS | [Tailwind documentation](https://tailwindcss.com/docs), [Tailwind v4 upgrade guide](https://tailwindcss.com/docs/upgrade-guide) |
+| Angular | [Angular documentation](https://angular.dev/overview), [Angular version compatibility](https://angular.dev/reference/versions), [Angular CLI](https://angular.dev/cli) |
+| Testing | [Vitest documentation](https://vitest.dev/guide/), [Jest documentation](https://jestjs.io/docs/getting-started), [Playwright documentation](https://playwright.dev/docs/intro) |
+| react-to-print | [Official repository](https://github.com/MatthewHerbst/react-to-print), [v3 changelog](https://github.com/MatthewHerbst/react-to-print/blob/v3.3.0/CHANGELOG.md) |
+| Formik | [Formik Form API](https://formik.org/docs/api/form) |
+| Radix UI | [Radix Primitives documentation](https://www.radix-ui.com/primitives/docs/overview/introduction) |
+| shadcn/ui | [shadcn CLI](https://ui.shadcn.com/docs/cli), [Radix migration](https://ui.shadcn.com/docs/cli#migrate-radix), [Tailwind v4 migration](https://ui.shadcn.com/docs/tailwind-v4) |
+
+For a library-specific issue, prioritize the library's official documentation, release notes, changelog, and migration guide. If the official sources do not cover the case, resolve it from the actual project context without writing to this knowledge base.
+
+---
+
+## Articles
+
+| File | Stacks | Content |
+|---|---|---|
+| [`react-patterns.md`](./react-patterns.md) | React 19, React Hooks | Effects, derived state, async UI strategy, Suspense boundaries, custom-hook extraction, state mutation |
+| [`nextjs-pitfalls.md`](./nextjs-pitfalls.md) | Next.js 16 | Build/lint changes, config schema drift, Server/Client boundaries, route loading/errors, hydration |
+| [`eslint-migration.md`](./eslint-migration.md) | ESLint 9, Flat Config | Flat config migration, masking, `resolutions`, inline suppressions |
+| [`typescript-patterns.md`](./typescript-patterns.md) | TypeScript Strict | Imports, suppressions, refs, discriminated UI states, runtime validation, null safety |
+| [`dependency-guide.md`](./dependency-guide.md) | npm/yarn/pnpm | Safe update model, dependency analysis, audit interpretation |
+| [`upgrade-fallout.md`](./upgrade-fallout.md) | Multi-stack | Upgrade fallout: scripts, config, new lint rules, validation |
+| [`migration-guides.md`](./migration-guides.md) | Libraries | `react-to-print` v3, Formik + React 19, Radix UI |
+| [`nodejs-patterns.md`](./nodejs-patterns.md) | Node.js | Runtime alignment, ESM/CJS, environment handling, async failures, script portability |
+| [`package-manager-patterns.md`](./package-manager-patterns.md) | npm, Yarn, pnpm | Lockfiles, peers, overrides, audit, workspaces, immutable installs |
+| [`monorepo-patterns.md`](./monorepo-patterns.md) | npm/Yarn/pnpm workspaces, Turbo, Nx | Package boundaries, dependency resolution, shared configs, cache hygiene |
+| [`trpc-patterns.md`](./trpc-patterns.md) | tRPC | Context/auth, input validation, errors, type integrity, router design, transport |
+| [`tanstack-patterns.md`](./tanstack-patterns.md) | TanStack Query | Query ownership, keys, invalidation, async UI states, caching, SSR hydration, cancellation, optimistic updates |
+| [`prisma-postgresql-patterns.md`](./prisma-postgresql-patterns.md) | Prisma, PostgreSQL | Generation drift, migrations, query loading, transactions, indexes, pooling |
+| [`nestjs-patterns.md`](./nestjs-patterns.md) | NestJS | Modules, DI, validation, guards, exceptions, configuration, request scope |
+| [`vite-patterns.md`](./vite-patterns.md) | Vite | Env exposure, base paths, aliases, ESM/CJS, optimizer cache, plugins, React integration |
+| [`tailwind-shadcn-patterns.md`](./tailwind-shadcn-patterns.md) | Tailwind CSS, shadcn/ui | v3/v4 migration, source scanning, tokens, dependencies, themes, design-system reuse |
+| [`testing-patterns.md`](./testing-patterns.md) | Vitest, Jest, Playwright | Environments, determinism, mocks, async UI behavior, isolation, CI parity, validation |
+| [`angular-patterns.md`](./angular-patterns.md) | Angular | Standalone APIs, DI, signals/RxJS, forms, HTTP, routing, version alignment |
+
+---
+
+## Maintenance (Dev Booster Maintainers Only)
+
+This base is manually curated. Only Dev Booster maintainers add, update, or remove content.