WaitingForPower

WaitingForPower —能源项目追踪器

开源，采用 MIT 许可证 — 详见 LICENSE。欢迎贡献、 复刻和提交问题。

追踪美国拟建能源项目 — 发电、输电、储能、LNG 和管道，涵盖所有燃料类型 — 以及每个项目已等待审批的时间和原因。

**这一论点着眼于结构，而非党派立场：**太阳能、风能、储能、天然气、 核能、水力发电、LNG、管道和输电项目都会卡在同一小部分瓶颈上。每项已追踪的延误都归入七个明确命名的原因类别之一 (src/lib/data/causeCategories.ts)。 本网站的政策主张 — 六项具体的两党改革提案，每项对应一个结构性瓶颈，并说明问题、提案、优势、 劣势及法案链接 — 集中在单个页面 /policies (src/lib/data/policies.ts)，并特意与中立的原因类别数据分开，以免“项目为何受阻”和“我们主张应做哪些改变”成为同一对象。

快速开始

npm install
cp .env.example .env      # set DATABASE_URL to your own Postgres instance
npx prisma migrate deploy # applies the committed migrations to your database
npm run ingest:permitting-dashboard  # populate from a live, no-key-needed source
npm run dev

需要在 DATABASE_URL 中提供有效的 Postgres 连接字符串 — 项目不附带本地数据库文件。部署的应用和本地开发环境都指向本项目使用的同一个托管 Postgres 实例（原因见下文“架构”）；如果你要创建自己的复刻，任何 Postgres 都可以（Neon、Supabase、Vercel/Prisma Postgres、RDS、通过 Docker 运行的本地 postgres 等）。

数据与来源

**所有项目数据都来自实时、可重复运行的数据源 — 不依赖人工挑选的临时研究。**本项目的早期版本曾附带一小组人工调研的数据；后来特意将其移除，改用能自行保持最新的数据源，避免数据快照逐渐过时。 每个数据源的完整表格、待解决问题及其调度方式，详见 src/lib/ingest/README.md：

