bms-speckit-plugin 6.10.0 → 6.10.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "bms-speckit",
-  "version": "6.10.0",
+  "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.0",
+  "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

@@ -294,6 +294,12 @@ Only after the Verification Gate passes (`GATE=OK`), update tasks 1–8 as compl
   4. **FIX** — fix every issue found in steps 2 and 3, re-run checks
   5. **COMMIT** — only commit when build + lint + unit tests + integration tests all pass with zero errors
   6. **NEXT** — move to next task
+- **CRITICAL — ralph-loop prompt sanitation:** The `/ralph-loop:ralph-loop` slash command currently does not quote `$ARGUMENTS` when handing the prompt to bash (a known upstream bug in `ralph-loop/commands/ralph-loop.md`). This means **any shell metacharacter in your prompt is interpreted before the ralph-loop script runs**, causing the loop to fail before it starts. When constructing the prompt below:
+  - **Never include backticks (`` ` ``) anywhere in the prompt.** Do not use markdown code spans for command names. Write `npm run build` as `'npm run build'` (single quotes) or as the words `the build command`.
+  - **Never include `$(...)` or `` `...` `` (command substitution).**
+  - **Never include unescaped double quotes** inside the prompt — they close the outer quoting. If you must mention a quoted string, use single quotes.
+  - **Avoid stray `&`, `|`, `;`, `<`, `>`, `\` in prose.** These are shell separators/redirections.
+  - **Pre-flight scrub:** before issuing the slash command, scan your constructed prompt and replace every backtick with a single quote, every `$(...)` with `the output of ...`, every internal `"` with `'`. If unsure, use only ASCII letters, digits, spaces, hyphens, em-dashes, parentheses, periods, commas, colons, and forward slashes.
 - **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. 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. SQL VALIDATION: before writing any SQL statement verify exact table and column names exist via bms-session-mcp-server list_tables/describe_table or bms-knowledge-mcp search_knowledge with hosxp collection, never guess column names, after writing test each query with EXPLAIN or LIMIT 0 via the query tool to confirm it executes without error. INTEGRATION TESTING: for every task that touches database or data-dependent logic run an integration test using the real bms-session-mcp-server query tool to execute the feature's SQL against the real HOSxP database (not mocks), flow the result through the actual code path, assert on concrete properties (row count, columns populated, types match, masked fields handled), use small LIMIT to avoid large result sets. If integration test fails investigate the real cause and fix it — do not relax the assertion. BUSINESS LOGIC: before writing any SQL state the business question it answers then consult bms-knowledge-mcp search_knowledge on hosxp collection to verify canonical table selection, soft-delete filters, correct date columns, join keys (hn/vn/an); use graph_search for multi-table relationships; for reporting queries also check moph or nhso collections for regulatory rules; cite the HOSxP convention in a code comment next to the query. 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`
@@ -303,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:**