bms-speckit-plugin 6.6.0 → 6.7.0

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.7.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

@@ -185,6 +185,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 +212,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)