来源	模块	检查方式	来源自身的发布频率
EIA-860M“计划中”发电机组清单	src/lib/ingest/eia860mPlanned.ts	每周 Cron（周日 13:00 UTC），/api/cron/ingest-eia	每月，EIA 方面约有 2 个月延迟
联邦许可仪表板（FAST-41）	src/lib/ingest/permittingDashboard.ts	每日 Cron（14:00 UTC），/api/cron/ingest-permitting-dashboard	实时 API——没有定期文件，实际为实时数据
LBNL Queued Up	src/lib/ingest/lbnlQueuedUp.ts	每周 Cron（周日 15:00 UTC），/api/cron/ingest-lbnl	约每年一次
ORNL HydroSource 水电项目许可续期	src/lib/ingest/ornlHydropowerRelicensing.ts	每周 Cron（周日 16:00 UTC），/api/cron/ingest-ornl-hydro	约每年一次
EIA 天然气管道项目追踪器	src/lib/ingest/eiaPipelineProjects.ts	每周 Cron（周日 17:00 UTC），/api/cron/ingest-eia-pipelines	约每季度一次
Virginia SCC CPCN 案卷	src/lib/ingest/vaSccDockets.ts	每日 Cron（18:00 UTC），/api/cron/ingest-va-scc。这是计划中按州扩展系列的首个来源，覆盖州 PUC/PSC 案卷，也就是本网站其他来源无法看到的结构性瓶颈（参见未解决问题 #10）。	实时 API，但目前只有一个州
Texas PUCT CCN 案卷	src/lib/ingest/txPuctDockets.ts	每日 Cron（18:30 UTC），/api/cron/ingest-tx-puct。系列中的第二个州——案件量高于 Virginia，但没有结构化状态字段，因此根据提交历史推断“仍在等待”（如何校准请参阅文件头部）。	服务端渲染的 HTML，无需身份验证
Colorado PUC CPCN 案卷	src/lib/ingest/coPucDockets.ts	每日 Cron（19:00 UTC），/api/cron/ingest-co-puc。第三个州——目前最整洁：搜索结果中已有真正的结构化状态字段，完全无需根据提交历史推断。	服务端渲染的 HTML，无需身份验证
Ohio Power Siting Board 案件	src/lib/ingest/ohOpsbCases.ts	每日 Cron（19:30 UTC），/api/cron/ingest-oh-opsb。第四个州——目前最简单的数据获取方式（一次无需身份验证的 JSON 请求即可返回完整案件历史），也是本系列中首个状态及燃料／项目类型都是真正结构化字段、而非推断所得的来源。	单个 JSON 端点，无需身份验证
South Carolina PSC 选址证书案卷	src/lib/ingest/scPscDockets.ts	每日 Cron（20:00 UTC），/api/cron/ingest-sc-psc。第五个州——与 Texas 一样没有可靠的状态字段，但案件标题描述异常详细（文本中写明设施类型、容量和县名）；“仍在等待”是根据嵌入的 Orders 子表推断，而非扫描完整提交历史。	服务端渲染的 HTML，无需身份验证
Arizona ACC 输电线路选址委员会案卷	src/lib/ingest/azAccLineSiting.ts	每日 Cron（20:30 UTC），/api/cron/ingest-az-acc。第六个州——具有真正的 JSON API，但也存在与 South Carolina 相同的“状态字段不可信”问题，这一问题是在此独立发现的：实际已裁决的案卷，其 docketStatus 仍可能显示“Open”。真正的信号来自单独的 decisions 数组。	真正的 JSON API，无需身份验证
Washington EFSEC 设施选址认证	src/lib/ingest/waEfsecFacilities.ts	每日 Cron（21:00 UTC），/api/cron/ingest-wa-efsec。第七个州——事实证明，Washington 自己的公用事业委员会（WUTC）根本没有选址证书审批权；真正的主管机构是另一个机构 EFSEC，直接导入其规模较小的全量清单（共 19 个设施）。目前唯一一个结构化状态字段可靠、而自由文本描述被发现不可信的州。	服务端渲染的 HTML，无需身份验证
New Mexico PRC CCN 案卷	src/lib/ingest/nmPrcDockets.ts	每日 Cron（21:30 UTC），/api/cron/ingest-nm-prc。第八个州——真正的 JSON API 位于 Angular SPA 前端之后，通过捕获应用自身的网络请求发现。其 CCN 类别还包含水务公用事业证书和因提交而被拒的重复申请，这两类都在本地过滤；与这里其他几个州不同，其状态字段经测试后证明可靠。	真正的 JSON API，无需身份验证
Illinois ICC CPCN 案卷	src/lib/ingest/ilIccDockets.ts	每日 Cron（22:00 UTC），/api/cron/ingest-il-icc。第九个州——其 CPCN 案件类型类别还包含声明性裁定和征用权申请，会在本地过滤；容量以电压（kV）而非 MW 发布，这是本系列首次遇到的情况。其 Grain Belt Express 案卷对应的实体输电线路与现有 Permitting Dashboard 条目是同一条；此案发现并修复了一个真实的跨来源合并错误，参见未解决问题 #1。	服务端渲染的 HTML，无需身份验证
Florida PSC + DEP 选址认证	src/lib/ingest/flPscDockets.ts	每日 Cron（22:30 UTC），/api/cron/ingest-fl-psc。第十个州——Florida 的 PSC 根本没有 CPCN；选址通过单独的 DEP 流程进行，PSC 只会在其中启动一个规模很小的“需求认定”子案卷。会交叉核对两个机构的网页；与本系列通常情况不同，说谎的是州案卷机构自身的状态字段，而第二个机构的网页才可靠。	真正的 JSON API（PSC）+ 服务端渲染的 HTML（DEP），无需身份验证
New York DPS Article VII/VIII 案卷	src/lib/ingest/nyDpsDockets.ts	每日 Cron（23:00 UTC），/api/cron/ingest-ny-dps。第十一个州——一个系统中包含两类正在进行的选址证书流程（Article VII 下的输电项目，以及 Article VIII／其前身 § 94-c 下的可再生能源发电项目），由一个模块统一覆盖。完全不发布状态字段，而且可再生能源流程的批准令甚至不会作为 Order/Decision 提交，而是作为普通往来文件提交，只有扫描所有文件标题、不限文件类型才能找到。	真正的 JSON API，无需身份验证
Nevada PUCN UEPA 许可证案卷	src/lib/ingest/nvPucnDockets.ts	每日 Cron（23:30 UTC），/api/cron/ingest-nv-pucn。第十二个州——没有 CPCN；Nevada 对应的审批机制是 Utility Environmental Protection Act 许可证，分布在两个独立的 PUCN 系统中（旧版 WebForms 案卷清单和新版 OnBase JSON API）。其多阶段输电审查（某阶段已“GRANTED”，数月后又提交新阶段）需要真正检查“之后没有实质性提交”，而不能只看是否有任何命令写着 GRANTED。	旧版 ASP.NET WebForms + 真正的 JSON API（OnBase），无需身份验证
Oregon EFSC 设施选址认证	src/lib/ingest/orEfscFacilities.ts	每日 Cron（00:00 UTC），/api/cron/ingest-or-efsc。第十三个州——与 Washington 一样，Oregon 自己的公用事业委员会没有选址审批权；真正的主管机构是 Energy Facility Siting Council。不同寻常的是，其两个结构化状态字段都不可靠（97 个设施中有 37 个字段值互相矛盾）；真正的信号来自自由文本叙述字段。当前候选项目 Cascade Renewable Transmission 与已通过 Washington EFSEC 模块追踪的实体 HVDC 输电线路是同一条，通过 manualOverrides.csv 合并。	真正的 JSON API（SharePoint REST），无需身份验证
Massachusetts EFSB 案卷	src/lib/ingest/maEfsbDockets.ts	每日 Cron（00:30 UTC），/api/cron/ingest-ma-efsb。第十四个州——与 Washington/Oregon 一样，州 DPU 本身不是实际的选址主管机构；行政上隶属 DPU 的委员会（EFSB）负责签发实际证书。其自身的“Closed Date”字段在实际批准数年后仍可能为空，因此改为扫描所有已提交文件的类型，查找“Final Decision”来推断结案情况。	真正的 JSON API，无需身份验证
Oklahoma OCC 高压输电 COA 案卷	src/lib/ingest/okOccDockets.ts	每日 Cron（01:00 UTC），/api/cron/ingest-ok-occ。第十五个州——没有通用 CPCN；Oklahoma 自己的“CCN”救济类型几乎专供电信运营商使用，真正对应电力选址的是范围更窄的“High Voltage Transmission COA”证书——自 2022 年起仅提交过 4 个案件，截至发布时全部已解决，这是确实没有候选项目（而非程序出错）的结果。	真正的 JSON API（Laserfiche WebLink），无需身份验证
Utah PSC CPCN 案卷	src/lib/ingest/utPscDockets.ts	每日 Cron（01:30 UTC），/api/cron/ingest-ut-psc。第十六个州——在 Utah 自 1987 年以来的全部电力案卷历史中，真正的新 CPCN 申请仅有 12 件，且全部已获批，这是又一个确实没有候选项目的结果（PacifiCorp/Rocky Mountain Power 的资源决策改走 Integrated Resource Plan 认可流程）。本项目没有 PDF 解析依赖，因此通过 Node 内置的 zlib 直接解压最终命令 PDF 自身的 FlateDecode 数据流来读取内容。	服务端渲染的 HTML，无需身份验证
Wisconsin PSC CPCN／Certificate of Authority 案卷	src/lib/ingest/wiPscDockets.ts	每日 Cron（02:00 UTC），/api/cron/ingest-wi-psc。第十七个州——大型设施 CPCN 和较小设施 Certificate of Authority 两种流程共用同一个案卷案件类型代码。PSC 自己的“Status”字段代表记录保留生命周期标记，而非案件裁决状态标记——7 年多以前裁决的案卷仍会无限期显示“Active”；真正的信号是已提交且标题为“Final Decision”的命令。	服务端渲染的 HTML（ASP.NET WebForms），无需身份验证
Kentucky PSC CPCN／Certificate of Construction 案卷	src/lib/ingest/kyPscDockets.ts	每日 Cron（02:30 UTC），/api/cron/ingest-ky-psc。第十八个州——与众不同的是，其“Include Closed”搜索筛选条件经双向核对真实案卷后证明可靠；这是本系列首次将其用作主要状态信号，同时仍保留基于文本的批准／拒绝扫描作为防御性次级检查。	服务端渲染的 HTML（ASP.NET MVC），无需身份验证
Missouri PSC Certificate of Convenience and Necessity 案卷	src/lib/ingest/moPscDockets.ts	每日 Cron（03:00 UTC），/api/cron/ingest-mo-psc。第十九个州——真正的受反伪造机制保护的 AJAX API。发布前运行后的数据质量检查与实时数据库核对，发现了一个真实错误：锚定正则未能匹配实际的“Order Approving Third/Unanimous Stipulation and Agreement”标题，而 Order/Notice 类型筛选则完全漏掉了实际的“Closing File”提交；两者导致多个已于 2018／2019 年解决的案卷被错误显示为仍在等待。	真正的 JSON API（ASP.NET Core MVC，受反伪造机制保护），无需身份验证
Indiana IURC CPCN 案卷	src/lib/ingest/inIurcDockets.ts	每日 Cron（03:30 UTC），/api/cron/ingest-in-iurc。第二十个州——公共门户上可见的 reCAPTCHA 只由客户端 JS 检查；实际后端 API（一个单独的配套 Azure App Service）从不接收或验证令牌。案件状态“Appealed”会映射到本网站自身的“诉讼”阶段，而不是删除，因为委员会的 Final Order 已存在，但尚未具有法律终局性。	真正的 JSON API（单独的配套 Azure App Service），无需身份验证
New Jersey BPU 40:55D-19 认定／CSI 选址豁免案卷	src/lib/ingest/njBpuDockets.ts	每日 Cron（04:00 UTC），/api/cron/ingest-nj-bpu。第二十一个州——New Jersey 根本没有 CPCN；最接近的对应机制是由一个模块覆盖的两种不同案卷类型（40:55D-19“对公众合理必要”的认定，以及 Competitive Solar Incentive Program 选址禁令豁免）。在一个真实案卷中发现，BPU 自己的“Case Status”字段已过时 9 年，因此改为从最近一份 Board Order PDF 的文本中读取结案情况，并使用 Node 内置的 zlib 解压（本项目没有 PDF 解析依赖）。	服务端渲染的 HTML（ASP.NET WebForms，前置 Imperva），无需身份验证
Maryland PSC CPCN 案卷	src/lib/ingest/mdPscDockets.ts	每日 Cron（04:30 UTC），/api/cron/ingest-md-psc。第二十二个州——完全没有“Status”字段；“仍在等待”是通过扫描所有已提交文件，查找具有决定效力的委员会／公共事业法法官命令来推断。由于实际的决定性命令措辞出奇多变（有些除了命令编号外主题为空），因此必须采用允许列表与排除列表相结合的方式。运行后的数据质量检查发现了一个真实的县名提取错误（自由格式正则误抓了前面的案件标题文本）和一个真实的来源拼写错误（一个真实标题中将“Dorchester”误写为“DORCESTER”）；两者都在发布前修复。	服务端渲染的 HTML（ASP.NET WebForms，仅通过无 Cookie 的 viewstate 回传），无需身份验证
Connecticut Siting Council（CSC）案卷／申请	src/lib/ingest/ctCscDockets.ts	每日 Cron（05:00 UTC），/api/cron/ingest-ct-csc。第二十三个州——与 Washington/Oregon/Massachusetts 一样，真正的选址主管机构并非显而易见的公用事业委员会（PURA 只会参与 CSC 自己的流程并提出意见）。CSC 根本没有可查询的案卷搜索功能，只有人工编写的 CMS 页面；其免责声明称“可能无法及时更新信息”，经人工核查证实属实（2013 年已批准的申请在 2026 年仍列为开放），因此每个候选项目在被视为仍待处理之前，都会与 CSC 自己的历史 Decision and Order List 交叉核对。在本项目自身验证步骤中发现并修复了一个结构性错误——已解决的候选项目会被悄悄排除在导入之外，而不是以已解决阶段传入；这意味着后来解决的项目永远不会从网站删除。	服务端渲染的 HTML（手工编写的 CMS，无搜索／API），无需身份验证
West Virginia PSC CPCN + Siting Certificate 案卷	src/lib/ingest/wvPscDockets.ts	每日 Cron（05:30 UTC），/api/cron/ingest-wv-psc。第二十四个州——包含两种案卷类型（通用 CPCN，以及针对商用发电机的独立 Siting Certificate），也是本系列中真实 STATUS 数据最丰富的来源之一：确认过一次真实的拒绝、一起通过 ALJ Recommended Decision 自动终结且没有单独委员会命令的案件，以及确认过一次误报（同一案卷中无关的律师执业资格申请动议使用了“granted”一词），结案正则已专门编写以避开这种情况。还发现了一个真实的燃料分类错误（混合燃气＋太阳能申请被固定的关键词优先级标为“solar”，而非依据案件标题中首先提到的燃料），以及在 Connecticut 发现的同一种“候选项目消失”结构性错误——WV 自己的搜索结果仅包含 Active 案件，因此 Active 标志变为 Closed 的案件会从之后的所有搜索中消失，不会被模块自身的结案检查发现；通过将之前追踪的 matchKeys 与每次运行的活动案件清单进行差分修复。	服务端渲染的 HTML（年代久远的 ColdFusion，无需身份验证）
Tennessee TPUC CCN 案卷	src/lib/ingest/tnTpucDockets.ts	每日 Cron（06:00 UTC），/api/cron/ingest-tn-tpuc。第二十五个州——这是一个经过确认、确实不会产生任何结果的来源：TVA 是免受 TPUC 证书管辖的联邦机构，供应 Tennessee 绝大部分电力；其约 150 家地方电力公司拥有预先分配的专属供电区域，因此新进入者几乎不会触发电力 CCN 申请。人工扫描全部 160 个活动案卷后，发现当前没有开放的电力候选项目——每个真正的 CCN 类标题都是水务公用事业或电信申请。该来源仍保持启用（不移除），作为“持续监视罕见事件”的来源，与 ORNL 水电来源自身数据稀少的情况采用相同惯例；即使目前没有任何项目会过时，也应用了与 Connecticut/West Virginia 相同的预防性“候选项目消失”修复。	服务端渲染的静态 HTML（S3/CloudFront），无需身份验证
California Energy Commission（CEC）发电厂选址案卷	src/lib/ingest/caCecDockets.ts	每日 Cron（06:30 UTC），/api/cron/ingest-ca-cec。第二十六个州——CPUC（显而易见的候选机构）已尝试过，并确认应暂缓接入：其搜索表单真正的提交流程由客户端 Dynamic Action 逻辑驱动，普通 fetch() 看不到；通过原始 POST 重放和真实浏览器会话两种方式确认，即使点击按钮也根本没有到达实际搜索端点。事实证明，真正的选址审批机构是 CEC——它对 ≥50MW 的热能／地热电厂拥有专属管辖权，自 AB 205 起还对 ≥50MW 的太阳能／风能项目和 ≥200MWh 的储能项目拥有专属管辖权；几乎所有大型项目都会在 CEC 而非 CPUC 备案。发布前发现并排除了一个误报结案信号（地方空气管理区自己的“Notice of Decision”，与 CEC 的选址决定无关），并修复了在 Connecticut/West Virginia 已发现的同一种“候选项目消失”结构性错误。	服务端渲染的 HTML（Drupal + ASP.NET WebForms），无需身份验证
New Hampshire Site Evaluation Committee（SEC）案卷	src/lib/ingest/nhSecDockets.ts	每日 Cron（07:00 UTC），/api/cron/ingest-nh-sec。第二十七个州——这是“真正的选址主管机构并非显而易见的公用事业委员会”的第四个真实案例（此前为 WA/OR/MA/CT）：PUC 的 3 名委员只是 SEC 的 5 名法定成员中的 3 名，单独无法构成法定人数。2025 年 12 月的一次重组将 SEC 的案卷记录迁至 PUC 自己的网站，并加上“SEC”前缀，这正是乍看之下容易误以为“PUC 负责选址”的原因。发布前发现了一个真实的误报结案信号——因程序不完整而被“驳回”的案卷，通过关键词匹配看起来恰好像最终拒绝，但实际上并非如此；通过一个真实且提交文件超过 190 份、在自身“驳回”后仍继续处理的案卷确认了这一点。文档记录了针对所有 nh.gov 子域名、仅限 curl 的 TLS 指纹机器人拦截（与 Node 自身的 fetch() 无关，而本模块实际使用的是后者），以免未来维护者误将其当成真正的阻碍。	服务端渲染的 HTML（ASP.NET WebForms），无需身份验证
Idaho PUC CPCN 案卷	src/lib/ingest/idPucDockets.ts	每日 Cron（07:30 UTC），/api/cron/ingest-id-puc。第二十八个州——它是最早发布真正结构化 Status 字段的来源之一；但由于 common.ts 中的 RESOLVED_STAGES 不论项目是“approved”还是“cancelled”都会以相同方式删除项目，因此 Idaho 自己的开放／关闭状态区分就已足够，无需像 WV/MD/CT 那样解析命令文件文本。一个真实的单复数正则错误（\bcertificate\b 末尾的单词边界悄悄排除了所有“CERTIFICATES OF...”复数标题）将 4 个真实候选项目少算成 1 个；通过在发布前将试运行结果与人工核实的数量对比发现——IPUC 自己的搜索框也实时证实了这一遗漏。还发现了一个真实的共同所有者重复项目（两家公用事业公司分别为同一条实体输电线路提交了各自的 CPCN）；按照本项目不去重的政策，保留为两行。	服务端渲染的 HTML（类似 ASP.NET 的 CMS），无需身份验证
Nebraska Power Review Board（PRB）申请	src/lib/ingest/nePrbDockets.ts	每日 Cron（08:00 UTC），/api/cron/ingest-ne-prb。第二十九个州——Nebraska 没有投资者所有的电力公司，PSC 也完全没有电力证书管辖权；真正的主管机构是 Power Review Board，但它没有任何案件搜索工具或案卷数据库，“仍在等待”完全根据 Board 自己的会议纪要文本推断。发布前通过实时数据库检查发现并修复了两个真实的结构性错误：争议案件的事实和解决结果可能分别位于与首次／末次提及不相邻的段落中，初版“首次提及＝事实，末次提及＝状态”的设计两方面都判断错误——一次弄乱了真实案件的名称／字段，另一次将确实已获批的案件误判为仍待处理。发布时，13 个真实且符合范围的候选项目均已解决（Nebraska 案件量小且大多无争议，通常一次 Board 会议就能结案）；人工确认目前确实没有待处理项目，并非抓取遗漏。	服务端渲染的 HTML（Drupal，仅含文本的会议纪要，无搜索工具），无需身份验证
Louisiana PSC 认证案卷	src/lib/ingest/laPscDockets.ts	每日 Cron（08:30 UTC），/api/cron/ingest-la-psc。第三十个州——没有统一命名的 CPCN 法规（一个看似有希望的命中 La. R.S. 45:1503，实际却是 1968 年的电信法规；阅读原文后发现这是一个真实的错误猜测陷阱）；真正的审批门槛是统一的“certification”／“approval to construct”案卷惯例，通过完整的 191 个真实案卷样本确认，未发现误报。已最终确认 New Orleans 不在范围内（Entergy New Orleans 根本未出现在 LPSC 约 16,900 个案卷的历史记录中——它仅由 City Council 监管）。LPSC 自己的 Status 字段以一种特别明显的方式不可信——实际批准命令发出数月甚至数年后，它仍会保持“Open”，因为 LPSC 会为批准后的合规监控而保持案卷开放。本项目自身的实时数据库验证步骤发现了一个模块最初校准时遗漏的真实错误：一个确认无误的实际批准命令使用了弯引号 Unicode 字符（“Judge’s Recommendation”），而仅匹配 ASCII 直引号的正则未能识别，导致已解决的案卷被错误显示为仍待处理。	真正的 JSON API（ASP.NET MVC + Kendo UI），无需身份验证
Alabama PSC CPCN 案卷	src/lib/ingest/alPscDockets.ts	每日 Cron（09:00 UTC），/api/cron/ingest-al-psc。第三十一个州——Alabama 的 CPCN 法规并非电力专用，所有类型的公用事业共用一套连续案卷编号，因此通过客户端内容筛选界定范围，而非使用案卷代码前缀。发现了一个真实的全文搜索索引缺口，导致本网站最关注的、最近提交的此类案卷会系统性地隐形——在长达 26 年的回溯期内，Alabama Power 真实且当前的“Lindsay Hill” CPCN（2025 年获批）始终未出现在短语搜索结果中；通过增加一条仅针对 Alabama Power 自身提交内容的结构化元数据发现路径修复。还发现了一种新形式的真实候选项目消失错误：内容筛选收紧前写入数据库的两个误报会永久留存，因为基于内容的拒绝（与之前各州基于状态筛选的此类错误不同）不会自然地重新检查已追踪的行；通过对本次运行已能明确判定的每个 matchKey 与实际写入数据库的项目进行差分，以相同方式修复。	服务端渲染的 HTML（通过会话 Cookie 的有状态 ASP.NET WebForms，无 ViewState），无需身份验证
Arkansas PSC CECPN/CCN 案卷	src/lib/ingest/arPscDockets.ts	每日 Cron（09:30 UTC），/api/cron/ingest-ar-psc。第三十二个州——Arkansas 没有专属的案件类型代码；所有事项（CECPN、CCN、电价案件、投诉、规则制定等）共用一套连续案卷编号，只有“-U”（“Utility”）后缀会对应真正的建设证书申请，这一点通过抽查其他每种实际使用的后缀下的实时案卷确认。本系列中第一个重新实时运行以验证新版 Status 筛选架构的州（参见“Stop hiding resolved projects”提交）：现在 17 个真实的 Arkansas 案卷会按其真实阶段保存（11 个获批、1 个被拒、5 个待处理），而不是删除已解决的案卷。	服务端渲染的 HTML，无需身份验证
Delaware PSC 输电 CPCN + Community Energy Facility 案卷	src/lib/ingest/dePscDockets.ts	每日 Cron（10:00 UTC），/api/cron/ingest-de-psc。第三十三个州——Delaware 的 CPCN 权限分属两部不同法规；本模块有意追踪其中与具体项目相关的一项（26 Del. C. §203F，适用于 ≥30 MW 的可再生能源并网设施），以及适用于最高 4 MW Community Solar 设施、非 CPCN 的“Preliminary Certificate to Operate”审批门槛；与本系列排除其他所有州的公用事业许可案卷一样，也排除实体层面的电力供应商 CPCN。	服务端渲染的 HTML（ASP.NET WebForms，基于 Cookie），无需身份验证
Maine DEP Site Law 许可证	src/lib/ingest/meDepSiteLawPermits.ts	每日 Cron（10:30 UTC），/api/cron/ingest-me-dep。第三十四个州——Maine 大多数大型能源项目真正的建设审批门槛不是 PUC 的 CPCN（35-A M.R.S. §3132，该法规仅适用于独立输电线路），而是 DEP 的 Site Location of Development Act 许可证；这与本系列在 WA/OR/MA/CT/NH 已发现的 PUC 与选址机构分立模式相同。	真正的 ArcGIS REST 端点，无需身份验证
Rhode Island EFSB 大型能源设施案卷	src/lib/ingest/riEfsbDockets.ts	每日 Cron（11:00 UTC），/api/cron/ingest-ri-efsb。第三十五个州——这是本系列在 WA/OR/MA/CT/NH 已发现的“PUC 并非真正选址主管机构”模式的第六个确认案例：Rhode Island 的许可要求（R.I. Gen. Laws §42-98-4）由独立的三人 Energy Facility Siting Board 负责，而不是初步搜索结果暗示的 PUC。	服务端渲染的 HTML（Drupal/Acquia CMS），无需身份验证
Vermont PUC Certificate of Public Good 案卷	src/lib/ingest/vtPucDockets.ts	每日 Cron（11:30 UTC），/api/cron/ingest-vt-puc。第三十六个州——与本系列在 WA/OR/MA/CT/NH/RI 发现的职权分立模式不同，Vermont 的 PUC 确实是真正的选址主管机构：直接核对法规文本后确认，30 V.S.A. §248 的 Certificate of Public Good 是发电、输电和储能项目共同的建设审批门槛。	服务端渲染的 HTML（Drupal 7），无需身份验证
South Dakota PUC Energy Conversion/Transmission Facility 许可证案卷	src/lib/ingest/sdPucDockets.ts	每日 Cron（12:00 UTC），/api/cron/ingest-sd-puc。第三十七个州——在这里发现并绕过了 South Dakota PUC 自己网站上的一个真实错误：实际批准后，单个案卷的状态徽标会过时（截至 2026-08-25，一个 2021 年的风电场许可证仍显示“Pending”，尽管 2023 年已有批准命令且施工报告持续发布）；因此本模块扫描每个候选项目自己的“Orders:”清单，查找实际的批准／拒绝／撤回文本，而不信任徽标。	服务端渲染的 HTML，无需身份验证
North Dakota PSC Energy Conversion/Transmission Facility 选址申请	src/lib/ingest/ndPscDockets.ts	每日 Cron（12:30 UTC），/api/cron/ingest-nd-psc。第三十八个州——South Dakota 和 Louisiana 已发现的同一种“Date Closed 字段不可信”错误也在这里得到确认（一个 2024 年已批准的真实证书转让仍显示空白的 Date Closed），但 HTML 中没有任何可用的自由文本命令摘要；要解决这一问题，必须采用本系列首次使用的方式：获取每个候选项目真正的 Commission Order PDF，并使用新增的 pdf-parse 依赖解析实际文本，查找批准／拒绝／驳回措辞；已通过实时数据核对一项证书转让批准和一个新设施批准予以确认。	服务端渲染的 HTML + 实际命令 PDF，无需身份验证
North Carolina Utilities Commission（NCUC）电力发电／输电线路证书案卷	src/lib/ingest/ncNcucDockets.ts	每日 Cron（13:30 UTC），/api/cron/ingest-nc-ncuc。第三十九个州——本系列中首个具有真正结构化案卷类型分类体系的来源：NCUC 自己的“EGC”／“ETL”提交类型代码可作为精确的服务端范围筛选，因此与 SC/AZ/TX 不同，本模块无需先按关键词搜索再在本地筛选。由 Cloudflare 代理，且采用真正非标准的 ASP.NET 回传引擎（自定义 __VIEWSTATE1 计数器按页面 URL 跟踪，而非仅按会话跟踪——A/B 测试确认，如果不先重新 GET，在搜索界面之间切换会悄悄返回上一个界面的过时结果）。与 SC/AZ 的情况一样，已确认案卷自身的 Status 字段不可靠（实际批准后数年仍显示“Open”），因此改为使用按案卷编号限定范围的独立 Orders 门户搜索来读取结案情况，扫描命令标题中的批准／拒绝信号——校准依据包括真实的批准和拒绝命令，以及一个“目前被拒绝但案卷仍保持开放”的真实陷阱案例，该案例并非最终结案。	服务端渲染的 HTML（由 Cloudflare 代理的 ASP.NET WebForms），无需身份验证
Wyoming DEQ Industrial Siting Council（ISC）许可证案卷	src/lib/ingest/wyIscDockets.ts	每日 Cron（14:30 UTC），/api/cron/ingest-wy-isc。第四十个州——本系列首次遇到这种情况：实际案卷档案存放在公开 Google Drive 文件夹中，而完全不在机构自己的网站上（其嵌入式文件浏览器小组件经确认在整个网站上都无法使用，永远卡在“Loading...”状态；页面上写着“如果此功能无法正常工作，请点击此处”的备用链接才是真正的入口）。Google Drive 新版网页界面没有无需 OAuth 令牌或 Cloud API 密钥即可稳定公开使用的 JSON 清单，但旧版、无需身份验证的 embeddedfolderview HTML 端点（许多“嵌入 Drive 文件夹”网站插件都在使用）仍然可用。此来源完全没有结构化状态字段；通过每个案卷自身的文件名读取结案情况。文件名使用两种实际存在的不同时期批准文件命名方式（2020 年代的案卷使用“Order”，较早的案卷使用“Permit”，其中还包括来源自身真实的“Pemit”拼写错误），另有第三种经确认的信号（“Amendment Approval”意味着底层批准已存在）——初版仅匹配“Order”，错误地将所有较早的批准项目（包括几十年前已建成的电厂）显示为仍在等待；发布前通过针对真实已运营项目的实时数据库健全性检查发现此问题。此外，还通过关键词允许列表排除同一选址主管机构也负责许可的大量非能源工业案卷（苏打灰／天然碱开采、水泥、金矿开采）；这是一个真实且有记录的覆盖缺口。	Google Drive 文件夹（旧版、无需身份验证的 HTML 清单端点），无需身份验证
Georgia PSC 电力案卷	src/lib/ingest/gaPscDockets.ts	每日 Cron（15:00 UTC），/api/cron/ingest-ga-psc。第四十一个州——Georgia 的模式与本系列其他所有州都不同：单个发电／储能项目并不会各自提交选址申请；Georgia Power 新增资源会通过定期 RFP/Integrated Resource Plan 程序批量获批，随后由每轮 RFP 的一个案卷统一认证多个底层项目。此类认证案卷作为汇总条目追踪（isAggregateExample: true），而不会捏造虚假的单个项目。第二类真实案卷“Construction Monitoring”（McIntosh 和 Bowen 等已命名、已获批且由 PSC 积极监督的电厂）经过实时确认后，有意不予追踪，因为这类案卷首次出现时全部已处于 under_construction 这一已解决阶段，而本项目在 common.ts 中现有的新行保护机制会正确拒绝写入此类项目。还通过实时核实确认，搜索 API 自己的 title 查询参数会在服务端被悄悄忽略，因此像 Alabama 模块的先例一样，根据完整结果集在客户端限定范围。	真正的 JSON XHR 端点（docket-filter-service），无需身份验证
上述每个来源——4 个联邦／国家级工作簿来源、Permitting Dashboard 的实时 API，以及全部 41 个州级案卷模块——都通过 Vercel Cron（vercel.json）运行，无需人工操作；每项任务间隔 30 分钟，以确保不同来源的运行不会重叠。运行频率与各来源的实际发布频率相匹配，而不是采用统一计划：41 个州级模块和 Permitting Dashboard 每天运行，因为当天提交的文件正是首页更新动态要呈现的内容；底层数据仅按月、按季度或按年重新发布的 4 个来源（EIA-860M、LBNL Queued Up、ORNL HydroSource、EIA 的管道跟踪器）则保持每周运行，因为每天检查也无法发现新内容。网站升级到 Vercel Pro 后，这些任务不再受 Hobby 计划限制而只能每周检查（完整的频率变更历史见 src/lib/ingest/README.md）。每次数据摄取运行都会按稳定的来源级 ID 执行 upsert（见开放问题 #1 中的 matchKey/manualOverrides.csv 身份识别机制），因此重新运行会就地更新现有项目，而不会重复创建。

