ColorYourModel — 通往「可用 v0.1」开发路线图（正式版 · REVISE-1）

如何使用本文档：从 §3 Phase 0 开始逐项勾选。每个 Gate 必须产出二值结论 + 失败分支，未达 EXIT 不得进入下一 Phase。每完成一个 Phase 追加一条 loop-journal.md 条目。

0. 当前看板（滚动更新 · 2026-08-10）

当前等待需求方复验（多类，均需真实 Tauri runtime / 切片器，headless 不可覆盖）：

1. 智能分区效果 — 装甲人偶经 eac4a64（默认 curvatureKMeans）+ 82b7366（crease 45°）应拆成 ~7–10 个分区（头/躯干/臂/腿），不再是 89 区 / 1 整块。
2. 阶段进度条 + 转圈（b1d523c）— 点「智能分区」应看到「阶段 X/Y · 名称」+ 旋转环，不再出现"卡死/无反馈"。
3. Lasso 第 3 点（71e8d34）— 胸前细电缆上连续点 3 点：第 3 点应正常放置、不误报黄色"ready to close"；只有点回起点顶点附近才变黄闭合。
4. Sphere.stl 导入不再崩（69a17ea）— 安装最新 NSIS，打开 samples/_src/Sphere.stl 确认不闪退。
5. Gate 0b 预设库复验 — 在切片器打开 examples/paint_color_sample.3mf：下拉框 Snapmaker U1 (0.4 nozzle)、喷嘴 0.4、工艺 0.20 Standard、spool 卡完整；首次弹 "Customized Preset" 确认框属正常。
6. (不阻塞) D6-a 非静默预览 UI — 可下轮排。

1. 产品裁决记录（Phase -1，已完成 ✅）

2026-08-06 由用户裁决。这些是后续所有技术方案的前提，不得单方面推翻。

D6-a（附加约束，非新增需求，而是 β 失败模式的必要补丁）：量化不得静默。导出前必须展示映射结果——原始色数、目标槽位数、每个槽位由哪些原色合并而来、以及一张合并前后对照预览。用户确认后才写文件。理由：工具的核心承诺是「所见即所得」，β 在切片器里改色而用户不知情会直接摧毁这个承诺；把改动摊开则 β 的代价从「欺骗」降为「知情妥协」。

2. 技术前提（已经 REFUTE 校验，含被推翻的原始判断）

2.1 三个 P0 由同一次「删除式重构」解决 —— 但删除清单需扩到五处

原判断（「删两个阈值 + fill 改 click 即可」）被 REFUTE 推翻。穷举「决定填哪些面 / 高亮哪些面」的全部代码路径后，实际需要删除五处，缺一则 Phase 2 复验必不通过：

后端口径已验证一致，无需改动：fillSegment 传 segmentId = overrideSegmentId ?? segmentLabels[faceId]（usePaintTool.ts:32-69）→ fill_segment_paint（commands/paint.rs:116-132）→ fill_segment 按 filter(|&label| label == segment_id) 收全段（fill.rs:14-26）。前端 facesBySeg（Viewport.tsx:466-478）同样纯按 segmentLabels 分组。两端唯一真值都是 segment_labels。

这满足 backlog M5 的「必须换角度」要求：过去 7 轮都在修补 hover 传递链路，本轮是移除 hover 的决策权。删除比统一更彻底 —— 没有第二条路径，就不会再次分叉。

B1（HUD 与屏幕高亮不同源）仍须先修：即便一致性成为结构性保证，回归验证仍需可信读数。Gate 0a 保留。

2.2 D2 的代价：高亮渲染性能 —— 原方案 β 已被推翻

SegmentHighlight（Viewport.tsx:591-610）在 useMemo 中同步重建 geometry：150 万面 → 5400 万次 Array.push + 216MB Float32Array 分配 + 全量 computeVertexNormals()，全在主线程。这才是 giantSegmentIds 静音存在的真实原因。

REFUTE 修正两点：

• ✅ SegmentOutline（:528-574）成本更低不是更高：它遍历面找「邻面 label 不同」的边界边，单段覆盖全模型时不存在边界边，直接返回 null。§2.2 只算 Highlight 的数量级是对的。
• ❌ 方案 β（indexed BufferGeometry）不可行：主 geometry 是非索引展开式（Viewport.tsx:13-23 构建注释、:1064-1068 明确保持 geometry.index === null），每三角形独占 3 顶点。在非索引 buffer 上建 index 等价于 [0,1,2,...]，省不下任何东西。要真省必须先做顶点去重映射，而这会破坏 faceIndex === 后端 face 序号 这个前提，使 indirect:true 的 BVH raycast 优化（:942-963）失效。

