prizmkit 1.1.154 → 1.1.156

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

@@ -13,6 +13,11 @@
 
 ---
 
+## SEMANTIC_FALLBACK_POLICY
+
+Every confirmed option is valid input. When no pre-authored block exists, render a complete rule for the selected platform/profile using current official and detected project conventions; do not copy the recommended option's framework, library, navigation, testing, distribution, or permission rules. Render `not required`, `not determined`, flexible, and conditionally skipped choices explicitly instead of leaving placeholders blank.
+
+For dual-native mode, evaluate every block against the iOS or Android answer profile before injection. A block without one unambiguous profile owner fails generation. Validate navigation, platform features, testing, distribution, performance, and AI permissions against the decision ledger before output.
 
 ## Phase 2 Normalized Semantic Fill Table
 
@@ -23,7 +28,7 @@ Resolve each selected option or custom reply into the complete semantic value sh
 | `{{ project_name }}` | Phase 0 auto-read | `my-mobile-app` |
 | `{{ generated_at }}` | Phase 4, AI writes current date | `2026-05-24` |
 | `{{ platform }}` | Q1 answer | `Flutter (Dart)` |
-| `{{ min_os_version }}` | Q2 answer | `iOS 17+ / Android 14+` |
+| `{{ min_os_version }}` | Q2 answer | `One major release behind the latest stable OS for each active platform, resolved when generated` |
 | `{{ architecture }}` | Q3 answer | `MVVM` |
 | `{{ ui_framework }}` | Q4 answer | `Material Design 3` |
 | `{{ navigation }}` | Q5 answer | `GoRouter` |
@@ -44,7 +49,7 @@ Resolve each selected option or custom reply into the complete semantic value sh
 
 ## Trigger Map
 
-**Coverage policy**: 【Recommended】options always have trigger entries with rule blocks. Non-recommended options may or may not have triggers. If a user selects a non-recommended option with no matching trigger, the corresponding rule placeholder is intentionally left empty — the TL;DR table still records the user's choice, but no pre-authored derived rules exist for that option. The AI may suggest the user switch to the recommended option for better rule coverage.
+**Coverage policy**: Pre-authored blocks are conveniences, not an allowlist. Recommended and non-recommended options are equally valid. If no matching block exists, apply `SEMANTIC_FALLBACK_POLICY`; do not leave a placeholder empty or pressure the user to change a confirmed decision for better template coverage.
 
 **Q13/Q14 note**: Q13 and Q14 are direct-fill only (no derivation rule blocks). The TL;DR table documents the chosen frameworks. Detailed framework-specific rules are not auto-generated — the AI should apply the framework's official best practices.
 
@@ -122,92 +127,88 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-FLUTTER-01
 **Trigger**: Q1 = Flutter | **Inject into**: `{{ tech_stack_rules }}`
 
-- Flutter SDK stable channel. `pubspec.yaml` locks dependency versions with caret constraints.
-- Dart analysis: `flutter analyze` must pass with zero errors in CI. Use `dart fix --apply` for auto-fixes.
-- Widget tree: prefer composition over inheritance. Forbid creating custom widget subclasses when composition works.
-- `const` constructors everywhere possible (improves rebuild performance). CI should warn on missing `const`.
-- StatefulWidget only when state is needed. Default to StatelessWidget.
+- Use the project's selected supported Flutter/Dart release and preserve its lockfile/update policy.
+- Run the configured Dart/Flutter analysis without silently suppressing new findings.
+- Prefer widget composition and use immutable/const construction where behavior and the supported SDK allow it.
+- State ownership follows the selected architecture and state-management decision rather than a platform default.
 
 ### D-FLUTTER-02
 **Trigger**: Q1 = Flutter | **Inject into**: `{{ tech_stack_rules }}`
 
