bms-speckit-plugin 6.0.0 → 6.1.0

package/agents/quality-control.md

@@ -49,6 +49,8 @@ You are a senior quality control engineer performing a comprehensive audit of a
 
 ## Phase A: Code Errors (MUST pass before other phases)
 
+### A1. Standard Checks
+
 1. Run the build command (`npm run build`, `tsc`, `python -m py_compile`, etc.)
 2. Run linter (`eslint .`, `flake8`, `ruff check`, etc.)
 3. Run the full test suite (`npm test`, `pytest`, etc.)
@@ -59,6 +61,50 @@ You are a senior quality control engineer performing a comprehensive audit of a
    - Re-run to confirm fix
 5. Repeat until all three (build + lint + test) pass with zero errors
 
+### A2. Runtime Safety Patterns
+
+Build and lint miss an entire class of runtime errors — type-correct syntax that crashes when executed. These checks close that gap. **Detect the project language(s) first, then apply the relevant checks.**
+
+#### Language Config Strictness
+
+Check that the project's type checker / compiler is configured for maximum strictness:
+
+- **TypeScript** — `tsconfig.json` should have `"strict": true` (or at minimum: `noImplicitAny`, `strictNullChecks`, `noImplicitReturns`, `noUncheckedIndexedAccess`). Enable and fix resulting errors.
+- **Python** — If using mypy/pyright, check config has `strict = true` or equivalent. If no type checker is configured, flag it.
+- **Go** — Verify `go vet` passes. Check for unchecked errors (`errcheck`).
+- **Rust** — Verify `#![deny(warnings)]` or strict clippy lints are enabled.
+- **Other** — Check for the language's equivalent strict/lint configuration.
+
+#### Type Mismatch Patterns
+
+Grep source files for patterns where a value of one type is used where another type is expected. These are the most common causes of runtime crashes that pass build/lint:
+
+1. **Iterable/collection confusion** — A function returns one collection type but the caller treats it as another:
+   - Spreading non-iterables: `[...obj]` where `obj` is a plain object (JS/TS crashes), `[...fn()]` where `fn` returns a dict/object instead of a list/array
+   - Iterating dicts/objects: `for x in fn()` where `fn` returns a dict (Python iterates keys, not values)
+   - Calling collection methods on wrong types: `.map()`, `.filter()`, `.reduce()` on non-arrays; `.keys()` on a list instead of a dict
+   - **Fix:** Add explicit return type annotations on the function, add runtime type checks at the call site (e.g., `Array.isArray()`, `isinstance()`)
+
+2. **Null/undefined/None access** — Chained property or method access on values from external sources (API responses, DB results, user input, config files) without null guards:
+   - JS/TS: `data.result.items.map(...)` where any level could be `undefined`
+   - Python: `data["result"]["items"]` where any key could be missing
+   - **Fix:** Add optional chaining, default values, or explicit null/key-existence checks
+
+3. **Type assertion/cast bypass** — Code that overrides the type system's safety checks:
+   - TS: `as SomeType`, `!` non-null assertion
+   - Python: `cast()`, `# type: ignore`
+   - Go: unchecked type assertions `val := x.(Type)` without `, ok` pattern
+   - **Fix:** Verify each assertion is actually correct. Replace with type guards or proper error handling where possible
+
+4. **Implicit type coercion** — Operations that silently convert types, masking bugs:
+   - JS/TS: `==` instead of `===`, string concatenation with numbers (`"count: " + count`)
+   - Python: comparing different types without explicit conversion
+   - **Fix:** Use strict equality, explicit type conversion
+
+5. **Missing return type annotations on data transformers** — Functions that reshape, map, filter, or aggregate data should always have explicit return types. Without them, the type system infers too broadly and callers may use the result incorrectly.
+   - Grep for exported functions and functions whose results are spread or iterated
+   - **Fix:** Add explicit return type annotations
+
 ## Phase B: Security Audit
 
 1. Run `npm audit` or `pip audit` to check for known vulnerabilities
@@ -162,6 +208,8 @@ After completing all phases, provide a summary report:
 - [ ] Build: PASS/FAIL (X errors fixed)
 - [ ] Lint: PASS/FAIL (X errors fixed)
 - [ ] Tests: PASS/FAIL (X failures fixed)
+- [ ] Language config strictness: PASS/SKIP (X issues fixed)
+- [ ] Runtime safety patterns: PASS (X type mismatches fixed)
 
 ### Security
 - [ ] No hardcoded secrets

package/blueprints/bms-speckit-pipeline.yaml

@@ -288,6 +288,16 @@ chain_sequence:
         For EACH task, execute this rolling QC cycle:
 
         1. IMPLEMENT — write code following TDD (tests first, then implementation)
