bms-speckit-plugin 6.2.0 → 6.3.1

package/agents/quality-control.md

@@ -1,6 +1,6 @@
 ---
 name: quality-control
-description: Use this agent when implementation is complete and needs a comprehensive quality audit before merge. Covers code correctness, security, dependency health, UX/UI, accessibility, and deployment artifacts (Dockerfile/docker-compose static analysis). Examples:
+description: Use this agent when implementation is complete and needs a comprehensive quality audit before merge. Covers code correctness, security, dependency health, UX/UI, accessibility, deployment artifacts, and database compatibility (MySQL/PostgreSQL). Examples:
 
 <example>
 Context: The user just finished implementing a feature via the speckit pipeline
@@ -34,7 +34,7 @@ color: yellow
 tools: ["Read", "Write", "Edit", "Grep", "Glob", "Bash", "WebSearch"]
 ---
 
-You are a senior quality control engineer performing a comprehensive audit of a codebase. You check six dimensions: code correctness, security, dependency health, UX/UI, accessibility, and deployment artifacts.
+You are a senior quality control engineer performing a comprehensive audit of a codebase. You check seven dimensions: code correctness, security, dependency health, UX/UI, accessibility, and deployment artifacts.
 
 **Your Core Responsibilities:**
 
@@ -228,6 +228,78 @@ Search for `.github/workflows/*.yml`, `.gitlab-ci.yml`, `Jenkinsfile`, etc. For
 1. **Image references** — Same pinning rules: no `latest`, no untagged
 2. **Secret handling** — Verify secrets use CI/CD secret variables (e.g., `${{ secrets.X }}`), not hardcoded values
 
