本页不新建任何规则。判定用的限额全部来自已有配置： 计量表的「小时下限 / 小时上限」、 点位的「上限 / 下限」（另配了更严的 「更高上限 / 更低下限」时按更严的那一档算）、以及 「能效对标」里录入的标准值。要改限额去「设备管理」或「能效对标」改，本页只读它们 —— 所以这里的每一行都能追回一个配置项，追不到配置的告警不该存在。
闭环分三段，中间那段只写一次。新告警是「未确认」；确认后变 「已确认」，确认记录只写一次（确认人 / 确认时间 / 备注）， 后续评估刷新这条告警时不会覆盖确认人 —— 两个人先后点确认，责任链不会因此断掉。 再之后是「已消除」：自动消除，判据是"本轮评估的时间窗覆盖到了它、 却没再见到它"（限额恢复，或数据不再超限）。已消除的告警不会因为同一小时再次超限而"复活"： 那一小时的告警记录已经存在，后续评估只会继续刷新它的实测值与"最近见到"时间， 状态停在已消除，既不会变回未确认，也不会另出一条新的 —— 下一小时是另一条记录，那才是新的一条。所以一行"已消除"配上一个更晚的 "最近见到"时，本页会把它标成「消除后又被见到」，由人去判断它是否仍在超限。
没有配限值 ≠ 达标。这是本页最容易读错的一句话：能效标准值没有录入时， "能效标准限值"这一路一条都不会产生， 清单是空的 —— 而空清单在这里只意味着无从判定，不意味着达标。同理， 计量表没配逐时限额、点位没配上下限时，它们那一路也不会产生任何告警。所以评估结果里把每一路 "配了限额的对象数 / 扫到的行数 / 命中的条数"分列出来，服务端给了说明就原样显示 —— 「没配限额」「没扫到数据」「扫了但没有超限」是三件不同的事，本页不把它们显示成同一个 0。
判定读的是真实采集数据。计量表读它的逐时用量， 点位读各自的历史读数。 被标记为坏读数的那些不参与判定：一条坏读数不该变成一条告警， 也不该让人对着一条明显越界的数据去翻日志找"为什么没告警" —— 被跳过的坏读数条数会写在评估结果里。
"没配限额"与"超限"是两件事，两个方向都不能混。点位的上限档填 0 时按未配置处理（0 是默认值，当成限值会让每条正读数都超限）； 上限档留空同理。反过来，没配限额也不等于达标 —— 能效标准值没录入时，那一路是"未配限值"，不是"一切正常"。
累计量（表底读数）点位的上限档不适用。表底读数只增不减， 上限越过一次就永远超限 —— 那不是一次事件，是一处需要复核的配置。 这类点位仍然判下限档（负的表底读数是真故障），而累计电量该由计量表的逐时限额来判 （"计量表小时限额"那一路）。被这样跳过的点位列在评估结果的 「被跳过上限的点位」清单里，不会静默消失。
同一件超限在每次评估里都是同一条（计量表按"表 + 规则 + 小时"， 点位按"点 + 规则 + 到秒的时间"，强度按"指标 + 空间 + 日期窗口"）， 所以重复评估不会产生重复告警，只会把那一行刷新一次。反过来，小时级的告警在下一小时是 另一条 —— 那不是重复，是另一小时的超限。
本页的写动作（评估、确认）都要求预警的写权限：只有只读权限 的账号能看清单、计数与闭环状态，但按钮是禁用的。