-- Project structure: `lib/features/<domain>/` with `screens/`, `widgets/`, `models/`, `services/`.
-- Assets declared in `pubspec.yaml` under `flutter: assets:`. Forbid hardcoded asset paths in code (use an `Assets` class or code-gen).
-- Use `flutter_lints` or `very_good_analysis` for lint rules. Forbid disabling lint rules without a comment explaining why.
-- Platform channels: isolate in a single `platform/` service layer. Forbid scattering `MethodChannel` calls across widgets.
+- Organize Flutter code through the selected architecture; do not inject one directory taxonomy solely from the platform choice.
+- Declare assets through Flutter's supported project mechanism and centralize identifiers when the project selects generation or a wrapper.
+- Preserve the existing lint selection unless a dependency/config change is separately authorized.
+- Isolate platform channels behind explicit adapters rather than calling them throughout UI code.
 
 ### D-RN-01
 **Trigger**: Q1 = React Native | **Inject into**: `{{ tech_stack_rules }}`
 
-- React Native with TypeScript strict mode. Forbid `any` in new code.
-- Use Hermes JS engine (default in RN 0.70+). Test with Hermes enabled.
-- Platform-specific code: use `Platform.OS` checks or `.ios.ts` / `.android.ts` file extensions. Forbid platform-specific imports leaking into shared code.
-- Metro bundler config: commit `metro.config.js`. Custom resolvers documented.
+- Preserve the project's selected React Native release, language/type-checking mode, JavaScript engine, and lockfile policy.
+- Keep platform-specific behavior behind explicit adapters, platform files, or narrow capability checks.
+- Change Metro or native build configuration only under the selected AI configuration/dependency permissions and document custom resolution behavior.
 
 ### D-RN-02
 **Trigger**: Q1 = React Native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Project structure: `src/features/<domain>/` with `screens/`, `components/`, `hooks/`, `api/`.
-- Native modules: wrap in a thin TypeScript adapter. Forbid using native module APIs directly in screens.
-- Use `react-native-mmkv` for fast KV storage over AsyncStorage for performance-critical data.
+- Organize React Native code through the selected architecture rather than a platform-owned folder mandate.
+- Wrap native modules behind a typed shared boundary and keep direct native calls out of screen orchestration.
+- Use only the persistence technology selected by Q8; React Native selection does not implicitly add MMKV or replace an existing store.
 
 ### D-IOS-01
 **Trigger**: Q1 = iOS native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Swift 5.9+. Use Swift Concurrency (`async/await`) for all async work. Forbid completion-handler-based APIs for new code.
-- Swift Package Manager for dependencies. Forbid Carthage. CocoaPods allowed only for legacy deps without SPM support.
-- All public API must have documentation comments (`///`). CI validates with `swift-docc-plugin`.
-- `swiftlint` must pass with zero errors. Config committed to repo root.
+- Use the Swift/Xcode toolchain compatible with the resolved minimum OS and existing project.
+- Prefer structured Swift concurrency for new owned async boundaries while adapting required callback APIs safely.
+- Preserve the selected dependency manager and lint/documentation tooling unless a migration or dependency/config change is authorized.
+- Public shared contracts document behavior and availability according to repository conventions.
 
 ### D-IOS-02
 **Trigger**: Q1 = iOS native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Xcode project settings managed via `.xcconfig` files. Forbid hardcoding build settings in the project file.
-- Version and build number managed by CI. Forbid manual increment.
-- App delegate/scene delegate minimal. Use feature-based app initialization.
+- Keep build settings, signing, and version ownership consistent with the selected repository/distribution workflow; adopting `.xcconfig` or CI versioning is a separate migration decision.
+- Keep application lifecycle entrypoints focused on platform lifecycle and composition responsibilities.
 
 ### D-ANDROID-01
 **Trigger**: Q1 = Android native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Kotlin 2.0+. Use Kotlin Coroutines + Flow for async. Forbid raw `Thread` / `AsyncTask` (deprecated).
-- Gradle Version Catalog (`libs.versions.toml`) for dependency management. Forbid declaring versions directly in module `build.gradle`.
-- `detekt` must pass with zero errors. Config committed to repo root.
-- Min SDK, target SDK, compile SDK declared in a single `config.gradle` or convention plugin.
+- Use the Kotlin/Android toolchain compatible with the resolved minimum/target APIs and existing project.
+- Prefer structured coroutines for new owned async work and avoid deprecated thread/task APIs.
+- Preserve the selected Gradle dependency and lint/configuration model unless a migration or config change is authorized.
+- Keep SDK declarations consistent across modules through the project's existing authoritative configuration boundary.
 
 ### D-ANDROID-02
 **Trigger**: Q1 = Android native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Project structure by feature: `app/src/main/java/<package>/<feature>/` with `ui/`, `data/`, `domain/`.
