prizmkit 1.1.154 → 1.1.156

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

@@ -12,6 +12,11 @@
 
 ---
 
+## SEMANTIC_FALLBACK_POLICY
+
+Every confirmed option is valid input even when no pre-authored block exists. Render unmatched choices as complete datastore-specific rules using current official and detected project conventions, without borrowing a recommended alternative's SQL, topology, backup, or permission policy. Render `no cache`, `no audit`, deferred, development-only, and conditionally skipped decisions explicitly; never leave placeholders blank.
+
+Validate all active blocks against the decision ledger. Datastore model, identifier strategy, normalization/document modeling, backup/availability, and AI execution permissions each have one owner. Incompatible combinations fail generation and return to clarification.
 
 ## Phase 2 Normalized Semantic Fill Table
 
@@ -49,6 +54,7 @@ Resolve each selected option or custom reply into the complete semantic value sh
 | Q1 = SQLite | `D-SQLITE-01` | `{{ tech_rules }}` |
 | Q2 = Redis | `D-REDIS-BACKEND-01` | `{{ cache_rules }}` |
 | Q2 = Memcached | `D-MEMCACHED-DB-01` | `{{ cache_rules }}` |
+| Q3 = Native ObjectId | `D-MONGO-ID-01` | `{{ schema_rules }}` |
 | Q3 = UUID v7 | `D-UUID-01` | `{{ schema_rules }}` |
 | Q3 = ULID | `D-ULID-01` | `{{ schema_rules }}` |
 | Q3 = Auto-increment + UUID mapping | `D-AUTOINC-01` | `{{ schema_rules }}` |
@@ -142,6 +148,13 @@ Resolve each selected option or custom reply into the complete semantic value sh
 - No persistence — data lost on restart. Only cache data that can be regenerated from the database.
 - Client sharding across multiple memcached instances via consistent hashing.
 
+### D-MONGO-ID-01
+**Trigger**: Q1 = MongoDB and Q3 = Native ObjectId | **Inject into**: `{{ schema_rules }}`
+
+- Use MongoDB `_id` with native ObjectId semantics as the document identity unless a confirmed integration requires another stable public identifier.
+- If public URLs must not expose `_id`, add an explicit opaque public identifier; do not imply relational auto-increment mapping.
+- References and indexes use the selected identifier type consistently.
+
 ### D-UUID-01
 **Trigger**: Q3 = UUID v7 | **Inject into**: `{{ schema_rules }}`
 
@@ -160,25 +173,24 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-AUTOINC-01
 **Trigger**: Q3 = Auto-increment + UUID mapping | **Inject into**: `{{ schema_rules }}`
 
-- Primary keys use `BIGINT AUTO_INCREMENT`. Do not expose to API.
-- API layer uses UUID (ID mapping in service layer or an additional UUID column).
-- Strictly forbid exposing auto-increment IDs in URLs or responses.
+- Use the selected datastore's monotonic numeric identity mechanism for the internal key and a separate UUID for external identity.
+- Define one authoritative mapping between the two identifiers and index the external UUID uniquely.
+- External contracts expose the UUID, not the internal sequence value.
 
 ### D-DIRECT-AUTOINC-01
 **Trigger**: Q3 = Direct auto-increment | **Inject into**: `{{ schema_rules }}`
 
-- Direct auto-increment IDs for internal use only.
-- Forbid exposing auto-increment IDs in URLs, API responses, or any client-facing layer.
-- Use UUIDs or opaque tokens for all external references.
-- Auto-increment IDs must be BIGINT (never INT for production tables expected to grow).
+- Use the selected datastore's direct monotonic numeric identity mechanism.
+- This option's declared external-reference limitation remains active: do not expose sequence values through public URLs or contracts; add an opaque identifier if an external reference is later required.
+- Select numeric width from projected lifetime cardinality and datastore capability rather than a universal type name.
 
 ### D-SOFTDELETE-01
 **Trigger**: Q4 = deleted_at | **Inject into**: `{{ schema_rules }}`
 