修订后的候选方案（Gate 0d 决策）：

2.3 D4 取证结论：「拆分」已实现，缺口仅「合并」

H1 证实 — finalize_manual_region（src-tauri/src/segment/manual.rs:578-582）无条件覆写 mesh.segment_labels[f] = label，源码注释明写 "faces may belong to an earlier region"，并以 ManualRegionSnapshot 记录原 label 供撤销。paint_segment_face（commands/segment.rs:122-123）同理。

→ 用户用套索/分区笔在任意已有分区内圈一块，该块 label 被覆写，原分区自动少掉这部分。功能上就是拆分。

H2 证实 — src-tauri/src/commands/ 下无任何 merge / split / relabel 命令，合并需从零实现。有利条件：SegmentsPanel.tsx 已存在，store 已有 selectedSegment 单选态（:13/:33），Viewport 已消费其高亮（:1797-1801）。

REFUTE 澄清（原判断为误解）：rebuild_segments（mesh/model.rs:332-367）只用 segment_labels 重建 segments，全程不触碰 face_colors → 合并不会丢失用户涂色。且后端 Segment.color（:351-360）是死字段，全前端无一处读取。原文档「保留目标分区的 label 与颜色」的表述应删除。

2.4 新发现缺陷：面板配色与 3D 配色不同源（docs/04 未收录）

后端 segments.sort_by_key(|s| s.id)（model.rs:365）。auto 段 id 连续为 0..n-1 时 i == id 属巧合一致；一旦出现手动区（id ≥ 100000，当前已可复现）或 Phase 3 合并造成 id 空洞，i ≠ id → 面板色点与 3D 分区颜色错位。

处置：统一为 segId % len，纳入 Phase 3，并补录进 docs/04。

2.5 撤销架构：存在两套互不同步的栈（R4 级架构决策，必须前置）

两者不互斥但不同步：lasso 落笔时 pointerdown 已 pushUndo 一份前端快照，finalize 又 push 一份后端 snapshot —— 同一次操作在两个栈里各留一条记录，谁先弹出取决于用户按了哪个入口，栈深还不一致。

原文档把「合并的撤销走哪套」写成「二选一（依 0c 结论）」并留在 Phase 3，违反 R4：这是前后端历史语义的架构决策，不是性能实测的下游产物。0c 只能回答「全量快照能否撑 150 万面」，回答不了「两套栈如何归一」。→ 前移为 Gate 0b'。

2.6 D2 条件性依赖 Gate 0c（原文档遗漏的依赖）

D2「整段填充不降级」是最大 undo 快照的唯一来源：一次填充可改动全模型面数。pushUndo 每次存全量 face_colors（appStore.ts:341-345），150 万面 ≈ 18MB/次 × 19 层 ≈ 340MB 常驻；撤销时 restoreFaceColors（useTauriCommand.ts:184-200）用 Array.from() 把整个数组转 JSON 数字过 IPC → 单次承载 450 万个十进制数。

D2 的论证前提是「有撤销兜底」。若 0c 实测不通过，该前提当场崩塌。因此 0c 必须写明失败分支，见 §3 Gate 0c。

2.7 Phase 1 与 Phase 3 的渲染契约冲突（原文档遗漏）

selectedSegment（appStore.ts:31，单值 number | null）与 hoveredSegment（:34）共用同一个 SegmentHighlight 组件，靠视图模式分流：paint 视图渲染 hovered（Viewport.tsx:1786-1789），segment 视图渲染 selected 并在 hovered ≠ selected 时额外画一条 hovered 的 Outline（:1795-1805）。

Phase 1 的全部工作是把决定权收敛到一个面集，而 Phase 3 要把 selectedSegment 扩成多选集合 —— segment 视图里会立刻重新出现「选中集 N 段」与「hover 集 1 段」两个面集，且 :1803 的 hoveredSegment !== selectedSegment 判等在集合语义下恒真（number !== Set）。

若放任到 Phase 3 再处理，等于亲手重建刚拆掉的「两个面集」结构。→ 渲染契约改造前移为 Phase 1c，Phase 3 只填数据。

