Recursive architecture · evidence first

先理解控制面,
再重构页面。

这不是 656 个 Swift 文件的目录浏览器,而是一张从用户价值下钻到状态 owner、数据流、证据、风险和迁移门禁的控制面。先选代码 revision,再谈问题和重构;同一结论在 Release、main 与本地候选上可能处于不同状态。

CURRENT MAIN MAPPED · RUNTIME STILL REQUEST CHANGES

main@6922f359 已由独立 clean snapshot 完整遍历并形成 L0–L4 current architecture;5e6ac6e 继续作为历史机制图,main-delta 只解释 Release → main 变化。74/74 Package tests 和 Archive 成功不等于 App 生命周期、真机性能或生产行为已通过。先读 current main 递归架构。

771current main Swift 文件
6 → 12Release → main Packages
4Release/main 产品 targets
0Release/main App test target
74/74current main Package tests
88main 超前 Release commits
Truth before priority

先说清“哪一版”,再说“有没有问题”。

旧问题不是全部作废,而是必须带适用范围。下面三条事实线不互相覆盖;本地候选尤其不能冒充已集成结果。

RELEASE · 0b90745

当前 Release 合同

4 个原生产品 target、6 个本地 package、没有 App test target。

  • Chat V1/V2 与 flag 仍在
  • Onboarding PiP 已删除
  • 旧设计 token 仍是多源
MAIN · 6922f35

当前完整静态架构

独立 clean snapshot 已完整遍历;比 Release 多 88 个提交。

  • 771 个 Swift 文件,4 个产品
  • Chat 只保留 V2,12 个本地 Package
  • 74/74 Package tests 通过
  • 仍没有 App test target
LOCAL · 5e6 + UNCOMMITTED

隔离候选,不是发布事实

Wave 0 hardening 与 hosted tests 只证明本地候选可运行。

  • 不能写成 main 已合入
  • 不能写成 Release 已覆盖
  • 不能写成 production 已验证
Comprehension gate

别相信页面自称好懂,拿三类读者来测。

产品、iOS 工程师和新人各用同一个 5 分钟窗口,完成问题定位、现场症状、因果机制、revision、第一动作与反证。评的是地图,不是参与者。

同一协议,三种观察角度

每个角色只有原话明确支持六项理解门时才通过。

PRODUCT
用户后果与取舍

能说清用户看到什么、为什么值得处理,以及第一条产品或测量决策。

PENDING
iOS
机制与 verifier

能说清状态 owner、数据流、effect、失败恢复和最小验证动作。

PENDING
NEWCOMER
事实线与起点

能分清历史、Release、main、本地候选和目标设计,并知道从哪里开始。

PENDING
Protect first

保留反例,也保留“为什么绿测仍不够”。

Last verdict 6faf7396…9b86a 是 request_changes:0 P0 + 6 P1。它还证明旧 83 项 mutation 可被共享 cache 的无关 schema 错误误杀;因此绿色输出已降级。Current successor 已用隔离 cache、目标诊断和 source-bound facts 重跑 credential90/90,并冻结为 2fadb1c1…95e0;独立 review 尚未产生。

PRIV-001 · INDEPENDENTLY CLOSED

先结算 backend outcome,再撤销账户 session

987a1b8b…d739 的 exact review 已确认,45ba8781…e44c 的未变 Swift 源回归也未发现新 P0/P1:pending Calendar backend delete 的权威重试与 reset commit 共用 serial owner;generic reset 对未知 outcome fail closed。

SEC-001 · FROZEN CANDIDATE

先让收据可信,再扩大矩阵

Current successor 保持 cache canonical immutable;每个 mutant 从同一 clean cache 隔离执行,只有目标 credential-policy 诊断才算 kill。Helper、invocation、binding、local、alias 都绑定源码 offset/slice;required/default closure、callable typealias、higher-order source、bound/optional/factory callAsFunction 与 method-value 已进入 90/90 精确矩阵。

Performance · P0 only

事故 P0 是 0;立即治理的 P0 工作是 4。

前者回答“是否已证明线上不可用”,后者回答“现在把性能预算投在哪里”。没有真机 Release trace 前,不把代码风险冒充事故;但核心路径的高杠杆工作可以先排到最前。

已证实性能事故 P00
P0 测量任务4
两个优先级不能混

这里的 P0 是工程工作的执行顺序,不是问题严重度升级:Chat 与 Contact 的全量更新机制及 Debug Simulator 页面路径已经闭合,Calendar 仍是 P1 risk,多图导入的放大机制也已在 Simulator 闭合;四者的真机与生产影响仍未知。是否升级成事故 P0,只由固定源码 SHA、Xcode Release configuration、设备、OS 与 fixture 的同场景证据决定。

