KanBox 的稳定性改进、Mix Space 的维护与 Whisp 的项目介绍 今天的工作横跨了几个项目：继续打磨 KanBox，维护基于 Mix Space 和 Yohaku 的个人博客，为 Whisp 发布项目介绍，迭代 Coralbay Rules，并把 MovieClaw 接入已有的下载器与 Plex 媒体库。这些项目反复遇到同一个问题：功能能够运行，并不代表它已经可靠。解析结果可能不完整，异步回调可能写错对象，缓存可能不断增长，自动清理可能误删数据，项目介绍也可能把“代码里已经存在”误写成“用户已经可以使用”。今天继续完善这些基本能用的功能，明确它们的适用范围，补充验证，并让失败后的数据能够恢复。KanBox 的解析与重新解析KanBox 今天的开发从几个真实使用问题开始，没有先增加新功能。旧版社交内容解析器倾向于收集页面中出现的全部媒体，因此正文图片、评论头像和回复图片可能混在一起。遇到带登录限制的页面时，又可能只取得正文或封面，却让界面看起来像已经得到了完整视频。新的解析逻辑不再把“页面里出现过”当成“属于目标内容”，而是根据正文结构和媒体归属关系进行筛选。无法取得真实视频地址时，结果会明确标记为“部分解析”，不再用封面图片冒充视频。KanBox 还增加了手动重新解析入口，但重新解析只刷新作者信息、媒体地址和封面等派生字段，不覆盖用户自己修改过的正文、标签与笔记。这样既能修复过期数据，也不会因为重新抓取而损失人工整理的内容。在线播放和下载保存也被拆成了两条独立能力：播放器能够播放网络视频，只能证明在线地址可用；只有媒体文件真正被下载、校验并写入本地后，才能算作离线保存完成。代码和验收记录中不再把这两件事混为一谈。用内容身份隔离迟到的异步回调今天修复的另一组问题集中在保存、分享、解析和删除之间的竞态。旧实现中，连续点击可能启动多个相同任务。用户已经切换到下一条内容后，上一条内容较晚完成的回调仍可能更新当前页面；内容已经删除后，旧页面也可能继续尝试保存笔记或输出图片。新的实现限制每项操作只能启动一个有效任务，并校验内容身份。任务启动时记录当前内容的唯一标识，提交结果前再检查一次：页面仍然显示同一条内容、这项任务仍是当前有效任务、内容没有被删除，并且没有更新的操作取代它。任一条件不成立，迟到结果就会被丢弃。内容删除成功后，相关页面也会立即停止接受保存、分享和重新解析操作。连续随机回顾采用了相同思路。开始一次回顾时，KanBox 会冻结当前筛选结果的标识列表，只洗牌一次；上一条、下一条沿历史移动，新增加的收藏不会突然插入当前轮次，已删除的内容则从候选和历史中移除。这样避免了回顾过程中重复抽取或进度跳动。备份恢复的文件校验与事务KanBox 的备份恢复也做了更严格的安全处理。旧流程的重点是压缩包能否读取；现在会在写入前检查 ZIP 边界、CRC、文件名、内容标识、图片路径和同名冲突。包含目录穿越、软链接越界或同名不同内容的备份会直接拒绝，不能借恢复流程覆盖应用目录之外的文件。真正写入时使用独立的数据事务。恢复失败只回滚本次新建的内容和图片，不影响用户正在编辑但尚未提交的其他数据。缺失原图的收藏也不会被包装成一份“完整备份”。本地图片路径同样经过规范化：只有确认位于 KanBox 管理目录内的文件才允许读取，目录外路径、越界路径和符号链接不会进入图片加载的回退逻辑。恢复现在只接受结构完整、路径安全且能原子提交的备份，不再只检查文件能否导入。SwiftUI 长列表与图片缓存KanBox 的性能问题主要出现在长列表和图片画廊。旧实现虽然使用了滚动容器，但访问过的 SwiftUI 行状态会逐渐累积。列表显示图片时，也可能过早解码接近原图尺寸的内容；预取和屏幕显示同时请求同一地址时，还会发生重复下载。新的实现分三处调整。首页、搜索结果和作者页面改为真正的懒加载或分段渲染，离开屏幕较远的行不再一直保留完整显示状态。画廊、网格和单列根据各自布局控制可见窗口，而不是一次为数千条内容建立完整视图状态。其次，图片加载分成“原始字节”和“显示缩略图”两层。列表通过 ImageIO 按实际显示尺寸生成缩略图，并设置最大边长；原始图片字节继续留给全屏查看、保存和分享。缩略图缓存有明确的容量和内存预算，不再让 NSCache 成为没有边界的黑盒。最后，下载层加入了 single-flight 式的请求合并。同一个地址如果同时被预取、头像和可见卡片请求，只创建一个实际下载任务，其他调用者共享结果。并发预取也设置了上限，避免快速滚动时瞬间启动大量任务。在约五千条隔离数据的同场景对照中，内存峰值和结束值从约 155 MiB 降到约 75 MiB，堆内存从约 116 MiB 降到约 48 MiB，持续持有的行状态从三千多份下降到一百多份。针对数百张独立图片的搜索页、作者页和画廊复测也已通过。不过，b15 性能候选仍在进行多轮触底、回顶和静置测试。当前测试表明修改方向有效，但还不足以确认所有内存增长都已解决，因此它暂时没有覆盖安装到手机。手机目前保留在已经完成验收的稳定版本。每次升级前都先备份应用与共享数据容器，覆盖安装后再检查数据库完整性、内容数量和内容标识，不通过卸载重装来掩盖迁移问题。Mix Space：裂图、超时和邮件头像是三个不同问题博客使用 Mix Space 作为后端、Yohaku 作为前端。今天遇到的图片裂图、上传超时和邮件头像异常，表面相似，实际来自完全不同的层级。留言图片裂图的原因是对象存储路径被重复拼接。链接生成逻辑把已经包含存储前缀的对象键再次附加到基础目录后面，导致错误地址返回 404；去掉重复部分后，同一个对象可以正常返回 200。这说明问题不在证书和访问权限，而在路径规范化。正确修法是先分别规范基础路径与对象键，再只进行一次拼接。已有留言中的旧地址仍需要后续迁移，今天没有直接批量改写历史内容。图片偶发上传失败则与路径无关。前端把图片上传和普通接口请求共用了大约八秒的超时，而服务端在部分情况下需要更长时间处理。反向代理中可以看到浏览器提前断开的 499，也能看到稍后成功完成的 201。因此下一步应为上传请求设置独立的较长超时，并继续追踪真正异常的慢请求，单纯增加重试次数不能解决问题。这个问题今天只完成了定位，修改尚未上线。邮件部分检查了 Mix Space 的三份 EJS 模板。评论通知里同时存在站点品牌头像和评论者头像，不能简单地全部替换为博主头像。更新后的模板明确区分两种角色，并补上品牌头像和评论者头像的独立回退、正文换行与长链接断行、移动端宽度适配、缺失字段兼容，以及详情链接与退订链接保留。原模板在修改前完成备份，更新后的模板通过本地 EJS 渲染和后台回读验证，全程没有向真实订阅者发送邮件。同时也明确了存储边界：数据库备份和公开图片不应长期混在同一个公开空间。私有备份与公开图片分离的方案已经确定，但独立图片存储、图片域名和自动证书还需要后续配置。Whisp：源码里有，不等于用户已经能用今天还为 Whisp 写完并发布了一篇完整的项目介绍。Whisp 是一款基于 Tauri 的跨平台语音输入工具，支持实时转写、AI 后处理、历史检索和多种识别服务。最初按照 README 整理时，很容易把它描述成“云端和本地 Whisper 可以自由切换”。继续检查实际执行路径后发现，这种说法并不准确。Whisp 的源码中已经存在本地 Whisper、失败回退和模型处理基础，但当前主要界面流程仍以云端识别为先，纯离线选择尚未完整接入用户界面。因此文章重新区分了三类能力：当前版本中用户可以直接使用的功能；源码已经具备基础，但界面尚未完整接通的能力；以及仍处于规划阶段的功能。横向对比也没有只比较功能数量，而是把 Whisp 与 Wispr Flow、Superwhisper、Typeless、VoiceInk、OpenWhispr、Handy 和 MacWhisper 放在平台支持、离线能力、隐私模式、价格、模型自由度和配置成本几个维度中讨论。文章同时保留了 Whisp 当前的限制，例如部分平台签名体验、自备接口密钥的配置成本、移动端缺失，以及本地离线流程尚未完全产品化。发布采用 Mix Space 新版的“创建草稿—提交发布任务—读取任务状态”流程。发布前检查 Markdown、分类、标签、摘要、题图和短链接冲突，发布后再从公开接口读回正文和元数据，确认公开页面与本地终稿一致。这次写作最重要的是写清“已经实现”和“未来方向”，不夸大 Whisp 的能力。Coralbay Rules 的生成历史与地区策略Coralbay Rules 今天连续完成了两个版本的迭代。MiaomiaowuX 原先只能方便地恢复最近一次生成结果，缺少完整的历史文件管理；地区分组、自动选择和均衡策略也比较固定。新版增加了生成历史、查看、下载、复用设置、移入回收站和恢复功能。相同配置生成相同内容时会复用已有版本，避免服务器堆积大量重复文件。地区策略也从固定组合改成了可配置结构。独立地区优先接收对应节点，未单独启用的节点再进入大区，最后进入未识别兜底组。每个地区可以分别生成自动、均衡和手动组，关闭某个组时，相关业务组选项也会同步移除，不能留下失效引用。随后又补齐了内置地区图标和“全球手动”的完整节点入口。图标直接打包在程序中，不再依赖客户端临时访问外部图片源；故障转移仍保持自动容灾语义，不因为用户需要手动选择节点就被错误改造成普通选择组。Mihomo 的规则仍遵守从上到下首次匹配的原则。YouTube、Spotify 等具体规则必须位于宽泛的国际媒体或 Google 规则之前，最终的 MATCH 只负责接住前面没有匹配的流量。界面里的策略组排列只影响展示，真正决定分流的是 rules 数组的顺序。两个版本都经过测试、GitHub 发布、多架构容器镜像构建、服务器备份和线上升级。旧设置、生成历史和已有数据在升级后保持不变。MovieClaw 的路径映射与旧文件处理晚上还把 MovieClaw 接入了已有的 qBittorrent 和 Plex 环境。MovieClaw 与 qBittorrent 不要求运行在同一台设备，只要 qBittorrent Web API 可以访问，MovieClaw 就能远程创建和管理下载任务。真正需要处理的是下载路径和媒体路径：容器内部必须能够把下载器返回的路径映射到实际媒体文件。Plex 媒体分散在多个存储目录中，因此 MovieClaw 容器增加了对应的目录映射，并按电影、剧集、动画、纪录片和综艺等内容类型重新建立媒体库。新下载仍进入原来的主目录，其他目录主要用于识别已有内容和判断是否需要洗版。这里遇到了一个权限取舍。如果旧媒体库以只读方式挂载，MovieClaw 可以发现旧版本，却无法在新版本验证成功后把旧文件移入回收站；如果直接给予写权限并打开自动清理，又会扩大误删风险。最终采用的是“目录可读写，但不启用自动批量删除”。只有在新版本下载、入库并确认质量更好后，旧版本才允许移入项目管理的回收区域，并保留恢复时间。只把目录改成可写不会触发删除。应用配置在重启前完成备份，随后扩展目录并重新扫描。整个过程中没有移动或删除已有媒体文件。等扫描结束后，还需要先处理未识别内容，再配置洗版规则和重复文件检查。网络排查中的出口与 IPv6 配置今天还分析了一次在线 AI 服务的地区与访问资格异常。沿着域名规则、规则集、策略组和实际出口逐层检查后，发现 AI 流量会进入一个可能在多个地区节点间选择的策略组。自动测速并不代表每次检查都会切换，但对依赖地区和会话一致性的服务，只要存在出口漂移的可能，就可能带来资格判断不一致。运行配置中还存在全局 IPv6 与 DNS IPv6 状态不一致的问题。Fake-IP 与基础 DNS 没有表现出直接故障，因此它们不是最优先的修改对象。更合理的处理方式是把相关域名放在宽泛 AI 规则之前，进入单独的固定策略，并统一 IPv6 与 DNS 配置。由于还缺少固定出口后的受控对照，今天只完成分析，没有直接修改配置。Codex 日记发布器的校验与文章结构晚上建立的每日 Codex 日记发布器已经能够完成线程汇总、隐私扫描、本地保存和 Mix Space 手记发布。发布器使用固定日期标识，同一天重复运行时更新原手记，不创建重复内容。文章通过 Mix Space 的草稿与发布任务接口提交，完成后再从公开接口读回标题、专栏和完整正文进行校验。本地日记和公开手记分别保存 SHA-256 摘要，并带有自动化所有权标记。如果检测到人工修改、人工草稿、手记被删除或公开正文发生变化，任务会停止，而不是覆盖或重新创建。首次生成则先写入候选文件，再以独占创建方式安装为正式日记；如果同名文件在此期间由人工创建，系统调用会失败并停止。博客授权只在运行时从系统安全存储读取，不进入日记、提示词或命令参数。不过，第一版日记虽然很好地执行了安全规则，文章却像一份工作日报。它记录了“完成了什么”，却没有解释“为什么开始、原代码怎样、改成什么、使用了什么技术、验证结果如何”。因此，后续日记会把每条主线写成完整的因果链：问题出现、原有行为、实现修改、技术原理、验证结果，以及尚未完成的边界。日记需要解释当时为什么这样设计，让人几个月后重新阅读时仍能理解，不能只列出当天的任务。今天留下的结论比起版本号或测试数量，今天更重要的收获是几项跨项目都适用的原则。KanBox 说明，异步任务必须知道自己属于哪一条内容；Mix Space 说明，路径、身份和存储用途必须有清楚边界；Whisp 的文章说明，源码中存在某项能力，不等于产品已经向用户交付；Coralbay Rules 和 MovieClaw 则再次证明，自动化不仅要能执行，还必须能停止、回滚和恢复。明天首先要完成 KanBox b15 的多轮长列表压力测试，再决定是否安装新的性能候选；继续修复 Mix Space 的历史图片链接和上传超时；等待 MovieClaw 扫描结束后处理识别结果；同时完成真实设备上的媒体播放、备份恢复和系统输出验收。功能实现后，还需要让它在数据异常、网络变化、重复操作和长时间运行下仍然可信。今天继续推进了这部分工作。隐私说明本文保留了公开项目名称、开源技术、版本演进和通用测试结果；账号、授权凭据、服务器地址、本地绝对路径、设备标识、私人媒体内容及其他可识别信息均已删除或概括。
2026-09-28｜自然语言编程日记
今天的工作横跨了几个项目：继续打磨 KanBox，维护基于 Mix Space 和 Yohaku 的个人博客，为 Whisp 发布项目介绍，迭代 Coralbay Rules，并把 MovieClaw 接入已有的下载器与 Plex 媒体库。
这些项目反复遇到同一个问题：功能能够运行，并不代表它已经可靠。解析结果可能不完整，异步回调可能写错对象，缓存可能不断增长，自动清理可能误删数据，项目介绍也可能把“代码里已经存在”误写成“用户已经可以使用”。
今天继续完善这些基本能用的功能，明确它们的适用范围，补充验证，并让失败后的数据能够恢复。
KanBox 的解析与重新解析
KanBox 今天的开发从几个真实使用问题开始，没有先增加新功能。
旧版社交内容解析器倾向于收集页面中出现的全部媒体，因此正文图片、评论头像和回复图片可能混在一起。遇到带登录限制的页面时，又可能只取得正文或封面，却让界面看起来像已经得到了完整视频。
新的解析逻辑不再把“页面里出现过”当成“属于目标内容”，而是根据正文结构和媒体归属关系进行筛选。无法取得真实视频地址时，结果会明确标记为“部分解析”，不再用封面图片冒充视频。
KanBox 还增加了手动重新解析入口，但重新解析只刷新作者信息、媒体地址和封面等派生字段，不覆盖用户自己修改过的正文、标签与笔记。这样既能修复过期数据，也不会因为重新抓取而损失人工整理的内容。
在线播放和下载保存也被拆成了两条独立能力：播放器能够播放网络视频，只能证明在线地址可用；只有媒体文件真正被下载、校验并写入本地后，才能算作离线保存完成。代码和验收记录中不再把这两件事混为一谈。
用内容身份隔离迟到的异步回调
今天修复的另一组问题集中在保存、分享、解析和删除之间的竞态。
旧实现中，连续点击可能启动多个相同任务。用户已经切换到下一条内容后，上一条内容较晚完成的回调仍可能更新当前页面；内容已经删除后，旧页面也可能继续尝试保存笔记或输出图片。
新的实现限制每项操作只能启动一个有效任务，并校验内容身份。任务启动时记录当前内容的唯一标识，提交结果前再检查一次：页面仍然显示同一条内容、这项任务仍是当前有效任务、内容没有被删除，并且没有更新的操作取代它。任一条件不成立，迟到结果就会被丢弃。内容删除成功后，相关页面也会立即停止接受保存、分享和重新解析操作。
连续随机回顾采用了相同思路。开始一次回顾时，KanBox 会冻结当前筛选结果的标识列表，只洗牌一次；上一条、下一条沿历史移动，新增加的收藏不会突然插入当前轮次，已删除的内容则从候选和历史中移除。这样避免了回顾过程中重复抽取或进度跳动。
备份恢复的文件校验与事务
KanBox 的备份恢复也做了更严格的安全处理。
旧流程的重点是压缩包能否读取；现在会在写入前检查 ZIP 边界、CRC、文件名、内容标识、图片路径和同名冲突。包含目录穿越、软链接越界或同名不同内容的备份会直接拒绝，不能借恢复流程覆盖应用目录之外的文件。
真正写入时使用独立的数据事务。恢复失败只回滚本次新建的内容和图片，不影响用户正在编辑但尚未提交的其他数据。缺失原图的收藏也不会被包装成一份“完整备份”。
本地图片路径同样经过规范化：只有确认位于 KanBox 管理目录内的文件才允许读取，目录外路径、越界路径和符号链接不会进入图片加载的回退逻辑。
恢复现在只接受结构完整、路径安全且能原子提交的备份，不再只检查文件能否导入。
SwiftUI 长列表与图片缓存
KanBox 的性能问题主要出现在长列表和图片画廊。
旧实现虽然使用了滚动容器，但访问过的 SwiftUI 行状态会逐渐累积。列表显示图片时，也可能过早解码接近原图尺寸的内容；预取和屏幕显示同时请求同一地址时，还会发生重复下载。
新的实现分三处调整。首页、搜索结果和作者页面改为真正的懒加载或分段渲染，离开屏幕较远的行不再一直保留完整显示状态。画廊、网格和单列根据各自布局控制可见窗口，而不是一次为数千条内容建立完整视图状态。
其次，图片加载分成“原始字节”和“显示缩略图”两层。列表通过 ImageIO 按实际显示尺寸生成缩略图，并设置最大边长；原始图片字节继续留给全屏查看、保存和分享。缩略图缓存有明确的容量和内存预算，不再让 NSCache 成为没有边界的黑盒。
最后，下载层加入了 single-flight 式的请求合并。同一个地址如果同时被预取、头像和可见卡片请求，只创建一个实际下载任务，其他调用者共享结果。并发预取也设置了上限，避免快速滚动时瞬间启动大量任务。
在约五千条隔离数据的同场景对照中，内存峰值和结束值从约 155 MiB 降到约 75 MiB，堆内存从约 116 MiB 降到约 48 MiB，持续持有的行状态从三千多份下降到一百多份。针对数百张独立图片的搜索页、作者页和画廊复测也已通过。
不过，b15 性能候选仍在进行多轮触底、回顶和静置测试。当前测试表明修改方向有效，但还不足以确认所有内存增长都已解决，因此它暂时没有覆盖安装到手机。
手机目前保留在已经完成验收的稳定版本。每次升级前都先备份应用与共享数据容器，覆盖安装后再检查数据库完整性、内容数量和内容标识，不通过卸载重装来掩盖迁移问题。
Mix Space：裂图、超时和邮件头像是三个不同问题
博客使用 Mix Space 作为后端、Yohaku 作为前端。今天遇到的图片裂图、上传超时和邮件头像异常，表面相似，实际来自完全不同的层级。
留言图片裂图的原因是对象存储路径被重复拼接。链接生成逻辑把已经包含存储前缀的对象键再次附加到基础目录后面，导致错误地址返回 404；去掉重复部分后，同一个对象可以正常返回 200。
这说明问题不在证书和访问权限，而在路径规范化。正确修法是先分别规范基础路径与对象键，再只进行一次拼接。已有留言中的旧地址仍需要后续迁移，今天没有直接批量改写历史内容。
图片偶发上传失败则与路径无关。前端把图片上传和普通接口请求共用了大约八秒的超时，而服务端在部分情况下需要更长时间处理。反向代理中可以看到浏览器提前断开的 499，也能看到稍后成功完成的 201。
因此下一步应为上传请求设置独立的较长超时，并继续追踪真正异常的慢请求，单纯增加重试次数不能解决问题。这个问题今天只完成了定位，修改尚未上线。
邮件部分检查了 Mix Space 的三份 EJS 模板。评论通知里同时存在站点品牌头像和评论者头像，不能简单地全部替换为博主头像。更新后的模板明确区分两种角色，并补上品牌头像和评论者头像的独立回退、正文换行与长链接断行、移动端宽度适配、缺失字段兼容，以及详情链接与退订链接保留。
原模板在修改前完成备份，更新后的模板通过本地 EJS 渲染和后台回读验证，全程没有向真实订阅者发送邮件。
同时也明确了存储边界：数据库备份和公开图片不应长期混在同一个公开空间。私有备份与公开图片分离的方案已经确定，但独立图片存储、图片域名和自动证书还需要后续配置。
Whisp：源码里有，不等于用户已经能用
今天还为 Whisp 写完并发布了一篇完整的项目介绍。
Whisp 是一款基于 Tauri 的跨平台语音输入工具，支持实时转写、AI 后处理、历史检索和多种识别服务。最初按照 README 整理时，很容易把它描述成“云端和本地 Whisper 可以自由切换”。
继续检查实际执行路径后发现，这种说法并不准确。Whisp 的源码中已经存在本地 Whisper、失败回退和模型处理基础，但当前主要界面流程仍以云端识别为先，纯离线选择尚未完整接入用户界面。
因此文章重新区分了三类能力：当前版本中用户可以直接使用的功能；源码已经具备基础，但界面尚未完整接通的能力；以及仍处于规划阶段的功能。
横向对比也没有只比较功能数量，而是把 Whisp 与 Wispr Flow、Superwhisper、Typeless、VoiceInk、OpenWhispr、Handy 和 MacWhisper 放在平台支持、离线能力、隐私模式、价格、模型自由度和配置成本几个维度中讨论。
文章同时保留了 Whisp 当前的限制，例如部分平台签名体验、自备接口密钥的配置成本、移动端缺失，以及本地离线流程尚未完全产品化。
发布采用 Mix Space 新版的“创建草稿—提交发布任务—读取任务状态”流程。发布前检查 Markdown、分类、标签、摘要、题图和短链接冲突，发布后再从公开接口读回正文和元数据，确认公开页面与本地终稿一致。
这次写作最重要的是写清“已经实现”和“未来方向”，不夸大 Whisp 的能力。
Coralbay Rules 的生成历史与地区策略
Coralbay Rules 今天连续完成了两个版本的迭代。
MiaomiaowuX 原先只能方便地恢复最近一次生成结果，缺少完整的历史文件管理；地区分组、自动选择和均衡策略也比较固定。新版增加了生成历史、查看、下载、复用设置、移入回收站和恢复功能。相同配置生成相同内容时会复用已有版本，避免服务器堆积大量重复文件。
地区策略也从固定组合改成了可配置结构。独立地区优先接收对应节点，未单独启用的节点再进入大区，最后进入未识别兜底组。每个地区可以分别生成自动、均衡和手动组，关闭某个组时，相关业务组选项也会同步移除，不能留下失效引用。
随后又补齐了内置地区图标和“全球手动”的完整节点入口。图标直接打包在程序中，不再依赖客户端临时访问外部图片源；故障转移仍保持自动容灾语义，不因为用户需要手动选择节点就被错误改造成普通选择组。
Mihomo 的规则仍遵守从上到下首次匹配的原则。YouTube、Spotify 等具体规则必须位于宽泛的国际媒体或 Google 规则之前，最终的 MATCH 只负责接住前面没有匹配的流量。界面里的策略组排列只影响展示，真正决定分流的是 rules 数组的顺序。
两个版本都经过测试、GitHub 发布、多架构容器镜像构建、服务器备份和线上升级。旧设置、生成历史和已有数据在升级后保持不变。
MovieClaw 的路径映射与旧文件处理
晚上还把 MovieClaw 接入了已有的 qBittorrent 和 Plex 环境。
MovieClaw 与 qBittorrent 不要求运行在同一台设备，只要 qBittorrent Web API 可以访问，MovieClaw 就能远程创建和管理下载任务。真正需要处理的是下载路径和媒体路径：容器内部必须能够把下载器返回的路径映射到实际媒体文件。
Plex 媒体分散在多个存储目录中，因此 MovieClaw 容器增加了对应的目录映射，并按电影、剧集、动画、纪录片和综艺等内容类型重新建立媒体库。新下载仍进入原来的主目录，其他目录主要用于识别已有内容和判断是否需要洗版。
这里遇到了一个权限取舍。如果旧媒体库以只读方式挂载，MovieClaw 可以发现旧版本，却无法在新版本验证成功后把旧文件移入回收站；如果直接给予写权限并打开自动清理，又会扩大误删风险。
最终采用的是“目录可读写，但不启用自动批量删除”。只有在新版本下载、入库并确认质量更好后，旧版本才允许移入项目管理的回收区域，并保留恢复时间。只把目录改成可写不会触发删除。
应用配置在重启前完成备份，随后扩展目录并重新扫描。整个过程中没有移动或删除已有媒体文件。等扫描结束后，还需要先处理未识别内容，再配置洗版规则和重复文件检查。
网络排查中的出口与 IPv6 配置
今天还分析了一次在线 AI 服务的地区与访问资格异常。
沿着域名规则、规则集、策略组和实际出口逐层检查后，发现 AI 流量会进入一个可能在多个地区节点间选择的策略组。自动测速并不代表每次检查都会切换，但对依赖地区和会话一致性的服务，只要存在出口漂移的可能，就可能带来资格判断不一致。
运行配置中还存在全局 IPv6 与 DNS IPv6 状态不一致的问题。Fake-IP 与基础 DNS 没有表现出直接故障，因此它们不是最优先的修改对象。
更合理的处理方式是把相关域名放在宽泛 AI 规则之前，进入单独的固定策略，并统一 IPv6 与 DNS 配置。由于还缺少固定出口后的受控对照，今天只完成分析，没有直接修改配置。
Codex 日记发布器的校验与文章结构
晚上建立的每日 Codex 日记发布器已经能够完成线程汇总、隐私扫描、本地保存和 Mix Space 手记发布。
发布器使用固定日期标识，同一天重复运行时更新原手记，不创建重复内容。文章通过 Mix Space 的草稿与发布任务接口提交，完成后再从公开接口读回标题、专栏和完整正文进行校验。
本地日记和公开手记分别保存 SHA-256 摘要，并带有自动化所有权标记。如果检测到人工修改、人工草稿、手记被删除或公开正文发生变化，任务会停止，而不是覆盖或重新创建。
首次生成则先写入候选文件，再以独占创建方式安装为正式日记；如果同名文件在此期间由人工创建，系统调用会失败并停止。博客授权只在运行时从系统安全存储读取，不进入日记、提示词或命令参数。
不过，第一版日记虽然很好地执行了安全规则，文章却像一份工作日报。它记录了“完成了什么”，却没有解释“为什么开始、原代码怎样、改成什么、使用了什么技术、验证结果如何”。
因此，后续日记会把每条主线写成完整的因果链：问题出现、原有行为、实现修改、技术原理、验证结果，以及尚未完成的边界。
日记需要解释当时为什么这样设计，让人几个月后重新阅读时仍能理解，不能只列出当天的任务。
今天留下的结论
比起版本号或测试数量，今天更重要的收获是几项跨项目都适用的原则。
KanBox 说明，异步任务必须知道自己属于哪一条内容；Mix Space 说明，路径、身份和存储用途必须有清楚边界；Whisp 的文章说明，源码中存在某项能力，不等于产品已经向用户交付；Coralbay Rules 和 MovieClaw 则再次证明，自动化不仅要能执行，还必须能停止、回滚和恢复。
明天首先要完成 KanBox b15 的多轮长列表压力测试，再决定是否安装新的性能候选；继续修复 Mix Space 的历史图片链接和上传超时；等待 MovieClaw 扫描结束后处理识别结果；同时完成真实设备上的媒体播放、备份恢复和系统输出验收。
功能实现后，还需要让它在数据异常、网络变化、重复操作和长时间运行下仍然可信。今天继续推进了这部分工作。
隐私说明
本文保留了公开项目名称、开源技术、版本演进和通用测试结果；账号、授权凭据、服务器地址、本地绝对路径、设备标识、私人媒体内容及其他可识别信息均已删除或概括。