prizmkit 1.1.154 → 1.1.156

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

@@ -1,211 +1,104 @@
-# Fixed Rules — Complete Database Fixed Rules
+# Database Invariant 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.
+POLICY_CLASS: invariant
 
----
+These blocks apply to relational, document, embedded, managed, and self-hosted data stores without imposing one model on another.
 
-## F1. Schema Design
+**Selected-decision boundary:** database technology, identifier strategy, soft deletion, normalization/document modeling, migration tooling, workload, scale, sensitivity, audit/CDC, deployment, backup, availability, and AI DDL permission belong to confirmed decisions and derivation rules.
 
-### F1.1 Naming Conventions (Mandatory)
+## I1. Schema and Model Integrity
 
-- **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.
+- Give each persisted concept an explicit owner, stable identity strategy, and documented lifecycle.
+- Preserve selected naming and modeling conventions consistently within the same datastore boundary.
+- Constraints enforced by the datastore and application must agree; do not rely on undocumented coercion.
+- Relational normalization and document embedding/reference policies come only from selected derivation rules.
 
-### F1.2 Required Fields
+Inject into `{{ FIXED_RULES_SCHEMA }}`.
 
-- **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.
+## I2. Type Integrity
 
-### F1.3 Primary Key Strategy
+- Use native datastore types or validated encodings that preserve the domain's precision, range, timezone, and nullability semantics.
+- Monetary or exact quantities must not use an imprecise representation.
+- Do not store structured values in an opaque string when the selected datastore has a safer queryable representation, unless compatibility requires it and the boundary is documented.
+- Technology-specific type names come from `{{ tech_rules }}`.
 
-- **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.
+Inject into `{{ FIXED_RULES_TYPES }}`.
 
-### F1.4 Normalization vs. Denormalization
+## I3. Access-Path Integrity
 
-- **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.
+- Add indexes or equivalent access paths from observed query patterns, selectivity, and write cost rather than universal rules.
+- Verify expensive access paths with the selected datastore's explain/profile capability when available.
+- Avoid duplicate or unused indexes and document intentional full scans for bounded datasets.
 
-### F1.5 Enum Values
+Inject into `{{ FIXED_RULES_INDEX }}`.
 
-- **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.
+## I4. Atomicity and Concurrency
 
----
+- Define the consistency, transaction, or atomic-write boundary for operations that update related state.
+- Keep atomic units bounded and avoid waiting on unrelated external systems while locks or equivalent write ownership are held.
+- Select isolation, optimistic concurrency, or conflict handling according to the datastore and business invariant.
 
-## F2. Column Types
+Inject into `{{ FIXED_RULES_TRANSACTION }}`.
 
-- **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.
+## I5. Change Management
 
----
+- Version structural or model changes and make the applied state observable.
+- Define rollout, compatibility, data transformation, and recovery behavior before a destructive or incompatible change.
+- Use the selected migration mechanism; do not require SQL rollback files for technologies or tools that use another safe recovery model.
 
-## F3. Index Strategy
+Inject into `{{ FIXED_RULES_MIGRATION }}`.
 
-- **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.
+## I6. Query and Mutation Safety
 
----
+- Bind untrusted values through the selected driver's safe query API; never concatenate untrusted input into executable query text.
+- Bound bulk and list operations or explicitly implement streaming/pagination.
+- Protect dynamic field, sort, operator, and projection choices with an allowlisted contract.
+- Apply SQL-specific syntax rules only to SQL datastores.
 
-## F3b. Transaction Isolation
+Inject into `{{ FIXED_RULES_QUERY }}`.
 
-### F3b.1 Transaction Isolation
+## I7. Data Security
 
-- **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.
+- Apply least privilege to application identities and separate administrative access from runtime access.
+- Keep credentials outside source control and secure network exposure according to the deployment boundary.
+- Protect sensitive fields, logs, replicas, exports, and backups according to the selected sensitivity classification.
+- Do not log secrets or unrestricted personal data.
 
----
+Inject into `{{ FIXED_RULES_SECURITY }}`.
 
-## F4. Migration Management
+## I8. Recovery Integrity
 
-- **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.
+- The selected backup decision must state accepted data-loss and recovery-time risk.
+- When backups are required, protect them independently from the primary datastore and verify restoration on a schedule appropriate to the risk.
+- Development-only `no automatic backup` is rendered explicitly and must not be contradicted by a universal production backup mandate.
 
----
+Inject into `{{ FIXED_RULES_BACKUP }}`.
 
-## F5. Query Standards
+## I9. Performance Integrity
 
-- **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.
+- Establish performance targets from the selected workload and scale.
+- Monitor resource saturation and slow operations using capabilities available for the selected datastore.
+- Do not require partitioning, replication, or archival solely from a generic threshold without considering access patterns and operational cost.
 
