桌面应用【免费下载链接】VortexVortex Development项目地址https://gitcode.com/gh_mirrors/vor/Vortex点击查看免费下载本文基于 Vortex 仓库watch-log技能包中的 §F 模式文档 collection-install.md讲解如何对一个“集合collection安装”做完整日志审计从识别安装信封envelope、逐成员生命周期追踪到“是否完全安装”的可计算判定以及九大安装完成不变量各自的破坏签名。读完本文你可以照着 Steps 六步流程把一次 Vortex 集合安装从日志中审计成一份“每个问题都有名字”的结论报告并对应的源码锚点都能定位到具体文件。1. 定位§F 是什么和 §E 有何不同§F 是 watch-log 技能 的六种分析模式之一。它的前置知识来自三份文档reference.md核心、shared/lifecycle.md生命周期标记与 shared/sessions.md会话边界与终止分类。§Etrace 模式沿一个实体追踪它在哪里卡住§F 则对整个集合安装做审计对照安装完成不变量install-completion invariants找出具体破坏了哪一条。审计范围默认限定在一个会话内默认最新会话按 §B 规则界定且必须在报告中明确说明用的是哪个会话。文档还给出一个关键提醒日志文本会随代码演进漂移log text drifts在依赖“某条消息缺失”作为结论前必须先 grep 各表中列出的源码文件确认消息字符串仍然存在。这些不变量是 LAZ-483 建立的契约因此对 dev 集合安装运行同一套审计同时就是一份483 回归检查。2. 识别目标集合审计的第一步是确定“审哪个集合”Identify the collection从用户参数$ARGUMENTS中取得集合名/ID或“the collection install”这类泛指若都没有就在限定范围内的日志中 grepstarting install of collection列出候选项带上collationId与totalMods供用户选择成员member线程靠modId/referenceTag/collationId以及安装日志上携带的sourceModId即 collection id来串联。starting install of collection锚点的真实出处是集合安装驱动器 InstallDriver.ts#L1023-L1026log(info, starting install of collection, { totalMods: required.length, missing: this.requiredMods.length, });注意这里的totalMods取的是必需成员总数required.length而missing是本次运行开始前仍需安装的成员数——这两个数字正是第 5 节“完全安装判定”公式的输入。3. 信封集合级生命周期锚点集合级信封envelope由以下日志锚点构成它们把一次集合安装框成一段可验证的时间线Envelope日志消息出处含义starting install of collection {totalMods, missing}InstallDriverInstallDriver.ts#L1023安装起点锚did install dependencies {modId}InstallDriverInstallDriver.ts#L674依赖阶段完成add collection rulepostprocessCollectionpostprocessCollection.ts#L57集合排序规则已应用postprocess collectionpostprocessCollectionpostprocessCollection.ts#L83成功终态锚pause collection/resume collection/failed to pause collection/User logged out during collection install, pausingcollections/index.ts如 L364、L1604暂停/恢复/登出暂停already installing a collectionInstallDriverInstallDriver.ts#L402第二次安装请求被拒绝从源码结构看postprocessCollection之所以是“成功终态锚”是因为它做完了集合安装收尾的全部事情先log(info, postprocess collection)再应用modRules排序规则每条新规则打出add collection rule然后触发deploy-mods部署并调用各扩展的parse钩子postprocessCollection.ts#L76-L104。因此“到达postprocess collection”在日志上等价于“集合安装走到了终态”。4. 逐成员生命周期与 SSOT 状态每个成员依赖的通用安装标记沿用 shared/lifecycle.md 中 §E 使用的序列start mod install → installing to {modId, destinationPath} → extracting mod archive → invoking installer → finish mod install {outcome} → Installation completed successfully {installId, modId, duration}它们分别落在 InstallContext.ts#L174start mod install、InstallManager.ts#L1707installing to、InstallManager.ts#L3977extracting mod archive、InstallManager.ts#L4112invoking installer与 InstallManager.ts#L1221Installation completed successfully。集合侧的“下载-安装交接”由 InstallManager 打出Found collection for downloadInstallManager.ts#L703与Found collection for failed downloadInstallManager.ts#L794。这里有一条审计上的重要边界SSOT 状态写入本身不打日志。{type:status, status:downloaded|failed|...}这类状态写入通过writeCollectionSession实现见 collectionSessionWrite直接落到会话 hivestate.session.collections不是日志字符串。所以要“观察”这些状态只能通过上述安装生命周期日志间接推断必要时借助persist:diff {hive:session}的到达记录§C 的标记持久化通道见 persistenceIPC.ts#L29。5. 完全安装判定每份报告必须回答每份集合审计报告必须显式回答一个判词该集合是否“完全安装”fully installed——不能只说“本次运行结束了”。计算方式Fully-installed verdict从信封数字入手starting install of collection {totalMods, missing}给出成员总数与开始时仍需安装的数量因此totalMods - missing在本次运行前已经安装统计限定窗口内打出Installation completed successfully的成员数得installed (totalMods - missing) completed-this-run。三类结论Fully installed—— 到达postprocess collection且installed totalMods没有失败/卡住的成员Completed, not fully installed—— 到达 postprocess 但有缺口须点名X 个失败、Y 个 skipped-or-unaccounted。注意totalMods包含可选recommends成员而可选成员默认跳过InstallDriver.ts#L1004-L1012 中对未显式决策的 optional 调用markCollectionMemberSkipped跳过用户跳过、可选默认只写会话状态成功路径没有日志行——所以“没有安装线程、也没有失败”的成员应归类为 “skipped or unaccounted”本身不是错误。唯一的跳过日志出现在失败路径could not find collection rule for skipped downloadcollectionSkip.ts#L138Not completed—— 从未到达postprocess collection卡住/被打断/被搁置按不变量 9 分类同样给出上述计数。6. 九大不变量与破坏签名下面是完整不变量表——健康安装必须成立的事实以及每条被破坏时在日志里出现的签名Invariants to assert#不变量健康安装成立的事实日志中的破坏签名源码位置1每个成员都到达终态installed 或 failedCalled callback for stuck installation某成员卡在 installing或 stall-rescue 流程触发Collection install stalled, attempting rescue之后出现Collection install stalled after rescue attempt, resolving安装器强制解析了停滞阶段成员可能被留在非终态InstallManager2失败的下载会把成员结算为 failed并让阶段继续推进Found collection for failed download之后没有跟随的成员 failed 结算或Collection is not currently installing - ignoring download failure在集合确实在安装时触发InstallManagerhandleDownloadFailedInstallManager.ts#L775-L8473没有重排循环requeue loop同一modId的start mod install运行次数超过MAX_DEPENDENCY_RETRIES值为 3定义于 InstallManager.ts#L567InstallManager4磁盘满会让成员终结性地失败解压遇到磁盘满但成员既没完成也没打出 Not enough disk space 终态失败失败模式requeue → skip → stuckInstallManagerInsufficientDiskSpace抛出点 InstallManager.ts#L40145孤儿归档磁盘上有文件、无下载记录在重新下载前被对齐reconcile磁盘上存在孤儿归档但依赖下载停滞时没有出现reconciling orphaned archive before download {fileName, gameId}reconcileOrphanedArchive.ts#L39reconcileOrphanedArchive.ts6集合到达 postprocess有starting install of collection但会话结束前没有postprocess collection/did install dependencies阶段卡死或Error during scheduled phase deployment某阶段部署失败可能阻塞推进InstallManager / InstallDriver / postprocessCollection7暂停/恢复与登出是干净的pause collection/ 登出暂停没有配对的resume collection或出现failed to pause collectioncollections/index.ts8进度值保持合理下载/安装进度值超过 100免费用户路径上 101/100 的freeUserDownloadPosition失败见 collectionInstallSession.ts#L55InstallManager 免费用户路径9被打断的安装不丢进度用户主动的 resume 保留已完成成员重启前打出过Installation completed successfully的成员在重启后被重装进度丢失或resume collection重跑已完成成员/无法继续。注意resume 是用户主动的因此没有resume collection的搁置parked安装不是失败会话 SSOTstate.session.collections不变量 2 值得对照源码理解handleDownloadFailed在确认集合正在安装后会打聚合通知然后必须调用writeCollectionSession(..., { type: status, status: failed })结算成员并maybeAdvancePhaseInstallManager.ts#L836-L846——代码注释明确说明终结性的下载失败不会被重排若不结算成员会一直停在 downloading 并被 Failed 过滤器漏掉。这正是破坏签名“failed download 之后没有成员 failed 结算”的含义。同理不变量 3/4 对应依赖错误恢复的决策树planDependencyErrorRecoveryInsufficientDiskSpace与安装自身产生的ProcessCanceled被判为不可重试重试注定重蹈覆辙直接结算为 failed普通瞬时错误则在MAX_DEPENDENCY_RETRIES3内 requeueInstallManager.ts#L2675-L2708。6.1 停滞、救援与关键错误信号安装器内置了 stall 检测安全网以下信号一旦出现必须上报Stall, rescue, and critical-error signalsCollection install stalled, attempting rescue {sourceModId}[WARN]InstallManager.ts#L2833——某阶段停滞首次超时救援进行中。还不是失败但是预警信号。对应实现是pollAllPhasesComplete的 5 分钟无进展超时STALL_TIMEOUT_MS 5 * 60 * 1000InstallManager.ts#L2795-L2858首次超时会forceCleanupStuckInstalls并视需要重排已下载成员Collection install stalled after rescue attempt, resolving {sourceModId}[WARN]InstallManager.ts#L2861——救援未能解除阻塞第二次超时安装器强制解析该阶段。该阶段的成员可能停留在非终态须结合逐成员汇总找出是哪些并按停滞关联不变量 1/6上报Critical error in dependency installation {downloadId, sourceModId}[ERRO]InstallManager.ts#L2756——依赖安装抛出了未捕获异常要确认成员是结算为failed而不是卡死Error during scheduled phase deployment {sourceModId}[WARN]InstallManager.ts#L3443——某阶段部署失败关联不变量 6Download not found when trying to resume {intendedId}[WARN]InstallManager.ts#L6388——resume 时某个预期成员的下载缺失关联不变量 9resume 完整性。6.2 不变量 9 — 中断与恢复数据丢失观测这是会话 SSOT 的核心承诺LAZ-483 建立的保证被重启/崩溃打断的安装恢复时应从会话状态继续不重做也不丢失已完成成员。每次中断都必须上报它是真实信号严重度框架如下Invariant 9检测中断一次starting install of collection其会话在集合到达postprocess collection之前结束下一个Vortex Version启动锚或无postprocess collection的 EOF。会话边界标记见 Application.ts#L213-L217Vortex closing→clean application end与 Application.ts#L465Vortex Version。边界分类沿用 shared/sessions.md / §B 的四态终止分类不要塌缩成 clean-vs-crashcleanVortex closing→clean application endkilled-during-exit有Vortex closing无 clean end典型于 dev 停止/重启/调试器杀进程hard-crash完全没有Vortex closing会话直接结束——真正的崩溃信号in-progress最新会话应用仍在运行严重度prod日志目录$APPDATA/Vortex/每次中断都是发现finding。安装中途硬崩溃是崩溃 bugclean/killed 退出则是 resume 正确性与数据丢失隐患需持续跟踪dev日志目录$APPDATA/vortex/main/中断某种程度是预期的开发者重启测试机要报告但标注为预期——除非开发者明确表示这次重启不是故意的此时按 prod 对待硬崩溃尤其如此。Resume 进度丢失检查在边界之后的会话里找resume collectioncollections/index.ts#L1604或同一集合的新starting install of collection看它是否到达postprocess collection。然后比较边界之前打出Installation completed successfully的成员modId与边界之后重跑start mod install/ 完成安装的成员重启前已完成的成员被重装 进度丢失/数据丢失SSOT 未保住它们——无论 dev/prod 一律上报已完成成员在 resume 时被正确跳过 SSOT 保住了进度通过没有任何resume collection parked等待用户恢复——不是失败resume 是用户主动行为。报告为 parked/incomplete而非 stuck。prod 监控视角对 prod 日志这条不变量就是集合安装可靠性的现场信号。对每个被打断的安装报告边界类别、恢复后是否保留了“N 中已完成 M”式的进度无重做、resume 本身是否成功。硬崩溃边界、或任何“已完成成员被重装”数据丢失都是要升级处理的真实发现无恢复尝试的 clean 退出则是良性的。此外要上报“下载事件找不到归属”的诊断性忽略日志——某成员附近成批出现时是不变量 1 或 2 即将被破坏的强提示No collection mod found for sourceModIdInstallManager.ts#L352No active collection installation foundInstallManager.ts#L374No matching rule found in collection for downloadInstallManager.ts#L382Collection mod not found in stateInstallManager.ts#L390Skipping download failure - download not foundInstallManager.ts#L7807. 审计步骤Steps按 Steps 执行解析日志集并按 §B 限定到会话找到集合信封构建逐成员汇总对每个成员线程modId记录到达的阶段、结果completed / failed /stuck、完成时的duration若有以及重试次数该modId的start mod install出现次数;逐条走不变量表每个破坏点引用成员、匹配行与时间戳。“没有终态”视为 stuck不变量 1/6不是成功计算完全安装判定信封是否到达 postprocessinstalled (totalMods - missing) completed-this-run对totalMods缺口按 failed / stuck / skipped-or-unaccounted 分类报告信封结果是否到达postprocess collection以及任何暂停/恢复/登出转移是否配对。若未到达 postprocess则执行不变量 9找出结束它的会话边界、分类clean / killed-during-exit / hard-crash / in-progress、检查后续会话的 resume 与进度丢失并套用 dev/prod 严重度框架列出窗口内[ERRO]/[WARN]中 payload 引用到成员的那些。8. 输出格式Output shape一份合规的 §F 审计输出包含以下要素Output shape一行判词回答“该集合是否完全安装”fully installed / completed-not-fully-installed / not completedstuck/ interrupted / parked并附成员计数installed / failed / skipped-or-unaccounted / stuck共totalMods逐成员表modId· 到达阶段 · 结果 · 时长 · 重试次数不变量结果1–9 每条 pass /FAIL附违规行本会话未走到的路径标 n/a信封时间线start → did install dependencies → add rule → postprocess带 Δ 时间外加暂停/恢复/登出事件中断若有边界分类clean / killed / hard-crash / in-progress、是否 resume 并到达 postprocess、进度丢失结论重做 vs 保留按严重度框架写明 dev-expected 还是真实发现prod 一律视为发现异常清单requeue 循环、stuck 成员、孤儿归档停滞、进度 100、忽略下载成批出现、resume 时的数据丢失。9. 小结§F 把“这次集合安装到底成不成功”从一个模糊印象变成了可验证的判定信封锚点给出骨架逐成员汇总给出明细九大不变量对应 InstallManager.ts、InstallDriver.ts、postprocessCollection.ts、collections/index.ts、reconcileOrphanedArchive.ts 等实现给出可 grep 的破坏签名而不变量 9 则把重启/崩溃边界与数据丢失连成一条可审计的链。对 dev 安装同一套审计顺带就是 LAZ-483 契约的回归检查。使用时注意两个前提审计窗口按 shared/sessions.md 限定到单个会话且依赖“消息缺失”的结论前必须先确认对应日志字符串仍在源码中存在。赞分享桌面应用【免费下载链接】VortexVortex Development项目地址https://gitcode.com/gh_mirrors/vor/Vortex点击查看免费下载相关推荐DInvoke vs PInvoke性能、安全性与灵活性的终极对比DInvoke vs PInvoke性能、安全性与灵活性的终极对比 在.NET开发中调用非托管代码是一项常见需求而DInvoke与PInvoke作为两种主Warp 变更日志语言审查Towncrier 片段措辞审查的三类标记、判断哲学与审计实践Warp 变更日志语言审查Towncrier 片段措辞审查的三类标记、判断哲学与审计实践 Warp 仓库用 Towncrier 片段 changelog/高性能计算物理引擎图形学机器人Velog数据可视化文章统计与阅读量分析功能完全指南Velog数据可视化文章统计与阅读量分析功能完全指南 Velog作为韩国最受欢迎的开发者博客平台提供了强大的数据可视化功能帮助博主深入了解文章表现。本文将前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
