docs: M3-1 流式可观测性/门槛缩尺/长局成本量化

- 维护说明新增 M3 批验小节：流式字段、50x20 门槛理由与实测、--cost-probe 数据表、
  Rumors 累积+全表扫描的机理与修复方向候选（本单不实施）
- Desktop 基线更新为 86/86
- overnight-status 追加本单实测与待收口

2 files changed, 47 insertions, 1 deletions

diff --git a/docs/overnight-status.md b/docs/overnight-status.md
index e8c2885..2896986 100644
--- a/docs/overnight-status.md
+++ b/docs/overnight-status.md
@@ -1191,3 +1191,10 @@ Updated: 2026-09-20 02:54:20 CST
 - **P14 派发**：prompt_async 204（13:03 CST 起 loop step 推进中，providerID=ark-plan modelID=deepseek-v4.1-flash 日志证实）。范围=上述 4 项整改+evidence 截图更新+维护说明补充；P13 已过验收部分别动。分支 p14-art-fix，verdict 协议照旧。
 - **M3 phase2 长测**：lv-m3-phase2.service MainPID=1694385 运行 ~10.5h，CPU 累计 1d13h43m 持续计算；日志仍 0 world 行无 exit 文件，verdict=null——运行中不计入验收。
 - completion-notice.md 不存在。待收口：P14 复验合并、M3 phase2 终态、最终发布门。
+
+## 2026-09-21 22:2x CST — M3-1 批验可观测性 + 门槛缩尺 + 长局成本量化（分支 m3-observability，未推送）
+- **流式输出**：`--batch K D` 改为每个世界完成即打印 `world=... OK elapsed_s=<秒>` 与 `[done k/N] elapsed=…s world=…` 并 flush；`batch_summary` 旧字段保留、追加 `workers=`/`wall_s=`。实测 `LV_BATCH_WORKERS=4 --batch 4 10`：world 行分别在 368.94s / 431.60s / 460.82s / 545.22s 出现（完成序 3,0,2,1），summary 545.23s，`M3_ACCEPTANCE=PASS`，exit 0；证据 `evidence/stream/batch-4x10.log`（逐行时间戳）。
+- **门槛缩尺**：`scripts/m3_supervise.py` `PHASES.phase2` 由 `(50,100)` 改为 `(50,20)`；`--selftest` 仍 `SELFTEST=PASS`。理由与实测（phase2 11.4h 仅 6/50、100 天≈6.8 CPU-h、全量≈335 CPU-h）写入 `docs/维护说明.md`。判据语义 check a/b/c 未改。
+- **成本探针**：新增只读 `--cost-probe [D1,D2,...]`（默认 1,5,10,20,50,100）。本机单 worker、npcs=30、seed=42 实测：1d 21.615s/19.0GB/gen0=2272，5d 111.645s/98.1GB/gen0=11728，10d 226.226s/202.4GB/gen0=24203（约 20.2GB/天·世界）。证据 `evidence/stream/cost-probe-1-5-10.log`。
+- **长局机理（只测不改）**：`World.Rumors` 永不裁剪，实测 count 1d=2025 / 5d=9821 / 10d=19493（≈1950/天），而 `latestRumorFor`/`rumorIsDuplicate`/`rumorPath` 每次全表扫描 → 单次交互成本随年龄线性、整轮超线性；`Mind.Memory` 有上限（恒 64）非主因。修复方向（裁剪工作集/Map 索引/限窗）留下一单，本单不实施。证据 `evidence/stream/growth-1-5-10.log`。
+- **待收口**：由 Hermes 独立复验本分支；正式 M3 重跑走冻结流程（50×20）。macOS 打包脚本事后单已排队（等本单交付）。
diff --git a/docs/维护说明.md b/docs/维护说明.md
index 4635b6d..19ca201 100644
--- a/docs/维护说明.md
+++ b/docs/维护说明.md
@@ -1,6 +1,6 @@
 # 维护说明
 
-结论先行：主分支保持 0 警告 0 错误 + Desktop 79/79、Kernel 79/79 全绿；性能基线
+结论先行：主分支保持 0 警告 0 错误 + Desktop 86/86、Kernel 79/79 全绿；性能基线
 final_digest 固定 953775FAEB2FDDE97289491AA260BD8D390C571E48A7A13AD2CB6FB7124F7F6C。
 本文记录模块职责、不变量与逐字可复制的验收命令。
 
@@ -83,6 +83,40 @@ dotnet src/LivingVillage.Headless/bin/Release/net8.0/LivingVillage.Headless.dll
 - digest 变化处理：先比对 `WorldSave.save world` 全文文本（版本头变化不构成失败即 digest 规范化后等价）；
   再查 Sim.step 数值路径是否被改动（不允许）。历史归属见 `artifacts/perf-independent/*/README.md`。
 
