prizmkit 1.1.153 → 1.1.155

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

@@ -1,290 +1,117 @@
-# Fixed Rules — Complete Mobile Fixed Rules
+# Mobile Invariant Rules
 
-> This file is read by the `mobile-rules` skill in Phase 1 and injected directly into `mobile-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 across Flutter, React Native, iOS, Android, and dual-native projects without forcing one platform's conventions onto another.
 
-## F1. Project Structure
+**Selected-decision boundary:** platform, minimum OS support, architecture, UI framework, navigation/deep linking, state management, networking library, persistence, push, background work, permissions timing, testing depth, distribution, performance target, accessibility target, dependency permission, caller analysis, and platform flexibility belong to confirmed decisions and derivation rules.
 
-### F1.1 Platform Directory Conventions
+## I1. Platform Ownership
 
-- **Rule**: Project root must clearly separate platform-specific code from shared code:
-  - Flutter: `lib/` (Dart), `test/`, `ios/`, `android/`
-  - React Native: `src/`, `ios/`, `android/`, `app.json`
-  - iOS: `AppName/` (Swift sources), `AppNameTests/`, `AppName.xcodeproj`
-  - Android: `app/src/main/java/`, `app/src/test/`, `app/build.gradle`
-- **Rule**: Shared cross-platform code goes in `shared/` or `core/` directory.
-- **Forbidden**: Mixing platform-specific and cross-platform code in the same directory.
-- **RATIONALE**: Clean platform separation is the first defense against accidental platform coupling.
+- Separate shared behavior from platform-specific adapters using the selected project structure.
+- Apply only the conventions of the active platform profile; dual-native projects maintain distinct iOS and Android profiles.
+- Public shared contracts state platform capability differences rather than hiding them behind accidental conditionals.
 
-### F1.2 Module Organization
+Inject into `{{ FIXED_RULES_STRUCTURE }}`.
 
-- **Rule**: Organize source by feature/module, not by technical layer (e.g., `features/auth/`, not `models/` + `views/` + `controllers/`).
-- **Rule**: Within each feature directory, enforce the chosen architecture pattern (MVVM/Clean Architecture/MVI).
-- **Forbidden**: Circular dependencies between feature modules.
-- **RATIONALE**: Feature-based organization keeps related code together and limits blast radius of changes.
+## I2. UI Integrity
 
-### F1.3 Naming Conventions
+- Components have explicit input, output, state, and sizing behavior.
+- Use the selected design system or platform theme consistently; document unavoidable platform-specific deviations.
+- Adapt safe areas, text scaling, and supported orientations according to the confirmed product and platform profiles.
 
-- **Flutter**: File names snake_case (`user_profile_screen.dart`). Widget classes PascalCase.
-- **React Native**: Component files PascalCase (`UserProfileScreen.tsx`). Hooks `useXxx.ts`.
-- **iOS/Swift**: Files PascalCase (`UserProfileView.swift`). Protocols start with describable verb.
-- **Android/Kotlin**: Files PascalCase (`UserProfileScreen.kt`). Layout XML snake_case.
-- **RATIONALE**: Consistent naming lets AI and developers find files by convention alone.
+Inject into `{{ FIXED_RULES_UI }}`.
 
----
+## I3. Navigation Integrity
 
-## F2. UI Development
+- Back behavior, restoration, and route ownership are deterministic for the selected navigation strategy.
+- Validate external navigation input before opening a screen or resource.
+- Deep-link requirements apply only when deep linking is selected; simple-stack projects render an explicit no-deep-link decision.
 
-### F2.1 Component/Widget Principles
+Inject into `{{ FIXED_RULES_NAVIGATION }}`.
 
-- **Rule**: UI components must be single-responsibility. One component does one visual unit.
-- **Rule**: Pass data down, emit events up. Forbid bidirectional data binding between parent and child.
-- **Rule**: Every UI component must specify explicit sizing behavior (intrinsic, expanded, fixed). Forbid relying on implicit defaults.
-- **Forbidden**: Hardcoding colors, font sizes, or spacing values in UI code. Use design tokens or theme.
-- **RATIONALE**: UI is the most change-prone layer. Single-responsibility components make changes localized.
+## I4. State Integrity
 
-### F2.2 Platform UI Conventions
+- Separate ephemeral UI state from longer-lived business/session state.
+- State ownership and mutation remain observable; avoid uncontrolled global mutable state.
+- Persistence across process death or configuration change is required only for state the product contract marks durable.
 
-- **Rule**: Follow platform HIG (Human Interface Guidelines) for navigation patterns:
-  - iOS: tab bar at bottom, back swipe gesture, navigation bar with large titles
-  - Android: navigation drawer or bottom nav, back button (system), app bar
-- **Rule**: Touch targets must be ≥ 44pt (iOS) / 48dp (Android). Smaller targets need padding.
-- **Forbidden**: Copying UI patterns from one platform to another without adapting to HIG.
-- **RATIONALE**: Users expect platform-native behavior. Violating HIG causes rejection from App Store review.
+Inject into `{{ FIXED_RULES_STATE }}`.
 
-### F2.3 Adaptive Layout
+## I5. Network Safety
 
-- **Rule**: UI must adapt to safe areas (notch, home indicator, camera cutout).
-- **Rule**: Support both portrait and landscape on iPad/tablet. Phone may lock to portrait.
-- **Rule**: Text must support Dynamic Type / font scaling (1x–3x). Test with largest accessibility text size.
-- **Forbidden**: Using fixed pixel dimensions for text containers.
-- **RATIONALE**: Device fragmentation is orders of magnitude worse on mobile than on web.
+- Network work never blocks the UI thread and defines timeout, cancellation, error, and retry/idempotency behavior appropriate to the operation.
+- Protect credentials and personal data in transit using current platform transport security.
+- Certificate pinning, offline queues, and cache policies are opt-in risk decisions, not unconditional requirements.
 
----
+Inject into `{{ FIXED_RULES_NETWORKING }}`.
 
-## F3. Navigation & Deep Linking
+## I6. Persistence Safety
 
-### F3.1 Navigation Patterns
+- Store each data class in a mechanism appropriate to its sensitivity, structure, and lifecycle.
+- Keep secrets and tokens out of plaintext storage.
+- Version persistent model changes and test compatibility with supported prior app versions when migration is required.
 
-- **Rule**: Navigation flow must be predictable. Back button/gesture always goes to the previous screen.
-- **Rule**: Deep links must resolve to a specific screen regardless of app launch state (cold start, background, foreground).
-- **Rule**: Navigation state must survive process death (save/restore navigation stack).
-- **Forbidden**: Modifying the navigation stack during transition animations.
-- **RATIONALE**: Broken navigation is the #1 cause of mobile app user frustration and 1-star reviews.
+Inject into `{{ FIXED_RULES_PERSISTENCE }}`.
 
-### F3.2 Deep Linking
+## I7. Platform Feature Safety
 
-- **Rule**: All deep link routes must be validated before navigation. Forbid navigating to arbitrary URLs.
-- **Rule**: Universal Links (iOS) / App Links (Android) must be configured with the correct `apple-app-site-association` / `assetlinks.json`.
-- **Rule**: Deep link handling must work with both custom scheme (`myapp://`) and HTTPS (`https://myapp.com/`).
-- **RATIONALE**: Deep links are an attack surface (open redirect). Unvalidated deep links can expose sensitive screens.
+- Check capability and permission state before invoking a protected platform feature.
+- Handle denial, unavailability, process termination, and token/registration changes without crashing or silently losing owned work.
+- Push and background requirements are injected only when selected; otherwise render them as not applicable.
 