2.8 色彩域基数差：本工具 RGBA 任意 vs 切片器 ≤16 槽位（Gate 0b 新发现，R4 级）

这是 A9 的真正拦路石，此前所有文档均未记录。

导出不是「格式转换」，而是有损映射：必须先把 N 种面色量化到 ≤16 个槽位，再把这 16 个颜色写进 Metadata/project_settings.config 的 filament_colour。

三条候选策略，代价与语义差别很大：

倾向 α（v0.1 范围最小、语义最诚实，且失败信息可直接指导用户），但 R4 要求用户确认后再动代码。

3. Phase 执行计划

Phase -1 — 裁决门 ✅ 已完成

• D1–D5 全部裁决（§1）
• README 四处失真校正（commit 9bbc9ff）
• 路线图 PLAN 版落盘（commit a5c4e51）→ REFUTE → 本 REVISE-1

Phase 0 — Gate 阵列（六项，全部产出二值结论 + 失败分支）

前置修复（必须最先做）：P1-8 render 期副作用（2 处）。✅ 已完成（550289e）

⚠️ 本条原立论已被证伪，修正如下：原文写「会让 0c/0d 实测不可复现」。查 React 官方文档后确认，StrictMode 在 DEV 下对 useMemo 工厂函数是确定性二次调用——测量值是可复现的，但被稳定放大约 2×。危害性质从「不可复现」变为「系统性偏高」，是准确性风险而非复现性风险。两者应对手段不同：前者靠稳定化，后者靠剥离观测干扰。

• 移除 render 期 ref 写入 2 处（useMesh.ts baseGeometry / paintColorArray），后者改用 useLayoutEffect 在 commit 后发布
• 新增测量逃生舱：VITE_NO_STRICT=1 时关闭 StrictMode，令 0c/0d 的内存与耗时反映生产行为
• DoD：npx tsc --noEmit exit 0；vite build 通过；cargo test --lib 13 passed

Gate 0a — 校准 HUD 仪器（B1）✅ 已完成（8ea2217）

三重分叉：HUD highlighted 取 facesBySeg.get(targetLbl).length（Viewport.tsx:1183，含 click 回退与复活值），屏幕高亮取 store hoveredSegment 且过 giantSegmentIds（:1786-1788）→ iter25–30 六条「决定性证据」不可采信。

采用解法：引入唯一真源 memo renderedHighlightLabel，覆盖 segmentView / hover / 巨块过滤三条分支；overlay JSX 与 HUD 同读该 memo，使「屏幕画的」与「HUD 报的」在结构上无法分叉。

• overlay JSX（paint view :1786、segment view :1797/:1803）改读 renderedHighlightLabel
• HUD 增打 renderedHover=（屏幕真正高亮的 label，null 显式打出）与 fillTarget=
• HUD 仅在 fillRouting === "segment" 时断言 MISMATCH——local 笔刷与 whole-region 洪泛设计上就与高亮不等，此前对它们报 MISMATCH 属误报
• enqueuePaint 快照 renderedHover，与 hoveredSegment 分开存，保留「所见高亮 vs 实际填充目标」的差值可见性
• DoD：npx tsc --noEmit exit 0；vite build 通过

Gate 0b — 3MF 格式前置验证（从 Phase 4 前移）🔴 结论：A9 按现设计不可达

调查已完成，结论比原预期严重。证据分两层：规范层（3MF Consortium 官方规范）与实现层（本机 OrcaSlicer 源码 C:\workDir\programing\OrcaHunSe\OrcaSlicer，逐条 grep 亲验）。

B1｜规范层缺陷（4 条，均已确认）

B2｜实现层：basematerials 在 OrcaSlicer 中零读者

grep -ri "basematerial|displaycolor" OrcaSlicer/src/libslic3r/Format/   →  No matches found

覆盖 3mf.cpp / bbs_3mf.cpp / AMF / STL / OBJ / STEP 全部导入导出器。即使把 B1 四条全部改对，OrcaSlicer 仍然一点颜色都读不到——规范正确性与目标切片器可用性在此处不是同一件事。

B3｜语义层（决定性）：OrcaSlicer 的颜色模型是「挤出机槽位」，不是 RGB

两条私有通道，均为逐三角面属性，不是材质引用：

编码规则（Model.cpp:3478 get_triangle_as_string + TriangleSelector.cpp:1648 serialize，源码注释明写 "changing it may break backwards compatibility"）：十六进制 nibble 串，未细分叶三角面状态 n 编码为 [0,0] + （n<3 时 2 bit / n>=3 时 [1,1] + base-15 的 4-bit 块），nibble 内 bit 序小端，字符串前插。实测推导：

