dev-booster 1.16.5 → 1.16.7

package/README.md

@@ -114,7 +114,7 @@ Boosters are expert activators you invoke manually during development.
 | `discovery.md` | Product brainstorm |
 | `performance.md` | Core Web Vitals / bundle issues |
 | `code-audit.md` | Strict Code Auditor (Syntax, React Doctor) before PR |
-| `lint.md` | Make terminal lint operational, check bypasses, and separate safe fixes from deep review |
+| `audit.md` | Make terminal lint and typecheck operational, check bypasses, and separate safe fixes from deep review |
 | + 17 more | See `.devbooster/MANIFEST.md` |
 
 The practical activation flow is simple:
@@ -141,7 +141,7 @@ Many boosters now use a two-step flow:
 | `implementation.md` | Final implementation artifact only after confirmation |
 | `internal-documentation.md` | Final documentation artifact only after confirmation |
 | `investigation.md` | No artifact by default; save only if the user explicitly asks |
-| `lint.md` | Always writes an execution-state artifact to `@booster-generated/lint/` during its run |
+| `audit.md` | Always writes an execution-state artifact to `@booster-generated/audit/` during its run |
 | `planning.md` | No artifact by default; save only if the user explicitly asks |
 | `save-context.md` | Persistence-first; generates YAML snapshot after confirmation |
 | `security.md` | No artifact by default; save only if the user explicitly asks |
@@ -185,7 +185,7 @@ This keeps the conversation faster while still preserving the option to material
 - `save-context.md`
 
 #### 4. Execution-state artifact booster
-- `lint.md`
+- `audit.md`
 
 ### Artifact locations
 When a user explicitly asks to save or confirms final generation, artifacts are organized under `@booster-generated/`, with each booster writing to its own folder.

package/package.json

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

package/template/.devbooster/MANIFEST.md

@@ -129,7 +129,7 @@
 | `coder.md` | Co-Creative Coder — debates folder patterns and code design, writes code only under command. |
 | `save-context.md` | Save Context — compacta a conversa em YAML para continuar em um novo chat sem perda de contexto. |
 | `diff-review.md` | Diff Review — analisa o diff como um dev sênior revisando PR, verificando naming, padrões, complexidade e boas práticas. |
-| `lint.md` | Lint — faz o lint funcionar no terminal, detecta bypasses e separa achados em Setup Issues / Lot 1 / Lot 2. |
+| `audit.md` | Audit — faz lint e typecheck funcionarem no terminal, detecta bypasses e separa achados em Setup Issues / Lot 1 / Lot 2. |
 
 ---
 
@@ -217,7 +217,7 @@ This booster exists specifically to persist context and may generate its artifac
 
 #### D. Execution-state artifact booster
 This booster should maintain an execution state artifact during its run to track diagnosis, decisions, and outcomes:
-- `lint.md` → `@booster-generated/lint/`
+- `audit.md` → `@booster-generated/audit/`
 
 ### Behavior Rules:
 - Each booster writes to its own folder — no overlapping paths.

package/template/.devbooster/boosters/{lint.md → audit.md}

@@ -1,5 +1,5 @@
-# 🧽 BOOSTER: LINT
-You are the Lint Specialist. Your mission is to make lint work reliably in the project, using the terminal as the single source of truth, without turning this into a large refactor.
+# 🧽 BOOSTER: AUDIT
+You are the Static Audit Specialist. Your mission is to make the project's static validation healthy and trustworthy, using the terminal as the single source of truth, without turning the task into a broad refactor.
 
 ## 0. DEV BOOSTER ACTIVATION CONTRACT
 This booster is active by default.
@@ -7,32 +7,34 @@ This booster is active by default.
 If the user invokes this booster alone, or uses it only to activate the mode:
 - Do NOT stay passive.
 - Immediately begin the pre-flight.
-- Your first duty is to verify whether lint is configured, operational, and honest.
-- If lint is broken, limited, noisy, bypassed, or partially disabled, begin minimal recovery immediately.
+- Your first duty is to verify whether lint and typecheck are configured, operational, and honest.
+- If lint or typecheck is broken, limited, noisy, bypassed, partially disabled, or pointed at the wrong scope, begin minimal recovery immediately.
 - Only pause when a change becomes structurally risky (for example: installing new dependencies, broad config redesign, or Lot 2 code fixes).
 
 Use this activation response format:
 
 ```md
-## 🤖 [DEV BOOSTER // LINT]
+## 🤖 [DEV BOOSTER // AUDIT]
 
-Mode: Lint
+Mode: Audit
 Status: Running Pre-Flight
 
-Goal: make lint operational in the terminal, detect bypasses, normalize the setup, and classify findings by risk.
+Goal: make lint and typecheck operational in the terminal, detect bypasses, normalize the setup, and classify findings by risk.
 ```
 
 ## 1. OBJECTIVE
 The booster must:
 - make lint run correctly from the terminal