-- Every table requiring soft delete adds `deleted_at TIMESTAMPTZ DEFAULT NULL`.
-- All queries default to filtering `WHERE deleted_at IS NULL`.
-- Unique indexes must include `deleted_at` (otherwise re-inserting the same unique key after deletion fails).
-- Periodically archive soft-deleted data older than N days (N based on business agreement).
+- Persist a nullable deletion marker using the selected datastore's appropriate timestamp or state representation for models that participate in soft deletion.
+- Default active-record access paths exclude deleted records, while authorized recovery/audit paths opt in explicitly.
+- Uniqueness applies to active records. Use a partial unique index where supported; otherwise use the datastore's supported generated-key, scoped-key, or transactional strategy.
+- Retention, restoration, legal erasure, and archival behavior come from the data lifecycle and sensitivity decisions.
 
 ### D-3NF-01
 **Trigger**: Q5 = Strict 3NF | **Inject into**: `{{ schema_rules }}`
@@ -189,134 +201,123 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-PARTIAL-DENORM-01
 **Trigger**: Q5 = Allow partial denormalization | **Inject into**: `{{ schema_rules }}`
 
-- Partial denormalization is permitted for OLAP, reporting, and performance-critical read paths.
-- Each denormalized field must: (a) be documented in the schema comment with 'DENORM:' prefix and the source table/column, (b) have a defined consistency maintenance strategy (application-level update, materialized view, periodic reconciliation), (c) be listed in a project-level denormalization-registry.md file.
-- Forbid denormalization on write-heavy OLTP paths.
+- Permit denormalization only for a named access path with evidence that the normalized model does not meet it.
+- Document the authoritative source, consistency mechanism, reconciliation behavior, and accepted staleness for each duplicated value.
+- Keep write amplification and concurrency behavior within the selected workload objective.
 
 ### D-ORM-MIGRATE-01
 **Trigger**: Q6 = ORM built-in | **Inject into**: `{{ migration_rules }}`
 
-- Migrations managed by ORM's built-in tool.
-- Always generate via ORM CLI commands; never hand-edit auto-generated migration files.
-- Version-control all migration files.
-- Test migrations on a staging database before deployment.
+- Use the selected ORM's supported migration workflow as the authoritative schema/model history.
+- Follow that tool's rules for generated versus editable migrations; do not impose another tool's file convention.
+- Version changes and verify forward compatibility plus the selected rollback/recovery path in an isolated representative environment before production.
 
 ### D-FLYWAY-01
 **Trigger**: Q6 = Standalone tool | **Inject into**: `{{ migration_rules }}`
 
-- Use Flyway (Java/Go) or Alembic (Python) as a standalone migration tool.
-- Migration file naming follows tool conventions. Each migration accompanied by a rollback file.
-- CI validates: migration file numbers are non-duplicate, non-regressing, previously executed migrations are not modified.
+- Use the explicitly selected standalone migration tool and its native ordering, checksum, and recovery conventions.
+- Keep applied migrations immutable and reject duplicate or regressing versions where the tool uses ordered versions.
+- A down migration is required only when safe and supported; otherwise document forward repair or restore behavior.
 
 ### D-MANUAL-MIGRATE-01
 **Trigger**: Q6 = Manual SQL files | **Inject into**: `{{ migration_rules }}`
 
-- Migration files follow naming convention: `V{YYYYMMDD}{HHmm}__{description}.sql` (forward) paired with `U{YYYYMMDD}{HHmm}__{description}.sql` (rollback).
-- Each migration must have a matching rollback file.
-- SQL review checklist: all statements idempotent where possible, no data loss in forward migration, rollback restores exact prior state.
+- Store ordered, immutable SQL migration files under one documented project convention.
+- Each change states prerequisites, forward effect, compatibility window, data transformation, operational risk, and safe recovery behavior.
+- Do not promise an exact rollback for destructive or irreversible transformations; use backup/restore or forward repair when that is the truthful strategy.
 
 ### D-OLTP-01
 **Trigger**: Q7 = OLTP | **Inject into**: `{{ performance_rules }}`
 
-- Slow query threshold set to 100ms.
-- Every query must be index-covered (EXPLAIN output shows no full table scan / full index scan).
-- Long transaction monitoring: transactions exceeding 5s trigger alerts.
-- Connection pool config: `pool_size = CPU cores × 2`. Max wait time ≤ 30s.
+- Optimize for frequent bounded reads/writes and short atomic operations.
+- Set slow-operation, transaction, and client-concurrency thresholds from the confirmed service objective and observed datastore capacity.
+- Full scans are acceptable only for demonstrably bounded datasets or maintenance paths; verify critical access paths with the datastore profiler.
 
 ### D-OLAP-01
 **Trigger**: Q7 = OLAP | **Inject into**: `{{ performance_rules }}`
 
