docs+repo: 正式化发布——三份 README 重写为正式版说明、DEVELOPMENT.md 取代交接文档、历史档案统一更名 worklog、全库清理交接字样；脱敏：用户本机路径/设备序列号/内网 Git 地址全部泛化，.tools 本地缓存(13MB,pyc内嵌路径)移出追踪并忽略；123 单测全绿

docs/android_app/rendering_diff_phone_20261006.md

@@ -422,7 +422,7 @@ PC 端 NUC 是逐字节相同的，所以嫌疑在"实时状态机采到的参
 用户："把'计数'噪声偏大修一下"。做法：在管线里临时插桩（DebugLog 打开、逐级打印
 raw/参考/差值/NUC 的 mean/std/HF），真机跑一遍，把噪声预算算清楚，再看 A/B 差在哪里。
 
-### 12.1 真机实测的噪声预算（设备 160043865，同一静止场景）
+### 12.1 真机实测的噪声预算（设备 <SN>，同一静止场景）
 
 ```
 [diag] ffcRefFrame mean=15084 std=3625 hfdx=1172   ×4 帧（快门帧）
@@ -600,7 +600,7 @@ JPEG 只能解释一部分：把我们那张（960×720 q95，202 KB）按 640×
 → 修好后我们**比官方更平滑**（官方因最近邻 4× 反而有 4 像素大块，见 x8 放大对照图）。
 单测 119 全绿（`PhotoNucMappingTest` 更新为 160×120→960×720 的新策略）。
 
-## 16. 「官方背景条纹更不明显」——逆向排除全部候选后，定位为**我们独有的逐行固定偏移**（2026-10-06 深夜，交接轮）
+## 16. 「官方背景条纹更不明显」——逆向排除全部候选后，定位为**我们独有的逐行固定偏移**（2026-10-06 深夜，记录轮）
 
 用户发了同场景双截图（官方 vs 我们，均为竖屏、12 px/传感器像素、同一调色板铁虹）并要求
 "看逆向出来的代码是不是还漏了什么"。本轮做了两件事：把官方每帧链路逐条再对一遍（IDA 批量
@@ -656,7 +656,7 @@ JPEG 只能解释一部分：把我们那张（960×720 q95，202 KB）按 640×
 分块统计（背景块）：scene 比 0.95、1-8px 频带比 1.58、时间比 2.0 —— 我们多出来的
 能量集中在 1~8px 频带且**逐帧可复现（固定）**。
 
-### 16.3 结论与交接（下一步）
+### 16.3 结论与下一步
 
 - **缺陷**：我们的渲染里有一个官方没有的**逐传感器行固定偏移**（残余行 FPN）。
   显示旋转 90° 后，传感器行=屏幕水平线 → 就是用户看到的"背景条纹"。
@@ -850,7 +850,7 @@ Kotlin 一致），与 App 自己 `copyNuc` 的 dump 对拍：corr=0.9996，仅
 
 ### 17.7 第三十九轮：GPU 画布假设被真机 A/B 推翻，真因 = 7×7 细节增强（2026-10-07）
 
-按 §16.3/17.6 交接清单执行（首验 GPU 硬件画布 → 正式修复 → A/B 验收）。全部测量用
+按 §16.3/17.6 待办清单执行（首验 GPU 硬件画布 → 正式修复 → A/B 验收）。全部测量用
 39 轮新脚本 `final39.py/final39b/c/d/e.py`（口径：12px 网格 + UI mask + 弧长反演 +
 鲁棒 std；暗区 = sensor 行 0..40 × 列 90..160；官方横屏直接同区；38 轮存档截图全部
 可复现，官方 FULL 0.10/0.28、暗区 0.15 与 17.6 表逐位一致，DARK 对照里照片 JPEG