prizmkit 1.1.147 → 1.1.149

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.147",
-  "bundledAt": "2026-07-23T04:05:31.031Z",
-  "bundledFrom": "5238680"
+  "frameworkVersion": "1.1.149",
+  "bundledAt": "2026-07-25T02:52:20.120Z",
+  "bundledFrom": "4b222c1"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.147",
+  "version": "1.1.149",
   "skills": {
     "prizmkit": {
       "description": "Framework introduction and navigation for the formal single-requirement lifecycle, project initialization, Prizm docs, and independent deployment.",

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

@@ -36,18 +36,18 @@ If you believe the task is better suited for a different workflow, you MUST:
 **Your ONLY writable outputs are:**
 1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
 2. `.prizmkit/plans/project-brief.draft.md` — working source during planning and saved draft when the user exits before completion
-3. Project conventions and architecture decisions appended to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
-4. Infrastructure configuration (database conventions, deployment config, **cloud services**) appended to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
-5. `.prizmkit/rules/<layer>-rules.md` — per-layer development rules generated by Rules Configuration
-6. `.prizmkit/prizm-docs/root.prizm` — `RULES:` pointer line only (not other root.prizm content; created minimally if absent)
-
-**Project instruction file selection**:
-- If `.prizmkit/manifest.json` exists, use its `platform` field as the source of truth.
-- Codex → `AGENTS.md`
-- Claude Code → `CLAUDE.md`
-- CodeBuddy → `CODEBUDDY.md`
-- `all` → all three files.
-- Only when the manifest is missing, fall back to installed PrizmKit-owned platform files such as `.claude/commands/prizmkit.md`, `.agents/skills/prizmkit/SKILL.md`, or `.codebuddy/skills/prizmkit/SKILL.md`. Do not treat a generic `.agents/` directory as Codex.
+3. The resolved project instruction target for the current AI host (with user consent) — only project conventions, infrastructure configuration (database conventions, deployment config, **cloud services**), frontend design direction, and architecture decisions
+4. `.prizmkit/rules/<layer>-rules.md` — per-layer development rules generated by Rules Configuration
+5. `.prizmkit/prizm-docs/root.prizm` — `RULES:` pointer line only (not other root.prizm content; created minimally if absent)
+
+**Current-host project instruction target resolution**:
+- Identify the current AI host from direct runtime/session evidence and the host's own project conventions. Installed project resources, existing project files, and `.prizmkit/manifest.json` are supporting evidence only; they are not a platform identity or path allowlist and must not override stronger current-session evidence.
+- Resolve the host's conventional main project-level AI instruction/context file: a project-local, durable file that the current host loads or reads to guide AI work in this project.
+- Named paths such as `AGENTS.md`, `CLAUDE.md`, `CODEBUDDY.md`, and `.pi/APPEND_SYSTEM.md` are non-exhaustive examples only. They do not define a platform-to-path mapping or a compliance condition.
+- The target must stay inside the project, represent the current host's main user-facing project instruction context, and must not be a private or framework-protocol-only import file.
+- If the conventional target is absent, create it only when current-host evidence establishes one unambiguous conventional project path and the user consents to the write.
+- If no target can be identified confidently or multiple plausible targets remain, use `AskUserQuestion` to confirm the intended project instruction file before writing. Never guess, and never treat semantic detection as permission to write an arbitrary file.
+- Resolve the target once before project-convention discovery and reuse the same resolved target for conventions, infrastructure, frontend design direction, architecture decisions, prerequisites, checkpoints, generated-plan review, and completion reporting. Do not mirror content to every installed host merely because multiple platform resources exist.
 
 **After planning is complete**, you MUST:
 1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
@@ -60,33 +60,43 @@ If you believe the task is better suited for a different workflow, you MUST:
 
 Every new or changed project brief line, convention, infrastructure decision, architecture decision, and rule must be understandable by a fresh AI session that has never seen the planning conversation. Durable app context records the actual selected product or technical decision, not the answer token used in chat.
 
+### Artifact-Wide AI Readability
+
+- Every generated natural-language value must be a standalone domain statement. This applies to all AI-visible fields and sections in project briefs and drafts, project instruction files, conventions, infrastructure, architecture decisions, generated layer rules, appendices, comments, brainstorm summaries, quoted evidence, and parentheticals.
+- Machine metadata such as schema markers, stable IDs, statuses, enums, and timestamps is exempt. Natural-language metadata is not exempt.
+- Never emit dialogue-role or chronology labels such as `user said`, `user answered`, `original request`, `this round`, `previous discussion`, `as discussed earlier`, `用户本轮回答`, or `如前面讨论`. Never emit planning question IDs, answer tokens, planning-option recommendation markers, checkpoint provenance, or raw internal answer-map entries as domain content.
+- Internal Q&A may drive derivation, but final writers render complete product or technical meaning. Quotes are allowed only as independently intelligible source evidence, never as planning-turn provenance.
+
 ### Conversational Context Normalization
 
 - Never persist standalone option labels such as `A`, `B`, `C`, `方案A`, or `方案B`.
-- Expand each selected option into complete meaning and preserve its source inline: `Selected decision: <complete meaning> (original response: "<exact response>")`.
+- Expand each selected option into complete decision meaning. Preserve substantive user rationale and constraints in durable prose at matching detail.
+- Do not emit transcript annotations such as `(original response: "...")` in final app-planning artifacts. Bare option labels and relative shorthand are not independently intelligible and materially useful exact wording.
 - Resolve `上面`, `这个`, `按推荐走`, `同前`, `继续这样`, `用刚才的方案`, `same as above`, or `go with your recommendation` only when there is one provable antecedent. If multiple antecedents are plausible, ask the user for clarification; never guess.
-- Exclude conversational authorization such as `所有问题都按你的推荐处理` when it only controls planning behavior and does not constrain the product or implementation.
+- Treat `所有问题都按你的推荐处理`, `全部按照推荐`, `use all recommendations`, and equivalent blanket recommendation approval as conversational authorization. Apply the concrete accepted defaults, then omit the approval; never repeat it once per accepted recommendation.
 - Do not present rejected alternatives as active decisions. Include one only when it defines a necessary non-goal or compatibility boundary.
-- Preserve detailed user requirements at matching detail; normalization must not simplify away substantive product, infrastructure, architecture, or development rules.
+- Preserve detailed user requirements at matching detail; normalization must not simplify away substantive product, infrastructure, architecture, or development rules. Retain an exact excerpt only when the wording itself is independently intelligible and materially useful.
 
 ### Reference Material Handling
 
-- Every retained file path, URL, screenshot, diagram, log, issue, PRD, or document reference must be purpose-tagged: say why it matters and what a downstream AI should inspect. This applies to paths and URLs in all app-planning artifacts.
-- Good: `docs/architecture.md §Authentication — inspect identity-provider ownership and session boundaries`; Bad: `docs/architecture.md` alone.
-- For large materials, record title/location and purpose, preserve only task-relevant exact excerpts, and move confirmed product or technical decisions into the durable app-planning artifact.
+- Every retained stable code, configuration, machine-consumed interface, or URL reference must be purpose-tagged: say why it matters and what a downstream AI should inspect. This applies to paths and URLs in all app-planning artifacts.
+- Do not retain non-code planning-source paths such as `.agents/brainstorm/<note>.md`, uploaded-document paths, screenshot paths, or ad-hoc log paths in durable app artifacts. Instead, copy or normalize the task-relevant content into the brief, conventions, architecture decisions, or rules; the artifact must not depend on that source file still existing.
+- Good: `src/auth/ — inspect identity-provider and session ownership`; Bad: `.agents/brainstorm/design.md — inspect accepted architecture`. For the latter, write the accepted architecture, rationale, constraints, and risks inline and omit the path.
+- For large materials, record purpose, preserve only task-relevant exact excerpts, and move confirmed product or technical decisions into the durable app-planning artifact. Retain a location only when it is a stable execution-time source of truth.
 - Embed complete large materials only when future sessions cannot access the source and all content is genuinely required.
 
 ### Good and Bad Normalization Examples
 
 - Bad: `[ ] 使用方案B`, `按推荐走`, `use option A`, `same as above`, or `go with your recommendation`.
-- Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`.
-- Good: `Deployment target: managed container service with PostgreSQL in the same region (original response: "use option A")`.
-- Bad: storing `所有问题都按你的推荐处理` as a project convention; it is conversational authorization.
+- Bad: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`; the decision is complete, but the transcript annotation still requires an unseen option list.
+- Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions`.
+- Good: `Deployment target: managed container service with PostgreSQL in the same region`.
+- Bad: storing or repeating `全部按照推荐` / `所有问题都按你的推荐处理` as project conventions; they are conversational authorization.
 - Bad: attaching an entire infrastructure proposal while recording only `follow this`. Good: retain a purpose-tagged proposal section and task-relevant exact excerpts, then name the actual network, database, and deployment decisions.
 
 ## Pre-Generation Headless Context Completeness Gate
 
-Before any final app-planning writer runs, review every new or changed brief line, convention, infrastructure decision, architecture decision, and rule as if the reviewer has never seen the planning conversation. Preserve unchanged historical content; do not bulk-rewrite it. From the proposed artifact alone, answer:
+Before any final app-planning writer runs, review every new or changed brief line, convention, infrastructure decision, architecture decision, and rule as if the reviewer has never seen the planning conversation. Preserve unchanged historical content; do not bulk-rewrite it. First scan all AI-visible fields and sections: every generated natural-language value must be session-independent, with no dialogue-role labels, question IDs, answer tokens, planning-option recommendation markers, checkpoint provenance, raw answer-map content, or transient planning-source dependencies. From the proposed artifact alone, answer:
 
 1. What exact product outcome or technical decision does this line record?
 2. What exists today and what desired state or constraint applies?
@@ -120,7 +130,7 @@ Do NOT use this skill when:
    - During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
 
 3. **Project conventions discovery** — after Intent Confirmation, before brainstorm or vision work:
-   → Read `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` and check for `### Project Conventions` section
+   → Resolve the current host's project instruction target through **Current-host project instruction target resolution**, then read that exact target and check for a `### Project Conventions` section
    → If section exists and covers the project well → skip silently
    → If section is missing or incomplete → run the **AI-driven convention discovery** below:
 
@@ -128,18 +138,18 @@ Do NOT use this skill when:
 
    → Read `${SKILL_DIR}/references/project-conventions-discovery.md` for the full AI-driven discovery procedure (Analyze → Reason → Present via AskUserQuestion).
 
-   → Run the Pre-Generation Headless Context Completeness Gate on each proposed convention, then save passing answers to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
+   → Normalize each proposed convention into a standalone domain rule, run the Pre-Generation Headless Context Completeness Gate, then save only passing convention meanings to the resolved project instruction target under `### Project Conventions` (one bullet per convention; no raw answers or planning provenance)
    → Output format will naturally vary per project — that is the intended behavior
 
    **Infrastructure Convention Discovery (Database + Deployment)**
 
-   After project conventions are captured, check the project instruction file for `### Infrastructure` section status. Read `${SKILL_DIR}/references/infrastructure-convention-discovery.md` for the full database (6 topics — table naming, field naming, migrations, primary keys, indexes, environment separation), deployment (4 topics — target refinement, existing infrastructure, AI-assisted deploy, env var management), and cloud services (2-round AskUserQuestion) inquiry procedures. Follow the inquiry flow there — use `AskUserQuestion` for each batch. Each question MUST include a "Skip — decide later" option.
+   After project conventions are captured, check the resolved project instruction target for `### Infrastructure` section status. Read `${SKILL_DIR}/references/infrastructure-convention-discovery.md` for the full database (6 topics — table naming, field naming, migrations, primary keys, indexes, environment separation), deployment (4 topics — target refinement, existing infrastructure, AI-assisted deploy, env var management), and cloud services (2-round AskUserQuestion) inquiry procedures. Follow the inquiry flow there — use `AskUserQuestion` for each batch. Each question MUST include a "Skip — decide later" option.
 
-   After inquiry, run the Pre-Generation Headless Context Completeness Gate on every proposed infrastructure decision, then update the `### Infrastructure` section in the project instruction file with passing content (see reference file for full output format). Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` for `prizmkit-deploy` to pick up later.
+   After inquiry, run the Pre-Generation Headless Context Completeness Gate on every proposed infrastructure decision, then update the `### Infrastructure` section in the resolved project instruction target with passing content (see reference file for full output format). Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` for `prizmkit-deploy` to pick up later.
 
 4. **Project brief accumulation** — throughout all interactive phases:
    → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
-   → Update the in-memory or `.prizmkit/plans/project-brief.draft.md` source after each meaningful user response containing business intent, constraints, or design decisions; do not write the final `.prizmkit/plans/project-brief.md` until the Pre-Generation Headless Context Completeness Gate passes
+   → After each meaningful response containing business intent, constraints, or design decisions, normalize its substantive meaning into standalone domain prose before updating the in-memory or `.prizmkit/plans/project-brief.draft.md` source; never store the raw turn or answer token; do not write the final `.prizmkit/plans/project-brief.md` until the Pre-Generation Headless Context Completeness Gate passes
 
 ## Rules Configuration (after Infrastructure)
 
@@ -158,8 +168,8 @@ Proceed to Prerequisites and continue the app-planner workflow.
 Before questions, check optional context files (never block if absent):
 - `.prizmkit/prizm-docs/root.prizm` (architecture/project context)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
-- `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions` section (previously answered project conventions)
-- `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section (database and deployment config from prizmkit-init or previous app-planner run)
+- Resolved project instruction target `### Project Conventions` section (previously answered project conventions)
+- Resolved project instruction target `### Infrastructure` section (database and deployment config from prizmkit-init or previous app-planner run)
 
 **Tech stack auto-population from config.json:**
 - If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill tech assumptions.
@@ -277,8 +287,8 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | Checkpoint | Artifact/State | Criteria | Phase |
 |-----------|----------------|----------|-------|
 | **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
-| **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `### Project Conventions` section in `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` up to date | 1 |
-| **CP-AP-1.5** | Infrastructure Checked | Infrastructure config loaded or asked; `### Infrastructure` section in `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
+| **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-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 |
@@ -289,15 +299,13 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 
 ## Generated App-Plan Review Gate
 
-User requirement preserved verbatim: `Add generated-plan review in app-planner also .`
-
 Run this gate before any final handoff whenever the current `app-planner` session wrote or rewrote final app-level planning content. In full produce mode this runs after CP-AP-5.5 and the passing content's final writes; in Quick Context Mode it runs after the confirmed `.prizmkit/plans/project-brief.md` write; in conventions, infrastructure, architecture-decision, or rules-only final-write flows it runs after those writes and before the completion summary. This gate reviews generated planning artifacts directly, not implementation diffs.
 
 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`, selected `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` sections, `.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.
+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.
-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 selected platform instruction file 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.
+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.
 
@@ -306,8 +314,8 @@ Run this gate before any final handoff whenever the current `app-planner` sessio
 After Phase 2, if framework-shaping architecture decisions emerged during planning (tech stack, communication patterns, data model strategies — not individual feature details), read `${SKILL_DIR}/references/architecture-decisions.md` and follow the capture flow. Most sessions will NOT produce architecture decisions — only capture when genuinely impactful.
 
 **How it works**:
-1. If decisions are captured → run the Pre-Generation Headless Context Completeness Gate on each decision, then append passing decisions to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` under `### Architecture Decisions` section
-2. Downstream skills (feature-planner, prizmkit-plan, etc.) read `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
+1. If decisions are captured → run the Pre-Generation Headless Context Completeness Gate on each decision, then append passing decisions to the resolved project instruction target under `### Architecture Decisions`
+2. Downstream skills (feature-planner, prizmkit-plan, etc.) read the current host's project instruction context, so they automatically receive these decisions
 3. Do NOT write architecture decision content directly to `.prizmkit/prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. (The `RULES:` pointer line is managed by Rules Configuration, not by this section.) If the project needs `.prizmkit/prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
 
 ## Project Brief Accumulation
@@ -340,10 +348,10 @@ When the session appears to be ending:
 After CP-AP-6 passes or is reported not applicable, present a summary and end the session:
 
 1. **Summary** (as text): List all project-level artifacts produced:
-   - Project conventions → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions`
-   - Infrastructure config → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` (database conventions + deployment config)
+   - Project conventions → resolved project instruction target `### Project Conventions`
+   - Infrastructure config → resolved project instruction target `### Infrastructure` (database conventions + deployment config)
    - Tech stack assumptions → captured in `.prizmkit/plans/project-brief.md` and reused from `.prizmkit/config.json` when it already exists
-   - Architecture decisions (if any) → `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` `### Architecture Decisions`
+   - Architecture decisions (if any) → resolved project instruction target `### Architecture Decisions`
    - Dev rules (if configured) → `.prizmkit/rules/<layer>-rules.md` (with `root.prizm` `RULES:` pointer)
    - Project brief → `.prizmkit/plans/project-brief.md`
    - 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/architecture-decisions.md

@@ -24,15 +24,9 @@ After Phase 2 (Confirm constraints and tech assumptions), before Phase 3 (Captur
 
 ## How to Capture
 
-1. **Detect platform** — determine which project instruction file to update:
-   - If `.prizmkit/manifest.json` exists, read `platform` and use it as the source of truth.
-   - `codex` → append to `AGENTS.md`
-   - `claude` → append to `CLAUDE.md`
-   - `codebuddy` → append to `CODEBUDDY.md`
-   - `all` → append to all three files. 
-   - If no platform can be determined, skip (no project instruction file).
-
-2. **Check for existing section** — read the target file and look for `### Architecture Decisions` heading:
+1. **Use the resolved project instruction target** — consume the exact current-host target already selected by `SKILL.md` before project-convention discovery. Do not redetect the host, reinterpret manifest identity, or choose from named platform files inside this reference. If the target was not resolved, return to the parent Skill's current-host resolution rule; ask the user when evidence is missing or ambiguous rather than guessing or silently skipping.
+
+2. **Check for existing section** — read the resolved target and look for `### Architecture Decisions` heading:
    - If heading exists → append new entries below it (avoid duplicates with existing entries)
    - If heading does not exist → create it at the end of the file
 
@@ -44,7 +38,7 @@ After Phase 2 (Confirm constraints and tech assumptions), before Phase 3 (Captur
    - Monorepo structure: shared types between frontend and backend
    ```
 
-4. **User confirmation** — before writing, show the collected decisions and ask:
-   > "These architecture decisions were identified during planning. Record them to [AGENTS.md / CLAUDE.md / CODEBUDDY.md]? (Y/n)"
+4. **User confirmation** — before writing, show the collected decisions and the exact resolved target path, then ask:
+   > "These architecture decisions were identified during planning. Record them in `<resolved-project-instruction-target>`? (Y/n)"
 
    If user declines, skip without further prompting.

package/bundled/skills/app-planner/references/brainstorm-guide.md

@@ -75,7 +75,7 @@ Produce a structured summary:
 [2-3 approaches with pros/cons/effort]
 
 ## Selected Approach
-[User's choice + rationale]
+[Complete selected approach and rationale, written as standalone design context without answer tokens or dialogue provenance]
 
 ## Assumptions
 [All assumptions explicitly listed]

package/bundled/skills/app-planner/references/frontend-design-guide.md

@@ -2,7 +2,7 @@
 
 > Create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
 
-**app-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction as decisions in the project instruction file (`AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md`). Downstream implementation skills will consume these decisions when building features.
+**app-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction in the current session's resolved project instruction target selected by `SKILL.md`. Do not redetect a platform or choose a named file in this reference. Downstream implementation skills will consume these decisions when building features.
 
 Load this guide **only when the feature involves frontend/UI work**. Skip for backend-only or infrastructure features.
 

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

@@ -14,7 +14,7 @@ Planning artifacts may be gitignored, untracked, or absent from staged and unsta
 
 - Project brief: `.prizmkit/plans/project-brief.md`
 - Draft brief when present: `.prizmkit/plans/project-brief.draft.md`
-- Project instruction files selected by `.prizmkit/manifest.json`: `AGENTS.md`, `CLAUDE.md`, `CODEBUDDY.md`
+- The exact project instruction target selected for the current session, limited to sections written or changed by app-planner
 - Generated rule files: `.prizmkit/rules/<layer>-rules.md`
 - Prizm docs root pointer: `.prizmkit/prizm-docs/root.prizm` `RULES:` line only
 - In-memory answers, draft brief data, rules configuration answers, or section snapshots captured before writes
@@ -32,7 +32,7 @@ Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whethe
 ## Source-of-Truth Map
 
 - `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, and architecture decisions are source sections in `AGENTS.md`, `CLAUDE.md`, or `CODEBUDDY.md`. If a fix changes user-approved wording or meaning, ask for user confirmation before rewriting.
+- 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.
 - `root.prizm` fixes are limited to correcting or adding the `RULES:` pointer line; do not rewrite unrelated root content.
 
@@ -44,16 +44,17 @@ For every reviewed app-planning artifact or section, check:
 - 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 pointer consistency: generated `.prizmkit/rules/<layer>-rules.md` files are referenced by the `root.prizm` `RULES:` line when rules were configured
-- User-provided wording preservation and detail preservation at matching detail after conversational normalization in project brief ideas, conventions, infrastructure notes, architecture decisions, and rules
-- Every selected product or technical decision is expressed by complete meaning rather than `A`, `B`, `C`, `方案A`, `方案B`, or another unseen option label; whenever the selection originated as shorthand, the original response is preserved inline for traceability
-- Purpose-tagged paths and URLs, screenshots, diagrams, logs, issues, PRDs, and documents; large materials retain title/location, purpose, and task-relevant exact excerpts rather than full-content injection
+- 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
+- Every selected product or technical decision is expressed by complete meaning rather than `A`, `B`, `C`, `方案A`, `方案B`, or another unseen option label; substantive rationale remains durable, while opaque transcript provenance is absent
+- Purpose-tagged stable code, configuration, machine-consumed interface, and URL references; non-code planning/evidence source paths are replaced by inline task-relevant decisions and excerpts, and large materials are bounded rather than injected in full
 - Conversational authorization is excluded when it controls planning but does not constrain implementation; rejected alternatives appear only as necessary non-goals
 - Downstream readiness: `feature-planner` has enough context to produce `.prizmkit/plans/feature-list.json` without guessing core app purpose, stack, constraints, or implementation conventions
 - No implementation/scaffolding actions are introduced by the app plan; outputs stay within app-planner's writable boundary
 
 ## Headless Context Completeness Gate
 
-Repeat the pre-generation simulation for every reviewed new or changed app-planning line or section as if the reviewer has never seen the planning conversation. From the artifact alone, answer:
+Repeat the pre-generation simulation for every reviewed new or changed app-planning line or section as if the reviewer has never seen the planning conversation. First scan all AI-visible fields and sections; machine metadata is exempt, but every generated natural-language value must be session-independent. From the artifact alone, answer:
 
 1. What exact product outcome or technical decision does this content record?
 2. What exists today and what desired state or constraint applies?
@@ -64,20 +65,22 @@ Repeat the pre-generation simulation for every reviewed new or changed app-plann
 7. Does any phrase require an unseen earlier question, recommendation, or option list?
 8. Do quoted source materials agree with the final task decision?
 
-Return `NEEDS_FIXES` if any answer is missing, ambiguous, or dependent on shorthand such as `方案B`, `按推荐走`, `use option A`, `same as above`, or `go with your recommendation`. Accept an expanded decision only when it states complete meaning with inline traceability such as `(original response: "方案B")`. Ask the user for clarification when there is not one provable antecedent. Exclude `所有问题都按你的推荐处理` and equivalent conversational authorization unless a concrete implementation constraint was separately confirmed.
+Return `NEEDS_FIXES` if any answer is missing, ambiguous, or dependent on shorthand such as `方案B`, `按推荐走`, `use option A`, `same as above`, or `go with your recommendation`. Parenthetical notes are part of the artifact and must pass the same fresh-session test. Do not emit transcript annotations such as `(original response: "...")`; raw shorthand is not independently intelligible and materially useful. Ask the user for clarification when there is not one provable antecedent. Treat `所有问题都按你的推荐处理`, `全部按照推荐`, `use all recommendations`, and equivalent blanket recommendation approval as conversational authorization: write the concrete accepted decisions, omit the raw approval, and never repeat it once per accepted recommendation. Do not retain non-code planning-source paths such as `.agents/brainstorm/<note>.md`; copy or normalize the task-relevant content into the durable artifact, which must not depend on that source file still existing.
 
 Apply this stricter gate prospectively to new or changed content and preserve unchanged historical app-planning content.
 
 ### Good and Bad Review Examples
 
-- Bad: `[ ] 使用方案B`; Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`.
+- Bad: `[ ] 使用方案B` or `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`; Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions`.
+- Bad: repeating `(original response: "全部按照推荐")` after each convention; Good: omit the blanket approval after normalizing every accepted convention into concrete meaning.
 - Bad: a bare architecture URL; Good: `Architecture RFC §5 — inspect identity ownership and session boundaries`, plus only task-relevant exact excerpts.
+- Bad: `.agents/brainstorm/design.md — inspect accepted risks` in a final brief; Good: write the accepted risks and resulting constraints inline, then omit the transient planning path.
 - Bad: a rejected serverless alternative listed as an active infrastructure decision; Good: include it only as a non-goal when preserving the selected container deployment boundary requires that fact.
 
 ## Fix Loop
 
 1. Present findings with artifact path, section name, severity, evidence, and suggested source change.
-2. Accept only findings that improve planner correctness, consistency, user wording preservation, or downstream feature-planner readiness.
+2. Accept only findings that improve planner correctness, consistency, substantive meaning preservation, or downstream feature-planner readiness.
 3. Apply accepted fixes to the source representation first: brief draft/checklist, instruction-file section source, rules answer/template source, or `root.prizm` `RULES:` pointer source.
 4. Regenerate or rewrite final artifacts through the same writer path used by app-planner. Do not hand-patch final artifacts as a shortcut when a draft/source representation exists.
 5. Re-read the changed final artifacts directly and repeat the Headless Context Completeness Gate only for changed sections.

package/bundled/skills/app-planner/references/infrastructure-convention-discovery.md

@@ -4,7 +4,7 @@ Detailed Q&A flows for database, deployment, and cloud services conventions duri
 
 ## Infrastructure Section Check
 
-Check `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` for `### Infrastructure` section:
+Check the current session's resolved project instruction target for a `### Infrastructure` section. Consume the exact target selected by `SKILL.md`; do not redetect a platform or choose a named file in this reference:
 
 - If `### Infrastructure` section does not exist → this project was not initialized with prizmkit-init's Phase 4.6. Treat as if both database and deployment are undecided — run full inquiry below.
 - If `<!-- infrastructure: deferred -->` → user explicitly skipped at init time. Ask: "During project init you deferred infrastructure decisions. Would you like to configure them now?" (options: "Yes — configure now (Recommended)", "Skip — decide later")
@@ -105,4 +105,4 @@ After infrastructure inquiry, update the `### Infrastructure` section in the pro
 <!-- If user picked "None" in Round 1, replace this block with: cloud-services: none -->
 ```
 
-Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in the selected project instruction file for `prizmkit-deploy` to pick up later.
+Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in the resolved project instruction target for `prizmkit-deploy` to pick up later.

package/bundled/skills/app-planner/references/project-brief-guide.md

@@ -33,10 +33,10 @@
    - Bad: `[x] User authentication -> src/auth/, src/middleware/auth.ts` because neither the selected behavior nor path purpose is clear
    - This lets future AI sessions locate the implementation without guessing or broad rescanning
 7. **Complete decision meaning**: Every line names the actual product or technical decision. Never write only `A`, `B`, `C`, `方案A`, `方案B`, `按推荐走`, `use option A`, `same as above`, or `go with your recommendation`.
-8. **Traceability**: Whenever a selection originated as shorthand, expand it into meaning and retain the original response inline: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`.
+8. **Artifact-safe normalization**: Every natural-language line, comment, quote, and parenthetical is written for an AI with no planning-session access. Preserve substantive rationale and constraints in durable prose. Do not emit transcript annotations, dialogue-role/chronology labels, question IDs, answer tokens, planning-option recommendation markers, or raw answer-map content; bare selection tokens are not independently intelligible and materially useful exact wording.
 9. **Ambiguous references**: Resolve shorthand only with one provable antecedent. Otherwise ask the user for clarification; never guess.
-10. **Conversational authorization**: Exclude statements such as `所有问题都按你的推荐处理` when they control planning behavior but do not constrain the product or implementation.
-11. **References**: Require purpose-tagged paths and URLs, documents, screenshots, diagrams, and logs. For large materials, retain title/location, purpose, and task-relevant exact excerpts; move confirmed decisions into the brief instead of embedding complete large materials.
+10. **Conversational authorization**: Treat `所有问题都按你的推荐处理`, `全部按照推荐`, `use all recommendations`, and equivalent blanket recommendation approval as dialogue control. Write each concrete accepted default, omit the raw approval, and never repeat it once per accepted recommendation.
+11. **References**: Purpose-tag stable code, configuration, machine-consumed interface, and URL references. Do not retain non-code planning-source paths such as `.agents/brainstorm/<note>.md`, uploads, screenshots, or ad-hoc logs in the brief; copy or normalize the task-relevant content inline so the brief must not depend on that source file still existing. For large materials, retain purpose and task-relevant exact excerpts rather than complete source content, and retain a location only when it is a stable execution-time source of truth.
 12. **Alternatives**: Do not present rejected alternatives as active brief items; include them only as necessary non-goals.
 
 ## Brownfield Init
@@ -93,9 +93,13 @@ Once all criteria are met:
 ### Good and Bad Brief Examples
 
 - Bad: `[ ] 使用方案B`.
-- Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`.
+- Bad: `[ ] Authentication uses organization-scoped OAuth with server-side sessions (original response: "方案B")`; the parenthetical still depends on an unseen option list.
+- Good: `[ ] Authentication uses organization-scoped OAuth with server-side sessions`.
+- Bad: repeating `(original response: "全部按照推荐")` on accepted conventions; omit the blanket approval after writing each convention's concrete meaning.
 - Bad: `[ ] same as above` when several prior decisions exist.
 - Good: ask the user which decision applies, then record its complete meaning.
 - Bad: `[ ] Follow https://example.test/platform-rfc`.
 - Good: `[ ] Deployment uses a managed container service with regional PostgreSQL; Platform RFC §3 — inspect region and failover constraints`.
+- Bad: `[ ] 首期采用通用电商方图；.agents/brainstorm/design.md — inspect accepted risks` because the brief breaks when the planning note is deleted.
+- Good: state the accepted dimensions, deferred platform templates, and accepted risks directly in the brief, with no brainstorm-file path.
 

package/bundled/skills/app-planner/references/project-conventions-discovery.md

@@ -55,5 +55,5 @@ Then ask in text: "Anything I missed that you'd like to standardize?" — if the
 
 ## After Discovery
 
-→ Save answers to `AGENTS.md` / `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
+→ Save resolved convention meanings to the current session's resolved project instruction target under `### Project Conventions` (one standalone domain rule per bullet). Consume the target selected by `SKILL.md`; do not redetect a platform or choose a named file in this reference. Do not copy raw answers, option labels, recommendation markers, question IDs, or dialogue provenance.
 → Output format will naturally vary per project — that is the intended behavior

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

@@ -6,7 +6,7 @@
 
 ## Table of Contents
 
-- [Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)](#phase-2-answer-direct-fill-table-copy-user-answer-text-directly-into-placeholders)
+- [Phase 2 Normalized Semantic Fill Table](#phase-2-normalized-semantic-fill-table)
 - [Trigger Map](#trigger-map)
 - [Rule Block Definitions](#rule-block-definitions)
 - [Template Placeholder Coverage Self-Check](#template-placeholder-coverage-self-check)
@@ -14,7 +14,9 @@
 ---
 
 
-## Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)
+## Phase 2 Normalized Semantic Fill Table
+
+Resolve each selected option or custom reply into the complete semantic value shown by the examples. Never copy raw answer tokens, recommendation markers, question IDs, dialogue labels, or planning chronology into placeholders. The Source column is internal derivation metadata only and never appears in generated rules.
 
 | Template Placeholder | Source | Example Fill |
 |---------------------|--------|-------------|

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

@@ -2,7 +2,7 @@
 
 > This file is read on demand by SKILL.md in Phase 2. The AI must strictly follow the group order defined in this file, asking **one group at a time (1–3 questions)**, never dumping all questions at once.
 > For every question, show the user: question number, question text, options, **recommended choice (marked "Recommended")**, and a one-line description.
-> After each user response, immediately record the choice to internal state `answers[Qx] = ...` and proceed to the next group.
+> After each response, resolve it to the complete option or custom meaning and record that internal-only semantic choice in `answers[Qx]`. Never store raw answer tokens, and never render question IDs or answer-map entries into generated artifacts.
 
 ---
 

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

@@ -6,14 +6,16 @@
 
 ## Table of Contents
 
-- [Phase 2 Answer Direct-Fill Table](#phase-2-answer-direct-fill-table)
+- [Phase 2 Normalized Semantic Fill Table](#phase-2-normalized-semantic-fill-table)
 - [Trigger Map](#trigger-map)
 - [Rule Block Definitions](#rule-block-definitions)
 
 ---
 
 
-## Phase 2 Answer Direct-Fill Table
+## Phase 2 Normalized Semantic Fill Table
+
+Resolve each selected option or custom reply into the complete semantic value shown by the examples. Never copy raw answer tokens, recommendation markers, question IDs, dialogue labels, or planning chronology into placeholders. The Source column is internal derivation metadata only and never appears in generated rules.
 
 | Template Placeholder | Source | Example Fill |
 |---------------------|--------|-------------|

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

@@ -2,7 +2,7 @@
 
 > This file is read on demand by SKILL.md in Phase 2. The AI must strictly follow the group order defined in this file, asking **one group at a time (1–3 questions)**, never dumping all questions at once.
 > For every question, show the user: question number, question text, options, **recommended choice (marked "Recommended")**, and a one-line description.
-> After each user response, immediately record the choice to internal state `answers[Qx] = ...` and proceed to the next group.
+> After each response, resolve it to the complete option or custom meaning and record that internal-only semantic choice in `answers[Qx]`. Never store raw answer tokens, and never render question IDs or answer-map entries into generated artifacts.
 
 ---
 

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

@@ -8,7 +8,7 @@
 
 ## Table of Contents
 
-- [Phase 2 Answer Direct-Fill Table (no derivation needed; copy the user's answer text directly into the placeholder)](#phase-2-answer-direct-fill-table-no-derivation-needed-copy-the-users-answer-text-directly-into-the-placeholder)
+- [Phase 2 Normalized Semantic Fill Table](#phase-2-normalized-semantic-fill-table)
 - [Trigger Map](#trigger-map)
 - [Rule Block Definitions](#rule-block-definitions)
 - [Template Placeholder Coverage Self-Check Table (Mandatory Check Before Phase 4 Rendering)](#template-placeholder-coverage-self-check-table-mandatory-check-before-phase-4-rendering)
@@ -16,16 +16,16 @@
 ---
 
 
-## Phase 2 Answer Direct-Fill Table (no derivation needed; copy the user's answer text directly into the placeholder)
+## Phase 2 Normalized Semantic Fill Table
 
-> These placeholders **don't need rule blocks**. In Phase 4, the AI directly writes the answers collected in Phase 2 into them.
+> These placeholders **don't need rule blocks**. Resolve the selected option or custom reply into the complete semantic value shown by the examples. Never copy raw answer tokens, recommendation markers, question IDs, dialogue labels, or planning chronology into placeholders. The Source column is internal derivation metadata only and never appears in generated rules.
 
 | Template Placeholder | Source | Example Fill |
 |---------------------|--------|-------------|
 | `{{ project_name }}` | Phase 0 auto-read from `package.json` `name` field; if unavailable, ask the user | `robot-svc` |
 | `{{ generated_at }}` | Phase 4, AI writes current ISO date | `2026-05-18` |
 | `{{ project_scope }}` | Phase 0 ask user ("Which directories/subprojects does this spec apply to?") | `apps/web, apps/admin` |
-| `{{ design_source }}` | Q8 answer | `Existing HTML prototype, path temp/` |
+| `{{ design_source }}` | Q8 answer | `Responsive layout, token, and component constraints extracted into this rules document; transient planning source omitted` |
 | `{{ framework }}` | Q1 answer | `React 18+` |
 | `{{ meta_framework }}` | Q2 answer | `Next.js (App Router)` |
 | `{{ package_manager }}` | Q3 answer | `pnpm` |

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

@@ -2,7 +2,7 @@
 
 > This file is read on demand by SKILL.md in Phase 2. The AI must strictly follow the group order defined in this file, asking **one group at a time (1–5 questions)**, never dumping all questions at once.
 > For every question, show the user: question number, question text, options, **recommended choice (marked "Recommended")**, and a one-line description.
-> After each user response, immediately record the choice to internal state `answers[Qx] = ...` and proceed to the next group.
+> After each response, resolve it to the complete option or custom meaning and record that internal-only semantic choice in `answers[Qx]`. Never store raw answer tokens, and never render question IDs or answer-map entries into generated artifacts.
 
 ---
 
@@ -153,13 +153,13 @@ Total: 25 questions.
 
 ## G4 — Design System
 
-### Q8. Primary Design/Mockup Source
+### Q8. Primary Design/Mockup Basis
 - **Options**:
-  - A) Existing HTML prototype in `temp/` directory
-  - B) Existing Figma designs
-  - C) Other location (specify path)
+  - A) Existing HTML prototype committed as a stable project artifact
+  - B) Existing Figma design with a stable accessible URL
+  - C) Other stable execution-time design source
   - D) None, starting from scratch
-- **Note**: If multiple sources exist, select the primary one. Additional sources will be noted in the output. A/B trigger a "design extraction" step (annotate token sources in output). D triggers a "recommend doing a style direction first" hint.
+- **Note**: If a source is transient—such as a brainstorm note, upload path, screenshot path, or temporary directory—extract its relevant layout, token, component, and interaction constraints into the generated rules and omit the path. Retain only purpose-tagged stable code/interface paths or URLs that the execution AI must inspect. D triggers a "recommend doing a style direction first" hint.
 - **Maps to**: `{{ design_source }}` (document header metadata)
 
 ### Q9. Token Naming Layers

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

@@ -2,7 +2,7 @@
 
 > This document was generated by the `frontend-rules` skill on {{ generated_at }}
 > Scope: {{ project_scope }}
-> Design/mockup source: {{ design_source }}
+> Design basis: {{ design_source }}
 > Audience: All human developers + all AI coding assistants on this project
 >
 > **Usage**:

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

@@ -6,7 +6,7 @@
 
 ## Table of Contents
 
-- [Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)](#phase-2-answer-direct-fill-table-copy-user-answer-text-directly-into-placeholders)
+- [Phase 2 Normalized Semantic Fill Table](#phase-2-normalized-semantic-fill-table)
 - [Trigger Map](#trigger-map)
 - [Rule Block Definitions](#rule-block-definitions)
 - [Template Placeholder Coverage Self-Check](#template-placeholder-coverage-self-check)
@@ -14,7 +14,9 @@
 ---
 
 
-## Phase 2 Answer Direct-Fill Table (copy user answer text directly into placeholders)
+## Phase 2 Normalized Semantic Fill Table
+
+Resolve each selected option or custom reply into the complete semantic value shown by the examples. Never copy raw answer tokens, recommendation markers, question IDs, dialogue labels, or planning chronology into placeholders. The Source column is internal derivation metadata only and never appears in generated rules.
 
 | Template Placeholder | Source | Example Fill |
 |---------------------|--------|-------------|

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

@@ -2,7 +2,7 @@
 
 > This file is read on demand by SKILL.md in Phase 2. The AI must strictly follow the group order defined in this file, asking **one group at a time (1–3 questions)**, never dumping all questions at once.
 > For every question, show the user: question number, question text, options, **recommended choice (marked "Recommended")**, and a one-line description.
-> After each user response, immediately record the choice to internal state `answers[Qx] = ...` and proceed to the next group.
+> After each response, resolve it to the complete option or custom meaning and record that internal-only semantic choice in `answers[Qx]`. Never store raw answer tokens, and never render question IDs or answer-map entries into generated artifacts.
 
 ---