01

长对话:只追加一条,仍重算整段历史

5000 行 Debug Simulator 单行追加的投影 + 同步列表路径配对中位数约 81.9ms;真机 Release 门仍未通过。

P0 ENGINEERING · DEVICE GATE OPEN
  1. 触发新消息、processing state 或反馈状态变化。
  2. 已有保护V2 有稳定 ID、同 tick 合并、后台 freeze、内容无变化早退和滚动锚点,全部保留。
  3. 根因ViewModel 每次从完整 TaskData 重建全部 rows;renderer 随后再全量去重、比较、建字典与 snapshot。
  4. 证据边界45 份优化逻辑结果证明 O(n);3×3 Debug 页面运行证明真实链可复现。没有真机 Release、mixed content 或可用 Instruments trace。

最小可交付颗粒

  1. 保留现有 full build,固定成正确性 oracle。
  2. 先让 feedback、expansion、processing 只更新目标 row;复杂 append 从安全边界重算,解释不了就 full fallback。
  3. renderer 接 insert / update / delete / move patch;保留现有列表与滚动保护。

为什么更好

先消掉最容易证明的无关工作,不拿 selection、widget 门禁和滚动正确性换跑分,也不重新引入 Chat V1。

真机验收:5000 行 append 主线程 p95 ≤16.7ms、相对 current 至少降 60%;feedback / expansion 从 500→5000 行 p95 不超过 2 倍;截图、连续视频、trace 共用 case ID。
源码、9 次页面运行与实现合同 → · 跨电脑 Notion 总包 →

02

图片导入:整批原图常驻,还会重复压缩

10×48MP 机制实验的 current-style 峰值中位数 785MB;一次 prepare 文件化候选约 82MB。

P0 ENGINEERING · DEVICE GATE OPEN
  1. 触发InputPanel 或 Camera 一次选择多张高像素照片。
  2. 当前机制整批 Data → UIImage 后才回调;附件状态继续留原图。
  3. 第二次放大每张 detached 预检先压一次,上传 actor 再按同一策略压一次。
  4. 证据状态三进程 Simulator 证明瞬时工作集放大;释放后回落。真机、真实格式与生产 OOM 仍待验证。

最小可交付颗粒

  1. 统一 PhotoImportPipeline,逐张发布状态,不再回调整批 UIImage。
  2. 一次 prepare 生成 600px preview 与 2048px upload file;预检只读文件大小。
  3. 并发从 1 起步;批次拥有取消、generation 与孤儿文件清理。

为什么更好

10×48MP 候选峰值中位数下降约 89.6%,本地阶段总时长仅约 3.57s → 3.63s。

真机验收:峰值至少降 60%;10 张不超过 1 张的 2.5 倍;首张 ≤500ms;取消后 3s 回到 +30MB。
本地证据与实现合同 → · 跨电脑 Notion 总包 →

03

Calendar:单事件走快路,边界变化整段重建

普通单事件只更新受影响日期;series、时区和窗口替换必须主动失效。

P0 MEASUREMENT · P1 RISK
  1. 触发创建、拖动、保存或同步任意一条事件。
  2. 当前机制@MainActor 的 events.didSet 遍历全部事件、展开跨日 key、逐日排序并发布整份 eventsByDate。
  3. 额外放大日期查询和缓存遍历还会通过 computed property 反复新建 DateFormatter。
  4. 证据状态全量工作是 current-main 事实;是否已形成用户可见卡顿仍待 1k / 10k fixture。

最小可交付颗粒

  1. 保留当前全量算法,作为领域正确性真值。
  2. 单 occurrence 只重算旧日和新日。
  3. series mutation、显示时区变化、权威窗口替换走 segment / full rebuild;日期 key 不在查询时重建。

为什么更好

快路只服务边界明确的单事件;系统级变化仍主动重建,避免用性能优化换来陈旧日期桶。

验收:1k / 10k、recurring series、all-day timezone、display timezone change、窗口替换下与全量真值等价。

04

Contact:只改姓名,背后的 Notes 也全部重算

12 次姓名输入稳定触发 12 次 Notes 全量投影;1,000 / 5,000 notes 每次无关投影中位数约 23.6 / 91.5ms。

P0 ENGINEERING · P1 RISK
  1. 触发用户停在 Notes tab,打开姓名、公司、职位、邮箱或电话编辑器并输入。
  2. 根因高频 editor draft 是 root VM 的 Published;Notes 又观察整个 VM,所以每个字符都叫醒 Notes。
  3. 额外放大Notes 每次醒来都解析全部日期前缀、拆 New/history、按日分组排序;ScrollView 里还是非 lazy VStack。
  4. 证据边界3×3 Debug 页面运行和五进程 production grouping 已闭合;真机 Release、生产 notes 分布与 view-construction 占比未知。