----
+Inject into `{{ FIXED_RULES_PLATFORM_FEATURES }}`.
 
-## F4. State Management Principles
+## I8. Resource Safety
 
-- **Rule**: UI state must be separated from business state. UI state belongs in the View/Widget. Business state belongs in ViewModel/Bloc/Store.
-- **Rule**: State changes must be observable and traceable. Forbid silently mutating shared state.
-- **Rule**: Long-lived state (user session, cached data) must survive configuration changes / process death.
-- **Forbidden**: Using global mutable variables as state containers.
-- **RATIONALE**: Uncontrolled shared mutable state is the root of all mobile app heisenbugs — bugs that vanish when you try to reproduce them.
+- Keep expensive CPU, I/O, decoding, and datastore work off the UI thread.
+- Release listeners, observers, tasks, and retained UI owners at the platform lifecycle boundary.
+- Apply numeric frame, memory, and package-size budgets only from the selected performance target.
 
----
+Inject into `{{ FIXED_RULES_PERFORMANCE }}`.
 
-## F5. Networking
+## I9. Accessibility Baseline
 
-### F5.1 API Communication
+- Interactive elements have accessible names and meet the active platform's minimum operability expectations.
+- Support system text scaling and do not convey meaning by color alone.
+- Apply stricter screen-reader, contrast, and audit requirements through the selected accessibility target.
 
