工位池塘 v0.6.2：两个老 issue 从分诊到三端发版

入档：2026-10-07 来源：desk-pond（工位池塘），issue #1 #2 → 提交 738911b 9cfa20b → GitHub Release v0.6.2 + B站 Toy 更新。一次会话做完，执行者是助手（Claude），在一台临时电脑上从克隆仓库开始 性质：工程闭环复盘。可复用的是 issue 分诊、桌面布局预算、浏览器辅助发版三类经验；发版当天没有下载和反馈数据

事实记录（不可修改区）

• 作品名称：工位池塘 Desk Pond v0.6.2
• 项目：desk-pond 两个开放 issue 的分诊与修复，加三端发版（Windows / macOS / B站 Toy）
• 提交时间：
  • 738911b：2026-10-06 23:40
  • 9cfa20b 和 tag v0.6.2：10-07 00:30
  • Toy 更新提交：00:40
  • GitHub Release 公开：00:43
• 预期目标（作者三次下达的原话）：
  1. 「先来检查issue是否都修复了，如果没有则优先修复，若修复完成则更新issue状态」
  2. 「发个新版本 v0.6.2」
  3. 「生成上传包，然后自动更新到TOY上」
• 起点：两个 issue 都是 07-16 提的，开了 82 天，没有回复。
  • #1：Win10 下进水族馆，「今日任务苗圃」变宽，按钮显示不全。
  • #2：建议加正计时、窗口大小可拖动调整。
• 分诊实测：
  • #1 在代码里早就修好了。07-10 的自检提交 759f3d4 把水族馆子标签移出了顶栏，但这个修复要到 09-29 的 v0.6.0 才发版；报告者 07-16 能下到的是 v0.5.0。
  • 在 v0.5.0 上复现：进水族馆后顶栏最小宽度从 570 涨到 676，整列被撑到 676 宽，任务区拉到 422，右边缘到 668 px，超出 640 px 的窗口 28 px。
  • HEAD 上还有一个更小的同类问题：所有房间的整列都是 644×528，比 640×520 的窗口宽 4、高 8。
  • #2 没做。
• 最终结果：
  • 符合预期：
    • #1 评论根因后关闭；#2 由提交信息里的 Closes #2 自动关闭，并补了用法评论。
    • Release v0.6.2 公开，两个附件和本地构建逐字节一致；发布触发的 macOS 冒烟测试 arm64 和 Intel 全绿。
    • Toy 5 分钟内过审上线，内层路径 …-v23165，线上 index.data 5,999,956 字节，和本地一致。
  • 不符合 / 有偏离：
    • 「自动更新到 Toy」没能全自动：Toy 包和 Release 附件都超过浏览器扩展 10 MB 的上传上限，作者手动拖了两次文件。
    • 助手报给作者的导出模板大小是 169 MB，实际 1198 MB。下载途中发现并更正。
    • 「用鼠标真拖窗口边缘」没有验证。
• 数据来源：Godot 4.6.3 无头测试和探针输出、真窗口渲染截图、GitHub API、curl --compressed 抓 Toy 外层和内层页。全部是自测；没有下载量和用户反馈。
• 获奖作品：不适用

已验证 vs 未验证

作品回顾

思路

• 先判断 issue 是「没修」「修了没发版」还是「修了但没修全」，再决定动不动代码。#1 不能只看提交记录下结论，要在报告者用的版本和 HEAD 上各量一次。
• #2 是功能需求。三个设计取舍由作者拍板，助手给选项并标出推荐：
  • 是否下载 Godot 来验证：作者选下载。
  • 窗口放大时内容怎么变：作者选等比放大、多出的空间给场景。
  • 正计时怎么结算：作者选满 1 分钟算一次专注。

执行过程

1. 克隆，跑原有测试打底（115 + 45 项通过）。
2. 用无头探针在 HEAD 和 v0.5.0 的 worktree 上量布局，定位 #1 的根因和残留问题。
3. 实现：
   • 正计时：钓竿标题行加一个小开关，不另占行高。专注中主按钮变成「收竿」；点池塘不会收竿；计时中不能切换方式；数到 180 分钟自动收竿。网页版按真实时钟补算，因为页面切到后台时计时会被冻结。
   • 窗口缩放：窗口是无边框的，所以在右边、下边各留一条 5 px 的拖拽区，右下角加一个手柄。stretch aspect 设为 expand。记住上次的大小，启动时限制在屏幕内并居中。
   • 布局预算：任务区最小宽度 390 → 386，场景最小高度 200 → 180，桌面版控制台不再分摊多出来的高度。
   • 测试基建：SaveManager.save_path 改成 static var，测试写临时存档，不碰玩家的真实存档。新增布局测试和计时测试。