-- Dependency injection via Hilt (recommended) or Koin. Forbid manual DI / service locator in application code.
-- ProGuard/R8 rules committed. Add rules for each reflection-using library.
+- Organize Android code through the selected architecture rather than a platform-owned folder taxonomy.
+- Use the dependency-injection approach already selected by the project; Android choice alone does not add Hilt or Koin.
+- Keep release shrinker/obfuscation rules synchronized with libraries that require reflection metadata when shrinking is enabled.
 
 ### D-BOTH-NATIVE-01
 **Trigger**: Q1 = Both native | **Inject into**: `{{ tech_stack_rules }}`
 
-- Dual native codebases (Swift + Kotlin). iOS rules apply to the Swift codebase. Android rules apply to the Kotlin codebase.
-- Shared business logic must be documented in a shared spec — no code-level sharing between the two platforms.
-- Each platform follows its own native conventions independently.
-- Both platform-specific rule sets (D-IOS-* and D-ANDROID-*) apply to their respective codebases.
+- Maintain distinct `ios` and `android` decision profiles. Apply Swift/iOS blocks only to iOS and Kotlin/Android blocks only to Android.
+- Keep shared product contracts and behavior documented. Code-level sharing is neither required nor forbidden unless the user separately confirms a supported sharing boundary.
+- Differences between profile decisions are intentional output, not drift to be normalized away.
 
 ### D-OS-LATEST-1-01
 **Trigger**: Q2 = Latest - 1 | **Inject into**: `{{ tech_stack_rules }}`
 
-- Target API level: latest stable - 1. minSdk = latest - 3 (or latest - 2 for platforms with faster adoption).
-- Forbid using APIs introduced in the latest OS version without `@available` / `@RequiresApi` guards.
-- Deprecated APIs in target version must be migrated within one release cycle.
+- Resolve concrete minimum OS/API versions from current stable releases for each active profile and record the resolution basis.
+- Guard APIs newer than that profile's minimum and provide a compatible fallback or explicit capability limitation.
+- Prioritize deprecated API migration by removal timeline and product risk rather than a universal one-release deadline.
 
 ### D-OS-LATEST-2-01
 **Trigger**: Q2 = Latest - 2 | **Inject into**: `{{ tech_stack_rules }}`
 
-- Target API level: latest stable - 2. Wider compatibility, more devices covered.
-- `@available(iOS 16, *)` / `@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)` for latest APIs.
-- Test on oldest supported OS version as part of CI or manual QA checklist.
+- Resolve and record the concrete minimum for each active profile from latest stable minus two.
+- Guard newer APIs with the active platform's availability mechanism; do not hardcode stale release constants from this reference.
+- Include the oldest supported OS in the selected automated device/simulator verification matrix, or report the unavailable environment as a release-evidence gap.
 
 ### D-OS-LATEST-3-01
 **Trigger**: Q2 = Latest - 3 | **Inject into**: `{{ tech_stack_rules }}`
 
-- Wide compatibility mode. Must test on oldest supported OS version for every release.
-- More `@available` checks needed. Document which features degrade gracefully on older OS versions.
+- Resolve and record the concrete minimum for each active profile from latest stable minus three.
+- Include the oldest supported OS in release verification and document capability fallbacks for features unavailable there.
 
 ### D-MVVM-01
 **Trigger**: Q3 = MVVM | **Inject into**: `{{ arch_rules }}`
@@ -268,11 +269,11 @@ Resolve each selected option or custom reply into the complete semantic value sh
 - Design tokens in `src/theme/tokens.ts`. All components reference tokens via `useTheme()` or import.
 
 ### D-NATIVEWIND-01
-**Trigger**: Q4 = Tamagui / NativeWind | **Inject into**: `{{ ui_rules }}`
+**Trigger**: Q4 = Tamagui or Q4 = NativeWind | **Inject into**: `{{ ui_rules }}`
 
