dev-booster 1.16.10 → 1.16.11

package/package.json

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

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

@@ -40,6 +40,8 @@ Purpose:
 
 Stage 1 is the only stage authorized automatically on activation.
 Stage 1 ends only when setup is healthy enough for a trustworthy audit pass.
+A setup is NOT healthy if abusive masking, broad suppressions, or lazy bypasses still remain in the project.
+
 At the end of Stage 1, the booster MUST:
 - update the artifact
 - summarize briefly in chat
@@ -209,6 +211,7 @@ Search for:
 - `eslint-disable-line`
 - `@ts-ignore`
 - `@ts-expect-error`
+- `@ts-nocheck`
 
 Flag especially:
 - file-wide disables
@@ -216,7 +219,8 @@ Flag especially:
 - suppressions around hook dependency rules
 - suppressions with no explanation
 
-If a suppression is clearly abusive, stale, or only there to lazily silence the tool, remove it during pre-flight or Lot 1 instead of merely reporting it.
+If a suppression is clearly abusive, stale, or only there to lazily silence the tool, remove it during Stage 1 instead of merely reporting it.
+If abusive suppressions appear across many files, remove them across all affected files before declaring Stage 1 healthy.
 
 ### Step D — Stabilize typecheck
 Inspect when relevant:
@@ -276,8 +280,10 @@ Without extra confirmation, you may:
 - remove abusive global bypass flags
 - remove clearly unjustified global rule disables or broad masking overrides
 - remove clearly unjustified inline disables when safe
+- remove abusive `@ts-nocheck`, `@ts-ignore`, `eslint-disable`, or equivalent masking patterns wherever they are found
 
 Only normalize what is necessary to make lint and typecheck truthful in the real project scope.
+For abusive masking, do not be conservative: remove it.
 
 ### Ask before
 Ask before:
@@ -304,6 +310,8 @@ In Stage 1, edits must stay limited to setup-enabling work.
 Do not drift into general code audit or broad product-code cleanup before the Stage 2 checkpoint.
 
 Round 1 must NOT be reported as complete until this setup-only normalization pass has happened.
+Stage 1 must NOT be declared healthy while abusive masking still exists anywhere in the project.
+If abusive masking is found in 1 file or 1,000 files, remove it before moving on.
 
 When setup is complete:
 - generate/update the artifact
@@ -436,6 +444,7 @@ All deeper detail must go into the artifact.
 - Do not claim lint or typecheck is healthy unless terminal execution was actually verified in the correct runtime, package manager, and scope.
 - Do not silently preserve abusive bypasses just because a command passes.
 - Do not present Round 1 findings on top of masking that should already have been removed.
+- Do not declare Stage 1 healthy while abusive masking still exists in the project.
 - 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.
@@ -477,6 +486,7 @@ It must preserve:
 - what was intentionally left untouched
 - what still needs review
 - what remains pending for the user
+- which abusive masking patterns were removed during Stage 1
 
 The artifact, not the chat, is the detailed memory of the audit.
 If something breaks later, this file must explain what was done and why.