bms-speckit-plugin 6.6.0 → 6.8.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.8.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/agents/quality-control.md

@@ -169,6 +169,8 @@ Grep source files for patterns where a value of one type is used where another t
 
 ## Phase D: UX/UI Review
 
+### D1. Functional UX
+
 1. Check every user-facing operation has:
    - Loading/progress indication for async operations
    - Actionable error messages (what went wrong + what to do)
@@ -184,6 +186,121 @@ Grep source files for patterns where a value of one type is used where another t
 4. Check for empty states (no data, first use, error state)
 5. Fix any missing feedback or poor UX patterns
 
+### D2. Brand Consistency (app name + identity)
+
+The application's name and identity must be consistent across every entry point. Grep the codebase for every place the app name can appear and verify they all match:
+
+1. **Collect every app-name occurrence:**
+   - `package.json` → `name` field and `description` field
+   - HTML `<title>` tag (in `index.html`, `_document.tsx`, layout files)
+   - `<meta name="description">`, `<meta property="og:title">`, `<meta property="og:description">`
+   - Navbar / header component — grep for the component that renders the top bar, find the brand text
+   - Login / signup page — grep for the component that renders auth screens
+   - Footer (if present)
+   - Manifest files (`manifest.json`, `site.webmanifest`) → `name`, `short_name`
+   - Service worker registration names
+   - README.md title
+   - Environment variables with "APP_NAME", "BRAND", "PROJECT_NAME"
+
+2. **Verify all occurrences match the spec** — the app name in `specs/*/spec.md` is the source of truth. If the spec says "BMS Patient Dashboard" but the navbar shows "My App" and the login page shows "Dashboard", fix all three to match the spec.
+
+3. **Flag placeholder/starter names** — these are signs of unfinished work:
+   - `"My App"`, `"App"`, `"React App"`, `"Vite App"`, `"Next App"`, `"Create React App"`
+   - `"Hello World"`, `"TODO"`, `"Placeholder"`, `"Example"`, `"Test"`, `"Demo"`
+   - `"Untitled"`, `"New Project"`, `"localhost"`
+   - Framework defaults left unchanged
+   - Fix by replacing with the actual app name from the spec
+
+4. **Check meta description quality** — the `<meta name="description">` should describe the system's purpose in one sentence, not repeat the name or contain placeholder text
+
+### D3. Login / Auth Page Content
+
+The login page is usually the first thing a user sees and sets the tone for the entire application. It must clearly identify the system and provide useful context.
+
+1. **System identification:**
+   - The app name is prominently displayed (matches navbar)
+   - There is a subtitle or tagline explaining what the system is for (e.g., "Hospital patient management for BMS clinics")
+   - A logo or brand mark is present (or, if not, flag as "missing visual identity")
+
+2. **Form quality:**
+   - All input fields have visible labels (not just placeholders)
+   - Password field has show/hide toggle if appropriate
+   - Submit button has a clear action label (not "Submit" — prefer "Sign In", "Log In", "Continue")
+   - Form has proper error display area
+   - Loading state during authentication
+
+3. **Helpful context:**
+   - "Forgot password" link if password reset is supported (or an explicit "Contact admin for password reset" message)
+   - Support contact info or help link
+   - Version number or build info in a subtle location (footer, corner) — helps with support tickets
+
+4. **Placeholder / demo content to flag and fix:**
+   - `"username@example.com"` as a default value
+   - `"password123"` or any default password
+   - Copy like `"Welcome to our amazing app"` without substance
+   - Empty or generic headlines like `"Login"` with no context
+   - Background images from stock libraries that were not replaced
+   - "Built with Create React App" or similar framework attributions in prominent positions
+
+### D4. Navbar / Header Consistency
+
+1. **App name / logo:**
+   - The navbar displays the app name prominently on the left (or per the design system's convention)
+   - Clicking the name/logo returns to the home/dashboard route
+   - The name matches what's shown on the login page
+
+2. **Navigation items:**
+   - Every nav item has a clear, descriptive label (not `"Page 1"`, `"Item 1"`, `"Menu"`, `"Link"`)
+   - Active route is visually indicated
+   - User identity/avatar is visible if logged in
+   - Sign-out / account menu is accessible
+
+3. **Responsive behavior:**
+   - On mobile: hamburger menu or drawer replaces horizontal nav
+   - Touch targets are adequate
+
+### D5. Professional Layout & Information Density
+
+Professional healthcare/enterprise applications should feel deliberate and informative, not generic. Check for:
+
+1. **Layout structure:**
+   - Every page has a defined structure: header, main content, footer (or equivalent)
+   - Consistent spacing/padding across pages (use design tokens, not hardcoded pixel values)
+   - No raw unstyled content (bare `<h1>` on white background with no container)
+
+2. **Anti-patterns to flag and fix:**
+   - Default framework colors left unchanged (default React blue, default Material UI purple, default Tailwind colors in brand positions)
+   - Lorem ipsum text anywhere in production routes
+   - "Hello World", "Welcome to Next.js", "Edit app/page.tsx" type starter content
+   - Single-page apps with just a form and no supporting information
+   - Dashboards with no actual data shown — just empty widgets or placeholders
+   - Pages with inconsistent fonts (multiple font families without a system)
+
+3. **Informative density:**
+   - Dashboard pages show meaningful data, not empty cards
+   - Empty states explain what would appear when data exists (e.g., "No patients found. Patients admitted today will appear here.")
+   - Key numbers/metrics have context (not just "42" — "42 patients active today")
+   - Data tables have column headers, sort indicators, and result counts
+   - Lists include counts ("Showing 10 of 145 results")
+
+4. **Typography hierarchy:**
+   - There is a visible distinction between page title (h1), section titles (h2), subsections (h3)
+   - Body text has adequate line height (1.4-1.7)
+   - Font sizes follow a scale, not arbitrary pixel values
+
+5. **Color usage:**
+   - Brand colors are defined and used consistently (check for a theme config or CSS variables)
+   - Semantic colors for state (success/warning/error/info) are defined once and reused
+   - No random inline `style={{color: '#ff0000'}}` — flag and replace with theme tokens
+
+6. **Visual polish quick checks:**
+   - Favicon is set and not the framework default
+   - Page has a proper `<title>` (not "localhost" or framework default)
+   - Loading spinners are styled to match the brand
+   - Buttons have consistent sizing and states (hover/focus/active/disabled)
+
+For each issue found, fix it by referencing the actual app name/description from `specs/*/spec.md` and the brand tokens from the design system (or create minimal tokens if missing).
+
 ## Phase E: Accessibility
 
 1. Check images have alt text
@@ -554,6 +671,16 @@ After completing all phases, provide a summary report:
 - [ ] Error messages are actionable
 - [ ] Loading states present
 - [ ] Empty states handled
+- [ ] Brand consistency: app name matches across package.json, title, meta, navbar, login, manifest
+- [ ] No placeholder app names (My App, React App, Hello World, etc.)
+- [ ] Login page identifies the system with name + subtitle explaining purpose
+- [ ] Login page has no default/demo credentials or lorem ipsum
+- [ ] Navbar displays app name and has descriptive nav labels (no Page 1, Item 1)
+- [ ] Layout has defined structure (header/main/footer) with consistent spacing
+- [ ] No default framework colors in brand positions
+- [ ] Dashboards show real data or informative empty states (no empty placeholder cards)
+- [ ] Typography hierarchy visible (h1 → h2 → h3)
+- [ ] Favicon and page title are customized (not framework defaults)
 
 ### Accessibility
 - [ ] Images have alt text

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bms-speckit-plugin",
-  "version": "6.6.0",
+  "version": "6.8.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`
@@ -185,6 +203,7 @@ After the subagent completes, update tasks 1-8 as completed using TaskUpdate, th
      - Add unit tests that actually execute data transformation functions and verify the output type and shape
      - **SQL validation:** before writing any SQL statement, verify the exact table and column names exist. Use `bms-session-mcp-server` tools (`list_tables`, `describe_table`) or `mcp__bms-knowledge-mcp__search_knowledge` (hosxp collection) to confirm every field reference. Never guess column names. After writing a query, test it with `query` tool using `EXPLAIN` or `LIMIT 0` to confirm it parses and executes.
      - **Business logic correctness:** before writing any SQL, state out loud what business question the query is supposed to answer. Then use `mcp__bms-knowledge-mcp__search_knowledge` on the `hosxp` collection to verify: (a) you're using the canonical table for this data (e.g., `ovst` vs `opd`), (b) you're applying the correct soft-delete/status filter (e.g., `vstatus != 'C'`), (c) you're using the right date column, (d) you're joining on the right key (hn vs vn vs an). For multi-table relationships use `graph_search` instead. For reporting queries, also check `moph` or `nhso` collections for regulatory inclusion/exclusion rules. Cite the HOSxP convention in a code comment (e.g., `// HOSxP: use vstdate not service_date`).
+     - **Brand & layout quality (for UI tasks):** whenever a task creates or modifies the navbar, login page, or page layout: source the app name and description from `specs/*/spec.md` (never invent one or use framework defaults); make sure the navbar displays the app name, the login page identifies the system with a descriptive subtitle, nav items have clear labels (not "Page 1"), layouts have a header/main structure with consistent spacing, and typography uses a visible hierarchy. No Lorem ipsum, no "Hello World", no default framework colors in brand positions, no placeholder credentials in login forms.
   2. **INLINE QC** — immediately run: build, lint, ALL tests, security quick scan, UX check
   3. **INTEGRATION TEST (real database)** — for every task that touches database queries or data-dependent business logic, run an integration test that:
      - Uses the real `bms-session-mcp-server` `query` tool to execute the feature's actual SQL against the real HOSxP database (not mocks)
@@ -211,7 +230,7 @@ After the subagent completes, update tasks 1-8 as completed using TaskUpdate, th
 - **Focus areas:**
   - **A. Security deep scan** — `npm audit` / `pip audit`, auth flow review, CORS, secrets across all files
   - **B. Dependencies** — outdated packages, vulnerable deps, unused packages
-  - **C. UX consistency** — consistent error handling and feedback patterns across ALL features, empty states, responsive design
+  - **C. UX consistency & brand polish** — consistent error handling and feedback patterns across ALL features, empty states, responsive design. Brand consistency: app name matches across package.json, HTML title, meta tags, navbar, login page, manifest (all sourced from spec). No placeholder names (My App, React App, Hello World). Login page identifies the system with name + descriptive subtitle, real form labels, no demo credentials. Navbar has descriptive nav labels. Professional layout: defined structure, consistent spacing, no default framework colors in brand positions, dashboards show real data or informative empty states, typography hierarchy, customized favicon and page title.
   - **D. Accessibility** — alt text, form labels, keyboard nav, heading hierarchy
   - **E. Integration check** — verify all components work together end-to-end
   - **F. Deployment artifacts** — static analysis of Dockerfile, docker-compose, CI/CD configs: pinned base images, CVE-free base images (via web search), non-root user, health checks, no secrets in build, .dockerignore coverage (skipped if no deployment files exist)