docs: M6a 谣言容量上界实施与 1/10/20 天成本复测记录

1 files changed, 27 insertions, 0 deletions

diff --git a/docs/维护说明.md b/docs/维护说明.md
index 19ca201..0761aef 100644
--- a/docs/维护说明.md
+++ b/docs/维护说明.md
@@ -117,6 +117,33 @@ dotnet src/LivingVillage.Headless/bin/Release/net8.0/LivingVillage.Headless.dll
   全表扫描；③把 `latestRumorFor`/`rumorIsDuplicate` 限制到最近窗口。以上都需单开一单、
   重跑 performance-baseline 与全部 digest 后由 Hermes 走冻结流程。
 
+## M6a 批验：谣言工作集容量上界与按天淘汰
+
+- 实施 M3 的三条修复方向：
+  ①`RumorEvent` 新增派生字段 `DayIndex = Tick / ticksPerDay`，不参与存档序列化，读档由 `Tick` 纯函数
+  重建，故 v1/v2/v3 存档文本逐字节不变；
+  ②新增可变参数 `rumorCapacity`（默认 16384）与 `rumorRetentionDays`（默认 3，>= 新鲜窗口 3 天），
+  纯函数 `trimRumors` 只保留最新 N 条并丢弃早于 `nowDay - rumorRetentionDays` 的条目；容量内且新鲜时
+  零拷贝原样返回；两个前插点 `chooseDialogue`/`chat` 统一走 `consRumor`；
+  ③列表最新在前，`latestRumorFor`/`rumorIsDuplicate` 改早停递归（越窗即停、无中间列表），
+  `nextRumorId` 改读表头 O(1)。
+- 等价性：保留窗口（>= 3 天）覆盖两个查询的新鲜判定，窗口外条目本就会因 `rumorStrengthAt <
+  rumorMinimumStrength` 被过滤，故裁剪不改变任何查询结果；「表头为最大 Id」不变量在裁剪后保持。
+- 实测（本机单 worker，npcs=30，seed=42，`--cost-probe`；同机 M3 未裁剪基线见上节）：
+
+  | days | 未裁剪 elapsed_s | M6a elapsed_s | 未裁剪 allocated_bytes | M6a allocated_bytes |
+  |---|---|---|---|---|
+  | 1 | 23.4（×3） | 23.4（×3） | 19,001,341,888 | 18,898,357,944 |
+  | 10 | 240.6 / 268.6 | 236.2 / 274.0 | 202,373,638,848 | 191,916,294,064 |
+  | 20 | ≈900（M3 记录） | 503.1 | — | 384,468,393,040 |
+
+  10 天分配/gen0 稳定下降约 5%；超线性项改善更大：M3 记录 20 天 ≈45 s/天，M6a 后 20 天 ≈25 s/天
+  （≈1.8×），单日成本回归平稳。
+- 工作集实测（`evidence/` 探针，seed=42，npcs=30）：第 5 天 `Rumors` 7796（收敛）vs 未裁剪 9821，
+  两者表头 `Id` 同为 9820，证明创建序列不变、仅淘汰已不可用的旧条目。
+- 门槛：`final_digest=953775FAEB2FDDE97289491AA260BD8D390C571E48A7A13AD2CB6FB7124F7F6C` 三次一致，
+  `performance_determinism=PASS`；Kernel 89 / Desktop 94 全绿。
+
 ## 已验证命令
 
 ```bash