-- Use Tamagui or NativeWind as the UI foundation. Forbid mixing with raw StyleSheet.
-- Design tokens in `tamagui.config.ts` or `tailwind.config.js`. Theme centralized.
-- Optimizing compiler (Tamagui) or Tailwind JIT must be configured for production builds.
+- Resolve whether the selected option means Tamagui or NativeWind for this profile; never emit both configurations from one answer.
+- Use the selected library's theme/token boundary consistently and define the allowed interop boundary with React Native core styles.
+- Configure only build integration required by the selected library and supported project version.
 
 ### D-SWIFTUI-01
 **Trigger**: Q4 = SwiftUI | **Inject into**: `{{ ui_rules }}`
@@ -307,12 +308,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-DEEP-LINK-01
 **Trigger**: Q5 = Platform-default | **Inject into**: `{{ navigation_rules }}`
 
-- Navigation uses platform defaults with deep linking support:
-  - Flutter: GoRouter with `ShellRoute` for tab-based navigation.
-  - React Native: React Navigation with linking config.
-  - iOS: NavigationStack with `navigationDestination(for:)`.
-  - Android: Compose Navigation with NavDeepLink.
-- Every screen must have a unique route path. Forbid ambiguous routes.
+- Use the active profile's selected/default navigation mechanism with an explicit deep-link mapping; do not inject other platforms' libraries.
+- Validate external routes, map each supported route unambiguously, and define authenticated/deferred navigation behavior.
+- A specific routing dependency is added only when compatible with the platform and dependency permission decisions.
 
 ### D-URL-ROUTING-01
 **Trigger**: Q5 = URL-based routing | **Inject into**: `{{ navigation_rules }}`
@@ -324,9 +322,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-STACK-NAV-01
 **Trigger**: Q5 = Simple stack | **Inject into**: `{{ navigation_rules }}`
 
-- Simple push/pop stack navigation. No deep linking.
-- Forbid programmatic navigation to arbitrary stack positions (push-only from current top).
-- Suitable for prototype/simple apps. Plan deep linking migration path for production.
+- Use a simple stack with no deep-link capability, as selected.
+- Keep push/pop/back behavior deterministic and document restoration expectations.
+- Do not inject a deep-link migration merely because the app may later be distributed; revisit Q5 only when a product flow requires it.
 
 ### D-RIVERPOD-01
 **Trigger**: Q6 = Riverpod | **Inject into**: `{{ state_rules }}`
@@ -361,17 +359,16 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-ZUSTAND-MOBILE-01
 **Trigger**: Q6 = Zustand | **Inject into**: `{{ state_rules }}`
 
-- Zustand stores: one per domain. Forbid massive global store.
-- Store selectors prevent unnecessary re-renders: `useStore(state => state.specificField)`.
-- Async actions in store via `set`. Forbid calling `set` outside of store actions.
-- Persist middleware for session state: `zustand/middleware persist` with MMKV storage adapter.
+- Scope Zustand stores to owned domains and use selectors to avoid unrelated rerenders.
+- Keep mutations behind store actions and make async side effects observable.
+- Persist only state classified as durable through the Q8-selected storage; Zustand selection does not authorize MMKV.
 
 ### D-REDUX-MOBILE-01
 **Trigger**: Q6 = Redux Toolkit | **Inject into**: `{{ state_rules }}`
 
-- Redux Toolkit with `createSlice` + `createAsyncThunk`.
-- Middleware: `redux-persist` with MMKV storage engine for session persistence.
-- Forbid dispatching actions directly from components — use typed hooks (`useAppDispatch`, `useAppSelector`).
+- Use Redux Toolkit's supported slice and async/effect mechanisms and typed access hooks.
+- Persist only selected durable state through the Q8 storage decision; Redux selection does not add redux-persist or MMKV automatically.
+- Components dispatch user/domain events through the project's typed boundary.
 
 ### D-SWIFT-STATE-01
 **Trigger**: Q6 = @Observable / @State | **Inject into**: `{{ state_rules }}`
@@ -403,17 +400,16 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-DIO-01
 **Trigger**: Q7 = Dio | **Inject into**: `{{ networking_rules }}`
 
