dev-booster 1.18.0 → 1.18.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-booster",
-  "version": "1.18.0",
+  "version": "1.18.1",
   "description": "Reusable AI development kit with manual boosters, governance, and project bootstrap",
   "type": "module",
   "scripts": {

package/template/.devbooster/MANIFEST.md

@@ -43,6 +43,37 @@
 
 ---
 
+## 📚 1.5 KNOWLEDGE BASE (CURATED PATTERNS AND DECISIONS)
+
+The knowledge base at `.devbooster/hub/knowledge/` contains curated, field-validated patterns, migration guidance, and technical decisions organized by stack. Each article documents a problem, symptom, or decision, and links to the relevant official source. Boosters consult this base selectively:
+`index.md` → matching article → relevant section (`start_line`/`end_line`) → linked official source → reconcile with actual project context.
+
+The base is read-only. Only project maintainers update it.
+
+| Article | Content |
+|---|---|
+| [`index.md`](.devbooster/hub/knowledge/index.md) | Global catalog, usage protocol, trusted official source matrix, and maintenance rules |
+| [`react-patterns.md`](.devbooster/hub/knowledge/react-patterns.md) | Effects, derived state, async UI strategy, Suspense boundaries, hooks, state mutation |
+| [`nextjs-pitfalls.md`](.devbooster/hub/knowledge/nextjs-pitfalls.md) | Build/lint changes, config drift, Server/Client boundaries, route loading, hydration |
+| [`eslint-migration.md`](.devbooster/hub/knowledge/eslint-migration.md) | ESLint 9 flat config migration, masking, inline suppressions |
+| [`typescript-patterns.md`](.devbooster/hub/knowledge/typescript-patterns.md) | Import paths, suppressions, discriminated UI states, runtime validation, null safety |
+| [`dependency-guide.md`](.devbooster/hub/knowledge/dependency-guide.md) | Safe update model, dependency analysis, audit interpretation |
+| [`upgrade-fallout.md`](.devbooster/hub/knowledge/upgrade-fallout.md) | Upgrade fallout: scripts, config, new lint rules, validation |
+| [`migration-guides.md`](.devbooster/hub/knowledge/migration-guides.md) | Library-specific migrations (react-to-print, Formik, Radix, shadcn) |
+| [`nodejs-patterns.md`](.devbooster/hub/knowledge/nodejs-patterns.md) | Runtime alignment, ESM/CJS, environment, async failures, scripts |
+| [`package-manager-patterns.md`](.devbooster/hub/knowledge/package-manager-patterns.md) | Lockfiles, peers, overrides, audit, workspace, immutable installs |
+| [`monorepo-patterns.md`](.devbooster/hub/knowledge/monorepo-patterns.md) | Package boundaries, dependency resolution, shared config, cache |
+| [`trpc-patterns.md`](.devbooster/hub/knowledge/trpc-patterns.md) | Context/auth, input validation, errors, type integrity, router design |
+| [`tanstack-patterns.md`](.devbooster/hub/knowledge/tanstack-patterns.md) | Query ownership, keys, invalidation, async UI states, caching, SSR hydration |
+| [`prisma-postgresql-patterns.md`](.devbooster/hub/knowledge/prisma-postgresql-patterns.md) | Generation drift, migrations, query loading, transactions, indexes |
+| [`nestjs-patterns.md`](.devbooster/hub/knowledge/nestjs-patterns.md) | Modules, DI, validation, guards, exceptions, configuration |
+| [`vite-patterns.md`](.devbooster/hub/knowledge/vite-patterns.md) | Env exposure, base paths, aliases, ESM/CJS, optimizer, plugins, React integration |
+| [`tailwind-shadcn-patterns.md`](.devbooster/hub/knowledge/tailwind-shadcn-patterns.md) | v3/v4 migration, source scanning, tokens, themes, design-system reuse |
+| [`testing-patterns.md`](.devbooster/hub/knowledge/testing-patterns.md) | Environments, determinism, mocks, async UI behavior, CI parity, validation |
+| [`angular-patterns.md`](.devbooster/hub/knowledge/angular-patterns.md) | Standalone APIs, DI, signals/RxJS, forms, HTTP, routing |
+
+---
+
 ## 🛠️ 2. TECHNICAL SKILL MATRIX (DENSE KNOWLEDGE)
 
 ### Frontend & UI/UX
@@ -167,7 +198,8 @@
 - **`playwright_runner.py`**: E2E Health checks with headless screenshots.
 - **`session_manager.py`**: Rapid tech stack analysis and file-level statistics.
 - **`auto_preview.py`**: Automated dev server lifecycle management.
-- **`convert_rules.py`**: Agent rule transformation and standardization.
+- `convert_rules.py`: Agent rule transformation and standardization.
+
 
 ---
 
@@ -178,6 +210,7 @@
 | **Total Agents** | 20 |
 | **Total Skills** | 40+ |
 | **Master Boosters** | 35 |
+| **Knowledge Base Articles** | 18 |
 | **Operational Scripts** | 2 (Master) + 20 (Skill-level) |
 | **Coverage** | ~95% Full-stack Web/Mobile |
 

package/template/.devbooster/boosters/advisor.md

@@ -51,6 +51,11 @@ When the first real advisory request arrives:
   - supporting booster
   - optional booster
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When advising on a task with a concrete stack-specific finding, recommend the appropriate specialist booster and state that it will apply the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 1. AVAILABLE INVENTORY SOURCE
 - Use repository-relative paths directly from `.devbooster/` and `.devbooster/hub/`.
 - Read `.devbooster/MANIFEST.md` only when the user provides a real advisory request.

package/template/.devbooster/boosters/audit.md

@@ -123,6 +123,25 @@ If it is generic, empty, or not useful, ignore it.
 - `.devbooster/hub/personas/agent_code-archaeologist.md`
 - `.devbooster/hub/skills/systematic-debugging/SKILL.md`
 
+### Knowledge Base Consultation — Finding-Driven and Read-Only
+Use `.devbooster/hub/knowledge/` only after Stage 2 produces a concrete lint, typecheck, configuration, runtime, or dependency finding.
+
+Do NOT read the entire knowledge base.
+
+For each relevant finding:
+1. Read `.devbooster/hub/knowledge/index.md`.
+2. Locate the matching article and section from the index.
+3. Read only that section using `read_file` with `start_line` and `end_line`.
+4. Read the official source linked by the article or section before choosing a correction.
+5. Reconcile the local pattern and official guidance with the actual project version, configuration, dependency graph, and affected code.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during an audit.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs an audit conclusion, correction, or recommendation, record a complete `Knowledge Base Decision Trace` in the execution artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+Keep chat concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current audit.
+
 ## 4. AUDIT DISCIPLINE
 The booster has only two missions:
 - run lint correctly
@@ -347,6 +366,7 @@ If the user approves:
   - **Typecheck Findings**
   - **Lot 1 — Safe Fixes**
   - **Lot 2 — Needs Deeper Analysis**
+- consult the knowledge base only for findings that match a concrete known pattern, following the finding-driven and read-only rules above
 - update the artifact
 - summarize briefly in chat
 - ask:

package/template/.devbooster/boosters/auto-triage.md

@@ -77,6 +77,11 @@ Only begin Stage 1 after the user provides a concrete demand.
 9. **Stage 1 is read-only for the project.** During triage, do not edit or create project files, create migrations, run mutating commands, invoke `atomic.md`, `implementation.md`, `builder.md`, or produce executable implementation instructions.
 10. **No invented business rules.** Repository naming, a plausible convention, or absence of evidence is not proof of a business rule, root cause, or safety guarantee.
 
+### Knowledge Base Routing — Delegate to the Specialist
+Auto Triage MUST NOT consult `.devbooster/hub/knowledge/` directly. When triage identifies a concrete stack-specific finding, select and delegate to the appropriate specialist booster. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Auto Triage and its work units MUST NOT create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 4. STAGE 1 — AUTOMATIC TRIAGE
 
 A concrete user demand starts Stage 1. Create the artifact before deep work begins and set the authorization ledger to show that only triage is authorized.

package/template/.devbooster/boosters/backend.md

@@ -55,6 +55,18 @@ Rules:
 - Prefer adding one relevant skill/persona at a time.
 - Keep the user inside the same booster mode while expanding context.
 
+## 0.3 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only when the concrete backend task or finding matches a known Node.js, tRPC, NestJS, Prisma/PostgreSQL, package-manager, monorepo, migration, or runtime pattern, or requires a non-trivial technical decision about an API contract, validation boundary, data access, transaction, module boundary, or runtime behavior.
+
+Do not consult the base for mechanical implementation that already follows a valid local service, router, schema, or repository convention. Before consulting it, inspect existing comparable code, local rules, contracts, schemas, configuration, and tests. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the actual API contract, database schema, runtime, dependency versions, configuration, and affected code. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during backend work.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a backend design or implementation decision, and a persistent backend artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the decision was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current backend work.
+
 ## 1. ALLOWED INVENTORY
 Allowed backend inventory:
 - `.devbooster/hub/personas/agent_backend-specialist.md`

package/template/.devbooster/boosters/builder.md

@@ -34,6 +34,11 @@ Upon receiving the plan or execution instructions:
 2. Load stack-specific rules from `.devbooster/rules/` (`rules/PROJECT.md`, `rules/FRONTEND.md`, `rules/BACKEND.md`, and/or `rules/USER_PREFERENCES.md`).
 3. Read the persona inventory in `.devbooster/MANIFEST.md` under Section 1 (Specialized Agents), identify the best-matching specialist personas for the target plan, and load their corresponding files.
 
+### Knowledge Base Routing — Delegate to the Specialist
+Builder MUST NOT consult `.devbooster/hub/knowledge/` directly. If pre-execution auditing or implementation reveals a concrete stack-specific issue outside the approved plan's established guidance, pause that decision and route the concern to the appropriate specialist booster. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 1. PRE-EXECUTION SANITY CHECK & AUDIT (MANDATORY GATE)
 Before writing ANY code, you must perform a senior audit of the plan against the active codebase:
 1. **Identify Gaps & Edge Cases:** Look for missing UX treatments (e.g., missing loading states, missing toast notifications, missing validation alerts), unhandled errors, database constraint conflicts, or folder pattern mismatches.

package/template/.devbooster/boosters/code-audit.md

@@ -60,6 +60,25 @@ Only switch to execution mode after the user provides the commit scope.
     - **Report & Decide**: Present "Immediate Actions" (Critical errors) in detail by line. For "Cosmetic Debt" (Warnings), create a dedicated section that groups the warnings by Rule/Category (e.g., "Tailwind Sorting: 70 issues", "Unused Variables: 20 issues"). Provide a 1-line explanation for the most frequent categories so the user understands the nature of the debt without being overwhelmed.
     - **ZERO Auto-Fix**: Do NOT modify code automatically. Ask the user: "Do you want to fix only the critical recommendations, everything, or specific items?" and wait for authorization.
 
+### 3.1 KNOWLEDGE BASE CONSULTATION — FINDING-DRIVEN AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only after lint, type coverage, React Doctor, framework diagnostics, or the diff review produces a concrete finding.
+
+Do NOT read the entire knowledge base.
+
+For each relevant finding:
+1. Read `.devbooster/hub/knowledge/index.md`.
+2. Locate the matching article and section from the index.
+3. Read only that section using `read_file` with `start_line` and `end_line`.
+4. Read the official source linked by the article or section before recommending a correction.
+5. Reconcile the local pattern and official guidance with the actual framework version, project configuration, dependency graph, diff scope, and affected code.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during Code Audit.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs an audit conclusion or recommended correction, and a persistent Code Audit artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current Code Audit.
+
 ## 4. OUTPUT STRUCTURE (MANDATORY)
 Your response MUST be an **Audit Report**:
 

package/template/.devbooster/boosters/coder.md

@@ -35,6 +35,11 @@ Upon receiving a code modification command (either direct in Route B or during t
 - **PARALLEL INGESTION:** Perform all checks and read all necessary files (evaluating target files to be modified, reading Section 1 of `.devbooster/MANIFEST.md` to identify personas, and loading stack-specific rules from `.devbooster/rules/` like `rules/FRONTEND.md` or `rules/BACKEND.md`) in a **single parallel tool call batch**.
 - Do NOT split these reads into sequential chat turns. Load all required context files concurrently in one turn, then proceed directly to execution.
 
+### Knowledge Base Routing — Delegate to the Specialist
+Coder MUST NOT consult `.devbooster/hub/knowledge/` directly. When discussion or implementation uncovers a concrete stack-specific finding that materially affects the design or change, route it to the appropriate specialist booster before deciding the technical approach. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 1. DIALOGUE & CONVENTION RULES (CRITICAL)
 - **DO NOT CODE PREMATURELY:** During design discussions, debate pros, cons, readability, and potential overengineering based on local project patterns. Do NOT generate full code blocks or diffs unless explicitly requested by the user.
 - **PROVIDE SINCERE FEEDBACK:** Evaluate the user's folder structures and code organization ideas critically. Suggest simpler alternatives if the proposal is too complex for the stack, or validate and refine the design if it is optimal.

package/template/.devbooster/boosters/create.md

@@ -37,6 +37,11 @@ When the first real creation request arrives:
 - Load the minimum required personas, skills, and local rules to start the creation flow.
 - Then continue with the booster's discovery and scaffolding logic.
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When discovery, scaffolding, or pre-flight identifies a concrete stack-specific design, migration, compatibility, runtime, or dependency concern, route it to the appropriate specialist booster before choosing the structure. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 1. PHASE 0: SOCRATIC DISCOVERY (THE GATE)
 **MANDATORY**: Before generating ANY plan or code, you must:
 1.  **Load `skill_brainstorming`**.

package/template/.devbooster/boosters/debug.md

@@ -9,6 +9,25 @@ You are the Lead Debugger. Your mission is to move beyond "quick fixes" into dee
     - Run `session_manager.py` to identify tech stack and project stats.
     - Run `lint_runner.py` to check for syntax/type-level errors.
 
+## 1.1 KNOWLEDGE BASE CONSULTATION — FINDING-DRIVEN AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only after a concrete symptom, error message, reproducible behavior, or evidence-backed hypothesis has been identified. The knowledge base informs hypotheses; it never replaces reproduction or root-cause verification.
+
+Do NOT read the entire knowledge base.
+
+For each relevant finding:
+1. Read `.devbooster/hub/knowledge/index.md`.
+2. Locate the matching article and section from the index.
+3. Read only that section using `read_file` with `start_line` and `end_line`.
+4. Read the official source linked by the article or section before choosing a fix.
+5. Reconcile the local pattern and official guidance with the actual error, reproduction, runtime, dependency versions, configuration, and affected code.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during debugging.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a hypothesis, root-cause conclusion, or fix, and a persistent debug artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and prevention or validation.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current debugging work.
+
 ## 2. THE DEBUG PROTOCOL
 When an issue is reported, you MUST follow these 4 stages:
 

package/template/.devbooster/boosters/deploy.md

@@ -35,6 +35,18 @@ When activated:
 - return risks, missing checks, and recommended manual next steps
 - never execute the deploy path itself
 
+## 2.0 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only after deploy-readiness inspection identifies a concrete runtime, Node.js, package-manager, lockfile, workspace, framework-build, configuration, or test-validation concern, or when such evidence requires a non-trivial compatibility or release-readiness decision.
+
+Do not consult the base for a mechanical readiness check that already follows a valid project deployment convention. Before consulting it, inspect the existing CI workflow, deployment configuration, runtime declaration, lockfile, and comparable release process. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the actual CI workflow, deployment target, runtime, package manager, lockfile, and build configuration. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during deploy auditing.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a deploy-readiness conclusion or recommendation, and a persistent deploy artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current deploy audit.
+
 ## 2.1 PLATFORM REFERENCE (FOR MANUAL EXECUTION)
 When a deploy target is identified, reference the appropriate platform command for the user to run manually:
 

package/template/.devbooster/boosters/discovery.md

@@ -39,6 +39,11 @@ Examples:
 - Load product and brainstorming context first.
 - Use validation scripts only when they are relevant to the exploration.
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When discovery produces a concrete stack-specific constraint, migration, compatibility concern, or technical finding, route it to the appropriate specialist booster before presenting a technical recommendation. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 1. INTEL LOADING SYNC (MANDATORY)
 - Use repository-relative paths directly from `.devbooster/` and `.devbooster/hub/`.
 - Load Persona: `.devbooster/hub/personas/agent_product-owner.md`

package/template/.devbooster/boosters/frontend.md

@@ -55,6 +55,18 @@ Rules:
 - Prefer adding one relevant skill/persona at a time.
 - Keep the user inside the same booster mode while expanding context.
 
+## 0.3 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only when the concrete frontend task or finding matches a known React, Next.js, Angular, Vite, Tailwind, shadcn/ui, TanStack Query, dependency, migration, or rendering pattern, or requires a non-trivial technical decision about async UI, `useEffect`, Suspense, query ownership, Server/Client boundaries, hydration, custom-hook extraction, runtime validation, design-system extension, or test strategy.
+
+Do not consult the base for a mechanical UI change that already follows a valid local component, hook, design-system, or data-fetching convention. Before consulting it, inspect comparable screens, existing abstractions, local rules, framework version, rendering model, and tests. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the actual framework version, rendering model, design system, dependency graph, configuration, and affected code. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during frontend work.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a frontend design or implementation decision, and a persistent frontend artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the decision was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current frontend work.
+
 ## 1. MANDATORY CONTEXT LOADING
 Allowed frontend inventory:
 - `.devbooster/hub/personas/skill_frontend-design.md`

package/template/.devbooster/boosters/implementation.md

@@ -53,6 +53,11 @@ Only generate the implementation plan after the user confirms to proceed.
 2. Analyze the current conversation context before selecting the implementation type.
 3. Ask for missing business rules ONLY if they are not documented or discussed.
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When implementation sizing identifies a concrete stack-specific risk, migration, compatibility concern, or technical finding that changes the plan, route it to the appropriate specialist booster before generating the final plan. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 2. DECISION MATRIX (REPOSITY IMPLEMENTATION)
 Evaluate the task complexity and select the corresponding template file:
 

package/template/.devbooster/boosters/investigation.md

@@ -52,6 +52,11 @@ Examples:
 - You MUST NOT describe how to implement.
 - This process is a prerequisite for another AI model to handle execution.
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When investigation establishes a concrete stack-specific finding, record the evidence and route it to the appropriate specialist booster. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 3. INVESTIGATION PROTOCOL
 
 ### 3.1 REQUEST ANALYSIS

package/template/.devbooster/boosters/performance.md

@@ -50,6 +50,18 @@ Rules:
 - Prefer adding one relevant skill/persona at a time.
 - Keep the user inside the same booster mode while expanding context.
 
+## 0.3 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only after profiling or investigation identifies a concrete stack-specific performance pattern, or when measured evidence requires a non-trivial choice between established implementation approaches, such as React rendering, Effect/data-fetching behavior, Next.js delivery, TanStack Query caching, Vite build behavior, or dependency/runtime overhead.
+
+Do not consult the base for generic optimization folklore or a mechanical change already covered by a valid local performance convention. Before consulting it, inspect existing measurements, abstractions, local rules, and comparable code. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with measured evidence, the actual bottleneck, active versions, configuration, and affected code before optimizing. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for the measured bottleneck.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during performance work.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs an optimization decision, and a persistent performance artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, measured evidence, decision, rationale, and validation.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the decision was validated against measured project evidence and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current performance work.
+
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/skills/performance-profiling`
 - `.devbooster/hub/skills/nextjs-react-expert`

package/template/.devbooster/boosters/planning.md

@@ -55,6 +55,11 @@ Only conclude readiness after the user confirms the planner alignment and the ma
 ### Complementary Skills (load only when relevant)
 - **`documentation-templates`** — use the ADR template to record planning decisions: context that led to the approach, risks accepted, and tradeoffs dismissed. Only when a material decision is finalized.
 
+### Knowledge Base Routing — Delegate to the Specialist
+This booster MUST NOT consult `.devbooster/hub/knowledge/` directly. When planning reveals a concrete stack-specific risk, migration, compatibility concern, or technical finding that needs validation, route it to the appropriate specialist booster before finalizing readiness. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
+
 ## 2. PLANNING ROLE
 This booster must:
 - Consolidate what was already decided.

package/template/.devbooster/boosters/refactor.md

@@ -17,4 +17,16 @@ You are the Quality Lead. Your goal is to eliminate technical debt and enforce c
 ### Complementary Skills (load only when relevant)
 - **`documentation-templates`** — use the ADR template to document refactoring decisions: why a pattern was replaced, tradeoffs involved, and migration strategy. Only when a structural change is material.
 
+### Knowledge Base Consultation — Conditional and Read-Only
+Consult `.devbooster/hub/knowledge/` only when the refactor targets a concrete known pattern, framework migration, dependency compatibility issue, stack-specific technical debt, or a non-trivial implementation decision such as state ownership, async-data strategy, rendering boundary, or reusable abstraction.
+
+Do not consult the base for mechanical restructuring that already follows a valid local convention. Before consulting it, inspect the project’s existing abstractions, local rules, tests, and comparable code. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the project architecture, versions, tests, and affected code before choosing a refactor. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during refactoring.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a refactoring decision, and a persistent refactoring artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the decision was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current refactoring work.
+
 **Response: "Quality Lead Activated. Resolving Hub paths and loading refactoring matrix... Where is the technical debt?"**

package/template/.devbooster/boosters/review.md

@@ -41,6 +41,18 @@ When the review input arrives:
 - Load only the personas, skills, and scripts necessary for that specific review.
 - Run audit scripts only when they are actually relevant to the supplied material.
 
+## 0.2 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only when the supplied plan, implementation, or review target contains a concrete known pattern, migration, dependency concern, framework compatibility issue, technical finding, or non-trivial implementation decision that needs validation.
+
+Do not consult the base for a mechanical plan detail already governed by a valid local convention. Before consulting it, inspect comparable project code, local rules, versions, configuration, tests, and evidence. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the actual project versions, configuration, dependency graph, plan scope, and evidence before issuing a review verdict. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during review.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a review verdict, and a persistent review artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the verdict was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current review.
+
 ## 1. PRE-FLIGHT (MANDATORY)
 1. Use repository-relative paths directly from `.devbooster/` and `.devbooster/hub/`.
 2. Read `.devbooster/MANIFEST.md` only after the review target is available.

package/template/.devbooster/boosters/security.md

@@ -52,6 +52,20 @@ Rules:
 - Prefer adding one relevant skill/persona at a time.
 - Keep the user inside the same booster mode while expanding context.
 
+## 0.3 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+The current knowledge base supports dependency and supply-chain concerns only. Consult `.devbooster/hub/knowledge/` when a concrete finding involves package provenance, lockfiles, package-manager behavior, overrides/resolutions, runtime version drift, or dependency audit interpretation.
+
+Do NOT use the knowledge base as a substitute for security-specific investigation of authentication, authorization, secrets, injection, PII, attack surfaces, or threat modeling.
+
+For an eligible dependency finding, do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the actual dependency path, reachability, runtime exposure, package manager, lockfile, and project configuration.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during security work.
+
+### Knowledge Base Decision Traceability
+For an eligible dependency or supply-chain consultation, when a knowledge-base section materially informs a security conclusion and a persistent security artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current security work. This traceability rule does not expand the knowledge base beyond dependency and supply-chain concerns.
+
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/personas/agent_security-auditor.md`
 - `.devbooster/hub/personas/agent_penetration-tester.md`

package/template/.devbooster/boosters/smart-task.md

@@ -38,9 +38,10 @@ This booster runs in three stages. It MUST respect the boundary between them.
 2. A concrete task authorizes **only Stage 1 — Full Investigation**. It does NOT authorize plan generation, Builder invocation, or file modification.
 3. Stage 1 may investigate, map flows, call specialist boosters, create the artifact, and present the "🎯 Entendimento" checkpoint. Stage 1 MUST NOT generate an atomic plan, invoke Builder, or edit repository files.
 4. The single user approval ("pode seguir") authorizes **only Stage 2 — Atomic Plan + Execution**. Stage 2 MUST NOT run additional investigation, create a new artifact, or present a second approval checkpoint.
-5. Never interpret a vague message such as "looks right", "continue", or "go ahead" as execution approval unless it directly follows the "🎯 Entendimento" checkpoint and clearly refers to the presented understanding. When in doubt, ask for clarification.
-6. If scope, business rules, or affected boundaries change materially during investigation, revisit the complexity check (4.3) and, if needed, offer the Auto Triage escape.
-7. Never advance stages silently. Every stage transition requires: artifact update (when applicable), the required chat checkpoint, and the authorization required by that transition.
+5. Stage 2 MUST invoke `atomic.md` to generate the plan and `builder.md` to execute it. Smart Task MUST NOT generate the plan or execute code itself.
+6. Never interpret a vague message such as "looks right", "continue", or "go ahead" as execution approval unless it directly follows the "🎯 Entendimento" checkpoint and clearly refers to the presented understanding. When in doubt, ask for clarification.
+7. If scope, business rules, or affected boundaries change materially during investigation, revisit the complexity check (4.3) and, if needed, offer the Auto Triage escape.
+8. Never advance stages silently. Every stage transition requires: artifact update (when applicable), the required chat checkpoint, and the authorization required by that transition.
 
 ## 2. STAGE 0 — ARMED ACTIVATION
 
@@ -74,6 +75,12 @@ Only begin Stage 1 after the user provides a concrete task.
 5. **Single approval gate.** There is only one "🎯 Entendimento" checkpoint. After the user says "Pode seguir", generate the atomic plan and invoke Builder in sequence — no second approval.
 6. **Chat is the dashboard, artifact is the source of truth.** Chat gets concise summaries. The artifact gets the complete detailed record.
 7. **Never skip the checkpoint.** Even when the task seems obvious, you MUST present the "🎯 Entendimento" checkpoint and wait for explicit user confirmation before proceeding to Stage 2.
+8. **Never bypass kit boosters.** The atomic plan MUST be generated by invoking `atomic.md`, not by the Smart Task itself. The execution MUST be done by invoking `builder.md`, not by the Smart Task itself. Smart Task is an orchestrator, not a plan generator or executor.
+
+### Knowledge Base Routing — Delegate to the Specialist
+Smart Task MUST NOT consult `.devbooster/hub/knowledge/` directly. When investigation identifies a concrete stack-specific finding, route it to the appropriate specialist booster. The specialist applies the selective, read-only knowledge-base protocol when relevant: `index.md` → matching article → relevant section only → linked official source → reconciliation with the actual project context.
+
+The knowledge base is read-only. Smart Task MUST NOT create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/`.
 
 ## 4. STAGE 1 — FULL INVESTIGATION
 
@@ -214,17 +221,20 @@ Wait for the user's response. You MUST NOT advance to Stage 2 without explicit u
 
 Triggered ONLY by the user's explicit confirmation at the "🎯 Entendimento" checkpoint ("pode seguir", "segue", "ok", "vai"). If the user responds without referring to the checkpoint context, ask for clarification before proceeding.
 
-### 5.1 Generate the Atomic Plan
+### 5.1 Invoke atomic.md to Generate the Plan
+
+You MUST NOT generate the atomic plan yourself. You MUST invoke the **`atomic.md`** booster with the full investigation context (artifact, verified facts, business rules, consolidated evidence).
+
+1. Load `.devbooster/boosters/atomic.md` and follow its contract.
+2. Provide `atomic.md` with the complete context: business rules, verified facts, files involved, expected behavior.
+3. `atomic.md` will return a deterministic plan with Objective, Scope, Files, Implementation Instructions, Constraints, and Validation.
+4. Capture the returned plan as the execution input.
 
-1. Read the target file(s) to confirm current state.
-2. Create a concise atomic plan:
-   - **Objective:** what the change does
-   - **Files to modify:** exact paths with specific changes
-   - **Validation:** how to verify
+**Why this is mandatory:** `atomic.md` is a dedicated booster in the Dev Booster kit that generates structured, machine-oriented implementation instructions. The Smart Task cannot replace this role.
 
-### 5.2 Invoke Builder
+### 5.2 Invoke Builder with the Atomic Plan
 
-Immediately invoke **Builder** (`ROUTE B: DIRECT EXECUTION`) with the atomic plan. Do NOT ask for a second approval.
+Once `atomic.md` has returned the plan, immediately invoke **Builder** (`ROUTE B: DIRECT EXECUTION`) with that plan. Do NOT ask for a second approval.
 
 ### 5.3 Update the Artifact After Execution (Mandatory)
 
@@ -270,10 +280,11 @@ flowchart LR
     C --> D["🎯 Checkpoint: Entendimento<br/>'É isso?'"]
     D -->|"Correção"| E["Ajusta entendimento<br/>+ artefato"]
     E --> D
-    D -->|"Pode seguir"| F["Stage 2<br/>Plano atômico"]
-    F --> G["Invoca Builder<br/>(execução automática)"]
-    G --> H["Atualiza artefato"]
-    H --> I["✅ Checkpoint: Concluído<br/>(resumo no chat)"]
+    D -->|"Pode seguir"| F["Stage 2<br/>Invoca atomic.md"]
+    F --> G["atomic.md gera o plano<br/>estruturado (Objective,\<br/>Scope, Files, Constraints)"]
+    G --> H["Invoca Builder<br/>com o plano do atomic.md"]
+    H --> I["Atualiza artefato"]
+    I --> J["✅ Checkpoint: Concluído<br/>(resumo no chat)"]
 ```
 
-**Reply:** On activation, enter Stage 0 Armed mode and wait — do NOT investigate or create anything. After a concrete task, execute Stage 1 with full investigation (same calibre as Auto Triage), create the artifact, and present the "🎯 Entendimento" checkpoint. You MUST NOT advance to Stage 2 (plan + Builder) without explicit user confirmation. On user approval ("pode seguir"), generate the atomic plan and invoke Builder immediately — do NOT ask for a second approval. After execution, update the artifact with full details and present a brief chat summary. Never skip stages, never advance silently, never execute without authorization.
+**Reply:** On activation, enter Stage 0 Armed mode and wait — do NOT investigate or create anything. After a concrete task, execute Stage 1 with full investigation (same calibre as Auto Triage), create the artifact, and present the "🎯 Entendimento" checkpoint. You MUST NOT advance to Stage 2 without explicit user confirmation. On user approval ("pode seguir"), invoke `atomic.md` with the full investigation context — do NOT generate the plan yourself. Then invoke Builder with the plan returned by `atomic.md`. After execution, update the artifact with full details and present a brief chat summary. Never skip stages, never advance silently, never execute without authorization, never bypass boosters from the kit.

package/template/.devbooster/boosters/stack-refresh.md

@@ -60,6 +60,7 @@ Purpose:
 - run the correct `outdated` commands for the detected package manager and scope
 - run the correct audit/security commands when relevant
 - classify findings into safe, risky, and human-review categories
+- consult the knowledge base only for findings that match a concrete known pattern, following the finding-driven and read-only rules below
 - update the artifact with the detailed findings
 
 Stage 1 requires explicit user approval after Stage 0.
@@ -176,6 +177,25 @@ Load only after the user has approved update execution and validation is actuall
 - Do NOT load validation/test assets during Stage 0 mapping.
 - If evidence is missing, stay with the Stage 0 fixed base load only.
 
+### Knowledge Base Consultation — Finding-Driven and Read-Only
+Do not consult `.devbooster/hub/knowledge/` during Stage 0 mapping. Consult it only after Stage 1 identifies a concrete outdated package, security finding, runtime mismatch, configuration warning, compatibility issue, or migration surface.
+
+Do NOT read the entire knowledge base.
+
+For each relevant finding:
+1. Read `.devbooster/hub/knowledge/index.md`.
+2. Locate the matching article and section from the index.
+3. Read only that section using `read_file` with `start_line` and `end_line`.
+4. Read the official source linked by the article or section before recommending an update, migration path, or deferral.
+5. Reconcile the local pattern and official guidance with the actual package versions, package manager, lockfile, workspace topology, runtime, configuration, and dependency graph.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during Stack Refresh.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs an upgrade classification, migration path, deferral, or recommendation, record a complete `Knowledge Base Decision Trace` in the execution artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation or follow-up.
+
+Keep chat concise: state the project convention, whether it was preserved or changed, and that the conclusion was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current Stack Refresh.
+
 ## 4. PRE-FLIGHT DISCIPLINE
 Start working immediately on activation.
 

package/template/.devbooster/boosters/testing.md

@@ -52,6 +52,18 @@ Rules:
 - Prefer adding one relevant skill/persona at a time.
 - Keep the user inside the same booster mode while expanding context.
 
+## 0.3 KNOWLEDGE BASE CONSULTATION — CONDITIONAL AND READ-ONLY
+Consult `.devbooster/hub/knowledge/` only when a concrete testing, validation, framework, migration, runtime, or dependency finding requires stack-specific guidance, or when a non-trivial testing decision is needed: test scope, async UI behavior, browser boundary, request mocking, or query/client-state setup.
+
+Do not consult the base for a mechanical test that already follows a valid local fixture, helper, mock, and assertion convention. Before consulting it, inspect the existing test setup, comparable tests, active runner, and CI behavior. Do NOT read the entire knowledge base. Read `index.md`, locate the matching article and section, read only that section with `start_line` and `end_line`, then read its linked official source. Reconcile both with the active test runner, environment, CI behavior, project versions, and the behavior being validated. Preserve a valid project convention unless the developer requests a change or evidence shows it is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+The knowledge base is read-only. Never create, modify, append to, or otherwise maintain files in `.devbooster/hub/knowledge/` during testing work.
+
+### Knowledge Base Decision Traceability
+When a knowledge-base section materially informs a testing decision, and a persistent testing artifact is created or updated, record a complete `Knowledge Base Decision Trace` in that artifact: project convention observed, article and section consulted, official source, decision, rationale, and validation.
+
+When no persistent artifact exists, keep the chat trace concise: state the project convention, whether it was preserved or changed, and that the decision was validated against project context and official guidance. Do not dump article names, section names, or URLs unless the user asks. Never claim that the knowledge base or an official source was consulted unless the relevant local section and source were actually read during the current testing work.
+
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/personas/agent_test-engineer.md`
 - `.devbooster/hub/personas/agent_qa-automation-engineer.md`