bms-speckit-plugin 6.10.0 → 6.10.1

package/.claude-plugin/plugin.json

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

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