prizmkit 1.1.154 → 1.1.155

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

@@ -1,188 +1,115 @@
-# Fixed Rules — Complete Frontend Fixed Rules
+# Frontend Invariant Rules
 
-> This file is read by the `frontend-rules` skill in Phase 1 and injected directly into `frontend-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 contain only safety and correctness requirements that remain valid across every frontend option exposed by Rules Configuration.
 
-## F1. Types & Code Quality
+**Selected-decision boundary:** framework, meta-framework, package manager, styling, fonts, state libraries, API type source, token layering, dark mode, responsive strategy, localization, test depth, dependency permission, caller analysis, config permission, file-size target, and performance targets belong to confirmed decisions and derivation rules. Do not add those policies here.
 
-### F1.1 TypeScript Strict Mode
-- **Rule**: `tsconfig.json` must enable `"strict": true`.
-- **Forbidden**: Using `any`. Use `unknown` and apply type guards before use.
-- **Forbidden**: `@ts-ignore`. If ignoring is necessary, use `@ts-expect-error` with a reason comment.
-- **RATIONALE**: Types are the safety net for large projects. AI understands context more accurately in strict mode.
-
-### F1.2 Lint & Formatting
-- **Rule**: ESLint + Prettier config must be committed to the repository root.
-- **Rule**: Git pre-commit hooks (husky + lint-staged) enforce lint and format.
-- **Forbidden**: Committing `console.log`, `debugger`, unattributed `TODO` (must include issue number or owner).
-- **RATIONALE**: Automated guardrails are always more reliable than manual review.
+## I1. Type and Contract Safety
 
-### F1.3 Naming Conventions
-- **Component files**: PascalCase (`UserCard.tsx`)
-- **Hook files**: camelCase prefixed with `use` (`useAuth.ts`)
-- **Utility functions**: camelCase (`formatDate.ts`)
-- **Constants**: SCREAMING_SNAKE_CASE (`MAX_RETRY_COUNT`)
-- **Types/Interfaces**: PascalCase. Avoid `I` prefix (`User`, not `IUser`).
-- **Forbidden**: Pinyin names, meaningless abbreviations (`a`/`b`/`tmp`), numeric suffixes (`button2`/`utils3`).
-- **RATIONALE**: Consistent naming significantly improves AI search/completion hit rates.
+- Preserve declared public component, hook, route, event, and data contracts unless the task explicitly includes a migration.
+- In typed code, keep public inputs and outputs typed and justify any suppression or unsafe cast at the narrowest boundary.
+- Validate untrusted runtime data before treating it as a trusted application type.
+- Do not invent API fields, routes, component props, or library capabilities.
+- Rationale: contract safety applies regardless of framework or type system.
 
----
+Inject into `{{ FIXED_RULES_TYPESCRIPT }}`.
 
-## F2. Style Deny List (universally applicable)
+## I2. Naming Integrity
 
-- **Forbid** `!important` (unless overriding uncontrollable third-party styles, with a comment explaining why).
-- **Forbid** hardcoded color values (must use design tokens).
-- **Forbid** hardcoded font sizes, line heights, spacing, border radius, shadows, animation durations.
-- **Forbid** magic numbers (must use named constants).
-- **Forbid** inline `style` attributes (unless for dynamically computed positions/sizes, with a comment).
-- **Forbid** raw `z-index` numbers (must use a z-index layer constant).
-- **RATIONALE**: Hardcoded values make the design system meaningless. Once AI learns to hardcode, it spreads everywhere.
+- Follow the naming convention already selected or consistently detected for the project.
+- Use descriptive domain names; avoid ambiguous temporary names in durable interfaces.
+- Renames of exported identifiers include an explicit consumer migration or compatibility plan.
+- Rationale: consistency is invariant; a specific casing convention is not.
 
----
+Inject into `{{ FIXED_RULES_NAMING }}`.
 
-## F3. Component Design
+## I3. Design-System Integrity
 
-### F3.1 Component Contract
-- **Rule**: All Props must have complete TypeScript types. Forbid `Props: any`.
-- **Rule**: Components must support `className` forwarding, merged via `clsx`/`cn`.
-- **Rule**: Controlled vs. uncontrolled must be explicit. "Semi-controlled" is not allowed.
-- **Rule**: Exposed `ref` must use `forwardRef` with typing.
-- **RATIONALE**: Unclear component contracts are the main reason AI breaks three things when changing one.
+- When a design system or token strategy is selected, component code must use its public tokens and extension points rather than bypassing them with unexplained one-off values.
+- Third-party overrides and computed values are allowed only at a documented boundary.
+- Do not combine incompatible styling systems unless the selected migration plan explicitly defines the boundary.
+- Rationale: the invariant is honoring the selected system, not forcing one styling technology.
 
-### F3.2 File Size
-- **Rule**: Single component file ≤ 300 lines (including comments).
-- **Rule**: Beyond this, split by logic/view/types into the same directory.
-- **RATIONALE**: Beyond 300 lines, the risk of AI losing context during modification spikes sharply.
+Inject into `{{ FIXED_RULES_DENY_LIST }}`.
 
-### F3.3 Four-State Completeness
-- **Rule**: All data-driven views must explicitly handle `loading` / `error` / `empty` / `success` states.
-- **Forbid**: Using `data && <UI/>` to gloss over the empty state.
-- **RATIONALE**: Missing states are the largest source of hidden UX bugs.
+## I4. Component Contract
 
----
+- Components expose explicit inputs, outputs, states, and ownership boundaries.
+- Data-driven UI handles the applicable loading, error, empty, and success states or documents why a state cannot occur.
+- Shared components preserve accessibility semantics and consumer compatibility.
+- Rationale: clear component contracts are framework-independent.
 
-## F4. Internationalization (i18n) Baseline
+Inject into `{{ FIXED_RULES_COMPONENT_CONTRACT }}`.
 
-- **Forbid**: Hardcoding any user-visible text (buttons, titles, tooltips, error messages, empty states, placeholders).
-- **Rule**: All user-visible text must use i18n keys.
-- **Rule**: i18n key naming follows `page.section.element` three-segment format (e.g., `login.form.submitBtn`).
-- **Exception**: Pure brand names, trademarks, fixed acronyms (like `API`, `URL`) may be hardcoded.
-- **RATIONALE**: Even for single-language projects, reserving the i18n channel costs almost nothing. Retrofitting it later costs an enormous amount.
+## I5. Localization Decision Integrity
 
----
+- Follow the selected localization strategy consistently across a feature.
+- Do not mix centralized keys and ad-hoc literals in a way that makes one user flow partially localized.
+- Preserve locale-sensitive formatting for dates, numbers, plurals, and currency when localization is enabled.
+- Rationale: localization depth is user-owned; consistency with that decision is invariant.
 
-## F5. Error Handling
+Inject into `{{ FIXED_RULES_I18N_BASELINE }}`.
 
-- **Rule**: Route-level ErrorBoundary must exist.
-- **Rule**: Async operations must have loading + error UI. "Silent failure" is not allowed.
-- **Rule**: API failures must have user notification (toast/inline) + retry entry.
-- **Rule**: Caught errors must be reported to monitoring (Sentry / custom).
-- **Forbid**: `catch(e) {}` empty catch blocks.
-- **RATIONALE**: The worst frontend experience isn't a bug — it's "nothing happened."
-
----
-
-## F6. Accessibility (a11y Baseline)
-
-- **Rule**: All interactive elements must be keyboard-operable (Tab/Enter/Space/Esc).
-- **Rule**: Images must have `alt`. Decorative images use `alt=""`.
-- **Rule**: Icon buttons must have `aria-label`.
-- **Rule**: Form controls must be associated with `<label>` (`htmlFor` or wrapping).
-- **Rule**: Modal open must move focus into the modal. Modal close must return focus to the trigger element.
-- **Forbid**: `<div onClick>` as a substitute for `<button>`.
-- **Forbid**: Conveying information through color alone (must pair with icon/text).
-- **RATIONALE**: a11y is not a moral requirement — it's a legal requirement (GDPR/ADA), and SEO shares the same foundation.
-
----
-
-## F7. Git Collaboration
-
-### F7.1 Branching & Commits
-- **Branch naming**: `feat/xxx`, `fix/xxx`, `refactor/xxx`, `chore/xxx`, `docs/xxx`.
-- **Commit messages**: Follow Conventional Commits (`type(scope): subject`).
-- **Rule**: Main branch protection. PR + Code Review required to merge.
-- **Rule**: Single PR changes ≤ 500 lines (generated code excluded). Beyond this, must split.
-
-### F7.2 PR Self-Check Checklist (must review each item)
-- [ ] Local `lint` / `typecheck` / `test` all green
-- [ ] New components registered in component index
-- [ ] New user-visible text has i18n keys
-- [ ] Four states (loading/error/empty/success) covered
-- [ ] No hardcoded colors/font sizes/spacing
-- [ ] No `console.log` / `debugger` / `any`
-- [ ] Key changes have supporting description (screenshots / recordings / design links)
-
----
-
-## F8. Security Baseline
-
-- **Forbid**: Writing API keys, tokens, or secrets into frontend code.
-- **Forbid**: Using `dangerouslySetInnerHTML` / `v-html` to render user input (must sanitize).
-- **Rule**: All external links with `target="_blank"` must include `rel="noopener noreferrer"`.
-- **Rule**: Form submission requires client-side validation, but **forbid** relying solely on client-side validation.
-- **Rule**: Sensitive operations (delete, payment) require secondary confirmation.
-- **RATIONALE**: The frontend is an attack surface, not a security boundary.
-
----
+## I6. Error and Async-State Safety
 
-## F9. AI Vibecoding Baseline Constraints (project-agnostic, always active)
-
-### F9.1 Search First
-- **Rule**: Before generating a new component, AI must search the `src/components/` index to check if a similar component already exists.
-- **Rule**: Before generating a utility function, AI must search `src/utils/` / `src/hooks/`. Forbid reinventing the wheel.
-
-### F9.2 Dependency Control
-- **Rule**: AI must not introduce new npm dependencies on its own.
-- **Rule**: If a new dependency is truly needed, AI must **explicitly list** in its response: package name, version, reason, alternative comparison. Human reviews the `package.json` change.
-
-### F9.3 Breaking Changes
-- **Rule**: Before modifying a shared component / common hook / common type, AI must first list **all callers**.
-- **Rule**: If the change would break callers, AI must provide a migration plan or refuse the change.
-
-### F9.4 Context Honesty
-- **Rule**: When uncertain, AI must explicitly say "I'm not sure." Forbid inventing API paths, file paths, or field names.
-- **Rule**: AI must read the latest file contents before modifying. Forbid generating diffs based on guesswork.
-
-### F9.5 Comment Obligation
-- **Rule**: Non-obvious AI-generated code must include a "why" comment (not "what").
-- **Forbid**: AI deleting existing comments (unless the corresponding code is also deleted).
-
----
+- Do not swallow errors silently.
+- Async user actions expose a deterministic pending and failure outcome and prevent unintended duplicate submission where side effects are not idempotent.
+- User-facing errors avoid secrets and internal implementation details while logs preserve actionable diagnostic context.
+- Rationale: failures must remain observable under every framework choice.
 
-## F10. Performance Baseline
-
-- **Rule**: List rendering must have `key`, and `key` must not use index (unless the list is purely static).
-- **Rule**: Long lists (>100 items) must use virtual scrolling.
-- **Rule**: Routes must be code-split (dynamic import).
-- **Rule**: Images must be lazy-loaded (`loading="lazy"`) + modern formats (webp/avif) + explicit width/height (prevents CLS).
-- **Rule**: Avoid creating new objects/functions in render (unless wrapped with memo).
-- **RATIONALE**: These are zero-cost performance optimizations. There is no reason not to do them.
+Inject into `{{ FIXED_RULES_ERROR_HANDLING }}`.
 
----
-
-## Injection Instructions (for the AI executing this skill)
-
-Each chapter in this file corresponds to a `{{ FIXED_RULES_* }}` placeholder in the template. During Phase 4 rendering, copy each chapter's full body (including RATIONALE) directly into the corresponding placeholder:
-
-| Chapter | Inject Into Placeholder | Template Section |
-|---------|------------------------|-------------------|
-| F1.1 TypeScript Strict Mode | `{{ FIXED_RULES_TYPESCRIPT }}` | §3.1 Type Safety |
-| F1.3 Naming Conventions | `{{ FIXED_RULES_NAMING }}` | §3.2 Naming Conventions |
-| F2 Style Deny List | `{{ FIXED_RULES_DENY_LIST }}` | §1.5 Style Deny List |
-| F3.1 Component Contract | `{{ FIXED_RULES_COMPONENT_CONTRACT }}` | §2.1 Component Contract |
-| F4 i18n Baseline | `{{ FIXED_RULES_I18N_BASELINE }}` | §5.4 Internationalization |
-| F5 Error Handling | `{{ FIXED_RULES_ERROR_HANDLING }}` | §5.2 Error Handling Rules |
-| F6 a11y Baseline | `{{ FIXED_RULES_A11Y }}` | §5.3 Accessibility |
-| F7 Git Collaboration | `{{ FIXED_RULES_GIT }}` | §8.1 Branching & Commits |
-| F8 Security Baseline | `{{ FIXED_RULES_SECURITY }}` | §9 Security Baseline |
-| F9 AI Baseline Constraints | `{{ FIXED_RULES_AI_BASE }}` | §7.1 Baseline Constraints |
-| F10 Performance Baseline | `{{ FIXED_RULES_PERFORMANCE }}` | §5.5 Performance Baseline |
-
-**Rendering rules**:
-1. For chapters marked "already present as fixed text in template", AI does not need to re-inject — the template has them hardcoded.
-2. Chapters marked "merged into..." should be prepended as baseline rules at the front of the corresponding derivation rule blocks.
-3. **RATIONALE fields must be preserved** — they give AI the basis for judgment at boundary cases.
-4. Keep the original markdown list structure when injecting. Do not rewrite as prose paragraphs.
+## I7. Accessibility Baseline
+
+- Interactive controls are operable with the platform's standard keyboard or assistive input model.
+- Controls have accessible names; form controls have associated labels; focus remains predictable across overlays and navigation.
+- Information is not conveyed by color alone, and decorative media is excluded from the accessibility tree.
+- Apply any stricter selected accessibility target through derivation rules.
+- Rationale: semantic access is a baseline while the conformance target is configurable.
+
+Inject into `{{ FIXED_RULES_A11Y }}`.
+
+## I8. Evidence-Based Performance
+
+- Measure before introducing a performance-specific abstraction.
+- Avoid unbounded rendering, listeners, subscriptions, caches, and retained resources.
+- Preserve correctness and accessibility when applying loading, memoization, virtualization, or code-splitting strategies.
+- Apply numeric budgets only from the selected performance decisions.
+- Rationale: resource safety is invariant; concrete budgets and techniques are contextual.
+
+Inject into `{{ FIXED_RULES_PERFORMANCE }}`.
+
+## I9. AI Change Safety
+
+- Read the current target and search for existing reusable behavior before creating a duplicate.
+- Keep changes inside the requested scope and report uncertainty rather than inventing repository facts.
+- Never expose secrets, weaken validation, or remove a safety check merely to make a build pass.
+- Dependency, shared-caller, config-file, and file-size permissions come only from their selected decision blocks.
+- Rationale: evidence and scope honesty remain valid under every permission mode.
+
+Inject into `{{ FIXED_RULES_AI_BASE }}`.
+
+## I10. Collaboration Integrity
+
+- Use the repository's existing branch, commit, review, and verification conventions when they exist.
+- Report changed public contracts, relevant verification, and known follow-up work.
+- Do not claim checks passed unless evidence exists.
+- Rationale: the project owns its collaboration model; truthful evidence is invariant.
+
+Inject into `{{ FIXED_RULES_GIT }}`.
+
+## I11. Frontend Security
+
+- Never place secrets or privileged credentials in browser-delivered code.
+- Treat browser validation as usability and defense-in-depth, not as the server authorization boundary.
+- Sanitize untrusted rich content and protect external navigation boundaries against opener and redirect abuse.
+- Sensitive side effects require the authorization and confirmation behavior defined by the product contract.
+- Rationale: the browser is attacker-controlled under every stack choice.
+
+Inject into `{{ FIXED_RULES_SECURITY }}`.
+
+## Injection Contract
+
+Copy each `I*` block only into its named placeholder. Do not copy the header, policy metadata, or selected-decision boundary into generated files. If a proposed invariant conflicts with a confirmed decision, fail generation and reclassify the rule instead of emitting both.

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

@@ -28,14 +28,14 @@
 1. **Group order**: G1 → G2 → G3 → G4 → G5 → G6 → G7 → G8 → G9. Do not skip.
 2. **Shortcut commands** (respond immediately when user types these at any point):
    - `recommended` / `default` → skip current group, adopt all recommended options
-   - `all recommended` / `one-click` → skip all remaining groups, adopt all recommended options
+   - `all recommended` / `one-click` → explicit authorization to adopt each remaining applicable recommended option; ask any question whose recommendation is ambiguous for the selected stack
    - `strict` / `strictest` → adopt the strictest option for the current group
    - `skip` / `don't need this` → mark current group as N/A, note in output that "project does not require this yet"
    - `custom: xxx` → record user's custom content, do not match against options
 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 (e.g., "I use Astro"), first confirm whether to classify as an "other" branch of an existing option before continuing.
 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.
 