-- Slow query threshold relaxed to 500ms.
-- Pre-aggregation tables / materialized views used for accelerating large queries.
-- Batch ETL executed during low-traffic hours (2–6 AM).
-- Forbid running DDL during OLAP query execution.
+- Optimize for analytical scans, aggregation, and batch throughput using capabilities of the selected datastore.
+- Choose pre-aggregation, materialized views, columnar paths, or batch windows only from measured query patterns.
+- Coordinate structural changes and heavy analytical work through documented resource and maintenance boundaries.
 
 ### D-MIXED-01
 **Trigger**: Q7 = Mixed | **Inject into**: `{{ performance_rules }}`
 
-- Dual slow query thresholds: OLTP queries <= 100ms, OLAP queries <= 500ms.
-- OLAP queries must use read replicas. Forbid running OLAP queries against the primary instance.
-- Pre-aggregation via materialized views for common reporting queries. Refresh during low-traffic hours (2-6 AM).
-- Forbid running DDL during OLAP query execution windows.
+- Classify transactional and analytical access paths separately and give each a confirmed service objective.
+- Isolate analytical load through replicas, warehouses, materialized data, or scheduling only when compatible with the selected availability topology and consistency needs.
+- Document resource contention and refresh/staleness behavior for shared infrastructure.
 
 ### D-PARTITION-01
 **Trigger**: Q8 = > 10M rows | **Inject into**: `{{ performance_rules }}`
 
-- Large tables partitioned by time range (monthly or quarterly). Indexes per partition.
-- New data written to the latest partition. Queries should include the partition key when possible.
-- Expired partitions are auto-detached + archived without affecting online service.
+- Evaluate partitioning or sharding from measured access paths, retention, write distribution, and operational support; scale alone does not force time partitioning.
+- When partitioning is selected, choose a key that enables pruning without creating hotspots and test cross-partition operations.
+- Archival and partition retirement follow the selected retention and backup rules.
 
 ### D-MEDIUM-SCALE-01
 **Trigger**: Q8 = 1M-10M rows | **Inject into**: `{{ performance_rules }}`
 
-- Plan partitioning strategy now even if not immediately needed. Reserve partition key columns.
-- Monitor table growth monthly. Trigger partition implementation at 5M rows.
-- Index maintenance: monthly reindex for fragmented indexes. Monitor index hit rates.
-- Archival strategy: identify cold data (> 90 days untouched) and plan archival path.
+- Record projected growth and monitor size plus critical access paths.
+- Reserve a partitioning strategy only when workload evidence identifies a viable key and benefit; do not add speculative columns or trigger at a universal row count.
+- Run datastore-specific index maintenance and archival from observed health and selected retention policy.
 
 ### D-PII-01
 **Trigger**: Q9 = Contains PII | **Inject into**: `{{ security_rules }}`
 
-- Sensitive fields (password hashes, national IDs, bank card numbers, phone numbers, email) must be encrypted at rest.
-- Passwords use bcrypt/argon2 hashing. Irreversible info uses AES-256-GCM encryption.
-- Database logs / slow query logs are auto-desensitized.
-- Database backup files must be encrypted at rest.
-- GDPR "right to be forgotten": user data deletion must be true deletion (or irreversible anonymization), not soft delete.
+- Classify sensitive fields and identify applicable legal, contractual, and product obligations before selecting controls.
+- Passwords use a current password-hashing construction and are never reversibly encrypted; reversible sensitive fields use authenticated encryption or an approved managed boundary when required.
+- Redact sensitive values from query/slow logs and protect exports and backups according to their classification.
+- Erasure, anonymization, retention, and soft deletion follow the applicable obligation; do not claim one jurisdiction universally.
 
 ### D-AUDIT-01
 **Trigger**: Q10 = Audit tables | **Inject into**: `{{ audit_rules }}`
 
-- Every audited table gets a corresponding `<table>_audit` table recording all INSERT/UPDATE/DELETE.
-- Audit table fields: `audit_id`, `operation` (I/U/D), `changed_by`, `changed_at`, `old_values`(JSONB), `new_values`(JSONB).
-- Audit tables populated via triggers. Application code does not write directly to audit tables.
-- Audit tables are partitioned and periodically archived.
+- Define audited entities, operations, actor attribution, before/after data policy, tamper resistance, access, and retention from the audit requirement.
+- Implement through datastore audit features, append-only records, triggers, or the application boundary according to the selected technology and trust model.
+- Use datastore-appropriate types; do not inject PostgreSQL JSONB or table-per-entity design into every datastore.
 
 ### D-CDC-01
 **Trigger**: Q10 = CDC | **Inject into**: `{{ audit_rules }}`
 
