NNN — <Short imperative title>

• Status: TODO
• Commit: <output of git rev-parse --short HEAD when this plan was written>
• Severity: HIGH | MEDIUM | LOW
• Category:
• Estimated scope: <n files, rough size>

各字段职责如下：

- **Status**：初始为 `TODO`，供 `plans/README.md` 的状态表与后续 `reconcile` 操作（把已完成的计划标为 DONE）使用；
- **Commit**：计划撰写时 `git rev-parse --short HEAD` 的输出。它是计划的“时间戳锚点”，是 Boundary 一节中 drift 检测规则的判据；
- **Severity**：沿用 [SKILL.md](https://gitcode.com/GitHub_Trending/rea/react-bits/blob/d71509062d8adbd97a43035a94d0ebdaf154b5cf/AGENTS/SKILLS/improve-animations/SKILL.md?utm_source=gitcode_repo_files#L74) 的三级定义——**HIGH** = 破坏手感（UI 上用错缓动、高频/键盘操作上有动画、掉帧、`scale(0)`）；**MEDIUM** = 明显不对（transform-origin 错误、动态 UI 不可中断、缺 reduced-motion 处理）；**LOW** = 打磨项（stagger、模糊遮罩淡入淡出、令牌整合）；
- **Category**：来自 [AUDIT.md](https://gitcode.com/GitHub_Trending/rea/react-bits/blob/d71509062d8adbd97a43035a94d0ebdaf154b5cf/AGENTS/SKILLS/improve-animations/AUDIT.md?utm_source=gitcode_repo_files) 的八大审计类别（Purpose & frequency / Easing & duration / Physicality & origin / Interruptibility / Performance / Accessibility / Cohesion & tokens / Missed opportunities）；
- **Estimated scope**：涉及文件数与粗略体量，服务于按 leverage（影响 ÷ 成本）排序。

## Problem：逐行定位 + 代码原文引用

`## Problem` 一节要求回答“哪里错了、为什么影响产品手感”，并且有两条硬性格式要求：

- **每个位置必须引用为 `path/to/file.tsx:123`**（文件:行号）；
- **必须逐字附上当前代码**，例如模板给出的示例：

```css
/* src/components/dropdown.css:14 — current */
.dropdown { transition: all 400ms ease-in; }

注意这个示例本身就是一个“教科书级反例”：transition: all 是 AUDIT.md 第 5 类（Performance）中“永远是 finding”的写法，400ms 超过了 UI 动画 300ms 的预算，ease-in 则是第 2 类（Easing & duration）中“在 UI 上出现就是 finding”的缓动。一份高质量的计划，其 Problem 一节应当让执行者在未读任何其他材料的情况下，就能通过 file:line 找到代码、并确认当前状态与计划撰写时一致。

这与 SKILL.md Phase 3 的审计纪律呼应：Never present a finding you haven't confirmed at its file:line——没在 file:line 处亲自复核过的发现不允许出现在计划里。

Target：把每一个值写死，禁止“换个好看的缓动”

## Target 一节定义精确的终态，模板的原文要求是“Every value spelled out — curves, durations, spring configs, media queries. Never 'use a nicer easing'”。模板给出的示例：

/* target */
.dropdown {
  transition: transform 200ms var(--ease-out), opacity 200ms var(--ease-out);
  transform-origin: var(--radix-dropdown-menu-content-transform-origin);
}

这个示例恰好与 AUDIT.md 中的“精确值目录”一一对应——计划中的每一个数值都必须从 AUDIT.md 抄录而来（模板 Notes 一节：“Pull every value from AUDIT.md — never approximate from memory”），而不是凭记忆近似：

• 强自定义缓动令牌（内置 CSS 缓动对刻意设计的动效来说太弱）：

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* strong ease-out for UI */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);    /* strong ease-in-out for on-screen movement */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);     /* iOS-like drawer curve */

• 时长预算（UI 动画不超过 300ms）：按钮按压反馈 100–160ms、Tooltip/小弹层 125–200ms、下拉/选择器 150–250ms、模态/抽屉 200–500ms、营销说明类可以更长。

react-bits 仓库本身就是这套惯例的活体示例：src/css/variables.css 中定义的令牌与 AUDIT.md 推荐值完全一致：

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);

--dur-press: 120ms;
--dur-tooltip: 160ms;
--dur-menu: 200ms;
--dur-panel: 280ms;

时长令牌甚至全部落在 AUDIT.md 的预算区间内（press 120ms ∈ 100–160ms、tooltip 160ms ∈ 125–200ms、menu 200ms ∈ 150–250ms、panel 280ms ∈ 200–500ms）。而 src/css/transitions.css 中的页面过渡 transition: opacity 300ms var(--ease-out) 则展示了“只动 opacity + 令牌化时长与缓动”的标准写法——这类已存在令牌与先例，正是计划中“仓库惯例”一节要指给执行者模仿的范本。

Repo conventions to follow：模仿仓库自己的做法

计划必须告诉执行者“这个代码库是怎么做这件事的”，并给出一个应被模仿的 exemplar（样板），包括令牌命名、文件位置、props 模式。模板示例：

## Repo conventions to follow

- Easing tokens live in `src/styles/tokens.css`; add new curves there, e.g. `--ease-out: cubic-bezier(0.23, 1, 0.32, 1);`
- <exemplar file:line that already does this correctly>

这对应 SKILL.md Recon 阶段的约定勘察：“plans must extend these, not invent parallel ones”——计划要扩展既有的 easing 令牌、时长标度与 spring 配置，而不是发明一套平行的新令牌。AUDIT.md 第 7 类（Cohesion & tokens）也把“五个手写的、几乎一样的 cubic-bezier”直接判为整合型 finding。以 react-bits 为例，新增曲线应落在 src/css/variables.css 的 --ease-* / --dur-* / --transition-* 区块，并仿照 src/css/transitions.css 的消费方式，而非在某个组件的 CSS 里硬编码新曲线。

Steps：一步一个具体编辑

## Steps 一节的要求是“One concrete edit per step: file, what changes, resulting code”——每一步只对应一个具体编辑：文件、改什么、改完后的代码。这保证了执行者不需要做任何跨步骤的推理或自行拆解。

Boundaries：四条防越界规则

边界一节防止执行者“顺手”扩大改动范围，模板固定给出四条：

## Boundaries

- Do NOT touch <files/components out of scope>.
- Do NOT change markup/structure — motion properties only (unless a step says otherwise).
- Do NOT add new dependencies.
- If a step doesn't match the code you find (drift since the commit stamp), STOP and report instead of improvising.

前两条把改动限定在“只动 motion 属性、不动标记结构、不碰范围外文件”；第三条禁止新增依赖（与 SKILL.md 的 No mutating operations 一致）；第四条是全模板中最有工程味道的一条——drift 熔断：如果执行时发现的代码与计划步骤不符（即自 Commit 字段记录的头以来代码已漂移），执行者必须停下来报告，而不是即兴发挥。这也正是 reconcile 调用变体（重新核对 plans/ 与当前代码、刷新过期的 file:line 引用、淘汰已修复的发现）存在的原因（见 SKILL.md）。

Verification：机械校验 + 手感校验，缺一不可

验证一节要求同时给出两类检查，且“手感校验不是可选项”：

## Verification

- **Mechanical**: <exact commands — typecheck, lint, build — with expected outcome>.
- **Feel check**: run the UI, trigger <interaction>, and confirm:
  - <observable check, e.g. "the dropdown scales from its trigger, not from center">
  - <e.g. "spamming the toggle never restarts the animation from zero">
  - In DevTools, set playback to 10% (Animations panel) and confirm <detail>.
  - Toggle `prefers-reduced-motion` (Rendering panel) and confirm movement is dropped but opacity feedback remains.
- **Done when**: <machine- or eye-checkable completion criteria>.