EnforcerBlockerType（TriangleSelector.hpp:13）枚举为 Extruder1..Extruder16——存的是槽位序号，不是颜色。真实颜色由 filament_colour 决定，落在 Metadata/project_settings.config（Orca/BBS，bbs_3mf.cpp:580）或 Metadata/Slic3r_PE.config（Prusa 路线，3mf.cpp:73）。

⛔ 由此产生一条 R4 级产品约束（阻塞，需用户裁决）

ColorYourModel 允许用户涂任意多种 RGBA；OrcaSlicer 只能表达 ≤16 个槽位。这不是 bug，是两个色彩域的基数差。要让颜色真正显示，必须补一个量化步骤（N 种面色 → ≤16 槽位）+ 写调色板进 config。量化策略属产品决策，见 §2.8。

• 规范逐条比对（B1 四条）
• 目标切片器实现层亲验（B2、B3）
• §2.8 已裁决（D6 = β 自动量化） → threemf.rs 解冻，改造清单如下

改造清单 v1（7 项，D6 驱动）— 已被 REFUTE-3 部分推翻，见下

REFUTE-3 裁决表（2026-08-07，双路独立证伪 + 我方亲验仲裁）

两个独立 agent 分别对上表证伪；结论冲突处由我在两份源码上亲验仲裁（投票制）。

由裁决产生的 5 条硬约束（写进实现，逐条对应单测）

改造清单 v2（REVISE 后，按可交付性重排）

REFUTE-4（2026-08-07，需求方二轮反馈「箭头指的地方」驱动）

需求方二轮实测：project_settings.config 扩到 41 字段（b10bd20）后，spool 卡仍 Bed type 空 / Diameter 显示 <<mm / spool 名截断。需求方原话「缺少 resources」精准——缺的是 embedded preset files（ORCA 的 resources）。派独立 Explore subagent 在双基线（Snapmaker fork bbs_3mf.cpp + 上游 stock）复核 _extract_project_embedded_presets_from_archive，推翻 4 点：

前缀常量逐字节相同（Metadata/machine_settings_ / process_settings_ / filament_settings_ / print_setting_），读取端纯 istarts_with 前缀，.config 不需 [Content_Types].xml 注册。无 m_is_bbl_3mf 门禁。

REVISE：export/project_config.rs 拆为 4 类 builder（build_project_settings_config 仅留 name/from/version + *_settings_id 引用；build_machine/process/filament_profile_config 承载 machine/process/filament 元数据）+ 常量 + 10 单测；threemf.rs 改为写 project + 1 machine + 1 process + N filament 共 6 + N 份 config。cargo test --lib 26 passed；examples/paint_color_sample.3mf 解包验证 12 entry 全绿（6 份 filament 预设名唯一、含正确 settings_id、无 obsolete 字段）。

• 失败分支已触发：格式需重写，单列子任务，不阻塞 Phase 1/2

REFUTE-6/7（2026-08-07，预设库实现前证伪，2e4e070 落地）

需求方需求升级：导出时可选厂商/机型/工艺/耗材，3mf 打开即识别为 Snapmaker U1 + 0.4mm 喷嘴（不依赖用户已装 Snapmaker vendor profile）。实现前派独立 Explore subagent 审计 SnapMakerOrcaMain 源码 + 双基线交叉验证，推翻两个关键假设：

IMPL（2e4e070）：tools/extract_orca_presets.py（vendor 索引白名单 → 265KB snapmaker_u1.json：4 变体/30 工艺/113 耗材）；presets.rs（OnceLock + ExportSelection::resolve 悬空名报错）；project_config.rs 重写（扁平 config + inherits_group + selected/generic 双路径）；threemf.rs 3 参签名（selected 写 6 entry 无 filament 文件）；前端 ExportDialog（厂商→机型→喷嘴→工艺→每槽耗材→目标切片器）+ zustand persist lastExportSelection。cargo test --lib 66 passed（含 selected-export zip 往返断言）；verify_3mf.py 解包：printer_settings_id 相等、machine 78 keys 含 start gcode、inherits_group 8 元素、无 @slotN。