每个摄取的项目都会链接回其公开来源（见各项目详情页）。如果无法有把握地获取日期或数值，项目会标记为 dateConfidence: "approximate"，或附上相应说明的 dataQualityNote，而不是将虚构的精确值当作事实呈现。迄今为止明显缺失的内容包括：容量低于 250 MW 的发电／储能项目（见上述各来源的容量下限／范围——这包括占水电许可证续期案卷绝大多数的小型项目），以及自动摄取项目的任何原因类别归属（五个来源均未公布项目延误的原因——见开放问题 #4）。本网站只跟踪仍在等待审批的项目——有关有意排除的内容及原因，见 src/lib/ingest/README.md 中的“RESOLVED_STAGES”。

并网队列详情。 lbnlQueuedUp.ts 为 LBNL 来源的项目新增了两个字段，自 2026-08-21 起生效：interconnectionQueueStage（工作簿本身使用的研究阶段标签，例如“可行性研究”）和 networkUpgradeCostUsd（预留用于与 LBNL 单独发布、更新不定期的并网成本分析数据集关联，目前尚无任何模块填充此字段）。根据明确的产品决策，已暂停的并网申请与已撤回申请同样处理：不显示为“等待中”。现在，每次摄取运行也会在后续版本报告项目已撤回、已暂停或已投入运营时，立即将之前显示的项目移除，而不是让项目停留在最后已知状态——完整详情和开放问题 #9 见 src/lib/ingest/README.md。

