tamakyi
3f1b737a78
用户要求这份记忆跟着仓库走，而不是只留在本机。 .gitignore 里挡路的是 `.workbuddy/`。改成反忽略六行，并且**只放行 .md**： 别用 `!.workbuddy/memory/**`——它会把 memory 下任何文件都放行，本项目真发生过 `web.test.exe` 混进暂存。复核用 `git check-ignore -q --no-index` 逐条打靶： memory/*.png、memory/sub/x.md、memory/MEMORY.md.bak、plans/a.md 全 IGNORED， 17 个 .md 全 included；`git add -An .workbuddy/` 恰好 16 个文件。 其余 .workbuddy 内容（计划、本地设置、临时产物）继续忽略。记忆里没有真凭据 （唯一命中是 2026-09-14.md 里的 `password=rond-admin`，那是项目默认口令）。 顺带做两件整理： 1. 取证了注入上限。以前按「字节数」判断 MEMORY.md 是否超限是错的： WorkBuddy 的 `getWorkingMemoryContent()` 用 `MAX_MEMORY_CHARS = 1e4` 比 JS `content.length`，即**字符数**（中文 1 字算 1）；超了 substring 截断、尾部静默丢失。 本 details 与每日日志都不参与注入，只有 MEMORY.md 受约束。 现已从 6604 字符收到上限的 66%，并把这条上限写进索引抬头。 2. 把「备份合并」「导出/恢复三条铁律」两段长文迁进 MEMORY-details.md 的卅一/卅二节， 索引只留关键词指针。行尾统一为 LF（仓库 .gitattributes 是 `* text=auto eol=lf`）。
1.9 KiB
1.9 KiB
2026-09-23 工作日志
第十一批（前端 P2 收尾）完成 + 全量审查
- 修掉原报告 P2 前端剩下的 8 条：F5/F6（
rond-map.js：localStorage 走lsGet/lsSet；previewQueue在if (live)之前排队）、F8/F9（photo-exif.js：EXIF 时间范围校验、findExifItemID读宽度守卫）、F14（app.css删死内边距）、F16（edit.html三个筛选表单带全 8 个参数）、 F17（view.go删safe）、F18（place.htmlaria-label + alt）。 - 新增
internal/web/frontend_fixes_test.go，本批 9 条守卫（含补的 F10：fillup.html的 sessionStorage 读写必须包 try）。全部逐条变异验证（注入→红→还原→绿）。 - 重要发现：F10 的代码早在提交
82e6341就修好了，原报告「尚未处理」清单与表格 ✅ 标记是陈旧的。 审查时把 F11/F12/F13/F15 也复核了一遍——同样是在更早批次已修，只是表格漏标。 - 最终验收：243 PASS / 0 FAIL / 0 SKIP，12 个包全
ok；导出 823/323/8/30/791/557/2246 全等、 坐标偏差 0、时间偏差 0s、迷雾 8701 块一致（本批不碰数据路径）。 - 完整审查另抽查复核 3 条早期批次守卫（D6 区域判定、S8 GPX 属主 ×2）——重新注入原始 bug 全部转红，
报文与当时记录逐字相同；还原后
git diff --stat与注入前一致。 - 报告
audit-2026-09-21.md已补「修复记录（第十一批）」「完整审查（2026-09-23 收尾）」， 「尚未处理」清空，验收状态更新到 243。
记忆整理
MEMORY.md之前 14,471 字符，注入时被截断（尾部「安全/跳转」「口径/验收」收不到）。 已把完整判据搬进MEMORY-details.md新增的第二十八节，索引压到 8,650 字符 （只留一句话判据 + 守卫名）。以后新规矩写 details / 技能，别再堆索引。