• 待需求方复验：切片器打开新 examples/paint_color_sample.3mf → 下拉框 Snapmaker U1 (0.4 nozzle)、喷嘴 0.4、spool 卡完整。首次弹 "Customized Preset" 确认框属正常（validate_presets 对非 system 预设的行为，勾选"不再提醒"）

Gate 0b′ — 撤销架构归一决策（R4 级，见 §2.5）✅ 已裁决（D7 + D8）

书面契约（用户已确认，2026-08-06）

REVISE-2 — 实现方案经双路独立证伪后的修正（2026-08-06）

实现草案（begin/end_stroke 协议 + 统一 FaceDelta + 一律增量回传）被两个独立 agent 分别攻破，两者独立收敛到同一处根因，故按投票制采纳。修正如下：

证伪中被确认成立、不需改的部分（同样重要）：

• Segment 完全可从 segment_labels 推导 —— name 是 format!("Region {}")、color 是 label 的哈希（model.rs:340-357），全仓无重命名/改色命令。故 label 的就地 swap + rebuild_segments() 能完整恢复分区的新建与消失。⚠️ 前提：一旦将来加「重命名分区」，Segment 即变为非派生态，本方案当场失效，必须同步改造。

• 颜色链无过期覆盖风险 —— paintColorArray 的 useMemo 依赖 [meshData?.faceColors, meshData?.faceCount] 两个引用均不变 → 永不重算；paintColorRef.current 就是该 memo 的返回值本身，patch 缓存等同 patch memo。

• 自反演（swap）+ 笔画内去重（保留首次 prev_color）组合正确，正反用皆成立。

• 复用 AppState 那把唯一的 Mutex 无死锁（无嵌套加锁）；load_model 整体替换 model，历史天然为空。

• DoD：契约成文并经用户确认（R4 满足）

• REVISE-2：实现方案经双路独立证伪并修正

• 实现 S1（后端）：mesh/history.rs + 8 个写命令接 stroke_id + undo/redo 命令 + 单测（5c85e80）

• 实现 S2（前端）：切到后端 undo，删除 pushUndo 等 8 项 + PaintSnapshot + 退役 restore_face_colors / manual_region_undo（7522659 + 7eaef39）

• 实现 S3：Gate 0c 实测校准（backlog：待需求方确认撤销交互后迭代）

Gate 0c — A6 大规模撤销实测（性质已变更）

D8 裁决后，0c 由「决策门」降为「验收实测」。原设计让 0c 去回答「全量快照撑不撑得住 150 万面」；D8 已直接选定增量 diff，该问题作废。0c 现在的职责是验证 0b′ 契约的实现真的达标，并把契约里暂定的栈深 50 / 内存 256MB 校准成实测值。

• 前置：0b′ 契约实现落地（后端增量 diff + 前端 pushUndo 下线）— 5c85e80/7eaef39/7522659，命名/合并/拆分均已接入时间线且可撤销
• 150 万面模型 + Fill 大分区，VITE_NO_STRICT=1 下实测 10 次撤销 + 10 次重做的单次耗时与进程内存峰值
• DoD：单次 undo/redo ≤ 200ms；50 层栈满时进程增量内存 ≤ 256MB；输出实测数字
• 失败分支：调低栈深上限（50 → 实测可承受值）并在 UI 明示；仍不可行才 回退重裁 D2

Gate 0d — 高亮性能方案落地（升级为 Phase 1 前置必做，见 §2.2）✅ 已完成（方案 α）

• 确认 β(indexed BufferGeometry) 不可行：主 geometry 非索引展开式，建 index 等价于 [0,1,2,...] 省不下任何东西，且会破坏 faceIndex === 后端 face 序号 前提（indirect raycast 失效）；γ/δ 同理被 α 取代
• 方案 α 落地（eea2fd1）：主材质 onBeforeCompile 注入 uHighlightLabel/uHighlightColor + per-vertex aSegLabel（non-indexed 几何，面 f → 顶点 3f/3f+1/3f+2 同值）；<color_fragment> 后 0.45 mix；hover 切换 O(1)。删 SegmentHighlight/FillFaceHighlight/giantSegmentIds/WHOLE_SEGMENT_MAX_SHARE/emptySet
• 性能优化（485aa7d，经 /adversarial-development-loop REFUTE 证伪 P1 全局 demand / P2 gl_PrimitiveID / P3 Uint32）：条件性 demand（IdleFrameloop，静止 1.5s 切 demand，任意交互唤醒）；删 preserveDrawingBuffer:true；aSegLabel varying 加 flat
• 工具门控（f192f98）：高亮仅 fill|picker|segment 工具计算；其余工具 renderedHighlightLabel 返 null → uniform -1 短路，消除 brush 拖涂 60fps 重渲染风暴
• DoD：tsc --noEmit exit 0；vite build 631 模块通过；cargo test --lib 67 passed。视觉一致性 + 卡顿消失待需求方装包复验（见 §0 待复验清单）
• 失败分支（已规避）：α 与主题色/vertexColors 耦合风险经 onBeforeCompile chunk 注入化解；若未来自定义 ShaderMaterial 冲突再回退 δ

