prizmkit 1.1.54 → 1.1.55

package/bundled/skills/app-planner/references/rules/database/fixed-rules.md

@@ -0,0 +1,211 @@
+# Fixed Rules — Complete Database Fixed Rules
+
+> This file is read by the `database-rules` skill in Phase 1 and injected directly into `database-rules.md`.
+> These rules are industry consensus / best practices — **do not ask the user**.
+> Every rule includes RATIONALE so the AI understands intent, not just constraints.
+
+---
+
+## F1. Schema Design
+
+### F1.1 Naming Conventions (Mandatory)
+
+- **Table names**: snake_case plural (`users`, `order_items`), not camelCase. Junction tables use alphabetical concatenation (`user_roles`).
+- **Column names**: snake_case (`created_at`, `user_id`), not camelCase.
+- **Primary keys**: use `id` for single tables, or concatenated names for junction tables (`user_id`, `role_id`).
+- **Foreign keys**: `<referenced_table>_id` (`user_id`, `order_id`).
+- **Indexes**: prefix `idx_` + table + columns (`idx_users_email`).
+- **Unique constraints**: prefix `uq_` + table + columns (`uq_users_email`).
+- **Forbidden**: Pinyin names, reserved keywords as table/column names (`order`, `group`, `user`).
+- **RATIONALE**: Consistent naming makes ORM mapping accurate, SQL readable, and AI code generation precise when guessing field names.
+
+### F1.2 Required Fields
+
+- **Rule**: Every business table must have:
+  - `id` — primary key
+  - `created_at` — `NOT NULL DEFAULT NOW()`
+  - `updated_at` — `NOT NULL DEFAULT NOW()` with auto-update (or trigger)
+- **Rule**: Tables requiring soft delete must add `deleted_at` (NULL = not deleted). Unique indexes must include `deleted_at`.
+- **Forbidden**: Using `is_deleted` boolean instead of `deleted_at` — losing the deletion timestamp loses audit information.
+- **RATIONALE**: Consistent timestamps are the foundation of all auditing, synchronization, and CDC.
+
+### F1.3 Primary Key Strategy
+
+- **Rule**: Prefer UUID v4/v7 or ULID as the business primary key exposed to APIs.
+- **Rule**: Primary key strategy is determined by Q3 (Primary Key Strategy). If UUID/ULID is chosen, UUIDs are used both internally and in the API layer. If auto-increment is chosen, BIGINT may be used internally, but the API layer must expose UUID (via an additional UUID column or ID mapping).
+- **Forbidden**: Exposing auto-increment IDs directly to the frontend (enumerable, leaks data volume).
+- **Forbidden**: Using business fields as primary keys (e.g., national ID, phone number) — business rules change.
+- **RATIONALE**: UUIDs prevent enumeration, support distributed generation, and avoid merge conflicts. Exposing auto-increment IDs is information leakage.
+
+### F1.4 Normalization vs. Denormalization
+
+- **Rule**: Default to 3NF (Third Normal Form) to reduce data redundancy.
+- **Denormalization exception**: Only allowed when query performance is a proven bottleneck AND index optimization has been exhausted. Must be documented with rationale in schema comments.
+- **Forbidden**: Denormalizing without load testing.
+- **RATIONALE**: Denormalization is a double-edged sword — queries get faster but writes and consistency maintenance costs skyrocket.
+
+### F1.5 Enum Values
+
+- **Rule**: Status columns must list all possible values in schema comments.
+- **Rule**: Prefer database ENUM types (PostgreSQL use CHECK constraint + string) or enum tables.
+- **Forbidden**: Using `status TINYINT` without comments — nobody knows what 2 means.
+- **RATIONALE**: Enum values are the easiest thing to rot — every status addition requires a full code scan to confirm compatibility.
+
+---
+
+## F2. Column Types
+
+- **Rule**: Monetary amounts always use `DECIMAL(19,4)` or `NUMERIC`. Forbid `FLOAT`/`DOUBLE`.
+- **Rule**: Date/time use `TIMESTAMP WITH TIME ZONE` (PostgreSQL) / `DATETIME` (MySQL). Forbid string-stored dates.
+- **Rule**: JSON data use `JSONB` (PostgreSQL) / `JSON` (MySQL 8+). Forbid storing TEXT and parsing in application layer.
+- **Rule**: Character set unified to `UTF8MB4` (MySQL) / `UTF8` (PostgreSQL). Collation unified.
+- **Rule**: IP addresses use `INET` (PostgreSQL) / `VARBINARY(16)` (MySQL), not VARCHAR.
+- **Forbidden**: Using VARCHAR to store arrays (e.g., `"a,b,c"`) — use array types or junction tables.
+- **RATIONALE**: The right type lets the database do validation and index optimization for you. Wrong types mean you're throwing away the database's self-protection.
+
+---
+
+## F3. Index Strategy
+
+- **Rule**: Primary keys are auto-indexed. Foreign keys must be manually indexed.
+- **Rule**: Columns involved in WHERE/JOIN/ORDER BY/DISTINCT must be evaluated for index need.
+- **Rule**: Multi-column queries use composite indexes with the leftmost prefix rule — equality columns first, range columns last.
+- **Rule**: Adding indexes to large tables must use `CONCURRENTLY` (PostgreSQL) / `ALGORITHM=INPLACE` (MySQL) to avoid table locks.
+- **Rule**: Regularly analyze slow query logs and remove unused indexes.
+- **Forbidden**: Indexing low-cardinality columns alone (e.g., `gender`, `status` with < 5 values).
+- **Forbidden**: Redundant indexes — `idx(a,b)` already covers `idx(a)` scenarios.
+- **RATIONALE**: Indexes are the core lever of database performance, but every additional index slows writes by a bit.
+
+---
+
+## F3b. Transaction Isolation
+
+### F3b.1 Transaction Isolation
+
+- **Rule**: Explicitly set transaction isolation level for each transaction. Do not rely on database defaults.
+- **Rule**: Default isolation for OLTP: READ COMMITTED (balances consistency and performance). For financial operations: REPEATABLE READ or SERIALIZABLE.
+- **Rule**: Document the chosen isolation level per business operation in code comments.
+- **Forbidden**: Using SERIALIZABLE for high-throughput read operations (causes unnecessary contention).
+- **RATIONALE**: PostgreSQL defaults to READ COMMITTED, MySQL to REPEATABLE READ. Different defaults cause different behaviors in the same application code.
+
+---
+
+## F4. Migration Management
+
+- **Rule**: All database structure changes must go through versioned migration files. Forbid executing SQL directly against production databases.
+- **Rule**: Migration file naming: `V<number>__<description>.sql` (Flyway format) or `<timestamp>_<description>.sql` (custom format).
+- **Rule**: Each migration file must include both `up` (forward) and corresponding `down` (rollback).
+- **Rule**: Schema changes must avoid table locks (choose the correct method per database):
+  - MySQL: `ALGORITHM=INPLACE, LOCK=NONE` (when conditions allow)
+  - PostgreSQL: `ALTER TABLE ... ADD COLUMN` without DEFAULT (add column first, then backfill defaults).
+- **Forbidden**: Dropping columns in migrations — mark as deprecated first, remove in the next version after confirming zero references.
+- **Forbidden**: Changing column types — must follow the pattern: add new column → dual-write transition → migrate data → switch reads → drop old column.
+- **RATIONALE**: Migrations are the most dangerous production operations. It's not just "does it run" — it's about online tables, rollback windows, and data consistency.
+
+---
+
+## F5. Query Standards
+
+- **Rule**: All SQL must be parameterized. Forbid string concatenation with user input.
+- **Rule**: SELECT must explicitly list column names. Forbid `SELECT *`.
+- **Rule**: Queries must have LIMIT (unless the business explicitly requires full results and data volume is controllable).
+- **Rule**: Bulk write operations (UPDATE/DELETE) must be batched (≤ 1000 rows per batch) with transaction intervals.
+- **Rule**: Transactions must be as short as possible — no external API calls, message sends, or user input waits inside transactions.
+- **Rule**: Complex queries must first run `EXPLAIN` / `EXPLAIN ANALYZE` to verify index usage.
+- **Forbidden**: Concatenating dynamic SQL strings in application code (use whitelist for dynamic sort fields, query builder for dynamic conditions).
+- **RATIONALE**: Query standards aren't about "writing prettier code" — every rule here corresponds to a real production incident.
+
+---
+
+## F6. Security & Permissions
+
+- **Rule**: Application accounts get minimum privileges — separate read and write accounts. Read accounts only get SELECT.
+- **Rule**: Forbid using root/superuser accounts for application connections.
+- **Rule**: Connections must enforce TLS/SSL.
+- **Rule**: Sensitive fields (passwords, tokens, national IDs, phone numbers) must be encrypted at rest.
+- **Rule**: Database ports must not be exposed to the public internet. Internal/VPC whitelist access only.
+- **RATIONALE**: The database is the attacker's ultimate target. Enough layers of defense is what keeps you safe.
+
+---
+
+## F7. Backup & Recovery
+
+- **Rule**: Automated backup strategy — daily full + continuous incremental/archiving (WAL archiving / binlog).
+- **Rule**: Backup files must be stored offsite and encrypted.
+- **Rule**: Regular recovery drills are mandatory (at least quarterly) to verify backup usability.
+- **Rule**: PITR (Point-in-Time Recovery) must be available — recovering only to the last full backup is not sufficient.
+- **RATIONALE**: A database whose backups have never been verified is a database without backups.
+
+---
+
+## F8. Performance
+
+- **Rule**: Connection pool limit ≤ 80% of database `max_connections`, leaving headroom for admin connections.
+- **Rule**: Slow query threshold set to 100ms (for OLTP workloads). Alert on exceeding.
+- **Rule**: Large tables (>10M rows) must plan a partitioning strategy (range partition by time or business key).
+- **Rule**: Historical data must have an archival strategy that doesn't impact online query performance.
+- **Forbidden**: Running DDL, bulk data migrations, or creating large indexes during peak hours.
+- **RATIONALE**: Database performance issues are "boiling the frog" — unnoticeable at first, then suddenly crashing three times a day once data volume grows.
+
+---
+
+## F8b. Connection Pooling
+
+### F8b.1 Connection Pooling
+
+- **Rule**: Every application service must use connection pooling. Forbid opening a new connection per request.
+- **Rule**: Pool size = CPU cores x 2 per service instance (for OLTP). Max pool size <= 80% of database max_connections / number of service instances.
+- **Rule**: Connection timeout: acquire <= 30s, idle <= 10min, max lifetime <= 1hour.
+- **Rule**: Pool must have health check (validation query on borrow).
+- **Forbidden**: Using hardcoded pool sizes without accounting for the number of service instances.
+- **RATIONALE**: Connection pooling misconfiguration is the #1 cause of "database is up but application can't connect" incidents.
+
+---
+
+## F9. AI Vibecoding Baseline Constraints (project-agnostic, always active)
+
+### F9.1 Migration Files
+- **Rule**: AI generating a new migration must also produce the corresponding rollback migration.
+- **Forbidden**: Dropping columns, changing column types, or renaming columns in migrations (unless a complete transition plan exists).
+- **Rule**: New migrations must pass `EXPLAIN` review before submission.
+
+### F9.2 SQL Safety
+- **Rule**: All AI-written SQL in application code must be parameterized queries.
+- **Forbidden**: AI generating string-concatenated SQL code.
+
+### F9.3 Search First
+- **Rule**: Before writing SQL/migrations, AI must read existing migration files and schema.
+- **Rule**: Before adding a new column, AI must confirm that a column with the same name doesn't already exist in that table.
+
+### F9.4 Context Honesty
+- **Rule**: When uncertain about database version, field names, or constraint names, AI must explicitly say "I'm not sure." Forbid inventing.
+- **Rule**: AI must understand the target database type before generating SQL (MySQL and PostgreSQL syntax differ).
+
+### F9.5 Irreversible Operations
+- **Rule**: AI must not execute any DROP/TRUNCATE statements (unless the user explicitly provides both the target object and the reason).
+- **Rule**: AI-proposed DDL must include a migration strategy assessment: online execution or maintenance window? How long is the table locked? What's the rollback plan?
+
+---
+
+## Injection Instructions (for the AI executing this skill)
+
+Each chapter in this file corresponds to a `{{ FIXED_RULES_* }}` placeholder in the template:
+
+| Chapter | Inject Into Placeholder | Template Section |
+|---------|------------------------|-------------------|
+| F1 Schema Design | `{{ FIXED_RULES_SCHEMA }}` | §1 Schema Design |
+| F2 Column Types | `{{ FIXED_RULES_TYPES }}` | §2 Column Types |
+| F3 Index Strategy | `{{ FIXED_RULES_INDEX }}` | §3 Index Strategy |
+| F3b Transaction Isolation | `{{ FIXED_RULES_TRANSACTION }}` | §3b Transaction Isolation |
+| F4 Migration Management | `{{ FIXED_RULES_MIGRATION }}` | §4 Migration Management |
+| F5 Query Standards | `{{ FIXED_RULES_QUERY }}` | §5 Query Standards |
+| F6 Security & Permissions | `{{ FIXED_RULES_SECURITY }}` | §6 Security & Permissions |
+| F7 Backup & Recovery | `{{ FIXED_RULES_BACKUP }}` | §7 Backup & Recovery |
+| F8 Performance | `{{ FIXED_RULES_PERFORMANCE }}` | §8 Performance |
+| F8b Connection Pooling | `{{ FIXED_RULES_CONNECTION }}` | §8b Connection Pooling |
+| F9 AI Constraints | `{{ FIXED_RULES_AI_BASE }}` | §9 AI Behavior Constraints |
+
+**Rendering rules**:
+1. Copy each chapter's full body (including RATIONALE) directly into the corresponding placeholder.
+2. RATIONALE must be preserved — it lets AI understand intent rather than follow mechanically.
+3. Keep the original markdown list structure. Do not rewrite as prose paragraphs.