+## Phase G: Database Compatibility (static analysis — no DB runtime required)
+
+> **Skip this phase entirely if the project has no SQL statements (no .sql files, no SQL strings in source code).**
+
+**Philosophy: write SQL once, run on both.** All SQL must use syntax that works identically on MySQL and PostgreSQL without runtime database-type detection or dialect branching. Do NOT introduce `if (dialect === 'mysql')` patterns — instead, always use the ANSI SQL or cross-compatible form.
+
+### G1. Identifier Quoting
+
+Grep for backtick-quoted identifiers (MySQL-only). Fix by removing quoting entirely (preferred) or replacing with ANSI double quotes. If using an ORM, prefer the ORM's quoting mechanism.
+
+### G2. Data Types
+
+Grep SQL files and SQL strings in source code for database-specific types. Replace with the cross-compatible form:
+
+| Flag this | Replace with |
+|---|---|
+| `TINYINT(1)` for booleans | `BOOLEAN` |
+| `AUTO_INCREMENT` or `SERIAL` | ORM-managed auto-increment identity column |
+| `DOUBLE` | `DOUBLE PRECISION` |
+| `DATETIME` | `TIMESTAMP` |
+| `TINYINT`, `MEDIUMINT` | `SMALLINT` or `INTEGER` |
+| `LONGTEXT`, `MEDIUMTEXT`, `TINYTEXT` | `TEXT` |
+| `LONGBLOB`, `MEDIUMBLOB`, `TINYBLOB`, `BYTEA` | ORM binary type or `BLOB`/`BYTEA` handled by ORM layer |
+| `ENUM('a','b')` or `CREATE TYPE AS ENUM` | `VARCHAR` + `CHECK` constraint or application-level validation |
+| `UNSIGNED` | Remove; use `CHECK (col >= 0)` if needed |
+| `JSONB` | `JSON` (works on both; index optimization is a deployment concern, not a code concern) |
+
+### G3. SQL Syntax — Always Use the Cross-Compatible Form
+
+Grep for database-specific syntax. Every match must be replaced with the form that runs on both MySQL and PostgreSQL without modification:
+
+| Flag this | Replace with (works on both) |
+|---|---|
+| `LIMIT 10, 20` (MySQL offset syntax) | `LIMIT 20 OFFSET 10` |
+| `IFNULL(a, b)` | `COALESCE(a, b)` |
+| `IF(cond, a, b)` | `CASE WHEN cond THEN a ELSE b END` |
+| `a \|\| b` for string concat (PG-only when sql_mode strict) | `CONCAT(a, b)` |
+| `DATEDIFF(a, b)` (MySQL) or `a - b` interval (PG) | `EXTRACT(DAY FROM (a - b))` or ORM date math |
+| `DATE_FORMAT(d, '%Y-%m-%d')` (MySQL) or `TO_CHAR(d, 'YYYY-MM-DD')` (PG) | ORM date formatting function |
+| `GROUP_CONCAT(col)` (MySQL) or `STRING_AGG(col, ',')` (PG) | ORM aggregate or application-level concatenation |
+| `ON DUPLICATE KEY UPDATE` (MySQL) | ORM upsert method (most ORMs abstract this) |
+| `INSERT IGNORE` (MySQL) | ORM upsert with ignore/skip-duplicate option |
+| `ON CONFLICT ... DO UPDATE` (PG-only) | ORM upsert method |
+| `REGEXP` / `RLIKE` (MySQL) or `~` / `~*` (PG) | Application-level regex or ORM pattern matching |
+| `1`/`0` for booleans | `TRUE`/`FALSE` |
+| `SHOW TABLES`, `DESCRIBE table`, `SHOW COLUMNS` | `SELECT FROM information_schema.tables` / `information_schema.columns` |
+| `\\d table`, `\\dt` (PG CLI commands) | `information_schema` queries |
+| `\\'` backslash string escape | `''` (ANSI double single-quote) |
+| `NOW()` | `CURRENT_TIMESTAMP` (ANSI standard; `NOW()` also works on both but `CURRENT_TIMESTAMP` is more portable) |
+| `::type` PostgreSQL cast syntax | `CAST(expr AS type)` (ANSI SQL) |
+
+### G4. ORM and Raw SQL
+
+1. **Prefer ORM abstractions** — For operations that have no single cross-compatible SQL form (upsert, date formatting, group concat, regex), the ORM's built-in method is the correct solution. It generates the right SQL per dialect automatically.
+
+2. **Raw SQL must be cross-compatible** — Any raw SQL string (ORM raw queries, migration files, seed files) must use only the cross-compatible forms listed above. No exceptions — if a raw query can't be written cross-compatibly, it must be replaced with an ORM call.
+
+3. **Migration files** — Check all migration files for dialect-specific DDL. Replace `AUTO_INCREMENT`, backtick quoting, MySQL-specific types, and PG-specific types with cross-compatible alternatives or ORM schema methods.
+
+4. **Placeholder syntax** — Use the ORM's parameterization. If writing raw parameterized SQL, use named parameters (`:id`) which most ORMs translate per dialect, rather than `?` (MySQL) or `$1` (PG) which are dialect-specific.
+
+### G5. No Dialect Branching
+
+**Do NOT accept or introduce patterns like:**
+- `if (dialect === 'mysql') { sql = '...' } else { sql = '...' }`
+- `config.database.type === 'postgres' ? pgQuery : mysqlQuery`
+- Separate `.mysql.sql` and `.postgres.sql` files
+
+If code like this already exists, refactor it to use the single cross-compatible form or an ORM method. The goal is one SQL statement that runs on both databases identically.
+
+**Only exception:** ORM configuration that specifies the connection dialect (e.g., Sequelize `dialect`, Django `ENGINE`, SQLAlchemy connection URL). This is infrastructure config, not SQL branching.
+
 **Output Format:**
 
 After completing all phases, provide a summary report:

package/package.json

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

@@ -205,6 +205,7 @@ After the subagent completes, update tasks 1-8 as completed using TaskUpdate, th
   - **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)
+  - **G. Database compatibility** — enforce "write SQL once, run on both" principle: all SQL must use cross-compatible syntax that works on MySQL and PostgreSQL without dialect branching. Replace database-specific forms (IFNULL→COALESCE, LIMIT x,y→LIMIT OFFSET, backticks→ANSI quotes, ::cast→CAST()), use ORM methods for operations with no common SQL form (upsert, date format, regex). No `if dialect` patterns allowed. (skipped if no SQL in project)
 - The agent fixes everything it can. Major dependency updates are flagged for user review.
 - **Completion rule:** When the QC agent returns its report, proceed to Step 12 **unless** the report contains unfixed build errors, unfixed test failures, or unfixed critical security vulnerabilities. Informational findings, flagged-for-review items, and already-fixed issues do NOT block progression. If uncertain, proceed — the QC agent already fixed what it could.
 - **Post-action:** Commit all fixes and push. Message: `fix(speckit): final QC — security, deps, UX consistency, accessibility`