开放问题

这些问题是刻意标记出来的，而非靠猜测作答——各数据源对应的清单版本也见 src/lib/ingest/README.md。

1. 跨来源项目身份匹配是一个真实且持续存在的问题， 尚未得到完全解决。 EIA、Permitting Dashboard，以及如今不断扩展的 州级案卷系列，都各自使用自己的名称/ID 来标识可能是同一个实体项目的 项目。src/lib/ingest/manualOverrides.ts + .csv 允许人工通过共享的 matchKey 声明两个来源记录属于同一个项目——这里 刻意没有自动模糊匹配（名称相似度 + 地理距离 + 容量相似度被标记为 最有价值的后续工程任务，本次并未尝试实现）。 该机制中的一个真实合并错误已于 2026-08-23 发现并修复： upsertNormalizedProject（common.ts）过去通过 slug 查找已有 项目，但 slug 是根据项目的名称生成的，而不同来源使用的名称并不 相同——因此，即使两条记录共享人工声明的 matchKey，最终仍会产生两行 独立记录，而不是合并成一行，导致覆盖文件的全部用途悄然失效（人工检查 时发现，伊利诺伊州新收录的 Grain Belt Express CPCN 案卷，竟与 Permitting Dashboard 中同一输电线路的现有条目重复）。 修复方法是在 Project（prisma/schema. prisma）中添加真正的 matchKey 列，并改为据此进行 upsert，同时 保留基于 slug 的回退查询，以便每个在该列存在之前导入的项目，都会在其 来源下次自然重新导入时自行修复（回填真正的 matchKey）——无需单独进行 回填迁移。现在 ProjectSource 行也按 (projectId, label) 进行 upsert，而不是每次运行都先删除再重建，因此合并后的项目会保留两个来源的 链接，不会再被较晚运行的来源写入覆盖另一个来源的链接。 manualOverrides.csv 目前只有一个真实条目（Grain Belt Express： Permitting Dashboard project_id 109441 + Illinois ICC 案卷 22-0499） ——最初标记的另外两个重复项 SouthCoast Wind 和 Ocean Wind 1，目前并无 重叠可供合并（参见 permittingDashboard.ts 中的 "NOTE on cross-source identity matching" 注释），因此暂未为它们声明 匹配关系。
2. Permitting Dashboard 的 Socrata 数据集是去规范化连接结果，而非每个 项目一行——单次查询就可能为每个项目返回数十条逐字节完全相同的重复 行。导入模块会在规范化之前去重；如果全新运行后的行数远高于预期，请留意 这一点。
3. 本项目使用的开放 Socrata 数据集上，Permitting Dashboard 没有公开的 里程碑/时间线或申请提交日期字段——这些数据可能存在于 Dashboard 自身 文档提到的、需要令牌才能访问的 /api/v1/project/{id} 端点后面， 但本轮并未注册该端点。
4. EIA-860M、Permitting Dashboard、ORNL 水电许可证续期数据集，以及 EIA 输油气管道项目追踪器都不提供原因类别。 从这四个来源导入的每个项目 都带有 causeSlugs: []，并明确注明需要人工/派生分配原因，而不是猜测 一个默认值。（LBNL Queued Up 是例外——其生成的每一行都会标记为 interconnection_queue_backlog，因为按定义，互联排队条目所等待的就是 这一事项。）
5. LBNL Queued Up 和 ORNL 水电许可证续期数据的列名尚未对照未来下载的 工作簿核实——两个解析器都是根据对各自过去/当前版本数据字典的熟悉程度 编写的，并会明确报错（指出缺少的列），而不是悄悄误读发生变化的列。在新的 年度版本发布后依赖其中任一解析器之前，请先检查当前工作簿自带的数据字典/ 字段说明选项卡。
6. 数据再分发条款——所有来源均已解决，详见 /data-licensing。 data.permits.performance.gov 自身的 Socrata 许可字段明确标为 "Public Domain"；此处获取 EIA-860M 和输油气管道追踪器时，使用的是 EIA 自行发布的 Excel 工作簿，而非 EIA 单独提供、需要密钥的 API （因此其服务条款不适用于本项目）；ORNL HydroSource 的数据使用政策声明 数据可“无限制”分享，并要求提供书目引用；据报告，LBNL Queued Up 使用 CC BY 4.0（署名 LBNL + GridTracker）——该页面注明此信息为报告所得， 未经独立重新获取核实，因为本次研究期间 LBNL 自身网站阻止了自动重新获取。 每个来源的完整说明请见 /data-licensing，此处不再重复。 在通过本网站自身的 API 大规模再分发批量数据之前，请先逐个来源获得明确答复。
7. 仅对具有 MW 容量且公布了建设成本数据的发电/储能项目估算等待投资金额。 输电、输油气管道和 LNG 项目显示“未估算”，而不是给出基于本项目无法充分 证明的假设得出的数字——参见 src/lib/calc/investmentWaiting.ts 和 /methodology。
8. LBNL 的互联成本分析数据集并非一个会可靠更新的单一来源。 2026-08-21 确认：架构中预留了 networkUpgradeCostUsd，但尚无任何 导入模块为其填充数据。底层数据 (emp.lbl.gov/interconnection_costs) 来自六份相互独立、按地区发布的数据（MISO、PJM、SPP、ISO-NE、NYISO、 非 ISO 的平衡责任区），不是像 Queued Up 那样一份合并且每年刷新的文件 ——其中多个版本已经过时多年（MISO 的版本来自 2021 年）。与现有 LBNL Queued Up 项目的关联（按 entity+q_id）确实可行——已对照 PJM 抽查确认——但这些成本研究对当前活跃排队条目的覆盖会很稀疏，因为这些 研究中的大多数项目早已投运或已撤回。参见 src/lib/ingest/README.md。
9. SQLite + 无服务器部署（已解决）。 v1 最初随项目提交了 SQLite 文件， 以便本地开发无需配置。首次部署到 Vercel 时，此方案完全失效：Next.js 的无服务器文件追踪器不知道要打包一个仅通过连接字符串引用（而未通过 import 导入）的文件，因此部署函数中悄然缺少 prisma/dev.db，所有 数据库读取都返回 500——这比此处最初指出的“写入无法持久化”问题还要糟糕。 现已改为使用托管 Postgres 实例（通过 Vercel Storage 集成的 Prisma Postgres），本地开发和生产环境共用该实例。
10. 州级 PUC/PSC 案卷：已覆盖三十八个州，还剩 12 个，每个州都有各自棘手 的问题。 2026-08-24 确认：州公用事业委员会的案卷没有全国性聚合器—— 每个州都运行自己的系统，FERC eLibrary 只涵盖联邦层面。 vaSccDockets.ts、txPuctDockets.ts、coPucDockets.ts、 ohOpsbCases.ts、scPscDockets.ts、azAccLineSiting.ts、 waEfsecFacilities.ts、nmPrcDockets.ts、ilIccDockets.ts、 flPscDockets.ts、nyDpsDockets.ts、nvPucnDockets.ts、 orEfscFacilities.ts、maEfsbDockets.ts、okOccDockets.ts、 utPscDockets.ts、wiPscDockets.ts、kyPscDockets.ts、 moPscDockets.ts、inIurcDockets.ts、njBpuDockets.ts、 mdPscDockets.ts、ctCscDockets.ts、wvPscDockets.ts、 tnTpucDockets.ts、caCecDockets.ts、nhSecDockets.ts、 idPucDockets.ts、nePrbDockets.ts、laPscDockets.ts、 alPscDockets.ts、arPscDockets.ts、dePscDockets.ts、 meDepSiteLawPermits.ts、riEfsbDockets.ts、vtPucDockets.ts、 sdPucDockets.ts 和 ndPscDockets.ts 都是纯 HTTP 获取来源，而非 网页抓取项目——它们都不需要无头浏览器，结构与本网站其他来源相同——但 没有一个是“加个模块就行”：
    • 弗吉尼亚州有真实且结构化的 Status 字段，但其搜索范围（标题中 必须包含确切短语 "Certificate of Public Convenience and Necessity"）既精准又狭窄：弗吉尼亚州历史上所有案件中只有 46 个 符合条件，目前只有 1 个仍在审理。
    • 得克萨斯州完全没有状态字段——“仍在等待”是通过扫描每个案卷的 完整文件记录，并查找结案信号（最终命令、复审命令或类似文件）推断出来 的；判断标准是通过真实案卷人工校准的，而非凭空猜测（详见 txPuctDockets.ts 的文件头，其中记录了发布前发现并修复的具体漏判）。 相应地，得克萨斯州的产出高得多——近期候选超过 100 个，而弗吉尼亚州 只有个位数。
    • 科罗拉多州的搜索结果本身就包含状态列 （Active/Closed/Effective/Withdrawn/Suspended/Appealed）——无需 逐个获取候选详情，就能知道案卷是否仍未结案，这一点与弗吉尼亚州和 得克萨斯州都不同。
    • 俄亥俄州出乎意料地最简单：其电力选址委员会会通过一个无需身份验证 的 JSON 请求发布全部案件历史（共 227 件），完全没有搜索/分页/会话， 且状态和燃料/项目类型都是真正的结构化字段——这是本系列中首个无需猜测 关键词即可获得燃料类型的来源。难点在于找到它：俄亥俄州常规 PUCO 案卷系统位于会阻止所有搜索请求的反机器人 WAF 后面，无论使用什么标头 都无济于事；人工确认确实走不通后，才转而使用 OPSB。
    • 南卡罗来纳州也没有可靠的状态字段（即使案卷在几年前已获批，其 “Status”列仍会显示 "Open"），因此“仍在等待”是根据同一详情页请求中 已包含的 Orders 子表推断出来的；这比得克萨斯州扫描完整文件历史成本更 低，因为它只需扫描一个小表，而非每一份文件。更大的陷阱在于搜索范围： 使用弗吉尼亚州和得克萨斯州采用的 CPCN 短语进行服务器端精确匹配搜索， 几乎完全找不到南卡罗来纳州的真实标题；当地标题使用的是更长的法定名称 ("Certificate of Environmental Compatibility and Public Convenience and Necessity")。更宽泛的关键词搜索则漏入了两个只是 针对证书提出异议、而非申请证书的请愿；这在实际运行后的数据质量检查 中发现并修复，方法是要求标题必须以 "Application of" 开头。
    • 亚利桑那州有真正的 JSON API（与弗吉尼亚州/得克萨斯州/南卡罗来纳州 使用 HTML 不同），但其案卷级 docketStatus 字段与南卡罗来纳州的 Status 字段一样不可靠——这是独立重新发现的，并非假定这一问题也会出现在 亚利桑那州：一个于 2022 年 12 月提交的案卷，尽管在提交五个月后就已获 证书，今天仍显示 docketStatus: "Open"。真正的信号是另一个 decisions 数组（为空 = 仍待处理；有任何条目 = 委员会已作出裁决）—— 已通过一个包含 64 个案卷的真实批次核实；其中具有迷惑性的 "Compliance Due" 状态（占该批次的 81%）可靠地表示“已经获批，现处于批准后的合规 监管阶段”，而非“仍在等待”。其搜索端点还会在省略 rowsPerPage 或将其 设为零时悄悄返回零行，尽管总数正确且没有报错——此问题在它看起来像是 “未找到候选项”之前就已发现。
    • 华盛顿州的公用事业委员会根本没有 CPCN/选址权限——WUTC 的约 36,500 个案卷都是资费、费率案件和关联利益申报；人工确认其中几乎没有 与选址有关的内容。该权限实际上属于另一个机构——能源设施选址评估委员会 (EFSEC)，其设施完整历史记录只有 19 条（RCW 80.50 仅涵盖大型 能源设施），少到无需按日期设置回溯范围即可全部导入。到目前为止，华盛顿州 也是本系列中唯一一个“别相信状态字段”这一熟悉教训反过来的州：EFSEC 的结构化状态字段结果可靠，出问题的反而是自由文本描述段落——某设施的 叙述仍称其处于活动状态、等待施工，但其选址认证实际上已在四个月前终止， 只有结构化字段正确反映了这一点。
    • 新墨西哥州在 Angular SPA 前端后有真实的 JSON API（通过捕获应用自身 的网络请求找到，而非猜测），而且与本系列中不常见的情况一样，其状态字段 经独立测试后证明可靠，并未失真。它真正的陷阱在于搜索范围：其 CCN 类别还包括供水/污水公用事业证书（通过标题关键词排除）；另一个问题是电子 申报的受理阶段驳回——这类申请从未获得真正的案卷编号，却仍像案件一样 出现在搜索结果中。
    • 伊利诺伊州成为本系列首个真正的跨来源重复项：其 Grain Belt Express CPCN 案卷，与已通过联邦 Permitting Dashboard 追踪的同一条实体州际输电 线路是同一个项目。确认并修复该问题时，也发现了 manualOverrides.csv 合并机制本身存在一个真实错误（见待解决问题 #1）——这项发现本身的价值 不亚于州级模块。伊利诺伊州自身的搜索范围问题是：其 CPCN 案件类型分组 还会收录一份宣告性裁决请愿和一份纯征用权请愿；要求标题包含实际 CPCN 短语即可排除这两类案件。其公布的容量是电压 (kV)，而非 MW，这是本系列 首次遇到这种情况（由于伊利诺伊州 1997 年解除发电管制，如今其 CPCN 案卷几乎完全用于输电线路选址——2000 年以来 59 个真正候选项中，58 个 是输电线路，而非发电项目）。
    • 佛罗里达州根本没有 PSC CPCN 流程——选址通过单独的 DEP 流程进行， PSC 的“需求认定”只是一个较小的起始子案卷；人工核实后确认，它仅涵盖 PSC 完整 30,555 个案卷历史中的两个案卷（佛罗里达州法律规定，除非开发商 主动选择申请，否则太阳能项目可免于强制选址认证；因此佛罗里达州大多数 实际太阳能/储能建设项目根本不会经过该流程）。佛罗里达州也是唯一一个 被发现说谎的是负责机构自身的状态字段，而不是第二个来源：PSC 自身一个 关于 FPL 输电线路的案卷显示结案日期为 2026-06-01，但 DEP 实时的 Applications-in-Process 页面——即 PSC 案卷仅作为入口的真正多机构流程 页面——在十周后的 8/18/2026 仍显示有新文件提交。
    • 纽约州在同一模块中涵盖两类仍在进行的选址证书流程，因为两者属于同一 底层系统：《公共服务法》第 VII 条（输电）和第 VIII 条（可再生能源发电； 该条款此前称为《行政法》第 94-c 条，直到 2024 年州法律废除并替换了 该规定——DPS 自身记录对这两个名称的使用并不一致，经人工核实，因此本模块 会同时查询两者）。纽约州完全不发布状态字段，而且——只有检查一个获批的 特定案件 Alfred Oaks Solar 才发现的真实陷阱——可再生能源流程中的实际 批准命令，甚至不属于 Order 或 Decision 文件类型；它只是一封标题为 "...Final_Siting_Permit_-_Signed" 的普通往来函件，只有扫描所有已提交 文件的标题（不论类型）才能找到。实际请求量也迫使我们在调度上作出取舍： 完整运行耗时 236 秒，而 cron 预算为 300 秒，因此为留出安全余量而收紧 候选项上限；这是已记录并接受的限制（详见模块文件头）。
    • 内华达州也没有 CPCN——与之相当的是《公用事业环境保护法》(UEPA) 许可证，相关数据分布在两个完全独立的 PUCN 系统中（一个仅覆盖至约 2023 年 10 月的旧版 WebForms 案卷列表，以及一个用于获取真实状态的新版 OnBase JSON API）。最棘手的问题是分阶段进行的输电审查：即使案卷中有一份 简单的 "GRANTED" 命令，几个月后仍可能处于真正的活动状态，因为在该命令 之后又提交了新阶段的申请；通过检查五个真实的 GridLiance West 案卷 确认了这一点，如果采用天真的“是否有任何命令写着 GRANTED”检查，这些案卷 都会被错误删除。现已修复：要求最新裁决之后没有更晚的实质性文件 （排除送达名单等同日常规附属文件）。
    • 俄勒冈州的公用事业委员会也没有选址权限，与华盛顿州相同——真正的 主管机构是能源设施选址委员会 (EFSC)。不同寻常的是，它自己的两个 结构化状态字段都不可靠，而非只有其中一个：通过交叉比对全部 97 个追踪中的 设施确认，两者有 37 个不一致；每一项经抽查的不一致，都由自由文本叙述字段 正确解决，而至少一个结构化字段给出了错误结果。这里也是继 Grain Belt Express 之后，本系列第二个真正的跨州重复项：Cascade Renewable Transmission 是一条跨越哥伦比亚河的 400kV HVDC 输电线路，与华盛顿州 EFSEC 中现有条目属于同一个实体项目；通过 manualOverrides.csv 将其 合并为一行，同时保留两个州的来源链接。
    • 马萨诸塞州也有独立于 DPU 的真实选址委员会 (EFSB)，结构与华盛顿州/ 俄勒冈州相同——经核查确认，而非想当然地认为；DPU 自身的 "Siting" 案卷流程大多只是已由本项目覆盖的 EFSB 案卷的配套申报。真实证书获批多年 后，其自身的 "Closed Date" 字段仍可能保持 null（案卷会无限期收到批准后 的合规文件）——因此改为扫描每份已提交文件自身的类型，查找 "Final Decision"，并与以相反方式结案的案件交叉核对（正式撤回通知，从未提交 最终裁决）。人工检查时发现了一次险些出错的情况：某案卷最近提交的文件是 "Notice of Withdrawal of Counsel"，表示律师退出案件，而非项目撤回—— 宽松的关键词匹配会错误地将其结案。
    • 俄克拉何马州根本没有通用 CPCN 流程——其自身的 "CCN" 救济类型几乎 完全用于电信运营商（抽样的约 60 份真实申报中，没有一份与电力有关）。 真正相当于电力选址的流程，是《高压输电线路选址法》下更狭窄的证书；自 该州影像文档系统于 2022 年启用以来，只有 4 个案件曾按该法律提交——截至 发布时，4 个案件都已结案，因此本模块今天正确地 upsert 零个项目；这是 经人工确认的真实结果，不是 bug。尽管如此，仍发现了真实陷阱：不同案卷类型 之间的案号并不唯一（只按案号搜索会悄悄合并两个不相关的案卷）；还有一个 真实案件的起始文件被书记员归为 "Other Document" 而非 "Application"， 因而被看似明显的文件类型过滤器完全漏掉。
    • 犹他州的情况也同样稀少：回溯至 1987 年的州内全部电力案卷历史中， 只有 12 个案卷是真正的新 CPCN 申请，而且 12 个都已获批——这是另一个 真实、经确认的零候选项结果（拥有犹他州几乎全部零售发电和输电业务的 PacifiCorp/Rocky Mountain Power，会通过定期的综合资源计划确认其资源 决策，而非逐个项目申请 CPCN 选址）。本项目没有 PDF 解析依赖，因此最终 命令——没有机器可读批准/拒绝字段的非结构化 PDF——通过 Node 内置 zlib 直接解压其 FlateDecode 内容流，再从原始 PDF 运算符中提取文本， 未添加新依赖。
    • 威斯康星州的同一个案卷案件类型代码涵盖两项法规——大型设施 CPCN (Wis. Stat. § 196.491) 和小型设施授权证书 (§ 196.49)——因此无需为 两者分别创建模块或搜索。其自身的 "Status" 字段实际上是记录保留周期标记， 而非案件裁决状态：两个已独立确认结案的案卷（一个自 2023 年起已并网， 另一个自 2019 年获批后不久就已投运）在 7 年多后仍都显示 "Active"。 真正的信号是已提交且标题为 "Final Decision" 的命令——通过一份标题本身 有拼写错误的真实案卷确认："Signed ad Served"；因此检测正则只匹配 "final decision"，而不匹配更完整的短语。
    • 肯塔基州是本系列中首个明显的状态信号确实可靠的州：我们针对真实案卷 从两个方向检查了案件搜索中的 "Include Closed" 筛选条件（一份多年未结、 且自 2022 年以来 PSC 没有采取任何行动的案件；一份已结案、并有真实 "Final Order Entered" 批准证书的案件），并将其用作主要信号；基于文本 的批准/拒绝扫描仅作为防御性次要检查。其自身的搜索范围问题则是：宽泛的 "Construct" 案件类型代码还涵盖新建总部大楼、AMI 部署、光纤/宽带建设 以及冷却塔改造，这些都不是发电/输电项目——通过要求出现真实建设项目相关 短语加以过滤。
    • 密苏里州在发布后确实需要修复问题；该问题是在本项目标准验证步骤中 发现的，而非留待生产环境处理：锚定匹配 "Order Approving Stipulation and Agreement" 的正则漏掉了真实标题变体，因为其中插入了修饰词 ("...Approving Third Stipulation..." / "...Approving Unanimous Stipulation...")；另一个信号——"Closing File"——既可能作为 "Order" 类型，也可能作为 "Notice" 类型文件提交，但原来的结案检查只扫描 "Order" 类型。这两个问题导致几份早在 2018/2019 年就已结案的案卷仍显示 为等待处理，直到运行后的数据质量检查对照实时数据库发现问题；修复两处后， 确认恰好移除了这些过期行，且未移除其他行。
    • 印第安纳州的问题是较轻微的安全漏洞，而非数据陷阱：其公开案卷搜索页 显示 Google reCAPTCHA 控件，但该控件只在页面自身的客户端 JS 中检查 ——门户 JS 跨域调用的真正后端搜索 API（一个独立的配套 Azure App Service）既不接收也不验证令牌，直接向其发送请求后确认了这一点。其 "Case Status" 字段经与已提交的 Final Orders 独立核对后证明可靠；进入 "Appealed" 阶段的案件会进入专门的 "litigation" 阶段，而不是像其他所有 已解决状态一样被删除，因为委员会的 Final Order 已存在，但仍在法院受到 挑战。
    • 新泽西州根本没有 CPCN 流程；最接近的两种机制是不同的两类案卷（一种 是依据 40:55D-19 作出的“对公众而言合理必要”认定，另一种是竞争性太阳能 激励计划的选址禁令豁免），由一个模块覆盖。真实的已批准案卷显示其自身的 "Case Status" 字段已过时九年，因此改为从最近一份委员会命令 PDF 自身的 文本中读取结案信息——使用 Node 内置 zlib 解压；本项目没有 PDF 解析 依赖，而犹他州模块（utPscDockets.ts）已经证明同一技术可行。
    • 马里兰州完全没有案件 "Status" 字段；“仍在等待”是通过扫描所有已提交 文件、查找具有裁决效力的委员会/公用事业法法官命令推断出来的。我们针对 全部 175 个真实案件（而非抽样）进行完整扫描校准，尝试并否决了四种不同的 启发式方法——真实的裁决命令措辞出乎意料地多样，包括有些文件除了命令 编号外完全没有描述性标题。运行后的实时数据库数据质量检查（本项目自身的 标准验证步骤，而非留待生产环境）发现了一个真实的县名提取 bug——一个 从“COUNTY”之前的大写单词中自由提取县名的正则，会把标题前面的文本也 扫进去，因为这些标题本身全为大写——已通过列出马里兰州 23 个真实县名的 白名单修复，并同时发现了一个真实的来源拼写错误（一份真实标题中将 "Dorchester" 拼成 "DORCESTER"）。
    • 康涅狄格州与华盛顿州、俄勒冈州和马萨诸塞州遵循同一规律：“真正的 选址主管机构并非表面上看起来的那个”——PURA 只是在康涅狄格州选址委员 会自身的流程中发表评论。CSC 根本没有可查询的案卷搜索，只有人工录入的 CMS 页面；其自身关于信息可能未及时更新的免责声明经人工核实属实：一份 于 2013 年获批的请愿，在 2026 年仍被列为未结事项；只有将每个候选项与 CSC 自身的历史 Decision and Order List 逐一交叉核对，才发现此问题。 项目自身的验证步骤还发现并修复了一个结构性 bug——不是解析错误：该模块 悄悄将已结案候选项从输出中完全排除，而不是将其作为已解决阶段的条目传出， 这意味着先前运行中已追踪、后来结案的项目不会被重新处理或删除 （common.ts 中的 upsertNormalizedProject 只有在项目以已解决阶段 传入时才会删除项目——它不会对比“之前追踪的全部项目，减去本次出现的 项目”）。现已修复：将每个已结案候选项都以 currentStage: "cancelled" 传入。
    • 西弗吉尼亚州将建设证书权限划分为一般 CPCN 和面向商业发电商的独立 选址证书，并带来了本系列迄今最丰富的真实 STATUS 数据集：确认发现真实的 否决、一份通过 ALJ 建议裁决结案且无需委员会另行下令的案件，以及确认发现 的假阳性（同一案卷中一项无关的 Pro Hac Vice 律师准入动议使用了 "granted" 一词，而结案正则会忽略该词）。发布前还发现了两个真实 bug： 一份混合天然气+太阳能申报被标记为 "solar"，因为燃料关键词按固定声明顺序 检查，而非按标题中实际首先出现的技术判断；以及康涅狄格州中发现的同一种 结构性“候选项消失”bug，不过此处的触发方式不同——西弗吉尼亚州自身的 案件搜索仅筛选 Active 案件，因此当某案卷的 Active 标记切换为 Closed 后，它就会从之后的所有搜索结果中消失，模块自身的结案检查甚至根本没有 机会运行，问题并非结案检查漏掉了它。现已修复：直接从数据库查询该来源先前 追踪的 matchKeys，与每次运行的活跃候选项列表对比，并为任何消失的项目 补入已解决占位记录。
    • 田纳西州是真正经确认的零产出来源，并非抓取遗漏：TVA 是免于 TPUC 证书管辖权的联邦机构，提供该州绝大多数电力；其约 150 家地方电力公司 根据 TVA 合同享有预先划定的独占供电区域——因此新进入者的电力 CCN 几乎 从不触发。人工扫描全部 160 个活跃案卷（而非抽样）后，找不到任何当前未结的 电力发电/输电/储能 CCN 候选项；所有真实的 CCN 类型标题都是扩展服务区域的 水务公司，或申请特许经营权的电信运营商。仍然保留该来源为实时来源，以便 “持续监视罕见事件”；本项目已对人口稀少的 ORNL 水电来源采用同一惯例。 尽管当前尚无会过时的记录，该来源也采用了与康涅狄格州/西弗吉尼亚州相同的 预防性“候选项消失”修复。
    • 加利福尼亚州首先需要排除看似最明显的机构：CPUC 自身的 "Proceeding Information Search" 是 Oracle APEX 应用，其真实搜索提交 流程由客户端 Dynamic Action 逻辑处理，普通 fetch() 无法触发——通过 两种方式确认了这一点（原始 POST 重放会被重定向，但搜索词实际上并不会被 保存；真实 Chromium 会话中，点击搜索从未到达实际的 postback 端点，输入的 内容两次都丢失）。没有 CAPTCHA，也没有登录墙——只是一个脆弱的、仅限 SPA 的界面，没有纯 HTTP 访问路径；按照本项目长期遵循的指导原则，正确做法 是暂缓处理，而不是强行接入。真正的准入机构是 CEC：它对 ≥50MW 热能/地热 电厂，以及自 AB 205 起的 ≥50MW 太阳能/风能项目和 ≥200MWh 储能项目拥有 专属管辖权，几乎所有大型项目都会向其申报，而非 CPUC。发布前发现了一个 假阳性：某地方空气管理区自身的 "Notice of Decision" 与 CEC 实际选址 决定无关，早期版本的结案正则会错误匹配此项；同时也发现了康涅狄格州/ 西弗吉尼亚州已有的同一种结构性“候选项消失”bug（CEC 自身的列表查询仅 涵盖 Under Review/Suspended Proceedings 状态）。
    • 新罕布什尔州是第四个真正经确认的“真正的选址主管机构不是显而易见的 公用事业委员会”案例（此前包括华盛顿州、俄勒冈州、马萨诸塞州和康涅狄格州）： RSA 162-H 将选址权限专属授予 Site Evaluation Committee，而 PUC 的 3 名委员仅占 SEC 法定 5 名成员中的 3 名——他们不能单独构成法定人数。 2025 年 12 月的重组将 SEC 自身的案卷记录迁移至 PUC 网站，并加上 "SEC" 前缀；这恰恰让人第一眼误以为“PUC 负责选址”。发布前发现了一个真实的假 阳性：一份因程序材料不完整而被“驳回”的案卷，通过关键词匹配读起来与最终 否决完全相同（"Application" + "Certificate" + "Rejecting" 均出现）， 但实际并非如此——通过一份真实案卷确认，该案卷在被“驳回”后又继续提交了 190 多份文件。还确认并记录了一个真实的访问工具陷阱：对任何 nh.gov 子域名 进行裸 curl GET 请求都会因 TLS 指纹被反机器人系统拦截，但通过 Node 自身的 fetch() 发送完全相同的请求（本模块和 Vercel 无服务器函数实际使用 的运行时），则会得到正常的 200 响应，无需特殊处理——这不是真正的访问 障碍，只是 curl 特有的误报警，特此记录，避免未来维护者将其误认为真正 的障碍。
    • 爱达荷州是本系列中较早采用真正结构化案件 Status 字段的州之一——但 由于一个真实的结构性原因，即便如此也不需要解析命令文件文本： common.ts 的 RESOLVED_STAGES 逻辑无论接收到 "approved" 还是 "cancelled"，都会以相同方式删除项目，因此案卷一旦结案，IPUC 自身的已结案/ 未结案区分就已足够——无论如何，本网站也无法明显地区分“获批”和“被否决”。 发布前通过将试运行输出与人工核实的数量对比，发现了一个真实正则 bug： 使用词边界的 \bcertificate\b 搜索悄悄排除了所有真实的 "CERTIFICATES OF..."（复数）标题，因为 "certificate" 与后面的 "s" 之间没有词边界——导致真实候选项从 4 个低估为 1 个；IPUC 自身的搜索框 在线使用时也独立证实了同一问题。还确认了一项真实的共同所有者重复记录 （两家公用事业公司各自就同一实体输电线路区段提交了自己的 CPCN），按照 本项目长期采用的不去重政策，仍保留为两行独立记录。
    • 内布拉斯加州根本没有投资者所有的电力公用事业公司（该州是唯一完全由 公共电力供电的州），PSC 对电力证书也没有管辖权——真正的主管机构是 Power Review Board，但该机构不提供任何形式的案件搜索工具或案卷数据库。“仍在 等待”完全根据委员会自身会议记录的文字推断。发布前通过实时数据库检查发现 并修复了两个真实的结构性 bug：争议案件的事实和结案情况可能分别出现在与 首次/最后一次提及不相邻的不同段落中——最初设计的“第一次提及 = 事实， 最后一次提及 = 状态”方案在两个方向上都判断错误，一次把真实案件的名称和 字段拼错，一次因为后续一个无关段落只是在转折句中顺带提到案号，就把实际 已获批的案件误判为仍在等待。截至发布时，所有 13 个符合范围的真实候选项 都已结案——内布拉斯加州案件量小且大多无争议，通常一次委员会会议就能 处理完毕；这是根据实时会议记录文本人工确认的真实“当前无待处理案件”结果， 并非抓取遗漏。
    • 路易斯安那州没有单独命名的 CPCN 法律——一个看似有希望的结果 La. R.S. 45:1503 实际上是 1968 年的电信法规，只有阅读法条原文才发现 这一真实的误判陷阱。真正的准入标准是持续采用的“认证”/“建设批准”案卷 惯例，并通过完整的真实 191 案卷样本校准，假阳性为零。新奥尔良市被排除在 外的结论经过确定性核实，而非想当然：Entergy New Orleans 从未出现在 LPSC 约 16,900 个案卷的任何位置，因为它只受市议会监管。LPSC 自身的 Status 字段在本系列各来源中失真的方式格外明显——即使真实批准命令已经 发布，案卷仍会保持 "Open" 数月或数年，因为 LPSC 会为批准后的合规监管 保持案卷开放。本项目自身的实时数据库验证步骤发现了模块最初校准时漏掉的 一个真实 bug：一份经确认的真实批准命令使用了弯引号 Unicode 撇号 ("Judge’s Recommendation")，而只匹配 ASCII 直撇号的正则悄悄漏掉了它， 导致已结案案卷被错误地显示为仍在等待。
    • 阿拉巴马州有 CPCN 法律，但并非专门针对电力——电、气、水和蒸汽公用 事业共用一组连续的案卷编号，因此范围筛选完全依赖客户端内容过滤，不像大多 数相邻州那样依靠专用案卷代码前缀。我们发现了一个真实的全文搜索索引漏洞， 它会导致本网站最关注的那类刚提交不久的案卷系统性地不可见：Alabama Power 当前一宗真实的 "Lindsay Hill" 发电站 CPCN（2025 年获批）在长达 26 年的 回溯范围内都没有出现在短语搜索结果中；通过三种不同方式确认，其中包括 全站搜索该案卷自身有拼写错误的用语。现已修复：增加了基于结构化元数据 （公司名称 + 提交日期）的独立发现路径，而非全文搜索；鉴于已确认 Alabama Power 实际上是电力发电/输电 CPCN 申请的唯一真实申请方，因此将此路径限定 于该公司。此外，还发现了一种新形式的真实“候选项消失”bug：内容过滤条件 收紧之前 upsert 的两个假阳性，会永远留在数据库中，因为基于内容的排除 （与之前各州由状态筛选触发的同类 bug 不同）不会在后续运行中自然重新检查 已追踪的行。现已采用相同方式修复：比较本次运行中所有作出明确判断的 matchKey（无论是被传入还是被明确排除）与最终实际 upsert 的记录。 扩大上述三十一个州中任何州的覆盖范围，或者并行评估已确认可行的其他研究 线索（北卡罗来纳州也可行，但需要有状态的会话/postback 计数器流程，以及 能适应 Cloudflare 的请求标头，工程投入确实更多；宾夕法尼亚州、佐治亚州、 明尼苏达州、密歇根州、堪萨斯州、爱荷华州、蒙大拿州和密西西比州仍暂缓处理 ——PA 的搜索结果没有标题字段；GA 虽有该字段，但服务器端已损坏，始终返回 完整未筛选的结果；明尼苏达州整个 eDockets/eFiling 平台都位于启用中的 Cloudflare Turnstile CAPTCHA 或账户登录之后，完全没有未认证访问路径； 密歇根州真正的案卷搜索是 Salesforce Experience Cloud 应用，其数据只能 通过内部 Aura RPC 端点加载——这种访问模式被记录为 2025-26 年针对配置 错误的 Salesforce 组织进行大规模抓取的技术，对本项目而言不值得冒险；而且 其唯一纯 HTTP 回退路径没有标题字段，除非新增 PDF 解析依赖；堪萨斯州旧版 纯 HTTP 案卷门户 (estar.kcc.ks.gov) 已于 2025 年 11 月彻底停用，由 "KCC-Connect" 取代；该网站与密歇根州的网站同属 Salesforce Aura Community 站点，已通过其 robots.txt、响应标头，以及没有服务器渲染案卷数据、仅返回 不含内容的 Aura 加载框确认；但与密歇根州还保留部分回退路径不同，堪萨斯州 已完全没有纯 HTTP 回退路径；爱荷华州的 Electronic Filing System (efs.iowa.gov，于 2023 年重新发布的 Angular SPA，后端是真实的 REST API）可通过其自身公开的查找表端点确认确切的 CPCN 对等范围（Generating Certificate Utility 案件类型，以及单独的 Chapter 478 电力特许经营流程； 后者还提供 countyIds 筛选条件，完全可以绕过爱荷华州 99 个县的白名单 问题），但每个案卷/特许经营搜索视图和详情端点都会返回真正由后端强制执行 的 HTTP 401，要求登录账户——这是实际的身份验证墙，而不只是前端保护；直接 请求 API 后确认了这一点；蒙大拿州有两个真实的潜在主管机构，都已确认不可行： PSC 的现代案件系统 (REDDI，已迁移至 Pega Constellation) 在登录前设有实时 CAPTCHA，且其自身的 "Continue as Guest" 选项只存在于 HTML 注释中，由 客户端 JS 渲染，无法通过纯 fetch() 获取；其旧版纯 HTML 前身系统已全部 停用（连接重置/404）。另一个真实的选址主管机构是 DEQ 的《大型设施选址法》 (Major Facility Siting Act)；遵循本系列华盛顿州/俄勒冈州/马萨诸塞州/ 康涅狄格州的先例，发现大型输电/输油气管道项目实际由 DEQ 而非 PSC 负责。 完全无需身份验证即可访问，但符合范围的项目总共只有 1 个，而且没有任何 案号、搜索或历史档案可用于校准状态启发式方法——其数据甚至比本系列现有 数据最少的已发布来源还少，也更难核实；密西西比州真正的案卷系统 (ctsportal.psc.ms.gov，与 laPscDockets.ts 已成功导入数据的底层 "Valence" 平台相同) 目前无法使用，存在实时且可复现的后端 bug：所有与案卷 相关的端点都会返回 HTTP 500，原因是 MPSC 自身应用服务器与内部 REST API 依赖之间的 TLS 握手失败；已针对 4 个不同的真实案号进行确认，并在数分钟 的多次重试中复现，而同一服务器上的非案卷类兄弟搜索端点却返回正常的 200 响应——这是 MPSC 自身基础设施的运维故障，而非结构性访问障碍；值得几周后 快速重新检查，而非永久排除（密西西比州自身的备用社区门户仅使用 Salesforce Aura，与堪萨斯州/密歇根州属于同类障碍，因此目前无法用作替代方案）），都是真正 可考虑的后续选项——每个选项都必须像本项目一贯坚持的那样，先确认、再判断， 一次处理一个州（以及一个范围/状态决策），不能假设调查结果可以推广到其他州。 2026-08-25 重新确认：佐治亚州的搜索错误确实存在（针对其案卷筛选 API 的实时 title=/description= 查询会在服务器端被悄悄忽略，无论搜索词是什么，始终 返回相同的、未经筛选的约 3,000 条电力行业记录）——即使不考虑该错误，对这 个未筛选的数据群体进行完整扫描后，也发现佐治亚州根本没有可供搜索的逐项目 证书案卷：发电项目新增内容被打包进 Georgia Power 定期提交的多年综合资源 计划中；找到的个别 "Construction Monitoring" 案卷（Vogtle 3&4、Bowen CC、Wansley CC）都是批准后的合规监管案卷，而非许可审批本身——这里不存在 像本系列其他各州那样“一个待审批项目对应一个案卷”的明确单位；这是除了搜索 错误之外，佐治亚州继续暂缓处理的第二个独立理由。同一天还确认了另外两个真正 走不通的案例：怀俄明州的 Industrial Siting Division（经确认的真正选址 主管机构——依据 W.S. 35-12-101 等规定，由 DEQ 而非 PSC 负责）在其网站上 完全没有任何可浏览的待审申请列表——没有 PDF 公告、没有搜索表单、没有结构化 案卷页面；已检查网站上的每个真实页面（许可、ISD 公告、选址委员会、网站文档 搜索、通用门户）；这是“没有可查询系统”的真实障碍，而非访问问题。 夏威夷州的 PUC 案卷搜索 (hpuc.my.site.com/cdms) 使用 Salesforce Experience Cloud (Aura)，与上文堪萨斯州/密歇根州/密西西比州备用门户属于 同一类障碍，此外还设有实时 reCAPTCHA。

架构

• Next.js（App Router）+ TypeScript + Tailwind v4，单一应用。
• Prisma + Postgres（prisma/schema.prisma）——本地开发和生产环境共用一个托管实例；关于项目为何从 SQLite 迁出，请参阅未解决问题 #9。
• 地图使用 MapLibre GL JS——免费的 CARTO Voyager 矢量底图（无需 API 令牌），项目以普通 DOM 标记（maplibregl.Marker）渲染，根据容量调整大小，颜色统一。早期版本使用聚类 GeoJSON 数据源，并以 GL 圆形图层渲染，但该流程（由 worker 构建图块 + GL 重绘）在生产环境中无法稳定渲染；DOM 标记完全避开了这个问题，但代价是失去原生聚类功能——请参阅 src/components/Map.tsx 的 Git 历史。
• 筛选条件以 React 状态的形式保存在 src/components/Explorer.tsx 中，并通过一个唯一事实来源（src/lib/filters.ts）同时驱动地图和可排序的列表／表格视图，同时实时更新汇总统计数据（src/lib/stats.ts）。

项目架构

权威版本请参阅 prisma/schema.prisma。要点：原因类别（以及在 /policies 中倡导的政策）不是数据库表，而是 src/lib/data/causeCategories.ts 和 src/lib/data/policies.ts 中固定的小型代码审核集合。项目通过字符串 slug 关联原因，并在应用代码中验证，而不是使用数据库外键——新增原因类别或政策应当是审慎的产品／政策决策，而不是数据导入脚本可以悄然完成的操作。