+## M3 批验：流式可观测性、门槛与长局成本（M3-1）
+
+- **流式输出**：`--batch K D` 每个世界一完成就立即打印 `world=... OK elapsed_s=<秒>` 与
+  `[done k/N] elapsed=…s world=…` 并 flush，结束时 `batch_summary` 旧字段原样保留并追加
+  `workers=` 与 `wall_s=`（总墙钟）。完成序可能非升序，监督器按索引集合恰为 0..K-1 校验。
+- **正式门槛缩尺 50×100 → 50×20**（`scripts/m3_supervise.py` 的 `PHASES.phase2`）：
+  phase2（50×100）实测 11.4 小时仅完成 6/50 世界，单世界 100 天约 6.8 CPU 小时，
+  全量约 335 CPU 小时，不可行（诊断见
+  `artifacts/m3-acceptance/final-candidate-20260921T095500Z/logs/phase2_20260921T101500.log.diagnosis.txt`）。
+  Hermes 实测单 worker 成本：1 天 25.6s / 5 天 123s / 10 天 254s / 20 天 ≈900s /
+  100 天 ≈6.8 CPU-h。缩尺只改规模，判据语义 check a/b/c 未动。
+- **成本探针**：`--cost-probe [D1,D2,...]`（默认 `1,5,10,20,50,100`）逐段真实测量单世界
+  `ticks_per_s`、墙钟、`allocated_bytes` 与 gen0/1/2，不估算、不写死。
+  本机（单 worker，npcs=30，seed=42）实测：
+
+  | days | elapsed_s | ticks_per_s | allocated_bytes | gen0 | gen1 | gen2 |
+  |---|---|---|---|---|---|---|
+  | 1 | 21.615 | 239837.5 | 19,001,478,648 | 2272 | 286 | 11 |
+  | 5 | 111.645 | 232165.0 | 98,066,613,520 | 11728 | 11 | 2 |
+  | 10 | 226.226 | 229151.8 | 202,369,225,952 | 24203 | 22 | 2 |
+
+  即约 **20.2 GB / 天·世界** 的分配；10 天内吞吐近乎平稳，超线性主要体现在更老的世界上
+  （Hermes 20 天 ≈45 s/天、100 天 ≈245 s/天）。
+- **成本随年龄上涨的机理（只测不改）**：`World.Rumors: RumorEvent list` 永不裁剪，
+  每次谣言扩散 `rumor :: world.Rumors` 前插。实测 `rumor_trace count`：1 天 2025、
+  5 天 9821、10 天 19493（≈1950/天线性累积）。而 `latestRumorFor` / `rumorIsDuplicate` /
+  `rumorPath` 每次都 `world.Rumors |> List.filter/tryFind` 全表扫描，因此每次聊天/对话的
+  成本随世界年龄线性增长、整轮成本随时长超线性（≈平方）增长；同时每次扫描与前插都产生
+  列表分配，推高 GC。`Mind.Memory` 有 `memoryCapacity` 上限（实测恒 64），不是主因。
+- **修复方向候选（本单不实施，避免动确定性语义）**：①按 `rumorFreshnessTicks`/半衰期
+  确定性裁剪工作集（谱系/annal 另存）；②以 `Map<RumorId, RumorEvent>` 或逐接收者索引替代
+  全表扫描；③把 `latestRumorFor`/`rumorIsDuplicate` 限制到最近窗口。以上都需单开一单、
+  重跑 performance-baseline 与全部 digest 后由 Hermes 走冻结流程。
+
 ## 已验证命令
 
 ```bash
@@ -96,6 +130,11 @@ dotnet build LivingVillage.sln -c Release 2>&1 | tail -n3
 dotnet test src/LivingVillage.Desktop.Tests -c Release --no-build
 dotnet test src/LivingVillage.Kernel.Tests -c Release --no-build
 
+# M3 批次（流式；判据行与原格式逐字节兼容，仅行尾追加 elapsed_s）
+LV_BATCH_WORKERS=4 dotnet src/LivingVillage.Headless/bin/Release/net8.0/LivingVillage.Headless.dll --batch 4 10
+# 长局成本阶梯（只读，真实测量）
+dotnet src/LivingVillage.Headless/bin/Release/net8.0/LivingVillage.Headless.dll --cost-probe 1,5,10
+
 # 素材再生成（确定性，输出 byte-identical）
 python3 scripts/make-jiangnan-art.py && python3 scripts/make-cc0-art.py