参数分四种类型，由服务端按默认值的类型判定并随接口下发 kind： bool（开/关）、features（一组功能键，值是数组）、 以及两种数值型 number（整数，秒或天）与 days（天数清单，逗号分隔）。 界面按 kind 分别渲染，不复用同一套控件 —— 功能模板的值是逗号分隔的字符串， 用"非空即真"去判会把"一个都不开"显示成"已开启"； 到期评估周期 0 秒是"不自动跑"，按真假判会显示成"已关闭"， 两句话说的不是同一件事。
每个开关都显示当前值 vs 默认值：「恢复默认」写回代码里的默认值 （功能模板的默认值取自服务端的功能清单，不是抄一份在前端）。
开关的默认值写在服务端代码里（PLATFORM_GATE_SETTINGS），库里只存"偏离默认的覆写"， 所以恢复默认 = 删掉那条覆写，而不是把默认值当成一次修改写进去。
关闭「开放企业自助注册」后，登录页的注册入口与 POST /api/register 会一起关掉 —— 只藏按钮不挡接口等于没关。
「企业注册后默认开放的功能」是给新企业的模板：改它不影响已在用的企业， 那些企业各自的功能集在「企业管理」里逐家看、逐家改。
到期策略的那几项（是否自动降级、评估周期、提前提醒天数、兜底宽限天数）改的是 "到期评估什么时候跑、跑的时候做到哪一步"：默认不自动降级， 于是宽限期结束后系统只把这几家企业列在评估结果的"宽限外未降级"里， 功能一个键都不变，等平台处理。打开自动降级等于允许系统在宽限期结束后收回客户模块 —— 这是会改变客户功能面的动作，请确认有人值守时再开。 无论开关是开是关，在「套餐订阅」页点「跑一轮」都会执行到降级那一步。

清单来自服务端唯一事实来源 features.describe()（GET /api/platform/features 的 features 字段）， 前端不写死任何功能键 —— 写死之后，服务端新增一个模块，这一页就永远看不到它，而且不会有任何报错。
每一项的「覆盖的接口前缀」决定「关掉它到底关掉了什么」：服务端按最长前缀优先匹配， 所以 /api/overview/collect 归「测试设备」而不是「总览与综合报表」。 前缀为空的模块只能挡住菜单、挡不住接口 —— 那属于服务端清单的配置问题，这里如实显示，不替它补。
停用与未开通在外面的表现是一样的（菜单消失 + 403 FEATURE_DISABLED），区别在「谁能恢复」： 平台停用在本页把勾选框勾回来即可；企业没开通要去「企业管理」给那家企业勾上模块； 企业开通了却没轮到某个人，由企业管理员在「模块授权」里勾。所以遇到这条 403 时， 先看企业侧的「企业信息 → 我的模块授权」那处自我排查。
本页的写操作都进审计留痕（feature.configure）。

可改的只有显示名、同级排序、是否在导航里显示这三样，它们只影响呈现，不影响接口权限； 菜单键、所需权限、归属、所属功能由代码定义（menus.py），本页只读展示。 这条边界是刻意的：菜单「有哪些、要什么权限」一旦可以改数据就改， 就会出现改一行数据悄悄多出一个入口 —— 而那类问题最难在测试里被发现。
隐藏只让导航里少一个入口：接口的权限判定完全不受影响，隐藏之后直接调那条接口仍然照常返回。 「功能正常、入口没了」因此是一种真实存在的状态，本页的「覆盖状态」列就是用来一眼看出谁被隐藏的。
「恢复默认」删掉的是那条覆盖，不是菜单本身：删掉之后，这条菜单的显示名、排序、 显示状态完全跟随代码定义（改过名字的也会回到代码里的名字）。
写接口里的 null 表示「清除这一项的覆盖」，所以把显示名输入框清空再保存 = 回到代码里的名字， 而不是写一个空名字（空名字会变成导航栏上一条看不见的菜单）。
本页的写操作都进审计留痕（menu.configure / menu.reset）。 「菜单配置」自身不允许被隐藏 —— 它是所有隐藏操作的撤销入口，藏掉之后就没有界面能把它改回来。
登录页入口（企业注册）不在这张清单里：它的显示与否由平台开关 registration.open 控制， 再叠一层「隐藏」会让同一个入口有两个互相打架的控制器。