weather scheduler proposal D-prime / rolling materialization

方案 D′ · 有界视界滚动物化物化即真值，落盘 + 离线定时器

在登录 / 访客 / 种植 / 用瓶 / Timer 五类触发点，把 [now, now+24h]（maxGrow 上界已坐实）的自然雨窗 生成一次并落盘；读天气 = 扫已物化窗口列表；到点事件与水位线前滚由 timersvr 离线定时器（BotTick 范式）驱动。 窗口生成用普通 RNG——结果落盘后即真值，无需跨 Pod 可复算，这是与 E 的本质分野。

加权评分（要实时徽标情景）3.43 加权评分（cache-on-visit 情景）3.88 落盘 item_rains + materialized[] + 水位线 + timer 簿记 timer 依赖 TaskTypeWeatherTick（新增） 配置 first 10-20m · next 30-60m · duration 20m · buffer 10-15m
SERVER TIMEDay0 00:00:00
01

排布如何生成 · 五触发点 + 水位线

生成用普通 RNG（演示用固定种子便于复现）；物化后不可复算、只可读取

ensureMaterialized（09 §3 对齐）

horizon = now + 24h            // maxGrow=24.00h 已坐实（05 §16.3）
if 水位线 materialized_until ≥ horizon: return   // 命中，零写
rollWindows(尾部 → horizon)   // 普通 RNG，逐日 0 点锚定 + 链式
append → WeatherState.materialized  // markDirty → 3 阶段 Save
GC 过期窗（end < now-24h）
renewTimer(下一窗口边界, seq++)     // AddTaskAsync（fire-and-forget）

触发点 = 登录、好友访问、种植、用瓶、timer 到点。任一漏挂即水位线停摆 → 读到「未物化」。 从不登录玩家在被第一次触达（如好友来访）之前，整条时间线不存在。

三位玩家的 WeatherState（实时）


    

  







  
02
三类玩家 · 三天物化时间轴

    琥珀竖线 = 水位线 materialized_until · 斜纹 = 未物化（读不到答案）

  

    

    

      已物化自然雨（落盘）
      道具雨（item_rains）
      被顺延重排的物化窗（列表被改写）
      新配置代际物化的窗（05 节热更后）
      回溯段（首触时补生成，此前无人可观测）
      未物化区（水位线之外）
    

    

  







  
03
timersvr 工况 · 离线驱动与断链自愈

    每个窗口边界一次回调（RainStart/End + 前滚 + 续约）· timer_seq 防孤儿（bot 范式）

  

    

      

      

        
      

      
勾选顶栏「模拟乙的 timer 断链」：乙的水位线停止前滚，越过水位线后乙的天气变为未物化——
        好友看到停摆数据，直到登录/被访问自愈。对照：timer.md §15.5，AddTaskAsync 失败仅打日志，自愈必须业务自带。

    

    

      
— timer / 事件日志 —

      
本配置约 23 场/天 → 每玩家每天约 46 次边界回调 + 续约；乘以「活动内登录过的玩家数」即 timersvr 的持续负载（开放问题 D-Q1：全量 / dormant 阈值 / D′-lite 三档未拍）。

    

  







  
04
道具雨干扰 · 已物化列表的顺延重排

    互斥：当前有雨不可用瓶 · 顺延 = 显式改写落盘列表

  

    

      

        
        
      

      
— 操作日志 —

      

    

    

      
与 E 的对照

      
E：顺延不写任何东西，读时重放自动级联。

      D′：顺延 = 把未来已物化窗逐个改写再落盘（本演示实现「级联平移、保留原间隔与原窗时长（快照）」）。
      被顺延窗口带金色描边。级联粒度 / 是否重 roll / 跨午夜是否 snap 回次日锚——语义未拍（开放问题 D-Q3）；
      改写逻辑一旦有 bug，坏数据会持久化（E 的重放坏了改代码即愈，D′ 的坏窗口要修数据）。

    

  







  
05
配置热更干扰 · 半物化边界与对齐（D-Q3②）

    已物化 = 快照，天然免疫回溯；代价 = 生效边界是 per-player 水位线（错峰）

  

    

      
      
      
      
      
      
    

    

      生效策略：
      
      
    

    

      
      
      
    

    

      
上下游影响面板（对照 02 节泳道的混合色窗）

        

      

        
— 配置变更日志 —

        
D′ 的处理协议：①物化即快照——已落盘窗（含道具雨时长与已写入的顺延结果）天然免疫热更回溯，这是 D′ 在此风险上的结构优势（E 要靠"版本按日选取"纪律达成同效）。
        ②代价 = 新配置从各玩家水位线外开始生效：边界错峰、玩家间不公平、混合期最长 24h；timer 断链者永远停在旧配置（03 节勾选断链叠加观察）。
        ③「翌日 0 点重物化对齐」可消除错峰（对齐 E 的 §14 天界语义），但引入"丢弃未来已物化窗重生成"的改写机制——窗口身份更换，每场限采的去重键随之失配，须与采集瓶场次键联动设计。
        ④重物化 / 强刷必须联动 gate-only 重算，否则窗新门旧（勾掉联动看后果）；已揭示相位锁定不回滚。
        ⑤GM 强刷禁止截断进行中窗口（去掉保护勾选看事故：现场雨消失 + 身份更换 → 双采/漏采，R-D5 二次事故）。

      

    

  







  
06
好友列表 ·「雷雨中」徽标（cache-on-visit）

    列表渲染不可能 N 好友 N 次 actor load → 徽标只能用上次进农场时的缓存

  

    

    

    
「真值」列是仿真上帝视角，用于暴露缓存陈旧度；真实系统里观察者拿不到它。
      从不登录的丙在被首次访问前徽标恒为「无数据」；访问丙会在读路径上触发 ensureMaterialized→markDirty 落盘——
      与 05 §15.2 否决 DeferCheckpoint 的「读触发写」判据正面冲突（开放问题 D-Q2）。

  







  
