bms-speckit-plugin 6.7.0 → 6.9.0

package/.claude-plugin/plugin.json

@@ -1,10 +1,10 @@
 {
   "name": "bms-speckit",
-  "version": "5.2.0",
-  "description": "Chain-orchestrated development pipeline with quality control agent. /bms-speckit runs brainstorm → constitution → specify → plan → tasks → analyze → implement → QC (UX/security/deps/code) → merge.",
+  "version": "6.9.0",
+  "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"
   },
   "license": "MIT",
-  "keywords": ["workflow", "tdd", "specification", "planning", "development"]
+  "keywords": ["workflow", "tdd", "specification", "planning", "development", "chain", "orchestrator", "autonomous"]
 }

package/package.json

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

@@ -7,6 +7,20 @@ description: Full automated development workflow. This skill should be used when
 
 Chain blueprint: `blueprints/bms-speckit-pipeline.yaml`
 
+## Autonomous Mode Contract — READ FIRST
+
+This skill runs **fully autonomously**. Once invoked, it must not prompt the user for anything until the pipeline finishes or hits a hard error it cannot self-resolve.
+
+**Hard rules — no exceptions:**
+
+- **Never ask clarification questions.** Do not emit `[NEEDS CLARIFICATION: ...]` blocks, A/B/C option tables, or "what should I do?" prompts back to the user at any point in the pipeline, including inside Step 5 (specify).
+- **Resolve all unknowns with documented defaults.** If a requirement is ambiguous, pick the industry-standard default, record it in the spec's `## Assumptions` section with a one-line rationale, and continue. The user can correct it later — blocking the pipeline on a question costs more than picking wrong.
+- **Never request confirmation between steps.** No "proceed?", no "is this OK?". Commit and move on.
+- **Never stop for optional choices.** Only stop for hard failures (build broken, tests failing after 3 retries, critical security issue the QC agent flagged). Everything else: pick a default, log it, continue.
+- **Override sub-skill clarification behavior.** Skills like `speckit.specify` have their own "ask up to 3 clarification questions" logic. When invoked through this pipeline, that logic is **disabled** — the sub-skill must default the answers and record them as assumptions.
+
+**Wrong entry point check:** if the user invoked this pipeline via `/speckit.specify`, `/speckit.plan`, or any other individual speckit slash command instead of `/bms-speckit:bms-speckit-auto`, those individual commands run only their single step. They will not execute the full 12-step chain. Only this skill (`bms-speckit-auto`) orchestrates the complete pipeline.
+
 ## Execution Rules
 
 1. Execute steps **sequentially** in chain order — never skip steps
