# 2026-05-11 — BRIDGE-MOCKUP-004 baseline 假设失效 + D 路线决策

## TL;DR

- backlog/pickup 写 BRIDGE-MOCKUP-004 时假设是 "2 figma-only 漂移 fix (~1-2h)"，baseline 实跑揭露真相："2 missing canonical 实现 (PopupBox + Chart, ~10-15h)"
- A/B/C 路线适用性失败（A 工作量 5x 超估 / B 不适用 status approved / C 脚本不支持白名单）
- User 拍板 **D 路线**：拆独立 canonical entries（CANONICAL-010 + CANONICAL-011）+ `audit:published-vs-code` 保 warn-only 直到两子项完才升 strict
- BRIDGE-MOCKUP-004 entry 重定义为 **tracker entry**（不是单一任务），跨 v0.1.x → v0.2 sprint
- 0.1.1 release 不阻：CANONICAL-009 已是有意义 patch，可立刻 ship 验证 release flow
- **学习**：backlog 写时基于"想象的现状"假设，必须 baseline 实跑后才能定路径；前提一变路径变是常态，不该 fight 假设走

---

## Lineage

```
NPM-003 Phase 1 baseline (2026-05-11, commit 520bb15a)
  └── audit:published-vs-code exit 1, 11 行输出
      └── backlog BRIDGE-MOCKUP-004 entry 写 "2 figma-only 漂移 fix ~1-2h"
          └── pickup §3 第 2 步 plan 基于该假设
              [2026-05-11 next session]
              └── 跑 audit baseline 真相揭露
                  ├── 2 figma-only = Popup Box (2 var) + Chart (6 var)
                  ├── mapping status: 均 needs-implementation
                  └── 工作量真实 ~10-15h, 超 v0.1.1 sprint 5x
                      └── plan owner propose A/B/C/D 4 路线
                          └── user 拍板 D 路线
                              ├── BRIDGE-MOCKUP-004 重定义 tracker
                              ├── 派生 CANONICAL-010 (PopupBox, v0.1.x)
                              ├── 派生 CANONICAL-011 (Chart, v0.2)
                              └── 0.1.1 release 不阻 (CANONICAL-009 已是 patch)
```

---

## 关键决策

### D 路线（vs 原 backlog A/B/C）

| 候选 | 适用性 | 决策 |
|---|---|---|
| A — 实现入库 | ✅ 默认路径 | ❌ 工作量 ~10-15h 超 v0.1.1 sprint 5x；不在本 sprint 做完 |
| B — 设计师删 figma | ❌ status approved + needs-implementation | 不适用 |
| C — audit 白名单 | ❌ status 不是"实验" + 脚本未实现白名单 | 不适用 |
| **D — 拆独立 entries + tracker** | ✅ 务实 | ✅ 拍板 |

**Why D**：
- 把"task entry" 拆成"tracker + child task entries"是 backlog 自然组合（CANONICAL-010/011 各自工作量合理可独立做）
- audit gate warn-only 是**预期状态**（不是 audit bug），由 tracker 维持直到两子项都完
- 0.1.1 release 不需要等大功能（CANONICAL-009 audit 升 strict 本身就是有意义 patch）
- 跨 sprint 推进（010 v0.1.x / 011 v0.2）符合实际节奏

### CANONICAL-010 / 011 拆分顺序

- **010 PopupBox** 先（v0.1.x）：modal/dialog 容器，参考既有 Tooltip/Notification 弹层范式，~3-5h，先验证 modal pattern
- **011 Chart** 后（v0.2）：数据可视化，需 dep 选型（chart.js / echarts）+ API 设计，~6-10h，是大功能

---

## 反模式 / 学习

### Anti-pattern 5 — Backlog 基于"想象的现状"写假设

**现场**：BRIDGE-MOCKUP-004 entry 写 "2 figma-only 漂移修 ~1-2h"，pickup §3 第 2 步基于该工作量假设 plan 整个 sprint。实跑 baseline 才发现 2 figma-only = 2 个 missing canonical 实现 (~10-15h)，差 5x。

**根因**：backlog entry 写时**没跑 baseline**，凭"figma-only 一般是漂移"的范式 prior 假设；pickup 写时未质疑 backlog 假设。