----
+Inject into `{{ FIXED_RULES_PERFORMANCE }}`.
 
-## F6. Security & Permissions
+## I10. Connection and Client Lifecycle
 
-- **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.
+- Reuse datastore clients or pools according to driver guidance; close or release resources deterministically.
+- Size concurrency against total service instances and datastore capacity rather than a per-process hardcoded formula.
+- Embedded or connectionless stores render the applicable client-lifecycle rule instead of a server pool requirement.
 
----
+Inject into `{{ FIXED_RULES_CONNECTION }}`.
 
-## F7. Backup & Recovery
+## I11. AI Data-Change Safety
 
-- **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.
+- Read the current schema/model and migration history before proposing a structural change.
+- State target datastore, environment, compatibility impact, lock/rewrite risk where applicable, and recovery plan.
+- Never execute destructive operations against user or production data without explicit authorization from the selected permission policy.
+- Concrete DDL generation and execution rights come only from `{{ ai_ddl_rule }}` and `{{ ai_safety_rule }}`.
 
----
+Inject into `{{ FIXED_RULES_AI_BASE }}`.
 
-## F8. Performance
+## Injection Contract
 
-- **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.
+Copy each invariant block only into its named placeholder. If a selected datastore or operational decision makes a block inapplicable, render the compatible invariant meaning or an explicit not-applicable statement; never inject relational rules into a document or embedded datastore by default.

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

@@ -11,14 +11,14 @@
 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