@@ -73,13 +73,16 @@ Total: 25 questions.
 
 ### Q2. Meta-Framework
 - **Options**:
-  - A) Next.js (App Router) **【Recommended for React projects】**
-  - B) Nuxt (Recommended for Vue projects)
+  - A) Next.js (App Router) **【Recommended for React full-stack/SSR needs】**
+  - B) Nuxt **【Recommended for Vue full-stack/SSR needs】**
   - C) Remix
   - D) Plain SPA (Vite)
-  - E) Custom
-- **Note**: Affects SSR/RSC, routing conventions, data fetching rules.
-- **Maps to**: `{{ meta_framework }}` (TL;DR + §2.4) + `{{ tech_stack_rules }}` (derivation injection)
+  - E) SvelteKit **【Recommended for Svelte full-stack/SSR needs】**
+  - F) SolidStart **【Recommended for Solid full-stack/SSR needs】**
+  - G) Custom
+- **Compatibility**: React → A/C/D/G; Vue → B/D/G; Svelte → D/E/G; Solid → D/F/G; Custom/Other → D/G unless the user names a compatible tool.
+- **Note**: Affects rendering, routing, and data-fetching rules. When product requirements do not need a meta-framework, a plain SPA is a valid explicit choice.
+- **Maps to**: `{{ meta_framework }}` (TL;DR + architecture section) + `{{ tech_stack_rules }}` (derivation injection)
 
 ### Q3. Package Manager
 - **Options**:
@@ -121,32 +124,39 @@ Total: 25 questions.
 
 ### Q5. Global State Library
 - **Options**:
-  - A) Zustand **【Recommended for React】**
-  - B) Pinia **【Recommended for Vue】**
+  - A) Zustand **【Recommended for React when global client state is needed】**
+  - B) Pinia **【Recommended for Vue when global client state is needed】**
   - C) Redux Toolkit
   - D) Jotai / Valtio
-  - E) Context / Provide-Inject only, no global store
-- **Note**: Recommendation depends on Q1 framework choice.
-- **Maps to**: `{{ state_lib }}` (TL;DR + §4.1) + `{{ state_rules }}` (derivation injection)
+  - E) Framework context/provide only
+  - F) Svelte runes/stores
+  - G) Solid signals/store
+  - H) Custom or no dedicated global-state library
+- **Compatibility**: React → A/C/D/E/H; Vue → B/E/H; Svelte → E/F/H; Solid → E/G/H; Custom/Other → H unless the user names a compatible mechanism.
+- **Note**: Use only for confirmed cross-page client state. Server data does not belong here, and Quick mode should select no dedicated library when no global-state need has been established.
+- **Maps to**: `{{ state_lib }}` (TL;DR + state section) + `{{ state_rules }}` (derivation injection)
 
 ### Q6. Server State Library
 - **Options**:
