更新：1、更新文档；

Signed-off-by: waiwaylee <waiwaylee@foxmail.com>

CHANGELOG.md

@@ -15,6 +15,36 @@
 
 ### Removed
 
+## [1.5.10] - 2026-11-03
+
+> 本次发布归档 1.5.9（fe7e194）之后的改动（提交 c77b6c2 … 95118d8）与版本号提升：配置加载放宽 `data_rate_tas`、新增 7 份设备配置、TAS 波束俯仰下限、频点步进参数、手动取消 TAS 的时序与完整输出、单跟踪模式偶发 TWS 波束修复、用户操作日志。
+> 版本号：`PATCH_VERSION` 9→**10**（`parameters.h`，工作区未提交），运行时 `version_info` 为 **`V1.5.10.GENERIC`**。
+
+### Added
+
+- **新增 7 份设备配置样例（c77b6c2 / b728ebc / a002961）**：`config/` 下由 1 份样例扩展为 **8 份 TOML**——`config_tmp.toml`（通用样例）、`X256_PS_3S_TAS_1Hz`、`X256_PS_3S_TAS_2Hz`、`X256_MS_4S`、`X1024_PS_3S_TAS_2Hz`、`X1024_MS_4.8S`、`X1024_MS_5S`、`Ku2304_PS`；各份差异集中在 `scan_mode`、`data_rate_tas`、`tas_beam_pitch_min`、`tas_track_num_max` 与频点（Ku2304 为 `freq_0_GHz=16.5` / `freq_step_GHz=0.05`），其余键与样例一致。
+- **新增配置参数 `freq_step_GHz`（频点步进，4926e90）**：`[radar_params]` 必填 float（校验 >0），盲速计算 `kalman::Bind_speed()` 的频点由硬编码 `freq_0_GHz + freq_ind*0.02` 改为 `freq_0_GHz + freq_ind*freq_step_GHz`；样例配置取 0.02、Ku2304 取 0.05。7 份既有配置同步补该键（95118d8），加载器键数由 63 增至 64。
+- **新增配置参数 `tas_beam_pitch_min`（TAS 波束俯仰下限，66cabb8）**：`[beam_control]` 必填 float；`tas_beam_output()` 输出俯仰改为 `max(elev, tas_beam_pitch_min)`，避免低仰角跟踪波束打到地面；样例 3.0、X256_MS_4S 与两份 X256_PS 取 5.4、Ku2304 取 **-90**（等价于不限制）。**加载器未对该值做范围校验**（任意 float 均可）；7 份既有配置同步补该键，加载器键数由 64 增至 65。
+- **用户操作日志（c77b6c2）**：手动操作与队列变动统一以 `RDP_LOG_INFO` 记录——`track_clear_all()`（All track clear）、`track_delete()`（Track <批号> deleted by user）、`primary_target_add/cancel()`（设为/取消重点目标）、`tracking_start/stop()`（转入/取消跟踪模式）、TAS 队列移除（Tatget <批号> delete from TAS queue，原文拼写如此）；随 spdlog 双写同时进入标准输出与日志文件，便于复盘操作序列。
+
+### Changed
+
+- **手动取消 TAS 跟踪的时序与航迹状态（c77b6c2）**：`tracking_stop()` 不再立即清 `Track_Mode`，改为 `manual_tracking_flag=0` 并置新增的 `Trust_Track::manual_untracking_flag=1`；TAS 队列在下一次 `Beam_Ctrl` 的 `tas_target_del()` 中出队，此时才置 `Track_Mode=0` 并**输出一整套完整航迹更新行**（此前取消后航迹状态不对外更新）。`tracking_start()` 会清 `manual_untracking_flag`；`track_process(model=3)` 按指纹匹配航迹时要求 `manual_untracking_flag==0`，且不再顺带置 `manual_tracking_flag=1`（该标志只由 `tracking_start` 置位）。
+- **TAS 队列遍历上界改为配置项（c77b6c2）**：`tas_target_add()` / `tas_target_del()` / `tas_beam_output()` 的队列循环由遍历整个编译期容量 `RDP_TAS_QUEUE_CAPACITY`（30）改为 `rdp_parameter.tas_track_num_max`（样例 4、机扫/单跟踪 1）；单跟踪模式下不再扫描未启用的队列槽位（此前可能取到槽位中的残留项而误发波束）。
+- **放宽 `data_rate_tas` 校验允许 0（c77b6c2）**：`rdp_parameter_loader.cpp` 对 `data_rate_tas` 的校验由 `>0` 放宽为 `≥0`——该值只用于 `delta_T_last_track > data_rate_tas` 门控比较（无除法），**0 表示不做 DLL 内部 TAS 波束限速，TAS 波束输出间隔由宿主 `Beam_Ctrl` 调用频率决定**；`data_rate_tws` 仍要求 >0（外推步长不可为 0），`data_rate_track_only` 保持 ≥0。修复 `config/X256_MS_4S.toml`、`config/X1024_MS_4.8S.toml` 等（`data_rate_tas = 0`）经 `parameters_reload()` 加载返回 -1 的问题；`config/config_tmp.toml` 的该键注释同步说明 0 的语义。验证（Lead 实测，2026-10-30）：加载器单元测试 240 项断言全部通过（新增「`data_rate_tas=0` 允许且取值正确」「`data_rate_tas=-1` 拒绝」「`data_rate_tws=0` 拒绝」）；4 配置重建 0 warning / 0 error；5 份配置（含两份机扫配置）经 DLL 公开接口 `parameters_reload()` 全部返回 0；公开接口运行期测试 4 配置 × 38 项断言全部通过（回归）。
+- **入队/取消输出的坐标不再叠加系统延迟（c77b6c2）**：`tas_target_add()` 与 `tas_target_del()` 的即时输出行改为直接用 `X[0]` / `X[3]` 求极坐标（eb9f30c 曾按 `radar_system_delay` 补偿）；常规关联输出与波束外推仍按 `radar_system_delay` 补偿。
+
+### Fixed
+
+- **修复单跟踪模式下偶发发送 TWS 波束（c77b6c2）**：根因是 TAS 队列遍历上界为编译期容量 30 而非配置的 `tas_track_num_max`，`tas_track_num_max=1` 时仍会扫描 1~29 号槽位，取到残留目标后按 TAS 逻辑外推并下发波束；改为按配置值遍历后不再误发（见 Changed）。
+- **修复手动取消 TAS 后航迹状态不更新（c77b6c2）**：取消跟踪后原实现既不输出航迹更新行、也不及时清 `Track_Mode`，宿主界面/回放看到的状态与实际不一致；现由出队环节置 `Track_Mode=0` 并输出完整更新行（见 Changed）。
+- **修复配置加载范围判断错误导致参数加载失败（c77b6c2）**：`data_rate_tas` 原按 `>0` 校验，使 `data_rate_tas=0` 的机扫/单跟踪配置整体加载失败并保留旧参数；放宽为 `≥0` 后这些配置可正常加载（见 Changed）。
+- 文档同步（本次文档更新）：README（2/3/5.2/6.2/7.1/8.2/9.10/10.1/10.2/11.2/12/13 节）、`docs/data_process_flow_report.md`（8.1/8.2/9.1/10）按源码同步 `freq_step_GHz`、`tas_beam_pitch_min`、手动取消 TAS 的 `manual_untracking_flag` 时序、TAS 队列按配置遍历、8 份配置文件与用户操作日志。
+
+### Removed
+
+- 无。
+
 ## [1.5.9] - 2026-10-29
 
 > 本次发布把 1.5.8 之后的全部改动（提交 423c200 … eb9f30c）归档：参数配置方式改造 + 机扫/相扫合并为单一份构建、工作参数改为全局对象、日志组件改为 spdlog、构建脚本与 VS Code 任务适配、**航迹指纹**与手动转 TAS 输出修复。