-- Dio instance singleton configured with base URL, interceptors, timeout (connect: 10s, receive: 30s).
-- Interceptors: auth token injection, refresh token retry, logging (debug only).
-- Response typed via `dio.withJson<T>()` or manual `fromJson` factories. Forbid `dynamic` response types.
-- Certificate pinning via `HttpClientAdapter` with custom `SecurityContext` for release builds.
+- Centralize the Dio client boundary and set timeout/cancellation/retry behavior from endpoint and product requirements.
+- Add authentication, refresh, logging, or certificate pinning interceptors only when separately required by the API and threat model.
+- Decode responses through typed/validated models and keep debug network logging free of secrets.
 
 ### D-AXIOS-MOBILE-01
 **Trigger**: Q7 = Axios | **Inject into**: `{{ networking_rules }}`
 
-- Axios instance with base URL, interceptors, timeout (30s default).
-- Request interceptor: attach auth token. Response interceptor: handle 401 refresh, global error normalization.
-- API functions in `src/api/` return typed Promise. Forbid `axios.get<any>(...)`.
+- Centralize the Axios client boundary and configure timeout/cancellation/retry behavior from endpoint requirements.
+- Add authentication/refresh interceptors only when the API contract selected those flows; always normalize errors without exposing secrets.
+- API functions return typed, runtime-validated results at untrusted boundaries.
 
 ### D-URLSESSION-01
 **Trigger**: Q7 = URLSession + async/await | **Inject into**: `{{ networking_rules }}`
@@ -426,18 +422,16 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-RETROFIT-01
 **Trigger**: Q7 = Retrofit + OkHttp | **Inject into**: `{{ networking_rules }}`
 
-- Retrofit interfaces with `suspend` functions returning `Response<T>` or `Result<T>`.
-- OkHttp client singleton with interceptors: auth token, logging (debug), caching.
-- Moshi or kotlinx.serialization for JSON. Forbid Gson (unmaintained, slower).
-- Timeout: connect 10s, read 30s, write 30s.
+- Define Retrofit interfaces with suspend/streaming behavior appropriate to each endpoint and a typed result boundary.
+- Configure OkHttp authentication, logging, cache, timeout, and retry behavior only from confirmed API/product needs.
+- Use the serialization mechanism already selected or detected by the project unless a dependency migration is authorized.
 
 ### D-DRIFT-01
 **Trigger**: Q8 = Drift | **Inject into**: `{{ persistence_rules }}`
 
-- Drift (SQLite, type-safe). Table definitions via Dart classes extending `Table`.
-- DAO (Data Access Object) classes for query logic. Forbid raw SQL in widgets/services.
-- Migration strategy: `onUpgrade` with versioned migration callbacks. Test migrations.
-- Database singleton provided via Riverpod/Provider. Forbid opening database directly.
+- Use Drift's typed schema/query and migration mechanisms, keeping persistence calls behind the selected architecture boundary.
+- Version and test model migrations from supported prior versions.
+- Provide the database through the Q6-selected composition/state mechanism; Drift selection does not authorize Riverpod or Provider.
 
 ### D-HIVE-01
 **Trigger**: Q8 = Hive | **Inject into**: `{{ persistence_rules }}`
@@ -493,10 +487,9 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-BG-TASK-01
 **Trigger**: Q10 = Yes, needed | **Inject into**: `{{ platform_features_rules }}`
 
-- Flutter: `workmanager` plugin. React Native: `react-native-background-fetch`.
-- iOS: BGAppRefreshTask (short) or BGProcessingTask (long). Android: WorkManager with constraints (network, charging).
-- Background task ID registered in Info.plist (iOS) and AndroidManifest.xml.
-- Forbid running UI updates from background tasks. Persist results, update UI on next foreground.
+- Select only the active profile's supported background mechanism and add a cross-platform plugin only when dependency permission allows it.
+- Register only required platform capabilities/identifiers and state scheduling, cancellation, retry, duplicate-work, and termination behavior.
+- Background workers do not mutate UI directly; persist or publish results through the selected state/data boundary.
 
 ### D-PERM-ASK-ON-USE-01
 **Trigger**: Q11 = Ask-on-use | **Inject into**: `{{ platform_features_rules }}`
@@ -514,37 +507,36 @@ Resolve each selected option or custom reply into the complete semantic value sh
 ### D-MOBILE-TEST-01
 **Trigger**: Q12 = All tiers | **Inject into**: `{{ test_rules }}`
 