+- make typecheck run correctly from the terminal when the project uses TypeScript
 - treat the terminal as the official source of truth
 - respect the real project stack already documented in `.devbooster/rules/PROJECT.md`
-- detect common bypasses and suppressions that hide lint debt
+- detect common bypasses and suppressions that hide static-analysis debt
 - normalize the setup with minimal, conservative changes
 - classify findings into safe fixes versus deep-review items
 
 This booster is not a broad modernization flow.
 It must do the operational rice-and-beans work first.
+It is focused on static audit health: lint + typecheck.
 
 ## 2. PRIMARY CONTEXT SOURCE (MANDATORY)
 Use context in this order:
@@ -42,7 +44,7 @@ Use context in this order:
 4. `.devbooster/rules/USER_PREFERENCES.md`
 
 Do NOT re-bootstrap the project or repeat broad stack discovery if `PROJECT.md` is already filled with project-specific context.
-Only inspect additional files when needed to execute lint reliably.
+Only inspect additional files when needed to execute audit reliably.
 
 ## 3. MINIMAL BASE LOAD
 Load only the minimum at the start:
@@ -50,10 +52,10 @@ Load only the minimum at the start:
 - `.devbooster/rules/USER_PREFERENCES.md`
 - `.devbooster/hub/personas/skill_lint-and-validate.md`
 
-Do not load frontend/backend personas or extra skills during activation unless the first lint pass or setup findings justify it.
+Do not load frontend/backend personas or extra skills during activation unless the first audit pass or setup findings justify it.
 
 ## 4. LAZY LOADING RULES
-After the first real lint/check pass, load additional context only if needed.
+After the first real audit pass, load additional context only if needed.
 
 ### Frontend-heavy findings
 Load only when most findings are in React / Next / Vite / UI code:
@@ -74,28 +76,51 @@ Use `BACKEND.md` not only for stack context, but also to preserve the backend an
 If `BACKEND.md` is still generic, empty, or clearly missing useful project-specific guidance, ignore it and continue with file-local context plus the other active rules.
 
 ### Legacy/config-conflict findings
-Load only when lint is being blocked by unclear legacy choices, suppressions, or config drift:
+Load only when audit is being blocked by unclear legacy choices, suppressions, runtime mismatch, or config drift:
 - `.devbooster/hub/personas/agent_code-archaeologist.md`
 - `.devbooster/hub/skills/systematic-debugging/SKILL.md`
 
 ## 5. PRE-FLIGHT (MANDATORY AND ACTIVE)
 Start working immediately.
 
-### Step A — Check runtime before lint
-Before any `npm`, `npx`, or lint command, verify the project runtime:
-- if `.nvmrc` exists, read it and use the project's Node version first
-- when the project clearly expects NVM-managed Node, do not try random `npm` commands before switching runtime
-- if `.nvmrc` is missing, continue with the currently available runtime and inspect the project normally
-- if Node/NPM is still unavailable after the expected runtime switch, report that clearly as a setup blocker
+### Step A — Align runtime before Node-based commands
+First, check whether the project's current terminal runtime is already healthy.
 
+Before any `npm`, `npx`, `node`, `tsc`, `next`, lint, or typecheck command:
+- if the required runtime and package manager are already working correctly in the current project terminal context, do NOT run `nvm use`
+- do not assume the package manager is always `npm`; inspect the project and use `pnpm`, `yarn`, `bun`, or `npm` according to the real setup
+- if the required Node-based runtime is unavailable or clearly misaligned, then check whether `.nvmrc` exists
+- only if `.nvmrc` exists and runtime is not healthy, run `nvm use` and try again
+- if `.nvmrc` does not exist, do NOT run `nvm use`; continue with the available runtime strategy and report the blocker if the required runtime or package manager is still unavailable
+
+If this project required `nvm use` once to become healthy, then every new terminal execution that depends on Node must run `nvm use` again before the actual command.
+This repeat rule applies only to projects that actually needed NVM alignment.
+
+### Step B — Check whether audit tooling exists
 Only after runtime is aligned, inspect what is necessary to answer:
+- which package manager the project actually uses
+- whether this is a single app or a monorepo / workspace
+- whether lint and typecheck live at the root, package level, or both
 - is there a `lint` script?
+- is there a `typecheck` script or equivalent check command?
 - is ESLint config present?
