@playcraft/cli 0.0.43 → 0.0.46

package/project-template/.claude/agents/refs/developer-phase1-flow.md

@@ -1,136 +1,182 @@
-# Developer Flow — ui_pass + gameplay_pass (L2)
+# Developer Task Protocol — `loop: build`
 
-> **Trigger**: `docs/project-state.md` stage = `ui_pass`, `ui_rework`, or `gameplay_pass`.
-> Agent context + STOP rules: [`../developer.md`](../developer.md).
+> **触发条件**：`npm run state:get -- --json` 披露 `iteration` 1..4 + `loop: build`。只读取其中披露的 `currentRingRequiredFiles`。
+>
+> 本文件不是完整项目执行序列。它是 Developer 在 build loop 中处理当前实现任务的轻量协议。任务可以是一个 Feature、一批相关 bug、一个体验调整或一个 scoped 集成修复。
 
 ---
 
-# Part A: ui_pass (UI shell only)
+## 目标
 
-> **Goal:** Runnable UI matching MC — scene switching, asset binding, simple states. **No core gameplay rules.**
+按照当前 Ring 披露的任务面实现游戏：Ring 1 只完成最小可验证 playable spine、`HOOK` 启动、`window.__playable` 生命周期和首关可胜；它可以是一个动作链路，不应扩张成完整游戏雏形。Ring 2+ 才根据 `state:get` 披露的计划、布局和视觉材料扩展体验。目标始终是达到真实的 `devStatus: ready` + `devUrl`。
 
-## Step 0: Upstream Intake (mandatory)
+**核心原则**：
 
-Read each file; fill **`logs/developer-log.md` § Upstream Intake** before any `game/` edit.
+1. **先 read / load，再写代码**——有现成代码也必须先读。
+2. **每次只做一个 scoped target**——不是串行完成所有 Feature 再交付，而是逐目标推进。
+3. **流程是少返工策略**——Skill 读取、scaffold 采用、placeholder 物化都是为了避免后面重写或猜测。
 
-| Doc                 | You need from it                                   |
-| ------------------- | -------------------------------------------------- |
-| `project-state`     | Wave 2 done, stage `ui_pass`, dev fields           |
-| `design-brief`      | Experience flow scene names (for navigation only)  |
-| `layout-spec`       | Zones, elementIds, assetMapping, atlasPath/frameId |
-| `atom-plan.json`    | Developer atoms, skillRef, dependsOn               |
-| `atom-plan.md`      | Acceptance + Impl Context                          |
-| `style-exploration` | MC panels — primary UI reference                   |
-| `designer-log`      | Palette / motion notes                             |
-| `ta-log`            | Compliance / atlas params                          |
+**资产策略（build 环）**：**能用占位图就用占位图** — 目标是玩法可玩、程序正常执行，不考虑视觉表现力。
 
