GR-Edge 事件处理链：从时间戳到质量状态

事件处理链至少面对三类输入：来自四个逻辑通道的合成采样、闸机时刻定义的观察窗口、描述人为实验场景的元数据。第一类是要计算的数值，第二类决定比较边界，第三类只用于解释生成器的前提。若把场景元数据作为算法识别结果，就破坏了处理链最基本的可审计性。

实际模块位于/gaterestart/web/event-analysis-v3.mjs，依赖V3数据包的CSV、cases与data-manifest。它能装载、选窗、构造曲线、分析和导出；这属于actual_software，不等于GR-Edge硬件已经上车道完成在线采集，更不等于设备能诊断汽车机械故障。

浏览器应先以fetch分别取得synthetic_events_v3.csv、cases_v3.json及data-manifest.json，再调用loadDataset({csvText,casesText,manifestText})。这一步依据manifest的哈希和字段关系核对数据，不允许通过旧V2.1的CSV或不同版本的报告混装成同一批输入。

版本边界必须体现在公共路径：V3有12案，每案-1.5到4.5秒共601点；旧V2.1仅5案、0到3秒、单位nT，两组文件及URL必须长期隔离。若混用，将导致时间窗口、单位和场景ID同时失真，是明确的工程错误而非小幅展示偏差。

exportSelectionCSV应保留窗口内的数据值、质量列、单位及合成标识；exportReportJSON应完整保留计算特征、状态、原因、来源哈希与不能推出的事实。固定的SIM-xx.json报告来自V3数据集的实际导出，不应由文章编辑器或前端另写一套规则生成。

完整分析证据链为“输入SHA256→选择窗口→模块版本→计算结果→质量判定→导出”。文件及源码存在可复核，正式浏览器导入、在线下载与实时传感器接入则各需独立运行证据，不能互相推定。

回归测试建议覆盖边界样本与异常请求：选择跨出数据范围的窗口、只请求reference通道、切到SIM-09的截顶区、切到SIM-12的失联区，分别比较绘图与报告结果。成功标准不仅是程序不抛错，更要确保质量标记没有在转换中消失，导出结果可反查到相同输入文件和选择条件。

GR-Edge处理流程当前证据是Node/浏览器软件及生成报告，而非工业现场系统认证。任何真实传感器接入都需要新增带宽、时钟、接口、失步、供电和数据完整性验收；软件架构具备处理字段不意味着相应硬件能力已经存在。

部署验收仍需检查三个fetch资源、ES module的MIME、各SIM报告和SVG的HTTP响应，以及旧版路径是否保留。只有这些验证真正完成后，页面才可以把“软件可离线复核”升级成“公网可使用”；在此之前不得写真实上线时间。