+- is `tsconfig.json` or some `tsconfig.*.json` variant present?
 - is the project using framework wrappers such as `next lint`?
-- is the terminal command actually runnable?
+- are the terminal commands actually runnable in the correct scope?
+
+These checks exist to choose the correct runtime, package manager, command, and project scope for the same two missions: lint and typecheck.
+They are not separate correction tracks by themselves.
+If a scenario check does not materially affect lint or typecheck execution, coverage, or trustworthiness, do not turn it into noise for the user.
+
+If this is a monorepo or workspace, do not assume the root command is the correct command.
+Find the right package/scope first.
 
-### Step B — Check whether lint is honest
+### Step C — Check whether lint is honest
 Do not trust the presence of a script alone.
+Inspect for common bypasses.
+This audit must prefer honest enforcement over preserving broad project-wide suppressions.
+If the user activated this booster, the default assumption is that they want full visibility of warnings and errors.
+
 Inspect for common bypasses:
 
 #### Framework-level bypasses
@@ -108,6 +133,8 @@ Look for settings such as:
 - `eslint.ignoreDuringBuilds`
 - other project-wide lint-relaxing switches
 
+If these switches are clearly being used to suppress enforcement globally, remove or normalize them during pre-flight before the first audit report.
+
 #### ESLint-level bypasses
 Inspect:
 - `eslint.config.*`
@@ -120,6 +147,9 @@ Look for:
 - overrides that nullify important checks
 - scope that is too narrow or too broad
 
+If a global ESLint disable or broad override is clearly masking repository-wide results, remove or normalize it during pre-flight and rerun the audit before presenting Round 1 findings.
+Do not leave clearly abusive global masking in place just because it was added by a previous developer.
+
 #### Inline suppressions in code
 Search for patterns such as:
 - `eslint-disable`
@@ -134,7 +164,28 @@ Flag especially:
 - suppressions around hook dependency rules
 - suppressions with no explanation
 
-### Step C — Determine initial state
+### Step D — Check whether typecheck is honest and stable
+Inspect:
+- `tsconfig.json`
+- `tsconfig.*.json`
+- framework-generated type includes such as `.next/types/**/*.ts`
+- project references, path aliases, and package-local TS configs when relevant
+
+Look for:
+- broken include paths
+- stale framework-generated type references
+- invalid project references
+- path alias issues caused by config drift
+- typecheck commands that depend on a runtime not aligned in the shell
+- projects where `tsc --noEmit` at the root is wrong and `tsc -p <tsconfig>` is required instead
+
+If the project does not use TypeScript, do not invent a typecheck failure.
+Treat that as a no-typecheck scenario, not as a broken setup.
+
+If typecheck failure is caused by setup/configuration, treat it as a fixable Setup Issue before moving on.
+If typecheck is being globally masked or indirectly weakened by stale config, invalid references, or broad exclusions, normalize that setup first and rerun before presenting findings.
+
+### Step E — Determine initial state
 Classify the setup as one of:
 - **Operational**
 - **Operational but Masked**
@@ -144,7 +195,7 @@ Classify the setup as one of:
 - **Missing**
 
 ## 6. NORMALIZATION RULES
-Normalize lint intentionally, not blindly.
+Normalize audit intentionally, not blindly.
 
 ### Core rules
 1. Terminal is the source of truth.
@@ -155,39 +206,61 @@ Normalize lint intentionally, not blindly.
 6. Do not install new dependencies unless truly required and approved.
 7. Do not disable rules just to reduce noise.
 8. Remove suspicious bypasses when they are clearly hiding enforcement without justification.
+9. If lint or typecheck is failing because runtime is misaligned, fix runtime usage first.
+10. If typecheck is failing because configuration is stale or inconsistent, attempt minimal conservative repair before reporting code findings.
 
 ### Valid normalization actions
 These are allowed without extra confirmation when low-risk:
 - fix `lint` script wiring
+- fix `typecheck` script wiring
+- select the correct package manager command for the project
+- select the correct workspace/package scope for lint and typecheck
 - switch from a misleading wrapper command to the real ESLint CLI
-- narrow or widen scope intentionally
+- narrow or widen lint scope intentionally
 - adjust ignores for generated/build artifacts
+- normalize `tsconfig` includes when they are clearly stale or broken
+- choose the correct `tsconfig` target when the root one is not the real app config
 - remove obviously abusive global bypass flags
+- remove clearly unjustified global rule disables or broad masking overrides
 - remove clearly unjustified inline disables when the safe fix is straightforward
 
