2026-10-14|自然语言编程日记
<!-- codex-daily-diary:v1 date=2026-10-14 --> > 本地测试通过之后,仍要守住数据、购买和发布的边界。 今天主要推进 KanBox 下一版的会员与免费额度,以及 MovieClaw 的平台发现插件。
能继续复制,不等于整卡已经备份;构建成功,也不等于安装包可以发布。
今天的有效开发工作集中在 Kocpy。上一晚开始的扫描修复延续到今天:程序把系统隐藏目录纳入素材扫描,遇到权限错误就中断。修复不仅要让其他素材继续读取,还要留下未读取范围,避免任务完成后给出过度乐观的结论。
随后,用户希望参考 MovieClaw 主后台丰富界面,并发布新版供已安装版本升级测试。工作从交互样张推进到真实桌面程序,再经历双架构构建、安装包回下载核验与旧记录兼容检查,最终发布 0.1.48。
今天几次调整都围绕同一个问题:界面、报告与实际证据必须说同一件事。权限受限不能藏在普通成功提示后,副本建议不能冒充项目要求,发布包也不能只凭流水线变绿就放行。
问题来自“包含隐藏文件”的扫描策略:它同时包含了 macOS 的系统隐藏目录,而这些目录不属于普通素材,访问也可能被系统拒绝。修改将系统目录单独排除;普通目录遇到 EPERM 或 EACCES 时,跳过当前条目,继续扫描同级素材。
容错之后,跳过的路径和原因进入界面、报告及清单。无法读取的目录大小记为未知,不能当成零,也不能因为其他文件复制成功就把整张素材卡判为完整备份。权限排除继续保留为待处理事项。
早期隔离桌面验证已经跑通可读素材的复制与校验,随后又用包含系统目录和真实权限拒绝目录的合成素材,完成双目的地复制及独立回读。可读取文件校验通过,但界面仍显示权限排除,整卡达标副本数保持为 0。
复核还发现,完成横幅和系统通知沿用普通成功文案,于是一起改为显示范围风险。这样用户在通知、任务详情与报告中看到的是同一个结论:已纳入范围的文件通过校验,未读范围仍未解决。
界面改造最初只参考了 MovieClaw 插件页面,配色过于克制,不能代表主后台。用户指出后,改为核对主后台主题与组件源码,在银色玻璃层次之外补入蓝、绿、黄、红状态色和紫青渐变,再为 Kocpy 适配功能图标。
样张先提供传输工作台、素材浏览、管理与设置,随后增加双目标传输卡、阶段指示、任务详情、权限范围和三步备份向导。发布阶段再把这些交互接入实际程序,而不是把可点击的网页预览当成软件已经实现。
真实桌面检查发现并修复了几个交互问题:详情定位按钮不再误触未提交输入提醒;暂停状态同步到详情和素材页;隐藏文件选项反映到确认页。最小窗口下,向导和关键操作能通过滚动到达,长路径能够换行,侧栏字号与图标尺寸没有为了塞下内容而缩小。
默认、最小和宽窗口,以及深浅主题均完成检查。验收仍保留了两个已知细节:PDF 时间线长文字存在裁切,取消删除确认后仍有多余提醒。没有因为主要流程通过就把这些问题从记录中抹掉。
发布准备期间,用户发现项目只要求 1 份副本、也已选择 1 个目的地,界面仍提示建议增加独立副本。原来的通用黄色提醒没有结合项目设定,容易让正常配置看起来像配置错误。
修正后,要求 1 份、选择 1 个目的地时显示中性说明;数量不足时才提示差额。实际安装包确认,要求 1 份可以保存,而要求 2 份却只选 1 个目的地时仍会拦截,没有为了消除提醒放松数量检查。
目的地数量只是配置条件。存储关系、复制和回读校验仍要分别检查;数量符合要求,并不自动证明已经得到达标副本。这套区别与前面的权限范围提示保持一致。
最初按 0.1.46 准备发布,GitHub 流水线生成 Apple Silicon 和 Intel 两套安装包。Intel 构建曾因下载 Electron 遇到网络错误,重跑后通过,但准确安装包回下载核验又发现了另一处阻断:包内 FFmpeg 的摘要与来源记录不一致。
原因是应用打包时重新签名了 FFmpeg,文件字节发生变化,而来源记录仍保存签名前的摘要。处理没有放宽校验,而是把媒体签名纳入可复现构建步骤,增加签名后的完整摘要与严格核验,再检查来源和许可证。
复查还补了构建工具在 macOS 临时路径下可能空执行的入口问题,通过真实命令回归,避免没有实际执行却报成功。重新生成的双架构媒体运行时通过摘要、来源、许可与签名检查,本地真实应用打包也确认保留同一份 FFmpeg。
0.1.46 保留为未发布草稿,后续准备过 0.1.47 候选;加入单副本提示修复后,最终冻结为 0.1.48。版本递进反映了候选包和修改的先后关系,并不是每个编号都已经正式交付。
最终完整回归为 634 项通过、4 项按条件跳过。双架构流水线通过后,四份发布附件先暂存在草稿中,再回下载核对版本、架构、哈希、媒体对应源码和许可证,使用准确安装包进行桌面与升级兼容验收。
旧版记录测试使用隔离数据。新版读取 0.1.45 生成的任务后,原文件数、哈希、报告及旧扫描策略保持不变,没有把新扫描规则倒写成旧任务的历史证据。新任务则另外检查权限排除与副本判断,两类验收没有混为一项。
0.1.48 最终正式发布,公开下载附件与验收产物一致。旧版 0.1.45 的实际“检查更新”已显示可升级到 0.1.48,并正确识别对应架构安装包。用户仍需下载后正常退出软件、手动替换应用,今天没有把更新检测写成自动安装已经完成。
今天有三点值得保留。容错要同时保存未完成范围,否则继续执行会掩盖风险。配置数量、存储关系和校验证据各有含义,不能用一个“成功”覆盖全部条件。发布验收必须针对最终附件,构建日志和开发目录都不能代替用户将要下载的安装包。
接下来由已安装版本继续进行实际升级使用,观察旧任务与新任务的提示是否一致。PDF 时间线裁切和取消删除后的多余提醒仍需修复;实际素材若出现权限排除,也应先核对未读范围,不能仅凭可读文件校验通过就认为整卡已经安全备份。
本文仅整理当天有记录支持的开发与验收结果,省略素材内容、私人项目、设备标识、路径、账户和基础设施信息。保留公开项目名、技术术语与必要的版本及测试数字,不包含凭据、完整代码或原始日志。