@@ -56,6 +70,8 @@ Subagent prompt:
 """
 You are running the BMS Speckit specification and planning chain. Execute each step in order using the Skill tool. Do NOT ask for confirmation. Follow error handling policies exactly. **Commit and push after every important step.**
 
+**AUTONOMOUS MODE — NO USER PROMPTS.** This subagent runs without user interaction. You must not return control to the user with questions, option tables, or `[NEEDS CLARIFICATION]` markers under any circumstance. For every ambiguity: pick the industry-standard default, record it in the relevant artifact's `## Assumptions` section with a one-line rationale, and continue. Specifically, when invoking `speckit.specify` in Step 5, pass it the explicit instruction: "Do not emit `[NEEDS CLARIFICATION]` markers or option tables; resolve all ambiguities with documented defaults in an `## Assumptions` section and produce a complete spec in one pass." Verify the final `spec.md` contains zero clarification markers before committing. If the sub-skill still emits markers, the subagent must rewrite the spec to replace each marker with a default + assumption before committing.
+
 **IMPORTANT — Progress reporting:** Before starting each step, output a progress message to the user in this format:
 
 `[Step N/12] step_name — description...`
@@ -117,7 +133,9 @@ After completing each step, output:
 - **Skill:** `speckit.specify`
 - **Input:** Use the detailed specification output from Step 1 (brainstorm) **enriched with the research findings from Step 2**. Include recommended libraries, best practices, and compliance requirements from the research brief in the specification input.
 - **Knowledge lookup:** Use `mcp__bms-knowledge-mcp__search_knowledge` to search the `hosxp` collection for exact table names, field names, data types, and relationships needed by this feature. Reference actual HOSxP data structures in the spec.
-- **Output:** `specs/*/spec.md`
+- **Autonomy override (CRITICAL):** `speckit.specify` by default emits `[NEEDS CLARIFICATION]` markers and prompts the user with A/B/C option tables for ambiguous requirements. **This behavior is DISABLED in the auto pipeline.** Pass this instruction to the specify skill invocation verbatim:
+  > "Do NOT emit any `[NEEDS CLARIFICATION]` markers or option tables. For every ambiguous requirement, pick the industry-standard default, write the chosen value into the spec directly, and record it in a new `## Assumptions` section at the end of the spec with a one-line rationale. The pipeline is running autonomously — the user will correct assumptions after the run if needed. Never block the pipeline with a question."
+- **Output:** `specs/*/spec.md` — must contain zero `[NEEDS CLARIFICATION]` markers. Verify before commit; if any remain, resolve them with a default and record in `## Assumptions`.
 - **Timeout:** 300s
 - **Retry:** up to 2 attempts
 - **Post-action:** Commit all files and push. Message: `feat(speckit): add feature specification`
@@ -151,12 +169,96 @@ After completing each step, output:
 - **Post-action:** Commit all files and push. Message: `feat(speckit): add cross-artifact analysis report`
 - **Done:** Output `[Step 8/12] DONE — analysis complete`
 
-After all steps complete, return: the feature name, number of tasks created, and the path to tasks.md.
+### Completion Contract — DO NOT RETURN UNTIL THIS IS SATISFIED
+
+Before returning to the main agent, perform these verification checks yourself using Bash/Read. Do NOT return a success message if any file is missing — exploration-only returns are a bug, not an acceptable outcome.
+
+1. **Identify the feature directory.** Run `ls -dt specs/*/ | head -1` — this is your feature path (e.g. `specs/003-my-feature/`). Capture the feature slug (basename without trailing slash).
+2. **Verify each required artifact exists and is non-empty** using `test -s <file>`:
+   - `specs/constitution.md`
+   - `specs/<slug>/research.md`
+   - `specs/<slug>/spec.md`
+   - `specs/<slug>/plan.md`
+   - `specs/<slug>/tasks.md`
+3. **Verify commits were made:** `git log --oneline -n 12` should show at least 5 speckit commits (brainstorm, research, constitution, specify, plan, tasks, analyze).
+4. **If any artifact is missing or empty, do NOT return failure — write it directly.** The `Skill` tool sometimes fails inside subagents (tool-access restrictions, one-shot mode). Your job is to ensure the artifact exists on disk regardless of how it got there:
+   - Read the relevant template from `.specify/templates/` (spec-template.md, plan-template.md, tasks-template.md)
+   - Fill it in using the in-memory content you already produced from brainstorm/research/specify
+   - `Write` the file, `git add`, `git commit`, `git push`
+   - Re-run the verification check
+5. **Return format — the LAST LINE of your response must be exactly this structured marker** (the main agent parses it; no prose after it):
+
+   `FEATURE=<slug>|SPEC=<path>|PLAN=<path>|TASKS=<path>|STATUS=OK`
+
+   If after the fallback write in step 4 some artifact is still missing, return:
+
+   `FEATURE=<slug-or-unknown>|MISSING=<comma-separated-list>|STATUS=INCOMPLETE`
 """
 