-- **Rule**: All API calls must handle: success, network error, timeout, server error (4xx/5xx), and empty response.
-- **Rule**: Network requests must be cancellable (dispose on screen exit to prevent memory leaks and stale UI updates).
-- **Rule**: Sensitive data in transit must use HTTPS with certificate pinning for production builds.
-- **Forbidden**: Making network calls on the main/UI thread.
-- **RATIONALE**: Mobile networks are unreliable by nature. Every network call needs full error handling or it will crash your app.
+Inject into `{{ FIXED_RULES_A11Y }}`.
 
-### F5.2 Offline & Caching
+## I10. Mobile Security
 
-- **Rule**: Critical flows must work offline or show graceful degradation (not a white screen).
-- **Rule**: Network responses should be cached with TTL. Stale cache is better than no data.
-- **Rule**: Offline mutations must be queued and synced when connectivity returns, with conflict resolution.
-- **RATIONALE**: Airplane mode, tunnels, elevators — mobile apps must assume connectivity is intermittent.
+- Treat the distributed application binary and local device as attacker-accessible.
+- Do not embed privileged server secrets or disable platform transport protections to bypass an error.
+- Protect sensitive local content and redact release logs according to the product's data classification.
+- Platform hardening features are enabled according to threat model, not universally.
 
----
+Inject into `{{ FIXED_RULES_SECURITY }}`.
 
-## F6. Data Persistence
+## I11. Verification Integrity
 
-### F6.1 Local Storage
+- Follow the selected test depth and framework for each active platform profile.
+- Enabled tests are deterministic and isolate network, clock, device, and backend dependencies as required by the test contract.
+- A `not required yet` selection is recorded with accepted risk instead of contradicted by unconditional three-tier requirements.
 
-- **Rule**: Choose the right storage for the data type: structured → SQLite, KV → DataStore/MMKV/Hive, files → app sandbox, credentials → Keychain/Keystore.
-- **Rule**: Database migrations must be versioned and tested. Forbid destructive migrations (drop column/table) without a backup step.
-- **Forbidden**: Storing sensitive data (tokens, passwords, PII) in plaintext in any local storage.
-- **RATIONALE**: Local storage is not encrypted by default on all platforms. Assume the device can be compromised.
+Inject into `{{ FIXED_RULES_TEST }}`.
 
-### F6.2 Encryption
+## I12. Distribution Integrity
 
-- **Rule**: Authentication tokens must be stored in Keychain (iOS) / EncryptedSharedPreferences or Keystore (Android).
-- **Rule**: Local databases containing PII must use SQLCipher or platform-level encryption.
-- **Forbidden**: Hardcoding encryption keys in source code.
-- **RATIONALE**: The mobile device is a hostile environment — jailbroken/rooted devices can access app sandboxes.
+- Follow the selected distribution channel and its signing, review, rollout, and compliance requirements.
+- Do not inject public-store rules into enterprise-only or undecided distribution profiles.
+- Protect signing material outside source control and make release identity reproducible.
 
----
+Inject into `{{ FIXED_RULES_DISTRIBUTION }}`.
 
-## F7. Platform Features
+## I13. AI Change Safety
 
-### F7.1 Permissions
+- Read the current platform profile and target feature before editing.
+- Search for existing shared and platform-specific implementations before creating duplicates.
+- Keep changes within scope and report uncertainty about API availability or platform behavior.
+- Dependency, caller-analysis, and cross-platform flexibility permissions come only from selected decision blocks.
 