-  - A) TanStack Query **【Recommended】**
+  - A) TanStack Query **【Recommended when client-side server-state caching is required and the selected framework is supported】**
   - B) SWR
   - C) RTK Query
-  - D) Custom fetch hook wrapper
-- **Strict option**: A (TanStack Query + enforced queryKey convention)
-- **Note**: Affects API caching, retry, and staleTime rules.
-- **Maps to**: `{{ server_state_lib }}` (TL;DR + §4.2) + `{{ server_state_rules }}` (derivation injection)
+  - D) Custom fetch/data boundary
+  - E) No dedicated client server-state library **【Recommended when the selected meta-framework owns data loading or no client cache is needed】**
+- **Strict option**: A (TanStack Query + enforced query-key convention)
+- **Note**: Choose from confirmed data-loading and caching needs. Quick mode must not add a client cache solely because a library is available.
+- **Maps to**: `{{ server_state_lib }}` (decision ledger + state section) + `{{ server_state_rules }}` (derivation injection)
 
 ### Q7. API Type Source
 - **Options**:
-  - A) Backend OpenAPI auto-generation **【Recommended】**
-  - B) Backend Protobuf generation
-  - C) Hand-written .d.ts
-  - D) Shared monorepo type package with backend
-- **Strict option**: A or B (eliminates hand-written types)
-- **Note**: Determines whether to inject the "forbid hand-written API types" constraint.
+  - A) Backend OpenAPI code generation **【Recommended for an OpenAPI-owned REST contract】**
+  - B) Backend Protobuf generation **【Recommended for a Protobuf/gRPC-owned contract】**
+  - C) Hand-written TypeScript declarations plus runtime validation
+  - D) Shared monorepo contract/type package with backend
+  - E) GraphQL schema/code generation **【Recommended for a GraphQL-owned contract】**
+  - F) Framework/server contract inference supported by the selected stack
+- **Strict option**: Use the authoritative backend contract source when one exists; never select an incompatible generator.
+- **Note**: There is no universal Quick default. Match the confirmed backend/API contract or ask, and keep runtime validation for untrusted data where static generation is insufficient.
 - **Maps to**: `{{ api_type_source }}` (TL;DR + §4.3) + `{{ server_state_rules }}` (derivation injection)
 
 ---
