prizmkit 1.1.153 → 1.1.155

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.153",
+  "version": "1.1.155",
   "skills": {
     "prizmkit": {
       "description": "Framework introduction and navigation for the formal single-requirement lifecycle, project initialization, Prizm docs, and independent deployment.",
@@ -23,35 +23,35 @@
       "hasScripts": false
     },
     "prizmkit-plan": {
-      "description": "Formal requirement lifecycle entry: natural language → spec.md and plan.md with mandatory Main-Agent planning review, optional capability-gated independent correctness review, stable artifact identity, and workflow-state handoff.",
+      "description": "Create and review spec.md and plan.md for one supplied requirement; return PLAN_READY or PLAN_BLOCKED.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": true,
       "hasScripts": false
     },
     "prizmkit-implement": {
-      "description": "Execute a reviewed formal requirement plan, preserve artifact identity, and route implementation repairs to the correct review or test gate.",
+      "description": "Execute one reviewed plan or explicit repair scope, perform focused verification, and return IMPLEMENTED or IMPLEMENT_BLOCKED.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
       "hasScripts": false
     },
     "prizmkit-code-review": {
-      "description": "Mandatory bounded Main-Agent code review plus optional capability-gated independent correctness review, with evidence-based adjudication, direct repairs, verification, and append-only progress reporting.",
+      "description": "Review one supplied change with bounded Main-Agent repair, optional capability-gated independent review, verification, and PASS or NEEDS_FIXES output.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
       "hasScripts": true
     },
     "prizmkit-committer": {
-      "description": "Final formal-requirement commit gate: verifies all prior stages, confirms interactive commits or performs authorized headless pipeline commits, and never pushes automatically.",
+      "description": "Create an explicitly confirmed interactive commit or prepare an exact Runtime commit request from caller-supplied evidence; never push automatically.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
       "hasScripts": false
     },
     "prizmkit-retrospective": {
-      "description": "Mandatory formal-requirement retrospective: updates durable Prizm docs or records NO_DOC_CHANGE with machine-verifiable result before commit.",
+      "description": "Synchronize durable Prizm docs for exact supplied change paths, or record NO_DOC_CHANGE; return RETRO_COMPLETE or RETRO_BLOCKED.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": true,
@@ -72,7 +72,7 @@
       "hasScripts": false
     },
     "prizmkit-test": {
-      "description": "AI-led project-native testing for the affected business module and Regression Ring, with bounded failure repair, mandatory Main-Agent review, optional strict independent Test Reviewer, and TEST_PASS/TEST_NEEDS_FIXES/TEST_BLOCKED results.",
+      "description": "AI-led project-native affected-module and Regression Ring testing with contract authority, test-double fidelity, consumer/provider compatibility, browser and Full-stack E2E classification, persistence re-entry, bounded repair, review, and TEST_PASS/TEST_NEEDS_FIXES/TEST_BLOCKED results.",
       "tier": "1",
       "category": "prizmkit-skill",
       "hasAssets": false,
@@ -159,12 +159,12 @@
       "hasScripts": false
     },
     "recovery-workflow": {
-      "description": "Detect whether interrupted work belongs to a direct requirement or autonomous pipeline, select the authoritative owner, and hand off without merging state machines.",
+      "description": "Detect valid active feature, bugfix, or refactor checkout records and return exact operation-first continuation commands without executing or mutating state.",
       "tier": "companion",
       "category": "orchestration-skill",
       "subcategory": "workflows",
       "hasAssets": false,
-      "hasScripts": false
+      "hasScripts": true
     }
   },
   "suites": {

package/bundled/skills/app-planner/SKILL.md

@@ -157,7 +157,7 @@ After Infrastructure configuration is complete (CP-AP-1.5), check whether the pr
 
 Rules are optional. If the user skips, AI uses general best practices freely — no reminders, no blocking.
 
-→ Read `${SKILL_DIR}/references/rules-configuration.md` for the full procedure: layer detection, configuration mode selection, interactive Q&A per layer, template rendering, and root.prizm RULES pointer update. Before rendering final rule files or updating the pointer, run the Pre-Generation Headless Context Completeness Gate on every proposed new or changed rule.
+→ Read `${SKILL_DIR}/references/rules-configuration.md` for the full contract: layer detection, explicit Quick/Full/Skip authorization, interactive decisions, invariant-only fixed rules, selected-option derivation with semantic fallback, dual-native profiles, conflict detection, deterministic resource validation, template rendering, and the `root.prizm` `RULES:` pointer update. Run `${SKILL_DIR}/scripts/validate-rules-configuration.py` before questioning and again before final rendering. Before writing rule files or updating the pointer, require both a passing decision-conflict gate and the Pre-Generation Headless Context Completeness Gate for every proposed new or changed rule.
 
 ### After rules configuration
 
@@ -289,7 +289,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
 | **CP-AP-1** | Conventions Checked | Current-host project instruction target resolved; its `### Project Conventions` section is loaded or asked and up to date | 1 |
 | **CP-AP-1.5** | Infrastructure Checked | Resolved project instruction target `### Infrastructure` section addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
-| **CP-AP-1.6** | Rules Configured | For each detected layer (from config.json or self-detection), rules file exists in `.prizmkit/rules/` or user explicitly skipped. `root.prizm` `RULES:` pointer up-to-date. | 2 |
+| **CP-AP-1.6** | Rules Configured | Rules resources pass deterministic validation; Quick defaults are explicitly authorized; every detected layer has a conflict-free `.prizmkit/rules/<layer>-rules.md` or an explicit skip; dual-native choices use separate profiles; no residual placeholders remain; `root.prizm` `RULES:` pointer is up to date. | 2 |
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing. **Auto-pass** for backend-only or non-UI projects. | 2 |
 | **CP-AP-4** | Project Brief Accumulated | The in-memory brief or `.prizmkit/plans/project-brief.draft.md` contains at least 3 ideas. For brownfield: already-implemented items marked `[x]` count toward this total. The final brief is not written before CP-AP-5.5. | 3 |
@@ -304,7 +304,7 @@ Run this gate before any final handoff whenever the current `app-planner` sessio
 1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for app-planner generated content review.
 2. **Read actual planning artifacts directly**: inspect current-session final outputs such as `.prizmkit/plans/project-brief.md`, changed sections in the resolved project instruction target, `.prizmkit/rules/<layer>-rules.md`, and `.prizmkit/prizm-docs/root.prizm` `RULES:` pointer line. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
 3. **Scope to new/changed app-planning content**: compare against pre-session snapshots or in-memory drafts when available. Preserve unchanged historical brief items, instruction-file sections, rules files, and Prizm doc content. For explore-only sessions, draft-save exits, or flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
-4. **Run the local checklist and fresh-session simulation** from the reference: project brief completeness, consistency of conventions/infrastructure/architecture decisions, rules pointer consistency, normalization of selected decisions, purpose-tagged references, app-planner writable-boundary compliance, and downstream `feature-planner` readiness to produce `.prizmkit/plans/feature-list.json` without guessing or seeing the original conversation.
+4. **Run the local checklist and fresh-session simulation** from the reference: project brief completeness; consistency of conventions, infrastructure, and architecture decisions; Rules Configuration resource-validation and conflict-gate evidence; selected-decision precedence; explicit not-applicable/deferred sections; dual-native profile separation; rules pointer consistency; normalization of selected decisions; purpose-tagged references; app-planner writable-boundary compliance; and downstream `feature-planner` readiness to produce `.prizmkit/plans/feature-list.json` without guessing or seeing the original conversation.
 5. **Apply accepted fixes through the source/writer path**: project brief fixes go through the draft/checklist source, instruction-file section fixes go through the resolved project instruction target's section source with user confirmation when changing approved wording, rules fixes re-render from rules configuration answers/templates when available, and `root.prizm` fixes are limited to the `RULES:` pointer line.
 6. **Recheck changed sections directly** after every accepted fix batch.
 7. **Report CP-AP-6** in the completion summary: include local generated-plan review verdict, reviewed app-planning artifacts/sections, accepted fixes (or "none"), and final writer/validation result.

package/bundled/skills/app-planner/references/generated-plan-review.md

@@ -33,7 +33,7 @@ Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whethe
 
 - `project-brief.md` fixes go through the draft/checklist project brief source representation described in `project-brief-guide.md`, then rewrite the final brief through the existing project brief writer path.
 - Project conventions, infrastructure, frontend design direction, and architecture decisions are source sections in the exact project instruction target selected for the current session. If a fix changes user-approved wording or meaning, ask for user confirmation before rewriting.
-- `.prizmkit/rules/<layer>-rules.md` fixes should re-render from the rules configuration answers and template inputs when available. If no structured source remains, update the source rule section explicitly and report that source path.
+- `.prizmkit/rules/<layer>-rules.md` fixes should re-render from the normalized decision ledger, invariant/derivation sources, and template inputs. Rerun `scripts/validate-rules-configuration.py` and the Rules Configuration conflict gate before rewriting. If no structured source remains, rebuild the decision ledger or ask for clarification; do not hand-patch a contradictory final rule file.
 - `root.prizm` fixes are limited to correcting or adding the `RULES:` pointer line; do not rewrite unrelated root content.
 
 ## Review Checklist
@@ -43,6 +43,7 @@ For every reviewed app-planning artifact or section, check:
 - Project brief completeness: goal, users, differentiators, constraints, tech stack assumptions, and at least three actionable ideas when producing a final brief
 - Consistency among conventions, infrastructure, architecture decisions, and project brief content
 - Infrastructure completeness or explicit deferral for database, deployment, and cloud services topics when those flows ran
+- Rules Configuration integrity: the deterministic resource validator passed; Quick defaults were explicitly authorized; fixed content contains only invariants; selected decisions own their policy domains; no active rule conflicts with the decision ledger; unmatched/not-applicable choices are explicit; dual-native decisions remain in separate iOS/Android profiles; and rendered files contain no residual placeholders
 - Rules pointer consistency: generated `.prizmkit/rules/<layer>-rules.md` files are referenced by the `root.prizm` `RULES:` line when rules were configured
 - Substantive user meaning and detail preservation at matching detail after conversational normalization in project brief ideas, conventions, infrastructure notes, architecture decisions, and rules
 - Artifact-wide readability: every generated natural-language value across all AI-visible fields and sections—including briefs/drafts, instruction sections, generated rules, appendices, comments, brainstorm summaries, quoted evidence, and parentheticals—is a standalone domain statement without dialogue-role labels, question IDs, answer tokens, planning-option recommendation markers, raw answer-map content, or planning provenance

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

@@ -13,6 +13,11 @@
 
 ---
 
+## SEMANTIC_FALLBACK_POLICY
+
+Every confirmed option is valid input even when no pre-authored block exists. For an unmatched framework, ORM, datastore, deployment, observability, or permission option, render the complete selected meaning, follow current official and detected project conventions, preserve brownfield behavior unless migration was selected, and import no rules from a recommended alternative. Render `none`, `not required`, deferred, and conditionally skipped decisions as explicit not-applicable or deferred statements; never leave placeholders blank.
+
+Validate active blocks against the decision ledger before rendering. Architecture, API style, authentication, data technology, testing, observability, and AI permissions each have one selected owner; incompatible blocks fail generation.
 
 ## Phase 2 Normalized Semantic Fill Table
 
@@ -124,9 +129,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-NODE-02
 **Trigger**: Q1 = Node.js | **Inject into**: `{{ tech_stack_rules }}`
 
-- Package manager locked to `pnpm` (recommended). Commit `pnpm-lock.yaml`.
-- `package.json` declares `"type": "module"`.
-- CI validates `engines` field matches `.nvmrc`.
+- Preserve the package manager and lockfile already selected by the project; do not introduce a different manager as an implicit Node.js default.
+- `package.json` declares the selected module format explicitly when the runtime requires it.
+- Keep runtime declarations used by package metadata, local tooling, and CI consistent.
 
 ### D-PYTHON-01
 **Trigger**: Q1 = Python | **Inject into**: `{{ tech_stack_rules }}`
@@ -354,38 +359,35 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-MONGO-01
 **Trigger**: Q8 = MongoDB | **Inject into**: `{{ data_rules }}`
 
-- MongoDB document model: schema validation via JSON Schema (`$jsonSchema` validator on collections).
-- Indexing strategy for query patterns: create indexes for all query filter fields. Use `explain()` to verify index usage.
-- Aggregation pipeline standards: stages must be documented with purpose comments. Forbid complex pipelines without EXPLAIN.
-- No-SQL injection prevention: validate and sanitize all user input in queries. Use parameterized query operators (`$eq`, `$gt`), forbid `$where` with user input.
-- Collection design with embedded vs. reference trade-offs: embed for read-together data, reference for independently-accessed data.
-- The relational-database-oriented F5 fixed rules (migration files, SELECT syntax, normalization) do NOT apply. Skip F5.1-F5.3 of the fixed rules content.
+- Define collection validation at the database or application boundary and keep it synchronized with the selected model source.
+- Derive indexes from measured query/sort paths and verify expensive operations with `explain()`; do not index every filterable field automatically.
+- Treat field names and query operators as allowlisted input and never evaluate caller-controlled `$where` or executable expressions.
+- Choose embedding versus references from aggregate ownership, update atomicity, document growth, and access patterns.
+- Apply document-model, migration, and query rules only; do not import relational SQL or 3NF rules.
 
 ### D-MYSQL-01
 **Trigger**: Q8 = MySQL | **Inject into**: `{{ data_rules }}`
 
-- MySQL 8.0+ with InnoDB engine default. Use `utf8mb4` charset for all tables.
-- Forbid `utf8mb3` (deprecated). Forbid MyISAM engine (no transaction support).
-- Index types: BTREE for range queries, HASH for exact-match lookups (memory tables only).
-- Connection pool: configure `wait_timeout` and `interactive_timeout` to prevent stale connections.
-- Migration files use the same tooling as PostgreSQL (golang-migrate, Flyway, Alembic). Schema differences documented in README.
+- Use a supported MySQL release and a transactional engine for state requiring atomicity.
+- Use `utf8mb4` for Unicode text and reject deprecated encodings in new structures.
+- Select indexes from query patterns and engine support, and configure client lifetime against server timeouts.
+- Use the migration mechanism selected by the project; do not inherit PostgreSQL syntax or tooling.
 
 ### D-SQLITE-01
 **Trigger**: Q8 = SQLite | **Inject into**: `{{ data_rules }}`
 
-- SQLite for local development and single-instance deployments. WAL mode enabled by default.
-- Forbid SQLite for multi-instance production deployments (no concurrent write support).
-- Forbid concurrent write access across multiple processes. Use a single writer pattern.
-- Migration files still version-controlled. Test with the same SQLite version as production.
-- No connection pool needed (single connection). Close connections explicitly after each operation.
+- Use SQLite only for a workload whose concurrency, durability, and deployment model match its capabilities.
+- Choose journal/WAL mode from the read/write and filesystem constraints and serialize writes when required.
+- Version model changes and test with the supported production SQLite version when SQLite is the deployed store.
+- Follow the selected driver lifecycle; do not impose a server-style connection pool.
 
 ### D-JWT-01
 **Trigger**: Q9 = JWT | **Inject into**: `{{ auth_rules }}`
 
-- Access token TTL ≤ 15min. Refresh token TTL ≤ 7d.
-- Token payload contains no sensitive info (passwords, phone numbers). Only userId + role.
-- Secret read from environment variables. Forbid hardcoding.
-- Token blacklist (logout/password change invalidation) implemented with Redis.
+- Define issuer, audience, subject, scopes/claims, signing algorithm, access lifetime, refresh/re-issuance, rotation, and revocation from the threat model.
+- Keep sensitive data out of token payloads and validate signature plus temporal and audience claims at every trust boundary.
+- Keep signing material outside source control and support key rotation.
+- Implement revocation through a compatible selected mechanism; JWT does not implicitly authorize Redis.
 
 ### D-OAUTH-01
 **Trigger**: Q9 = OAuth2 | **Inject into**: `{{ auth_rules }}`
@@ -398,19 +400,17 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-SESSION-01
 **Trigger**: Q9 = Session | **Inject into**: `{{ auth_rules }}`
 
-- Session storage uses Redis, not memory (loses data on restart, not shared across instances).
-- Session ID generated with `crypto.randomUUID()`, not auto-increment IDs.
-- Cookie settings: `HttpOnly` + `Secure` (production) + `SameSite=Lax`.
-- Session ID must be rotated after successful login (prevent Session Fixation).
+- Store sessions in a mechanism compatible with the selected deployment and availability topology; an external cache is not implied when Q10 selected no cache.
+- Generate high-entropy opaque session identifiers, rotate them at authentication/privilege changes, and invalidate them on logout.
+- Use `HttpOnly`, production `Secure`, and a SameSite/CSRF policy compatible with confirmed cross-site flows.
 
 ### D-APIKEY-01
 **Trigger**: Q9 = API Key | **Inject into**: `{{ auth_rules }}`
 
-- API keys for service-to-service communication. Not for end-user auth.
-- Keys stored hashed (SHA-256) in database. Plaintext shown once at creation.
-- Key format: `sk_<random_32_bytes_base64url>` with prefix for easy identification in logs.
-- Key validation: constant-time comparison to prevent timing attacks.
-- Keys must have expiration (default 365d). Must be rotatable without downtime.
+- Restrict API keys to named machine or integration principals, not end-user authentication.
+- Generate high-entropy keys, display plaintext only at creation, and store a one-way verifier plus a non-secret lookup prefix.
+- Compare verifiers safely and support scoped authorization, rotation, revocation, ownership, and last-used audit data.
+- Set expiry from integration risk and lifecycle rather than a universal duration.
 
 ### D-REDIS-01
 **Trigger**: Q10 = Redis | **Inject into**: `{{ cache_rules }}`
@@ -462,18 +462,16 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-DOCKER-01
 **Trigger**: Q12 = Docker | **Inject into**: `{{ deploy_rules }}`
 
-- Dockerfile uses multi-stage builds. Final image excludes build tools.
-- Base image uses `-slim` or `-alpine` variants.
-- Health check: `HEALTHCHECK` points to `/health` endpoint.
-- `.dockerignore` excludes node_modules, .git, log files.
+- Use a reproducible build and a minimal runtime image compatible with the selected language/runtime; do not force Alpine when native dependencies make it unsafe.
+- Exclude build-only tools and sensitive/unneeded context from the final image.
+- Connect container health behavior to the selected application liveness/readiness contract rather than assuming one route.
 
 ### D-K8S-01
 **Trigger**: Q12 = Kubernetes | **Inject into**: `{{ deploy_rules }}`
 
-- Must configure liveness and readiness probes (pointing to `/health` and `/health/ready`).
-- Resource limits (requests/limits) must be set.
-- Sensitive config via Secret, non-sensitive via ConfigMap.
-- Pod anti-affinity: same-type pods not scheduled on the same node (high availability).
+- Configure probes against the application's selected liveness/readiness contract and set resource requests/limits from measured behavior.
+- Keep sensitive and non-sensitive configuration in the platform's appropriate boundaries without committing secret values.
+- Replicas, disruption budgets, anti-affinity, and multi-zone placement come from the confirmed availability objective; Kubernetes selection alone does not require them.
 
 ### D-AI-DEP-STRICT-01
 **Trigger**: Q18 = Forbid | **Inject into**: `{{ ai_dependency_rule }}`
@@ -519,10 +517,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-OBS-LOG-01
 **Trigger**: Q16 = Structured JSON logging | **Inject into**: `{{ observability_rules }}`
 
-- Log format: JSON with fields `timestamp`, `level`, `message`, `traceId`, `userId`, `service`, `path`, `method`, `duration_ms`.
-- Centralized collection via ELK (Elasticsearch + Logstash + Kibana) or Grafana Loki.
-- Log levels: ERROR (requires alert), WARN (requires investigation), INFO (key business events), DEBUG (development only).
-- Forbid logging sensitive data (passwords, tokens, national IDs). Must mask.
+- Emit structured events with timestamp, severity, message, service/operation, and available correlation context; add identity or request fields only when useful and privacy-safe.
+- Send events through the centralized collection boundary selected by the deployment; do not force ELK or Loki.
+- Define severity and alert mappings operationally, and redact credentials, tokens, and sensitive personal data.
 
 ### D-OBS-LOG-02
 **Trigger**: Q16 = local files | **Inject into**: `{{ observability_rules }}`
@@ -543,26 +540,23 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-OBS-METRICS-01
 **Trigger**: Q17 = OpenTelemetry + Prometheus + Grafana | **Inject into**: `{{ observability_rules }}`
 
-- OpenTelemetry SDK auto-instruments HTTP/gRPC/database calls.
-- Custom metrics: request count, request duration (p50/p95/p99), error rate, DB query duration.
-- Prometheus scrapes `/metrics` endpoint. Grafana dashboards for: request latency, error rate, DB connection pool, cache hit rate.
-- Alerting rules: error rate > 5% for 5min triggers alert, p95 latency > 500ms for 5min triggers warning.
+- Instrument applicable transport and dependency boundaries with the selected OpenTelemetry-compatible pipeline.
+- Define service metrics and dashboards from confirmed service objectives and selected dependencies; cache metrics appear only when caching is selected.
+- Expose or export telemetry through the selected collector/platform mechanism and derive alert thresholds from objectives and observed baselines rather than universal percentages.
 
 ### D-TEST-STRATEGY-01
 **Trigger**: Q13 = Unit tests + Integration tests | **Inject into**: `{{ test_rules }}`
 
-- Testing tiers: unit tests (service/repository layers) + integration tests (API endpoints + DB).
-- Unit tests: fast (<100ms each), no external deps. Mock all I/O.
-- Integration tests: use test database or testcontainers. Test realistic scenarios.
-- Coverage targets: service layer >= 80%, controller layer >= 60%.
-- CI runs all tests. Integration tests run against a fresh DB instance each time.
+- Include unit and integration behavior appropriate to the selected architecture and external boundaries.
+- Unit tests isolate owned behavior; integration tests verify real contract boundaries using the separately selected mock/environment strategy.
+- Set numeric coverage or timing thresholds only when the project confirms them. CI runs the enabled tiers in deterministic isolation.
 
 ### D-TEST-STRATEGY-02
 **Trigger**: Q13 = Unit tests only | **Inject into**: `{{ test_rules }}`
 
-- Unit tests only. Coverage target: service layer >= 80%.
-- External deps mocked. No database or network access in tests.
-- Recommend adding integration tests for critical data-access paths before production.
+- Keep the mandatory suite at the unit boundary selected by the project and isolate external dependencies according to Q15.
+- Do not inject an unselected coverage percentage.
+- Record the accepted lack of integration evidence and revisit it when production risk changes.
 
 ### D-TEST-STRATEGY-03
 **Trigger**: Q13 = Critical path integration tests only | **Inject into**: `{{ test_rules }}`
@@ -574,10 +568,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-TEST-MOCK-01
 **Trigger**: Q15 = testcontainers | **Inject into**: `{{ test_rules }}`
 
-- External APIs (payment gateways, email services, third-party SDKs): mocked.
-- Database: use testcontainers (dockerized Postgres/MySQL/Redis) for integration tests.
-- Testcontainers lifecycle: start before test suite, stop after. Use singleton container pattern to share across tests.
-- Test data: seeded per test file, cleaned up after each test. Forbid shared mutable test data.
+- Mock external service dependencies at their contract boundary.
+- For datastore integration tests, use a testcontainer or an in-memory implementation only when it faithfully represents the selected datastore behavior; do not start Redis unless caching/session decisions require it.
+- Bound environment lifecycle and isolate mutable test data so tests remain repeatable.
 
 ### D-TEST-MOCK-02
 **Trigger**: Q15 = including database | **Inject into**: `{{ test_rules }}`
@@ -590,10 +583,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-TEST-MOCK-03
 **Trigger**: Q15 = real environments | **Inject into**: `{{ test_rules }}`
 
-- Prefer real environments over mocking. Tests run against dedicated test infrastructure.
-- Test database is a shared instance (not per-developer).
-- Test data isolation: each test creates its own data and cleans up.
-- Requires CI access to test infrastructure. Tests may be slower but more realistic.
+- Prefer representative real dependencies through dedicated test infrastructure where the selected risk justifies it.
+- Shared infrastructure must still isolate tenants/data and support deterministic cleanup; a shared instance is not automatically required.
+- Document CI access, cost, failure ownership, and any remaining non-production differences.
 
 ---