4. 验证：
   • 无头测试全过。
   • 故意改回旧值，确认布局测试会变红。
   • 真窗口截图：extends SceneTree 的脚本里，await RenderingServer.frame_post_draw 之后调用 root.get_texture().get_image().save_png()。
5. issue：作者选择直推 main。评论稿先给作者确认；用作者已登录 GitHub 的 Chrome 发评论并关闭 #1。
6. 发版：
   • 改版本号（导出配置 6 处、project.godot、README 徽章），打 tag。
   • 本机导出三个包；Web 包再跑仓库自带的 make_toy_package.ps1。
   • 作者选择直接公开，不挂草稿。
7. Toy 和 Release 上传：
   • 作者把文件拖进 Toy 的更新页和 GitHub 发布页。
   • 助手看过 Toy 预览后点「更新」，核对附件后点「Publish release」。
   • 两边都按字节核对线上产物。
8. 清理：作者授权后，删掉导出模板、编辑器、测试存档、给作者拖文件用的副本，共约 1.8 GB。

最终输出

• 代码：738911b（功能 + 测试）、9cfa20b（版本号）。
• 发布：Release v0.6.2（DeskPond-v0.6.2.exe 110,522,208 字节，DeskPond-macOS-v0.6.2.zip 66,534,035 字节）；Toy 内层版本 -v23165。
• issue：#1、#2 都已关闭并附说明。

结果分析

• #1 真正的问题不在代码，在发版节奏。修复在报告前 6 天就进了 main，之后 82 天里既没发版，也没人回复；在报告者看来，这个 bug 一直没修。
• 计划外的消耗主要是三处：
  • 本机缺工具链，要下载约 1.4 GB。
  • 文件位置对作者不可见，多了一轮往返。
  • 助手在作者手动操作时并行操作浏览器，被叫停一次。

方法论沉淀

老 issue 分诊：在报告者的版本上复现，再在 HEAD 上量

核心：开了很久的 issue，要在报告者当时用的版本和当前 HEAD 上各量一次，才能分清「没修」「修了没发版」「修了没修全」。

来源：#1。提交记录只能说明「可能修了」。v0.5.0 上量到 676，坐实根因；HEAD 上量到 644，抓出一个更小的同类问题。

验证状态：⚠️ 首次发现

操作规则：

1. 报告者用的版本 = issue 日期之前最近的那个 Release，不是之前最近的那个提交。
2. git worktree add ../<目录> <tag> 切出那一版，和 HEAD 跑同一个探针，输出数字而不是截图。
3. 回复 issue 时写清「从哪个版本起修好」；修复合进 main 不等于到了用户手里。

反例/边界：issue 没写复现条件、本机无法复现报告者环境（比如特定 DPI、特定显卡）时，这一招只能排除，不能定案。

桌面布局要算预算，并用会变红的测试守住

核心：Godot 容器的最小尺寸会一层层往上累加；子节点的最小宽度加起来超过窗口最小宽度时，根容器就比窗口宽，最右边的按钮被裁掉，而且不报任何错。

来源：HEAD 上整列 644×528 > 640×520。顶栏图标把顶栏撑到 48 高；钓竿 230 + 任务 390 + 间距边距超过 640。

验证状态：⚠️ 首次发现（Godot）。「量盒子，别量像素」这一条的再验，见 2026-06-26_桌面应用打磨发布闭环复盘_工位池塘v0.5.0_v1

操作规则：

1. 把预算算式写进代码注释：宽度 8 + 230 + 8 + 386 + 8 = 640，高度 48 + 180 + 280 ≤ 520。
2. 无头测试逐个房间、逐个窗口尺寸断言两件事：整列不超出窗口，每个按钮都在窗口内。无头模式下 get_combined_minimum_size() 和 get_global_rect() 照样能算。
3. 写完测试，故意把值改回旧的，确认它会变红。测试自己先被证伪过，才算数。

反例/边界：只覆盖桌面最小窗口和几种放大尺寸；手机版是另一套布局，这个测试没覆盖。

