qatools-cli 1.1.2 → 1.1.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qatools-cli",
-  "version": "1.1.2",
+  "version": "1.1.3",
   "description": "CLI for QA Tools — requirements, epics, sprints, sessions, App Context sync, project agenda. The companion to qa-tools.com.",
   "bin": {
     "qatools": "./qatools.js"

package/qatools.js

@@ -1863,6 +1863,12 @@ Every claim, verdict, analysis, and recommendation MUST cite specific evidence:
 
 ## If you're unsure
 Say "I'm unsure" — that's better than guessing. Suggest what evidence would resolve the uncertainty.
+
+## Specialized skills
+
+There is a specific skill for **algorithmic and numerical** bugs: \`qa-numerical-verification.md\`. Read it when you're fixing a formula or any code where the bug is "wrong number" rather than "wrong structure".
+
+If you encounter a different recurring bug class that needs its own verification pattern (UI regressions, race conditions, data integrity, etc.), create a NEW specific skill (\`qa-<class>-verification.md\`) rather than expanding this file or building a monolithic "fix-checklist". The pattern is: principle here, specific category in its own skill, CLI enforces evidence regardless of category. Don't build a generic checklist for hypothetical categories — let real biting cases drive the need.
 `,
       "qa-numerical-verification.md": `---
 description: How to verify algorithmic and numerical bug fixes. Read this when fixing a formula, calculation, or any code where the bug is "wrong number" rather than "wrong structure".
@@ -1874,6 +1880,18 @@ Most evidence-first examples deal with structural bugs (NullReferenceException,
 
 This skill is for those bugs. The verification pattern is non-negotiable.
 
+## Before you start — entry-point checklist
+
+Stop here and answer these BEFORE writing any verification code:
+
+- [ ] Which input or test case actually triggers the bug? (Not "the system" — name a specific input.)
+- [ ] Does that input have non-zero, non-default values for the field the bug touches? (If everything is 0 or NULL, multiplying by anything gives the same result — the input cannot discriminate buggy from fixed code.)
+- [ ] If your input is non-discriminating: change it, or pick a different input. Never proceed with "the data doesn't show it".
+- [ ] Where will you write the expected and actual values? Answer: in the --evidence flag when you set status. If the values are large, also save them to a file you reference in evidence ("see /tmp/verify-2026-04-08.txt").
+- [ ] Can you compute the expected value by hand from the formula in under 60 seconds? If not, the formula is too complex for this verification — break it into pieces and verify each.
+
+If any answer is "I don't know", stop and ask. Don't guess.
+
 ## The pattern
 
 1. **Trivialize the input.** Pick values that make the formula readable. Set multipliers to 1, set inputs to round numbers (10, 100), set toggles to known states.