+           RUNTIME SAFETY RULES (prevent errors that build/lint miss):
+           - Always add explicit return type annotations on data transformation
+             functions. Never rely on type inference for functions whose return
+             values are spread, iterated, or passed to collection methods
+           - Never spread or iterate a function return value without verifying
+             it returns the expected collection type (array not object, list not dict)
+           - Use strict equality, add null/undefined/None guards for external
+             data (API responses, DB results, config, user input)
+           - Write unit tests that execute data transformation functions and
+             verify the output type and shape
         2. INLINE QC — immediately after implementation, run:
            a. Build/compile — fix any type or build errors
            b. Lint — fix all lint errors and warnings
@@ -296,6 +306,9 @@ chain_sequence:
               XSS, unvalidated input in the code you just wrote
            e. UX check — if UI code was changed, verify error messages are
               actionable, loading states exist, and user feedback is present
+           f. Runtime safety scan — grep for spread/iteration on non-collection
+              types, missing return type annotations on data transformation
+              functions, loose equality operators. Fix any found.
         3. FIX — fix every issue found in step 2, then re-run checks
         4. COMMIT — only commit when build + lint + tests all pass with zero errors
         5. NEXT TASK — proceed to the next task

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bms-speckit-plugin",
-  "version": "6.0.0",
+  "version": "6.1.0",
   "description": "Chain-orchestrated development pipeline: /bms-speckit takes requirements and runs brainstorm → constitution → specify → plan → tasks → analyze → implement → verify with per-step error handling",
   "files": [
     ".claude-plugin/",

package/skills/bms-speckit-auto/SKILL.md

@@ -178,14 +178,18 @@ After the subagent completes, update tasks 1-8 as completed using TaskUpdate, th
 - **Max iterations:** 10
 - **Pattern:** Rolling Review — each task gets its own QC cycle before moving to the next
 - **Per-task cycle:**
-  1. **IMPLEMENT** — write code following TDD (tests first, then implementation)
+  1. **IMPLEMENT** — write code following TDD (tests first, then implementation). **Runtime safety rules:**
+     - Always add explicit return type annotations on data transformation functions — never rely on type inference for functions whose return values are spread, iterated, or passed to collection methods
+     - Never spread or iterate a function's return value without verifying it returns the expected collection type (e.g., array not object, list not dict)
+     - Use strict equality, add null/undefined/None guards for external data (API responses, DB results, config, user input)
+     - Add unit tests that actually execute data transformation functions and verify the output type and shape
   2. **INLINE QC** — immediately run: build, lint, ALL tests, security quick scan, UX check
   3. **FIX** — fix every issue found, re-run checks
   4. **COMMIT** — only commit when build + lint + tests pass with zero errors
   5. **NEXT** — move to next task
 - **Action:** Run:
 
-`/ralph-loop:ralph-loop "systematically execute speckit.implement via the Skill tool to complete every task defined in {TASKS_PATH} with strict adherence to specification requirements. IMPORTANT: apply rolling QC after EACH task — after implementing a task run build and fix build errors, run linter and fix lint errors, run ALL tests (not just new ones) and fix failures, check for hardcoded secrets and injection vulnerabilities in code you just wrote, verify UI code has actionable error messages and loading states — only commit when build plus lint plus tests all pass with zero errors then proceed to next task. Report progress to the user after each task: output [Task N/total] DONE — task_name. Do NOT batch QC at the end. Maintain atomic commits after each successful task with clear traceability, avoid requesting confirmation and proceed autonomously, once all tasks are implemented invoke speckit.analyze via the Skill tool to perform a full validation pass, automatically apply all recommended improvements or corrections, re-run all tests to confirm stability and zero regression, and only output <promise>FINISHED</promise> after every task is fully completed, validated, and aligned with production-grade quality standards" --completion-promise "FINISHED" --max-iterations 10`
+`/ralph-loop:ralph-loop "systematically execute speckit.implement via the Skill tool to complete every task defined in {TASKS_PATH} with strict adherence to specification requirements. IMPORTANT: apply rolling QC after EACH task — after implementing a task run build and fix build errors, run linter and fix lint errors, run ALL tests (not just new ones) and fix failures, check for hardcoded secrets and injection vulnerabilities in code you just wrote, verify UI code has actionable error messages and loading states. RUNTIME SAFETY: always add explicit return type annotations on data transformation functions, never spread or iterate a function return value without verifying it returns the expected collection type, use strict equality and null guards for external data, write tests that execute data transformers and verify output type and shape. Only commit when build plus lint plus tests all pass with zero errors then proceed to next task. Report progress to the user after each task: output [Task N/total] DONE — task_name. Do NOT batch QC at the end. Maintain atomic commits after each successful task with clear traceability, avoid requesting confirmation and proceed autonomously, once all tasks are implemented invoke speckit.analyze via the Skill tool to perform a full validation pass, automatically apply all recommended improvements or corrections, re-run all tests to confirm stability and zero regression, and only output <promise>FINISHED</promise> after every task is fully completed, validated, and aligned with production-grade quality standards" --completion-promise "FINISHED" --max-iterations 10`
 
 - **Done:** Update task 10 as completed. Output `[Step 10/12] DONE — all tasks implemented and verified`