要作者手动选的文件，一开始就放到作者找得到的地方

核心：浏览器扩展传不了的文件，交给作者拖之前，先复制到作者熟悉的位置并在资源管理器里选中。

来源：Toy 包 12.8 MB、Release 附件 105 MB 和 63 MB，都超过扩展 10 MB 的上传上限。助手第一次给的是会话临时目录里的路径，那个目录在应用里是隐藏的，作者找不到，多了一轮往返。

验证状态：⚠️ 首次发现。10 MB 上限本身是第三次碰到，见 浏览器插件自动化的能力边界_v1

操作规则：

1. 开始发版前就判断哪些文件超过 10 MB。
2. 把这些文件一次性复制到「下载」下的独立文件夹，用 explorer /select,<文件> 打开并选中。
3. 一次说清每个文件拖到哪一页的哪个区域；作者做完之前，助手不在同一个浏览器里并行操作。

反例/边界：文件放在页面能跨域读到的地址上时，可以改用页面内 fetch 注入，不必人工；见 2026-07-11_B站Toy同步事故复盘_版本指纹与外部cron兜底_v1 附录。

要作者据此做决定的数字，从结构化字段读

核心：大小、费用、时长这类要作者同意的数字，必须按字段取值，不能用文本行去配对。

来源：助手失误。下载 Godot 导出模板前，用 grep | paste - - 把接口 JSON 里的 name 和 size 两两配对，配错了行，报给作者「169 MB」，实际 1198 MB。下载到 734 MB 时发现，当场更正。

验证状态：⚠️ 首次发现

操作规则：

1. 用能按字段取值的方式读：PowerShell 对象、jq。
2. 报数字时顺带写出它对应的名字，方便自己核对。

反例/边界：只是给自己看的估算，可以粗略；进了「请作者确认」这一步的数字，不行。

长路径工作目录下的 git 和原生程序

核心：Windows 下当前目录太长时，git clone 和部分原生 exe 会直接失败。

来源：会话目录约 165 字符。git clone 报 '$GIT_DIR' too big；在过长的当前目录下启动原生程序，报「path longer than allowed for a Win32 working directory」。

验证状态：⚠️ 首次发现

操作规则：

1. 用 git init 建仓，再 git config core.longpaths true，然后 git fetch，代替 git clone。
2. 下载、解压这类命令不 cd 进长路径，直接给完整的输出路径。

反例/边界：路径较短的工作目录不需要这么做。

下次改进

• 如果重来，最想改的一步：报导出模板大小那一步。作者是按 169 MB 同意下载的，实际是 1.2 GB；同意依据错了，比下载慢更严重。
• 下次同类任务的行动清单：
  1. 修复合进 main 以后，回头看有没有对应的 issue；发版时在 Release 说明里点名 issue，并在 issue 下回复版本号。
  2. 发版开头就把超过 10 MB 的文件一次放进下载文件夹，让作者一次拖完。
  3. 可以考虑用 tag 触发 CI，自动导出三个包，省掉本机 1.2 GB 的模板和手动上传。还没试过。
  4. 请作者真机终验：拖窗口边缘缩放；手机 Toy 上的正计时。

一句话提炼

分诊老 issue，最快的办法是在报告者的版本上复现一次、在 HEAD 上量一次。这次两个数字（676 和 644）同时说清了两件事：「早就修好但没发版」，以及「还剩一个更小的同类问题」。工程上三端都上线了，用户是否满意还没有数据。

关联文档

• 同一个游戏的前两次发布：2026-06-26_桌面应用打磨发布闭环复盘_工位池塘v0.5.0_v1 · 2026-09-29_右下角的池塘_游戏宣传微电影_实录混剪到双语字幕发布_复盘_v1
• 本次补丁：2026-07-11_B站Toy同步事故复盘_版本指纹与外部cron兜底_v1 · 无Mac冒烟测试macOS版_GitHubActions截图验字体_v1 · 浏览器插件自动化的能力边界_v1
• 同族纪律：交付前实测证伪律_v1 —— 回归测试自己也要先被证伪
• 复盘方法：复盘事实先行原则_v1 —— 工程成功不写成作品成功
• 推送方式：个人项目免PR直推主分支_v1
• 临时环境：展台机易失环境自恢复预案_v1 —— git 身份和工具链在临时机器上都得现装