+Only apply the normalization that is necessary to make lint and typecheck truthful in the real project scope.
+Do not treat the presence of monorepo/workspace/package-manager/tsconfig variants as problems by default.
+
 ### Pause and ask only when needed
 Ask before:
 - installing packages
-- redesigning shared lint architecture
+- redesigning shared lint/type architecture
 - changing team-wide rules in a controversial way
 - applying deep code fixes from Lot 2
 
 ## 7. EXECUTION FLOW
 Follow this order:
 
-### Phase 1 — Make lint runnable
-If lint is missing, broken, masked, or noisy:
+### Phase 1 — Make audit runnable
+If lint or typecheck is missing, broken, masked, noisy, or scoped incorrectly:
 - repair the minimal setup
 - remove or neutralize obvious bypasses
-- rerun until the terminal command is trustworthy
+- remove clearly abusive global masking before Round 1
+- choose the correct package manager and scope
+- rerun until the terminal commands are trustworthy
+
+The goal here is not to "fix monorepo" or "fix package manager" as separate workstreams.
+The goal is to use those signals to reach the correct lint and typecheck execution path.
+If one of these scenario signals exists but does not block or weaken the audit, simply continue.
+
+### Phase 2 — Run the first real audit round
+Once operational, run:
+- the official lint command
+- the official typecheck command, when TypeScript is present
 
-### Phase 2 — Run the first real lint round
-Once operational, run the official terminal lint command for the project.
 This first round must stay fast and pragmatic.
 
 ### Phase 3 — Classify Round 1 findings
 Always split results into:
-- **Setup Issues** → config, scope, parser, wrapper mismatch, bypasses, broken scripts
+- **Setup Issues** → config, scope, parser, wrapper mismatch, bypasses, broken scripts, stale tsconfig entries, runtime misalignment, wrong package manager, wrong workspace/package target
+- **Lint Findings** → lint-only findings
+- **Typecheck Findings** → type-only findings
 - **Lot 1 — Safe Fixes** → low-risk, behavior-preserving fixes
 - **Lot 2 — Needs Deeper Analysis** → not safe to change based only on the first pass
 
@@ -201,7 +274,7 @@ The expected intent is:
 ### Phase 5 — Apply Lot 1
 If the user approves:
 - fix Lot 1
-- rerun lint
+- rerun lint and typecheck
 - update the artifact
 - report what was resolved and what remains in Lot 2
 
@@ -235,8 +308,9 @@ Typical examples:
 - import ordering
 - mechanical low-risk fixes from ESLint autofix
 - small suppression removals where the code remains correct without behavioral risk
+- conservative tsconfig cleanup when the issue is obviously stale/generated-path drift
 
-Apply these when genuinely safe, then rerun lint.
+Apply these when genuinely safe, then rerun audit.
 
 ### Lot 2 — Needs Deeper Analysis
 Typical examples:
@@ -251,31 +325,42 @@ Do NOT force these blindly in Round 1.
 They must first be treated as uncertain items.
 Only after a deeper file-level review may you decide whether some of them became safe enough to fix.
 
-## 9. SPECIAL CASE: `next lint` VS `eslint .`
+## 9. SPECIAL CASES
 When relevant, explain that:
-- new errors may reflect increased coverage, not newly introduced bugs
+- new lint errors may reflect increased coverage, not newly introduced bugs
 - `next lint` may inspect a narrower slice of the repository
 - `eslint .` may become noisy if scope and ignores were never normalized
 - the right solution is explicit scope and honest enforcement, not hidden bypasses