+   - `all recommended` / `one-click` → explicit authorization to adopt each remaining applicable recommended option; ask any question whose recommendation is ambiguous for the selected datastore
    - `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 make choices for the user before they explicitly answer, except concrete defaults covered by the user's explicit Quick/all-recommended authorization.
    - Must not fabricate user preferences to complete the answer set.
    - Must not output more than 3 questions in a single message.
 
@@ -64,26 +64,31 @@ Total: 15 questions.
 ## G2 — Data Modeling
 
 ### Q3. Primary Key Strategy
-- **Options**:
+- **Options for relational or embedded SQL datastores**:
   - 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."
+- **Options for MongoDB**:
+  - A) Native ObjectId **【Recommended】**
+  - B) UUID v7
+  - C) ULID
+- **Note**: Options vary by Q1. Direct auto-increment selection includes the explicit external-reference limitation; MongoDB never inherits relational auto-increment rules.
 - **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.
+- **Note**: Determines deletion filtering, recovery, lifecycle, and active-record uniqueness rules using capabilities of the selected datastore.
 - **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.
+### Q5. Modeling / Normalization Level
+- **Conditional logic**: Ask for relational and embedded SQL datastores. For MongoDB, auto-derive `Document modeling: embedding vs. references follows access patterns and consistency boundaries` and do not ask a 3NF question.
+- **Options when asked**:
+  - A) Strict 3NF; denormalization requires evidence and documented consistency handling **【Recommended】**
+  - B) Allow partial denormalization for confirmed reporting or performance paths
+- **Note**: Determines the selected data-redundancy policy without applying relational normalization to document storage.
 - **Maps to**: `{{ normalization }}` + `{{ schema_rules }}`
 
 ---
@@ -102,20 +107,20 @@ Total: 15 questions.
 
 ## G4 — Index & Performance
 
-### Q7. Query Complexity
+### Q7. Workload Type
 - **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.
+  - A) OLTP (frequent bounded reads/writes and short atomic operations) **【Recommended for transactional web applications】**
+  - B) OLAP (large scans, aggregations, and batch analytics)
+  - C) Mixed (transactional plus confirmed reporting/analytics paths)
+- **Note**: Numeric service objectives and maintenance windows require project evidence; they are not hidden defaults of a workload label.
 - **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.
+  - C) > 10M records/documents in a major collection (large scale, explicit access-path and lifecycle plan required)
+- **Note**: Scale triggers evaluation of partitioning, sharding, archival, and index operations; it does not make time partitioning universally mandatory.
 - **Maps to**: `{{ data_scale }}` + `{{ performance_rules }}`
 
 ---
@@ -124,9 +129,9 @@ Total: 15 questions.
 
 ### 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.
+  - A) Contains personal, regulated, credential, or equivalent sensitive data
+  - B) Business/public data only, with no identified special classification
+- **Note**: Select from the product's actual data inventory; this is not a preference that Quick mode may guess. Choosing A derives encryption, redaction, retention, and access rules from the identified field classes rather than claiming every value is reversibly encrypted.
 - **Maps to**: `{{ data_sensitivity }}` + `{{ security_rules }}`
 
 ### Q10. Audit Requirements
@@ -135,7 +140,7 @@ Total: 15 questions.
   - 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.
+- **Note**: Choose C when both capabilities are required; do not encode a free-form multi-select value. Audit and CDC have separate trust, retention, transport, and failure contracts.
 - **Maps to**: `{{ audit }}` + `{{ audit_rules }}`
 
 ---
@@ -160,10 +165,10 @@ Total: 15 questions.
 
 ### 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.
+  - A) Managed failover or primary-replica topology **【Recommended when the confirmed availability target requires it】**
+  - B) Single instance is sufficient **【Recommended for development or an accepted low-availability workload】**
+  - C) Multi-writer/multi-region topology (only with a documented consistency need)
+- **Note**: Determines failover and connection behavior from the selected availability objective; read/write splitting is not implied unless the workload and datastore support it.
 - **Maps to**: `{{ ha }}` + `{{ ops_rules }}`
 
 ---
@@ -174,7 +179,7 @@ Total: 15 questions.
 - **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)
+  - C) AI may generate DDL and execute it only in an explicitly identified disposable development environment under Q15 safety confirmation
 - **Maps to**: `{{ ai_ddl_rule }}`
 
 ### Q15. AI Safety Constraints

package/bundled/skills/app-planner/references/rules/database/question-manifest.json

@@ -1,9 +1,18 @@
 {
-  "schema_version": "app-planner-question-manifest-v1",
+  "schema_version": "app-planner-question-manifest-v2",
   "layer": "database",
   "total_questions": 15,
   "_doc": "Machine-readable structure for database question-bank.md. Question TEXT/options/Recommended/Notes are authoritative in question-bank.md; this file carries ONLY structure: group membership, quick-mode, question->placeholder mapping, and conditional logic. Keep Qids and group ids in sync with question-bank.md. The AI reads this as its asking checklist (Phase A) and self-check expected-set (Phase D).",
   "_conditions": "required_if / auto_derived_when use simple expressions over recorded answers. options_vary_by names a prior answer that changes the OPTION LIST only (question is still asked; never affects required). A single answer may fill more than one placeholder (a TL;DR value + a rules-block), both listed in maps_to.",
+  "render_contract": {
+    "fixed_rules_policy": "invariants_only",
+    "selected_decision_precedence": true,
+    "quick_mode_requires_explicit_authorization": true,
+    "unmapped_option_policy": "semantic_fallback",
+    "not_applicable_policy": "explicit_statement",
+    "conflict_policy": "fail_generation",
+    "semantic_fallback_questions": ["Q1", "Q2", "Q3", "Q4", "Q5", "Q6", "Q7", "Q8", "Q9", "Q10", "Q11", "Q12", "Q13", "Q14", "Q15"]
+  },
   "groups": [
     { "id": "G1", "topic": "Database Selection", "quick_mode": true },
     { "id": "G2", "topic": "Data Modeling", "quick_mode": true },
@@ -16,11 +25,11 @@
   "questions": [
     { "id": "Q1", "group": "G1", "topic": "Primary Database", "maps_to": ["database", "tech_rules"], "required": true },
     { "id": "Q2", "group": "G1", "topic": "Cache Layer", "maps_to": ["cache", "cache_rules"], "required": true },
-    { "id": "Q3", "group": "G2", "topic": "Primary Key Strategy", "maps_to": ["pk_strategy", "schema_rules"], "required": true },
+    { "id": "Q3", "group": "G2", "topic": "Primary Key Strategy", "maps_to": ["pk_strategy", "schema_rules"], "required": true, "options_vary_by": "Q1" },
     { "id": "Q4", "group": "G2", "topic": "Soft Delete", "maps_to": ["soft_delete", "schema_rules"], "required": true },
-    { "id": "Q5", "group": "G2", "topic": "Normalization Level", "maps_to": ["normalization", "schema_rules"], "required": true },
+    { "id": "Q5", "group": "G2", "topic": "Modeling / Normalization Level", "maps_to": ["normalization", "schema_rules"], "required": true, "required_if": "Q1 != C", "auto_derived_when": "Q1 == C" },
     { "id": "Q6", "group": "G3", "topic": "Migration Tool", "maps_to": ["migration_tool", "migration_rules"], "required": true },
-    { "id": "Q7", "group": "G4", "topic": "Query Complexity", "maps_to": ["workload_type", "performance_rules"], "required": true },
+    { "id": "Q7", "group": "G4", "topic": "Workload Type", "maps_to": ["workload_type", "performance_rules"], "required": true },
     { "id": "Q8", "group": "G4", "topic": "Estimated Data Volume", "maps_to": ["data_scale", "performance_rules"], "required": true },
     { "id": "Q9", "group": "G5", "topic": "Data Sensitivity Level", "maps_to": ["data_sensitivity", "security_rules"], "required": true },
     { "id": "Q10", "group": "G5", "topic": "Audit Requirements", "maps_to": ["audit", "audit_rules"], "required": true, "multi_select": true },