@@ -173,10 +183,10 @@ Total: 25 questions.
 
 ### Q10. Dark Mode
 - **Options**:
-  - A) Supported, via CSS variable switching **【Recommended】**
-  - B) Supported, via class switching (Tailwind `dark:` prefix)
-  - C) Not supported
-- **Note**: Choosing A/B auto-injects "tokens must include both light/dark value pairs" rule.
+  - A) Supported via the selected token/theme mechanism **【Recommended when dark mode is a product requirement】**
+  - B) Supported via a styling-library class/variant mechanism
+  - C) Not supported **【Recommended when no dark-mode requirement exists】**
+- **Note**: Choose from product/design evidence. A/B derive complete light/dark token behavior; C renders an explicit no-dark-mode decision.
 - **Maps to**: `{{ dark_mode }}` (TL;DR) + `{{ dark_mode_rules }}` (derivation injection into §1.3)
 
 ---
@@ -206,10 +216,10 @@ Total: 25 questions.
 
 ### Q13. Internationalization (i18n)
 - **Options**:
-  - A) Multi-language with full i18n framework (specify: zh-CN, en-US, ja-JP, etc.)
-  - B) Single-language, but text centralized in i18n files for future expansion **【Recommended: early-stage projects】**
-  - C) Single-language, hardcoding allowed (no i18n infrastructure)
-- **Note**: Choosing A auto-injects i18n key naming rules and forbid hardcoding user-visible text. B centralizes text but does not require multi-language support. C allows hardcoding and requires no i18n infrastructure.
+  - A) Multi-language with a selected i18n framework and explicit locale list
+  - B) Single-language with text centralized for a confirmed near-term localization path
+  - C) Single-language with no i18n infrastructure **【Recommended when localization is not planned】**
+- **Note**: Quick mode derives this only from confirmed locale/product scope. A/B centralize user-visible text; C permits in-scope literals and must not inherit hidden i18n requirements.
 - **Maps to**: `{{ i18n }}` (TL;DR) + `{{ i18n_rules }}` (derivation injection into §5.4)
 
 ### Q14. Accessibility Target
