--- description: 审计 Ailoha iOS 前端重构认知体系是否足够，并把 Release、main 与本地候选的结论拆开 status: request_changes updated: 2026-08-28 sources: - repo://ailoha-agent-iOS@5e6ac6e41c53780c85808c92290d2bd38f809123 - repo://ailoha-agent-iOS@0b90745ed21438b194f8f9401a47d012cdbe66e5 - repo://ailoha-agent-iOS@6922f359ad08da70242e4ec0c5c4a1486bc2908d - https://github.com/Ailoha-ai/ailoha-agent-iOS/compare/0b90745ed21438b194f8f9401a47d012cdbe66e5...6922f359ad08da70242e4ec0c5c4a1486bc2908d - https://reports.cubxxw.com/ios-frontend-refactor-map/ - brain://reports/ios-frontend-refactor-map/README.md - brain://reports/ios-frontend-refactor-map/current-main-accessibility-runtime-baseline-2026-08-28.md - brain://reports/talent-signal-dynamic-island-pilot-2026-08-27/README.md - https://app.notion.com/p/3caa444a6c0081d987a0dc871c7e5688 confidence: high sensitivity: internal --- # iOS 前端重构认知体系：完成度与 Revision 审计 ## 2026-08-28 successor：current main 完整架构已补齐 本页原先的最大缺口已经关闭：不再只靠 GitHub compare 推断 current main。本轮在独立临时目录中固定并完整遍历 clean snapshot `main@6922f359ad08da70242e4ec0c5c4a1486bc2908d`，没有读取或修改用户正在工作的 iOS checkout。 - `fact`：当前树有 771 个 Swift 文件、163,172 行 Swift；其中主 App 350 文件 / 98,552 行，`AilohaShared` 22 / 7,000，Widget 6 / 2,703，Notification Content 1 / 605，12 个本地 Package 合计 341 / 37,673。 - `fact`：完整运行图已经覆盖 `AilohaApp → RootPage → MainTabPage`、typed route、Task/Home/Contact/Calendar owner、REST + ARPC、App Group、Widget/Live Activity/App Intent/Notification extension、12 个 Package 和当前测试边界。见 [current main 递归架构](current-main-recursive-architecture-2026-08-28.md) 与 [可探索图](current-main-architecture.html)。 - `fact`：12 个 Package suite 共 `74/74` 通过；7 个定向静态/生命周期检查通过；当前 main head 有一条成功的 Xcode Cloud Archive。它们分别证明 package 行为、已枚举合同和可归档性，不能替代 App 生命周期、真机性能、可访问性或跨进程 replay。 - `fact`：Release/main 工程仍没有 App unit/UI test target；共享 scheme 仍指向不存在的 `ailoha-assistant-sharedTests.xctest`。 - `inference`：旧的 `main-delta` 不再是“current main 架构本体”，而是 Release → main 的变化说明；`5e6` 继续是历史机制地图。 - `boundary`：Chat 与 Contact 已补 Debug Simulator 页面路径，多图和 Calendar 已补机制实验；登录页已补最大 Dynamic Type、Reduce Motion 与运行语义树。仍没有真机 Release ETTrace、生产分布、memgraph、双账号、spoken VoiceOver 全旅程或真实 extension suspension。因此局部运行机制可称事实，生产影响仍待反证，不能写成线上事故。 因此下表里“深度遍历”和“递归架构”的静态 current-main 缺口已从 compare-capped 更新为**完整源码树闭合、运行证据仍未闭合**。这段 successor 是对 2026-08-27 审计的追加修正；下文历史判断保留，便于追踪结论怎样变化。 ## 2026-08-28 successor：登录入口可访问性从推断推进到局部运行闭环 - `fact / positive`：Debug Simulator 运行语义树能发现 Google、Apple 与 Legal agreement 三个产品动作，协议状态有 `Not agreed` value。 - `fact / Dynamic Type`：Large 与 AXXXL 都是 40 个语义元素、6 个目标、0 个滚动区域；品牌字体适配器使用 fixed size。登录入口没有形成最大字号行为已经由代码与运行共同支持。 - `fact / Reduce Motion`：开启偏好后一秒间隔的画面变化主要集中在视频区；播放器无条件播放并循环。登录背景不尊重 Reduce Motion 已闭合。 - `unknown`：这不是 spoken VoiceOver 走查；Debug 空白 target 是否进入 Release、协议链接顺序、alert 焦点、账号内旅程与真机仍未知。 因此“可访问性完全没有运行验证”的旧状态已失效；新状态是 **登录入口局部验证、全 App 仍未闭合**。执行合同见[登录入口可访问性运行基线](current-main-accessibility-runtime-baseline-2026-08-28.md)，包含三个最小改造颗粒、8 张状态截图、3 段未剪视频与明确 fail 条件。 ## 2026-08-28 successor：产品 / 设计判断已绑定 current-main revision 本轮又关闭了一类更隐蔽的误读：过去的对齐页同时引用了历史 Figma、2026-06-22 飞书和不同代码 revision，却把其中一部分 Release / 历史实现写成 current main。 - `fact / current main@6922f359`：Chat 只构造 V2；旧 `TaskChatPage.swift`、`ChatPageDebugFlags.swift` 已不存在，旧 rollout cache 会在启动时清理。 - `fact / current main@6922f359`：可见底部导航只有 Task / Contact / Calendar；Discover 仍可被 Router 表达，但不是 visible tab。 - `fact / current main@6922f359`：Onboarding 有 12 个可恢复 route；问卷输入表面已经收缩为姓名，不是整个 Onboarding 只剩一页。 - `fact / current main@6922f359`：颜色 manifest → generated Swift → Widget consumer 已成立；`ALHColors` 的 legacy adaptive accent 仍并存，因此是部分迁移，不是“完全没有共同来源”，也不是“已经全部收口”。 - `unknown / Figma`：2026-08-28 fresh read 被 Professional View-seat MCP 调用额度阻断。`2391:25876` 只能继续作为 2026-08-11 的历史视觉证据，不能称 current target。 这些事实由 [产品 / 设计 / 代码对齐](product-design-alignment.md) 与[机器审计收据](evidence/current-main-product-design-alignment-2026-08-28/product-design-alignment-audit.json)固定。它们证明“旧判断需要按 revision 拆开”，**不证明当前产品设计正确、设计 owner 已接受，或用户已经喜欢。** 跨电脑执行和截图 / 视频验收入口已整理到 [Notion 重构验收控制面](https://app.notion.com/p/3caa444a6c0081d987a0dc871c7e5688)。 ## 一句话结论 现有材料已经能教人理解旧前端的主要控制面、问题机制和重构方法，但**还不能叫“当前 iOS 前端的完整重构依据”**。真正的第一缺口不是少列了几个问题，而是 `Release`、`main` 与本地实验分支被混成了一个“当前架构”；同一句结论在三条代码线上可能分别是“仍存在”“已经迁移”“只在本地候选修过”。 所以现在最先要修的不是再加一百张问题卡，而是给每条判断补上 revision 身份：**它描述哪条代码线、在哪个 commit 观察、什么证据能让它失效。** ## 三条事实线 | 事实线 | 固定修订 | 它能回答什么 | 不能冒充什么 | |---|---|---|---| | 当前 Release | `Release@0b90745`，2026-08-25 | 当前 Release 分支还保留哪些产品与工程合同 | 不能代表 `main` 正在形成的下一版结构 | | 当前 main | `main@6922f35`，2026-08-27 | 当前集成方向、已删除旧路径和新增 package 边界 | 未进入 Release 的代码不能写成线上或发布事实 | | 本地候选 | `codex/ail-727-ios-refactor@5e6ac6e` + 大量未提交改动 | Wave 0 hardening、hosted tests 等候选是否在本机通过 | 不能代表 Release、main、PR、CI 或生产已集成 | `fact`：旧架构地图固定在 `5e6ac6e`。它与当前 Release 已经分叉：Release 相对共同祖先多 60 个提交，旧地图分支也有 7 个 Release 不包含的提交。它与当前 main 的分叉更大：main 多 148 个提交，旧地图仍有 7 个 main 不包含的提交。 `fact`：当前 main 以当前 Release 为祖先，额外多 88 个提交。GitHub compare 返回 300 个文件条目并命中端点上限，变化横跨 Home、Task/Chat、Onboarding、Design System、Import、Logging、Speech、TwoMeet 与测试包。 `fact`：本机的 `origin/main` / `origin/Release` 跟踪引用仍停在更旧的提交；本轮用 `git ls-remote` 与 GitHub commit API 重新核对后，远端分支头仍是上表的 `6922f35` / `0b90745`。因此后续 revision 审计不能只读本机 `origin/*`，必须先向远端确认分支头。 `inference`：这组变化足以移动多个架构与问题结论，不能按“小版本增量”直接继承旧地图。 `inference`：旧地图仍有学习价值，但它现在是**历史机制地图**，不是无条件的 current architecture。未经 revision 复核的问题，不应直接进入排期、重构或验收。 ## 原目标完成到哪里 | 用户要的能力 | 当前状态 | 已有证据 | 还缺什么才闭合 | |---|---|---|---| | 深度遍历 iOS 前端代码 | current-main 静态树已闭合；运行仍条件性 | clean `main@6922f359` 已完整盘点 771 个 Swift 文件、4 个产品、12 个 Package，并沿启动、导航、Task/Chat、Contact、Calendar、REST/ARPC、App Group/Extension 和测试边界下钻 | 真机运行、账号切换、性能、内存、无障碍与跨进程 suspended replay；后续 revision 仍需增量刷新 | | 可递归展开的架构理解 | current main L0–L4 已建立 | `current-main-recursive-architecture-2026-08-28.md` + `current-main-architecture.html` 是当前完整入口；`recursive-architecture.md` 是 5e6 历史，`main-delta` 是变化说明，目标图仍是候选 | 真实运行 trace、具名 owner 接受的目标合同，以及分支前进后的 freshness 复核 | | 代码、Figma、飞书对齐 | current-main 代码侧已按 revision 闭合；产品设计侧仍未闭合 | Chat、三 Tab / dormant Discover、dark-only 运行行为、12-route Onboarding、部分 token migration、Live Activity 政策缺口已绑定 `main@6922f359` 和机器收据；历史 Figma 节点、飞书 iOS 索引与十个子文档仍保留来源时间 | 当前 Figma revision / successor、2026-06-22 飞书的具名 successor、design owner 对三 Tab、主题、Onboarding、token 语义与 Live Activity 政策的接受；旧节点生命周期仍是 unknown | | 合适颗粒度的问题清单 | revision claim ledger 已建立 | 21 个 P0/P1 已补 `applies_to`、`observed_at`、`invalidated_by`、责任角色与 verifier state，并接入网页卡片；新增 REL-002 固定 Onboarding 页面字段、配置 required 与提交 version 的合同缺口 | canonical Linear issue / assignee 仍未绑定；REL-002 的 DEV/生产响应、5 张截图与 2 段未剪视频仍缺 | | 性能优化判断 | 四条 P0 工程切片已有机制证据；生产定级仍未闭合 | Chat 5000 行单条更新、Contact 1k/5k Notes 下姓名输入已有 3×3 Debug 页面复现；多图 10×48MP 与 Calendar 1k/10k 有独立机制实验。Contact 已从“可能 fan-out”升级为“12 次按键触发 12 次 Notes 全量投影”的运行事实 | 固定 Release/最低支持真机/同 fixture 的 SwiftUI、Time Profiler、Hangs/Hitches、内存 before/after；生产 history/notes/events/图片分布 | | 可访问性判断 | 登录入口局部运行闭合；全 App 未闭合 | current main 登录页已有 Large/AXXXL、Reduce Motion on/off 对比帧和运行语义树；最大字号未进入品牌字体、背景视频忽略 Reduce Motion 已形成代码 + 运行证据；三个核心动作可发现 | Release + spoken VoiceOver；账号内 Home/Chat/Contact/Calendar；真机；按 8 图 3 视频合同验证改后版本 | | App 级可靠性证明 | 未闭合 | current main 的 12 个 Package suite `74/74`、7 个定向静态/生命周期检查、Xcode Cloud Archive 通过；本地 Wave 0 另有 hosted candidate | Release/main 工程仍无 App unit/UI test target；Package、Archive 与本地候选都不能替代集成后的 App 行为证据 | | Agentic E2E 闭环 | 有基础设施和部分场景 | 本地 E2E runner、case manifest、若干验证记录 | 九类关键表面统一的可复验旅程、失败恢复和产物索引 | | Talent Signal 先行验证 | 比较材料和执行工具已放行，真实实验未开始 | Gate 0 独立复核 GO；Gate 1 冷读工作台在修正曝光与保存问题后 GO；灵动岛业务场景、ActivityKit 实施合同、迁回 Ailoha 的问题卡与视频合同已形成 | 当前仍是 0/8 招聘者样本，没有视觉赢家；未实现 ActivityKit、未录真实 Showcase 视频，也不能外推 Ailoha 生产链 | | 团队冷读与行动 | 执行工具完成，真实结果 0/3 | Notion 问题页已改成人话因果链；[5 分钟团队冷读评测器](coldread-runner.html) 固定三类角色、六项理解门、致命 revision 误读、匿名本机保存与 JSON/CSV 导出，自动合同检查通过 | 真实产品/iOS/新人各 1 人完成同一场“定位—复述—首个动作—反证”测试；三场原话与主持人评分仍缺 | | 网页公网访问 | 本轮入口与关键资源已闭合 | 稳定入口为 [reports.cubxxw.com/ios-frontend-refactor-map/](https://reports.cubxxw.com/ios-frontend-refactor-map/)；2026-08-28 重新发布后，总页、Onboarding 合同 Markdown/JSON 与 Talent Signal 实施总包均返回 HTTP 200；1280×900 与 390×844 均无横向溢出、无控制台 warning/error；问题目录初始为 30/30，搜索 `REL-002` 精确收敛到 1/30 | 公网可访问、筛选正确和资源可读不能替代团队冷读，也不能证明 iOS 实现、DEV/生产响应、真机性能或生产效果 | | 进入整体重构 | 尚未满足 | 已有演进式方案与 Wave 0 保护候选 | revision-aware coverage、App tests、运行性能/a11y、迁移删除合同与人工确认 | ## 六个已经改变判断的技术颗粒 ### 1. Chat 双轨：Release 仍开，main 已删 - `fact / Release`：`Router.swift` 仍读取 `ChatPageDebugFlags.useChatPageV2`，在 `TaskChatPage` 与 `TaskChatPageV2` 之间选择。 - `fact / main`：`TaskChatPage.swift` 与 `ChatPageDebugFlags.swift` 已删除；Router 只构造 `TaskChatPageV2`。 - **原问题怎么改写**：`MIG-001` 不是“全项目仍双跑”，而是“Release 仍有迁移债，main 已结构性关闭，待确认 Release 合并与运行指标”。 - **最小验证**：Release 上验证 flag 分流；main 上做旧页/flag consumer=0 静态检查，加 V2 长对话运行基线。 ### 2. 设计 token：main 已有生成链，但还没完全收口 - `fact / Release`：`AilohaColorTokens.swift`、`ALHColors.swift` 和 `WidgetCardKit.swift` 分别持有颜色值，没有 versioned manifest。 - `fact / main`：新增 `design-tokens/tokens/colors.tokens.json` 与生成的 `AilohaColorTokens.generated.swift`；`WidgetCardKit` 已消费生成 token。 - `fact / main`：`ALHColors.swift` 仍手写 `#00C8B3` / `#D6FE51` 的自适应颜色。 - **原问题怎么改写**：`DS-001` 从“没有共同来源”变成“生成链已经建立，但 legacy adaptive token 与跨 target 迁移尚未完成”。 - **最小验证**：manifest → generated Swift 的确定性检查；raw/legacy consumer 账本；App/Widget 的浅深色与语义角色视觉回归。 ### 3. App 测试：main 包测试更多，但跨层缺口仍在 - `fact / Release + main`：Xcode 工程都只有 App、Shared framework、Widget extension、Notification content 四个原生 target，没有 App unit/UI test target。 - `fact / main`：新增 Import、Logging、Markdown、Speech、TaskCore、TwoMeet 的 package tests。 - `fact / local candidate`：本地未提交工作区出现 `AilohaTests` 与 test plan；这只能叫候选证据。 - **原问题怎么改写**：package testability 明显变好，但账号切换、冷启路由、App Group、通知和 Live Activity 仍没有进入主线 App 生命周期 gate。 - **最小验证**：先在集成分支落一个 hosted target，跑 A→logout→B、冷/热启动入口去重、extension late write 三类行为合同。 ### 4. Onboarding PiP：旧路径已删除，剩余动效问题要单独看 - `fact / 5e6 + Release@60b1777113a8cb5a7466bd47ad42a6acc3124e9b`：存在 `OnboardingPiPGuideController`、PiP 视频资源与 `PiPPlaybackRestartSession`。 - `fact / current Release + main`：这些 PiP 文件已在 `0b90745` 删除。 - **原问题怎么改写**：不要继续把 PiP 当 current flow；但现存循环视频、定时/弹簧动画是否尊重 Reduce Motion，仍是独立的可访问性检查。 - **最小验证**：从当前 Release/main 重新列出现存自动播放与 motion consumer；开启 Reduce Motion 跑完 Onboarding，不再复用旧 PiP 证据。 ### 5. Package 边界：main 从 6 个增到 12 个 - `fact / Release`：6 个本地 package。 - `fact / main`：12 个 package；新增 Import、Logging、Markdown、Speech、TaskCore、TwoMeet。 - `fact / main`：新包开始承载导入策略/存储、日志与 zip、Markdown cache/渲染、音频流、任务本地操作/乐观匹配、TwoMeet 聚合与 SWR policy。 - **原问题怎么改写**：旧图里“App 内大 owner → 目标 package/repository”的迁移，有一部分已经发生；现在要检查的是边界是否真正拥有 state/effect，还是只把纯函数与文件移到 package。 - **最小验证**：对每个新包写 `producer → canonical state → effect owner → consumer → failure/recovery`；只把有 owner 与行为合同的边界记作架构迁移完成。 ### 6. Chat 已有保护，不等于性能已经通过 - `fact / main`：聊天列表已经改成 `UICollectionView` + diffable snapshot；同一轮的多次 publisher 更新会合并，只重配内容变化的行，后台更新会先冻结。 - `fact / main`：现有长回复脚本验证 7 段文字、选择卡和前后正文没有被截断，也验证布局写入会延后；它没有记录构建行数据、应用列表差异、滚动卡顿或内存。 - **原问题怎么改写**：Chat 不是“完全没做性能设计”，也不是“性能已经解决”；它已经有高价值保护，但缺少 100 / 1,000 / 5,000 条历史下的运行预算。 - **最小验证**：固定同一份长会话数据，分别量 `rebuildChatRows`、snapshot apply、首屏出现和连续滚动；保存设备、OS、Release 构建与 trace，再决定是否需要继续拆 projection。 ## 根因树 ```text 团队仍难判断“前端是否已经研究够” ├─ 入口按报告生成时间组织，而不是按代码 revision 组织 │ ├─ 5e6 历史地图被命名为 current │ ├─ 60b Release 审计只晚一个 Release commit，但仍是旧锚点 │ └─ main 的 88 个提交没有进入同一 claim ledger ├─ revision claim ledger 已建立，但 authority 仍未完全接通 │ ├─ 已能区分 Release open / main closed / local candidate │ └─ canonical Linear owner 与多数运行 verifier 仍未绑定 └─ 运行证据仍少于静态证据 ├─ 性能没有固定真机 baseline ├─ 可访问性只有登录入口局部收据，账号内与 spoken VoiceOver 仍缺 └─ Release/main 没有 hosted App behavior target ``` 真正的控制层缺口是：**没有一个机制在代码分支前进后提醒文档“哪些 claim 必须重验”。** ## 现在怎么改，按最小完整方案 ### P0：先修认知入口，不改业务代码 1. 网页首屏固定显示 Release/main/local 三条线；所有统计数字写明属于哪条线。 2. 每张 P0/P1 问题卡增加 `applies_to`、`observed_at`、`invalidated_by`、`next_probe`。**已完成：见 Revision Claim Ledger；Linear assignee 仍明确 unknown。** 3. 当前架构图降级为 `5e6 historical map`；在完成 main 复核前，不重新命名为 current。**已完成并继续演进：2026-08-27 先交付 main 增量图；2026-08-28 已由 clean tree 完整遍历补齐 current main L0–L4，增量图保留为变化说明。** 4. 只刷新五个已证明会移动结论的域：Chat、Design Tokens、App Tests、Onboarding、Packages。**已完成 compare-driven 第一轮；后续由任务与 revision 变化继续增量。** 5. Talent Signal 灵动岛停在 Gate 1 招聘者冷读：Gate 0 和执行工具已经 GO，但当前样本仍是 0/8。没有理解门与安全门结果、也没有选出方向前，不用实现和视频掩盖设计未知。 ### P1：compare-driven 增量刷新 不重新扫描所有文件。每次以 `旧观察 commit → 当前 Release/main` compare 产生候选清单，再沿用户旅程与 owner 边界复核。只有会改变问题状态、方案或验收的变化进入正文，其余留在 evidence ledger。 ### P2：形成轻量 freshness guard 当 `Release` 或 `main` 的 SHA 变化时，只报告受影响 claim，不自动改结论。输入是固定 SHA 与 claim 的代码锚点；输出是 `fresh / needs-review / path-removed`；owner 人工确认后再更新 canonical 文档。没有连续两次稳定使用前，不升级为 CI。 ## 这轮审计的验收标准 - 任意读者能在 30 秒内说出：这条问题描述的是 Release、main 还是本地候选。 - 对 Chat 双轨、设计 token、App tests、Onboarding PiP、Package 数量，不再出现跨 revision 的错误复述。 - 问题从“已删除路径”迁移为“Release 债 / main closed / 待发布验证”时，旧证据仍保留但不再占用当前优先级。 - 页面不再把本地 PASS、独立 review、PR 集成、Release 和生产验证混成一种完成状态。 - 后续架构刷新能由 compare 触发，而不是每次从 656 个文件重新开始。 ## 明确不在本轮做 - 不修改 `ailoha-agent-iOS` 的任何代码或脏工作区。 - 不把本地 Wave 0 候选写成 main/Release 已完成。 - 不把 Gate 0 / Gate 1 工具 GO 写成用户偏好已经验证；真实招募、方向选择、ActivityKit 实现和 Showcase 视频仍是后续独立 gate。 - 不把本轮已授权的网页发布成功写成 iOS 实现、团队冷读或生产验证已经完成。 ## 能力收获 这不是一次性的“文档过期”，而是重复出现的 **revision identity 缺口**。当前先停在 L2：把 revision 元数据和失效条件写进页面与 claim ledger。升级成自动 freshness guard 的触发条件是：至少两次分支前进都出现同类误判，且输入路径、判定规则和人工 owner 稳定。