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/DINSAR_ENHANCEMENT_TASKS.md

@@ -0,0 +1,426 @@
+# D-InSAR 增强 Task 文档
+
+更新日期：2026-03-13
+
+## 1. 文档目的
+
+这份文档用于统一管理本轮 D-InSAR 系统重构任务，覆盖以下两大方向：
+
+- D-InSAR 多引擎生产系统增强
+- D-InSAR 结果管理系统增强
+
+文档定位是“任务总表 + 实施边界 + 验收口径”，用于后续分阶段实施、联调和运维验收。
+
+## 2. 背景
+
+当前系统的 D-InSAR 生产能力主要绑定在 ENVI + SARscape 链路上，前端、后端任务模型、运行监控和结果入库都默认只有一个处理引擎。这会带来两个直接问题：
+
+- 客户如果没有 ENVI/SARscape license，D-InSAR 核心生产能力会直接失效。
+- 后续接入 ISCE2、LANDSAR 时，只能继续堆在现有 IDL/ENVI 语义上，导致架构持续恶化。
+
+同时，当前 D-InSAR 结果管理能力偏轻，更多是“结果浏览 + 缓存管理”，还不足以支撑多引擎、多版本、多产物、多轮生产的正式管理需求。
+
+## 3. 本轮目标
+
+### 3.1 生产系统目标
+
+- 将 D-InSAR 生产系统升级为“多引擎生产中心”
+- 正式支持两类可执行引擎：
+  - `sarscape`：ENVI + SARscape
+  - `isce2`：WSL 内部署的 ISCE2
+- 预留第三类引擎：
+  - `landsar`：仅保留接口和前端占位，不实现算法
+- 将运维自检升级为“系统级 + D-InSAR 专项级”双层检查
+
+### 3.2 结果管理目标
+
+- 将 D-InSAR 结果从“单文件记录”升级为“可追踪、可治理、可比对”的结果资产
+- 支持来源追踪、版本管理、多产物管理、审核状态和运维治理
+- 让结果管理适配多引擎场景，而不是继续依赖单一文件命名和单一路径假设
+
+## 4. 范围与非范围
+
+### 4.1 本轮范围
+
+- 多引擎 D-InSAR 后端抽象层
+- 新 D-InSAR 生产中心前端架构
+- ENVI/SARscape 的兼容接入
+- ISCE2 的 WSL 环境校验与运行接口
+- 运维自检与 D-InSAR 专项健康检查
+- D-InSAR 结果管理增强
+
+### 4.2 明确不在本轮范围
+
+- LANDSAR 算法实现
+- 对现有配对算法本身做大幅重写
+- 对 AI 诊断能力做独立重构
+- 一次性替换全部旧接口
+
+## 5. 现状要点
+
+### 5.1 ENVI 现有处理模式
+
+当前 ENVI 侧应明确建模为 `sarscape` 引擎下的两种 profile：
+
+- `metatask`
+- `custom6`
+
+其中 `custom6` 的 6 步链路为：
+
+1. Interferogram Generation
+2. Filtering and Coherence
+3. Orbital Trend Removal
+4. Phase Unwrapping
+5. GCP Generation + Refinement
+6. Phase to Displacement + Geocoding
+
+### 5.2 ISCE2 的特殊约束
+
+ISCE2 不走本机 Windows 直接执行链路，默认按 WSL 方式部署与运行，因此必须把 WSL 环境校验设计成正式能力，而不是上线前人工检查事项。
+
+### 5.3 当前结果管理主要短板
+
+- 结果记录字段偏少，缺少引擎来源、运行来源、版本、产物类型等核心字段
+- 结果入库逻辑仍偏向单文件扫描，不适合多引擎多版本
+- 前端结果面板偏重展示，缺少治理、比对、版本和来源追踪能力
+- 运维自检尚未覆盖结果资产层面的异常
+
+## 6. Task 总览
+
+| Task ID | 主题 | 目标 |
+|---|---|---|
+| T1 | 多引擎生产基座 | 建立统一的 D-InSAR 引擎抽象、调度和兼容层 |
+| T2 | 前端生产中心 | 将现有 IDL 自动化面板升级为多引擎生产中心 |
+| T3 | SARSCAPE 兼容接入 | 将现有 ENVI 链路适配到新抽象层 |
+| T4 | ISCE2 + WSL 接入 | 建立 ISCE2 的 WSL 检查、运行和日志链路 |
+| T5 | 运维自检增强 | 增加多引擎专项健康检查和自愈入口 |
+| T6 | 结果管理增强 | 将 D-InSAR 结果升级为正式结果资产管理体系 |
+
+## 7. 任务拆分
+
+### T1. 多引擎生产基座
+
+#### 目标
+
+- 将 D-InSAR 生产从 `IDL/ENVI 单引擎假设` 中抽离
+- 为 `sarscape`、`isce2`、`landsar` 建立统一抽象
+
+#### 关键任务
+
+- 定义统一引擎接口
+- 建立引擎注册表
+- 建立统一运行记录模型
+- 建立统一产物收集与入库接口
+- 保留旧 `/idl/...` 路由兼容转发能力
+
+#### 目标结构
+
+- `dinsar_engines/base.py`
+- `dinsar_engines/registry.py`
+- `dinsar_engines/sarscape_engine.py`
+- `dinsar_engines/isce2_engine.py`
+- `dinsar_engines/landsar_engine.py`
+- `dinsar_orchestrator.py`
+
+#### 验收标准
+
+- 新生产调度层可按 `engine_code` 分发
+- `sarscape`、`isce2`、`landsar` 均可在注册表中查询到
+- 旧 ENVI 生产功能不回归
+
+### T2. 前端生产中心
+
+#### 目标
+
+- 用统一生产中心替代当前单引擎 `IDLAutomationPanel`
+- 支持多引擎选择、运行监控、日志查看和结果入库操作
+
+#### 前端信息架构
+
+- 引擎状态区
+  - SARSCAPE
+  - ISCE2
+  - LANDSAR
+- 生产提交区
+  - 批次选择
+  - 引擎选择
+  - profile 选择
+  - 输入/输出目录
+  - 参数模板
+- 运行监控区
+  - 当前任务
+  - 步骤进度
+  - 运行日志
+  - 历史记录
+- 产物处理区
+  - 提取
+  - 入库
+  - 重扫
+  - 缓存重建
+
+#### 关键任务
+
+- 新建 `DinsarProductionPanel`
+- 废弃前端对 `/idl/...` 语义的直接依赖
+- 增加引擎状态卡和 WSL 状态卡
+- 运行记录中展示 `engine`、`profile`、`run_id`
+
+#### 验收标准
+
+- 前端可以清晰区分三类引擎状态
+- `landsar` 显示为预留，不可执行
+- 当 ENVI 不可用但 ISCE2 可用时，页面仍可提交 ISCE2 任务
+
+### T3. SARSCAPE 兼容接入
+
+#### 目标
+
+- 将现有 ENVI 链路正式纳入新生产体系
+- 明确 `metatask` 与 `custom6` 是同一引擎下的两个 profile
+
+#### 关键任务
+
+- 封装现有 ENVI 运行逻辑为 `sarscape_engine`
+- 将 `metatask` 和 `custom6` 暴露为 profile
+- 保留进度文件、日志、超时监控和历史运行能力
+
+#### 验收标准
+
+- 旧 ENVI 作业仍可执行
+- 新系统中可选择 `sarscape/metatask` 与 `sarscape/custom6`
+- 原有任务状态、日志和结果提取行为保持兼容
+
+### T4. ISCE2 + WSL 接入
+
+#### 目标
+
+- 建立 ISCE2 运行的正式环境检查、任务执行和输出接入能力
+
+#### WSL 环境校验任务
+
+- 检查 WSL 是否安装
+- 检查是否支持 WSL2
+- 检查目标 distro 是否存在
+- 检查目标 distro 是否可启动
+- 检查 `bash -lc` 是否可执行
+- 检查 Python 是否可执行
+- 检查 ISCE2 是否可 import
+- 检查目标入口命令是否可执行
+- 检查 DEM 路径在 WSL 内是否可读
+- 检查轨道目录在 WSL 内是否可读
+- 检查输出目录在 WSL 内是否可写
+- 检查 Windows 路径到 WSL 路径转换是否正确
+- 增加可选 smoke test
+
+#### 建议配置项
+
+- `ISCE2_ENABLED`
+- `ISCE2_WSL_DISTRO`
+- `ISCE2_PYTHON`
+- `ISCE2_PROFILE`
+- `ISCE2_DEM_PATH`
+- `ISCE2_ORBIT_DIR`
+- `ISCE2_WORK_ROOT`
+- `ISCE2_OUTPUT_ROOT`
+- `ISCE2_SMOKE_TEST_ENABLED`
+
+#### 关键任务
+
+- 新建 `wsl_service.py`
+- 新建 `isce2_engine.py`
+- 建立 WSL 执行和日志封装
+- 将 ISCE2 输出纳入统一结果收集和入库流程
+
+#### 验收标准
+
+- 前端可见 ISCE2 环境状态
+- WSL 校验结果可解释、可定位故障点
+- ISCE2 至少有一个正式 profile 可提交并跑通
+
+### T5. 运维自检增强
+
+#### 目标
+
+- 将当前“系统健康检查”升级为“系统级 + D-InSAR 专项级”双层运维自检
+
+#### 关键任务
+
+- 保留现有 `/health` 简版接口
+- 增加管理员详细健康接口
+- 增加多引擎专项检查
+- 增加 WSL 专项检查
+- 增加 D-InSAR 队列、存储、结果一致性检查
+- 增加自愈动作入口
+
+#### 专项健康检查项
+
+- 核心服务状态
+  - 数据库
+  - schema
+  - worker
+  - queue
+- 引擎状态
+  - `sarscape`
+  - `isce2`
+  - `landsar`
+- WSL 状态
+- DEM/轨道/输出目录可用性
+- D-InSAR 运行任务积压
+- stale run 检测
+- 输出未入库检测
+- 入库但源文件缺失检测
+- 缓存一致性检测
+
+#### 自愈入口建议
+
+- 重扫结果目录
+- 重建缓存
+- 重试入库
+- 重置 stale run
+- 标记失效结果
+
+#### 验收标准
+
+- 运维面板能区分系统级故障与引擎级故障
+- 当 ENVI 不可用但 ISCE2 可用时，总体 D-InSAR 服务状态应为 `degraded` 或 `ok`，不能直接判全系统失败
+- WSL 故障能定位到具体检查项
+
+### T6. 结果管理增强
+
+#### 目标
+
+- 将 D-InSAR 结果从“扫描到的一条文件记录”升级为“正式结果资产”
+
+#### 核心设计
+
+- `Run`
+  - 一次真实生产执行
+- `Artifact`
+  - 一次运行产出的具体文件
+- `Managed Result`
+  - 面向前端与业务的主结果对象
+
+#### 关键任务
+
+- 扩充结果模型字段
+- 增加结果来源追踪
+- 增加版本管理
+- 增加多产物管理
+- 增加结果生命周期状态
+- 增加批量治理能力
+- 增加多引擎结果对比能力
+
+#### 结果管理能力清单
+
+- 来源追踪
+  - engine
+  - profile
+  - batch
+  - pair
+  - run
+- 版本管理
+  - 当前版本
+  - 历史版本
+  - 最新成功版本
+- 多产物管理
+  - disp
+  - coherence
+  - unwrapped phase
+  - geotiff
+  - browse
+  - log
+- 生命周期管理
+  - `NEW`
+  - `INGESTED`
+  - `QC_PENDING`
+  - `QC_PASSED`
+  - `QC_REJECTED`
+  - `PUBLISHED`
+  - `ARCHIVED`
+- 批量操作
+  - 发布
+  - 归档
+  - 重扫
+  - 重建缓存
+  - 重绑定来源
+  - 导出
+- 检索增强
+  - 按引擎
+  - 按批次
+  - 按任务名
+  - 按状态
+  - 按 AOI
+  - 按版本
+
+#### 前端结果管理架构建议
+
+- 结果列表视图
+- 结果详情视图
+- 来源与版本视图
+- 治理与运维视图
+
+#### 运维治理项
+
+- 入库记录存在但源文件缺失
+- run 存在但 artifact 缺失
+- 当前版本指针异常
+- 同名结果冲突
+- 缓存与主文件不一致
+- 已发布结果未完成审核
+
+#### 验收标准
+
+- 同一对影像允许保留多引擎结果
+- 同一任务允许保留多版本
+- 结果详情页能追踪到来源 run 和主产物列表
+- 运维面板可识别结果资产层异常
+
+## 8. 实施顺序
+
+### Phase 1
+
+- 完成多引擎与结果管理设计冻结
+- 完成接口契约
+- 完成数据模型草案
+
+### Phase 2
+
+- 实现后端抽象层
+- 完成 SARSCAPE 兼容接入
+- 保持旧接口兼容
+
+### Phase 3
+
+- 实现新前端生产中心
+- 实现引擎状态、运行监控和运维自检增强
+
+### Phase 4
+
+- 接入 ISCE2 + WSL
+- 打通首条正式生产链
+
+### Phase 5
+
+- 实现结果管理增强
+- 补齐版本、来源、治理与自愈
+
+## 9. 交付顺序建议
+
+建议按照以下顺序落地：
+
+1. 先重构生产抽象层，不先碰最终结果治理细节
+2. 先让 `sarscape` 在新体系下跑通
+3. 再接入 `isce2`
+4. 最后再把结果管理全面升级
+
+这样可以避免在“生产链尚未稳定”时提前锁死结果模型细节。
+
+## 10. 当前结论
+
+本轮不应被理解为“给当前 ENVI 面板再加一个 ISCE2 按钮”，而应被理解为：
+
+- D-InSAR 生产系统平台化
+- D-InSAR 结果资产化
+- 运维自检从系统健康升级为多引擎专项健康
+
+后续所有开发任务、联调任务和运维验收，均以本 Task 文档为总入口。