桌面应用【免费下载链接】VortexVortex Development项目地址https://gitcode.com/gh_mirrors/vor/Vortex点击查看免费下载/watch-log是 Vortex 仓库内置的 Claude Code 技能专门用于观察和诊断 Vortex 的日志文件其中 Investigate 模式§B负责把多兆字节、带滚动、一次文件里混着多次运行的噪声日志压缩成一份以会话为边界的诊断报告应用如何终止、触发了哪些错误与告警、跨会话是否存在回归、重装或版本降级。读完本篇你可以完整复现 Investigate 模式的六步流程——定位作用域会话、通过发布时效门、记录会话元数据、输出会话级报告、计算跨会话信号、遵守报告规则——并理解每一步背后 Vortex 源码中的真实日志标记是怎么产生的。前置知识watch-log 技能的结构与日志格式技能定位一个薄路由器.claude/skills/watch-log/目录整体是一个按需加载的薄路由器SKILL.md只负责从用户请求中挑选模式reference.md承载核心事实日志格式、dev/prod/滚动日志集解析器而modes/下每个模式一个文件、shared/下是可复用知识块按需加载以保持上下文最小。Investigate 模式的完整定义在 modes/investigate.md其 Prereq 行声明了执行前必须加载的知识块reference.md核心shared/sessions.mdshared/edge-cases.md必备处理多个 / 外部文件foreign files时加载 shared/multi-file.md问题涉及 plugins / load order / LOOT 时加载shared/gamebryo.md。在 SKILL.md 的模式选择表中Investigate 的触发词是investigate / analyze / report / crashes / errors / warnings / session / what happened或一个日期/会话引用。一次调用可以选择多个模式如 investigate persistence此时日志集只解析一次并在所有模式间共享。日志行格式与滚动机制源码印证Investigate 模式的一切标记判断都建立在 Vortex 的日志格式之上。logging.ts 中的customFormatter输出了最终行格式TIMESTAMP [LEVEL] [SOURCE] message {json}两个对日志分析至关重要的细节都可以从源码直接确认等级是 4 字符 token。formatLogLevel 把debug/info/warn/error映射为[DEBG] [INFO] [WARN] [ERRO]——错误是[ERRO]不是[ERROR]。用[ERROR]去 grep 会漏掉全部错误行。来源是[MAIN]或[RENDERER]。格式化器把 metadata 里的process字段main | renderer见 logging.ts大写后写入行内renderer 侧的日志经 IPClogging:log见 logging.ts转发到主进程落盘。主进程的log()入口把 metadata 做JSON.stringify后追加在消息之后logging.ts这一点对后面的版本行为什么带引号很重要。滚动方面logging.ts 配置了 winston File transportconst LOG_MAX_SIZE 1024 * 1024 * 10; // 10 MB // winston.transports.File 参数 maxsize: LOG_MAX_SIZE, maxFiles: 5, tailable: true,即vortex.log是当前的最新文件滚动后产生vortex1.log、vortex2.log……编号越大越旧。reference.md 据此给出两条关键事实条目按时间顺序追加所以任何文件的尾部都是其最近的活动只有当会话开始于上次滚动之前、或用户要查历史时才需要进入更旧的滚动文件。每个日志目录里还有一份独立的network.log组装日志集时必须排除。第 1 步定位作用域会话scoped sessionInvestigate 的第一步是确定报告针对哪个会话。默认作用域是最新会话它位于当前vortex.log的尾部从文件末尾向前扫描最后一个开始锚点start anchor[INFO] [MAIN] Vortex Version …该锚点前有一行[INFO] [MAIN] --------------------------分隔线。这一对标记正是源码 Application.ts 中regularStartInner启动路径写下的log(info, --------------------------); log(info, Vortex Version, app.getVersion()); log(info, Parameters, process.argv.join( ));由于log()会对 metadata 做JSON.stringify字符串形式的版本号在日志里会带 JSON 引号——这就是[INFO] [MAIN] Vortex Version 1.99.0中引号的来源也意味着锚点引号内的值就是该会话的应用版本。向前扫到最后一个锚点后锚点 → 文件末尾EOF即最新会话。只有两种情况需要回看vortex1.log再往前vortex2.log……开始锚点不在vortex.log中会话开始于上次滚动之前回看是为了让会话保持连续用户要求查更早的会话或所有会话——此时按最旧→最新的顺序组装文件。对显式指定的作用域会话索引、日期/时间、all sessions要原样遵守不要擅自改成最新会话。按最旧→最新组装滚动文件reference.md 给出了一段可直接复制的 bash 解析器按后缀降序输出编号文件即最旧在前vortex.log最后D$APPDATA/vortex/main # 或 $APPDATA/Vortex或显式路径所在目录 { ls $D/vortex[0-9]*.log 2/dev/null \ | sed -E s/.*vortex([0-9])\.log/\1 / | sort -rn | cut -d -f2- ; \ echo $D/vortex.log ; }vortex[0-9]*与vortex.log两个 glob 天然排除了network.log。目录选择优先级为$ARGUMENTS中的显式文件路径 prod关键字prod 目录$APPDATA/Vortex/ 默认的dev目录$APPDATA/vortex/main/工作构建若本地根本没有安装如在 claude.ai 沙箱中运行则日志以上传文件形式到达此时多个文件一律加载shared/multi-file.md处理。第 2 步发布时效门release-currency gate会话枚举完成后、深入分析之前对prod / foreign 日志运行一次时效检查dev 目录跳过——dev 日志按定义就是当前环境如果会话集合中没有任何一个会话运行着最新 stable / 最新 beta或1.0.0dev 标记、或更新未发布的版本就明确警告用户日志已过时发现的问题大概率已不可复现/已被修复并先询问是否继续时效判定结论要写进最终报告。shared/sessions.md 给出了判定细节dev 构建标记记录Vortex Version 1.0.0的会话永远是 dev 构建dev 环境的占位版本一律视为当前版本绝不能当成2019 年的 1.0.0。比较单位是每个会话引用的Vortex Version值绝不是文件的 mtime 或文件名——一个滚动集可能混着升级和降级看起来很旧的文件里仍可能藏着当前会话。无gh/checkout 时可通过 GitHub API 取 releasesper_page15看prerelease标志与tag_name两个来源都不可达时明说时效检查被跳过而不是猜测。即便整套日志是当前的来自旧版本会话的发现也要标注该会话的版本因为可能已经修好的免责声明同样适用。第 3 步逐会话记录关键元数据对每个枚举出的会话记录开始时间戳、结束时间戳、持续时长、跨越哪些文件、终止状态、应用版本引号内的Vortex Version值、instanceId来自startup instance行以及[ERRO]与[WARN]的行数——后两者是第 5 步跨会话排名的输入。终止状态4 态分类shared/sessions.md强调不要把它塌缩成干净 vs 崩溃二分而是 4 态状态日志特征含义CleanVortex closing之后有clean application end正常退出完成Killed during exit有Vortex closing但下一次开始锚点 / EOF 之前没有clean application end典型 dev 停止、重启或调试器 kill不是硬崩溃Hard crash / abrupt完全没有Vortex closing会话在中途戛然而止真正的崩溃信号In progress最新会话、无退出标记、应用仍在运行不是崩溃要明确说明这两条标记的源码位置在 Application.ts 的window-all-closed处理器中语义非常清晰app.on(window-all-closed, () { log(info, Vortex closing); // 退出发起 finalizeMainWrite() // 持久化落盘 .then(() this.waitForRendererExit()) .then(() { log(info, clean application end); // 退出完成 DuckDBSingleton.getInstance().close(); this.mTray?.close(); ... }) .catch((err: unknown) { log(error, error finalizing write, unknownToError(err)); app.exit(1); }); });从源码结构看Vortex closing是退出流程已发起clean application end是主进程持久化写完成 renderer 退出确认之后的成功回执。因此有前者无后者正好对应进程在两者之间被外部杀死killed-during-exit而两者皆无才是硬崩溃。注意shared/sessions.md还指出一条经验法则prod 会话通常能走到clean application enddev 会话经常停在Vortex closingdev 日志常常不发出clean application end解读信号时要按目录加权。instanceId 的语义[DEBG] [MAIN] startup instance {instanceId:…}行携带 instanceId其源码在 Application.ts启动时从持久化apphive 读取instanceId首次启动无持久值则生成uuidv4并落盘同时记一条first startup, generated instance id。由此得出语义规则prod同一安装的 instanceId 跨重启稳定所以相邻会话之间 instanceId 变化 重装 / 全新安装devinstanceId 每次测试运行都可能换新变化属于噪声不当作重装会话边界仍然用开始/结束标记来切不用 instanceId 切分不同命名的外部文件若共享 instanceId说明可能是同一安装的滚动集见shared/multi-file.md。第 4 步输出会话级报告针对作用域会话报告依次包含四块终止状态 时间窗口与所跨文件。硬崩溃要显著标出calling out prominentlykilled-during-exit 作为较温和的 dev-stop 信号单独说明。[ERRO]行按归一化签名分组并给出计数归一化 去掉时间戳、路径、id、数字。告警按来源拆分[WARN] [RENDERER]renderer/UI 侧与[WARN] [MAIN]主进程侧。文档特别警告不要grep 裸的React字符串——它会误匹配 Reactions 之类的词必须依赖[WARN]等级 token。无等级 crash 签名Unhandled/uncaught/Traceback/FATAL这类可能出现在结构化 logger 之外的崩溃标记要一并扫出。第 5 步跨会话信号在保留下来的会话集合上按时间顺序计算四类信号最易出错会话排名按[ERRO][WARN]计数对保留会话排名展示第一名及其窗口与计数。如果最易出错会话不是作用域/最新会话要显著高亮并主动提议把报告作用域切到它——常见场景是最新会话只是一次简短的启动即退出真正的活动在更早的会话里。权重上[ERRO]高于[WARN]并且任何包含硬崩溃的会话无论计数多少都要单独标出。回归 / 潜在已修复days-apart 场景把每条错误/告警归一化成签名strip 时间戳、路径、id、数字后跨会话对比某签名存在于较早会话但不在最新会话中→ 高亮为potentially fixed — last seents, not in latest session某签名首次出现在最新会话 → 标记为 newly introduced。短会话降级规则short-session caveat如果作用域/最新会话非常短或几乎没被使用例如几分钟内的启动即退出或其[ERRO][WARN]计数只是最易出错会话的一小部分要把 potentially fixed降级为 not reproduced (session too short)——签名缺席几乎总是意味着这次没跑到而不是修好了。必须明确说出这一点并指用户去最易出错会话做真实对比。重装检测仅 prod当 instanceId 从上一个会话变化到下一个会话时在该边界高亮为re-install / fresh installprod 的 instanceId 本应跨重启稳定。dev 上跳过此检查——dev 的 instanceId 每次测试运行都换那里的变化不构成重装证据。版本降级逐会话追踪应用版本如果时间上更晚的会话运行着更低的 semver则高亮降级from hi down to lo at ts。当保留会话中出现超过 2 个不同版本且序列包含降级时要显著展示。纯粹的向前升级不标记。第 6 步报告规则Investigate 模式的收尾纪律每份报告必须说明它覆盖哪一个会话及精确时间窗口永远不静默混用会话只有用户说 all 或点名一个区间时才扩大范围且扩大后每条发现都要标注其所属会话最易出错会话、重装、降级、回归这些信号本质上是跨会话的——把它们放进一个简短的across sessions 附录与单会话报告主体明确分开。实操提示与适用边界结合 README 与 shared/edge-cases.md实战中常用的调用方式/watch-log investigate— 报告最新 dev 会话崩溃、错误、告警/watch-log investigate prod, all sessions— 完整 prod 历史 跨会话信号/watch-log investigate prod— 针对 prod 目录的最新会话此时时效门会被执行。几个边界情形的处理规定应用正在运行最新会话无结束标记这是 in progress 而不是崩溃要说明会话开始已被滚动冲掉最旧文件从会话中途开始注明 session start not in retained logs; window is partial多文件/外部文件shared/multi-file.md先用cmp -s去重字节相同的副本再用 instanceId 尝试把不同命名但共享 instanceId 的文件重组成一个滚动集需时间窗互斥、可衔接、版本连续佐证并在报告中说明顺序是 instanceId 推断的没有匹配不构成任何证明重装会发新 id未建立关联的文件之间禁止做回归 diff、重装/降级对比等跨会话信号。最后强调技能文档自身声明的定位Investigate 模式及整个 watch-log 技能是只读分析不修改日志或应用状态且专门针对 Vortex 的日志标记设计不是通用日志工具。小结Investigate 模式的方法论可以浓缩为一条主线先用Vortex Version锚点把旋转日志切成连续会话再用Vortex closing/clean application end四态判终止、用 instanceId 与版本行判重装与降级最后以归一化签名做会话内分组与跨会话回归对比并全程遵守单会话报告 跨会话附录的输出纪律。这套流程的每一个判断点——等级 token[ERRO]、引号包裹的版本值、1.0.0dev 标记、killed-during-exit 与硬崩溃的区分——都能在 src/main/src/logging.ts 与 src/main/src/Application.ts 的源码中找到一一对应的产生位置这正是该模式对 Vortex 日志可信且可复现的原因。赞分享桌面应用【免费下载链接】VortexVortex Development项目地址https://gitcode.com/gh_mirrors/vor/Vortex点击查看免费下载相关推荐Vortex 日志诊断技能 /watch-log旋转与会话感知的六模式排障路由器Vortex 日志诊断技能 /watch log旋转与会话感知的六模式排障路由器 本文聚焦 Vortex 仓库内置的 Claude Code 技能 /watc桌面应用Vortex 日志排查实战watch-log 技能的六模式路由、会话感知分析与日志到源码的关联Vortex 日志排查实战watch log 技能的六模式路由、会话感知分析与日志到源码的关联 Vortex 的日志文件按约 11 MB 滚动rotatio桌面应用Watchman 的 log-level 命令详解动态调整客户端会话日志级别Watchman 的 log level 命令详解动态调整客户端会话日志级别 log level 是 Watchman 提供给客户端的一条会话级命令用于实时后端开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考