docs: govern and archive superseded notes

- add documentation governance and cleanup audit documents

- update README and docs index to distinguish current vs historical sources

- move superseded planning, SBAS, Gamma, and experiment notes into docs/archive

- fix remaining archive text garbling in two documents

docs/archive/项目汇报.md

@@ -0,0 +1,403 @@
+# InSAR 管理系统项目汇报
+
+版本日期：2026-03-13
+
+## 一、汇报目的
+
+本文用于项目汇报和方案评审，重点说明三件事：
+
+1. 当前 InSAR 管理系统的建设内容和系统价值。
+2. 系统在 D-InSAR 生产侧已经形成的技术架构与扩展能力。
+3. 如何将 LANDSAR 系统作为第三个 D-InSAR 生产核心嵌入本系统，以及这件事对采购方案的直接影响。
+
+本文是单独汇报材料，强调整体把握、系统边界、实施路径和采购判断，不展开到底层代码细节。
+
+## 二、项目总体定位
+
+本项目不是单一的数据展示平台，而是一个面向 InSAR 业务的综合管理与生产支撑平台，核心目标是把“数据入库、生产组织、结果管理、运行监控、质量分析”放到同一套系统中统一管理。
+
+从业务定位看，系统承担了以下角色：
+
+1. 数据管理平台：统一管理雷达源数据、轨道数据、D-InSAR 结果、水体监测结果等。
+2. 生产组织平台：支持配对、批次管理、任务下发、后台处理、结果回收。
+3. 运维监控平台：支持健康检查、任务状态、日志、鉴权、许可证控制。
+4. 分析辅助平台：支持 AI 质量分析、AI 诊断、统计看板、地图可视化。
+
+因此，这个项目的价值不只是“能不能跑一次处理”，而是把整个业务流程固化为可持续运行的平台能力。
+
+## 三、当前系统建设情况
+
+### 3.1 技术架构
+
+当前系统采用前后端分离架构：
+
+1. 前端：React + Vite，使用 Leaflet 负责地图展示，Chart.js 负责统计图表，Zustand 负责状态管理。
+2. 后端：FastAPI 提供 REST API，SQLAlchemy 负责 ORM，Pydantic 负责数据模型校验。
+3. 数据库：PostgreSQL + PostGIS，用于业务数据存储和空间能力支撑。
+4. 后台任务：独立 Job Worker 进程，负责执行扫描、生产、AI、解包等异步任务。
+5. 部署入口：Nginx 负责前端静态资源和反向代理。
+6. 外部能力：可选接入 ENVI/SARscape、ISCE2、Ollama 等外部组件。
+
+### 3.2 主要功能模块
+
+系统目前已经具备较完整的业务模块：
+
+1. 雷达数据管理
+   支持监控目录扫描、元数据解析、预览图生成、空间范围展示、检索和分页浏览。
+2. 轨道数据管理
+   支持轨道文件关联和本地轨道池同步，为生产链路提供基础输入。
+3. 配对与批次管理
+   支持 D-InSAR 配对策略、批量任务组织、批次项管理和后续复制导出。
+4. D-InSAR 生产中心
+   已经从单引擎思路升级为多引擎生产中心，支持统一查看引擎状态、提交任务、查看运行记录。
+5. D-InSAR 结果管理
+   支持结果扫描入库、地图展示、缓存、导出、AI 评分与人工标注。
+6. AI 能力
+   支持质量模型训练、质量预测、影像诊断、报告生成。
+7. 水体监测
+   已形成相对独立的处理链路和界面。
+8. 运维与权限
+   包含健康检查、任务管理、审计日志、用户管理、登录限流、许可证控制等。
+
+### 3.3 当前系统成熟度判断
+
+从工程状态看，项目已经不是原型阶段，而是进入“可持续扩展的平台阶段”：
+
+1. 业务边界已明确。
+2. 前后端结构已稳定。
+3. 后台任务与数据库模型已成体系。
+4. 多引擎 D-InSAR 生产框架已经搭起来。
+5. 系统具备继续接入第三方生产核心的基础。
+
+这意味着后续采购不应再按“买一个孤立的软件工具”来考虑，而应按“纳入统一生产平台的外部生产核心”来考虑。
+
+## 四、系统运行主线
+
+从全流程看，当前系统的主线可以概括为：
+
+1. 数据进入系统
+   扫描雷达目录、轨道目录、结果目录，完成入库和索引。
+2. 用户在前端组织任务
+   选择 AOI、筛选源数据、执行配对、形成批次、下发生产任务。
+3. 后端进入异步处理模式
+   系统创建任务记录和作业记录，由 Worker 执行具体处理。
+4. 外部引擎执行生产
+   当前已支持 ENVI/SARscape 和 ISCE2 两类生产能力。
+5. 结果回流系统
+   产物落地后可扫描入库、生成缓存、展示到地图和列表，并进入后续分析。
+6. 运维与质量闭环
+   通过健康检查、日志、审计、AI 分析和人工核查，形成可运维闭环。
+
+这一主线决定了本系统天然适合接入多个生产引擎，只要外部引擎能被标准化调用。
+
+## 五、D-InSAR 生产体系现状
+
+### 5.1 已形成的多引擎框架
+
+当前项目已经不再把 D-InSAR 生产写死在某一套工具链上，而是抽象成统一的“生产引擎”框架。对每个引擎，系统要求至少具备三类能力：
+
+1. 可用性检查：系统要知道该引擎当前能不能用。
+2. Profile 列表：系统要知道该引擎支持哪些处理链路。
+3. 统一运行入口：系统要能按同样的方式下发任务并接收结果。
+
+在这个框架下，系统现在已有三类引擎标识：
+
+1. `sarscape`
+   已可运行，对接现有 ENVI/SARscape 流程。
+2. `isce2`
+   已可运行，通过 WSL 调用 ISCE2 链路。
+3. `landsar`
+   目前仅做接口预留和前端占位，尚未真正接入生产能力。
+
+### 5.2 当前已落地的两个生产核心
+
+#### 1. ENVI / SARscape
+
+这是当前系统最成熟的生产核心，主要特点：
+
+1. 与现有历史流程兼容度高。
+2. 支持 `metatask` 和 `custom6` 两种 profile。
+3. 已具备运行、日志、结果回收和健康检查能力。
+4. 适合作为当前生产主力链路。
+
+#### 2. ISCE2
+
+这是当前系统第二个生产核心，主要特点：
+
+1. 通过 WSL 方式运行，避免强依赖本机 Windows 图形环境。
+2. 已具备环境检查、路径转换、脚本调用、任务执行能力。
+3. 适合承接 LT-1 等标准化链路。
+4. 为系统后续接入更多异构引擎提供了样板。
+
+### 5.3 LANDSAR 当前状态
+
+这一点在汇报和采购中必须明确说明：
+
+截至 2026-03-13，`LANDSAR` 在本项目中属于“架构已预留、能力未接入”的状态，具体表现为：
+
+1. 后端已存在 `landsar` 引擎占位。
+2. 前端生产中心已预留 `LANDSAR` 状态卡位置。
+3. 健康检查体系已将 `LANDSAR` 视为可纳入统一监控的引擎类型。
+4. 轨道池体系中已预留 `ORBIT_POOL_LANDSAR` 的配置位置。
+5. 但任务提交、执行、日志、结果回收尚未真正实现。
+6. 当前生产提交接口实际仍只支持已落地的引擎，`LANDSAR` 还不能像现有生产核心那样直接投入运行。
+
+这意味着：系统架构已经准备好接纳 LANDSAR，但采购后的接入工作仍需要正式实施，不能误判为“买来即可无缝运行”。
+
+## 六、为什么要把 LANDSAR 作为第三个生产核心
+
+从平台演进角度，引入 LANDSAR 的意义主要有四点：
+
+1. 降低对单一商业引擎的依赖。
+2. 提升不同场景下的处理适配能力。
+3. 形成多引擎并行的生产格局，增强方案弹性。
+4. 使采购的软件能力真正纳入平台统一调度，而不是形成新的信息孤岛。
+
+如果 LANDSAR 只是作为独立软件单独运行，那么它对现有系统的价值有限，最终仍然会回到“人工切换工具、人工导入结果、人工追踪过程”的旧模式。只有把它嵌入本系统，成为第三个生产核心，采购价值才能最大化。
+
+## 七、LANDSAR 接入的目标定位
+
+本项目对 LANDSAR 的目标定位不是“重写 LANDSAR 算法”，而是“把 LANDSAR 系统现有 D-InSAR 生产服务纳入统一调度平台”。
+
+因此，推荐的定位是：
+
+1. 本系统负责任务组织、权限控制、日志审计、状态展示、结果入库和运维闭环。
+2. LANDSAR 系统负责实际 D-InSAR 生产处理。
+3. 双方通过标准接口交互，而不是把两边代码强行揉成一体。
+
+这也是最符合采购落地的模式，因为它对供应商最明确，对我方平台风险最可控。
+
+## 八、LANDSAR 与本系统的推荐交互模式
+
+### 8.1 推荐模式：服务嵌入式接入
+
+建议将 LANDSAR 以“外部生产服务”的方式接入本系统，而不是以人工操作方式接入。
+
+推荐架构如下：
+
+1. 用户仍然只在本系统前端操作。
+2. 用户在 D-InSAR 生产中心中选择 `LANDSAR` 作为引擎。
+3. 本系统后端创建标准任务和作业记录。
+4. `landsar` 适配引擎把任务参数发送给 LANDSAR 生产服务。
+5. LANDSAR 返回运行编号并执行处理。
+6. 本系统轮询任务状态，或者接收 LANDSAR 回调通知。
+7. 处理完成后，产物输出到约定目录，或由本系统拉取到指定目录。
+8. 本系统完成结果扫描、入库、展示和后续分析。
+
+这样做的最大好处是：对用户来说，LANDSAR 不是另一套系统，而是本系统中的第三个生产核心。
+
+### 8.2 不推荐模式：纯人工导入导出
+
+如果采购的 LANDSAR 只能做到“人工打开软件、手工点运行、手工拷贝结果”，则它不能真正成为第三个生产核心，只能成为一个外部工具。这样会带来以下问题：
+
+1. 无法统一任务状态。
+2. 无法统一日志与审计。
+3. 无法统一批次管理。
+4. 无法纳入健康检查。
+5. 无法形成稳定的生产闭环。
+
+因此，采购时必须把“可集成、可调用、可监控”作为硬条件。
+
+## 九、LANDSAR 接入后的业务流程
+
+建议将接入流程设计为以下八步：
+
+1. 任务组织
+   用户在本系统完成配对、批次选择、AOI 约束和参数选择。
+2. 任务提交
+   本系统向 LANDSAR 服务提交标准化请求，包括输入目录、输出目录、profile、处理参数、任务编号等。
+3. 运行登记
+   本系统保存本地任务 ID 和 LANDSAR 侧运行 ID 的映射关系。
+4. 执行监控
+   本系统通过轮询接口或回调机制获取进度、状态和错误信息。
+5. 日志采集
+   本系统读取 LANDSAR 返回的执行日志摘要，必要时保留完整日志文件地址。
+6. 产物回收
+   LANDSAR 将产物输出到双方约定目录，或通过下载接口交给本系统。
+7. 结果入库
+   本系统对产物进行扫描、索引、缓存生成和结果入库。
+8. 统一展示
+   用户在现有结果管理界面中查看 LANDSAR 结果，与其他引擎结果统一管理。
+
+## 十、LANDSAR 作为第三核心时的系统改造点
+
+从本系统角度，真正需要做的改造不是推倒重来，而是在现有多引擎框架上补全 `landsar` 适配层。
+
+### 10.1 后端改造点
+
+1. 完成 `landsar_engine.py`
+   目前这个文件只是占位，需要实现真正的可用性检查、profile 获取和运行逻辑。
+2. 增加 LANDSAR 任务处理器
+   可以新增独立 `JOB_TYPE_LANDSAR_RUN`，也可以复用统一外部引擎作业模式。
+3. 增加运行状态映射
+   需要把 LANDSAR 的状态映射到本系统统一状态，如 `PENDING`、`RUNNING`、`COMPLETED`、`FAILED`。
+4. 增加日志采集与错误归一化
+   要保证前端看到的日志和错误信息可理解、可追踪。
+5. 增加结果回收逻辑
+   需要把 LANDSAR 输出目录纳入结果扫描与入库体系。
+6. 补充轨道池适配
+   当前系统已预留 `ORBIT_POOL_LANDSAR`，采购后需明确 LANDSAR 轨道格式和同步策略。
+
+### 10.2 前端改造点
+
+1. 让 `LANDSAR` 状态卡从“预留”变成“可选可提交”。
+2. 展示 LANDSAR 专属 profile 和参数项。
+3. 在运行历史中显示 `engine=landsar`。
+4. 在结果列表和详情中标识结果来源于 LANDSAR。
+
+### 10.3 运维改造点
+
+1. 增加 LANDSAR 服务健康检查。
+2. 增加供应商服务连通性检查。
+3. 增加回调鉴权或调用鉴权。
+4. 增加 LANDSAR 结果目录一致性检查。
+
+## 十一、采购时必须明确的接口要求
+
+这一部分是采购方案的核心。若这些能力得不到保障，LANDSAR 就无法真正嵌入平台。
+
+### 11.1 必须具备的调用方式
+
+供应商至少应提供以下三种方式之一，优先级从高到低如下：
+
+1. HTTP/REST 服务接口
+   最推荐，最适合平台接入。
+2. 命令行接口（CLI）
+   可作为次优方案，但需要明确返回码、日志和输出目录约定。
+3. Python/SDK 接口
+   也可接受，但后续部署和版本兼容成本通常更高。
+
+如果三者都没有，只提供 GUI 操作，则不建议作为“第三生产核心”采购。
+
+### 11.2 必须具备的最小接口能力
+
+若采用服务接口，建议采购时要求至少提供以下能力：
+
+1. 提交任务接口
+   输入参数包括任务编号、profile、输入目录、输出目录、处理参数。
+2. 查询任务状态接口
+   能返回排队、运行中、完成、失败、取消等状态。
+3. 查询进度接口
+   能返回百分比或阶段性进度。
+4. 查询日志接口
+   至少能返回日志摘要，最好支持完整日志文件。
+5. 查询产物接口
+   能返回主产物、辅产物、日志文件、质量文件等路径或下载地址。
+6. 健康检查接口
+   能返回服务可用性、许可证状态、核心依赖状态。
+7. 能力枚举接口
+   能列出当前支持的 profile、版本、约束条件。
+
+### 11.3 必须明确的数据约定
+
+采购时要和供应商约定清楚以下数据边界：
+
+1. 输入目录结构由谁负责准备。
+2. 输出目录结构是否固定。
+3. 主结果文件命名规则是否稳定。
+4. 日志文件命名规则和保存期限。
+5. 失败任务是否保留中间文件。
+6. 轨道文件格式和目录组织方式。
+7. 坐标系、DEM、投影和元数据约定。
+
+没有这些约定，后续集成必然出现反复沟通和返工。
+
+## 十二、建议的采购技术条款
+
+为了确保 LANDSAR 真正能嵌入本系统，建议采购文件中写入如下技术条款。
+
+### 12.1 必选条款
+
+1. 供应商须提供可编程调用接口，不得仅提供人工图形界面。
+2. 供应商须提供任务提交、状态查询、日志查询、结果获取的完整接口说明。
+3. 供应商须支持与第三方业务系统进行集成，并配合联调。
+4. 供应商须提供稳定的版本管理和升级兼容说明。
+5. 供应商须明确许可证机制对服务化调用的限制条件。
+6. 供应商须配合完成至少一个标准 D-InSAR 生产 profile 的端到端联调验收。
+
+### 12.2 强烈建议条款
+
+1. 支持回调通知机制，减少轮询压力。
+2. 支持独立健康检查接口。
+3. 支持 profile 枚举和参数模板查询。
+4. 支持输出标准化目录结构。
+5. 支持服务部署在内网服务器环境。
+6. 支持批量任务执行和失败重试。
+
+### 12.3 验收建议
+
+建议把验收拆成两个层次：
+
+1. 集成验收
+   能在本系统中完成 LANDSAR 任务提交、状态查看、日志查看、结果入库。
+2. 业务验收
+   能稳定完成至少一个真实生产样例，并在前端完成统一展示。
+
+### 12.4 采购方案分级建议
+
+为了避免采购完成后无法嵌入现有系统，建议把采购方案分成三档判断：
+
+1. 推荐方案
+   采购“LANDSAR 服务接口版 + 联调实施服务 + 服务化许可”。
+   该方案要求供应商提供 API 或等价服务接口，并配合完成与本系统的任务、状态、日志、结果联通。这是最符合“第三生产核心”目标的方案。
+2. 可接受方案
+   采购“LANDSAR CLI/SDK 版 + 本地部署支持 + 接口适配支持”。
+   该方案在没有标准服务接口时仍可落地，但后续部署、升级、兼容和运维成本会明显高于推荐方案。
+3. 不建议方案
+   仅采购“LANDSAR 桌面 GUI 单机版”。
+   该方案无法稳定嵌入本系统，只能形成独立工具，难以支撑统一任务管理、日志审计和结果治理，不建议作为本项目采购目标。
+
+## 十三、LANDSAR 接入对采购决策的影响
+
+这一点需要在汇报中重点强调：
+
+采购 LANDSAR，不是单纯采购一个处理软件，而是在采购本系统的第三个生产核心。
+
+因此，采购判断应从以下维度展开：
+
+1. 不只是看算法效果，还要看是否可集成。
+2. 不只是看桌面端能不能跑，还要看服务端能不能调。
+3. 不只是看一次能不能出结果，还要看能否纳入长期运维。
+4. 不只是看供应商交付软件，还要看是否交付接口和联调能力。
+
+如果采购时忽略这些条件，后续极有可能出现“软件买到了，但无法嵌入现有平台”的情况，导致采购价值被打折。
+
+## 十四、建议的实施路径
+
+建议分两步推进：
+
+### 第一阶段：完成服务嵌入
+
+目标是让 LANDSAR 先成为“可调度、可监控、可回收”的第三生产核心。
+
+重点工作：
+
+1. 完成接口对接。
+2. 完成任务状态联通。
+3. 完成日志与结果回流。
+4. 完成前端选择与展示。
+
+### 第二阶段：完成深度治理
+
+目标是把 LANDSAR 结果纳入更完整的统一治理体系。
+
+重点工作：
+
+1. 结果版本管理。
+2. 多引擎结果对比。
+3. 质量评价与复核闭环。
+4. 更细粒度的运行审计和运维检查。
+
+这样推进的好处是先把采购价值尽快落地，再逐步做深，而不是一开始就把目标定得过重。
+
+## 十五、结论
+
+综合判断如下：
+
+1. 当前 InSAR 管理系统已经具备平台化能力，适合承接第三方 D-InSAR 生产核心。
+2. 系统的多引擎架构已经形成，`LANDSAR` 不是从零开始接，而是在既有框架中补齐适配层。
+3. 截至目前，`LANDSAR` 在系统中仍是预留状态，尚未真正接入生产执行。
+4. 因此，采购方案必须把“可编程调用、可集成、可监控、可回收”写成明确要求。
+5. 最推荐的采购与实施方式，是将 LANDSAR 以外部生产服务的形式嵌入本系统，作为第三个 D-InSAR 生产核心统一调度。
+
+一句话概括：本项目当前已经具备“接入第三生产核心”的平台基础，下一步采购是否成功，关键不在于是否购买到一个能跑的工具，而在于是否购买到一个能够被本系统稳定接入的服务化能力。