-- **Rule**: Request permissions at the time of use, not at app launch (except for critically required permissions with explanation).
-- **Rule**: Handle all permission outcomes: granted, denied, denied permanently ("Don't ask again").
-- **Rule**: When a permission is permanently denied, guide the user to system Settings with a clear explanation of why it's needed.
-- **Forbidden**: Crashing or silently failing when a permission is denied.
-- **RATIONALE**: Permission rejection rates are high (30-50% for camera/mic). Crashing on denial is a guaranteed crash report.
+Inject into `{{ FIXED_RULES_AI_BASE }}`.
 
-### F7.2 Background Tasks
+## Injection Contract
 
-- **Rule**: Background work must use the platform's recommended API:
-  - iOS: BGTaskScheduler (short, scheduled) or BGAppRefreshTask
-  - Android: WorkManager (deferrable) or Foreground Service (user-visible)
-- **Rule**: Background tasks must be battery-efficient. Forbid polling every few seconds in the background.
-- **Rule**: Background task results must be persisted before task completion (system may kill the process).
-- **RATIONALE**: Mobile OSes aggressively kill background processes. Using the wrong background API means your task never runs.
-
-### F7.3 Push Notifications
-
-- **Rule**: Notification content must be localized. Forbid hardcoding notification text in English only.
-- **Rule**: Notification tap must navigate to the relevant screen, not just open the app.
-- **Rule**: Handle FCM/APNs token refresh. Stale tokens cause silent notification delivery failure.
-- **Forbidden**: Sending sensitive data (passwords, PII) in notification payloads.
-- **RATIONALE**: Notifications are the primary re-engagement channel. Broken deep links from notifications mean lost users.
-
----
-
-## F8. Performance
-
-### F8.1 Main Thread
-
-- **Rule**: UI thread (main thread) must stay at 60fps (16ms/frame) or 120fps (8ms/frame). Any work > 1ms offloads to background.
-- **Rule**: JSON parsing, image decoding, database queries must run off the main thread.
-- **Forbidden**: Synchronous I/O on the main thread.
-- **RATIONALE**: Jank (dropped frames) is immediately visible to users. A single 100ms main-thread block drops 6 frames at 60fps.
-
-### F8.2 Memory
-
-- **Rule**: Avoid memory leaks: unregister listeners/observers in dispose/deinit/onDestroy.
-- **Rule**: Image memory: load scaled images (not full resolution into a thumbnail). Use image caching libraries.
-- **Rule**: Monitor memory warnings. Release cached data when the system sends a memory warning.
-- **Forbidden**: Holding references to Activity/Fragment/ViewController after they're destroyed.
-- **RATIONALE**: Mobile OSes kill apps that exceed memory limits. Memory leaks accumulate and eventually cause OOM crashes.
-
-### F8.3 App Size
-
-- **Rule**: App download size target < 100MB (cellular download limit for many regions).
-- **Rule**: Use App Bundles (Android) / App Thinning (iOS) for platform-optimized delivery.
-- **Rule**: Large assets (videos, models) should be downloaded on-demand after install, not bundled.
-- **RATIONALE**: App size directly impacts install conversion. Every 10MB above 100MB loses ~1% of potential installs.
-
----
-
-## F9. Accessibility
-
-- **Rule**: All interactive elements must have accessibility labels (contentDescription / accessibilityLabel).
-- **Rule**: Decorative images must be marked as not important for accessibility.
-- **Rule**: Color must not be the sole means of conveying information (pair with icon or text).
-- **Rule**: Minimum contrast ratio: 4.5:1 for normal text, 3:1 for large text (≥18pt bold or ≥24pt).
-- **Rule**: Support system font scaling up to 2x without layout breaking or text truncation.
-- **RATIONALE**: 15% of the world's population has some form of disability. Accessibility is not optional — it's also increasingly an App Store review requirement.
-
----
-
-## F10. Security
-
-### F10.1 App Hardening
-
-- **Rule**: Release builds must enable code minification/obfuscation (ProGuard/R8 for Android, strip symbols for iOS).
-- **Rule**: Jailbreak/root detection recommended for financial, healthcare, or enterprise apps.
-- **Rule**: Screenshot/screen recording prevention for sensitive screens (banking, health records).
-- **Forbidden**: Leaving debug logs, debug menus, or development endpoints in release builds.
-- **RATIONALE**: A released app is a binary that anyone can decompile. Defense in depth is the only strategy.
-
-### F10.2 Data Protection
-
-- **Rule**: App sandbox file protection: `NSFileProtectionComplete` (iOS) / device-encrypted storage (Android).
-- **Rule**: API keys must not be stored in the app bundle. Use server-side proxy or secure enclave.
-- **Rule**: User sessions must expire. Token refresh must require re-authentication for sensitive operations.
-- **RATIONALE**: The app binary is distributed to attacker-controlled devices. Assume everything in the binary is public knowledge.
-
----
-
-## F11. Testing
-
-- **Rule**: Testing has three tiers:
-  - Unit tests: ViewModels/Blocs/UseCases/Repositories (fast, no UI)
-  - Widget/Component tests: individual UI components in isolation (medium speed, fake dependencies)
-  - Integration/E2E tests: critical user flows through real screens (slow, real or staged backend)
-- **Rule**: Tests must be deterministic. Forbid relying on real network calls, real time, or random values without seeding.
-- **Rule**: Golden/image snapshot tests must use the same OS version and device configuration for consistency.
-- **RATIONALE**: Mobile testing is harder than backend testing because it spans UI, platform APIs, and network. Clear tiers prevent confusion about what to test where.
-
----
-
-## F12. App Distribution
-
-- **Rule**: Version code/number must be incremented for every build submitted to store.
-- **Rule**: Staged rollout: 10% → 50% → 100% over 48 hours. Monitor crash rate at each stage.
-- **Rule**: Release notes must be localized for all supported languages.
-- **Rule**: Keep a version history document: what changed, why, and the minimal OS version bump if any.
-- **RATIONALE**: A bad release can't be undone instantly (store rollback takes hours). Staged rollout is the cheapest insurance.
-
----
-
-## F13. AI Vibecoding Baseline Constraints (project-agnostic, always active)
-
-### F13.1 Search First
-- **Rule**: Before creating a new widget/component/screen, AI must search existing code for similar implementations.
-- **Rule**: Before adding a new dependency, AI must check if an existing dependency already covers that use case.
-
-### F13.2 Platform Awareness
-- **Rule**: AI must know which platform it's writing code for. iOS patterns in Android code (or vice versa) must be flagged explicitly.
-- **Rule**: AI-generated code that uses platform-specific APIs must include the API level/iOS version availability annotation.
-
-### F13.3 Dependency Control
-- **Rule**: AI must not modify `pubspec.yaml` / `package.json` / `Podfile` / `build.gradle` on its own.
-- **Rule**: If a new dependency is needed, AI must list: package name, version, reason, alternative comparison.
-
-### F13.4 Breaking Changes
-- **Rule**: Before modifying a shared widget/component/utility, AI must list all callers and assess platform impact.
-- **Rule**: Changing navigation routes or deep link schemes requires assessing all entry points.
-
-### F13.5 Context Honesty
-- **Rule**: When uncertain about a platform API availability, behavior, or deprecation status, AI must explicitly say "I'm not sure" and suggest the developer verify against the platform documentation.
-
-### F13.6 Security
-- **Rule**: AI must not generate code that stores secrets in the app bundle, logs sensitive data, or disables ATS/SSL verification.
-
----
-
-## 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 Project Structure | `{{ FIXED_RULES_STRUCTURE }}` | §1 Project Structure |
-| F2 UI Development | `{{ FIXED_RULES_UI }}` | §2 UI Development |
-| F3 Navigation | `{{ FIXED_RULES_NAVIGATION }}` | §3 Navigation & Deep Linking |
-| F4 State Management | `{{ FIXED_RULES_STATE }}` | §4 State Management |
-| F5 Networking | `{{ FIXED_RULES_NETWORKING }}` | §5 Networking |
-| F6 Data Persistence | `{{ FIXED_RULES_PERSISTENCE }}` | §6 Data Persistence |
-| F7 Platform Features | `{{ FIXED_RULES_PLATFORM_FEATURES }}` | §7 Platform Features |
-| F8 Performance | `{{ FIXED_RULES_PERFORMANCE }}` | §8 Performance |
-| F9 Accessibility | `{{ FIXED_RULES_A11Y }}` | §9 Accessibility |
-| F10 Security | `{{ FIXED_RULES_SECURITY }}` | §10 Security |
-| F11 Testing | `{{ FIXED_RULES_TEST }}` | §11 Testing |
-| F12 Distribution | `{{ FIXED_RULES_DISTRIBUTION }}` | §12 Distribution |
-| F13 AI Constraints | `{{ FIXED_RULES_AI_BASE }}` | §13 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. In dual-native mode, evaluate every derived rule against the iOS or Android profile it belongs to. If a rule cannot be assigned unambiguously, fail generation rather than applying it to both platforms.

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