最小可交付颗粒

  1. 编辑草稿归 ContactFieldEditor 本地持有,确认时只 commit 一次。
  2. Notes 只消费不可变 input/projection 和编辑 action,不再观察 root VM。
  3. 保留 full grouping oracle;consumer test 后逐个删除 child→root forwarding。

为什么更好

把“每个字符广播到整页”变成“草稿只更新编辑器”;备注没变时,解析和分组次数应该是严格的 0。

验收:20 次姓名/company 输入的 Notes body/projection = 0;note 事务至多投影一次且与 full oracle 等价;真机 1,000 notes 单次输入 app-owned p95 ≤8ms。
源码、3×3 页面运行、截图与实现合同 → · 跨电脑 Notion 总包 →

Talent Signal → Ailoha

先拿小系统验设计,再回 Ailoha 验历史链路。

Talent Signal 能便宜地验证第一眼、ActivityKit 形态和合同写法;它不能替 Ailoha 证明 ARPC、Widget Intent、App Group、多账号与后端推送已经可靠。

CURRENT EVIDENCE · WAITING

Gate 0 已通过平台复审;Gate 1 是 0/8,selectedDirection = UNSET;ActivityKit 未实现,真实系统截图 0/10。current main 的合同审计已证明 status、identity、ordering、recovery 与 disclosure 分散,但没有证明线上事故。下面七项是可独立实现和验收的 P0 原子。

P0-01 · ATTENTION

进 App 回复后,谁继续汇报?

先在 Talent Signal 验证 App 可见 / 不可见的接管规则;再在 Ailoha 重放“进岛 → 回复 → 退出 → 再接管”。

  • 证据:TS-LA-02…07、09 + 连续视频
  • 当前:WAITING
P0-02 · STATE

一条 status 承担了四种责任

先验证 execution × attention × freshness 的投影和非法组合;再映射 Ailoha 的 Chat、Widget 与外部动作。

  • 证据:projector tests + ATLAS
  • 当前:WAITING
P0-03 · CLARITY

没有 ETA,就别用正计时冒充答案

Ailoha compact 显示不断增长的 timer,expanded 却显示阶段。先做五秒误读测试,再决定是否迁回。

  • 证据:Gate 1 Block C + TS-LA-02/05
  • 当前:WAITING
P0-04 · IDENTITY

单卡还是多卡,必须先选

当前客户端允许多张非终态卡,但注册链只有一个 update token / observer。事实成立,生产故障仍待双任务真机反证。

  • 证据:同 task 重复启动 10 次
  • 当前:PRODUCT DECISION
P0-05 · ORDERING

远端 timestamp 不等于业务终态合同

为 local update、Intent、reconcile 与 remote push 共用 eventRevision 和 allowed transition;晚到 running 不能覆盖 completed。

  • 证据:r10 → r12 → r11 replay
  • 当前:CONTRACT MISSING
P0-06 · LIFECYCLE

补丁很多,完整恢复故事还没有

Atom A 只验真实系统 UI;Atom B 才验 APNs、exact readback、乱序、杀进程和 outbox;最后仍需 Ailoha 自己复验。

  • 证据:TS-LA-09 + failure matrix
  • 当前:WAITING
P0-07 · PRIVACY

锁屏显示什么,不能由 View 顺手决定

先验证最小 disclosure projection、payload allowlist、VoiceOver 和 Always-On;Ailoha 再按任务类型制定隐私矩阵。

  • 证据:TS-LA-04/07 + payload/log audit
  • 当前:PRODUCT DECISION
现在可以先做的两个产品决定

current main 已证明“系统允许多卡、更新寻址更像单卡”,也证明 21 个富字段由 Widget 局部决定是否显示。新的共同决策包给出 A/B/C 三种卡片策略、D0–D4 披露分级和直接动作边界;推荐候选仍是 一张 task-bound Spotlight Card + D0 strict + 高后果动作回 App,但未被产品 owner 接受前仍是 proposal。

Baseline → local candidate

执行进度与待决策

下方只描述隔离 worktree 的 Wave 0 候选,不把本地通过写成已合并、已上线或已完成整个重构。

Wave 0 · 保护边界

bat/IOS-20260812-frontend-refactor-wave0 · 88-file 2fadb1c1…95e0 frozen · 未 commit / push / PR / merge / release

CHECKPOINT 0
Hosted App test substrate