-- Three-tier testing: unit (ViewModel/Bloc/UseCase), widget/component (individual UI), integration (critical flows).
-- Unit test coverage: ViewModel/Bloc layer ≥ 80%. Widget/component tests for shared components ≥ 60%.
-- Integration tests cover: login, registration, core CRUD, payment (if applicable).
+- Include unit, widget/component, and integration behavior for the active profile and selected architecture.
+- Derive test subjects from actual product flows and boundaries; do not invent login, payment, CRUD, or numeric coverage thresholds.
+- Use the Q13/Q14 framework selected for each platform profile.
 
 ### D-MOBILE-TEST-02
 **Trigger**: Q12 = Unit + Widget | **Inject into**: `{{ test_rules }}`
 
-- Unit tests + widget/component tests. No integration/E2E tests.
-- Coverage: ViewModel/Bloc layer ≥ 80%. Shared widgets ≥ 60%.
-- Recommend adding integration tests for critical flows before production.
+- Require the selected unit and widget/component tiers through each active profile's Q13 framework.
+- Do not inject numeric coverage or mandatory integration tests that Q12 did not select; record the accepted integration-evidence gap.
 
 ### D-MOBILE-TEST-03
 **Trigger**: Q12 = Critical path only | **Inject into**: `{{ test_rules }}`
 
-- Integration tests for critical flows only (login, core CRUD, payment).
-- No coverage thresholds enforced project-wide. Critical paths must have ≥ 1 test each.
+- Require integration tests only for product-defined critical flows through each active profile's Q14 framework.
+- Do not invent generic login, CRUD, or payment flows; map tests to the confirmed app brief and acceptance criteria.
 
 ### D-APP-STORE-01
 **Trigger**: Q15 = App Store + Google Play | **Inject into**: `{{ distribution_rules }}`
 
-- iOS: archive via Xcode Cloud or Fastlane. Upload to App Store Connect via `deliver` or Xcode.
-- Android: signed app bundle via `./gradlew bundleRelease`. Upload to Google Play Console.
-- Staged rollout default: 10% → 50% → 100% over 48 hours. Monitor crash-free rate at each stage.
-- Code signing: iOS uses automatic signing (Xcode managed). Android uses `signingConfigs` in Gradle with keystore in CI secrets.
+- Apply public-store build, signing, submission, and rollout rules only to active platform profiles: App Store Connect/TestFlight for iOS and Google Play testing/release tracks for Android.
+- A single-platform project must not receive the other platform's release requirements.
+- Choose staged rollout percentages and observation windows from product risk and store capability; record the selected rollout rather than imposing one universal schedule.
+- Keep signing credentials in the approved CI or managed signing boundary, never in source control.
 
 ### D-ENTERPRISE-DIST-01
 **Trigger**: Q15 = Enterprise distribution | **Inject into**: `{{ distribution_rules }}`
 
-- iOS: enterprise certificate + provisioning profile. OTA distribution via HTTPS server with manifest.plist.
-- Android: signed APK distributed via private channel or MDM.
-- No App Store Review process. Internal compliance review replaces it. Document compliance criteria.
+- Apply enterprise/private distribution only to active profiles and through the organization's selected MDM/private-store capability.
+- Keep signing material outside source control and document installation, update, revocation, device eligibility, and compliance ownership.
+- Do not emit iOS certificate/manifest rules for Android-only projects or Android package rules for iOS-only projects.
 
 ### D-PERF-60FPS-01
 **Trigger**: Q16 = 60fps | **Inject into**: `{{ performance_rules }}`
@@ -644,7 +636,7 @@ Resolve each selected option or custom reply into the complete semantic value sh
 | `{{ ai_dependency_rule }}` | D-AI-DEP-STRICT/ANNOUNCE-MOBILE | Derivation |
 | `{{ ai_breaking_change_rule }}` | D-AI-BREAK-STRICT-MOBILE | Derivation |
 | `{{ ai_platform_rule }}` | D-AI-PLATFORM-STRICT | Derivation |
-| `{{ FIXED_RULES_* }}` | fixed-rules.md (14 chapters) | Fixed injection |
+| `{{ FIXED_RULES_* }}` | fixed-rules.md (13 invariant blocks) | Invariant injection |
 | `{{ deny_list_summary }}` | Phase 4 auto-extract | Auto-generated |
 | `{{ recommended_libs }}` | Phase 4 platform+tools recommendation | Auto-generated |