bms-speckit-plugin 6.10.1 → 6.10.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "bms-speckit",
-  "version": "6.10.1",
+  "version": "6.10.2",
   "description": "Chain-orchestrated development pipeline with 12-step autonomous workflow (brainstorm → research → constitution → specify → plan → tasks → analyze → implement with rolling QC → final quality gate → merge) and 9-dimension QC agent (code errors, security incl. SQL parameterization, deps, UX/UI, accessibility, deployment artifacts, cross-DB compatibility, real-DB integration testing, HOSxP business logic validation, brand/layout polish). Runs autonomously — never prompts for clarification.",
   "author": {
     "name": "manoirx"

package/agents/quality-control.md

@@ -50,6 +50,26 @@ You are a senior quality control engineer performing a comprehensive audit of a
 
 **Audit Process:**
 
+## Execution Rules — read before running any check
+
+**Never use `sleep N && cat <output>` to wait for a background job.** The Claude Code harness blocks long leading-sleep commands and `sleep`-based polling loops because they waste tokens and burn cache. This rule applies even when waiting for typecheck/lint/test runs that take 30–120 seconds.
+
+Use one of these patterns instead, in priority order:
+
+1. **Run synchronously (preferred for QC).** Build, lint, test, and audit commands are short enough to run as a normal foreground `Bash` call with a generous `timeout` parameter. Just call `npm run build`, `npm test`, `tsc -b`, `eslint .` directly and wait for the result. The QC pass is sequential by design — there is no concurrency benefit to backgrounding these checks.
+
+2. **If you genuinely need a background job** (e.g., starting a dev server while you run other checks against it): use `Bash` with `run_in_background: true`. The harness will notify you when the process exits — **do not poll**. Read the output once with the read-output mechanism after the notification arrives.
+
+3. **If you need to wait for a condition to become true** (e.g., dev server ready on a port): use the `Monitor` tool with an `until-loop` like `until curl -sf localhost:3000/health; do sleep 2; done` — this is the only sanctioned waiting pattern, and you'll be notified when the loop exits.
+
+**What NOT to do:**
+- ❌ `npm run build > /tmp/build.log 2>&1 &` followed by `sleep 60 && cat /tmp/build.log`
+- ❌ Any `sleep` longer than ~30s as a leading command
+- ❌ Polling loops that re-issue `cat` or `tail` against a log file every N seconds
+- ❌ Backgrounding short-lived checks (build/lint/test) "to save time" — they aren't long enough to benefit and you'll trigger the anti-poll guard
+
+**Why this matters here:** the QC audit fires many checks (build, lint, test, npm audit, accessibility scans, SQL validation queries). Running them in the background and then polling looks faster but costs extra agent turns when the harness blocks the polling, sometimes triggering self-recovery loops that re-run the same checks synchronously anyway. Just run them synchronously the first time.
+
 ## Phase A: Code Errors (MUST pass before other phases)
 
 ### A1. Standard Checks

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bms-speckit-plugin",
-  "version": "6.10.1",
+  "version": "6.10.2",
   "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

@@ -309,6 +309,7 @@ Only after the Verification Gate passes (`GATE=OK`), update tasks 1–8 as compl
 ### Step 10 — Final Quality Gate `[on_failure: STOP | max_retries: 3]`
 - **Progress:** Output `[Step 10/11] Final QC — running comprehensive quality audit...`
 - **Agent:** Dispatch `bms-speckit:quality-control` agent
+- **Subagent execution rule (REMIND THE AGENT):** in your dispatch prompt, instruct the QC agent that it MUST run build, lint, test, audit, and SQL-validation commands **synchronously** as foreground `Bash` calls with a generous `timeout` parameter. **Forbid `sleep N && cat <output>`-style polling against backgrounded jobs** — the harness blocks long leading-sleep commands and sleep-based polling, which causes the QC pass to stall and self-recover, costing extra turns. The full rule is documented at the top of the QC agent file under "Execution Rules"; just remind the agent to follow it.
 - **Purpose:** Final comprehensive sweep. Since inline QC already caught per-task issues, this focuses on **cross-cutting concerns** that can only be detected across the full codebase.
 - **Timeout:** 900s
 - **Focus areas:**