DeepSeek-Reasonix 桌面端 App 组合边界架构解析App.tsx、AppRuntime 与分层守卫【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-ReasonixApp 组合边界App composition boundary是 DeepSeek-Reasonix 桌面端前端架构中最关键的一条代码组织约束它规定了入口组件App.tsx只能挂载运行时组合根AppRuntime由AppRuntime统一组合会话、导航与界面状态所有者再由AppRuntimeView渲染共享区域并通过 AST 分层检查与入口契约脚本将这条边界固化为可执行的 CI 规则。本文基于 docs/APP_SHELL.md 展开结合仓库源码深入讲解这条边界的设计意图、实现方式、验证命令与相关验收要求帮助读者理解如何在大型 React 桌面应用中避免第二套可变会话权限、保持 Hook 顺序与组件身份稳定。一、为什么需要组合边界问题背景在持续演进的桌面 AI 客户端中前端界面React 视图层与后端控制器runtime之间横跨着大量领域逻辑会话状态、标签页导航、终端面板、工作区 Dock、远程会话、草稿输入等。如果放任各模块随意访问全局入口或桥接层会出现两类典型问题权限分裂多个模块各自持有当前活动会话的引用并独立修改形成第二套可变权威second mutable active-session authority导致发送、取消、审批等动作被重定向到错误的会话Hook 顺序漂移在提取组件树或调整渲染结构时如果改变 Hook 调用顺序或组件身份component identityReact 的状态复用会被破坏草稿内容、滚动位置、输入焦点等 UI 状态随之丢失。APP_SHELL.md 给出的解决思路是一条清晰的三层分工App.tsx纯组合入口不包含任何业务逻辑AppRuntime组合根composition root负责装配会话、导航、shell 状态所有者并完成接线wiringAppRuntimeView纯装配视图只把组合产物渲染成共享区域自身不持有领域逻辑。二、入口契约App.tsx 只挂载 AppRuntime仓库中 desktop/frontend/src/App.tsx 的完整实现极其精简几乎就是文档契约的字面落实import { AppRuntime } from ./AppRuntime; /** * The application entry is intentionally a composition boundary. Runtime * ownership, domain commands and region view models live below this seam; * this module must remain free of bridge calls and async coordination. */ export default function App() { return AppRuntime /; }这段代码本身只有 10 行但它背后的约束由 desktop/frontend/scripts/check-app-entry-contract.mjs 以自动化脚本形式强制契约项脚本检查逻辑违反后果入口文件行数App.tsx超过 200 行即失败lines 200强制入口保持精简防止业务逻辑回流禁止直接访问桥接源码中出现app.如window.app.xxx或from ./lib/bridge即失败入口不得直连桌面桥接层禁止副作用与异步出现useEffect(或await即失败入口不得拥有 effect 或异步协调逻辑必须组合 AppRuntime必须存在from ./AppRuntime导入保证入口的唯一职责是挂载组合根脚本通过后输出app-entry-contract: App.tsx is a pure composition boundary任何一项失败都会以非零退出码阻断pnpm check:app-layers乃至pnpm build构建脚本将check:app-layers放在tsc --noEmit vite build之前见 desktop/frontend/package.json。三、AppRuntime组合根如何装配三大所有者AppRuntime是整个 App 的组合根。从 desktop/frontend/src/AppRuntime.tsx 的注释可以看到它的设计定位Composition root: owns the controller adapter, the session identity/fence, the navigation surface and every store-backed state, then delegates all command domains to the session/navigation compositions and the tree to the shell view.Wiring only — no domain logic lives here.具体来说AppRuntime 依次完成以下装配对应 desktop/frontend/src/AppRuntime.tsx运行时适配useRuntimeStateSync()同步 runtime 状态useAppRuntimeAdapter()提供{ state, liveStore, activeTabId, notice }快照会话身份与围栏通过sessionIdentityKey()计算当前活动会话身份tabId、sessionPath、sessionGeneration、scope、workspaceRoot、topicId并创建sessionSurfaceFence围栏在useLayoutEffect中提交/释放保证布局已提交的注册才拥有权限导航面useNavigationSurface()基于projectNavigationSurfaceTarget()投影出导航表面Shell 状态useAppShellStores()提供侧边栏、终端、工作区等界面状态 store会话组合useAppSessionComposition()汇总会话操作、命令域与本地 UI 生命周期导航组合useAppNavigationComposition()汇总导航/历史/主题命令交给视图最终把core / shell / session / navigation / runtime / local六组 props 一并传入AppRuntimeView /。这些组合函数各自独立成文件位于 desktop/frontend/src/app-runtime/ 目录下useAppSessionComposition.ts、useAppNavigationComposition.ts、useAppShellStores.ts、useAppRuntimeAdapter.ts、useRuntimeEventHandlers.ts、activeTabMirror.ts、WindowChromeLifecycle.tsx等。文档强调的副作用和来源绑定命令保留在对应领域模块在此得到体现——例如useSessionOperations()只负责会话操作注册setReasoningDisplayPending()这类启动期偏好设置也只在组合根顶层执行一次而非散落到视图组件中。四、AppRuntimeView纯装配视图与懒加载模块AppRuntimeView负责把组合产物渲染成共享区域。它的代码注释desktop/frontend/src/app-shell/AppRuntimeView.tsx明确说明Pure assembly of the App shell tree: every region receives its props from the session/navigation composition bags and the callers stores. No hooks beyond value memoization live here; ownership stays in the compositions.该视图自身只做值记忆化useMemo与样式类拼接所有命令与状态都来自组合结果。它把页面划分为以下共享区域模块均在 desktop/frontend/src/app-shell/ 下SidebarRegion侧边栏项目树、话题、设置入口TopicbarRegionTopicbarActionsStack话题栏与动作栈ChatPaneRegion会话主面板DecisionFooterRegion决策底栏发送/停止/撤销/待办WorkspaceDockRegion工作区 Dock文件变更、终端、媒体AppBottomRegions底部区域终端面板等AppOverlayHost覆盖层宿主历史面板、命令面板、会话恢复版本等。针对文档提到的上下文窗口展示辅助函数、延迟加载的子代理结果和预览卡片均独立为展示模块仓库中对应着两类证据一是懒加载隔离。AppRuntimeView自身对 Windows 窗口控件与 Dock 启动器使用React.lazydesktop/frontend/src/app-shell/AppRuntimeView.tsx#L38-L39AppOverlayHost懒加载历史面板、会话恢复版本、命令面板、Transcript 选择菜单等重组件desktop/frontend/src/app-shell/AppOverlayHost.tsx#L8-L16AppBottomRegions懒加载终端面板ChatPaneRegion懒加载远程会话表面与 IM 详情desktop/frontend/src/app-shell/ChatPaneRegion.tsx#L12-L13。二是控制器持有紧凑数据、展示时再解析的结果边界。文档明确控制器保留工具输出及实时事件的紧凑结果元组compact tuple历史结果文本只在懒加载卡片实际渲染时才解析从而保证最终展示结果和来源命令边界保持一致——渲染层无论如何懒加载、如何拆分都不改变控制器持有的数据形状与命令归属。五、AST 分层检查把依赖方向变成机器可判定的规则文档指出AST 层检查跟踪运行时导入、重导出、别名和动态导入拒绝领域/公共模块经传递依赖访问 App 所有者类型边单独处理并通过反例验证。这一契约由 desktop/frontend/scripts/check-app-layers.mjs 实现其核心机制是用 TypeScript 编译器 API 构建模块边moduleEdges见 check-app-layers.mjs#L17-L49对每个文件生成 AST收集 import 声明、export 重导出、import()动态导入、require调用与import 赋值解析出{ specifier, typeOnly }边同时收集标识符集合用于识别对 DOM/React 全局的引用解析模块解析链resolved通过ts.resolveModuleName把相对导入解析到实际文件再递归沿依赖链检查覆盖运行时导入、重导出、别名与动态导入的传递路径按目录分级施加规则检查对象为app-shell、app-runtime、app-features、app-domain四层目录以及lib/下的公共基础文件useCommittedCommand.ts、subscriptionScope.ts等并定义如下禁止方向领域层*Owner.ts、sessionTarget.ts、app-domain/*不得经任何传递链触及 DOM/React 对象window、document、HTMLElement、ReactNode等标识符领域层不得经运行时依赖引入react/react-dom或app-shell/components展示层非 shell 层不得经传递依赖触达app-shell/公共基础文件不得向上依赖app-runtime、app-features、app-shell类型边单独处理edge.typeOnly的导入边纯import type在检查中被直接跳过不参与运行时依赖判定——这正是文档类型边单独处理的含义同时domNames检测时排除了 DTO 字段名恰好叫window的合法场景见 check-app-layers.mjs#L24-L25反例验证desktop/frontend/scripts/check-app-layers.test.mjs 通过node --test内置测试框架对检查器本身进行负向用例验证确保这些违规模式确实会被拒绝。这条规则与入口契约脚本check-app-entry-contract.mjs、桌面宿主边界检查check-desktop-host-boundary.mjs共同组成了pnpm check:app-layers命令并被纳入pnpm build的前置步骤。六、单一会话权威为什么不能有第二套可变当前会话权限文档最核心的纪律是提取页面树必须保持 Hook 顺序、组件身份、草稿状态及命令注册且不能建立第二套可变的当前会话权限。其背后的会话所有权模型在 docs/APP_SESSION_OWNERSHIP.md 中有详细说明会话动作在发起时捕获来源source capture后续切换标签页不能把待发送、取消、审批、模型更新或导航完成重定向到新选中的会话布局已提交的命令注册才发布权限committed publication替换代数与卸载会撤销旧的续接后台取消解析的是规范控制器目标而非 UI 标签标识符。AppRuntime 负责把这些所有者session owner与 AppRuntimeView 接线视图只接收已提交的命令和展示数据——App.tsx作为小型组合入口从结构上杜绝了第二权威的诞生。落地到代码层面可以看到三重保护desktop/frontend/src/AppRuntime.tsxsessionSurfaceFenceRef以 ref 形式在整个组合根生命周期内保持唯一围栏实例useLayoutEffect中先fence.commit(activeTabId, activeSessionIdentity)再在卸载时dispose()保证权限提交与渲染时机对齐useSessionOperations只接收可见会话 资源会话列表操作永远针对显式传入的会话键而不是从全局读取。七、验证命令用测试把契约钉死文档给出的四组验证命令在 desktop/frontend/package.json 中均可找到对应脚本命令验证内容pnpm check:app-layers入口契约check-app-entry-contract.mjs、分层依赖检查check-app-layers.mjs 及其反例测试、桌面宿主边界检查是构建的前置门槛pnpm test:app-lifecycle覆盖来源捕获、已提交发布、超期supersession、A→B→A 导航、规范后台取消、卸载、订阅销毁与内存协议负向用例共约 40 组测试见 package.json#L47pnpm test:app-browser通过 Playwright 回放真实本地/远程导航、发送/停止、三种布局与 Composer/Workspace DOM 身份package.json#L48确保组件身份在运行时层面保持一致pnpm test:all聚合类型检查、状态、远程、性能等全部前端回归套件package.json#L46需要特别指出的是pnpm test:app-lifecycle中的node --test bench/app-memory-evidence.test.mjs、app-memory-shards、app-memory-paths等内存协议用例它们与文档末尾的独立 App 内存工作流相呼应该工作流构建一次干净提交由三个隔离 runner 各启动新的 Chromium 进程累计执行 128 全屏 128 窗口 128 安全 512 混合共 2688 次往返并要求三份分片身份、源/构建哈希、平台信息全部一致才给出聚合 PASS详见 docs/APP_SESSION_OWNERSHIP.md 的 Independent memory screening 一节。八、验收要求与后续工作文档明确指出pnpm check:app-layers、pnpm test:all、pnpm test:app-lifecycle、pnpm test:app-browser之外独立 App 内存工作流与原生 Transcript 门禁仍是验收要求required qualification。同时 docs/APP_SESSION_OWNERSHIP.md 补充了两点关于筛查协议的说明聚合 PASS 不等于整体内存无泄漏证明SHARD_PASS只代表单个完整进程通过堆保留链分析heap-retainer analysis与主分支对照归因mainline control comparison是分离的独立归因工作报告需保留其待定状态PR 头证据不能替代集成与原生检查针对目标分支的集成检查和原生nativeTranscript 检查仍需单独执行。九、小结边界即架构对 DeepSeek-Reasonix 桌面端而言App 组合边界不是一次性的代码规范而是一套可执行的工程系统App.tsx用 10 行代码守住入口纯净性AppRuntime以组合根身份统一装配三大所有者并保证单一会话权威AppRuntimeView以纯装配方式渲染共享区域并把重组件懒加载隔离AST 分层检查与四组验证命令在构建与 CI 两个层面持续施压。理解这条边界就理解了整个桌面前端如何在快速迭代中维持 Hook 顺序、组件身份、草稿状态与命令注册的稳定性——这正是大型 React 应用可长期演进而不腐化的底层保障。【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepSeek-Reasonix 桌面端 App 组合边界架构解析：App.tsx、AppRuntime 与分层守卫
DeepSeek-Reasonix 桌面端 App 组合边界架构解析App.tsx、AppRuntime 与分层守卫【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-ReasonixApp 组合边界App composition boundary是 DeepSeek-Reasonix 桌面端前端架构中最关键的一条代码组织约束它规定了入口组件App.tsx只能挂载运行时组合根AppRuntime由AppRuntime统一组合会话、导航与界面状态所有者再由AppRuntimeView渲染共享区域并通过 AST 分层检查与入口契约脚本将这条边界固化为可执行的 CI 规则。本文基于 docs/APP_SHELL.md 展开结合仓库源码深入讲解这条边界的设计意图、实现方式、验证命令与相关验收要求帮助读者理解如何在大型 React 桌面应用中避免第二套可变会话权限、保持 Hook 顺序与组件身份稳定。一、为什么需要组合边界问题背景在持续演进的桌面 AI 客户端中前端界面React 视图层与后端控制器runtime之间横跨着大量领域逻辑会话状态、标签页导航、终端面板、工作区 Dock、远程会话、草稿输入等。如果放任各模块随意访问全局入口或桥接层会出现两类典型问题权限分裂多个模块各自持有当前活动会话的引用并独立修改形成第二套可变权威second mutable active-session authority导致发送、取消、审批等动作被重定向到错误的会话Hook 顺序漂移在提取组件树或调整渲染结构时如果改变 Hook 调用顺序或组件身份component identityReact 的状态复用会被破坏草稿内容、滚动位置、输入焦点等 UI 状态随之丢失。APP_SHELL.md 给出的解决思路是一条清晰的三层分工App.tsx纯组合入口不包含任何业务逻辑AppRuntime组合根composition root负责装配会话、导航、shell 状态所有者并完成接线wiringAppRuntimeView纯装配视图只把组合产物渲染成共享区域自身不持有领域逻辑。二、入口契约App.tsx 只挂载 AppRuntime仓库中 desktop/frontend/src/App.tsx 的完整实现极其精简几乎就是文档契约的字面落实import { AppRuntime } from ./AppRuntime; /** * The application entry is intentionally a composition boundary. Runtime * ownership, domain commands and region view models live below this seam; * this module must remain free of bridge calls and async coordination. */ export default function App() { return AppRuntime /; }这段代码本身只有 10 行但它背后的约束由 desktop/frontend/scripts/check-app-entry-contract.mjs 以自动化脚本形式强制契约项脚本检查逻辑违反后果入口文件行数App.tsx超过 200 行即失败lines 200强制入口保持精简防止业务逻辑回流禁止直接访问桥接源码中出现app.如window.app.xxx或from ./lib/bridge即失败入口不得直连桌面桥接层禁止副作用与异步出现useEffect(或await即失败入口不得拥有 effect 或异步协调逻辑必须组合 AppRuntime必须存在from ./AppRuntime导入保证入口的唯一职责是挂载组合根脚本通过后输出app-entry-contract: App.tsx is a pure composition boundary任何一项失败都会以非零退出码阻断pnpm check:app-layers乃至pnpm build构建脚本将check:app-layers放在tsc --noEmit vite build之前见 desktop/frontend/package.json。三、AppRuntime组合根如何装配三大所有者AppRuntime是整个 App 的组合根。从 desktop/frontend/src/AppRuntime.tsx 的注释可以看到它的设计定位Composition root: owns the controller adapter, the session identity/fence, the navigation surface and every store-backed state, then delegates all command domains to the session/navigation compositions and the tree to the shell view.Wiring only — no domain logic lives here.具体来说AppRuntime 依次完成以下装配对应 desktop/frontend/src/AppRuntime.tsx运行时适配useRuntimeStateSync()同步 runtime 状态useAppRuntimeAdapter()提供{ state, liveStore, activeTabId, notice }快照会话身份与围栏通过sessionIdentityKey()计算当前活动会话身份tabId、sessionPath、sessionGeneration、scope、workspaceRoot、topicId并创建sessionSurfaceFence围栏在useLayoutEffect中提交/释放保证布局已提交的注册才拥有权限导航面useNavigationSurface()基于projectNavigationSurfaceTarget()投影出导航表面Shell 状态useAppShellStores()提供侧边栏、终端、工作区等界面状态 store会话组合useAppSessionComposition()汇总会话操作、命令域与本地 UI 生命周期导航组合useAppNavigationComposition()汇总导航/历史/主题命令交给视图最终把core / shell / session / navigation / runtime / local六组 props 一并传入AppRuntimeView /。这些组合函数各自独立成文件位于 desktop/frontend/src/app-runtime/ 目录下useAppSessionComposition.ts、useAppNavigationComposition.ts、useAppShellStores.ts、useAppRuntimeAdapter.ts、useRuntimeEventHandlers.ts、activeTabMirror.ts、WindowChromeLifecycle.tsx等。文档强调的副作用和来源绑定命令保留在对应领域模块在此得到体现——例如useSessionOperations()只负责会话操作注册setReasoningDisplayPending()这类启动期偏好设置也只在组合根顶层执行一次而非散落到视图组件中。四、AppRuntimeView纯装配视图与懒加载模块AppRuntimeView负责把组合产物渲染成共享区域。它的代码注释desktop/frontend/src/app-shell/AppRuntimeView.tsx明确说明Pure assembly of the App shell tree: every region receives its props from the session/navigation composition bags and the callers stores. No hooks beyond value memoization live here; ownership stays in the compositions.该视图自身只做值记忆化useMemo与样式类拼接所有命令与状态都来自组合结果。它把页面划分为以下共享区域模块均在 desktop/frontend/src/app-shell/ 下SidebarRegion侧边栏项目树、话题、设置入口TopicbarRegionTopicbarActionsStack话题栏与动作栈ChatPaneRegion会话主面板DecisionFooterRegion决策底栏发送/停止/撤销/待办WorkspaceDockRegion工作区 Dock文件变更、终端、媒体AppBottomRegions底部区域终端面板等AppOverlayHost覆盖层宿主历史面板、命令面板、会话恢复版本等。针对文档提到的上下文窗口展示辅助函数、延迟加载的子代理结果和预览卡片均独立为展示模块仓库中对应着两类证据一是懒加载隔离。AppRuntimeView自身对 Windows 窗口控件与 Dock 启动器使用React.lazydesktop/frontend/src/app-shell/AppRuntimeView.tsx#L38-L39AppOverlayHost懒加载历史面板、会话恢复版本、命令面板、Transcript 选择菜单等重组件desktop/frontend/src/app-shell/AppOverlayHost.tsx#L8-L16AppBottomRegions懒加载终端面板ChatPaneRegion懒加载远程会话表面与 IM 详情desktop/frontend/src/app-shell/ChatPaneRegion.tsx#L12-L13。二是控制器持有紧凑数据、展示时再解析的结果边界。文档明确控制器保留工具输出及实时事件的紧凑结果元组compact tuple历史结果文本只在懒加载卡片实际渲染时才解析从而保证最终展示结果和来源命令边界保持一致——渲染层无论如何懒加载、如何拆分都不改变控制器持有的数据形状与命令归属。五、AST 分层检查把依赖方向变成机器可判定的规则文档指出AST 层检查跟踪运行时导入、重导出、别名和动态导入拒绝领域/公共模块经传递依赖访问 App 所有者类型边单独处理并通过反例验证。这一契约由 desktop/frontend/scripts/check-app-layers.mjs 实现其核心机制是用 TypeScript 编译器 API 构建模块边moduleEdges见 check-app-layers.mjs#L17-L49对每个文件生成 AST收集 import 声明、export 重导出、import()动态导入、require调用与import 赋值解析出{ specifier, typeOnly }边同时收集标识符集合用于识别对 DOM/React 全局的引用解析模块解析链resolved通过ts.resolveModuleName把相对导入解析到实际文件再递归沿依赖链检查覆盖运行时导入、重导出、别名与动态导入的传递路径按目录分级施加规则检查对象为app-shell、app-runtime、app-features、app-domain四层目录以及lib/下的公共基础文件useCommittedCommand.ts、subscriptionScope.ts等并定义如下禁止方向领域层*Owner.ts、sessionTarget.ts、app-domain/*不得经任何传递链触及 DOM/React 对象window、document、HTMLElement、ReactNode等标识符领域层不得经运行时依赖引入react/react-dom或app-shell/components展示层非 shell 层不得经传递依赖触达app-shell/公共基础文件不得向上依赖app-runtime、app-features、app-shell类型边单独处理edge.typeOnly的导入边纯import type在检查中被直接跳过不参与运行时依赖判定——这正是文档类型边单独处理的含义同时domNames检测时排除了 DTO 字段名恰好叫window的合法场景见 check-app-layers.mjs#L24-L25反例验证desktop/frontend/scripts/check-app-layers.test.mjs 通过node --test内置测试框架对检查器本身进行负向用例验证确保这些违规模式确实会被拒绝。这条规则与入口契约脚本check-app-entry-contract.mjs、桌面宿主边界检查check-desktop-host-boundary.mjs共同组成了pnpm check:app-layers命令并被纳入pnpm build的前置步骤。六、单一会话权威为什么不能有第二套可变当前会话权限文档最核心的纪律是提取页面树必须保持 Hook 顺序、组件身份、草稿状态及命令注册且不能建立第二套可变的当前会话权限。其背后的会话所有权模型在 docs/APP_SESSION_OWNERSHIP.md 中有详细说明会话动作在发起时捕获来源source capture后续切换标签页不能把待发送、取消、审批、模型更新或导航完成重定向到新选中的会话布局已提交的命令注册才发布权限committed publication替换代数与卸载会撤销旧的续接后台取消解析的是规范控制器目标而非 UI 标签标识符。AppRuntime 负责把这些所有者session owner与 AppRuntimeView 接线视图只接收已提交的命令和展示数据——App.tsx作为小型组合入口从结构上杜绝了第二权威的诞生。落地到代码层面可以看到三重保护desktop/frontend/src/AppRuntime.tsxsessionSurfaceFenceRef以 ref 形式在整个组合根生命周期内保持唯一围栏实例useLayoutEffect中先fence.commit(activeTabId, activeSessionIdentity)再在卸载时dispose()保证权限提交与渲染时机对齐useSessionOperations只接收可见会话 资源会话列表操作永远针对显式传入的会话键而不是从全局读取。七、验证命令用测试把契约钉死文档给出的四组验证命令在 desktop/frontend/package.json 中均可找到对应脚本命令验证内容pnpm check:app-layers入口契约check-app-entry-contract.mjs、分层依赖检查check-app-layers.mjs 及其反例测试、桌面宿主边界检查是构建的前置门槛pnpm test:app-lifecycle覆盖来源捕获、已提交发布、超期supersession、A→B→A 导航、规范后台取消、卸载、订阅销毁与内存协议负向用例共约 40 组测试见 package.json#L47pnpm test:app-browser通过 Playwright 回放真实本地/远程导航、发送/停止、三种布局与 Composer/Workspace DOM 身份package.json#L48确保组件身份在运行时层面保持一致pnpm test:all聚合类型检查、状态、远程、性能等全部前端回归套件package.json#L46需要特别指出的是pnpm test:app-lifecycle中的node --test bench/app-memory-evidence.test.mjs、app-memory-shards、app-memory-paths等内存协议用例它们与文档末尾的独立 App 内存工作流相呼应该工作流构建一次干净提交由三个隔离 runner 各启动新的 Chromium 进程累计执行 128 全屏 128 窗口 128 安全 512 混合共 2688 次往返并要求三份分片身份、源/构建哈希、平台信息全部一致才给出聚合 PASS详见 docs/APP_SESSION_OWNERSHIP.md 的 Independent memory screening 一节。八、验收要求与后续工作文档明确指出pnpm check:app-layers、pnpm test:all、pnpm test:app-lifecycle、pnpm test:app-browser之外独立 App 内存工作流与原生 Transcript 门禁仍是验收要求required qualification。同时 docs/APP_SESSION_OWNERSHIP.md 补充了两点关于筛查协议的说明聚合 PASS 不等于整体内存无泄漏证明SHARD_PASS只代表单个完整进程通过堆保留链分析heap-retainer analysis与主分支对照归因mainline control comparison是分离的独立归因工作报告需保留其待定状态PR 头证据不能替代集成与原生检查针对目标分支的集成检查和原生nativeTranscript 检查仍需单独执行。九、小结边界即架构对 DeepSeek-Reasonix 桌面端而言App 组合边界不是一次性的代码规范而是一套可执行的工程系统App.tsx用 10 行代码守住入口纯净性AppRuntime以组合根身份统一装配三大所有者并保证单一会话权威AppRuntimeView以纯装配方式渲染共享区域并把重组件懒加载隔离AST 分层检查与四组验证命令在构建与 CI 两个层面持续施压。理解这条边界就理解了整个桌面前端如何在快速迭代中维持 Hook 顺序、组件身份、草稿状态与命令注册的稳定性——这正是大型 React 应用可长期演进而不腐化的底层保障。【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考