对 GitHub 开源 Skill 仓库 fwc-swiftui-skills 中 iPhone Duo 适配规则库的深度拆解： 它是一份 25 条规则的「设计哲学清单」，我们的是一条「扫描 → 改造 → 回归」的工程流水线。 两者定位互补，其中有 7 个规则层的点值得吸收进我们的 skill。
整个 skill 只有两个文件，但结构非常规整：SKILL.md 是入口与摘要，reference.md 是完整规则库。所有内容围绕一条核心哲学展开。
禁用 UIDevice / UIScreen.main / idiom / 方向 / isDuo / isFolded 做布局分支。同一台 Duo 会以外屏、内屏全屏、分屏、不同折叠态出现——布局只能跟随「可用容器空间」。
遇到自适应问题按序尝试：系统导航容器 → 自适应 Grid → ViewThatFits → size class → 精确几何计算（最后手段）。禁止跳级直接用 GeometryReader。
背景与滚动内容可以跨过折痕；按钮、文字、人脸、二维码、拖拽手柄不行。折痕干扰某个元素时局部挪移该元素，不要因为出现折痕就重构整个页面。
全书最严格的一条：hinge.angle 只许驱动物理交互（弯音、游戏、特效），不许用它决定 sidebar、列数、导航折叠——那些永远由可用宽度决定。
不要把内外屏当两块独立画布手动管理。外屏只放「有意为之的附属内容」（提词器、被拍者预览、倒计时），主体验永远挂在主 scene 上。
Duo 模拟器可用之前：可以做通用自适应、去除设备假设、预留 API 边界；不许硬编码猜测的铰链坐标、不许加未验证的 Duo 专属分支。准备优先于投机实现。
FWC 最有操作价值的设计——强制要求 Tier 1 全部完成后才允许提 Tier 2/3。
FWC 面向 SwiftUI 新代码的设计与重构，是一份纯规则书；我们的 skill 面向 存量 UIKit/OC 工程，是一条带扫描器的工程流水线。事实准确性抽查：25 条规则与 Apple 官方 Tech Talks 结论全部一致。
| 维度 | FWC swiftui-iphone-duo | 我们的 ios27-adaptation |
|---|---|---|
| 定位 | SwiftUI 设计哲学：新代码/重构时「应该怎么设计才对」 | 存量工程改造流水线：扫描 → 分级 → 方案 → 改造 → 回归，A 线保命（UIScene/Xcode27）+ B 线增值（Duo） |
| 覆盖栈 | 纯 SwiftUI；不提 UIKit/OC、UIScene 迁移、keyWindow、二进制组件 | UIKit / ObjC / SwiftUI 混合全栈，含组件升级策略（amaze + GitLab + otool 二进制验证） |
| 事实深度 | 较薄：无 SDK 分层行为表、无相机/多屏深度内容、无实测坑 | 很厚：6 部官方视频字幕 + REDoc 内部文档 + iOS 27.2 beta SDK 头文件核对 + halo/campus/Outrline 实测坑 |
| 规则形态 | 强：25 条编号 Agent rule，每条附「错误写法 → 推荐写法」对照 | 分散：规则嵌在 references 的改造模板与坑位记录里，无统一编号 |
| 代码审查 | 9 问决策树 + 12 类红旗清单（含「只测两个宽度」「双份状态」等语义级问题） | 正则级扫描器（P0/P1/P2 + P1-B/P2-B 标记），抓得到 API 误用，抓不到语义问题 |
| 进度约束 | Tier 1/2/3 强制递进：通用自适应没做完，不许提 Duo 专属 API | A 线优先于 B 线有约束；但 B 线内部没有「先通用后专属」的递进约束 ⚠️ |
| 工程配套 | 无扫描器、无回归清单、无灰度策略、无组件管理 | 强：scan_ios27.py + test-checklist.md + 组件版本三步确认法 + 工时估算基准 |
| 宽屏设计观 | 4 条专规：宽屏要更有意义（非更宽）、文本限宽、暴露层级、保持触达性 | 缺失：只讲「怎么不 crash、怎么避让」，没讲「展开后怎么算好」 ⚠️ |
| 状态连续性 | Rule 19 独立成规：布局切换 ≠ 应用状态切换，state 上提到布局层之上 | 仅有反面案例（缓存布局常量），无正面原则 ⚠️ |
⚠️ 标记的三行，正是 FWC 能补给我们的部分。
全部是规则层/流程层的吸收，不涉及推翻现有工程流水线。
reservedRegions / onHingeChange，而这些大多可以用普通自适应解决。.frame(maxWidth: 700)；③ 额外宽度优先暴露层级而非加空白；④ 大屏保持触达性，主操作不许甩到远处角落。isDuo / isFolded / idiom / orientation 分支、固定大 frame、硬编码 sidebar 宽度、固定列数、自建 bar、内容居中跨折痕、compact/expanded 双份状态、只在两个宽度测过。后两项正则抓不到，只能 review 时查。ViewThatFits → size class → 精确几何（最后手段）。我们模板里隐含了这个偏好但没写成显式规则，agent 容易跳级直接上 GeometryReader。FWC 完全不覆盖 UIKit/ObjC——我们的主战场是 OC 存量工程，「用 NavigationSplitView 替代 HStack sidebar」这类建议在 OC 代码里无法直接执行。
FWC 没有扫描器、回归清单、组件升级策略、实测坑库——这些恰是我们最强的部分，不存在可搬的东西。
A 线保命内容（UIScene 强制、statusBar 失效、arm64-simulator、组件版本三步确认）FWC 完全没有，它是纯 B 线 skill。
「复制打勾」式进度跟踪适合小任务；我们的「扫描→分级→方案→改造→回归」五阶段已经更完整，不需要替换。
references/iphone-duo.md 新增三节开头加「三层递进（Tier 1/2/3）」总则；新增「宽屏设计规则」（有意义 > 更宽、文本限宽、暴露层级、保持触达）；新增「状态连续性」（布局切换 ≠ 状态切换，state 上提，反对双份 view 层级）。
SKILL.md B 线任务表前加总则扫描器命中 P1-B/P2-B 时先问一句：「这个问题能否用通用自适应（Tier 1）解决？」能就不碰 Duo 专属 API。同时把排坑决策顺序（系统容器→grid→ViewThatFits→size class→几何）写成显式规则。
references/test-checklist.md B 线段扩充合并 FWC 红旗清单中扫描器覆盖不到的语义项：双份状态、只测两个宽度、宽屏只拉伸；并把 9 问决策树翻译后接为逐屏 review checklist。
SKILL.md 代码纪律段补一条「Duo 模拟器不可验证时，准备优先于投机实现」：允许去设备假设与预留边界，禁止硬编码猜测坐标与未验证的 Duo 分支。