package/bundled/skills/app-planner/references/rules/database/question-bank.md

@@ -0,0 +1,184 @@
+# Question Bank — Database Interactive Question Bank
+
+> This file is read on demand by SKILL.md in Phase 2. The AI must strictly follow the group order defined in this file, asking **one group at a time (1–3 questions)**, never dumping all questions at once.
+> For every question, show the user: question number, question text, options, **recommended choice (marked "Recommended")**, and a one-line description.
+> After each user response, immediately record the choice to internal state `answers[Qx] = ...` and proceed to the next group.
+
+---
+
+## Asking Rules
+
+1. **Group order**: G1 → G2 → G3 → G4 → G5 → G6 → G7. Do not skip.
+2. **Shortcut commands** (respond immediately when user types these at any point):
+   - `recommended` / `default` → skip current group, adopt all recommended options
+   - `all recommended` / `one-click` → skip all remaining groups, adopt all recommended options
+   - `strict` / `strictest` → adopt the strictest option for the current group
+   - `skip` / `don't need this` → mark current group as N/A
+   - `custom: xxx` → record user's custom content
+3. **Abbreviation recognition**: `A` / `a` / `1` all mean option A.
+4. **Follow-up rule**: If the user gives an answer outside the options, first confirm whether to classify as an "other" branch.
+5. **Forbidden behaviors**:
+   - Must not make choices for the user before they explicitly answer.
+   - Must not fabricate user preferences to complete the answer set.
+   - Must not output more than 3 questions in a single message.
+
+---
+
+## Group Overview
+
+| Group | Topic | Questions | Count |
+|-------|-------|-----------|-------|
+| G1 | Database Selection | Q1–Q2 | 2 |
+| G2 | Data Modeling | Q3–Q5 | 3 |
+| G3 | Migration | Q6 | 1 |
+| G4 | Index & Performance | Q7–Q8 | 2 |
+| G5 | Security & Compliance | Q9–Q10 | 2 |
+| G6 | High Availability & Ops | Q11–Q13 | 3 |
+| G7 | AI Constraints | Q14–Q15 | 2 |
+
+Total: 15 questions.
+
+---
+
+## G1 — Database Selection
+
+### Q1. Primary Database
+- **Options**:
+  - A) PostgreSQL **【Recommended: most feature-complete】**
+  - B) MySQL
+  - C) MongoDB
+  - D) SQLite (development/small projects)
+- **Note**: Determines all subsequent column type, index syntax, and migration tool options.
+- **Maps to**: `{{ database }}` + `{{ tech_rules }}`
+
+### Q2. Cache Layer Needed?
+- **Options**:
+  - A) Redis **【Recommended: when caching is needed】**
+  - B) Memcached
+  - C) No cache layer needed
+- **Note**: Determines cache key naming conventions, TTL requirements, and batch operation rules.
+- **Maps to**: `{{ cache }}` + `{{ cache_rules }}`
+
+---
+
+## G2 — Data Modeling
+
+### Q3. Primary Key Strategy
+- **Options**:
+  - A) UUID v7 (time-sortable, 128-bit with dashes) **【Recommended】**
+  - B) ULID (lowercase, URL-safe, 26-char, time-sortable)
+  - C) Auto-increment BIGINT + UUID mapping for external use
+  - D) Direct auto-increment IDs
+- **Note**: Choosing D injects the rule "forbid exposing auto-increment IDs to the frontend."
+- **Maps to**: `{{ pk_strategy }}` + `{{ schema_rules }}`
+
+### Q4. Soft Delete
+- **Options**:
+  - A) Use `deleted_at` field **【Recommended】**
+  - B) No soft delete needed (data is irrecoverably deleted)
+- **Note**: Determines whether audit fields and unique indexes with `deleted_at` rules are needed.
+- **Maps to**: `{{ soft_delete }}` + `{{ schema_rules }}`
+
+### Q5. Normalization Level
+- **Options**:
+  - A) Strict 3NF; denormalization requires comments explaining why **【Recommended】**
+  - B) Allow partial denormalization (OLAP/reporting scenarios)
+- **Note**: Determines the threshold for data redundancy.
+- **Maps to**: `{{ normalization }}` + `{{ schema_rules }}`
+
+---
+
+## G3 — Migration
+
+### Q6. Migration Tool
+- **Options**:
+  - A) ORM's built-in migration tool **【Recommended: when consistent with ORM】**
+  - B) Flyway / golang-migrate / Alembic (standalone migration tool)
+  - C) Manually managed SQL files
+- **Note**: Determines migration file format, naming conventions, and rollback requirements.
+- **Maps to**: `{{ migration_tool }}` + `{{ migration_rules }}`
+
+---
+
+## G4 — Index & Performance
+
+### Q7. Query Complexity
+- **Options**:
+  - A) OLTP (high-frequency small queries, ≤ 10ms each) **【Recommended: web apps】**
+  - B) OLAP (low-frequency large queries, ≥ 100ms each)
+  - C) Mixed (has reporting/analytics needs)
+- **Note**: Determines slow query thresholds, index strategy strictness, and partitioning rules.
+- **Maps to**: `{{ workload_type }}` + `{{ performance_rules }}`
+
+### Q8. Estimated Data Volume (per table)
+- **Options**:
+  - A) < 1M rows (small scale, no partitioning needed) **【Recommended: early-stage projects】**
+  - B) 1M-10M rows (medium scale, recommend reserving partition expansion space)
+  - C) > 10M rows (large scale, partitioning strategy is mandatory)
+- **Note**: Determines the urgency of partitioning and archival rules.
+- **Maps to**: `{{ data_scale }}` + `{{ performance_rules }}`
+
+---
+
+## G5 — Security & Compliance
+
+### Q9. Data Sensitivity Level
+- **Options**:
+  - A) Contains PII (Personally Identifiable Information), encryption at rest required **【Recommended: privacy-first, safest default】**
+  - B) Business data only, no special encryption needed
+- **Note**: Choosing A auto-injects "encrypt sensitive fields", "log desensitization", and other strict rules.
+- **Maps to**: `{{ data_sensitivity }}` + `{{ security_rules }}`
+
+### Q10. Audit Requirements
+- **Options**:
+  - A) Need audit tables + operation logs **【Recommended: enterprise-grade projects】**
+  - B) Need CDC (Change Data Capture, for sync/analytics)
+  - C) Both audit tables + CDC (for comprehensive compliance + real-time sync)
+  - D) No audit needed
+- **Note**: **Multi-select allowed** — audit tables (A) and CDC (B) serve different purposes and can be used together. Determines audit table structure and trigger rules.
+- **Maps to**: `{{ audit }}` + `{{ audit_rules }}`
+
+---
+
+## G6 — High Availability & Operations
+
+### Q11. Deployment Method
+- **Options**:
+  - A) Cloud managed service (RDS / Cloud SQL / Supabase) **【Recommended】**
+  - B) Self-hosted
+  - C) Development environment Docker Compose
+- **Note**: Determines backup strategy and high availability rules.
+- **Maps to**: `{{ deployment }}` + `{{ ops_rules }}`
+
+### Q12. Backup Strategy
+- **Options**:
+  - A) Daily full + continuous incremental (PITR available) **【Recommended: production environments】**
+  - B) Daily full backup only
+  - C) No automatic backup needed (development environment)
+- **Note**: Determines backup frequency, retention period, and recovery drill requirements.
+- **Maps to**: `{{ backup }}` + `{{ ops_rules }}`
+
+### Q13. High Availability Requirements
+- **Options**:
+  - A) Primary-replica replication / read-write split **【Recommended: production environments】**
+  - B) Single instance is sufficient
+  - C) Multi-master cluster
+- **Note**: Determines connection pool configuration and failover strategy.
+- **Maps to**: `{{ ha }}` + `{{ ops_rules }}`
+
+---
+
+## G7 — AI Constraints
+
+### Q14. AI Permission to Modify Database Structure
+- **Options**:
+  - A) AI may only generate migration files; human reviews before execution **【Recommended】**
+  - B) AI may not generate any DDL (fully human-managed)
+  - C) AI may operate freely (development environment)
+- **Maps to**: `{{ ai_ddl_rule }}`
+
+### Q15. AI Safety Constraints
+- **Options**:
+  - A) AI must not execute DROP/TRUNCATE/drop column/change type **【Recommended】**
+  - B) No restriction, but explicit confirmation required
+- **Maps to**: `{{ ai_safety_rule }}`

