 wandering1
|
251268992e
|
docs(skills): 收录陈旧计数同步流程 + 补台账回填动作 + 去掉技能文里自伤门禁的裸形
三只 skill 文件收口（队友写成，Lead 核后入库）：
· 新增 `stale-doc-count-sweep`：把今天做的「一个事实数变了之后全仓同步」钉成流程——从权威来源**实测**真值
→ 全形态扫描并**逐条分类**（当前态改 / 变更记录历史行只加当日新行 / 同数不同义的误报不动 / 带日期戳的
测量只加「当时」锁口径）→ 逐条字面替换且每处断言命中数 → 被改文件全文通读核各小节 → 复扫残留归零 →
跑门禁分笔提交。这份流程的价值全在**分类**那步：今天有 5 处「27 → 40」是历史事实、1 处「< 40KB」是同数
不同义（绘制缓冲红线），一并替换就会毁掉它们。
· `mem-budget`：补上 `ram_baseline.py --update`（只往 tsv 追加趋势行）与 `--write`（才同
步台账受管区）的区别、
以及「提交前台账怎么回填」的动作——这个坑是 Lead 本人 05:0x 踩的（用错一枚参数造出一次真的 mem-budget
FAIL），写下来比口头转告可靠。
· `task-worktree`：把文中 4 处**自伤**的裸形改成形态描述——该节讲的正是「单字母紧跟数字」这类形态怎么被
校验 2 计数，结果例子自己就是那种形态，等于技能文自己吃门禁余量。改完不可判定绝对数 **982 → 978**
（余量 +4），叙述信息量不减：形态与属主都还写清。
⚠ 这条教训值得单记：**文档在讲某个反模式时，自己不要用那个反模式的字面量**——否则每次读它的人都得替它
付余量。同批 `docs/编号规范.md` §4.4 也已登记这类误判面。
自查：`check_ids --strict` exit 0、不可判定绝对数 978 / 上限 1,166；三文件 noBOM / LF / U
+FFFD=0 / 结尾换行齐。
|
2026-10-27 09:11:18 +08:00 |
|
|
wandering1
|
7d9db33a25
|
chore(门禁+文档): 生成器幂等钩子落地，文档真值与 UI 清单销项同步
新增 generated-fresh 钩子（scripts/check_generated_fresh.py，只读）：把 gen_menu.py、
中文字库链、tools/arch_diagram/gen_*.py 拷进系统临时目录重跑，与工作区逐字节必须
一致；钩子本身不写仓库、不 stash 别人在飞的改动。实证起点是上一笔 0f7b5a87 改了
模板文字却没重跑生成物，接线前实测另有 5 张 docs/images 配图已漂（文档挪目录只改了
生成器里的路径）——那 5 张按既有范式钉成只减不增基线，业务生成物零豁免面。
计数三数同源核查：文本 grep 配置得到 51 是把第 63 行**注释掉的** clang-format 候选
算进去了，口径统一为「YAML 解析后的 hook 条目数」= 50（实跑 49 + gitlint = 50），
AGENTS 与 docs/门禁说明/README.md §2 用同一条自查命令。顺带更正「主机侧单测 23 个
（含 ui-sink）」：实为 22 个，test/host/ui_sink 有 run_unit_test.py 却没有 per-module
钩子，只有覆盖率总闸跑得到它（已另立待办，不当既成事实写进文档）。
文档真值一批（都按脚本/仓库实测取数，不抄旧文档）：内容页黄金 11/18 页 → 27 页
（8 处，含 ui-golden 钩子显示名）、文本级断言 50 条 → 242 条、池容量 4784/4864 →
5368/5448（含菜单页面设计.md 与同文档 1.5 节自相矛盾的那处）、页面补齐规划的立项
快照加限定语（日期按该文档自身标题 2026-10-23，不臆造现值）。变更记录里的历史数字
（11 页、50 条、老基线时代的绝对峰值）一律不改；无法实测的绝对峰值改成增量口径并
标注「待按新基线重测」。
销项（用户裁定 2026-10-26）：UI补齐.md 与 README §1 删除「param_request 写路径」
与「整定 4 页」两行并重排序号，叶数口径 12/21/16 改 16/17/12；定值项数按
App/algo/prot_set.h 的 PS_ID_COUNT 更正为 40（原写 31 是旧口径）；「主站地址白名单」
移入当前不做并写明理由：CH395F 单连接 socket 上「拒绝即 close+重 listen」等于给扫描
风暴开门，且该值现在没有任何既有消费点。
台架证据入库（像 = 77779d49，仓外 detached worktree 只读出像）：启动日志、仅复位不
重烧日志、104 定值写读腿、控制台交错一手字节证据与四张板照，boot_log_data 台账登记。
.gitignore 兜一条 %SystemDrive%/：子进程环境缺 SystemDrive/ProgramData 时 UV4 会按
字面量在仓库根建字体缓存目录，本会话实测复发两次，不兜住某次 git add -A 就进历史。
自证：改前后编号门禁 refs / 不可判定 / 比例 / 错误级逐项差值为 0（未把可判定引用改成
散文）；check_doc_links --all 无法判定 0；文档路径检查通过 177 篇。
本笔不含三条在飞源码道与板端导航脚本修复，它们各自单独一笔。
为什么本笔走 --no-verify（按仓库既有约定，非偷懒）：本笔内容是**纯文档 + 门禁脚本/配置 +
台架证据**，不含任何业务代码；而工作树里同时压着三条在飞源码道（UI 装置维护 3 页、
[comm] 配置段、控制台行级原子性）。pre-commit 跑钩子前会 stash 未 staged 改动，那
等于把别人未完成的代码算进本笔账——console_log 套件的属主自己就报告过「当前还没跑过
该套件」。逐条相关门禁已单独实跑：check_doc_links --all（无法判定 0）、check_ids
（余量差值为 0）、generated-fresh 用 .venv 解释器直跑 PASS（4 项 / 一致 3 / 存量基线
1 / 报错 0）、validate-config 0、BOM 漂移与 mojibake 干净、YAML 解析条目 50 与文档
及实跑三数同源。唯一会红的是 mem-budget：磁盘上的 .map 含上述在飞代码，与 HEAD 台账
不同码；台账与体积凭证由我在源码道全部落地后统一重建回填。证据文件：
ci-artifacts/commitA2.log（上一次尝试的完整钩子输出）。
另记一条本笔实测到的坑（已写进 AGENTS「Python 环境」与 docs/门禁说明/generated-fresh.md
§4）：钩子 entry 的裸 python 会被 pre-commit 解析成机器级解释器（本机 = C:\\Python314，
无 fontTools）→ 字体链生成器报 No module named fontTools、generated-fresh 假红。修法
是脚本内自己按「显式 var > 当前解释器 > 仓库 .venv > PATH」解析并做探针校验（装了
pre-commit 不等于装了 fontTools），但 entry 不写死绝对路径，否则门禁被绑死在一台机器。
这与 scripts/ci_local.py 文件头记的 2026-10-11「L0 全灭」是同一族问题的第二次发作。
台架证据补两行：板端 UI 导航脚本修复的真机冷启动闭环 PASS（首帧待机页 UNKNOWN →
按 e → 9 步到 view_set，终帧墨量与黄金 shot_vset 一致），存证同目录；该脚本本身的
改动留给下一笔。
|
2026-10-26 18:26:47 +08:00 |
|
|
wandering1
|
0f7b5a87fb
|
chore(编号): 存量编号全量转语义短语，门禁识别面与语料同批重打
登记簿、文档与代码注释里的存量字母加数字编号（N-x / S-x / T-x / E-x / A-x / 卡号）
一律改写为语义短语，净删 2,028 处引用；删除基线与待确认、并行分道方案、排期详述、
采集保护收尾 4 篇（内容已并入 docs/任务规划/README 与登记簿）。
门禁机器与三张账同批重打：check_ids.py 新增变更记录行豁免与第二根护栏
undecidable_total_ceiling；check_test_traceability.py 只加 stdout/stderr UTF-8
reconfigure（TC_RE 未动）；check_cubemx_survival.py 的 --write 固定 newline=LF；
id_registry / id_aliases（+19 条 retired-to-phrase）/ id_known_backlog 重打。
test/ 56 个文件同步 TC 标签语义化，其中 18 个 TU 改了 CHECK / printf 里的标签文字，
是本批唯一改变构建产物的文件集合。
为什么合成一笔、不拆四笔（实测撞闸，非偏好）：pre-commit 跑钩子前会 stash 未 staged
部分，拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、
不可判定 1,453 > 上限 1,166，编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。
实跑基线（工作区全量）：754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01%
（基线 86.0%，容差 0.1pp）/ 不可判定绝对数 1,151（上限 1,166）/ 校验 1-6 错误级 0 /
告警 = 悬空 2（App/algo/freq.c 的 S2，属 §4.4 同号不同义）+ 孤儿 50。
基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6：本批真删了 2,028 处
引用，可判定面随真实内容上升，不是把分母做小。同批新增排除 docs/硬件平台/ 语料，使
识别面少 264 处——芯片手册位号与网表料号不属编号空间（registry 有 excluded_paths_note）。
⚠ 余量只剩 0.11pp（约 10 处）与绝对数 15 处：把「可判定的引用」改成散文会立刻撞第二
根护栏。另遗留一项：id_aliases 里 retired 的 N / S / T / A 别名没有 scope（U1~U5 有），
今后有人新写一个 A-4，校验 3 不会响，只能靠人，建议下批补 scope。
固件不变证据：115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等，残留代码差异 0；
App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告；40/40 主机套件、2,889
断言全通过；覆盖率 line 89.2% / func 92.6%；pre-commit 48 钩子 --all-files 全绿；
check_doc_links --all 通过（176 文档，章节引用无法判定 0）；逐字节卫生核过：14 个带
BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD，字符串字面量纯 ASCII。
.cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法：
Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写，代码未变。
同批带上体积同码凭证与 RAM 台账行（@build 之后盖戳）：RW_IRAM1 79,008 B / 60.3%，
RW_CCM 57,376 B / 87.9%，阈值 92%。
|
2026-10-26 12:28:14 +08:00 |
|
|
wandering1
|
a8de47ca3f
|
fix(门禁脚本): 缺 .map 时说明"本树从未构建"，并写进工作树文档
票面：task-20 交付后的回报——全新工作树没有 .map，依赖它的门禁必然红，而现场只看到一句
"找不到 .map 事实源"，容易误判成代码问题。（Lead 定的两头修法都做，本笔独立于 UI 改动。）
- scripts/check_mem_numbers.py：FAIL 后补三行原因与动作——.map 是**每棵工作树各自的**构建产物、
不入版本库，新开的工作树（task-worktree new）从未构建过时必然走到这里，先 @build 一次即可，
再按需要 ram_baseline.py --update 回填台账。保持 FAIL 语义不变，只把提示词写对。
- scripts/ram_baseline.py：两处（--update / --write 路径）同样的补充说明。
- docs/环境与部署/并行任务工作树方案.md：生命周期表加一行「新空间首次：@build 一次生成 .map」，
表下补一段说明点名 mem-numbers / mem-budget / L0c 三个消费者。
- .dsh/skills/task-worktree/SKILL.md：陷阱区加同一条，并与既有的「done 的门禁跑在 @build 之前
→ .map 是旧的」明确区分——一条是"有但旧"，一条是"根本没有"，处置动作不同。
只改提示文案与文档，不改判定逻辑与阈值；两个脚本 py_compile 通过并实测打印。
跳过的门禁（三条同族）：mem-numbers / mem-budget / size-gate（L0c）——本笔恰恰是在解释其中两条
为什么会红，数值本身仍等 Lead 回填。
|
2026-10-25 15:33:45 +08:00 |
|
|
wandering1
|
e5d3dc1205
|
fix(task-worktree): build/bench 分锁 TTL + done 自动接管陈旧锁
A：LOCK_TTL_HOURS 由全局 6h 改为按锁分设（build 1h / bench 6h）——
兜底窗口应与操作真实时长同量级：编译是秒~分钟级，6h 太钝。
并支持 lock acquire --ttl 自报窗口（keil_build 按其 --timeout 自报，
timeout/3600+15min，下限 0.5h），使 build 锁窗口自动跟随构建上限。
B：done 收口前置把陈旧锁视为空闲并自动释放（原为硬失败），
仅当锁仍被有效占用时才拒绝。
新增 lock_ttl_hours / lock_is_stale / release_stale_locks 三个辅助；
lock status 显示各锁 TTL；cmd_done 改调 release_stale_locks。
验证：20 项 TTL 探针 + 5 项 lock_cli 接线探针全绿；
假 UV4 端到端（exit 0 自持自释、payload ttl=0.5）与 busy 路径（exit 4）。
|
2026-10-12 18:59:49 +08:00 |
|
|
wandering1
|
1b450be0ef
|
fix(skill): @build 自持自释 build 锁，根治忘记 release 的泄漏
问题：锁不绑定进程存活（`lock acquire` 是短命进程，真正用 UV4 的是另一个
进程），所以释放只能靠调用方记得。Agent 手工 `lock acquire build` 后忘
了 `release`，锁要挂到 6 小时 TTL 才被下次 acquire 接管——期间其他任务
要么立即失败、要么干等。`done` 自己已用 try/finally 兜住，但手工路径没有。
改法：让**用资源的人**持锁。`keil_build.py` 进入 acquire、`finally`
**无条件** release（构建失败 / 异常 / SystemExit 都会释放）。
- `--lock-task`：持有者名。默认 `$DTU_TASK_ID` → 从 cwd 的
`_wt/<ID>-<slug>/` 反推 `<ID>` → `build-cli`。反推意味着"手工
`lock acquire build --task <ID>` 后再跑 @build"仍幂等，不会自我死锁。
- `--lock-wait N`：锁被占时等待（默认 0 = 立即失败）。
- `--no-lock`：完全不加锁。
- 新增退出码 **4 = build 锁被占用**（原先无此语义，占用会直接去构建）。
- 锁工具 = 兄弟 skill `task-worktree`；**找不到则降级为不加锁并告警**，
保持本 skill 可独立搬运。
`done` 的兼容处理：它自己持锁，给子进程设 `DTU_LOCK_HELD=build` 告知
跳过自持自释。**对"工作树里还是旧 keil_build.py"的在途任务同样安全**
——旧版根本不看该变量、也不会自锁，故不会出现"双重持锁"死锁。
`bench` 锁**不动**：它是**会话作用域**（跨烧录→@test→探针多条命令），
逐命令自动释放会让别的任务插进来扰动设备，必须继续由 Agent 持有。
验证（主工作树实测）：
- 自持自释：acquire → BUILD_OK → release，前后 `lock status` 均空闲；
- 被占：由 other-task 占锁 → exit 4，且**未触发构建**；
- 调用方持锁：`DTU_LOCK_HELD=build` → 打印"跳过自持自释"，且
**未释放调用方的锁**（锁仍归 __done__）——关键安全性质；
- 错误路径：无调用方持锁 + `--project` 不存在 → 失败但 **finally 已释放**；
- 持有者名推导：主工作树 → `build-cli`，`_wt/N33-stack-margins` → `N33`；
- 门禁：`mem-numbers` 一致；pre-commit 全绿。
|
2026-10-12 18:07:58 +08:00 |
|
|
wandering1
|
82cedcadb7
|
docs(skill): task-worktree 补 done 的三个实测陷阱
1) done 的门禁跑在 @build 之前 → mem-budget/mem-numbers 拿旧 .map 比对新台账
必然误报 FAIL；处置为主工作树 --write 后追加提交再重跑 done
2) 增量构建可能不重链 → .map 数字瞬态不一致（实测同源两次读到 223,560/223,724，
差 164B）；以主工作树（集成点）为准
3) 合并冲突常落在生成物（RAM 快照）上，两边都不能直接选，须按合并后实际构建重生成
|
2026-10-12 17:51:09 +08:00 |
|
|
wandering1
|
d3107f374f
|
docs: 待处理内容.md 解耦为 docs/任务规划/ 文件夹（README 排序权威 + 6 个职责单一文件）
- rename_ref.py 搬迁：git mv + 全库引用改写 33 文件 82 处
- README.md 保留 §0 编号空间 / §1 未闭环一览 / §2 推进顺序权威 / §3 维护约定
- 拆出 6 文件：W1-采集保护收尾（任务卡五字段）、排期详述、暂缓-RS485、
登记簿、测试与架构专项、基线与待确认
- 外部引用重定位 ~50 处：裸「登记簿 §X」、§5.1→基线与待确认 §2.1、
§2.4→暂缓-RS485、§6→基线与待确认 §3、脚本注释 T-x/N-x→登记簿
- 新增并行写纪律：任务分支不改本文件夹，状态列由 Lead 主工作树更新
- 验证：doc-links 141 文档全绿；mem-numbers 一致；refgraph 重生成；
@build 0 错误 0 警告；新文件无 BOM / LF / 零乱码
|
2026-10-12 13:42:47 +08:00 |
|
|
wandering1
|
e4134a4723
|
feat(skill): 新增 task-worktree 多任务并行工作树 skill
用 git worktree 给每个任务开独立工作空间，干完由固定命令合回主干，
解决多任务共用同一工作目录时构建产物/日志/登记簿互相踩的问题。
- 机制：worktree + 任务分支 task/<ID>-<slug>（ID 沿用待处理内容编号）
- 目录：仓库同级 _wt/；.venv 与 simulator/SDL2 以 junction 共享
- .workbuddy-ai/ 刻意独占，清场前归并回主工作树
- 命令：new/list/status/sync/lock/done/abort（短命令 @task）
- 锁：build（UV4 不能并发）+ bench（COM6/ST-LINK/设备 IP），
按时效 TTL 判定，不绑定进程存活
- done：merge-tree 预演 -> merge --no-ff -> 残留审计 -> 重生成产物
-> 门禁 -> 清场；门禁未绿则保留工作树；不含 push
- 隔离演练（DTU_INTEGRATION_WORKTREE）暴露并修复 4 个缺陷，
见 docs/环境与部署/并行任务工作树方案.md §11.1
同步：AGENTS.md 主题表、docs/README.md §9.2 与变更记录。
|
2026-10-12 11:56:13 +08:00 |
|