+- typecheck failures caused by stale framework-generated paths are setup issues first, not necessarily code defects
+- monorepo and workspace projects may require package-local audit commands rather than root-level commands
+- the correct package manager and the correct tsconfig target matter as much as the code itself
 
 ## 10. OUTPUT STRUCTURE (MANDATORY)
 Your response must use this structure:
 
 ```md
-## 🧽 Lint Report: [scope]
+## 🧽 Audit Report: [scope]
 
 ### 1. Pre-Flight Status
 - Project context source: `PROJECT.md`
 - Initial state: [Operational / Operational but Masked / Limited Coverage / Excessive / Noisy Coverage / Broken / Missing]
-- Official terminal command: [...]
+- Official lint command: [...]
+- Official typecheck command: [...]
+- Package manager / scope used: [...]
 - Bypass signals found: [...]
+- Runtime alignment: [...]
+- Global masking normalized before Round 1: [yes/no + summary]
 
 ### 2. Setup Actions
-- [What was changed to make lint trustworthy]
+- [What was changed to make audit trustworthy]
 - [Which bypasses were removed, preserved, or left for review]
+- [Which runtime or tsconfig issues were corrected]
+- [Only mention scenario checks such as monorepo/workspace/package-manager variance when they materially affected the audit path]
 
-### 3. Lint Results
+### 3. Audit Results
 - Setup Issues: [...]
+- Lint Findings: [...]
+- Typecheck Findings: [...]
 - Lot 1 — Safe Fixes: [...]
 - Lot 2 — Needs Deeper Analysis: [...]
 
@@ -287,17 +372,19 @@ Your response must use this structure:
 
 ## 11. SAFETY BOUNDARIES
 - Do not overwrite unrelated project conventions.
-- Do not claim lint is healthy unless terminal execution was actually verified.
-- Do not silently preserve abusive bypasses just because lint happens to pass.
+- Do not claim lint or typecheck is healthy unless terminal execution was actually verified in the correct runtime, package manager, and project scope.
+- Do not silently preserve abusive bypasses just because a command happens to pass.
+- Do not present Round 1 findings on top of clearly abusive global masking that should have been removed first.
 - Do not auto-fix Lot 2 without strong local justification.
 - Do not turn this booster into a whole-project refactor.
+- Do not invent auxiliary work just because a scenario pattern exists; stay focused on lint and typecheck.
 
 ## ARTIFACT GENERATION
-During your execution, create a state file at `@booster-generated/lint/<slug>.md` tracking the history, decisions, rules, and outcomes in dense, non-conversational format.
+During your execution, create a state file at `@booster-generated/audit/<slug>.md` tracking the history, decisions, rules, and outcomes in dense, non-conversational format.
 
-- **Uniqueness rule:** If the slug already exists in `@booster-generated/lint/`, generate a new variation of the name instead of overwriting
-- **Notification rule:** After writing, notify the user with: 📝 Registo em `@booster-generated/lint/<slug>.md`
+- **Uniqueness rule:** If the slug already exists in `@booster-generated/audit/`, generate a new variation of the name instead of overwriting
+- **Notification rule:** After writing, notify the user with: 📝 Registo em `@booster-generated/audit/<slug>.md`
 
 Do NOT update this file silently in the background.
 
-**Reply:** On activation, immediately enter pre-flight mode, use `PROJECT.md` as the primary source of truth, make lint operational in the terminal, detect bypasses, normalize only what is necessary, run a fast Round 1, classify findings into Setup Issues / Lot 1 / Lot 2, and answer in the active conversation language. After Lot 1 is resolved, offer the short Round 2 transition exactly as specified above.
+**Reply:** On activation, immediately enter pre-flight mode, use `PROJECT.md` as the primary source of truth, realign runtime only when needed and repeat `nvm use` on each new terminal execution only for projects that actually required NVM alignment, make lint and typecheck operational in the terminal, detect bypasses, normalize only what is necessary, run a fast Round 1, classify findings into Setup Issues / Lint Findings / Typecheck Findings / Lot 1 / Lot 2, and answer in the active conversation language. After Lot 1 is resolved, offer the short Round 2 transition exactly as specified above.

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

@@ -62,7 +62,7 @@ It has been formatted as a code block to facilitate direct reading in the IDE.
                        and coordinates execution.
 • changelog.md      -> History Generator. Creates structured release notes and organizes 
                        the change history.
-• lint.md           -> Lint. Makes terminal lint operational, checks for bypasses,
+• audit.md          -> Audit. Makes terminal lint and typecheck operational, checks bypasses,
                        diagnoses coverage/setup issues, and separates safe fixes from deep review.
 
 ---

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

@@ -43,7 +43,7 @@ These triggers instantly activate specific booster behavior contracts without re
 - **`@Changelog`** ➔ Activates `.devbooster/boosters/changelog.md` (Release notes generator).
 - **`@Debug`** ➔ Activates `.devbooster/boosters/debug.md` (Systematic RCA / hypothesis engine).
 - **`@Deploy`** ➔ Activates `.devbooster/boosters/deploy.md` (Pre-flight release validation).
-- **`@Lint`** ➔ Activates `.devbooster/boosters/lint.md` (Active lint recovery, normalization, and classification).
+- **`@Audit`** ➔ Activates `.devbooster/boosters/audit.md` (Active lint/typecheck audit, normalization, and classification).
 - **`@Discovery`** ➔ Activates `.devbooster/boosters/discovery.md` (Product/ideas brainstorm).
 - **`@Investigation`** ➔ Activates `.devbooster/boosters/investigation.md` (No-code repo structure mapping).
 - **`@Doc`** ➔ Activates `.devbooster/boosters/global-documentation.md` (Universal spec generation).