-- Use Debezium / Maxwell / PostgreSQL logical replication for CDC.
-- CDC events pushed to Kafka/message queue. Downstream consumers handle (sync to ES, data warehouse, cache invalidation).
-- CDC connectors must have dead letter queues configured. Failure must not obstruct primary database operation.
+- Select a CDC mechanism supported by the datastore or managed service and state snapshot, ordering, schema-change, offset, and duplicate-delivery behavior.
+- Route change events through the separately selected transport; CDC does not implicitly authorize Kafka or any message queue.
+- Make connector failure observable and define recovery without corrupting or blocking the primary write path.
 
 ### D-CLOUD-01
 **Trigger**: Q11 = Cloud managed | **Inject into**: `{{ ops_rules }}`
 
-- Automated backup enabled (default: retain 7+ days). Multi-AZ deployment.
-- Security group: only whitelisted IPs can access the database port.
-- Connections enforce SSL/TLS.
-- Upgrade windows set during low-traffic periods.
+- Use the selected managed service's private-network and identity controls and encrypt remote connections.
+- Configure backup strictly from Q12 and availability/failover strictly from Q13; managed deployment alone enables neither policy implicitly.
+- Choose upgrade and maintenance behavior from the confirmed availability objective and provider capability.
 
 ### D-SELFHOST-01
 **Trigger**: Q11 = Self-hosted | **Inject into**: `{{ ops_rules }}`
 
-- Database port not exposed to the public internet.
-- Monitoring must be set up: connections, slow queries, disk usage, replication lag.
-- Backup scripts run independently of application servers.
-- Regular recovery drills (at least quarterly).
+- Keep the datastore off the public internet and restrict administrative and runtime identities separately.
+- Monitor capacity, connections, and slow operations; monitor replication only when Q13 selected a replicated topology.
+- Implement backups and recovery verification strictly from Q12 rather than enabling them as a hidden self-hosting default.
 
 ### D-DOCKER-DEV-01
 **Trigger**: Q11 = Development environment Docker Compose | **Inject into**: `{{ ops_rules }}`
 
-- Docker Compose for local development only. Production deployment handled separately.
-- Database data persisted via Docker volumes. Forbid losing data on container restart.
-- docker-compose.yml committed to repository. Includes database service + cache service definitions.
-- Health checks configured for all services. Startup order managed via depends_on + healthcheck conditions.
+- Docker Compose is the selected local development boundary; production deployment remains a separate decision.
+- Persist database data through an explicit development volume unless an ephemeral reset was requested.
+- Commit the Compose definition when repository policy allows it. Include only selected services; a cache service appears only when Q2 selected one.
+- Configure health checks and dependency readiness for services that participate in the selected topology.
 
 ### D-PITR-01
 **Trigger**: Q12 = Daily full + continuous incremental | **Inject into**: `{{ ops_rules }}`
 
-- PostgreSQL: enable WAL archiving + `pgBackRest` / `WAL-G`.
-- MySQL: enable binlog + `XtraBackup` / `mysqlbackup`.
-- PITR Recovery Time Objective (RTO) ≤ 1 hour. Recovery Point Objective (RPO) ≤ 5 minutes.
-- Backups retained for 30 days, stored offsite.
+- Enable the selected datastore or managed service's continuous log/journal backup mechanism in addition to daily full backups.
+- Record the required RPO, RTO, retention, encryption, and independent storage boundary before production generation; do not invent numeric objectives.
+- Verify that one restore can reach a chosen point between full backups and capture the evidence.
 
 ### D-FULL-BACKUP-01
 **Trigger**: Q12 = Daily full backup only | **Inject into**: `{{ ops_rules }}`
 
