8 Commits

Author	SHA1	Message	Date
super_agent_bot	0d21d9bf04	fix(nand-ftl): 传输失败不再误标坏块 + format 不再被脏缓存挡死（#79） ... 根因（真机定案，问题 #79）：旧 dhara_nand_erase/prog() 把一切失败一律 mark_bad，而 mark_block_bad 每次**立即持久化**板级 BBT（不可撤销）—— 一次传输层/等忙抖动就把好块永久记成坏块。台架 129 个好块（1016–1142 连续段）被固化，journal prepare_head() 连续 8 次撞 is_bad → TOO_BAD → Cache flush FAIL → reformat 又被同一页挡住 → 整卷禁用、重启不恢复。 - 修复①：只有芯片明确回 E_FAIL/P_FAIL（状态位证据）才标坏； 传输/超时失败只报 DHARA_E_BAD_BLOCK 让 dhara 重试，不标坏 - 修复②：nand_ftl_format() 尽力刷一次脏缓存，失败即丢弃并继续 dhara_map_clear()（格式化语义本就是销毁映射；旧实现第一步返回， 恢复动作在同一页死锁，f_mkfs 全在旧映射上必失败） - C4 还债：新增跨调用失败类快照 nand_ftl_fault_get/clear（20 B， resume/读/刷/同步四点位记账）；defaultTask 探针按类分流， BSP_ERR_NO_SPACE 跳过重格式化（容量问题不该用 mkfs 解） - 哨兵与诊断：init 解锁块保护（A0h）后补回读校验（与 B0h ECC 同族 缺口，实测本板 A0h=0，非本次根因，留作哨兵）；gd5f_bbt_load() 合并后坏块数 > 出厂扫描时打「BBT after merge」，现场可区分 真坏与误标固化 - 测试：主机单测 149→178 全绿；新增 format 死锁（TC-NANDPORT-800.. 813b）、传输失败不标坏（207 语义翻转 + 208/505）；牙齿检查过—— 把修复回退即见红 - 真机：恢复动作 A 重建 BBT 清除已固化误标（3/3 PASSED，BBT version=71）；产品镜像复烧 [FS] FATFS mounted、配置出厂模板 落盘、0 条 flush FAIL——#79 真机闭环（旧卷内容随 map clear 作废，台架卷为可弃数据） - 文档：存储架构说明 §10.4 口径修正 + 新增 §10.4.1/§10.4.2（页级 失败升级链与误标持久化机理），存储维护与容量恢复 §2 补板级 BBT 独立持久化注记 + §2.1（动作 A 此前静默失效），登记簿 C4 销项 - Keil 0 错 0 警（Code=255552，与烧录验证镜像一致）；doc-links 213 文档通过	2026-11-04 18:51:24 +08:00
wandering1	f754d59218	docs(测试说明): 按用途分六个子目录并同步全库引用 ... 分层：流程与规范/ 单元测试/ 板级测试/ 专项验证/ 测试工具/ 测试数据/， 顶层只留新增的目录导航 README.md（归层判据 + 硬约束 + 本次处置记录）。 - 搬迁 28 个路径：测试数据三个目录 58 个文件为纯改名（R100，内容逐字节不变） - 全库引用同步 124 个文件：AGENTS / docs 索引 / skills / 门禁注释 / scripts - 门禁面：scripts/check_test_traceability.py 的 glob 改 rglob （分层后不递归扫描＝追溯门禁直接瞎掉） - scripts/rename_ref.py：收尾的 ℹ 提示在 GBK 代码页抛 UnicodeEncodeError， 让进程以退出码 1 收场而改写其实已落盘（RC 与真实结果相反）；改为把 stdout/stderr reconfigure 成 UTF-8，与 check_doc_links.py 等同法 - docs/文档规范.md §1.1 补「子目录文件过多时再分一层」；§3.6 补 rename_ref 搬整目录的两个实测坑：① 会改写目录内部文件的内容 ② 内部文件的 ../ 出链 不补层级（本次 23 个被误改的证据文件已按 HEAD 原始字节逐字节还原） - docs/README.md §6 改为与六个子目录一一对应，并补登原先漏登记的 「启动日志原子性复验流程」一行 - .cubemx_survival_baseline.json：App/util/task_watchdog.c 的注释路径也随分层更新， 该文件是存活审计的 watchdog-module 漂移锚点，按脚本自己的提示跑 --write 重建基线 （实测重建后仅 watchdog-module 一条哈希变化） - 铁律 4 例外（本次在任务树里改了单写者文件）：AGENTS.md 与 .pre-commit-config.yaml 只被 rename_ref 改写路径字面量（后者全在注释行）， 任务表块与钩子声明一字未动 验证：check_doc_links.py --sections-strict 覆盖全部 88 个改动 .md 全绿； check_test_traceability.py 输出与主树逐行一致；196 个文本文件无 BOM、无新增 CR、无 U+FFFD、无行尾空白；陈旧引用面由主树 25 处降到 6 处（无新增断链）。	2026-10-30 07:16:07 +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	2575177e81	refactor(gate): bsp-err 四项检查改用自描述标签，废掉 R1~R4 这组撞车代号 ... 纯改名，检查行为一个字没动：规则逻辑、阈值、豁免形状全部原样。 改名原因（用户一句「R4 到底是什么」问出来的）：R1~R4 是我在 check_bsp_err.py 注释里 自造的序号，而这个裸形在本仓另有含义——R1~R8 已在 scripts/id_registry.json 登记为 "专项风险"的文档内编号（保护规划与看门狗的风险表都在用），带连字符的那一族又是审查 报告的可靠性 / 内存优化项编号（编号规范 §1 的"连字符承载语义"一行正是这么写的）。 **同一个裸形四种意思**。最刺人的一点：编号门禁**不会报**这种撞法，因为编号规范 §4.3 已把这些裸形声明为"同号不同义"、走 collides_with 白名单，校验 4 不计事故——同一天里 我起的另一组自造号被当场拦下、这组代号却一路绿灯，差别不在我做对了什么，而在白名单 挡的是"事故"、不是"可读性"。 新名同时是基线键的第二字段（格式 文件|标签|名字）： · err-type 错误通道不外泄（对外接口不拿 HAL_StatusTypeDef / bool 当成败） · timeout-name 超时宏不取负值 · return-doc 公开函数必须写「返回值：」 · consume-result 返回值不得裸丢弃（须接住或显式 (void)） 老名对照：R1=err-type、R2=timeout-name、R3=return-doc、R4=consume-result。 同步面：脚本里的规则码与 38 条基线键的字段**一起换**（中途不跑 --prune，否则改名会被 读成"38 条全还清 + 38 条新账"），换完 --emit-baseline 复核仍是 38/38/0、RC=0。现状类 文本全部换新名：AGENTS.md、pre-commit使用说明.md §2.27（新增"检查项叫什么"一行含老新 对照与撞号说明）、bsp_err.h 边界纪律、报告 §0.4 / §9 / 附录 A，以及代码注释里的 5 处 （gd5f2gq5ue.c/.h、nand_ftl.h、ui_menu_tab.h）。已提交的变更记录行里的老名按"冻结历史 不回改"处理，以 §2.27 对照行为准。ui_menu_tab.h 带 BOM，Edit 又剥掉、已按原样补回。 写说明文字时又被编号门禁拦了一次：我为了举例"老名撞车"，在那段话里写了两个编号字面， 被判"未紧邻文档名 / 未登记前缀"共 3 类新账——连批评自造编号的段落本身都在自造编号。 改法是不写号、只描述形态并指向权威条目。 验证：@build **0 错 0 警告**，Program Size 与上一笔**逐字段相同**（Code 213,676、RO 18,860、RW 1,188、ZI 131,500）→ 证明确为注释与文案，故不跑 @test（无指令变化）； pre-commit run 全绿 **17 项 Passed**；check_doc_links --all --sections-strict 147 篇 0 问题（中途我自己写的 §4.3 没紧邻文档名，被判成本文自引用，已补全路径）；9 个文件字节 卫生 0 异常（UI 头 BOM 仍在、无 CR、无 U+FFFD、均有尾换行）。	2026-10-23 09:36:01 +08:00
wandering1	cc2966319a	docs(S-5): 补齐 16 条返回值约定，bsp-err 基线 19 → 1，并修门禁自身误判 ... A（还债）先行，B（GD5F 的 SPI 失败被吞成成功）另波处理。本笔不改行为：@build 的 Program Size 与上一笔逐字段相同（Code 213,648、RO 18,860、RW 1,188、ZI 131,500）。 **补齐 16 条「返回值：」约定，bsp-err 存量基线 19 → 1**： · gd5f2gq5ue.h 九个 SPI 原语（wait_busy / write_enable / read_status / page_read / read_from_cache / program_load / program_exec / block_erase / check_ecc） 写全规范五要素， 并把**每个函数能返回哪些码**写死：哪一个是"可重试"的 GD5F_WAIT_EXPIRED、哪一个才是 器件自认坏块的 P_FAIL/E_FAIL、失败时出参为什么不可信（E-42 同族）。 · nand_ftl.h 从零散三行补成带模块头，并明写 **nand_ftl_init() 的 −1 抹掉了失败类**： 分类目前只在失败点进日志，要按类分支需要 C4 快照（现无消费者故未做）；同时警告"不得 把 −1 解读成卷坏了可以重格式化"（E-31 的教训正在这条上）。 · ui_menu_tab.h 五个表查询 API 由行尾短注释升级为完整块（含"越界返回 false 是保守取 只读"、"宁可按一张错表导航失败也不要按错表导航成功"这类判断依据）。 **修掉门禁自己的一条误判口径**（本笔最该记的）：R3 原本要求紧邻注释块里出现字面"返回值"， 而规范 V1.0 允许列对齐写法「返 回 值：」。后果有两层：① 合规写法被判违规；② 反向更糟—— gd5f_write_enable / gd5f_read_status 两条**早就"通过"了**，原因竟是它们的**函数说明**里顺口 写了"返回值"三个字，而不是真有一行返回值说明。**一条会因为散文里出现关键词而放行的规则， 等于在奖励运气**。修法是在块内忽略空格后再匹配关键词（排版选择不是违规），并在注释里写明 为什么不许把"必须写成不空格的形式"写进规则。 剩余 1 条刻意保留：bool ui_content_page_open()。它与"补注释"不是一档事——要改签名、要处理 3 个调用点（ui_menu.c:138/192/196 **今天三处全部丢弃返回值**，即"按 ENTER 开页失败是静默的" 这件事现在没人知道）、且 UI 源码双端编译（模拟器同一份），验证面是"重建模拟器 + 像素回归 + 真机逐页进菜单"。这不是还债，是独立一波改动，留档待决策。UI 三个文件带 BOM，Edit 会静默 剥掉 → 已按原样补回 3 字节（AGENTS 铁律：丢 BOM 后 ARMCC 按 CP936 解码，中文报 #870-D）。 **更正我自己写进文档的一条错话**：S-5 各条里我把 GD5F_SPI_TIMEOUT 100 记成"自旋圈数（改 分频时长会变）"。这次逐行核它 12 处用法，**全部是 HAL_* 超时参数或 HAL_GetTick() 差值 → 它也是毫秒**。真问题降级为"单位没写进名字（缺 _MS 后缀），读代码必须回实现里查单位"。 osWaitForever 与 HAL_MAX_DELAY 同为 0xFFFFFFFFU、以及 *_BUSY_TIMEOUT = -2 其实是返回码这两条 仍然成立（后者已改）。现状类条目（报告 §0.4、bsp_err.h、pre-commit使用说明.md §2.27、脚本 文件头）已全部改准；**已提交的变更记录行仍写着旧说法——按 §8.1 冻结历史不回改，以本笔新增 的更正行为准**。 验证：@build 0 错 0 警告（尺寸同上，故**不跑 @test**——无指令变化，跑它没有新信息）；受影响 文件的 17 个钩子全 Passed（含 ui-golden 像素回归、cppcheck、编码规范、bsp-err 1/1/0 且 --prune 干净）；check_doc_links --all --sections-strict 147 篇 0 问题；id-check --strict 通过； 9 个文件字节卫生 0 异常（UI 头 BOM 仍在、无 CR、无 U+FFFD、无行尾空格、均有尾换行）。 口径同步：AGENTS.md、.pre-commit-config.yaml、pre-commit使用说明.md §2.27 的基线计数 19 → 1； 报告 §0.4 / §9 / 附录 A 与变更记录两条（还债一条、更正一条）。	2026-10-23 08:25:58 +08:00
wandering1	bb76cfd779	修复规范矛盾并定案5项规则，保护宏统一XXX_H ... 规则定案：常量在右（a>5）、保护宏XXX_H（禁双下划线）、 头文件常量用#define、存储类前缀（g_/s_）优先、允许void返回值 全库32个.h头文件保护宏 __XXX_H → XXX_H 改名（字节级替换） S1检查规则同步更新（拒绝双下划线），Inc/gpio.h 反向验证被正确拦截 规范示例矛盾修复：K&R括号、标准类型、变量初始化、命名常量、注释字段补全	2026-09-01 16:07:00 +08:00
wandering1	65f1d72ca3	存储测试通过	2026-08-27 18:22:44 +08:00
wandering1	01ad5e476f	增加文件系统	2026-07-21 00:30:59 +08:00