@@ -255,12 +265,12 @@ Total: 25 questions.
 
 ## G8 — AI Vibecoding Constraints
 
-### Q18. AI Component Index Sync
+### Q18. AI Component Export Registry Sync
 - **Options**:
-  - A) Must sync to `src/components/index.ts` + type exports **【Recommended】**
-  - B) Not required
-- **Strict option**: A
-- **Note**: Determines whether AI will reinvent existing components. Strict is safer.
+  - A) Must synchronize the project's existing authoritative component/export registry **【Recommended when such a registry exists】**
+  - B) No central registry; update direct exports/consumers only **【Recommended when no registry exists】**
+- **Strict option**: A when a stable registry path was detected or confirmed
+- **Note**: Record the actual stable registry path when A is selected; never invent `src/components/index.ts`.
 - **Maps to**: `{{ ai_index_rule }}` (injected into §7.3)
 
 ### Q19. AI Permission to Add Dependencies

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

@@ -1,9 +1,18 @@
 {
-  "schema_version": "app-planner-question-manifest-v1",
+  "schema_version": "app-planner-question-manifest-v2",
   "layer": "frontend",
   "total_questions": 25,
   "_doc": "Machine-readable structure for frontend 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. 'Q15 in [A, B]'. options_vary_by names a prior answer that changes the OPTION LIST/recommendation only (question is still asked; never affects required).",
+  "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", "Q4b", "Q5", "Q6", "Q7", "Q8", "Q9", "Q10", "Q11", "Q12", "Q13", "Q14", "Q15", "Q16", "Q17", "Q18", "Q19", "Q20", "Q21", "Q22", "Q23", "Q24"]
+  },
   "groups": [
     { "id": "G1", "topic": "Tech Stack", "quick_mode": true },
     { "id": "G2", "topic": "Styling", "quick_mode": true },
@@ -34,7 +43,7 @@
     { "id": "Q15", "group": "G7", "topic": "Test Coverage Requirements", "maps_to": ["test_coverage", "test_rules"], "required": true },
     { "id": "Q16", "group": "G7", "topic": "Unit Test Framework", "maps_to": ["unit_test_framework", "test_rules"], "required": true, "required_if": "Q15 in [A, B]" },
     { "id": "Q17", "group": "G7", "topic": "E2E Framework", "maps_to": ["e2e_framework", "test_rules"], "required": true, "required_if": "Q15 in [A, C]" },
-    { "id": "Q18", "group": "G8", "topic": "AI Component Index Sync", "maps_to": ["ai_index_rule"], "required": true },
+    { "id": "Q18", "group": "G8", "topic": "AI Component Export Registry Sync", "maps_to": ["ai_index_rule"], "required": true },
     { "id": "Q19", "group": "G8", "topic": "AI Permission to Add Dependencies", "maps_to": ["ai_dependency_rule"], "required": true },
     { "id": "Q20", "group": "G8", "topic": "AI Impact Analysis Before Modifying Shared Components", "maps_to": ["ai_breaking_change_rule"], "required": true },
     { "id": "Q21", "group": "G8", "topic": "AI Permission to Modify Config Files", "maps_to": ["ai_config_rule"], "required": true },