真实 Ailoha hosted target、test plan 与可加载 app-owned type 的 smoke test。

LOCAL PASS
CHECKPOINT 1
SEC-001 · SwiftSyntax source → known sink

生产日志value-free;旧83项收据因cache自污染失效。Current successor以隔离cache与目标诊断完成90/90,并通过连续复验与全fact omission negatives。

CHIEF-LOCAL PASS
CHECKPOINT 2
PRIV-001 · transactional account/effect boundary

Calendar backend-ID/phase ledger、single serial owner 与 logout-before-revoke settlement 已进入账户合同。

INDEPENDENTLY CLOSED
VERIFY
新旧收据分层,不以异常冒充目标 kill

Hosted65/65、ARPC6/6与account/effect89/89保留;credential旧83失效,successor 90/90 Chief-local PASS;exact manifest与独立 verdict仍未完成。

WAVE 1 BLOCKED

攻击性审查如何改写实现

下列账本把完整 verdict、中途 finding、漂移停审与回应分层。Last exact 6faf7396…9b86a 是 0 P0 + 6 P1;current successor 已获 Chief-local 90/90 + 89/89,manifest 与独立复审仍未完成。

P0 · REAL PRE-SEND

反例:不存在的 EventMonitor hook。回应:Session 暂停自动发送,registry 在真实 task 创建后校验;stale 先 cancel 具体 task、再 cancel request。该用例曾 RED(transport=1)后 GREEN。

P0 · SESSION REVOCATION

反例:logout 发布可捕获的过渡 session。回应:reset 首步写 App Group tombstone 并移除 session;成功登录事务最后才 activate。

P0 · CALENDAR LINK RECOVERY

反例:same-session restart 会清掉通用 ledger,错误 link 可被接受,response-lost 不做 backend reconciliation。回应:backend-ID/phase ledger + exact GET;unknown outcome、marker failure 与 relaunch 都幂等续跑。

P0 · SCREENSHOT WRITER

反例:writer 可越过 reset receipt。回应:writer 与 reset 协调同一 screenshots directory,临界区重验 session,stale cleanup throwing + readback;新增 precheck 已过后的暂停竞态。

P0 · RECOVERY JOURNAL

反例:不可读 journal 被 try? 当成无 pending,启动 auto-retry 反而退出 quarantine。回应:读取错误在启动与运行中都一律 recovery-required。

P1 · LIVE ACTIVITY CLASSIFICATION

反例:taskId == nil 被猜作本地卡并跳过 owner guard。回应:owner guard 先执行;本地卡只由 session-bound durable registry 识别,reset 同步清 registry。

P0 · NOTIFICATION OWNER

反例:随机 ID 与敏感正文跨账号留存。回应:通知内容 value-free、ID 带 session namespace,退出事务验证 pending/delivered 均已清除。

REVIEWED CLOSED · CALENDAR SERIAL OWNER

a6259a09…a191 的独立复审已确认 startup recovery 与 foreground mirror 共用串行 owner;这个关闭结论只属于该快照,新候选仍需回归。

P1 · PENDING MIRROR DELETE

反例:backend response 没有 Apple link 时 delete 直接返回,pending create 的 EventKit object 与 ledger 可长期残留。回应:先按 backend ID cleanup + absence readback,再完成 ledger;失败可重试。

P1 · LOGGER INVENTORY

反例:factory-returned Logger 与同一声明第二 binding 不在 sink inventory。回应:增加 repository Logger summary 与两个精确 compile-valid mutation。

P1 · HIGHER-ORDER CLOSURE

反例:wrapper 接收 credential trailing closure,跨文件调用后进入日志。回应:对 body 直接含 credential source 的 higher-order assignment 做保守 summary;不宣称完整语言 taint。

STOPPED · MANIFEST DRIFT

Reviewer 对 bb65577e…4fcc 已形成两类 P1,但最终复算变为 db110943…8d54a;按 FREEZE 合同立即停止,既不外推 finding,也不给 exact verdict。

P1 · PRODUCTION STARTUP DELETE RETRY

反例:删除失败只可人工二次调用,startup 仍误走 create/link GET。回应:side effect 前 durable deletePending,startup 直接重试 delete,测试断言 backend GET=0。

P1 · CLOSURE / LOGGER GRAMMAR

反例:ordinary closure argument、调用 tainted helper 的 trailing closure、computed Logger property。回应:direct/indirect closure summary 与 computed Logger inventory,新增三条 compile-valid mutation。

P1 · NORMAL LINKED DELETE

