wandering1
511fd30cc6
用户裁定：文档只写现状，历史流水一律删掉，过程查 git log。 - 43 篇「变更记录 / 修订记录」整节删除：继电保护规划 12.6 KB、产品 需求 11.8 KB、项目部署环境 5.5 KB、BSD Socket 指南 5.3 KB、架构 总览 5.0 KB、实机测试实施指南 3.8 KB 等 - 23 篇别处仍有指向：只留节名 + 一行「本文件不再记流水账，过程查 git log」，节号与锚点不位移（doc-links 不因此断链） - 5 篇整表保留（被当唯一证据 / 活台账引用）：看门狗设计说明、配置 文件设计说明、RAM预算台账、内容页架构、本地工具路径环境变量方案 - 规范同步：文档规范 §5.1 改新裁定；测试文档模板规范删示例节与 登记句；测试开发标准流程 / UI 两篇 / 实机测试实施指南 / 四篇单测 说明 / 并行任务工作树方案 / 编号规范 的「登记变更记录」改「写进 正文」 - 技能同步：stale-doc-count-sweep / ui-verify / id-family 三个 SKILL 正文不再要求追加流水行（顺带消掉 SKILL.md:121「产品需求 §12」 失效引用） - 修 5 处悬空指针：采样有效性校验目录锚点、BSD 指南「文末变更 记录」、docs/README 过期描述、网络自愈架构两处指向面 72 篇文档净减 600 余行；check_doc_links --all --sections-strict 可判 定比例 61% → 78%、失效引用 0；静态门禁 passed=50 failed=0；gitlint 10 条历史提交信息 0 failed。 未提交他人在飞改动：.dsh/skills/keil-build/*（%SystemDrive% 守卫）。
3.7 KiB
3.7 KiB
task-table — README / AGENTS 里的任务表是否与 Src/freertos.c 一致
一句话：任务名 / 栈字数 / 优先级这三列不许手抄，事实源是
Src/freertos.c。
- 归属："文档与源码一致性"里的任务表档（口径见
docs/文档规范.md）。 - 配置：
entry: python scripts/gen_task_table.py --check、pass_filenames: false、files: ^(README\.md|AGENTS\.md|Src/freertos\.c)$。
1. 它在查什么
- 解析
Src/freertos.c里const osThreadAttr_t <name>_attributes = { .name = …, .stack_size = N * 4, .priority = (osPriority_t) osPriorityX }形式的块； - 把
stack_size按N * 4换算回 words（CMSIS-RTOS2 的单位是字节，本仓约定写words * 4，所以注释里的数字就是字数）； - 重新渲染被
<!-- TASK_TABLE:BEGIN … -->/:END包住的表格区，与文档现状比对，不一致即 FAIL。
2. 为什么要它
- 真事故：历史上两张表全靠手写，
Src/freertos.c改栈后表忘了同步——2026-09 实测两张表都比 源码落后一大截（表里写 2048/4096/4096/4096/16384/2048，实际是 1024…512）。 - 为什么这件事在本仓特别危险：栈大小是 IWDG 任务健康判定与栈水位核算的输入，读者拿错的
表去推余量，会得出"还有余量"的错误结论（同一思路见
mem-numbers）。
3. 触发面 / 看不见什么
- 只校验受管生成区内的表；受管区外手写的任务叙述（散文里的"某某任务栈 640"）不校验。
- 只解析
osThreadAttr_t常量块形式。用变量、宏或运行时拼出来的属性 → 解析不到，表里那一行会消失而不是报错（少一行比错一行更隐蔽）。 Src/freertos.c是 CubeMX 生成文件（只允许写USER CODE区）→ 任务表本身由 CubeMX 生成， 重生成后本门正好负责发现"栈被模板改回去了"。
4. 报错怎么读
FreeRTOS 任务表一致性.......Failed
AGENTS.md: 任务 protectTask 栈 512 与源码 640 words 不一致
-
同步：
& '.venv\Scripts\python.exe' scripts/gen_task_table.py --write（只改受管区，两处文档一起改）； 只看期望值：--diff。 -
典型报错：
[FAIL] 以下文档的任务表与 Src/freertos.c 不一致：README.md。 -
改栈只有一条路：先改
Src/freertos.c→ 跑--write同步两处文档 → 提交。钩子报不一致时 不要手改表格——手改会被下一次--write覆盖，还掩盖了"源码其实没改"这个真问题。 -
脚本按文件原有换行符与 BOM 状态回写，不会造成整文件行尾漂移。
5. 好处
- 抬栈 / 加任务时，表格跟着源码走，评审看 diff 就知道动了哪个任务的栈；
- 与
mem-budget、stack_report.py形成闭环：表里的字数是核算的输入，不再靠记忆。
6. 限制与盲区
- 只保证"表 == 源码属性块"，不判断这个栈够不够（够不够要靠
scripts/stack_report.py静态最坏链 + 串口[STACK]实测）。 - 只覆盖受管区；README/AGENTS 散文里的任务与栈叙述无人核对。
- 解析依赖固定形状（
N * 4）；换成宏或表达式就静默漏掉该行。 - 任务是否真的被创建、是否纳入看门狗
required_mask，不在本门范围（那是Src/freertos.c与看门狗配置的语义问题）。
7. 豁免与基线
- 无基线：不一致即拦。合法动作只有
--write（把文档改成与源码一致）。
8. 改这个门禁本身
- 加新的属性字段（例如
mpu_stack_size）要同步解析器与表头，否则新字段静默丢失； - 改列顺序会同时改两处文档，属于"生成物改动"，提交里要写明。