Gate 0e — 切片器环境可获得性（新增，见 D3）✅ 通过

开发机实测已安装（C:\Program Files\）：

⚠️ 基线更正（2026-08-07，REFUTE-3 发现，原记载完全反了）

原文写「OrcaHunSe\OrcaSlicer 是上游 OrcaSlicer 源码；SnapmakerOrca 本机无源码」。两句都错：

后果：IMPL-1 记录的 Gate 0b 全部「实现层证据」取自 Snapmaker fork，却被标注为上游。已在 stock 上逐条复验（见 §Gate 0b REFUTE-3 裁决表），结论大部分仍成立，但槽位上限一条被推翻。双基线源码此后均可亲验，无需黑盒。

• DoD：二值结论 = 可获得，D3 双基线维持不变，无需降级

Phase 1 — 删除式重构（解决 P0-1 / P0-2 / P0-3）

Gate 0a（仪器）、0d（性能方案）→ 两者均已完成。本 Phase 实际落地与 §2.1 字面方案有偏差（见下），但 D1/D2 语义目标已达成（hover 降级为纯视觉提示、整段填充不降级）。本 Phase 需单独 REFUTE 已不阻塞 —— 实现已过且需求方将装包复验。

1a — 统一 hover 语义（「所见」侧稳定）✅ 已完成（7b74707）

• 替换 iter30 v7 过度粘性守卫（if (!(prevIsManual && lbl < MANUAL_SEGMENT_OFFSET))）：改为真实区域一律接管高亮；仅光标落极小碎面 crumb（faceCount < max(16, 总面数*0.001)）才允许手动段保持粘性（覆盖 seg=0 碎片误填，不阻挡正常区域切换）
• 加 segmentFaceCount 映射（id→faceCount）；加陈旧清除 effect（标签不在 segmentIds 立即清空）；无命中时 nextHover = null
• 删 lastValidHoveredSegmentRef 复活逻辑（§2.1 #5）
• 手动验证：hover 手动区 A → 移到 auto 区 B → 高亮立即切到 B；移出模型 → 高亮消失（需求方多轮实测无粘滞回归，迭代 35 后 hover 始终跟随光标）

1b — 收敛 fill 决策 + 删闸门 ✅ 基本完成（eea2fd1 + 早轮 !opts?.wholeRegion 改动）

• fill 目标权威源已为 segmentLabels[faceId]（早轮 usePaintTool.ts 改 !opts?.wholeRegion && label !== undefined，同时删 !!seg 与 realSegs.length > 1 —— §2.1 #2/#3）
• 删除 WHOLE_SEGMENT_MAX_SHARE / MANUAL_REGION_MAX_SHARE 常量及引用（§2.1 #3 配套）；删除 giantSegmentIds 及 autoSegs.length <= 1 早退（§2.1 #4，原依赖 0d —— 现 0d 已完成故已删）
• SegmentHighlight/FillFaceHighlight（几何重建叠加）已删，高亮改走方案 α 着色器（Gate 0d）；hover 不再压制 giant 段
• lastValidHoveredSegmentRef 复活通路（§2.1 #5）已在 1a 一并删除；Viewport.tsx sticky 块经 1a 重写为 cursor-follow
• 手动验证：Fill 整段 = 高亮整段，HUD 无 MISMATCH（需求方实测 fill 整段填充，无"高亮 A 填 B"反馈；A4 系统复验仍留 Phase 2）

1c — 渲染契约前置改造（为 Phase 3 铺路，见 §2.7）✅ 由 0d 方案吸收，无需再做

原任务是把 SegmentHighlight/SegmentOutline 入参从 selectedSegment: number 改成集合，为 Phase 3 多选铺路。Gate 0d 已删除这两个几何重建组件，高亮统一走着色器 uniform（hover/选中都写 uHighlightLabel，不存在"两个面集"），§2.7 描述的叠加冲突被方案 α 结构性化解。