@@ -46,7 +76,6 @@
 
 ### Changed
 
-- **放宽 `data_rate_tas` 校验允许 0（修复机扫配置加载失败，工作区未提交）**：`rdp_parameter_loader.cpp` 对 `data_rate_tas` 的校验由 `>0` 放宽为 `≥0`——代码中该值只用于 `delta_T_last_track > data_rate_tas` 门控比较（无除法），**0 表示不做 DLL 内部 TAS 波束限速，TAS 波束输出间隔由宿主 `Beam_Ctrl` 调用频率决定**；`data_rate_tws` 仍要求 >0（外推步长不可为 0），`data_rate_track_only` 保持 ≥0。修复 `config/X256_MS_4S.toml`、`config/X1024_MS_4.8S.toml`（均配置 `data_rate_tas = 0`）经 `parameters_reload()` 加载返回 -1 的问题。同步更新 `config/config_tmp.toml` 的 `data_rate_tas` 注释（0 语义）。验证（Lead 实测，2026-10-30）：加载器单元测试 240 项断言全部通过（新增「`data_rate_tas=0` 允许且取值正确」「`data_rate_tas=-1` 拒绝」「`data_rate_tws=0` 拒绝」）；4 配置重建 0 warning / 0 error；5 份配置（含两份机扫配置）经 DLL 公开接口 `parameters_reload()` 全部返回 0；公开接口运行期测试 4 配置 × 38 项断言全部通过（回归）。
 - **日志组件行为改为 spdlog（日志组件 spdlog 改造，24ce1e6）**：`data_process_class_dll.cpp` 的 `Data_Process_Factory::GetB()` 每次创建实例时调用 `rdp_log::Init()`（在 `rdp_record::Init()` 之前，使记录模块初始化日志也写入同一文件），`Destroy()` 在 `rdp_record::Shutdown()` 之后调用 `rdp_log::Shutdown()`（flush 并关闭日志文件）；不再使用 `rdbuf()` 重定向/恢复 `std::cout`，`std::cout` 保持宿主原始语义，日志的双写完全由 spdlog 双 sink 完成；`RDP_LOG_DIR` 路径与 `.\rdp_logs\` 命名风格保持与旧实现一致。全部 `RDP_LOG` 调用点按语义迁移为级别宏：`data_process.cpp`（`parameters_reload` 成功 INFO / 失败 ERROR）、`track_asso_tas.cpp`（ΔT≤0 告警 WARN）、`rdp_record.cpp`（19 处：初始化/统计/建表/关闭 INFO，PRAGMA 回退/队满丢弃/时间获取失败/数据库打开失败 WARN，写入失败/连续错误熔断/写线程异常 ERROR），其余注释代码中的旧宏引用同步改为对应级别宏注释；`parameters.h` 的日志说明改为 spdlog + `SPDLOG_ACTIVE_LEVEL`/`RDP_LOG_LEVEL` 描述。
 - **日志改造的第三方告警隔离**：spdlog 静态库第三方源码以目标级 `/w` 编译，包含其头文件的 `rdp_log.h` 用 `#pragma warning(push, 0)` / `(pop)` 包裹（README 4.5 已同步为第三个第三方告警例外），项目源码仍保持 `/W3` 零告警。
 - **本次日志改造的验证（Lead 实测，2026-10-28）**：① 构建：4 个配置（Release/Debug × REC_OFF/REC_ON）经 `.vscode/scripts/build_config.bat` 全部成功、退出码 0、**0 warning / 0 error**；重复执行无编译步骤（增量幂等）；`RDP_LOG_LEVEL=BAD` 在 configure 阶段被拒绝（退出码 1）。② compile_commands：Debug 配置 `-DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_TRACE`、Release 配置 `-DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_INFO`（AUTO），各目标均含 `-DSPDLOG_COMPILED_LIB`，REC_ON 的 `rdp_record.cpp`（C++20）与 DLL 源文件定义一致。③ DLL 体积：Release REC_OFF 537,088 B（较改造前 331,264 B +205,824 B）、Release REC_ON 1,855,488 B（+202,752 B）、Debug REC_OFF 3,317,760 B（+1,602,560 B）、Debug REC_ON 5,867,520 B（+1,175,552 B），增量来自内置 spdlog/{fmt}（DLL 公开接口与业务数值行为不变）；导出表仍 **31 项**（无 spdlog 符号导出），导入表仅 KERNEL32/MSVCP140/VCRUNTIME140*/api-ms-win-crt-*，无新增第三方 DLL 依赖（spdlog 为静态库）。④ 运行期（4 配置逐一编译并运行 `build/verify/build_api_test.bat`，各 38 项断言 0 失败）：同一批日志消息在 stdout 与日志文件中逐行一致；日志文件名匹配 `rdp_\d{8}_\d{6}(_\d+)?\.log`，每次 GetB 一个文件、同秒 Destroy→GetB 重连产生 `_1` 后缀新文件；日志行匹配 `[YYYY-MM-DD HH:MM:SS.mmm] [级别] [文件:行号] 内容`（中文消息正常），REC_ON 配置可见 `[rdp_record]` 的 `journal_mode`/`enabled`/`table ... created without AUTOINCREMENT`/`stats`/`shutdown` 等日志并随双写落盘。⑤ 编译期级别隔离实测：在 `build/verify/` 下独立配置构建 `RDP_LOG_LEVEL=WARN` 与 `=OFF`（不污染标准构建目录）均 0 warning；WARN 构建运行期 stdout/日志无 `[info]` 行、仅有 `[error]`（失败路径）且日志文件仍创建；OFF 构建运行期不创建 `rdp_logs` 目录/文件、stdout 无任何日志行、接口退出码正常。⑥ 静态检查：源码已无 `RDP_LOG <<` 与 `RDP_LOG_ENABLE` 残留；`rdp_log.h` 提供 6 个级别宏 + `RDP_LOG_ERR` 别名；`GetB()/Destroy()` 已实际调用 `rdp_log::Init()/Shutdown()`（非注释）。验证程序/日志位于 git 忽略的 `build/verify/`，未入库；另由独立验证者以冻结源码快照复验全部验收项（4 配置干净构建 0 warning/0 error、双写/文件名/行格式/逐行一致、WARN/OFF 隔离、dumpbin 导出与依赖、幂等与非法值），结论一致，报告见 `build/verify/verification_report.md`（未入库）。