@@ -11,14 +11,14 @@
 1. **Group order**: G1 → G2 → G3 → G4 → G5 → G6 → G7 → G8 → G9 → G10. 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 active platform profile
    - `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. `A,C` means multi-select (only for multi-select questions).
 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.
 
@@ -53,15 +53,15 @@ Total: 20 questions.
   - D) Android native (Kotlin)
   - E) Both native (Swift + Kotlin, separate codebases)
 - **Note**: Determines all subsequent framework, tooling, and platform-specific rule injections.
-- **Dual-native note**: If Q1=E (Both native): present Q4/Q6/Q7/Q8/Q13/Q14 for iOS first, then ask the user if they want to repeat for Android (or apply same choices).
+- **Dual-native contract**: If Q1=E, collect Q4/Q6/Q7/Q8/Q13/Q14 separately for iOS and Android. Store two named answer profiles and render both through `{{ platform_profiles }}`; never collapse one profile into scalar values or copy an option across platforms unless the user explicitly selects equivalent meanings for both.
 - **Maps to**: `{{ platform }}` + `{{ tech_stack_rules }}`
 
 ### Q2. Minimum OS Version
 - **Options**:
-  - A) Latest - 1 (iOS 17+ / Android 14+) **【Recommended: covers ~90% of active devices】**
-  - B) Latest - 2 (iOS 16+ / Android 13+)
-  - C) Latest - 3 (wider compatibility, more legacy handling)
-- **Note**: Determines API availability and deprecation handling rules.
+  - A) Latest stable major release minus 1 **【Recommended: balanced active-device coverage】**
+  - B) Latest stable major release minus 2
+  - C) Latest stable major release minus 3 (wider compatibility, more legacy handling)
+- **Note**: Resolve concrete iOS and Android versions from current stable releases when generating the file; record both the relative policy and resolved versions instead of preserving stale version examples in this question bank.
 - **Maps to**: `{{ min_os_version }}` + `{{ tech_stack_rules }}`
 
 ---
@@ -83,7 +83,7 @@ Total: 20 questions.
 
 ### Q4. UI Framework (varies by Q1)
 - **For Flutter**: A) Material Design 3 **【Recommended】** — B) Cupertino (iOS-style) — C) Adaptive (auto-switch by platform)
-- **For React Native**: A) React Native core components + StyleSheet **【Recommended】** — B) Tamagui / NativeWind — C) Custom design system
+- **For React Native**: A) React Native core components + StyleSheet **【Recommended】** — B) Tamagui — C) NativeWind — D) Custom design system
 - **For iOS**: A) SwiftUI **【Recommended: modern, declarative】** — B) UIKit (programmatic) — C) UIKit + Storyboards
 - **For Android**: A) Jetpack Compose **【Recommended: modern, declarative】** — B) XML + Material 3 — C) Hybrid (Compose + Views)
 - **Maps to**: `{{ ui_framework }}` + `{{ ui_rules }}`
@@ -131,16 +131,16 @@ Total: 20 questions.
 
 ### Q9. Push Notifications
 - **Options**:
-  - A) Yes, needed (remote push via FCM/APNs) **【Recommended: production apps】**
-  - B) Not required yet
-- **Note**: Determines notification channel configuration, token management, and foreground/background handling rules.
+  - A) Yes, required by a confirmed product flow (remote push through active platform services)
+  - B) Not required **【Recommended when no notification use case is established】**
+- **Note**: Determines channel configuration, token lifecycle, consent, and foreground/background handling. Quick mode must not add push infrastructure because an app is intended for production.
 - **Maps to**: `{{ push_notifications }}` + `{{ platform_features_rules }}`
 
 ### Q10. Background Tasks
 - **Options**:
-  - A) Yes, needed (data sync, file upload, periodic refresh) **【Recommended: data-heavy apps】**
-  - B) Not required
-- **Note**: Determines background execution constraints, battery optimization, and platform-specific background mode rules.
+  - A) Yes, required by a confirmed sync, transfer, processing, or refresh flow
+  - B) Not required **【Recommended when no background-owned work is established】**
+- **Note**: Determines background execution, retry, termination, battery, and platform-specific capability rules. Quick mode must not invent background work.
 - **Maps to**: `{{ background_tasks }}` + `{{ platform_features_rules }}`
 
 ### Q11. Permissions Strategy
@@ -182,10 +182,10 @@ Total: 20 questions.
 
 ### Q15. Distribution Method
 - **Options**:
-  - A) App Store (TestFlight) + Google Play (Internal Testing) **【Recommended】**
+  - A) Applicable public stores for active profiles **【Recommended】** — App Store/TestFlight for iOS; Google Play testing/release tracks for Android
   - B) Enterprise / internal distribution (MDM / private store)
-  - C) Not determined yet (development phase)
-- **Note**: Determines code signing, version management, staged rollout, and app review guideline rules.
+  - C) Not determined yet (development phase) **【Recommended when no release channel has been confirmed】**
+- **Note**: A single-platform project receives only its platform's distribution rules. Dual-native projects render both public-store profiles. Rollout percentages and observation windows are selected from product risk rather than hardcoded here. Quick mode cannot assume public distribution from `mobile` alone.
 - **Maps to**: `{{ distribution }}` + `{{ distribution_rules }}`
 
 ---

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

@@ -1,9 +1,24 @@
 {
-  "schema_version": "app-planner-question-manifest-v1",
+  "schema_version": "app-planner-question-manifest-v2",
   "layer": "mobile",
   "total_questions": 20,
   "_doc": "Machine-readable structure for mobile 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, e.g. 'Q12 in [A, B]'. options_vary_by names a prior answer that changes the OPTION LIST only (question is still asked; never affects required). dual_native_repeat_when notes Q1=E (both native) repeats the question per platform.",
+  "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", "Q16", "Q17", "Q18", "Q19", "Q20"]
+  },
+  "multi_profile_contract": {
+    "when": "Q1 == E",
+    "dimensions": ["Q4", "Q6", "Q7", "Q8", "Q13", "Q14"],
+    "profiles": ["ios", "android"],
+    "output_placeholder": "platform_profiles"
+  },
   "groups": [
     { "id": "G1", "topic": "Platform & Language", "quick_mode": true },
     { "id": "G2", "topic": "Architecture", "quick_mode": true },
@@ -41,7 +56,7 @@
   "template_placeholders": {
     "from_questions": ["platform", "tech_stack_rules", "min_os_version", "architecture", "arch_rules", "ui_framework", "ui_rules", "navigation", "navigation_rules", "state_management", "state_rules", "networking", "networking_rules", "persistence", "persistence_rules", "push_notifications", "platform_features_rules", "background_tasks", "permissions_strategy", "test_coverage", "test_rules", "unit_test_framework", "e2e_framework", "distribution", "distribution_rules", "performance_target", "performance_rules", "a11y_target", "a11y_rules", "ai_dependency_rule", "ai_breaking_change_rule", "ai_platform_rule"],
     "from_fixed_rules": ["FIXED_RULES_A11Y", "FIXED_RULES_AI_BASE", "FIXED_RULES_DISTRIBUTION", "FIXED_RULES_NAVIGATION", "FIXED_RULES_NETWORKING", "FIXED_RULES_PERFORMANCE", "FIXED_RULES_PERSISTENCE", "FIXED_RULES_PLATFORM_FEATURES", "FIXED_RULES_SECURITY", "FIXED_RULES_STATE", "FIXED_RULES_STRUCTURE", "FIXED_RULES_TEST", "FIXED_RULES_UI"],
-    "auto_generated": ["deny_list_summary", "recommended_libs"],
+    "auto_generated": ["deny_list_summary", "recommended_libs", "platform_profiles"],
     "metadata": ["project_name", "generated_at"]
   }
 }