反例:普通已完成 mirror 没有 pending-create ledger,EventKit failure/crash 后无 startup owner。回应:每次 linked delete 都先建立独立 durable delete intent,失败与 completion failure 均由启动恢复。

P1 · PREFERENCE BYPASS

反例:mirrorEnabled guard 可让断开日历的用户跳过既有 pending cleanup。回应:owner cleanup 先于 preference,新增 disabled-preference case 与 mutation。

P1 · ADJACENT GRAMMAR

反例:labeled closure、tainted-property trailing closure 与 typed-factory computed Logger。回应:fixed-point summary 扩展并新增第 26–28 个 compile-valid mutation。

P1 · BACKEND DELETE UNKNOWN OUTCOME

97f1… 反例:backend DELETE 在 durable local owner 前发生。response-lost / crash 可留下永久 EventKit mirror;现有 linked-delete tests 从太晚的 mirrorDelete seam 起步。

P1 · LOGGER ALIAS / INIT

97f1… 反例:Logger alias 与 Logger.init 构造都 typecheck-valid 且通过 28-mutant guard;repository-wide known-sink 声明因此失效。

REVIEWED RESPONSE · BACKEND DELETE TRANSACTION

b915… 在请求前持久化 backendDeletePending;第十轮确认 linked/pending 主状态机进入生产路径,同时发现 backend-only event 的相邻 owner 缺口。

REVIEWED RESPONSE · LOGGER FIXED POINT

b915… 增加 Logger-valued alias、Logger.init 与 os.Logger qualification;第十轮确认三条直接反例关闭,同时发现五种相邻 grammar。

P1 · BACKEND-ONLY DELETE OWNER

b915… 反例:event 没有 Apple link 时 production DELETE 仍可无 ledger 发送,commit→response-lost 后 startup 无 owner。回应:a8b8… 允许 externalID 为空的 durable row,success/404 后才 complete。

P1 · COMMON LOGGER GRAMMAR

b915… 反例:immediate receiver、parenthesized / optional / computed alias 与 .notice 都 typecheck-valid 且可绕过。回应:五个 exact mutant + real typecheck,credential 扩到 36/36。

REVIEWED RESPONSE · A8B8 DIRECT FIXES

a8b8… 的第十一轮确认 backend-only owner 与五种 Logger grammar 直接反例已进入实现,同时在同一 exact 快照发现 logout/reset handoff 与两种 constructor grammar 的相邻 P1。

P1 · LOGOUT BACKEND OUTCOME HANDOFF

a8b8… 反例:session revoke 后 generic reset 可 complete 未知结果的 backendDeletePending,或只删 EventKit 而不确认 backend。回应:987a… 在同一 serial owner 内先结算,再提交 reset;generic reset fail closed。

P1 · LOGGER CONSTRUCTOR SHORTHAND

a8b8… 反例:typed Logger = .init(...) 与 outer-parenthesized (Logger(...)) 均 typecheck-valid 且可绕过。回应:两个 exact mutant + real typecheck,credential 扩到 38/38。

REVIEWED CLOSED · CALENDAR LOGOUT HANDOFF

987a… 的第十二轮确认 settlement/backend retry/reset commit 共用同一 serial owner,generic reset 对未知 outcome fail closed;该关闭结论只属于 exact 快照,current 仍做有限回归。

P1 · LOGGER TYPEALIAS / WRAPPER

987a… 反例:Logger typealias constructor 与 Optional(Logger(...))! 均 typecheck-valid 且可绕过。回应:45ba… 加 typealias fixed point、wrapper inventory 与两个 exact mutants,credential 扩到 40/40。

EXACT OPEN · LOGGER INVENTORY LIMIT

45ba… 复审确认指定两条已闭合,但括号 typealias、Optional.some 与 typed closure receiver 仍可绕过。结论不是“再补三条就语言完备”,而是升级 AST/SwiftSyntax 或收窄版本化语法合同。

E76 · AST FIXED-POINT GAPS

e76… 的 49/49 与四类 P1 同时成立:default arity、nested closure ownership、higher-order/cast callable 与 multiline parameter-return。回应:统一 SwiftSyntax declaration/call graph;该快照 verdict 保持 0 P0 + 4 P1。

5DA · MEMBER / VARIADIC / OVERLOAD

5da… 虽有 55/55,仍跳过 member call、只消费 variadic 首参、让 local name 遮住跨文件 overload,并排除 member source-return;另可接受成功但空的 analyzer JSON。Exact verdict:0 P0 + 5 P1。

F42E · EXACT 0 P0 + 3 P1

五条 5da exact mutation与 envelope negatives均独立通过;新反例是 overload/container scope 合并、带标签 variadic 中间实参、computed/nested member source。Manifest 首末均为 f42e41cb…a4a91。