• SegmentHighlight/SegmentOutline 几何重建组件已删（eea2fd1），无"入参改集合"对象
• 「选中集 + hover 段」叠加规则由着色器 uniform 承载（Viewport.tsx 渲染单 label），无恒真判等残留
• 选中集未进持久化（SegmentsPanel 多选为本地 state，见 SegmentsPanel.tsx），P1-6 条件门未触发
• 结论：1c 关闭，Phase 3 直接落地（见下）

Phase 1 DoD：

• npx tsc --noEmit exit 0（持续通过）
• cargo test --lib 不回退（≥13，现 103）
• HUD 无 MISMATCH（需求方实测无"高亮 A 填 B"反馈；A4 系统复验仍留 Phase 2）
• 同步更新 PRD：FR-PNT-02（取消半径降级）、FR-PNT-03（click 权威）— ⚠️ PRD 仍未同步（当前 PRD 仍是旧语义），待补

Phase 2 — 复验 A4 / A5

• A4：150 万面模型，分别在 auto 大分区、auto 小分区、手动区、单一真实分区模型上 Fill，HUD 四次均无 MISMATCH
• A5：笔刷光标环位置 == 着色位置，无偏移
• EXIT：A4 通过；若仍不一致，停止打补丁，派 REFUTE 重新取证（不得进入第 9 轮同思路修补）

Phase 3 — 分区合并（D4）✅ 已完成（并入智能分区泳道）

撤销架构（0b′）与渲染契约（1c）已在上游关闭；实现 f7d2f83（合并）+ 72455f3（拆分）+ 39736dd（命名）已全部落地并通过需求方实测。

• 后端 merge_segments(target_label, source_labels)：重写 segment_labels + rebuild_segments()（f7d2f83）
• 后端单测（普通合并 / 含手动区 / 单分区入参 / 空入参 / 越界 label）
• SegmentsPanel 多选交互 + 「合并」按钮（Ctrl+点击多选 + mergeInto 动作）
• 按 0b′ 契约接入撤销（label-only 历史，增量 diff）
• 修复 §2.4 配色不同源：SegmentsPanel.tsx 改为按 seg.id % len 取色，与 useMesh.ts:96 统一（788f7b9）
• DoD：cargo test --lib 13 → ≥18（现 103）；tsc exit 0；合并后撤销能完整还原
• 拆分（D4 取证「拆分已具备」的强化）：split_segment 沿内部棱角拆成多区，可撤销（72455f3 + 阈值滑块）
• PRD FR-SEG-03 同步：当前 PRD 中 FR-SEG-03 仍是「分区元数据双写」旧条目，未补合并语义（Event-driven：选中 ≥2 分区触发合并 → 归并为单一分区保留目标 label）⚠️ 待补

Phase 4 — 3MF 收口（A9）

Gate 0b 已排除格式层风险，0e 已确认环境，此处做真实规模验证。

• 真实彩色模型导出 3MF → OrcaSlicer 打开验色
• 同一产物 → SnapmakerOrca 打开验色（若 0e 判定不可获得则跳过，A9 降为单基线）
• DoD：基线全部通过，截图存档

Phase 5 — 发版收口

• A1 / A2 / A3 / A7 / A8 逐条实测（此前未系统走过完整清单）
• B1 npx tsc --noEmit exit 0
• B2 cargo test --lib 全通过
• B3 npx tauri build --bundles nsis 产出 setup.exe + 便携 exe，冒烟启动
• CHANGELOG 补齐（当前实际停在 Round 3-4）
• docs/04 缺陷清单状态回填 + 补录 §2.4 新缺陷
• 打 tag v0.1.0（本仓库第一个 tag）

4. v0.1 验收清单（判定「可用」的唯一依据）

B3 例行化（backlog M6）：NSIS 构建在 journal 中已多次成功，属低风险，归入「每次提交必跑」例行项，不与 A9 捆绑为发版门槛。

5. 范围与技术债对照表

纳入 v0.1

分区合并（D4 → A10）；§2.4 配色不同源修复（Phase 3）；P1-8 render 副作用（Phase 0 前置，因其污染 Gate 测量）；P1-3 addUpdateRange 截断（与 0d 同一战场，合并在同批 buffer 改造中完成，避免重复改同段代码）。

排除 v0.1（附理由）

条件门与技术债

6. 变更记录