-## Step 1: Spec Quick-Check (30s)
+严格按三档执行 — **(1)** plan/ref-flow 已 link 的 Skill 资产直接用；**(2)** 合约路径需要静态图片的 → `npm run placeholder:gen`；已 load 的 MP3 路径 → `npm run placeholder:gen-audio`；**(3)** 占位文件不可行的（动态数字、计时文本、纯事件钩子）→ 最小化代码绘制，并在 `developer-log` 记录原因。先读 **`skills/playable-placeholder/SKILL.md`**。详见 [`developer-impl-cookbook.md` § Asset Placeholder Strategy](./developer-impl-cookbook.md#asset-placeholder-strategy-phase-1)。
 
-- Every referenced `elementId` exists in `assetMapping`
-- Gaps → `spec-gap` in project-state → wait for PM
+---
 
-## Step 2: Experience Flow → Code Mapping
+## 入场状态认知
 
-Write to `developer-log.md` — map MC panels to scenes (Hook / Tutorial / EndCard / CTA). See template.
+**你进来时项目已经是这个状态：**
 
-## Step 3: Skill Preflight + Scaffold
+- 当 `state:get` 披露 `docs/atom-tree.json` 时，`meta.selectedAtoms` 对应 skill 文件可能已在 `.claude/skills/<skillRef>/` 下；如果缺失，按当前 Ring 命令补齐，不要提前读取未披露材料。
+- `game/` 目录下可能已有 scaffold 文件或半成品代码，这些是当前项目现实的一部分，不是草稿。
+- scaffold 必须由已披露的 `docs/atom-tree.json` 的 `meta.engineDecision.adapter` 选择。
+- 你的工作起点是**读懂当前项目现实**，而不是从零开始铺代码。
 
-Per `atom-plan.json` Developer `skillRef` entries — read `.claude/skills/<skillRef>/` or CLI fallback; run `playcraft skills scaffold --out ./game` once.
+**Ring 1 scaffold 前置链（legacy：仅在 `state:get` 披露且无 active slice 时执行，不静默覆盖）**：
 
-Fill **`§ Skill Preflight`** in developer-log.
+```bash
+npm run state:get -- --json
+# Must already be produced by the temporary ref-flow atom-selection subagent:
+# docs/atom-tree.json
+playcraft remix init-template --from-atom-tree
+npm install
+npm run verify:contract
+npm run verify:lifecycle
+npm run verify:firstwin
+npm run verify:placeholders
+```
 
-## Step 3b: UI Pass Plan (mandatory before `game/` edits)
+---
 
-Write **`logs/developer-log.md` § UI Pass Plan**:
+## Task Loop
 
-1. **Architecture** — engine, entry, scene flow
-2. **Scene-Asset Binding Plan** — verify every path with `ls`
-3. **Scene navigation** — how Reviewer reaches each MC panel (URL param or button)
-4. **Risk Checklist** — all `[x]`
+Developer 在 build loop 中的工作单元不是"串行完成所有 Feature"，而是逐目标推进。每个目标是：
 
-**Forbidden in ui_pass:** PGS rules, scoring, elimination, win/lose, Near-Win logic.
+- 实现一个 Feature slice
+- 修复一批相关 bug
+- 调整一个体验区域
+- 集成或修复一个运行时表面
 
-Hook validates § UI Pass Plan on STOP.
+### 1. 定义当前目标
 
-## Step 4: Implement UI shell
+- 明确当前目标名称和来源：Ring checklist 项、`docs/implementation-plan.md`（Ring 2+）、review action item、blocker、或观察到的运行时问题。
+- 定义验收信号（什么算完成）。
+- Ring 1 checklist 至少包括：`currentPhase` 初始为 `HOOK`、核心玩法 loop 可执行、`autoPlay()` 推进到 `ENDCARD`、首关必赢、`verify:contract` / `verify:lifecycle` / `verify:firstwin` 通过。
 
-- Bind **real** assets at contract paths (WebP atlas + JSON sidecar)
-- Implement scenes + `index.html` skeleton (see [`developer-impl-cookbook.md`](./developer-impl-cookbook.md))
-- Scene switching only — static/simple interactive states OK
-- Text-as-image per `playcraft-text-rendering` skill
+### 2. 读取相关输入
 
-## Step 5: Dev self-check (ui_pass)
+只读与当前目标相关的材料：
 
-```bash
-npm run dev
-```
+| 输入                                 | 读取条件                                         |
+| ------------------------------------ | ------------------------------------------------ |
+| `npm run state:get -- --json`        | 每次必读                                         |
+| `docs/DESIGN.md`                     | Ring 1+ 披露时（Ring 1 玩法唯一来源）            |
+| `docs/atom-tree.json`                | build 披露时（selected atoms + engine decision） |
+| `docs/implementation-plan.md`        | Ring 2+ 披露时                                   |
+| `docs/layout-spec.md`                | Ring 2+ 披露时                                   |
+| `docs/style-exploration.md`          | Ring 3+ 披露时                                   |
+| 现有 `game/` 代码                    | 改之前必读                                       |
+| `.claude/skills/<skillRef>/SKILL.md` | 当目标涉及该 skill                               |
 
-- All MC-reachable scenes render with real assets
-- No white screen; layout matches zones
-- Record devUrl in developer-log
+> **Ring 1 禁止**读取 design-brief / layout-spec / implementation-plan — Ring 1 不产出这些。
 
-## Step 6: ui_pass STOP
+**Skill / scaffold 判断**：
 
-- `devStatus: ui_ready` (not `ready`)
-- handoff: `Invoke @reviewer ui_diff`
-- **Do not** set mainline `stage`
+- 检查 reference scaffold 和 selected Skill refs 是否已引入项目。
+- 未引入：先阅读参考，判断是否需要引入。已引入：阅读 Skill/scaffold source 和当前代码再改。
+- scaffold 决策记录在 `developer-log.md`：每个 relevant atom 标注 `scaffold-candidate` 或 `skip-with-reason`。
 
----
+### 3. 确认实现边界
 
-# Part B: ui_rework
+- 列出将要改动的文件。
+- 确认现有代码应该被适配而非替换（scaffold 文件 = 项目现实）。
+- 确认当前目标可以作为一个可验证的运行时闭环关闭。
+- 如有 contract 缺失、intent 不明，记录 blocker 并 route upstream。
 
-1. Read `logs/review-report.md` UI Diff section
-2. Fix only Action Items with `routeTo: Developer`
-3. Re-run `npm run dev` → `devStatus: ui_ready` → handoff `Invoke @reviewer ui_diff`
+**场景模块拆分约束**：
 
-If `routeTo: ta` or `designer` — STOP; orchestrator invokes them first.
+- 按职责拆分 `game/`：`gameplay/`（纯逻辑）、`scenes/`（场景壳）、`config/`（常量）
+- 单文件 **≤ 350 行**；超过则拆为子模块
+- 禁止 `cat >` / `cat >>` heredoc 拼接大文件
 
----
+### 4. 实现 scoped 闭环
 
-# Part C: gameplay_pass (core gameplay)
+- 只改当前目标需要的内容。
+- 实现足够的数据、状态、交互、反馈和场景布线，让当前目标在运行时可以被验证。
+- 不要把开发当成 broad UI pass / gameplay pass / final integration pass。
+- 不要用条件分支掩盖没有理解的状态模型或缺失的 contract。
 
-> **Prerequisites:** `uiReviewStatus: passed` (or max ui rework rounds). **Do not rewrite UI layout.**
+**Placeholder 物化**（先读 `skills/playable-placeholder/SKILL.md`）：
 
-## Step 0: Read UI baseline
+- 合约路径需要图片 → `npm run placeholder:gen`
+- 已 load 的 MP3 → `npm run placeholder:gen-audio`
+- Tier 3 代码绘制只用于不可行的场景，记录原因
 
-- Confirm `devStatus` was `ui_ready` / UI diff passed
-- Read existing `game/` scenes — extend, do not replace layout
+### 5. 本地验证
 
-## Step 1: Gameplay Pass Plan (mandatory)
+- 运行最小有意义的检查证明当前目标的运行时闭环工作。
+- Ring 1 objective self-gate（脚本自带 dev server，禁止为跑 verify 而手动 `npm run dev`）：
 
-Write **`logs/developer-log.md` § Gameplay Pass Plan**:
+```bash
+npm run verify:contract
+npm run verify:lifecycle
+npm run verify:firstwin
+npm run verify:placeholders
+```
 
-1. **PGS Strategy** — rules from design-brief + Skill recipe
-2. **First level guarantee** — how tutorial/config ensures win
-3. **State machine** — Hook → Tutorial → Gameplay → EndCard transitions with logic
-4. **Risk Checklist** — all `[x]`
+- 当改动影响运行时接线、场景可达、状态机、资产加载或交互时，用 `npm run dev` 验证。
+- 将 `verify:contract` / `verify:lifecycle` / `verify:firstwin` / `verify:placeholders` 的 pass/OK 结果写入 `developer-log` § Dev self-check。
+- 记录 pass / fail / blocker。
 
-Hook validates § Gameplay Pass Plan on STOP.
+### 6. 更新 developer-log + 状态
 
-## Step 2: Implement GameplayAtom + ConfigAtom
+- 在 `logs/developer-log.md` 记录：当前目标、读了什么、改了什么、验证结果、剩余 blocker。
+- 通过 `npm run state:set -- devStatus=... devUrl=... devBlockers=...` 更新状态。
+- 如果目标完成且还有下一个目标，回到步骤 1。
 
-- Write testCases FIRST
-- Core rules, scoring, Near-Win, CTA handler
-- First level MUST guarantee player success
+---
 
-## Step 3: Dev self-check (gameplay_pass)
+## Ready 判断
 
-```bash
-npm run dev
-```
+只有同时满足以下条件，才能设置 `devStatus: ready`：
+
+- 当前 Ring 的 Feature checklist 没有未解释的空项
+- 所有 `blocked` 项都已经显式进入 `devBlockers` 或 routed upstream
+- 本地运行结果与日志描述一致
+- 当前项目现实下已经达到可交 Reviewer 的状态
+
+Ring 1 handoff：`next_orchestrator_action: "npm run ring:gate -- --iteration 1"`
+Ring 2+ handoff：`next_orchestrator_action: "Invoke @reviewer gameplay_conformance"`
+
+## STOP
+
+- 设置 `devStatus: ready` + `devUrl`
+- 更新 handoff
+- 确认 `developer-log` 能说明：读了什么、Feature 状态、验证结果、blocker
+- 追加 `--- PLAYCRAFT_STOP ---`（`role: developer`）
+
+---
+
+## Ring 4 production integration（TA Wave 2 之后 — mandatory）
+
+After `@technical-artist` STOP with `next_orchestrator_action: Invoke @developer (Ring 4 production integration)`:
 
-- Gameplay loop works; CTA fires; audio loads
-- Record devUrl
+1. Read `logs/ta-log.md` Handoff + Production manifest — wire **every** delivered asset at `assetMapping` paths.
+2. Update `TILE_KEYS` / loaders so all new tiles are referenced — run `npm run verify:asset-code-sync`.
+3. Remove or disable placeholder-only paths; ensure `bg_*` is a clean plate layer (z below tiles/HUD).
+4. Self-check: `npm run verify:ui` + `npm run dev` with `?debug=1`.
+5. STOP: `devStatus: ready` → `next_orchestrator_action: "Invoke @reviewer ui_diff"`.
+
+**Do not** route to `@reviewer ui_diff` until integration is complete.
+
+---
 
-## Step 4: gameplay_pass STOP
+## Rework（`ui_review` 之后）
 
-- `devStatus: ready`
-- handoff: `Invoke @reviewer load_check`
-- **Do not** set Gate #3 or `stage: done`
+Ring 4 verify ui_diff 修复不走完整 build flow。由 [`../developer.md`](../developer.md) 按 routed Action Items 执行 scoped fixes，并 handoff `Invoke @reviewer ui_diff`。
 
 ---
 
-## Shared references
+## 共享参考
 
-- PGS patterns, CTA, atlas binding: [`developer-impl-cookbook.md`](./developer-impl-cookbook.md)
-- Dev ready gate details: [`developer-dev-handoff.md`](./developer-dev-handoff.md)
+- 实现模式：[`developer-impl-cookbook.md`](./developer-impl-cookbook.md)
+- Dev 交接详情：[`developer-dev-handoff.md`](./developer-dev-handoff.md)

package/project-template/.claude/agents/refs/framework-5-component-filter.md

@@ -0,0 +1,252 @@
+# 5-Component Filter 框架 — 机制好玩度快速检验
+
+## 原始来源
+
+- **出处**：https://mcpmarket.com/zh/tools/skills/game-design-framework
+- **性质**：这是一个 Claude Code Skill 中提出的实战框架，并非学术论文。它综合了多个游戏设计理论（MDA、Game Feel 等），形成了一套**快速可操作**的机制评估工具。
+- **关联理论**：
+  - Steve Swink 的 Game Feel 6 组件（Response 对应"实时控制"，Satisfaction 对应"多汁性"）
+  - MDA 框架的 Aesthetics 层（Motivation 对应"目标情感"，Fit 对应"整体一致性"）
+  - Nielsen 的可用性启发式（Clarity 对应"系统可见性"和"匹配现实世界"）
+
+---
+
+## 一、核心思想
+
+5-Component Filter 是一个**快速评估清单**，用于在设计和迭代阶段检验每一个游戏机制是否"好玩"。
+
+它的核心问题是：
+
+> **"这个机制通过了以下 5 项检查吗？如果任一项不通过，它就不会好玩。"**
+
+---
+
+## 二、5 个组件详解
+
+### 组件 1：Clarity（清晰度）
+
+> **核心问题：玩家在 3 秒内能看懂怎么玩吗？**
+
+| 维度             | 检查点                                                |
+| ---------------- | ----------------------------------------------------- |
+| **视觉可见性**   | 可操作对象是否视觉突出？能否一眼分辨什么能点/不能点？ |
+| **动作可猜测性** | 不看教程，玩家能猜到该做什么吗？                      |
+| **反馈明确性**   | 操作后发生了什么——成功还是失败——是否立刻清晰？        |
+| **状态可读性**   | 当前游戏状态（分数、剩余步数、进度）是否随时可读？    |
+
+**评分标准**：
+| 等级 | 描述 |
+|------|------|
+| ⭐⭐⭐ | 零教程可上手，3 秒内理解玩法 |
+| ⭐⭐ | 需要 1 次提示或试错后理解 |
+| ⭐ | 需要文字教程或多次试错 |
+| ❌ | 5 秒后仍不知道该做什么 |
+
+**Playable Ad 中的硬约束**：
+
+> 在 Playable Ad 中，Clarity 是**生死线**。玩家不会花超过 3 秒去"学"一个广告。如果不能即刻理解，就会关闭。
+
+**常见修复手段**：
+
+- 手指引导动画（指示首次操作）
+- 高亮可操作区域
+- 第一步设计为"不可能失败"
+- 减少首屏信息量
+
+---
+
+### 组件 2：Motivation（动机）
+
+> **核心问题：玩家为什么想做这个动作？**
+
+| 维度           | 检查点                               |
+| -------------- | ------------------------------------ |
+| **目标可见性** | 玩家是否知道自己在朝什么目标努力？   |
+| **进度感**     | 每次操作后是否感到"离目标更近了"？   |
+| **奖励预期**   | 玩家是否期待下一个动作会带来好结果？ |
+| **紧迫感**     | 是否有时间/步数/空间等约束驱动行动？ |
+
+**评分标准**：
+| 等级 | 描述 |
+|------|------|
+| ⭐⭐⭐ | 玩家主动想做、停不下来 |
+| ⭐⭐ | 知道该做什么但没有强烈冲动 |
+| ⭐ | 被动执行，缺乏内在驱动力 |
+| ❌ | "为什么我要做这个？" |
+
+**设计策略**：
+
+| 策略         | 机制示例                               | 适用场景   |
+| ------------ | -------------------------------------- | ---------- |
+| **可见目标** | 进度条、目标分数、"消除 30 个红色方块" | 所有类型   |
+| **短期奖励** | 每次匹配后的分数弹出、金币收集动画     | 休闲消除   |
+| **紧迫感**   | 倒计时、步数限制、上升的障碍           | 增加挑战感 |
+| **好奇心**   | 翻转显示隐藏图案、解锁新内容预览       | 探索发现类 |
+| **差一点感** | 失败时显示"还差 2 个就赢了！"          | 转化驱动   |
+
+---
+
+### 组件 3：Response（响应性）
+
+> **核心问题：操作后 100ms 内有反馈吗？**
+
+| 维度       | 检查点                               |
+| ---------- | ------------------------------------ |
+| **即时性** | 触摸/点击后有即时视觉+听觉反馈吗？   |
+| **多通道** | 反馈是否同时涵盖视觉+听觉（+触觉）？ |
+| **比例性** | 反馈强度是否与动作重要性成正比？     |
+| **一致性** | 相同操作的反馈是否每次都一致？       |
+
+**评分标准**：
+| 等级 | 描述 |
+|------|------|
+| ⭐⭐⭐ | 每次操作都有多通道即时反馈，爽快利落 |
+| ⭐⭐ | 有反馈但单通道或有延迟感 |
+| ⭐ | 部分操作无反馈或反馈不一致 |
+| ❌ | 操作后没有任何可感知的变化 |
+
+**这与 Steve Swink 的 Game Feel 直接对应**：
+
+- 100ms 阈值 → 来自 Swink 的"实时控制"组件
+- 多通道反馈 → 来自 Swink 的"润色"组件
+- 比例性 → 来自 Swink 的"多汁性"组件
+
+**快速检查表**：
+
+```
+□ 点击有按下缩放效果？
+□ 松手有弹起动画？
+□ 匹配成功有消除动画？
+□ 消除有音效？
+□ 连击有升级反馈？
+□ 失败有挫败感反馈（但不惩罚）？
+□ 每一帧都有东西在动？
+```
+
+---
+
+### 组件 4：Satisfaction（满足感）
+
+> **核心问题：每次成功操作有"爽"的感觉吗？**
+
+| 维度           | 检查点                                         |
+| -------------- | ---------------------------------------------- |
+| **"啊哈"时刻** | 操作结果是否超出玩家预期？（如意外的连锁消除） |
+| **感官奖励**   | 成功是否伴随视觉+听觉的"爆发"？                |
+| **成长曲线**   | 随着游戏进行，满足感是否在升级？               |
+| **对比度**     | 成功与未成功之间的反馈差距是否足够大？         |
+
+**评分标准**：
+| 等级 | 描述 |
+|------|------|
+| ⭐⭐⭐ | 每次成功都想"再来一次"，有近乎上瘾的满足感 |
+| ⭐⭐ | 成功有正反馈但缺乏"wow"时刻 |
+| ⭐ | 成功与失败的感觉差距不大 |
+| ❌ | 成功了也没什么特别感觉 |
+
+**满足感的层级设计**（对应 Juice 的"连击升级"）：
+
+```
+Level 1（单次匹配）  → 小粒子 + 轻音效
+Level 2（连击 ×2）   → 更多粒子 + 音高上升 + 飘字
+Level 3（连击 ×3）   → 屏幕震动 + 大粒子 + 连击文字
+Level 4（超级连击）   → 全屏特效 + 慢动作 + 欢呼声
+```
+
+> **关键洞察**：满足感 = Response（响应性）× Surprise（惊喜度）。同样的响应如果每次都完全一样，会逐渐麻木。适度的随机性和升级机制维持满足感。
+
+---
+
+### 组件 5：Fit（契合度）
+
+> **核心问题：这个机制与整体风格搭吗？**
+
+| 维度               | 检查点                                 |
+| ------------------ | -------------------------------------- |
+| **与主题一致**     | 机制是否与游戏的视觉主题和世界观匹配？ |
+| **与其他机制协同** | 这个机制是否与其他机制产生有趣的交互？ |
+| **与目标受众匹配** | 机制的复杂度是否适合目标玩家？         |
+| **与平台特性适配** | 机制是否利用了平台的特有输入方式？     |
+
+**评分标准**：
+| 等级 | 描述 |
+|------|------|
+| ⭐⭐⭐ | 机制与整体风格浑然一体、不可分割 |
+| ⭐⭐ | 机制与整体搭配，但有可改进空间 |
+| ⭐ | 机制感觉像是"外挂"上去的 |
+| ❌ | 明显与游戏整体格格不入 |
+
+**Fit 的检查维度扩展**：
+
+| 契合维度   | 好的例子                   | 坏的例子                 |
+| ---------- | -------------------------- | ------------------------ |
+| 主题契合   | 果冻消除游戏用"弹弹弹"动画 | 中世纪骑士游戏用霓虹粒子 |
+| 节奏契合   | 休闲消除的慢节奏配柔和配乐 | 放松游戏用高速闪烁特效   |
+| 复杂度契合 | 休闲广告用单指操作         | 休闲广告用 5 步组合操作  |
+| 平台契合   | 移动端用滑动/点击          | 移动端用双指旋转缩放     |
+
+---
+
+## 三、5-Component Filter 的使用方法
+
+### 方法 1：单机制评估卡
+
+评估一个具体的游戏机制（如"滑动交换两个相邻方块"）：
+
+```
+机制名称: [交换消除]
+┌──────────────┬────────┬─────────────────────────┐
+│ Component    │ Score  │ Notes                   │
+├──────────────┼────────┼─────────────────────────┤
+│ Clarity      │ ⭐⭐⭐  │ 滑动方向=交换方向，直觉  │
+│ Motivation   │ ⭐⭐⭐  │ 可见的目标分数+步数限制  │
+│ Response     │ ⭐⭐    │ 缺少消除音效，需补充     │
+│ Satisfaction │ ⭐⭐    │ 连锁反馈不够强烈         │
+│ Fit          │ ⭐⭐⭐  │ 与糖果主题完美搭配       │
+└──────────────┴────────┴─────────────────────────┘
+最低分: Response (⭐⭐) & Satisfaction (⭐⭐)
+优先改进: 添加消除音效 + 增强连锁视觉反馈
+```
+
+### 方法 2：多机制对比
+
+在 Brainstorm 阶段比较多个候选机制：
+
+```
+          Clarity  Motivation  Response  Satisfaction  Fit   Total
+方案A-滑动交换  ⭐⭐⭐     ⭐⭐⭐       ⭐⭐       ⭐⭐        ⭐⭐⭐   13
+方案B-点击选取  ⭐⭐      ⭐⭐        ⭐⭐⭐      ⭐⭐        ⭐⭐    11
+方案C-拖拽放置  ⭐⭐      ⭐⭐⭐       ⭐⭐       ⭐⭐⭐       ⭐⭐    12
+```
+
+### 方法 3：迭代检查点
+
+在开发过程中定期使用，特别是：
+
+1. **Brainstorm 后**：评估概念是否有基本的好玩潜力
+2. **原型完成后**：第一次可玩版本的快速健检
+3. **Juice 添加后**：确认 Juice 是否真的提升了各项分数
+4. **最终交付前**：确保没有组件被遗漏
+
+---
+
+## 四、快速诊断表
+
+当 QA 或玩家说"不好玩"但说不清原因时，用此表逐项排查：
+
+| 玩家的模糊反馈          | 最可能的缺失组件 | 优先修复方向                       |
+| ----------------------- | ---------------- | ---------------------------------- |
+| "不知道该干什么"        | Clarity          | 加引导动画、高亮可操作区           |
+| "没意思" / "为什么要玩" | Motivation       | 加可见目标、紧迫感、奖励预览       |
+| "操作没感觉" / "卡卡的" | Response         | 加即时反馈、音效、缓动动画         |
+| "赢了也没什么感觉"      | Satisfaction     | 加连击反馈、胜利演出、对比度       |
+| "感觉怪怪的" / "不搭"   | Fit              | 检查主题一致性、节奏匹配、平台适配 |
+
+---
+
+## 五、参考资源
+
+- 🔗 **框架来源**：[Game Design & Mechanics Framework (MCP Market)](https://mcpmarket.com/zh/tools/skills/game-design-framework)
+- 📕 **Clarity 理论基础**：Jakob Nielsen 的 [10 Usability Heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)
+- 📕 **Response 理论基础**：Steve Swink 的 [Game Feel (2008)](https://www.taylorfrancis.com/books/mono/10.1201/9781482267334/game-feel-steve-swink)
+- 📕 **Motivation 理论基础**：MDA 框架的 [Aesthetics Taxonomy](https://www.researchgate.net/publication/228884866_MDA_A_Formal_Approach_to_Game_Design_and_Game_Research)