dev-booster 1.16.6 → 1.16.8

package/package.json

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

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

@@ -8,7 +8,7 @@ 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 and typecheck are configured, operational, and honest.
-- If lint or typecheck is broken, limited, noisy, bypassed, or partially disabled, begin minimal recovery immediately.
+- 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:
@@ -34,6 +34,7 @@ The booster must:
 
 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:
@@ -85,26 +86,41 @@ Start working immediately.
 ### 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, typecheck, or build command:
-- if `node` and `npm` are already working correctly in the current project terminal context, do NOT run `nvm use`
-- if `node` or `npm` is unavailable or clearly misaligned, then check whether `.nvmrc` exists
+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 Node/NPM is still unavailable
+- 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?
+- is there a `typecheck` script or equivalent check command?
 - is ESLint config present?
-- is `tsconfig.json` or equivalent present?
+- is `tsconfig.json` or some `tsconfig.*.json` variant present?
 - is the project using framework wrappers such as `next lint`?
-- are the terminal commands 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 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
@@ -117,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.*`
@@ -129,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`
@@ -148,6 +169,7 @@ 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
@@ -155,8 +177,13 @@ Look for:
 - 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:
@@ -186,13 +213,20 @@ Normalize audit intentionally, not blindly.
 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 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
@@ -204,25 +238,29 @@ Ask before:
 Follow this order:
 
 ### Phase 1 — Make audit runnable
-If lint or typecheck is missing, broken, masked, or noisy:
+If lint or typecheck is missing, broken, masked, noisy, or scoped incorrectly:
 - repair the minimal setup
 - remove or neutralize obvious bypasses
+- 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
-- optionally the project's build sanity command afterward if it already exists and fits the stack
 
 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, stale tsconfig entries, runtime misalignment
+- **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
-- **Build Findings** → build-only findings when relevant
 - **Lot 1 — Safe Fixes** → low-risk, behavior-preserving fixes
 - **Lot 2 — Needs Deeper Analysis** → not safe to change based only on the first pass
 
@@ -237,7 +275,6 @@ The expected intent is:
 If the user approves:
 - fix Lot 1
 - rerun lint and typecheck
-- rerun build sanity when it is part of the current audit flow
 - update the artifact
 - report what was resolved and what remains in Lot 2
 
@@ -295,6 +332,8 @@ When relevant, explain that:
 - `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:
@@ -307,19 +346,21 @@ Your response must use this structure:
 - Initial state: [Operational / Operational but Masked / Limited Coverage / Excessive / Noisy Coverage / Broken / Missing]
 - 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 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. Audit Results
 - Setup Issues: [...]
 - Lint Findings: [...]
 - Typecheck Findings: [...]
-- Build Findings: [...]
 - Lot 1 — Safe Fixes: [...]
 - Lot 2 — Needs Deeper Analysis: [...]
 
@@ -331,17 +372,40 @@ Your response must use this structure:
 
 ## 11. SAFETY BOUNDARIES
 - Do not overwrite unrelated project conventions.
-- Do not claim lint or typecheck is healthy unless terminal execution was actually verified.
+- 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/audit/<slug>.md` tracking the history, decisions, rules, and outcomes in dense, non-conversational format.
 
+This artifact is mandatory for this booster.
+Create it even when:
+- there is only one finding
+- the setup is already healthy
+- the audit result is small
+- the user stops after Round 1
+
+The artifact must begin in the first real audit round and then be updated continuously as the audit progresses.
+Update it after every meaningful round-trip in the flow, especially when:
+- pre-flight / Round 1 is completed
+- Lot 1 is approved and executed
+- Round 2 / deeper Lot 2 analysis begins
+- deeper analysis reclassifies findings
+- new fixes are applied
+- the user asks follow-up questions that materially change the audit state
+
+Treat this file as the persistent audit trail for the session.
+It must preserve what was found, what was changed, what was intentionally left untouched, and what still needs review.
+This is important both for continuity in a later session and for explaining regressions or side effects if something breaks afterward.
+
 - **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 skip artifact creation for small audits.
 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, realign runtime before every Node-based terminal command when `.nvmrc` exists, 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 / Build 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.
+**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 already established by the user and current conversation. After Lot 1 is resolved, offer the short Round 2 transition exactly as specified above.