quality-guardian

Quality Guardian

Iron rule: do not treat "the command ran" as a quality conclusion. You must explain what was run, why it was run, where it failed, and whether it is allowed to continue.

Workflow

• Step 1: Assess the required checks ⚠️ REQUIRED
  • 1.1 Based on the type of change, determine whether to run lint, test, typecheck, or a combination of checks.
  • 1.2 Distinguish between quick verification and full verification.
• Step 2: Execute the quality gate ⚠️ REQUIRED
  • 2.1 Prefer scripts that actually exist in package.json.
  • 2.2 If there are no fine-grained scripts, then explain why only heavier checks can be run.
  • 2.3 ⚠️ Bypassing pnpm run to execute the quality gate：pnpm run lint will trigger a dependency status check → automatically pnpm install → may fail due to ERR_PNPM_IGNORED_BUILDS exit code 1, masking the real lint results. The correct approach is to call the binary directly:

    & "node_modules\.bin\eslint.cmd" .
    & "node_modules\.bin\vitest.cmd" run
    

    Or use npx <binary>(if the binary supports npx mode). Avoid introducing unnecessary dependency check side effects when executing quality gates.
• Step 3: Analyze the results
  • 3.1 Extract the failing files, error categories, and root causes, rather than pasting the entire log.
  • 3.2 Clarify whether this is a blocking issue, a suggested issue, or a known external issue.
• Step 4: Give a release conclusion
  • 4.1 Clearly state whether proceeding to commit, release, or the next stage is allowed.
  • 4.2 If certain checks were not run, explain the reason and the residual risk.

Common checks

• pnpm lint
• pnpm lint:md
• pnpm test

Project-specific tips

• If the repository provides a typecheck or equivalent type-checking script, it should be included in the quality gate; if not, you must clearly state that this layer of verification is currently missing.
• If the full test suite is too expensive, prioritize running the test files or test sets directly related to the scope of changes.
• When outputting the conclusion, strictly distinguish between "the script does not exist" and "the script passed."

Anti-patterns

• Not checking package.json and inventing scripts that do not exist.

• Dumping failure logs to the user verbatim without extracting the root cause.

• Pretending "everything passed" when the full checks were not run.

• Using pnpm run to execute lint/test, triggering unnecessary dependency status checks, causing ERR_PNPM_IGNORED_BUILDS to masquerade as a quality gate failure.

Pre-delivery checklist

• The quality gate has been selected based on the scope of changes.
• All commands used actually exist.
• The root cause of failure or residual risk has been clearly identified.
• The output includes a judgment on whether the next stage can proceed.