400508 · EXACT 0 P0 + 5 P1

Stable scope、labeled middle actual与member property/call/wrapper直接反例已关闭;新反例是不可见nested/closure/receiver candidate遮蔽、typealias/generic误排除、variadic吞trailing closure、member subscript无fact,以及successful-empty/poisoned cache。Manifest首末均匹配。

F6B499 · EXACT 0 P0 + 6 P1

400508九条direct regression均关闭;新反例是source/alias仍file-shadow、Substring compound误判、default+required trailing closure、callAsFunction、_read/yield,以及非空伪造sink fact。Manifest首末均匹配。

6FAF7396 · EXACT 0 P0 + 6 P1

独立复审发现 cache 原地加入 characterOffset,导致后续 mutant 用无关 schema failure 冒充 kill;另有 source visibility、required/default + typealias closure、bound/factory callable、method-value 与 non-sink fact completeness 五类缺口。旧 83/83 已失效。

2FADB1C1 · FROZEN, REVIEW PENDING

cache 改为 immutable copy;mutant cache 隔离且拒绝 analyzer/schema 错误归因;全部六类 fact 绑定 source slice;连续 validate、五类 fact 删除、closure 顺序/typealias、higher-order source、direct/bound/optional/factory callable 与 method-value 已进入 90/90。System Lightweight、HEAD RED与diff-check通过;独立 review 尚待。

DECISION · REMOTE REVOKE UX

当前 ordinary logout 已 strict server unregister;但离线/过期凭据会使退出保持 recovery shell。需后端 generation/receipt 与产品恢复体验共同决策。

P1 · RECEIPT SCOPE

当前65/65、credential90/90与account/effect89/89只覆盖已枚举合同;旧credential83/83保持失效。新逐项mutant仍只保证parse-valid,代表性typecheck由聚合oracle提供。Protected CI与真实账号UI/extension/system replay仍缺。

L0 → L4 · CURRENT MAIN

递归架构

左侧节点与默认 Archify 图都固定在 clean main@6922f359。5e6 是历史机制,Release → main 是变化说明,目标态是候选设计;四者不会混成一张图。

current main 完整运行架构

调研如何收敛,AI 如何被约束

“深度”不等于扫描更多文件,而是让每个结论都能回到固定修订、运行路径、来源边界与可反证条件;让每次代码动作都只能发生在被外部授权的一小步内。

  1. 01 · OBSERVE固定 revision、时间与真相源
  2. 02 · MODEL沿用户流下钻 owner 与 effect
  3. 03 · FALSIFY用迟到、崩溃与跨账号反例攻击
  4. 04 · GUARD把机制写成测试与 mutation
  5. 05 · FREEZE冻结 manifest;任何漂移立即停审
  6. 06 · REVIEW独立 verdict 决定能否外推

从代码事实到重构判断

本轮调研的递归路径与每一层留下的可复用产物。

  1. 固定真相源

    先锁定 commit、clean state 与观察时间。运行代码决定实现事实;设计与协作文档提供意图和时间切片。OUTPUT · revision ledger

  2. 沿运行流递归

    从 L0 用户价值下钻到 L4 实现缝,逐层记录 owner、输入、状态、effect、失败模式与 consumer,不用目录结构冒充架构。OUTPUT · recursive map

  3. 三源对齐

    代码回答“现在实际运行什么”;Figma 回答局部设计意图;飞书回答协作语义与历史。三者发生漂移时保留分歧,不强行合并。OUTPUT · alignment ledger

  4. 分层陈述

    Fact 必须有直接来源与观察时间;inference 必须写推理和反证;hypothesis 必须有验证动作,永远不能伪装成结论。OUTPUT · claim + source + falsifier

  5. 六面反证

    按用户/产品、代码/数据流、架构/依赖、可靠性/可观测性、安全/隐私、流程/成本逐面检查,问题按机制去重。OUTPUT · 30 mechanisms + unknowns

  6. 独立攻击审查

    Reviewer 不只读结论,还构造 compile-valid 日志绕过、A→B 迟到响应、跨进程 TOCTOU、401/5xx retry 与 EventKit 乱序;未解决的 P0/P1 阻断批准。OUTPUT · counterexample → invalidated claim → next gate

  7. 结论失效与停止

    新反例会立即降级旧的 PASS;先冻结可构建快照,再把未关闭机制、解除条件和不可外推边界写回控制面。OUTPUT · claim invalidation ledger + next gate

Fact

来源直接支持;记录 revision、source 与 observed time。

Inference

由多个事实推导;必须公开推理链和能推翻它的条件。

