chore(spec): 综合清理 + legacy-layer 迁移 spec/plan/data
主要改动: - 切到 funplay-cocos-mcp v0.5.1 (用户级配置, 项目级 .mcp.json 删除) - 仓库文档/CLAUDE.md/.gitignore 等清理过时 cocos-mcp-server 引用 - memory 文件同步: cocos-mcp-setup/path/blocker/spriteframe-uuid/prefab-persist 等加 funplay 实测警告 - memory 新建 funplay-cocos-mcp-pending-verification.md (后已被实测覆盖) - spec/plan/data: - docs/superpowers/specs/2026-09-02-legacy-layer-migration-design.md - docs/superpowers/plans/2026-09-02-legacy-layer-migration.md - docs/superpowers/data/layer-spirit-summary.json - YouleNexus: profiles.ts / defaults.ts / PlayerInfoView.prefab / scene 改动 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -84,7 +84,7 @@ A 与 B 互不依赖、可并行；C 必须等两者。
|
||||
|
||||
### 0.4 已确认决策
|
||||
|
||||
- **设计分辨率保持 1280×720 + `fitHeight`** —— 991 个对象的 X/Y **全部 1:1 迁移**，不做任何坐标缩放。现代宽屏由 `fitHeight` 天然获得（20:9 下水平可见区约等于 1600×720）。
|
||||
- **设计分辨率设为 1600×720（20:9 主流移动端比例）+ `fitHeight`** —— 991 个对象的 X/Y **全部 1:1 迁移**，不做任何坐标缩放。旧引擎的 1280×720 降格为**内容区基准**（`DESIGN_WIDTH`），只用于坐标换算、三区锚点推断、满屏/越界判断；设计分辨率画布宽度是**另一个独立常量**（`CANVAS_WIDTH = 1600`），落地时据此设定 Layer/Group 根节点尺寸。20:9 实机 1:1 无缩放，16:9 老设备由 `fitHeight` 收缩画布、Widget 弹性贴边自动适配。
|
||||
- **多帧图切成散图**（1306 张）—— 多帧网格是旧引擎缺图集能力的手工替代品，Cocos 的 Auto Atlas 在构建期自动打包；照搬它等于把引擎缺陷当成新框架的约定。
|
||||
- **同组对象挂同一父节点** —— `GroupList` 覆盖 990/991，是旧引擎用来做整体操作的机制，语义等价于父节点。
|
||||
- **锚点按中心点三区自动推断**，仅水平方向（§2.3）。
|
||||
@@ -208,9 +208,9 @@ tools/ui-migration/intermediate/
|
||||
解法是让父节点**不产生坐标偏移、且与屏幕同尺寸**：
|
||||
|
||||
```
|
||||
Layer 根节点 1280×720，Widget 四边拉伸
|
||||
└─ Group 节点 1280×720，Widget 四边拉伸，position (0,0)
|
||||
└─ 对象节点 §2.2 转换后的绝对坐标
|
||||
Layer 根节点 1600×720（设计分辨率画布），Widget 四边拉伸
|
||||
└─ Group 节点 1600×720，Widget 四边拉伸，position (0,0)
|
||||
└─ 对象节点 §2.2 转换后的绝对坐标（以 1280 内容区基准换算）
|
||||
```
|
||||
|
||||
于是子对象坐标 = 转换后的绝对坐标（无需再减父偏移），其 Widget 锚定的满屏父节点等价于锚定屏幕边界。
|
||||
@@ -224,13 +224,15 @@ x = Left + Width / 2 − 640
|
||||
y = 360 − Top − Height / 2
|
||||
```
|
||||
|
||||
其中 `640`/`360` 是**内容区基准 1280×720 的一半**（`DESIGN_WIDTH / 2`），不是设计分辨率画布 1600 的一半。对象中心 `x = 0` 落在内容区中心，而 Layer/Group 根节点是 1600×720，两者中心重合于屏幕中心——所以居中对象天然居中，靠边对象再由 Widget 贴到画布边缘，无需为画布变宽重算坐标。
|
||||
|
||||
**为何不用 `(0, 1)`（左上）**：那样公式更简（`x = Left − 640`、`y = 360 − Top`）且与旧引擎语义一一对应，但用户明确会**在编辑器里人工审核并修改节点树**，而 Cocos 的编辑器、对齐工具、Widget 全部假定锚点居中。转换公式复杂一点是转换器一次性的成本，人工编辑的别扭是长期成本。
|
||||
|
||||
原始 `Left`/`Top` 存入 `legacy`，回溯对照随时可查。
|
||||
|
||||
### 2.3 锚点推断：只需要水平方向
|
||||
|
||||
**`fitHeight` 下垂直方向永远精确撑满、不会溢出，因此不需要任何垂直适配**——垂直用固定位置即可。这是保持 1280×720 设计分辨率带来的实质简化。
|
||||
**`fitHeight` 下垂直方向永远精确撑满、不会溢出，因此不需要任何垂直适配**——垂直用固定位置即可。这是设计分辨率高度保持 720（与内容区基准高度一致）带来的实质简化。
|
||||
|
||||
水平方向按对象中心点 `cx = Left + Width / 2` 三区推断：
|
||||
|
||||
@@ -240,7 +242,7 @@ y = 360 − Top − Height / 2
|
||||
| `cx > 960` | 靠右 | `right = 1280 − (Left + Width)` |
|
||||
| 其余 | 水平居中 | `horizontalCenter = cx − 640` |
|
||||
|
||||
分界取 1280 的四等分点。这是**机械规则，不追求完美**——用户已确认转换后会逐屏人工审核修正，规则只需「大部分对、且错了容易看出」。
|
||||
分界取**内容区基准 1280** 的四等分点（与设计分辨率画布 1600 无关；`cx`/`Left`/`right` 里的 `1280`/`640` 均指内容区基准）。这是**机械规则，不追求完美**——用户已确认转换后会逐屏人工审核修正，规则只需「大部分对、且错了容易看出」。
|
||||
|
||||
### 2.4 背景：四边拉伸
|
||||
|
||||
@@ -383,6 +385,8 @@ gameabc_*.json ──[Node 转换器]──► 中间描述 55 份 + 散图 1306
|
||||
| 3 | MCP 批量建节点的可行性与耗时（991 节点） | 实测（2026-08-29）：`Login_Layer` 18 节点落地共 **76 次 MCP 调用、约 20 分钟**。`builder.build` 1 次可建整棵树，但 cc.Widget「flag 使能即采纳当前 margin」会按瞬时尺寸污染 margin，需**逐节点 `set_property` 修正**（约 22 次、每次 ~3.5s）。按 991 节点外推仅 margin 修正即需 ~1000 次调用（≈58 分钟纯往返）。**结论：逐节点 MCP 不可行** | 已确认：修 builder 的 Widget 赋值时序（margin 在最终尺寸后设）或写编辑器扩展批量修正，二者取一 |
|
||||
| 4 | 三区锚点规则的实际命中率 | 抽样 5 个界面视觉比对 | 调整分界阈值，或改为逐元素人工标注 |
|
||||
|
||||
> **margin 污染的事后修复方法（2026-08-30 实测确认）**：cc.Widget 四边拉伸下 `contentSize` 是**派生值**（`= 父尺寸 − left − right`），不是自由变量。修正时**必须 `set_property` 设公开属性 `left`/`right`**（触发 setter 正向对齐，`contentSize` 自动跟随）；**切勿 set `_contentSize`**——那会触发 Widget 反算，把刚设好的 margin 打回污染值（`-160`），形成死循环（实测：set contentSize=1600 → 实际返回 1920 且 margin 弹回 -160）。正确路径实测：先恢复 `_enabled=true`，再设 `left=0`、`right=0`，`contentSize` 自动从 1920 收敛到 1600。已落地样板：`should_hide_in_hierarchy`（`left/right=0 + contentSize=1600 + originalWidth=0`），而 `Login_Layer`/`group-2` 污染时 `originalWidth=100`。
|
||||
|
||||
---
|
||||
|
||||
## 6. 非目标（YAGNI）
|
||||
@@ -399,6 +403,6 @@ gameabc_*.json ──[Node 转换器]──► 中间描述 55 份 + 散图 1306
|
||||
## 7. 与其它 spec 的接口
|
||||
|
||||
- **`2026-08-27-ui-asset-and-skin-design.md`**：切出的散图落入其定义的 8 个可覆盖目录；bucket 划分沿用其 §2 规则 3 的目录表；label 样式取自其 §4 的 `theme.fonts`。
|
||||
- **子系统 B（引擎机制映射，待写）**：需要 A 产出的 `legacy.objectId` / `groupId` / `events`；其产出的属性号对照表是 C 的前置。
|
||||
- **子系统 C（平台逻辑移植，待写）**：依赖 A 的 ObjectID → 节点路径全局索引（§1.3）与 B 的 API 映射表。
|
||||
- **子系统 B（引擎机制映射）→ `2026-08-30-legacy-engine-api-mapping.md`**：需要 A 产出的 `legacy.objectId` / `groupId` / `events`；其产出的属性号对照表是 C 的前置。
|
||||
- **子系统 C（平台逻辑移植）→ `2026-08-30-legacy-platform-logic-migration.md`**：依赖 A 的 ObjectID → 节点路径全局索引（§1.3）与 B 的 API 映射表；并定义四层架构映射、状态归属边界、核心流程一致性检查点。
|
||||
- **组件替换 spec（待写）**：`SeatView` / 按人数布局。牌桌内的 `Player_Head_Score_Layer`（60 个对象）由 A 转出静态版本后，该 spec 决定哪些改为按人数动态生成。
|
||||
|
||||
Reference in New Issue
Block a user