-After the subagent completes, update tasks 1-8 as completed using TaskUpdate, then output:
+### Phase 1 → Phase 2 Handoff — Verification Gate (MANDATORY)
+
+The subagent is one-shot — the Task tool dispatches it, waits, and returns a single text response. There is no SendMessage chaining. So the main agent **must verify artifacts exist on disk before proceeding**. A subagent that did only read-only exploration will return success-looking prose but leave `specs/*/` empty — do not trust the prose.
+
+**Step A — Parse the subagent marker.**
+Find the line beginning with `FEATURE=` in the subagent's output. Extract `<slug>`, `<spec>`, `<plan>`, `<tasks>`, `<status>`. If no marker is present, treat as `STATUS=INCOMPLETE`.
+
+**Step B — Verify artifacts on disk from the main context** (the subagent lies sometimes):
+
+```
+Bash: test -s specs/constitution.md \
+  && test -s specs/<slug>/spec.md \
+  && test -s specs/<slug>/plan.md \
+  && test -s specs/<slug>/tasks.md \
+  && echo "GATE=OK" || echo "GATE=MISSING"
+```
+
+**Step C — Branch:**
+- `GATE=OK` and marker `STATUS=OK` → verification passed. Proceed to Step 9.
+- Otherwise → run **Recovery Protocol**.
+
+#### Recovery Protocol
+
+**Attempt 1 — Retry subagent with a stricter recovery prompt.**
+
+Re-dispatch via Task tool:
+
+"""
+RECOVERY RUN. A previous Phase 1 execution returned without producing artifacts on disk at `specs/<slug>/`. The existing files may be partial. Your job now is to produce the missing artifacts — not to re-explore, not to re-research, not to ask questions.
+
+Required outputs (all must exist and be non-empty before you return):
+- specs/constitution.md
+- specs/<slug>/research.md
+- specs/<slug>/spec.md
+- specs/<slug>/plan.md
+- specs/<slug>/tasks.md
+
+Rules:
+1. Read `$ARGUMENTS` and every existing file under `specs/` to pick up where the prior run left off.
+2. If the `Skill` tool fails or is unavailable, do NOT retry it — `Write` the artifact directly using `.specify/templates/*.md` as the structure and content you know from the user requirement as the body.
+3. Resolve every ambiguity with a documented default in an `## Assumptions` section. Never emit `[NEEDS CLARIFICATION]` markers.
+4. After each file you write, `git add && git commit && git push` with message `feat(speckit): <step>`.
+5. Before returning, `test -s` each required file and `git log --oneline -n 12` to confirm.
+6. Return with the structured marker `FEATURE=<slug>|SPEC=<path>|PLAN=<path>|TASKS=<path>|STATUS=OK` as your final line, no prose after.
+"""
+
+After the retry returns, re-run Step B. If `GATE=OK`, proceed to Step 9.
+
+**Attempt 2 — Main-context inline fallback** (runs only if the retry also fails).
+
+Execute steps 5–8 directly in the main agent using Write/Edit/Bash, NOT via Task subagent and NOT via Skill tool:
+
+1. Read `.specify/templates/spec-template.md`, `.specify/templates/plan-template.md`, `.specify/templates/tasks-template.md`.
+2. Read `$ARGUMENTS` and any partial artifacts already on disk under `specs/`.
+3. If the feature branch does not exist yet: `.specify/scripts/bash/create-new-feature.sh "$ARGUMENTS" --json --short-name <derived-slug> "$ARGUMENTS"` to create branch + spec directory.
+4. `Write` `specs/<slug>/spec.md` filling in each template section from the requirement. Use `## Assumptions` for defaults. Zero `[NEEDS CLARIFICATION]` markers allowed.
+5. `Write` `specs/<slug>/plan.md` with ordered steps, file paths, component boundaries, test strategy, rollback considerations.
+6. `Write` `specs/<slug>/tasks.md` with atomic, dependency-ordered tasks, each with acceptance criteria.
+7. Commit each as written: `git add <file> && git commit -m "feat(speckit): <step> (main-context fallback)" && git push`.
+8. Re-run Step B verification. If still `GATE=MISSING`, halt the pipeline with a clear error listing the missing files — do NOT proceed to Phase 2 with a broken spec tree.
+
+Only after the Verification Gate passes (`GATE=OK`), update tasks 1–8 as completed using TaskUpdate, then output:
 
-> Phase 1 complete. N tasks created at specs/feature-name/tasks.md
+> Phase 1 complete. N tasks at specs/<slug>/tasks.md
 > Starting Phase 2 (implementation)...
 
 ---