package/bundled/skills/app-planner/references/rules/database/template.md

@@ -0,0 +1,158 @@
+# Database Rules — {{ project_name }}
+
+> This document was generated by the `database-rules` skill on {{ generated_at }}
+> Audience: All project developers + DBAs + all AI coding assistants
+>
+> **Usage**:
+> 1. All AI coding assistants must read this file before generating or modifying any database-related code
+> 2. This document takes precedence over "general best practices" in AI training data
+> 3. Operations conflicting with this document must not be executed
+
+---
+
+## 0. TL;DR — Key Decisions at a Glance
+
+| Dimension | Decision |
+|-----------|----------|
+| Primary Database | {{ database }} |
+| Cache Layer | {{ cache }} |
+| Primary Key Strategy | {{ pk_strategy }} |
+| Soft Delete | {{ soft_delete }} |
+| Normalization Level | {{ normalization }} |
+| Migration Tool | {{ migration_tool }} |
+| Workload Type | {{ workload_type }} |
+| Data Scale | {{ data_scale }} |
+| Data Sensitivity | {{ data_sensitivity }} |
+| Audit Requirements | {{ audit }} |
+| Deployment Method | {{ deployment }} |
+| Backup Strategy | {{ backup }} |
+| High Availability | {{ ha }} |
+| AI DDL Permission | {{ ai_ddl_permission }} |
+| AI Safety Constraints | {{ ai_safety_constraint }} |
+
+---
+
+## 1. Schema Design
+
+{{ FIXED_RULES_SCHEMA }}
+
+{{ schema_rules }}
+
+---
+
+## 2. Column Types
+
+{{ FIXED_RULES_TYPES }}
+
+{{ tech_rules }}
+
+---
+
+## 3. Index Strategy
+
+{{ FIXED_RULES_INDEX }}
+
+---
+
+## 3b. Transaction Isolation
+
+{{ FIXED_RULES_TRANSACTION }}
+
+---
+
+## 4. Migration Management
+
+{{ FIXED_RULES_MIGRATION }}
+
+{{ migration_rules }}
+
+---
+
+## 5. Query Standards
+
+{{ FIXED_RULES_QUERY }}
+
+> **Note**: For data access method rules (ORM/Query Builder/Raw SQL organization), refer to `backend-rules.md` §5 (Database). This document covers SQL-level query standards only.
+
+---
+
+## 6. Security & Permissions
+
+{{ FIXED_RULES_SECURITY }}
+
+{{ security_rules }}
+
+---
+
+## 7. Backup & Recovery
+
+{{ FIXED_RULES_BACKUP }}
+
+{{ ops_rules }}
+
+---
+
+## 8. Performance
+
+{{ FIXED_RULES_PERFORMANCE }}
+
+{{ performance_rules }}
+
+---
+
+## 8b. Connection Pooling
+
+{{ FIXED_RULES_CONNECTION }}
+
+---
+
+## 9. AI Vibecoding Behavior Constraints
+
+### 9.1 Baseline Constraints (project-agnostic, always active)
+
+{{ FIXED_RULES_AI_BASE }}
+
+### 9.2 Project-Specific Hard Constraints
+
+- **Database structure change permission**: {{ ai_ddl_rule }}
+- **Safety operation constraints**: {{ ai_safety_rule }}
+
+### 9.3 Mandatory Pre-Actions (before generating any SQL/Migration)
+
+AI must complete the following in order before performing any database-related operation:
+
+1. Read this file (`database-rules.md`)
+2. Read existing schema or migration files to confirm table structure
+3. Confirm the target database type and version
+4. If involving indexes/DDL, first assess EXPLAIN and estimated execution time
+
+---
+
+## 10. Audit & Compliance
+
+{{ audit_rules }}
+
+---
+
+## 11. Caching
+
+{{ cache_rules }}
+
+---
+
+## Appendix A: Deny List (Quick Reference)
+
+> This appendix is auto-generated by AI in Phase 4 by extracting all forbidden entries from each section.
+
+{{ deny_list_summary }}
+
+## Appendix B: Recommended Tools
+
+> This appendix is auto-generated by AI in Phase 4 to recommend supporting tools based on database selection.
+
+{{ recommended_libs }}
+
+---
+
+**Version**: v1.0 — Generated on {{ generated_at }}
+**Next review recommended**: before database upgrades or architecture changes