**修正（已落 [memory feedback_baseline-before-plan.md](待写)）**：
- backlog entry 含"工作量估值"时必须标注是 "estimate (假设)" vs "verified after baseline"
- pickup 路径设计前必须 baseline 实跑（即使 backlog 已估）
- 真相 vs 假设差 >2x 时 **STOP + 重新 propose 路线**，不要 fight 走完原路径
- "tracker entry" 是 backlog 自然组合范式：当单一 task entry 工作量爆炸 → 拆 tracker + child entries

### One-shot prompt × tracker entry 组合

CANONICAL-009 那次落实了"一步到位 prompt"反模式 #3。但是 **tracker entry 不是 one-shot prompt 的对立面**——tracker 是 backlog 层组织，one-shot prompt 是 executor 任务层组织。两层独立：

- backlog 层：单一 task entry vs tracker + child entries（按工作量爆炸性决定）
- executor 层：分阶段 prompt vs 一步到位 prompt（按假分阶段触发条件决定）

CANONICAL-010 / 011 各自将走"一步到位 prompt"（同 CANONICAL-009 范式）。

---

## 工程技巧（可复用）

### 1. Tracker entry 范式

适用条件：单一 task entry 工作量爆炸（>2x backlog 估值）且可自然拆分子任务时。

Tracker entry 结构：
- **性质**：明确标 "tracker entry（不是单一任务）"
- **派生 entries**：列子项 ID + 工作量 + 版本归属
- **Resolved 条件**：列出所有子项完成 + 关联 audit gate 升级动作
- **执行链路**：plan owner 起子项 prompts（非同 session）
- **触发查看条件**：用户询 tracker 状态 / 任一子项 commit 完成

实证：BRIDGE-MOCKUP-004 重定义。

### 2. audit gate "warn-only by design" 状态

audit gate warn-only 不只是"基线 FAIL 等修复" — 也可以是**预期长期状态**，由 tracker 维持。RELEASING.md gate 表加备注说明 warn-only 的"由谁维持" + "升级触发条件"（哪个 tracker / 哪些子项完）。

实证：`audit:published-vs-code` 备注添加 "Maintained warn-only until BRIDGE-MOCKUP-004 tracker closed"。

### 3. STATUS.md "Process rule updates" 段累积

STATUS.md "Process rule updates" 段记录每次 backlog/audit/gate 结构性决策（不是每个 task 完成）。一行式简短风格：日期 + 决策类型 + 跳转复盘链接。

实证：2026-05-11 entry "M21/R6" + "BRIDGE-MOCKUP-004 重定义"。

### 4. pickup 修订段 vs 重写覆盖

pickup §3 路径前提失效时，2 个处理路径：
- **重写覆盖**（旧版归 archived/）—— 适合**整个 sprint 路径前提变**（如 v0.1 → v0.2 大方向变）
- **加 Update 段**—— 适合**部分步骤前提变**（如本次 §3 第 2 步变，第 1 步已完、第 3 步仍适用）

本次选加 Update 段（§9）—— 第 1 步 CANONICAL-009 ✅ 已完，第 3 步 0.1.1 release 仍适用，只第 2 步前提变。

---

## Follow-up

| 项 | 状态 | 描述 |
|---|---|---|
| CANONICAL-010 PopupBox | Active v0.1.x | 派生子项 1/2 |
| CANONICAL-011 Chart | Active v0.2 | 派生子项 2/2 |
| BRIDGE-MOCKUP-004 tracker | Active v0.1.1 sprint (不阻 release) | 跨 sprint 跟踪两子项进度 |
| 0.1.1 release cycle 演练 | 待 user 操作 | `changeset:version → tag → push → CI auto-publish` |
| memory feedback_baseline-before-plan.md | 待写 | 本次反模式 #5 学习固化 |

---

## 元说明

- 本复盘对应 STATUS.md Process rule updates 段 2026-05-11 BRIDGE-MOCKUP-004 重定义 entry
- 关联 pickup §9 Update 2026-05-11 baseline 后修订段
- 学习固化到 [memory feedback_baseline-before-plan.md](.claude memory)（如未写则在 next session 起手前补）