joywayerandClaude Opus 4.7
3039daf903
早期 CLAUDE.md 把原则 A / B 描述为"地位对等"，本次升级：原则 A 是
**第一准则**，地位高于原则 B。两者冲突时无条件选 A、压力让原生 Swift
端承担，哪怕代码看起来过时。
原则 A 新增三个子节：
A.1 已经被否决的 / 永远不要再提出的方案：
- "H5 改一行"（哪怕只是把读 app_xxx 挪到 DOMContentLoaded 之后）
- "H5 改一个文件"（哪怕只是改成 if-undefined 守卫）
- "H5 加一个 polyfill"
- "H5 调整调用时机"
- "新桥接口"
唯一例外：项目方主动要求改 H5 时
A.2 替代方案 = 原生 Swift 端硬扛：
- 回到原 msext 老路（哪怕是写文件 / 轮询等"现代不推荐"模式）
- 接受技术不优雅：B 对 A 让步
- 不要"等 H5 改了再优雅化"自我安慰
A.3 判定流程：写代码前问"方案要 H5 改任何东西吗？" → 是则立即否决
「两条原则的交叉判定」段同步修订：A > B（不再地位对等）。
新增典型案例 3「app_* 注入时序问题」记录本轮：
- 调研发现 WKUserScript 无法 1:1 等价 msext 的"loadFileURL 前写文件"
- 我错误地提出 A/B/C 三方案，其中 A/B 要求 H5 配合改动 → 违反原则 A
- 正确做法：方案 C，原生 Swift 回到 msext 老路 writeToFile
- 教训：WKUserScript / evaluateJavaScript 不是万能药；遇时序冲突
回到旧路径不要为了"现代"而牺牲契约
下一步等用户确认后：撤回 §7.5 路径调整（commit 246f215），把 Design
重新指回 AppDataWriter 写文件方案 + 代码层落地实施。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>