StartLux 344与Jev 686：同一Native机制，审核输入和模型判断不同
代码和实跑配置核对
当前15条归档中的executor.jar均为c08fdb34321c760112383b9afc2c11360d35f01120259492ea25d39fb95ea370，匹配各自config.snapshot.json中的artifacts.jar；单独的bridge文件native-entry.jar均为782cbfcb9dadd1a9f0a428b517458772d4b315d7b6044931f491f6cedec7c630，匹配artifacts.bridge。这两个文件用途和SHA不同，但各自在15条Run间完全一致。逐文件原始SHA；配置与归档逐项校验。冻结source blob 9a50958d…与构建收据对应Fix A+B执行JAR；归档中的191个Native源文件与当前源码逐字节一致。源完整性；构建收据。本次没有重建或替换实验JAR。
每App的两模型properties恰有7项不同：endpoint、model、provider、servedModel（Jev侧）、outputRoot、platform.config_sha、platform.run_id。候选门槛、超时、历史选择、预算、Probe等非Provider规则相同。35项逐项配置差。servedModel/provider属于身份/接入差异，不能说两配置字节相同。
核对的是冻结Native及请求/响应；本地services/startlux/startlux_decision/jevfmt.py与冻结source版本不同，属于既有用户修改，没有拿当前dirty文件冒充实跑服务渲染器。没有重新调用在线Provider，也没有服务端部署代码全量快照足以证明两Provider内部处理相同；两Provider内部实现本来就不属于“同一Native机制”的结论范围。
| 阶段 | 同一实现及具体位置（均为冻结源码） | 身份/运行差异 |
|---|---|---|
| 审核入口与轻量门槛 | JevSemanticReview.java182–220、342–352：合法启用且需target的ModelAction，fresh round至少3个resolved concrete；pending Probe保留 | 当前GUI、已执行历史、pending状态不同会返回NO_BUILD |
| 候选及Witness | 同文件collectCandidates及615–723 buildPage；同ModelAction confirmedHistory、recoverable witness、Top3历史及相同本地过滤 | 不同State、具体成员、历史执行/版本导致Pair数量不同；前置逐个过滤原因并非全量记录 |
| 聚合 | JevHistoryPairwiseProtocol.java119–178：trusted SAME优先REPRESENTED；否则任意trusted DIFFERENT可PROMOTE；否则UNRESOLVED，阈值confidence>0.5 | 模型返回choice/confidence不同，改变之后的Ledger和轨迹；不把INSUFFICIENT硬改成DIFFERENT |
| 页面/Pair/指纹缓存 | JevSemanticReview236–273；Protocol181–198 pairFingerprint | 模型、contract、endpoint、State/version、page/provenance在键中；Ledger run-local，不跨模型复用同一答案。不能称缓存键字节相同 |
| 请求和回执 | JevSemanticReview278–315、514–599、775–884；JevTransport.javaCall.consume原子仅消费一次 | 同步等待与异步arrival归档并存；缓存也可合成一条响应并被消费，不能把arrival/consume再数成HTTP |
| Probe持久化、绑定、导航和确认 | JevReviewLedger.java、JevRegistry.java、JevSemanticReview.java | Provider身份通过相同contract规则隔离；没有StartLux专用候选或Jev专用执行策略分支 |
request body中model字符串不同也会改变指纹和少量字节；不能说“除返回外其他字节完全相同”。离线交换model的检查只证明已保存请求没跨32KB限额，没有重放未保存的完整历史/原始超大页面，不能拿它证明所有反事实候选发现也一样。
先把不同计数器分开
每Run的provider-review-funnel.csv和reviews.csv保留原事件引用；完整汇总见provider-funnel-summary.csv。这里HTTP按实际保存的semantic-request收据、原始send事件及独立response收据对齐，不从单一“reply”事件估算。
入口不等于构造：NO_BUILD可能是无工作、复用已有pending、页面已缓存等轻量返回。HISTORY_PAIRWISE_COST构造可能候选非空、Pair为0；只有选中可比较Witness的Pair才会进入有效请求。构造事件、候选观察次数、Pair比较次数彼此也不是同一分母。
| App | SL审核入口 | Jev审核入口 | SL HTTP | Jev HTTP | SL缓存合成回复 | Jev缓存合成回复 | SL消费 | Jev消费 |
|---|---|---|---|---|---|---|---|---|
| ODK | 1967 | 1998 | 7 | 20 | 0 | 0 | 7 | 20 |
| Wikipedia | 319 | 290 | 26 | 25 | 2 | 2 | 28 | 27 |
| Scarlet | 1534 | 779 | 74 | 318 | 2 | 15 | 76 | 333 |
| Omni | 1041 | 1125 | 97 | 80 | 11 | 28 | 108 | 108 |
| ActivityDiary | 742 | 663 | 140 | 243 | 5 | 3 | 145 | 246 |
| 合计 | 5603 | 4855 | 344 | 686 | 20 | 48 | 364 | 734 |
这里的消费364/734大于HTTP344/686，差值正好是20/48条缓存合成响应，不是发生了那么多额外模型请求或重复收费。真实网络回复344/686与HTTP对应；异步arrival归档同样是一份请求的另一个生命周期阶段，不能相加。
本轮10条模型Run的JEV_REQUEST_FAILED均为0，HTTP逻辑请求ID/send/收据逐项一致，冻结聚合无误。部分attempt>1并非失败重试：nextAttempt（JevSemanticReview932）对同input fingerprint累计，response的retry_count=attempt-1因此不能直接累加成网络错误重试数。按实际失败事件与重复ID审计没有失败重发的证据；相同指纹后来再次发出，是重复审核需求，不自动视为传输重试。每Run重复指纹和attempt统计仍保留。
Scarlet为何入口更少，HTTP却更多
| 入口分层 | SL | Jev |
|---|---|---|
| NO_BUILD_NO_HTTP | 1275 | 402 |
| BUILD_NO_HTTP | 183 | 44 |
| HTTP | 74 | 318 |
| PAIR_CACHE_NO_HTTP | 2 | 15 |
| 合计审核入口 | 1534 | 779 |
| 构造事件（后三行） | 259 | 377 |
| 构造候选观察数 | 589 | 1040 |
| 构造Pair数（含缓存） | 505 | 2489 |
进一步分层：SL183次BUILD_NO_HTTP共378候选、0 Pair；74个HTTP入口对应的构造页共207候选/493 Pair；2个缓存入口4候选/12 Pair。Jev44次BUILD_NO_HTTP共114候选、0 Pair；318个HTTP入口构造页共892候选/2434 Pair；15缓存入口34候选/55 Pair。这些是HISTORY_PAIRWISE_COST构造页的计数，不是最终HTTP body。 pending/指纹过滤和闭包预算处理之后，真实网络body合计为SL164候选/404 Pair、Jev570候选/1540 Pair，与响应聚合、答案数量对应。
两组还都真实使用两种保存的Evidence view：Scarlet SL的74请求中candidate-closure-v1为31、incremental-candidate-closure-v2为43；Jev318请求中分别239/79。这些是同一Native预算/增量闭包实现的不同运行分支，不是按Provider换一套策略；源码见JevSemanticReview的roundPage、submitProjected（422起）及JevPairwiseEvidenceView。不能把“同一机制”偷换成“每个请求都恰好使用同一View和同样Pair数”。全部实际wire统计
因此主要差异在缓存前已经存在：SL入口多却大多不构造，构造中又常没有可比较Witness；Jev构造更多，非零Pair更多。不能把HTTP倍差单独归因于缓存更好或更差。
运行场景也确实不同：provider-review-scenes.csv保存version/State/Activity和当步选择。SL大量入口在Main g1s1及搜索g40s123，Jev更多出现在编辑g8s19、g22s58、g16s42；这些ID仅在本Run内有意义，不能跨Run当作同一页面的共同ID。对应GUI/具体控件可通过reviews.csv的原事件行与actions.csv的输入快照追溯。各Run分层构造汇总
模型返回又会继续影响轨迹：Scarlet网络候选聚合SL REP119/UNRES41/PROM4，Jev408/145/17；Pair答案SL SAME329/DIFFERENT75，Jev SAME1202/DIFFERENT198/INSUFFICIENT140。后者较多审核和Probe，不等于发现了较多独立功能；Scarlet实际功能解释中主要提醒收益来自普通APE，额外块菜单等多是重复模板。
Scarlet平均HTTP延迟SL1.481秒、Jev4.005秒，Native步分别2221与1641。模型接入的延迟、判断、后续历史和GUI异步时序共同影响60分钟内轨迹；不能仅凭步数差反算“每个额外Probe损失了多少覆盖”，也不能把请求次数直接解释成能力强弱。
0 Pair只证明这次构造没有选中可比较历史Pair，不能再猜它究竟由于哪些逐项过滤丢失，因为该层没有全量逐候选排除日志。现有冻结wire也不是完整的Native状态/历史执行快照，故没有伪造“同一Evidence全链重放后候选发现完全相同”的结果。
真实Native离线回放范围与结果
GUITabooWireReplay.java调用真实JevHistoryPairwiseProtocol.request/fromProvider，恢复保存的State、questions、Pair绑定、history coverage、provenance；用保存答案聚合，没有HTTP发送，也没有再次询问模型。
- 1030份请求原body字面SHA全部匹配；请求结构及字节长度全部一致。
- 检查1974个保存候选决策，聚合不一致0。
- 交换model后保存State/questions不变；1030份已保存请求中因交换model超过32768字节的0。
- 宿主Android JSONObject可能重排key，重序列化SHA不相同单列为宿主差异；不是将该差异隐藏成成功，原body字面SHA另行验证。
1030条逐请求结果、编译classpath及SHA、请求体大小。回放边界是保存wire构造与答案聚合；没有恢复全部历史图，没有重新调用两Provider，也没有证明Provider内部token渲染一致。
结论：这轮是相同Native GUITaboo实现及非Provider规则，加不同Provider/模型判断与运行轨迹。缓存的身份隔离是真实机制差异的参数表现，候选和执行策略没有按Provider分叉。请求倍差可直接追溯到审核入口→候选/Pair→缓存/HTTP漏斗及不同页面历史；剩余未记录的前置过滤细节不能再细分。