Phase 3：iFay 派生接管軟體應用

Phase 3 把擴展方向從終端硬體轉到軟體應用——本地應用、雲端服務、In-APP 嵌入式場景。

軟體應用與硬體終端有一處關鍵差異：硬體終端的狀態相對集中，一台無人機、一台機器人就是一個被監護對象；而軟體應用的邊界往往是程序化、模組化、跨網路的。一個被 iFay 接管的電商客戶端可能同時跨多個域名、多個 API、多個第三方服務在協作。Phase 3 的難點不在於「接管」，在於接管的邊界是否被清晰描述。

與 Phase 2 同源的派生結構

Phase 3 與 Phase 2 在結構上對稱，仍然不引入「人類原型 ↔ 軟體應用」這種直接關係：

該軟體應用通過對應人類原型的 iFay 進入 Faying State。

責任端仍然是人類原型。iFay 通過 Faying State 派生地接管軟體應用，與 Phase 2 中接管終端的機制同源。軟體應用本身不在 Faying State 中獨立存在。

三處關鍵差異

Phase 3 在 Phase 2 的結構基礎上多了三處需要被特別處理的複雜性。

接管粒度更細。iFay 可能只接管軟體中的一部分功能——例如允許它代為下單，但不允許代為修改帳戶安全策略。Phase 3 因此必須在協定層面表達「接管範圍」的精細化，與第十二章中「Faying Action 必須是有限範圍的」原則同源。

跨邊界協作更密集。被接管的軟體可能在內部呼叫多個外部服務、第三方 API、遠端雲函式。Phase 3 必須確保：iFay 通過被接管軟體向外發起的任何呼叫，歸責仍然落在原人類原型身上，不允許責任在跨服務呼叫鏈中悄悄丟失。這一要求直接呼應第一章描繪的「呼叫鏈上資料經手哪些主體無人能說清」的現實痛點。

副作用更隱蔽。相比物理動作，軟體副作用（資料寫入、訂閱變更、第三方帳號聯動）更不容易被人類原型直覺地察覺。Phase 3 必須把第十一章 Human View 的「資訊可達」要求落得更顯式——副作用必須以人類原型能在合理代價內得知的方式被披露，而不是埋藏在呼叫鏈深處。

與本期範圍的關係

Phase 3 不在本期協定設計範圍內。本章描繪 Phase 3 的存在，是為了說明 Faying Protocol 的演進方向，而不是承諾本期交付。Phase 3 的具體協定形態由後續獨立 spec 承擔。

Phase 3 完成後，Faying Protocol 已經覆蓋了 Fay 與硬體、軟體兩類執行端的關係，但所有討論仍然圍繞「一個人類原型 + 一個 iFay」展開。下一階段 Phase 4 把視角擴展到組織：當 Fay 不止一個、當責任端不再是單一自然人時，Faying 關係如何依然保持一致歸責。