07
作物与闪电变异 · eager 烘焙（读物化窗）+ 施肥移轴

    集成模型 = eager（05 §16.9 已锁）：与 E 页完全同构，唯一差异是门的数据源

  

    

      
      
      
      
      
      
    

    
    
尚未种植。选一种成熟时长（4/8/12/24h），把时间调到某场已物化雨前再种；观察四个跨阶段判定点是否落进物化雨窗，再试施肥把判定点整体前移。

  







  
08
双方如何拿到同一份排布 · 数据流

    真值 = 落盘物化态（单写者，owner actor 锁内）

  

    

      
观 察 者 Pod（好友列表）

      
friend.SyncAll 批量拉好友
        锁外查 info（Redis 镜像）· 镜像里没有天气字段

      
│ 徽标无法逐好友现算（要读各 owner 物化态）

      
徽标 = 上次进农场时缓存的快照
        cache-on-visit · 有陈旧度 · 从不登录好友无数据

      
└ 或未验证的混合：timer 边界推 info 镜像（仅覆盖 timer 链存活者）

    

    

      
owner Actor（自己 / 被访问）

      
登录 / 种植 / 用瓶（InvokeLock 内）
        ensureMaterialized → 读物化窗 → 烘焙 Phases[].Mutants

      
好友进农场：visit/plant SS → owner actor
        ensureMaterialized（可能写！）→ 读物化窗 → 精确天气 + 作物纯投影

      
timer 回调（interceptor→actorLoad→InvokeLock）
        校验 timer_seq → 发 RainStart/End → 前滚水位线 → 续约

    

    

      
存 储 / 基础设施

      
Tcaplus player 记录
        WeatherState{ item_rains, materialized[], materialized_until, timer_seq/active }

      
timersvr
        TaskTypeWeatherTick（timer/const.go 追加）· 每窗口边界一次 · AddTaskAsync 失败仅日志

      
配置（Bottle）
        新配置只影响此后物化的窗；已物化历史天然免疫（边界=per-player 水位线，见 D-Q3；05 节可交互热更）

    

  







  
09
BOT 伙伴参与天气排布 · 物化存哪？（BOT-Q2）

    伙伴不是 actor：无独立 Model 可放 materialized[] + watermark —— 三条路各有代价

  

    

      
存储位三选一 + 规模（伙伴数据内嵌 owner 玩家 Model · bot/entity.proto）

      

        
        
        
        
        
      

      

        
        
      

    

    

    

    
成本与风险账（随上方选项联动 · 详见 10_DE_REEVAL §10）

      

  







  
10
三优三劣 与 三个开放问题

  

    

      
优点
    
        
  1. 与 plant 现有 eager 架构同构：种植时物化 24h 视界即可烘焙全生命周期（maxGrow=24.00h、相位无前向漂移已坐实）；「物化 + 单写者」与 plant「种植预定 + 纯投影」是同一设计语言，团队心智成本最低。
    2. 
        
  2. 无冻结契约、变更友好：物化即真值，算法/RNG/config 可随版本演进；已发生窗口落盘不可撕裂；多类型 = 列表里多掺几种窗，无 K 路归并与饥饿建模税。
    3. 
        
  3. 天然事件发射点：timer 到点发 RainStart/End（含离线玩家）——统计、推送、tlog 直接挂；BotTick 防孤儿范式现成可抄。
    4. 
      

      
缺点
    
        
  1. 好友列表徽标结构性缺失：从不登录好友物化态恒空、长期离线好友水位线过期，列表只能 cache-on-visit（或未验证的镜像推送混合），实时 pre-visit 徽标做不到。
    2. 
        
  2. timer 生命周期与写放大：每玩家每天约 46 次边界回调+续约；AddTaskAsync 失败仅日志、断链靠登录/访问自愈；水位线前滚周期性 markDirty；访客触发物化 = 读路径写 owner（反模式判据冲突）。
    3. 
        
  3. 物化态一致性 = 五触发点全对：登录/访客/种植/用瓶/config 任一漏挂即 stale（gate 烘焙吃到过期窗）；顺延是对落盘列表的显式改写，写坏即持久化坏数据。
    4. 
      

    

    
就方案 D′ 还需要拍板的三个问题（详见 10_DE_REEVAL.md §4）

      
    
        
  1. D-Q1 timer 三档选型与预算：全量链式（46 回调/人/天 × 登录过玩家数，timersvr QPS/任务存量预算？）/ dormant 阈值（事件与离线统计打折）/ D′-lite（无 timer，纯触发点物化）——选哪档？可观测优势只在第一档全额成立。
    2. 
        
  2. D-Q2 访客触发物化 = 读触发写：与 05 §15.2 否决 DeferCheckpoint 的判据冲突。豁免，还是访客只读？只读则从不登录好友农场的天气只能现算不落盘（E 逻辑复活、两套真值源）或恒晴（体验不可接受）。
    3. 
        
  3. D-Q3 顺延级联与 config 半物化边界：①重排只平移紧邻一场还是链式全平移？保留原间隔还是重 roll？②config 变更生效边界是 per-player 随机水位线（不齐天界、玩家间不公平），要不要强制翌日 0 点重物化对齐天界（E 在 §14 已定天界语义，D′ 对应物缺失）？
    4. 
      

  






  b-weather-rain-statemachine-260624 · weather-demo-Dprime.html · 2026-07-02 · 机制与 09 §3、05 §16 逐条对齐，配置热更对照 05 §14（演示级简化：日界用整 86400；RNG 用固定种子 mulberry32 便于复现——真实实现可用任意 RNG，落盘即真值）