Hypothesis

仍是未知;绑定 owner、验证动作与下一决策点。

Mechanism catalog

全部问题,按机制去重

搜索和筛选不会丢失证据;展开卡片可看后果、claim 类型、验证动作与代码锚点。

Decision, not doctrine

三档方案,一条推荐路径

推荐演进式垂直切片:先保护账户与日志,再让 Task 证明新的 owner/effect 边界。

A · 保守护栏

只修 P0、补 app tests、修 scheme,暂不改变 state owner。

  • 快、回归面小
  • 控制面分裂继续存在

C · 目标架构重写

新建 AppShell、Stores、Transport、DesignSystem 后整体切流。

  • 目标模型整洁
  • 隐性合同与长分支风险最高
WAVE 0 · REVIEW PENDING

保护边界

Calendar P1 已独立关闭;credential guard 的 6faf verdict 仍有 6 个 P1。Current 90/90 remediation 已完成 Lightweight 并冻结为 2fadb1c1…95e0;只有 independent approval 后才可进入 Wave 1。

WAVE 1

组合与导航

Typed dependencies、session scope、NavigationEffect。

WAVE 2

Task 试点

统一 Home/Chat/详情、alias、乐观 transition。

WAVE 3

Contact / Calendar

Repository、query、screen session 分离。

WAVE 4

体验与系统表面

Tokens、Dynamic Type、Reduce Motion、跨进程 envelope。

WAVE 5

删除旧控制面

基于 rollout、consumer=0 与 Reviewer 证据删除。

Current-main runtime · login only

可访问性不是“加几个 label”,而是三条可验收的用户能力。

这轮只验证未登录入口。把已经好的语义基础、已经闭合的失败和账号内未知分开,避免一句“无障碍有问题”让团队无从下手。

LOGIN RUNTIME · PARTIAL / REQUEST CHANGESmain@6922f359:Google、Apple、同意协议能被运行语义树发现;最大字号没有进入品牌字体;Reduce Motion 开启后背景视频仍播放。spoken VoiceOver、Release 语义树和账号内旅程仍未验证。打开完整证据和验收合同
P0-1 · DYNAMIC TYPE

系统字号变大,品牌字没跟着变

Large 与 AXXXL 都是 40 个语义元素、6 个目标、0 个滚动区域;品牌字体 API 使用 fixed size。

  • 先给 DesignSystem 增加 relative text style
  • 只迁登录页,不一次改全仓
  • 中英、窄屏、Large/AXXXL 截图验收
P0-2 · REDUCE MOTION

偏好已开启,背景视频还在循环

一秒间隔两帧的变化主要集中在视频区;播放器无条件 play 并在结束后重播。

  • 把 motion policy 作为声明式输入
  • 开启时显示静态 poster
  • 3 秒未剪视频证明真的静止
P0-3 · SEMANTIC JOURNEY

按钮能发现,不等于 VoiceOver 已通过

三个核心动作有语义基础;Debug 仍有快捷登录、环境和空白 target,真实朗读顺序与 alert 焦点未知。

  • Release 不出现 Debug / 空名称动作
  • 协议链接、alert、loading 状态可感知
  • VoiceOver 单镜头 + transcript 验收
Same product, different time slices

Figma / 飞书 / 代码

设计和文档提供意图,当前修订提供运行事实;任何一方都不能无条件覆盖另两方。

2026-08-28 revision 修正main@6922f359 已是 Chat V2-only、三项 visible bottom nav、12-route Onboarding 与部分生成 token 链;Figma fresh read 因 View-seat MCP 限额失败,所以历史问卷节点仍标记 unknown,不冒充 current target。读人话对齐页 · 看机器收据
FIGMA · PARTIAL / RATE-LIMITED

Onboarding 问卷节点

已保存的 2026-08-11 观察:393×852、dark #1A1A1A、Lora 24、Manrope、5 选项、disabled Continue、24pt inset、accent #C8F04A。

当前代码主路径已演进为 Setup 2.0 + permissions + Action Button + Try It;不能把此节点当全流程。
飞书 · ACTIVE, LAST EDIT 2026-06-22

iOS parent + 10 子文档

Onboarding、Chat、Calendar、Contact、Screenshot、Home、ARPC、Auth、Task lifecycle、Live Activity。

决定产品/协作陈述,不覆盖之后的代码事实。名为 iOS 重构的一篇草稿正文实际是 Agent/backend。
CODE · CURRENT MAIN + HISTORY + LOCAL CANDIDATE

当前事实、历史机制与候选分层