-- Daily full backup via pg_dump/mysqldump/mongodump.
-- Backups retained for 7 days locally + 30 days offsite.
-- Warning: without continuous incremental/WAL archiving, PITR is not available. RPO = up to 24 hours.
-- Recovery drill: monthly restore test from latest backup.
+- Run one full backup per day through the selected datastore or managed service mechanism.
+- Record retention, encryption, storage independence, and restore-verification cadence from product and compliance needs.
+- Without continuous change-log backup, the accepted recovery point may lose changes since the latest successful full backup; state that risk explicitly.
 
 ### D-NO-BACKUP-01
 **Trigger**: Q12 = No automatic backup needed | **Inject into**: `{{ ops_rules }}`
@@ -328,33 +329,32 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-REPLICA-01
 **Trigger**: Q13 = Primary-replica | **Inject into**: `{{ ops_rules }}`
 
-- Read-write split: writes go to primary, reads go to replicas. Application code must explicitly distinguish read/write data sources.
-- Replication lag monitoring: alert when exceeding 5s.
-- Failover drills at least quarterly.
-- Connection pool config: primary pool small (fewer writes), replica pool large (more reads).
+- Configure the selected managed-failover or primary-replica topology and document its consistency behavior.
+- Route reads to replicas only when stale reads are acceptable and the application has an explicit read-routing boundary; failover alone does not imply read/write splitting.
+- Monitor replication/failover health against the selected availability objective and verify recovery at an approved cadence.
+- Size client pools from topology and datastore capacity rather than a universal primary/replica ratio.
 
 ### D-SINGLE-01
 **Trigger**: Q13 = Single instance is sufficient | **Inject into**: `{{ ops_rules }}`
 
-- Single database instance. No replication or failover.
-- Acceptable downtime window: defined by business (default: off-hours maintenance).
-- Warning: single point of failure. Instance failure = full service outage until restored from backup.
-- Connection pool sized for one instance. No read/write split needed.
+- Use one database instance with no database-level failover.
+- Record the accepted outage and recovery risk; do not invent a default maintenance window.
+- Size clients for one instance and do not create replica routing.
 
 ### D-MULTIMASTER-01
 **Trigger**: Q13 = Multi-master cluster | **Inject into**: `{{ ops_rules }}`
 
-- Multi-master replication. All nodes accept writes. Conflict resolution strategy must be explicitly chosen (last-write-wins / application-level merge / CRDT).
-- Auto-increment IDs must use offset-step allocation to avoid collisions across masters.
-- Application must handle replication lag (eventual consistency). Read-after-write may not see latest data.
-- Connection pool: separate pool per master. Load-balanced writes across all masters.
+- Use only a datastore-supported multi-writer topology and state its consistency and partition behavior.
+- Choose and test conflict resolution for the affected business invariants; do not assume last-write-wins is safe.
+- The selected identifier strategy must remain collision-safe across writers; apply datastore-supported allocation only when auto-generated numeric IDs were selected.
+- Route clients using the supported topology driver or service boundary rather than hand-built load balancing by default.
 
 ### D-AI-DDL-AUDIT-01
 **Trigger**: Q14 = Migration only | **Inject into**: `{{ ai_ddl_rule }}`
 
-- AI may generate migration files but must not execute them.
-- Each AI-generated migration must include: forward SQL + rollback SQL + EXPLAIN output + lock table analysis.
-- Migration files must be human-reviewed before execution.
+- AI may generate changes through the selected migration mechanism but must not execute them.
+- Each generated change states forward behavior, compatibility/rollback or recovery behavior, data transformation, and lock/rewrite or equivalent operational risk where applicable.
+- The generated migration or model change must be reviewed before execution.
 
 ### D-AI-DDL-FORBID-01
 **Trigger**: Q14 = Fully forbid | **Inject into**: `{{ ai_ddl_rule }}`
@@ -366,9 +366,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-AI-DDL-FREE-01
 **Trigger**: Q14 = Free operation | **Inject into**: `{{ ai_ddl_rule }}`
 
-- AI may freely generate and execute DDL in development environments.
-- All DDL changes must still be version-controlled in migration files.
-- Warning: free DDL operation is suitable for development only. Restrict before production deployment.
+- AI may generate DDL and may execute it only in an explicitly identified disposable development environment under the separately selected safety-confirmation policy.
+- All DDL changes remain version-controlled through the selected migration mechanism.
+- This permission never applies to shared, staging, or production data and must be narrowed before deployment.
 
 ### D-AI-SAFETY-STRICT-01
 **Trigger**: Q15 = Forbid destructive | **Inject into**: `{{ ai_safety_rule }}`