# 從通用 Runtime 到 Native World：ANDO 雙生產品線的互操作、遷移與共同演化 ## From General Runtime to Native World: Interoperability, Migration, and Co-Evolution of the ANDO Twin Product Lines **系列：** ANDO Twin Runtime Series **篇次：** 05 / 05 **作者：** Neo.K **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 **日期：** 2026-08-23 **文件類型：** 理論論文 / 雙生架構收束論文 **狀態：** 公開初稿 --- ## 摘要 前四篇已分別建立 ANDO 雙生架構的總體定位、Portable Semantic Kernel、General-OS / Windows-first 商業 Runtime，以及 HDUS-native World-Native Runtime。剩餘的關鍵問題是：當兩條產品線開始獨立演化後，如何避免它們逐步成為兩套互不相容的系統？又如何讓既有 General-OS 使用者在不被迫遷移的前提下，保留未來進入 Native World 的選擇？ 本文提出 ANDO Twin Interoperability & Co-Evolution Framework。其核心主張是：互操作不應以 internal schema copying 為中心，而應以 Portable Semantic Kernel 為共同語義面；遷移不應被理解為單純 export/import，而應被理解為 identity、lineage、authority、artifact、verification、receipt、commit 與 history 的跨 substrate re-embodiment；共同演化不要求 feature parity，而要求 semantic compatibility、conformance 與 drift control。 本文形式化提出 Semantic Interop Plane、Migration Envelope、Loss Manifest、Compatibility Matrix、Twin Version Vector、Cross-Runtime Delegation、Portable Receipt Chain、Verification Portability、Authority Preservation、Semantic Drift Budget、Conformance Gate 與 Twin Release Protocol 等概念。本文亦區分 migration、federation、projection、mirroring 與 handoff，避免將所有跨 runtime 行為混成「同步」。 最終，本文將 ANDO 雙生產品線定義為：兩條可以各自商業化、獨立部署與持續分化的 Runtime，透過共同 semantic kernel、明確 conversion contract 與 conformance suite 保持長期身份一致。理想狀態不是兩條產品線看起來越來越像，而是它們在功能上可以持續分歧，同時在核心組織語義上維持可證明的相容性。 --- ## 關鍵詞 ANDO、Twin Runtime、Interoperability、Migration、Co-Evolution、Semantic Drift、Portable Semantic Kernel、HDUS、General-OS Runtime、Cross-Runtime Delegation、Conformance --- # 1. 問題：雙生架構最終會不會變成兩套系統？ 設： $$ R_G(t) $$ 為 General-OS Runtime， $$ R_H(t) $$ 為 HDUS-native Runtime。 若兩者各自獨立發展，則 feature set 會逐步形成： $$ F_G(t), $$ $$ F_H(t). $$ 功能差異本身不是問題。 真正問題是： $$ SemanticDrift( R_G, R_H ). $$ 若 semantic drift 持續增加： $$ SemanticDrift \rightarrow Large, $$ 則「雙生」只是歷史名稱。 --- # 2. Twin Architecture 的完成條件 本文主張完整雙生架構至少需要四個平面： $$ \mathcal T_A = ( SemanticPlane, RuntimePlane, InteropPlane, EvolutionPlane ). $$ 其中： - SemanticPlane：Portable Semantic Kernel； - RuntimePlane：General 與 Native realization； - InteropPlane：跨 runtime 交換與遷移； - EvolutionPlane：版本、conformance 與 drift control。 沒有 InteropPlane： $$ Twin \rightarrow Fork. $$ 沒有 EvolutionPlane： $$ Twin \rightarrow EventualSemanticFork. $$ --- # 3. Semantic Interop Plane 定義： $$ \mathcal I_S = ( Identity, State, Task, Delegation, Authority, Artifact, Verification, Receipt, Commit, History, Governance ). $$ 這些物件的交換不應依賴： ```text SQLite row shape HDUS object memory layout HTML UI Windows path native renderer state ``` 而應經過 Portable Semantic Contract。 因此： $$ \boxed{ Interop \neq InternalSchemaCopy. } $$ --- # 4. 五種跨 Runtime 行為 本文區分五種操作： ## 4.1 Migration $$ M_{A\rightarrow B} $$ 將主要 operational ownership 從 A 移到 B。 ## 4.2 Projection $$ P_{A\rightarrow B} $$ 只建立另一邊可讀的 representation。 ## 4.3 Federation $$ F(A,B) $$ 兩邊都持續運作，並共享部分 semantic domain。 ## 4.4 Handoff $$ H_{A\rightarrow B} $$ 某個 task / delegation 暫時交由另一 runtime 執行。 ## 4.5 Mirror $$ Mirror(A,B) $$ 維持 read-oriented replica 或觀測副本。 這五者不能全部叫「同步」。 --- # 5. Migration 的正式定義 Migration 不只是 copy bytes。 定義： $$ M_{A\rightarrow B} : X_A \rightarrow (X_B,L_M,C_M), $$ 其中： - $X_A$：source state； - $X_B$：target state； - $L_M$：Loss Manifest； - $C_M$：Migration Certificate / Receipt。 因此： $$ \boxed{ Migration = StateTransfer + SemanticReconstruction + LossDisclosure + Verification. } $$ --- # 6. Migration Envelope 定義 Migration Envelope： $$ \mathfrak M = ( MID, SourceRuntime, TargetRuntime, KernelVersion, Scope, Entities, AuthorityMode, HistoryMode, ArtifactMode, VerificationMode, LossPolicy, StartedAt, CompletedAt ). $$ 它使 migration 成為 first-class governed action。 --- # 7. Migration Scope Migration 不一定是整個 organization。 可以是： $$ Scope \in \{ Entity, Task, Project, Workspace, Organization, HistoryWindow \}. $$ 例如只遷移： ```text project P its tasks its artifacts its verification history ``` 而不是整個使用者環境。 --- # 8. Identity Preservation 核心條件： $$ I_A(e) = I_B(M(e)) $$ 若是 same-identity migration。 如果 target runtime 無法保留 ID，可建立 mapping： $$ I_A(e) \leftrightarrow I_B(e'). $$ 並保存： $$ IdentityMap. $$ 但不能假裝： $$ e=e' $$ 而不留下 mapping。 --- # 9. Identity Fork 有些 migration 其實是 fork。 例如 source 繼續運作，target 也產生可寫副本。 此時： $$ Fork(e) = (e_A,e_B). $$ 必須建立： $$ CommonAncestor. $$ 否則兩邊後續 commit 會產生不可解釋的歷史分叉。 --- # 10. Lineage Preservation Migration 必須保留： $$ Parent, DerivedFrom, Supersedes, RetryOf, DelegatedFrom $$ 等 lineage。 因此： $$ Migration \not\Rightarrow LineageReset. $$ --- # 11. Authority Preservation 若 source authority： $$ A_A(x), $$ 則 target authority： $$ A_B(M(x)) $$ 至少不能無授權膨脹。 要求： $$ A_B \subseteq Translate(A_A). $$ 因此： $$ \boxed{ NoAuthorityInflationAcrossMigration. } $$ --- # 12. Authority Translation General-OS 可能用： ```text scope + connector + role + expiry ``` HDUS 可能用： ```text authority edge ``` 因此需要： $$ T_A : Authority_G \rightarrow Authority_H. $$ 若 target 無法精確表示某限制： $$ TranslationLoss>0, $$ 則 migration 必須降權或拒絕。 不能擴權。 --- # 13. Safe Authority Rule 建議： $$ UnknownAuthorityMapping \Rightarrow DenyByDefault. $$ 而不是： $$ UnknownAuthorityMapping \Rightarrow Allow. $$ --- # 14. Artifact Portability Artifact migration 可有多種模式： ```text copy reference project reconstruct native-import ``` 定義： $$ Mode_A \in \{ Copy, Reference, Projection, Reconstruction \}. $$ 不同 artifact 可選不同模式。 --- # 15. Artifact Identity 與 Representation General Runtime： $$ A_G = Path + Digest + Metadata. $$ Native Runtime： $$ A_H = NativeObject + StateIdentity + Lineage. $$ 因此 migration 需要： $$ ArtifactContract $$ 而不是強迫 target 也產生同一 filesystem path。 --- # 16. Verification Portability 若 source 有 verification： $$ V_A. $$ 遷移後不能自動宣稱： $$ V_B=Pass $$ 除非 verification 仍 applicable。 至少要檢查： $$ TargetIdentity, TargetState, ContractVersion, EvidenceAvailability, Freshness. $$ --- # 17. Verification Applicability Across Runtime 若： $$ EquivalentState(A_G,A_H)=1, $$ 且： $$ Contract_G = Contract_H, $$ 則某些 verification 可直接 portable。 但若 target representation 改變了 relevant semantics，就需要： $$ Reverification. $$ --- # 18. Generic Verification 不可升格 跨 runtime 仍需： $$ GenericPass \not\Rightarrow TypedPass. $$ 以及： $$ StructuralPass \not\Rightarrow ExecutedPass. $$ migration 不能成為 verification laundering。 --- # 19. Receipt Portability Receipt chain： $$ Receipt_D \rightarrow Receipt_X \rightarrow Receipt_V \rightarrow Receipt_C $$ 應可跨 runtime 保留。 但 target runtime 不一定需要重建相同 storage。 只需要： $$ \alpha_A(Q_A) = \alpha_B(Q_B). $$ --- # 20. Commit Portability Commit history 是 P0 hard semantic state。 因此： $$ Migration \not\Rightarrow CommitHistoryReset. $$ 若某 commit class 在 target 不被支援，可以： $$ PreserveAsHistoricalReadOnly. $$ 而不是刪除。 --- # 21. History Window 完整 history 可能非常大。 因此 migration 可以選： $$ HistoryMode \in \{ Full, Windowed, Compressed, Referenced \}. $$ 但對任何非 Full mode，必須附： $$ HistoryManifest. $$ --- # 22. Compressed History 若： $$ H \rightarrow H_c, $$ 需要保留： - source digest； - compression method； - covered range； - omitted detail policy； - reconstruction boundary。 因此： $$ Compression \neq HistoryErasure. $$ --- # 23. Loss Manifest 定義： $$ L_M = ( Preserved, Translated, Degraded, Dropped, Unresolved, Reason, RecoveryHint ). $$ 如果： $$ Loss>0, $$ 則： $$ L_M\neq\varnothing. $$ --- # 24. Loss Severity 可定義： $$ Severity \in \{ Informational, Operational, Governance, Security, Identity \}. $$ Identity / Security loss 不應被自動接受。 --- # 25. Migration Gate 定義： $$ MigrationAllowed = IdentitySafe \land AuthoritySafe \land HistorySafe \land LossPolicySatisfied. $$ 必要時再加： $$ HumanApproval. $$ --- # 26. Migration Receipt Migration 本身也要產生： $$ Receipt_M. $$ 內容至少： $$ SourceDigest, TargetDigest, EntityCount, LossManifestRef, ConformanceResult, Time. $$ --- # 27. Cross-Runtime Delegation 不一定要 migration 才能協作。 可以： $$ D_{G\rightarrow H} $$ 表示 General Runtime 將某 delegation 交給 HDUS-native 執行。 也可： $$ D_{H\rightarrow G}. $$ --- # 28. Delegation Envelope Portability 跨 runtime delegation 最低需要： $$ ( Intent, Scope, Target, Authority, Budget, Risk, Verification, Output, Checkpoint, Escalation ). $$ 因此： $$ DelegationEnvelope \subseteq PortableSemanticContract. $$ --- # 29. Remote Execution 不等於 Authority Transfer 即使 task 在另一 runtime 執行： $$ ExecutionLocation \neq AuthorityOwner. $$ source governance 仍可保留 revocation capability。 --- # 30. Cross-Runtime Revocation 如果 source 撤銷： $$ Revoke(D,t_r), $$ target runtime 必須在 bounded latency 內停止後續合法 action。 因此可定義： $$ L_{R}^{cross}. $$ 這是 interop benchmark。 --- # 31. Cross-Runtime Budget 若 source delegation budget： $$ \mathbf B_S, $$ target 不得創造： $$ \mathbf B_T \succ \mathbf B_S $$ 除非有額外授權。 --- # 32. Cross-Runtime Checkpoint Handoff 中需要： $$ Checkpoint_P $$ 為 portable checkpoint。 其內容不必包含 target-private cache，只需： $$ TaskState, Progress, ArtifactRefs, OpenIssues, AuthorityContext, Revision. $$ --- # 33. Federation Migration 是 ownership movement。 Federation 則是： $$ R_G \parallel R_H $$ 同時持續運作。 此時最大的問題是： $$ WriteConflict. $$ --- # 34. Single-Writer 與 Multi-Writer Federation 可以採： ## Single-Writer 某 semantic domain 只有一個 canonical writer。 ## Multi-Writer 兩邊都可寫，但需要 conflict protocol。 第一版建議： $$ SingleWriter > MultiWriter $$ 作為安全預設。 --- # 35. Canonical Ownership 定義： $$ Owner(e,t) \in \{ R_G, R_H, Shared \}. $$ 對高風險 semantic entity： $$ Owner \neq Ambiguous. $$ --- # 36. Ownership Transfer 若 canonical ownership： $$ R_G \rightarrow R_H, $$ 需： $$ Freeze_G \rightarrow Transfer \rightarrow Validate_H \rightarrow Activate_H. $$ 避免 dual-write window。 --- # 37. Mirroring Mirror 主要用於： - audit； - dashboard； - disaster recovery； - analytics。 可令： $$ Write(Mirror)=0. $$ 因此比 federation 安全。 --- # 38. Projection Projection 不需要完整 state ownership。 例如 HDUS-native artifact 可投影成 Windows file： $$ P_{H\rightarrow G}(A). $$ 這個 file 可能只是： $$ DerivedRepresentation. $$ 修改它是否回寫，需另外 policy。 --- # 39. Write-Back Projection 若允許： $$ Edit(P(A)) \rightarrow Update(A), $$ 則 projection 已不再 read-only。 需要： $$ WriteBackContract. $$ --- # 40. Conflict 若 General 與 Native 兩邊都改同一 semantic entity： $$ e_G' \neq e_H', $$ 便形成： $$ Conflict(e). $$ 不能只靠 timestamp 永遠解決。 --- # 41. Conflict Types 至少區分： ```text representation conflict content conflict authority conflict verification conflict commit conflict history conflict ``` 其中 authority / commit conflict 屬高風險。 --- # 42. Merge Policy 對低風險 content： $$ Merge $$ 可以自動化。 對 authority / commit： $$ AutoMerge \rightarrow Forbidden $$ 作為預設。 --- # 43. Twin Version Vector 兩條 Runtime 各自有版本： $$ v_G, v_H. $$ 還有 kernel 版本： $$ v_K. $$ 定義： $$ \mathbf V_T = (v_K,v_G,v_H,v_I), $$ 其中 $v_I$ 為 interop contract version。 --- # 44. Compatibility Matrix 定義： $$ C_{ij} = Compat( R_i, K_j ). $$ 可以產生： | Runtime | PSK Core | Verification | Migration | NativeWorld | |---|---|---|---|---| | General | Full | Full | Full | Incompatible | | HDUS | Full | Full | Full | Full | 這比單一版本號更有用。 --- # 45. Semantic Drift 定義： $$ D_S(t) = d( \alpha_G(R_G(t)), \alpha_H(R_H(t)) ). $$ 目標不是： $$ D_S=0 $$ 對所有 feature，而是對 hard kernel： $$ D_S^{core} \rightarrow 0. $$ --- # 46. Semantic Drift Budget 可定義： $$ B_D $$ 為允許的 drift budget。 對 Hard Invariant： $$ B_D=0. $$ 對 Optional Extension： $$ B_D>0. $$ --- # 47. Feature Divergence 可以增加 理想狀態仍是： $$ \frac{d}{dt} FeatureDivergence > 0, $$ 同時： $$ SemanticDrift_{core} \rightarrow 0. $$ 也就是兩邊越來越各自擅長不同事情，但仍保持同一組織語義。 --- # 48. Co-Evolution Protocol 定義： $$ CEP = ( Proposal, Classification, KernelImpact, TwinImpact, InteropImpact, Conformance, Release ). $$ 任何重大 feature 先判定： ```text runtime-local portable extension kernel change interop change ``` --- # 49. Runtime-Local Feature 例如： ```text Windows COM connector HDUS spatial observer ``` 屬： $$ RuntimeLocal. $$ 不需要另一條產品線實作同 feature。 --- # 50. Portable Extension 若某 feature 具有跨 runtime 意義，例如： ```text new verification contract new receipt type ``` 則應先抽象成： $$ PortableExtension. $$ 再由兩條 runtime 各自實作。 --- # 51. Kernel Change 若 feature 改變： $$ Identity, Authority, Delegation, Verification, Commit, History $$ 等 hard semantics，則它不是普通 feature。 必須標記： $$ KernelChange. $$ 並重新跑 twin conformance。 --- # 52. Interop Change 若只改： - migration envelope； - loss manifest； - handshake； - projection format； 則： $$ InteropVersion \uparrow $$ 可能即可，不必升 kernel major。 --- # 53. Twin Release Protocol General 與 Native 不必同日 release。 但任何 release 應標記： $$ SupportedKernelVersion $$ 與： $$ SupportedInteropVersion. $$ 因此 release metadata 至少包含： ```text runtime_version kernel_version interop_version migration_profiles conformance_result ``` --- # 54. Conformance Gate 發布前： $$ ReleaseAllowed = RuntimeTests \land KernelConformance \land InteropConformance. $$ 若包含 migration change： $$ MigrationRegression $$ 也必須通過。 --- # 55. Twin Scenario Suite Conformance 不應只測 schema。 應測 scenario： ```text create task delegate checkpoint replace agent produce artifact verify commit revoke migrate resume ``` 然後比較： $$ \alpha_G(Result_G) $$ 與： $$ \alpha_H(Result_H). $$ --- # 56. Probe-Based Equivalence 對 probe set： $$ \mathcal P = \{p_1,\ldots,p_n\}, $$ 要求： $$ p_i(R_G)=p_i(R_H) $$ 對 hard semantic probe 成立。 例如： ```text is_task_complete authority_of latest_applicable_verification commit_eligibility revocation_state ``` --- # 57. Semantic Fingerprint 兩條 runtime 可各自產生： $$ F_S(R). $$ 若： $$ F_S^{core}(R_G) = F_S^{core}(R_H), $$ 則表示共同 kernel profile 相容。 但 fingerprint 只是快速摘要，不替代 full conformance。 --- # 58. Twin Capability Negotiation 跨 runtime handoff 前，可交換： $$ CapabilityProfile. $$ 例如： ```text CodeVerification L2 CurrentState L2 W1 commit W2 commit NativeWorldProjection BrowserAdapter ``` 這使 delegation 不會派到無法執行的 runtime。 --- # 59. Capability 不等於 Authority Capability negotiation 只說： $$ CanPotentiallyDo. $$ 真正 action 還需要： $$ AuthorizedToDo. $$ 因此跨 runtime 仍需： $$ Capability \neq Authority. $$ --- # 60. Verification Negotiation 若 source 要求： $$ Code/Pass/L2, $$ target 只支援： $$ Code/L1, $$ 則： $$ HandoffRejected $$ 或降級需 explicit policy。 不能靜默把 requirement 降低。 --- # 61. Freshness Across Runtime CurrentState verification 具有時間性。 若 source verification： $$ ValidUntil=t_v, $$ 而 migration 完成： $$ t_m>t_v, $$ 則 target 必須視為： $$ Stale. $$ 不是因為 migration 完成就刷新時間。 --- # 62. Clock Domain 跨 runtime 可能有不同 clock。 因此 timestamp 需要： $$ ClockDomain $$ 與： $$ OffsetAwareTime. $$ 對高精度事件可再保留 monotonic sequence。 --- # 63. Event Ordering Distributed federation 中： $$ WallClockOrder $$ 未必可靠。 因此可以同時保存： $$ LocalSequence + CausalRelation + WallClock. $$ 而不是只看 timestamp。 --- # 64. Causal History 若 event： $$ e_2 $$ 依賴： $$ e_1, $$ 則 migration / federation 應保留： $$ e_1\prec e_2. $$ 這比單純排序更重要。 --- # 65. Cross-Runtime Ledger 可定義： $$ L_T = L_G \cup L_H \cup L_I, $$ 其中 $L_I$ 為 interop event。 例如： ```text handoff.requested handoff.accepted migration.started migration.completed authority.revoked.cross_runtime projection.created ``` --- # 66. Ledger 不必物理集中 即使： $$ L_T $$ 是邏輯整體，也可以物理分散。 因此： $$ LogicalLedgerUnity \neq PhysicalSingleDatabase. $$ --- # 67. Trust Boundary General 與 Native runtime 不應因同一品牌就互相信任所有輸入。 需要： $$ TrustBoundary. $$ 每個 inbound object 至少驗證： - identity； - schema / contract； - authority； - digest； - receipt； - version。 --- # 68. Cross-Runtime Authentication 需要證明： $$ Runtime_A $$ 確實是允許的 peer。 但 authentication 只建立 peer identity，不建立 action authority。 因此： $$ AuthenticatedPeer \neq AuthorizedAction. $$ --- # 69. Cross-Runtime Security Profile 可定義： ```text read-only peer delegation peer migration peer full federation peer ``` 不同 profile 授予不同 interop capability。 --- # 70. Zero-Trust Interop 較安全預設： $$ DefaultPeerAuthority = 0. $$ 再透過 explicit grant 開啟。 這與： $$ Authority(PublicInput)=0 $$ 的既有 ANDO 原則一致。 --- # 71. Disaster Recovery Twin architecture 還可以形成異質 recovery。 例如： $$ GeneralRuntimeFailure \rightarrow NativeReadOnlyRecovery $$ 或反方向。 但 recovery copy 不等於 canonical ownership 自動轉移。 --- # 72. Recovery Promotion 若 backup runtime 要升為 writer： $$ ReadOnlyReplica \rightarrow CanonicalWriter, $$ 需要 promotion protocol。 例如： $$ VerifyLatestState \rightarrow AcquireOwnership \rightarrow FenceOldWriter \rightarrow Activate. $$ --- # 73. Split-Brain Risk 若兩邊都認為自己是 canonical writer： $$ Owner_G=1, $$ $$ Owner_H=1, $$ 可能形成： $$ SplitBrain. $$ 對 authority / commit domain，這是高風險 incident。 --- # 74. Writer Fencing 需要： $$ FenceToken $$ 或等價 ownership proof。 只有持有有效 writer authority 的 runtime 可提交 canonical mutation。 --- # 75. Human Governance Across Twins Human 不應需要理解所有 interop internals。 可顯示： ```text Migration ready 3 items degraded 1 authority mapping unresolved No history loss Proceed / Cancel / Inspect ``` 這是 Human-on-the-Bridge 的 cross-runtime 版本。 --- # 76. Human Override Human 可以： - reject migration； - lower authority； - require reverification； - choose read-only projection； - cancel handoff。 但不能直接把 historical Fail 改成 Pass。 --- # 77. Auditability of Migration 任何 migration decision 都應可回溯： $$ Decision \rightarrow Policy \rightarrow LossManifest \rightarrow Conformance \rightarrow Receipt_M. $$ --- # 78. Commercial Migration Product 對一般商業線，migration tooling 本身可以成為產品能力。 例如： ```text General Runtime Backup HDUS Import Wizard Twin Compatibility Report Enterprise Migration Planner ``` 這降低未來 lock-in 感。 --- # 79. Migration Optionality 再論 General-OS 使用者不必現在就遷移。 但知道存在： $$ ValidatedMigrationPath $$ 本身就有價值。 因此： $$ MigrationPathExistence \neq MigrationRequirement. $$ --- # 80. Long-Term Dual Deployment 某些組織可能永久採： $$ R_G + R_H. $$ 例如 Windows endpoint + HDUS native core。 這不是 transitional hybrid，而可能是穩定架構。 --- # 81. Endpoint/Core Split 可形成： $$ R_G^{edge} \leftrightarrow R_H^{core}. $$ General Runtime 負責： - local software； - browser； - user files； - legacy systems。 HDUS core 負責： - persistent world organization； - deep Agent collaboration； - native history； - native authority graph。 --- # 82. 反向配置也可能成立 某些場景可能： $$ R_H^{personal} \leftrightarrow R_G^{enterprise}. $$ 也就是個人使用 Native World，企業後端仍在 conventional infrastructure。 因此 twin architecture 不預設固定中心。 --- # 83. Commercial Co-Evolution 兩條產品線的商業需求不同： $$ Demand_G \neq Demand_H. $$ 但可共同回饋： $$ SemanticRoadmap. $$ 例如 General customers 對 audit 的需求，可以改善 Native governance；Native world 的新型 artifact relation，可以抽象成 General portable extension。 --- # 84. Innovation Extraction 從 Native feature 抽象到 PSK： $$ NativeFeature \rightarrow SemanticExtraction \rightarrow PortableExtension. $$ 只有 extraction 成功，才適合下放 General Runtime。 --- # 85. Compatibility Extraction 反方向： $$ GeneralConnectorPattern \rightarrow SemanticNeed \rightarrow NativeCapability. $$ 例如大量 General workflows 都需要 external identity binding，可能促使 Native Runtime 建立更好的 portable identity projection。 --- # 86. 不要求 Symmetric Feature 因此： $$ Feature_G \neq Feature_H $$ 是正常。 真正要求： $$ KernelInvariant_G = KernelInvariant_H. $$ --- # 87. Semantic Debt 如果某 runtime 暫時不能支援新 extension，可以記錄： $$ SemanticDebt. $$ 而不是假裝已完全相容。 例如： ```text PSK-Core: Full Verification 1.1: Partial Migration 0.2: ReadOnly ``` --- # 88. Compatibility Debt 定義： $$ D_C = \sum_i Weight_i \times MissingSemantic_i. $$ 這可成為 release / roadmap 指標。 --- # 89. Drift Detection 可以定期跑： $$ TwinConformanceSuite. $$ 若某 probe 從 Pass 變 Fail： $$ DriftDetected. $$ 應阻止宣稱 full compatibility。 --- # 90. Drift Repair 流程： $$ Detect \rightarrow Classify \rightarrow Localize \rightarrow Repair \rightarrow Reverify. $$ 不一定要兩邊同時改；應找出哪一端偏離 kernel。 --- # 91. Kernel Governance Portable Semantic Kernel 不應由任一 runtime 的 implementation convenience 單方面修改。 需要： $$ KernelChangeProposal. $$ 至少回答： - why semantic； - backward compatibility； - migration impact； - twin impact； - conformance changes。 --- # 92. Major 與 Minor Kernel Change 若只增加 optional field： $$ MinorChange. $$ 若改變： $$ AuthorityMeaning, CommitMeaning, VerificationMeaning, IdentityMeaning, $$ 則： $$ MajorChange. $$ --- # 93. Twin Release Independence 兩條產品線可以： $$ Release_G(t_1) $$ 與： $$ Release_H(t_2) $$ 不同步。 只要 compatibility matrix 明確即可。 --- # 94. Cross-Version Interop 若： $$ R_G(v_3) $$ 與： $$ R_H(v_5), $$ 只要共享： $$ K(v_2) $$ 與： $$ Interop(v_1), $$ 仍可能安全互通。 因此 runtime version 不等於 protocol version。 --- # 95. Downgrade 若 target 只支援舊 kernel： $$ K_1