dev-booster 1.18.0 → 1.18.1

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

@@ -0,0 +1,219 @@
+# 📘 TypeScript Patterns
+
+> **Purpose:** Problematic patterns and fixes for TypeScript Strict Mode
+> **Primary official sources:** [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/) · [TypeScript Release Notes](https://devblogs.microsoft.com/typescript/)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed TypeScript version, `tsconfig`, local rules, existing type abstractions, runtime validation boundaries, 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. [Incorrect Import Path](#incorrect-import-path)
+2. [@ts-ignore vs @ts-expect-error](#ts-ignore-vs-ts-expect-error)
+3. [React useRef Guidance](#react-useref-guidance)
+4. [Function Placement Around Effects](#function-placement-around-effects)
+5. [Duplicate Props in Spread](#duplicate-props-in-spread)
+6. [Explicit Any](#explicit-any)
+7. [Null Check Missing](#null-check-missing)
+8. [Model UI State with Discriminated Unions](#model-ui-state-with-discriminated-unions)
+9. [Validate Untrusted Data at the Runtime Boundary](#validate-untrusted-data-at-the-runtime-boundary)
+
+---
+
+## Incorrect Import Path
+
+### Problem
+Importing a package subpath that is not part of its documented public API.
+
+### Code (symptom)
+```ts
+// WRONG — internal package path (not public API)
+import { SomeType } from 'package-name/src/internal/types'
+
+// CORRECT — public export
+import type { SomeType } from 'package-name'
+```
+
+### Why it's a problem
+- A path containing `src/` is not automatically private, but an unexported deep import is not a stable public API
+- Unexported paths can break in future versions without notice
+- Internal types may differ from the package's supported exports
+
+### Fix
+1. Check the package documentation and its `package.json` `exports` map
+2. Use the equivalent documented public path
+3. If the needed type is not exported, redesign around the public API or request an export. Avoid copying a package's internal declaration unless you own and can maintain that contract.
+
+---
+
+## @ts-ignore vs @ts-expect-error
+
+### Problem
+`@ts-ignore` silently suppresses type errors. If the error is fixed by other changes, the comment becomes orphaned with no warning.
+
+### Code (symptom)
+```ts
+// @ts-ignore — if the error disappears, nobody knows
+const result = someFunction()
+```
+
+### Fix
+Replace with `@ts-expect-error`:
+```ts
+// @ts-expect-error — reason: package X's API changed in v2
+const result = someFunction()
+```
+
+### Why it's better
+- If the expected error is resolved, TypeScript reports an **error** for the unused `@ts-expect-error` directive
+- It makes intentional suppressions visible for future cleanup
+- A lint rule such as `@typescript-eslint/ban-ts-comment` can require a description when the project needs one
+
+### Exceptions
+- `@ts-nocheck` in generated or third-party files — requires case-by-case analysis
+- Files that will be deleted in an upcoming refactor — may not be worth switching
+
+---
+
+## React useRef Guidance
+
+React 19 requires an explicit initial value for `useRef`; this is a React type-definition change, not a consequence of TypeScript strict mode. See the canonical guidance in [React Patterns: useRef Without Initial Value in React 19](./react-patterns.md#useref-without-initial-value-in-react-19).
+
+For nullable object references, represent the runtime value honestly and check it before use:
+
+```ts
+const socketRef = useRef<Socket | null>(null)
+if (socketRef.current) socketRef.current.send(message)
+```
+
+---
+
+## Function Placement Around Effects
+
+**Evidence:** Field-validated in a real audit.
+
+### Context
+A function declared with `const` after a `useEffect` callback is not necessarily a TypeScript or JavaScript hoisting error because the Effect runs after component initialization. In React code, however, source order can obscure a dependency issue when the helper is recreated during render or omitted from the dependency list.
+
+### Guidance
+For the complete React-specific pattern, including the safe alternatives and verification criteria, see [React Patterns: Function Placement Around Effects](./react-patterns.md#function-placement-around-effects).
+
+---
+
+## Duplicate Props in Spread
+
+### Problem
+A property may be passed through a spread and explicitly. JSX applies props from left to right, so a later explicit prop deterministically overwrites the spread value.
+
+### Intentional override
+```tsx
+<Component {...props} size={16} /> // size={16} wins
+```
+
+### Avoid the duplicate
+```tsx
+const { size: _ignoredSize, ...rest } = props
+<Component {...rest} size={16} />
+```
+
+---
+
+## Explicit Any
+
+### Problem
+Explicit `any` disables type checking in that section. `noImplicitAny` (included by `strict`) reports implicit `any`, but it does not prohibit an explicit `any` annotation.
+
+### Code (symptom)
+```ts
+const data: any = await fetchData() // loses all type safety
+```
+
+### Fix
+```ts
+// Option 1: A value from a typed, trusted boundary
+const data: ApiResponse = await fetchData()
+
+// Option 2: Validate untrusted API or JSON data at runtime
+const data: unknown = await fetchData()
+if (isApiResponse(data)) {
+  console.log(data.specificField)
+}
+```
+
+---
+
+## Null Check Missing
+
+### Problem
+`strictNullChecks` reports a nullable value when it is used as though it were non-null. It is enabled by `strict` unless explicitly overridden.
+
+### Code (symptom)
+```ts
+const element = document.getElementById('app')
+element.textContent = 'Hello' // ❌ Object is possibly 'null'
+```
+
+### Fix
+```ts
+// Option 1: Early return
+const element = document.getElementById('app')
+if (!element) return
+element.textContent = 'Hello'
+
+// Option 2: Guarded branch
+const root = document.getElementById('app')
+if (root) root.textContent = 'Hello'
+
+// Option 3: Non-null assertion, only with a proven runtime invariant
+document.getElementById('app')!.textContent = 'Hello'
+```
+
+---
+
+## Model UI State with Discriminated Unions
+
+### Decision
+When a UI has mutually exclusive async states, model the valid states explicitly instead of combining loosely related booleans such as `isLoading`, `hasError`, and nullable data.
+
+### Example
+```ts
+type LoadState<T> =
+  | { status: 'idle' }
+  | { status: 'loading' }
+  | { status: 'success'; data: T }
+  | { status: 'error'; error: Error }
+```
+
+A `switch` on `status` narrows the available fields and makes unhandled states visible to the compiler.
+
+### Verify first
+- Reuse the project’s existing state/result type when one exists.
+- Do not wrap a query library result in a second state model unless it adds a real domain boundary.
+- Include only states the UI can actually reach; do not create abstractions that hide the library or framework behavior developers maintain.
+
+*Source: [TypeScript Handbook — Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions)*
+
+---
+
+## Validate Untrusted Data at the Runtime Boundary
+
+### Decision
+Type annotations do not validate JSON, external API responses, form payloads, storage values, or any value supplied at runtime. Treat untrusted input as `unknown` until a runtime validator, schema, or type guard establishes its shape.
+
+### Verify first
+- Reuse the project’s established validation library and schemas when present.
+- Keep validation near the transport, storage, or form boundary so downstream code receives a trusted type.
+- Do not add a new validation library only to replace a valid project convention.
+
+```ts
+const payload: unknown = await response.json()
+if (!isUser(payload)) throw new Error('Invalid user payload')
+// payload is User here
+```
+
+Avoid `as User` for external input unless a proven runtime contract already guarantees it and the project convention documents that boundary.
+
+*Sources: [TypeScript Handbook — `unknown`](https://www.typescriptlang.org/docs/handbook/2/functions.html#unknown) · [TypeScript Handbook — Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html)*

package/template/.devbooster/hub/knowledge/upgrade-fallout.md

@@ -0,0 +1,154 @@
+# ⚠️ Upgrade Fallout
+
+> **Purpose:** Catalog of side effects observed after dependency upgrades
+> **Primary official sources:** [Next.js documentation](https://nextjs.org/docs) · [ESLint documentation](https://eslint.org/docs/latest/) · [TypeScript TSConfig reference](https://www.typescriptlang.org/tsconfig/) · [npm CLI documentation](https://docs.npmjs.com/cli/)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing abstractions, configuration, lockfile, upgrade path, 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.
+
+---
+
+## Index
+
+1. [Script Compatibility — Broken Command Post-Update](#script-compatibility)
+2. [Config Legacy Incompatible — Serialization Error](#config-legacy-incompatible)
+3. [New Lint Rules Exposing Latent Code](#new-lint-rules-exposing-latent-code)
+4. [TSConfig Auto-mutated by Build](#tsconfig-auto-mutated-by-build)
+5. [Config Schema Drift — Property in Wrong Place](#config-schema-drift)
+6. [Peer Warnings Post-Update](#peer-warnings-post-update)
+7. [Residual Risk — What Remains After the Safe Wave](#residual-risk)
+
+---
+
+## Script Compatibility
+
+### Problem
+A framework update can invalidate `package.json` scripts even when the code compiles without errors.
+
+### Generic example
+Starting with Next.js 16, the `next lint` command is removed. A legacy `next lint` script can therefore be interpreted as a request to use `lint` as a project directory.
+
+### Symptom
+```
+Invalid project directory provided, no such directory: .../lint
+```
+
+### Fix
+Use the documented Next.js lint migration or migrate explicitly to the ESLint CLI (for example, `next lint` → `eslint .`) only after confirming that ESLint and its configuration are installed and current.
+
+---
+
+## Config Legacy Incompatible
+
+### Problem
+An upgrade can expose an unsupported legacy configuration loader or serializer. A generic serialization error alone does not prove that legacy configuration is the cause.
+
+### Diagnostic workflow
+1. Identify the tool, version, configuration file, and command that produced the error.
+2. Inspect the complete stack trace to find the loader or serializer involved.
+3. Compare the active configuration with the tool's version-specific migration documentation.
+4. Reproduce the failure with the smallest relevant configuration before changing compatibility settings.
+
+### Resolution
+Apply the documented migration only after the incompatible mechanism is identified. Record the affected tool and version so the finding remains reproducible.
+
+---
+
+## New Lint Rules Exposing Latent Code
+
+### Problem
+After migrating to a newer lint configuration, new rules may be enabled and reveal problems that already existed in the code — but were not detected.
+
+### Common examples
+- Callback referenced before declaration (incorrect ordering)
+- Non-deterministic logic during render (e.g. `Math.random()` in the component body)
+- Unused import that previously went unnoticed
+
+### Critical distinction
+⚠️ **This is not an upgrade regression.** These are latent problems that are now visible because the analysis tools have improved.
+
+### Fix
+1. Analyze each error individually
+2. Separate between "actual regression" and "latent code now detected"
+3. Apply specific fixes for each case
+
+---
+
+## TSConfig Auto-mutated by Build
+
+### Problem
+Framework commands may create or update `tsconfig.json` with recommended settings. The exact behavior and command output depend on the framework and version.
+
+### Example change to inspect
+```json
+{
+  "compilerOptions": {
+    "moduleResolution": "bundler"
+  }
+}
+```
+
+### Treatment
+- The new value may be correct for the framework version in use.
+- Review and record the `tsconfig.json` diff and command output.
+- Check for other configuration changes before accepting the update.
+
+---
+
+## Config Schema Drift
+
+### Problem
+An unsupported configuration property can be mistaken for a version-to-version schema migration. The build may ignore it or emit a warning.
+
+### Generic example
+```js
+// Invalid top-level Next.js configuration property
+module.exports = { unoptimized: true }
+
+// Valid Next.js Image configuration
+module.exports = { images: { unoptimized: true } }
+```
+
+### Treatment
+- Do not present an unsupported property as a documented migration without version-specific evidence.
+- A build with warnings is not a sign of clean compatibility.
+- Triage warnings tied to the upgrade against the relevant configuration documentation.
+
+---
+
+## Peer Warnings Post-Update
+
+### Problem
+After updating a core dependency (e.g. React), libraries with outdated peer ranges may generate warnings.
+
+### Common examples
+- UI library with React 18 peer range, after upgrading to React 19
+- Transitive dependency with outdated peer range
+
+### Treatment
+- Peer warnings may not appear as lint or build diagnostics, but package-manager policy can turn peer conflicts into install failures.
+- They can also signal build-time or runtime incompatibility.
+- Document unresolved warnings with the dependency path, package-manager behavior, and validation evidence.
+
+---
+
+## Residual Risk
+
+### What remains after the safe wave
+Even after applying eligible updates, residual risks may remain:
+
+1. **Direct security exposure** — a confirmed advisory or CVE with no compatible remediation, after assessing reachability
+2. **Transitive toolchain exposure** — findings in build or development tooling whose affected environment is documented separately from runtime exposure
+3. **Unresolved upstream versions** — nested framework copies that remain after provenance confirms the root update cannot change them
+4. **Deferred migration risk** — major migrations that were postponed (e.g. Tailwind 3→4, Chakra 2→3)
+
+### How to document
+Use the provenance and exposure classification in [Dependency Guide — Audit Interpretation Rules](dependency-guide.md#audit-interpretation-rules).
+
+```markdown
+### Residual Risk
+- **3 unresolved audit findings** — include dependency paths, affected environment, and unavailable remediation
+- **2 peer warnings** — include the peer ranges and package-manager outcome
+- **1 deferred migration**: tailwindcss 3→4 (breaking change)
+```

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

@@ -0,0 +1,177 @@
+# ⚡ Vite Patterns
+
+> **Purpose:** Diagnose common Vite configuration, dependency, and environment failures.
+> **Primary official sources:** [Vite Guide](https://vite.dev/guide/) · [Env and Mode](https://vite.dev/guide/env-and-mode) · [Config](https://vite.dev/config/) · [Plugin API](https://vite.dev/guide/api-plugin) · [Dependency Pre-Bundling](https://vite.dev/guide/dep-pre-bundling)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing build and plugin conventions, configuration, environment model, 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. [Environment Variables Exposed to the Client](#environment-variables-exposed-to-the-client)
+2. [Development and Production Base Paths Differ](#development-and-production-base-paths-differ)
+3. [Aliases Resolve in Vite but Not TypeScript](#aliases-resolve-in-vite-but-not-typescript)
+4. [ESM and CommonJS Dependency Boundaries](#esm-and-commonjs-dependency-boundaries)
+5. [Dependency Optimization or Cache Staleness](#dependency-optimization-or-cache-staleness)
+6. [Plugin Ordering and Node Runtime Alignment](#plugin-ordering-and-node-runtime-alignment)
+7. [Preserve the Existing React Integration and Build Boundary](#preserve-the-existing-react-integration-and-build-boundary)
+
+---
+
+## Environment Variables Exposed to the Client
+
+### Symptom
+A value is `undefined` in browser code, or a secret was accidentally included in the browser bundle.
+
+### Verify first
+`import.meta.env` is Vite's client-side environment interface. Confirm the variable name, the loaded `.env` file for the active mode, and whether the code runs in the browser rather than only in Node.
+
+### Fix
+Only variables beginning with Vite's configured `envPrefix` are exposed to client code; the default prefix is `VITE_`.
+
+```ts
+const apiUrl = import.meta.env.VITE_API_URL
+```
+
+Do not put credentials, private keys, or server-only tokens in a `VITE_*` variable: any exposed value is bundled into client code. Keep secrets in a server-side boundary.
+
+*Source: [Vite — Env Variables and Modes](https://vite.dev/guide/env-and-mode#env-variables)*
+
+---
+
+## Development and Production Base Paths Differ
+
+### Symptom
+Assets, dynamic imports, or client-side navigation work in development but return 404 after deployment under a subpath.
+
+### Verify first
+Identify the deployed public URL (for example, `/` versus `/app/`), inspect generated asset URLs, and distinguish application routing from Vite's asset `base` setting.
+
+### Fix
+Set `base` to the public path used by the production host. Use `/` when served from the origin root and a trailing-slash subpath when served below one.
+
+```ts
+import { defineConfig } from 'vite'
+
+export default defineConfig({
+  base: '/app/',
+})
+```
+
+Use `import.meta.env.BASE_URL` rather than a hard-coded root path when constructing URLs that must respect `base`.
+
+*Source: [Vite — Shared Options: base](https://vite.dev/config/shared-options#base)*
+
+---
+
+## Aliases Resolve in Vite but Not TypeScript
+
+### Symptom
+The app runs, but the editor or `tsc` reports `Cannot find module` for an alias such as `@/ui/button`.
+
+### Verify first
+Check that the alias resolves to the same absolute directory in Vite and in the TypeScript configuration actually used by type checking. Also confirm case matches the filesystem.
+
+### Fix
+Mirror the alias in both places. Vite resolves bundler imports; TypeScript needs `baseUrl` and `paths` to understand the same specifier.
+
+```ts
+// vite.config.ts
+resolve: { alias: { '@': new URL('./src', import.meta.url).pathname } }
+```
+
+```json
+{
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": { "@/*": ["src/*"] }
+  }
+}
+```
+
+The precise Vite alias representation can vary by configuration format; verify resolution with the project’s typecheck and production build.
+
+*Sources: [Vite — resolve.alias](https://vite.dev/config/shared-options#resolve-alias), [TypeScript — paths](https://www.typescriptlang.org/tsconfig/#paths)*
+
+---
+
+## ESM and CommonJS Dependency Boundaries
+
+### Symptom
+A build or config load fails with errors such as `require() of ES Module not supported`, missing named exports, or an unexpected default import.
+
+### Verify first
+Inspect the failing file and the dependency's published `package.json` (`type`, `exports`, and documented import examples). Determine whether the failure is application code, a Vite config/plugin, or a Node script; they may run under different module rules.
+
+### Fix
+Use the module syntax supported by the dependency and runtime. For an ESM-only package, migrate the consuming boundary to ESM or use the package’s documented compatible entry point. Do not rely on undocumented deep imports or assume transpilation changes Node's runtime module rules.
+
+For Vite configuration, use the module format supported by the current Vite/Node setup and validate the config with the same Node version used in CI.
+
+*Sources: [Node.js — ECMAScript modules](https://nodejs.org/api/esm.html), [Vite — Configuring Vite](https://vite.dev/config/)*
+
+---
+
+## Dependency Optimization or Cache Staleness
+
+### Symptom
+A newly linked, updated, or conditionally exported dependency behaves differently until a restart; development shows an old export or optimization error.
+
+### Verify first
+Confirm the installed dependency version and lockfile, then reproduce with a clean dev-server restart. Check whether the affected package is a dependency that Vite pre-bundles for development.
+
+### Fix
+Use Vite's dependency optimizer options only for a demonstrated resolution issue, such as including a dependency that is not discovered or excluding one that must not be pre-bundled. When the dependency graph has changed, force re-optimization rather than treating cache deletion as a permanent fix:
+
+```sh
+vite --force
+```
+
+Vite caches optimized dependencies in `node_modules/.vite`; deleting that cache is a diagnostic reset, not evidence of the underlying cause.
+
+*Sources: [Vite — Dependency Pre-Bundling](https://vite.dev/guide/dep-pre-bundling), [Vite — optimizeDeps](https://vite.dev/config/dep-optimization-options)*
+
+---
+
+## Plugin Ordering and Node Runtime Alignment
+
+### Symptom
+A transform, virtual module, or generated output is missing; the issue appears only locally or only in CI.
+
+### Verify first
+Inspect the final `plugins` array, each plugin's documented compatibility range, and the Node versions in local tooling, CI, and deployment. Check the installed Vite version's current Node requirement rather than assuming a version from another release line.
+
+### Fix
+Place plugins in the documented order. When a plugin must run before or after normal plugins, use its supported `enforce: 'pre'` or `enforce: 'post'` hook rather than relying on incidental array position. Align Node versions through the repository’s declared runtime mechanism and CI configuration, then reinstall dependencies and run a production build.
+
+*Sources: [Vite — Plugin API: Ordering](https://vite.dev/guide/api-plugin#plugin-ordering), [Vite — Getting Started](https://vite.dev/guide/)*
+
+---
+
+## Validation Checklist
+
+1. Run the production build with the intended mode and `base`.
+2. Run type checking to verify aliases outside Vite’s resolver.
+3. Test a fresh dev start after dependency changes; use `--force` only when optimizer state is implicated.
+4. Confirm local and CI Node versions satisfy the installed Vite and plugin requirements.
+5. Inspect built output or a deployed preview for asset and route URLs under the real public path.
+
+---
+
+## Preserve the Existing React Integration and Build Boundary
+
+### Decision
+Before adding or changing Vite plugins, inspect the active framework integration, JSX transform, test configuration, aliases, and environment conventions. Do not replace a working React integration merely because another official Vite plugin is available.
+
+### Verify first
+- Identify the installed Vite and framework-plugin versions and read their compatibility guidance.
+- Reuse the project’s existing plugin, plugin order, Fast Refresh behavior, and configuration-file format.
+- Keep browser-only environment access behind `import.meta.env`; do not copy Node or Next.js environment conventions into a Vite client bundle.
+- Validate changes with the project’s typecheck, development startup, and production build.
+
+Choose a migration only when the project explicitly requests it or the installed integration is incompatible, deprecated, broken, or unable to support a verified requirement.
+
+*Sources: [Vite — Using Plugins](https://vite.dev/guide/using-plugins) · [Vite — Features](https://vite.dev/guide/features) · [Vite — Env Variables and Modes](https://vite.dev/guide/env-and-mode)*

package/template/.devbooster/rules/GUIDE.md

@@ -151,6 +151,30 @@ Example:
 
 ---
 
+## 📚 KNOWLEDGE BASE
+
+Dev Booster ships with a curated knowledge base at `.devbooster/hub/knowledge/`.
+It contains field-validated patterns, migration guides, and technical decisions
+organized by stack. Every article links to official documentation.
+
+When a booster encounters a concrete technical finding or non-trivial decision, it
+may consult this base selectively:
+`index.md` → matching article → relevant section only → linked official source
+→ reconcile with the actual project context.
+
+Articles available:
+- react-patterns, nextjs-pitfalls, typescript-patterns
+- tanstack-patterns, trpc-patterns, testing-patterns
+- tailwind-shadcn-patterns, vite-patterns, eslint-migration
+- dependency-guide, upgrade-fallout, migration-guides
+- nodejs-patterns, package-manager-patterns, monorepo-patterns
+- prisma-postgresql-patterns, nestjs-patterns, angular-patterns
+
+The base is read-only. Only project maintainers may update it.
+Boosters never create, modify, or maintain files in the knowledge base.
+
+---
+
 💡 INSTANT ROUTING (SHORTCUT TRIGGERS):
 Instead of dragging booster files, you can instantly activate any booster behavior contract
 by typing its corresponding trigger in the chat (e.g., @Context, @Coder, @Builder, @Planning).

package/template/.devbooster/rules/PROTOCOL.md

@@ -44,8 +44,9 @@
 - **AMBIGUITY FALLBACK:** If the user remains unclear, says they do not know, or delegates discovery entirely (e.g. "research it", "you figure it out"), load the full relevant local context before proceeding. For technical ambiguity, default to loading `.devbooster/rules/FRONTEND.md` and `.devbooster/rules/BACKEND.md` in addition to the always-on base context. Add `.devbooster/rules/COMMERCIAL.md` when the task may involve positioning, copy, or conversion logic.
 
 ## 📚 6. PERSISTENCE & SHORTCUTS (TRIGGERS)
-- **TRIGGER ROUTING:** Whenever the user references a `@` trigger (e.g., `@Coder`, `@SaveContext`, `@SavePattern`), you MUST then read `.devbooster/rules/TRIGGERS.md` to identify the trigger's contract, load the corresponding files, and execute the behavior mode or background action.
-- **RESTRICTION:** Execute code edits, file writes, or log updates ONLY when explicitly instructed by the trigger contract or a direct user command.
+- **TRIGGER ROUTING:** Whenever the user references a `@` trigger (e.g., `@Frontend`, `@Coder`, `@SaveContext`), you MUST read `.devbooster/rules/TRIGGERS.md` to identify the trigger's contract, load the corresponding booster, and enter its contract mode.
+- **ACTIVATION-FIRST:** A trigger activates the booster's contract (Stage 0 / Armed mode) only. It does NOT authorize the booster's full execution flow, analysis, investigation, or implementation. After activation, present the armed-mode banner and wait for the user to provide the concrete task, symptom, or objective before loading deeper context or taking action.
+- **RESTRICTION:** Execute code edits, file writes, or log updates ONLY when explicitly instructed by the trigger contract or a direct user command after activation.
 
 ---
 *Elite Sovereignty Framework - Conduct Governance 2026*

package/template/.devbooster/rules/TRIGGERS.md

@@ -52,3 +52,17 @@ These triggers instantly activate specific booster behavior contracts without re
 - **`@Doc`** ➔ Activates `.devbooster/boosters/global-documentation.md` (Universal spec generation).
 - **`@Enhance`** ➔ Activates `.devbooster/boosters/enhance.md` (Evolution mode for adding features to existing projects).
 - **`@UIUX`** ➔ Activates `.devbooster/boosters/ui-ux-pro-max.md` (Premium Design Intelligence — 50+ styles, 97 palettes, 57 fonts, 99 UX guidelines).
+- **`@Frontend`** ➔ Activates `.devbooster/boosters/frontend.md` (Frontend specialist with stack-specific React/Next/Vite/Angular/Tailwind rules).
+- **`@Backend`** ➔ Activates `.devbooster/boosters/backend.md` (Backend architect with API, database, runtime, and validation rules).
+- **`@Refactor`** ➔ Activates `.devbooster/boosters/refactor.md` (Clean Code and SOLID refactoring specialist).
+- **`@Performance`** ➔ Activates `.devbooster/boosters/performance.md` (Web Vitals, bundle optimization, rendering and caching analysis).
+- **`@Testing`** ➔ Activates `.devbooster/boosters/testing.md` (QA and test strategy coordinator for unit, integration, and E2E).
+- **`@Security`** ➔ Activates `.devbooster/boosters/security.md` (Security posture auditor for dependency, supply-chain, and threat analysis).
+- **`@CodeAudit`** ➔ Activates `.devbooster/boosters/code-audit.md` (Strict syntax, lint, React Doctor, and framework diagnostics audit).
+- **`@Design`** ➔ Activates `.devbooster/boosters/design.md` (UI/UX component audit and visual standards validation).
+- **`@Create`** ➔ Activates `.devbooster/boosters/create.md` (Master Architect for scaffolding new features and apps).
+- **`@Accessibility`** ➔ Activates `.devbooster/boosters/accessibility.md` (WCAG compliance and semantic HTML auditor).
+- **`@I18n`** ➔ Activates `.devbooster/boosters/i18n.md` (Internationalization specialist for text extraction and localization).
+- **`@Seo`** ➔ Activates `.devbooster/boosters/seo.md` (SEO audit and semantic HTML compliance check).
+- **`@Mobile`** ➔ Activates `.devbooster/boosters/mobile.md` (Mobile UX patterns for React Native and Expo).
+- **`@InternalDoc`** ➔ Activates `.devbooster/boosters/internal-documentation.md` (Internal project documentation with absolute paths and asset maps).