main@6922f359 的 clean tree 是当前静态架构;5e6ac6e 解释旧机制;Wave 0 只代表本地保护候选。

74/74 Package tests 与 Archive 只支持已枚举合同和可归档性;本地 overlay 未 commit / PR / merge / release,不能当生产事实。
Evidence bundle

文档与证据

HTML 负责探索;Markdown 负责长期审阅、diff 与 AI 后续加载。

current main 递归架构完整 L0–L4、四个产品、运行脊柱、状态 owner、六条机制与适当重构切片 current main 可探索图固定 main@6922f359;34/34 源码引用、四个 guided views 5e6 历史递归架构历史 L0–L4、八个运行表面、状态 owner 与关键数据流 问题目录30 个机制、证据、反证、修复边界 P0/P1 Revision Claim LedgerRelease / main / local 的适用范围、失效条件、责任角色与 verifier 5 分钟团队冷读评测器产品、iOS 工程师、新人三类原话、六项理解门与本机 JSON / CSV 导出 Talent Signal → Ailoha 迁移证据账本六类灵动岛问题、证据升级门、十张真实系统截图和 Ailoha replay current main Live Activity 合同对照保留现有可靠性支点,把七个 P0 原子、12 张 Ailoha 状态截图、三段未剪视频与测试真相编译成 Agent 执行包 Live Activity 产品政策决策包单卡/多卡、D0–D4 锁屏披露、直接动作边界、10 张系统截图与 2 段未剪视频 可视化共同决策画布可浏览 A/B/C 卡片策略、任务披露矩阵、反证条件和 owner 待选择项;同时提供可编辑 Excalidraw 源文件 单卡/多卡与锁屏披露 · Notion另一台电脑可直接冷读、选择、实现并按 10 图 2 视频验收的共同设计页 Ailoha 灵动岛合同 · Notion另一台电脑可直接执行的 current-main 事实、实施顺序、12 图与三视频验收 重构策略三档方案、Wave 0-5、验证矩阵、删除门槛 产品 / 设计对齐按 current-main revision 纠正 Chat / Tab / Onboarding / theme / token;Figma 生命周期仍是 unknown current main × Figma × 重构验收 · Notion给新电脑 / 新 Agent 的五个最小颗粒、真实未知、10 图 2 视频与 12 图 3 视频入口 Onboarding 设计合同 · Notion只填姓名却提交旧三题问卷:另一台电脑可直接执行的事实、DEV 裁决、实现边界、5 图 2 视频验收 可访问性表面5e6 历史 441 文件扫描 + current-main successor + 运行 gate 登录入口可访问性运行基线最大字号、Reduce Motion、运行语义树、三个最小重构颗粒与 8 图 3 视频验收合同 登录入口可访问性 · Notion另一台电脑可直接执行;内嵌四张 current-main 状态截图、声明式实现顺序、8 图 3 视频和总体验收表 性能风险源码候选、反证条件与 Instruments 计划 性能工程清单工程认知颗粒、最小改法、分层测试与验收门 长对话单行更新基线完整全量链、45 份逻辑证据、3×3 Debug 页面运行、最小增量方案与十张视觉证据合同 联系人字段更新基线姓名输入触发 Notes 重算的 3×3 页面证据、五进程机制基线、四个最小颗粒与 0-update 验收门 Contact 观察边界 Notion 总包另一台电脑可直接接手的声明式模型、文件级切片、十张截图、视频、性能 Gate 与禁止扩域边界 Chat 增量投影 Notion 实施总包另一台电脑可直接接手的状态机、切片、截图、视频、性能 Gate 与回退合同 覆盖账本5e6 历史扫描方法;current main 由 successor 文档裁决 证据索引revision ledger、high-impact claims、上游来源 Wave 0 实现覆盖本地 checkpoint、验证收据、待决策与 recovery Wave 0 验证摘要公开 gate、命令、结果与 reviewer 状态;完整账本位于 brain://tasks/active/IOS-20260812-frontend-refactor-wave0/verification.md 独立攻击审查摘要公开反例与复审状态;完整账本位于 brain://tasks/active/IOS-20260812-frontend-refactor-wave0/review.md current main Archify specification固定 revision、12 个主节点、15 条连接、34 个可解析源码引用 5e6 历史 Archify specification历史态 JSON;目标态见相邻文件 Release → main 变化说明Chat 收敛、六个 Package owner、隐式依赖与 token 生成链;不是完整 current architecture AI 重构 Harness 方法概览公开方法摘要;完整入口位于 brain://reports/ios-refactor-harness/README.md Gate 状态与恢复摘要公开执行边界;完整合同位于 brain://reports/ios-refactor-harness/gate-contract.md