bms-speckit-plugin 6.2.0 → 6.3.0

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,85 @@ 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).**
+
+All SQL in the project must be compatible with both MySQL and PostgreSQL. Since no database runtime is available, this phase uses **static grep-based analysis** to find database-specific syntax and replace it with cross-compatible alternatives.
+
+### G1. Identifier Quoting
+
+- **MySQL backticks** — Grep for backtick-quoted identifiers: `` `table_name` ``, `` `column` ``
+  - Fix: Replace with double quotes `"table_name"` (ANSI SQL, works on both) or remove quoting if identifiers don't need escaping
+  - If using an ORM, prefer the ORM's quoting mechanism instead of raw quoting
+
+### G2. Data Types
+
+Grep SQL files and SQL strings in source code for database-specific types:
+
+| MySQL-only | PostgreSQL-only | Cross-compatible replacement |
+|---|---|---|
+| `TINYINT(1)` for booleans | `BOOLEAN` | `BOOLEAN` (MySQL treats as TINYINT, PG native) |
+| `AUTO_INCREMENT` | `SERIAL`, `GENERATED ALWAYS AS IDENTITY` | Use ORM auto-increment, or `SERIAL` (PG) + `AUTO_INCREMENT` (MySQL) via migration |
+| `DOUBLE` | `DOUBLE PRECISION` | `DOUBLE PRECISION` (works on both) |
+| `DATETIME` | `TIMESTAMP` | `TIMESTAMP` (works on both) |
+| `TINYINT`, `MEDIUMINT` | not supported | `SMALLINT` or `INTEGER` |
+| `LONGTEXT`, `MEDIUMTEXT`, `TINYTEXT` | not supported | `TEXT` (works on both) |
+| `LONGBLOB`, `MEDIUMBLOB`, `TINYBLOB` | `BYTEA` | Handle via ORM or use `BLOB`/`BYTEA` per dialect |
+| `ENUM('a','b')` | `CREATE TYPE ... AS ENUM` | Use CHECK constraint or application-level validation |
+| `UNSIGNED` | not supported | Remove `UNSIGNED`, use CHECK constraint if needed |
+| `JSON` (MySQL 5.7+) | `JSON` / `JSONB` | `JSON` works on both; prefer `JSONB` on PG for indexing |
+
+### G3. SQL Syntax Differences
+
+Grep for these MySQL-specific or PostgreSQL-specific patterns:
+
+| Pattern | MySQL | PostgreSQL | Cross-compatible |
+|---|---|---|---|
+| Pagination | `LIMIT 10, 20` | not supported | `LIMIT 20 OFFSET 10` (works on both) |
+| String concat | `CONCAT(a, b)` | `a \|\| b` | `CONCAT(a, b)` (works on both in modern versions) |
+| Null coalesce | `IFNULL(a, b)` | not supported | `COALESCE(a, b)` (ANSI SQL, works on both) |
+| If/else | `IF(cond, a, b)` | not supported | `CASE WHEN cond THEN a ELSE b END` |
+| Current time | `NOW()` | `NOW()` | `NOW()` works on both, or `CURRENT_TIMESTAMP` |
+| Date diff | `DATEDIFF(a, b)` | `a - b` (returns interval) | Use `EXTRACT(EPOCH FROM a - b)` or handle per dialect |
+| Date format | `DATE_FORMAT(d, '%Y-%m-%d')` | `TO_CHAR(d, 'YYYY-MM-DD')` | Handle per dialect or use ORM date formatting |
+| Group concat | `GROUP_CONCAT(col)` | `STRING_AGG(col, ',')` | Handle per dialect or use ORM |
+| Upsert | `ON DUPLICATE KEY UPDATE` | `ON CONFLICT ... DO UPDATE` | Use ORM upsert or handle per dialect |
+| Insert ignore | `INSERT IGNORE` | `ON CONFLICT DO NOTHING` | Use ORM or handle per dialect |
+| Regex | `REGEXP` / `RLIKE` | `~` / `~*` | Handle per dialect |
+| Boolean literals | `TRUE`/`FALSE` or `1`/`0` | `TRUE`/`FALSE` | `TRUE`/`FALSE` (works on both) |
+| Table exists | `SHOW TABLES` | `\dt` / information_schema | `SELECT FROM information_schema.tables` (works on both) |
+| Column info | `DESCRIBE table` / `SHOW COLUMNS` | `\d table` | `SELECT FROM information_schema.columns` (works on both) |
+| String escape | `\'` (backslash) | `''` (double single quote) | `''` (ANSI SQL, works on both) |
+
+### G4. ORM/Query Builder Dialect Safety
+
+If the project uses an ORM or query builder:
+
+1. **Check dialect configuration** — Verify the ORM is configured to produce dialect-agnostic SQL, or has explicit multi-dialect support:
+   - Sequelize: check `dialect` option — should support switching between 'mysql' and 'postgres'
+   - TypeORM: check `type` in data source config
+   - Prisma: check `provider` in schema.prisma
+   - SQLAlchemy: check engine URL — should be configurable via env var, not hardcoded
+   - Django: check `DATABASES.ENGINE` setting
+
+2. **Raw SQL in ORM context** — Any raw SQL used alongside an ORM must follow the same cross-compatibility rules above. Flag raw SQL that uses dialect-specific syntax.
+
+3. **Migration files** — Check migration files for dialect-specific DDL. Migrations that use `AUTO_INCREMENT`, backtick quoting, or MySQL-specific types will fail on PostgreSQL.
+
+### G5. Handling Unavoidable Differences
+
+Some operations genuinely differ between databases. For these:
+
+1. **Dialect abstraction** — If the project must support both databases, verify there's a dialect layer that switches SQL per database type. Example:
+   ```
+   // Acceptable pattern
+   const upsertSQL = dialect === 'mysql'
+     ? 'INSERT INTO t (...) VALUES (?) ON DUPLICATE KEY UPDATE ...'
+     : 'INSERT INTO t (...) VALUES ($1) ON CONFLICT (...) DO UPDATE ...';
+   ```
+2. **Document exceptions** — If a query intentionally uses dialect-specific syntax, it must have a comment explaining which database it targets and why cross-compatibility isn't possible.
+
 **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.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

@@ -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** — static analysis of all SQL statements for MySQL/PostgreSQL cross-compatibility: identifier quoting, data types, syntax differences (IFNULL→COALESCE, LIMIT offset, upsert), ORM dialect config, migration files (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`