Checkpoint production workflow updates

docs/DEM_PRODUCTION_SOURCE_CONTRACT_20260628.md

@@ -0,0 +1,52 @@
+# DEM Production Source Contract (2026-06-28)
+
+## Decision
+
+New production should use `D:\DEM\SRTMDEM_RSP_SARscape` as the common DEM source family unless a task explicitly declares another DEM in its manifest. The system should not mix SRTM, COPDEM, GMTED, and the interpolated Heilongjiang 10 m DEM silently.
+
+This does not mean every engine reads the same physical file. The same SRTM source is maintained in several engine-compatible forms:
+
+| Role | Path | Format | Intended consumers |
+| --- | --- | --- | --- |
+| SARscape/ENVI source | `D:\DEM\SRTMDEM_RSP_SARscape` | ENVI/SARscape float32 binary with `.hdr` | `IDL_DINSAR_DEM_BASE_FILE`, `GF3_SARSCAPE_DEM_PATH` |
+| WGS84 prepared source | `D:\DEM\SRTMDEM_RSP_SARscape.wgs84` | ENVI float32 binary/VRT-readable raster | `ISCE2_DEM_PATH`, `PYINT_PREPARED_DEM_PATH`, `SAR_ANALYSIS_DEM_PATH`, `GAMMA_SBAS_DEM_PATH`, `TIMESERIES_DEM_PATH` |
+| Int16 GeoTIFF source | `D:\DEM\SRTMDEM_RSP_SARscape_global_int16.tif` | GeoTIFF int16 | `LANDSAR_DEM_PATH`, `LANDSAR_SBAS_DEM_PATH`, GDAL/RPC-style GeoTIFF consumers such as `GF3_GEO_DEM_PATH` |
+
+The LT-1 single-scene production profile uses a 30 m analysis grid. Product manifests must still record the selected SRTM-derived source file, the cropped/converted DEM path, the actual Gamma DEM spacing, the derived `dem_lat_ovr`/`dem_lon_ovr`, and the configured target grid so reviewers can distinguish the source DEM family from the output grid.
+
+The LT-1 single-scene profile also performs multilook and speckle filtering before registering the final analysis GeoTIFF. The production manifest must record `SAR_ANALYSIS_RANGE_LOOKS`, `SAR_ANALYSIS_AZIMUTH_LOOKS`, and the speckle filter method/window so reviewers can reproduce the output pixel statistics.
+
+## Current Configuration
+
+The current server should use:
+
+```env
+IDL_DINSAR_DEM_BASE_FILE=D:\DEM\SRTMDEM_RSP_SARscape
+GF3_SARSCAPE_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape
+
+ISCE2_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84
+PYINT_PREPARED_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84
+SAR_ANALYSIS_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84
+SAR_ANALYSIS_DEM_RESOLUTION_M=30.0
+SAR_ANALYSIS_TARGET_GRID_SIZE_M=30.0
+SAR_ANALYSIS_RANGE_LOOKS=6
+SAR_ANALYSIS_AZIMUTH_LOOKS=5
+SAR_ANALYSIS_SPECKLE_FILTER_ENABLED=true
+SAR_ANALYSIS_SPECKLE_FILTER_METHOD=lee
+SAR_ANALYSIS_SPECKLE_FILTER_SIZE=5
+GAMMA_SBAS_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84
+TIMESERIES_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84
+
+LANDSAR_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape_global_int16.tif
+LANDSAR_SBAS_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape_global_int16.tif
+GF3_GEO_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape_global_int16.tif
+```
+
+## Non-Default DEMs
+
+- `D:\DEM\HeiLongJiang10M_DEM.tif` is a regional interpolated DEM. It is not the default production DEM.
+- `D:\DEM\landsar_prepared\HeiLongJiang10M_DEM_full_4326_int16.tif` is a LandSAR-compatible regional derivative of the interpolated DEM. It should only be used by an explicitly named regional/high-resolution experiment.
+- `D:\DEM\COPDEM_GLO30_China_4326_DEM` remains a possible China-coverage fallback, but it is not the default after this contract.
+- `D:\DEM\GMTED2010.jp2` is too coarse for production geocoding and should not be used as a production DEM default.
+
+Any task that intentionally uses a non-default DEM must record the selected source path, derived/cropped path, DEM resolution, target output grid, and coverage decision in its manifest.

docs/DEPLOYMENT.md

@@ -112,7 +112,7 @@ ORBIT_POOL_LANDSAR=
 ```env
 IDL_EXECUTABLE=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idl.exe
 IDL_WORKBENCH_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlde.exe
-IDL_DINSAR_DEM_BASE_FILE=D:\SRTM30m\SRTMDEM_RSP_SARscape
+IDL_DINSAR_DEM_BASE_FILE=D:\DEM\SRTMDEM_RSP_SARscape
 IDL_WORKER_RUNTIME_DIR=D:\production_runtime\idl_worker
 ENVI_TASK_TIMEOUT_SECONDS=21600
 ```
@@ -131,7 +131,7 @@ GF3_STORAGE_DIRS=D:\GaoFen3_Pool\catalog
 GF3_SARSCAPE_RUNTIME_DIR=D:\GaoFen3_Pool\task_pool\sarscape_runtime
 GF3_SARSCAPE_WRAPPER_EXE=D:\Code\Insar_management_system_v2\third_party\GF3_L1A_To_L2_pipeline\dist\windows\gf3wrapper.exe
 GF3_SARSCAPE_IDLRT_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlrt.exe
-GF3_SARSCAPE_DEM_PATH=D:\DEM\COPDEM_GLO30_China_4326_DEM
+GF3_SARSCAPE_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape
 GF3_SARSCAPE_POLARIZATIONS=HH,HV
 GF3_SARSCAPE_AUTO_STANDARDIZE=false
 GF3_SARSCAPE_CLEAN_AFTER_SUCCESS=true

docs/GF3_SARSCAPE_NATIVE_TO_GEOTIFF_DESIGN_20260530.md

@@ -454,7 +454,7 @@ GF3_ARCHIVE_SOURCE_DIRS
 ```env
 GF3_SARSCAPE_WRAPPER_EXE=D:\Code\Insar_management_system_v2\third_party\GF3_L1A_To_L2_pipeline\dist\windows\gf3wrapper.exe
 GF3_SARSCAPE_IDLRT_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlrt.exe
-GF3_SARSCAPE_DEM_PATH=D:\DEM\GMTED2010.jp2
+GF3_SARSCAPE_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape
 GF3_SARSCAPE_POLARIZATIONS=HH,HV
 GF3_SARSCAPE_KEEP_EXTRACTED=true
 GF3_SARSCAPE_AUTO_STANDARDIZE=false

docs/INDEX.md

@@ -31,14 +31,22 @@
   褰撳墠闄嗘帰涓€鍙枫€丼entinel-1銆侀珮鍒嗕笁鏈満鐢熶骇銆佹寜闇€瑙ｅ寘銆丟F3 澶栭儴鐢熶骇鐧昏銆佺粨鏋滅鐞嗗拰 UNC 閫€鍑虹害瀹氥€?
 - [PRODUCTION_RESULTS_MULTI_ENGINE_DESIGN_20260423.md](PRODUCTION_RESULTS_MULTI_ENGINE_DESIGN_20260423.md)  
   缁熶竴缁撴灉鐩綍銆佹爣鍑嗕骇鍝佸寘銆乧atalog 涓庡寮曟搸缁撴灉鍏卞瓨绾﹀畾銆?
+- [RESULT_EXTRACTION_ACCESS_CONTROL_AUDIT_20260630.md](RESULT_EXTRACTION_ACCESS_CONTROL_AUDIT_20260630.md)
+  Result extraction and access-control audit: current D-InSAR export/registration boundaries, placeholder channels, admin/viewer limitations, and recommended exporter/operator/admin permission model.
 - [DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md](DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md)  
   D-InSAR 淇濈暀 ENVI/SARscape銆丩andSAR銆丟amma/PyINT 涓夊紩鎿庯紝閫€鍑?ISCE2锛岀粺涓€ Task_Pool銆佺粨鏋滆仛鍚堝拰涓棿鏂囦欢娓呯悊鐨勫綋鍓嶈璁°€?
 - [LANDSAR_DEM_PREPARATION_CONTRACT_20260618.md](LANDSAR_DEM_PREPARATION_CONTRACT_20260618.md)  
   LandSAR D-InSAR/SBAS 鐨勫叏鐞?DEM 涓€娆℃€?Int16 鏍囧噯鍖栥€佸尯鍩熻鍓?tif銆佺敓浜ч厤缃拰 guardrail 绾﹀畾銆?
+- [DEM_PRODUCTION_SOURCE_CONTRACT_20260628.md](DEM_PRODUCTION_SOURCE_CONTRACT_20260628.md)
+  Production DEM source contract: SRTM-derived common source family, engine-specific derived formats, and non-default DEM guardrails.
 - [LANDSAR_CLUSTER_WORKER_DEPLOYMENT_20260624.md](LANDSAR_CLUSTER_WORKER_DEPLOYMENT_20260624.md)  
   LandSAR D-InSAR 集群 worker 的队列分片设计、主服务器 IP 白名单、远端 Windows 节点 192.168.1.6 部署和运行约束。
 - [LANDSAR_CLUSTER_DATA_TRANSPORT_DESIGN_20260625.md](LANDSAR_CLUSTER_DATA_TRANSPORT_DESIGN_20260625.md)
   LandSAR 集群数据搬运（HTTP Task_Pool 下载 + 结果回传）、Windows 集群运维（Task Scheduler 开机自启 + 心跳监控）。
+- [PRODUCTION_NODE_SUBSYSTEM_DESIGN_20260627.md](PRODUCTION_NODE_SUBSYSTEM_DESIGN_20260627.md)
+  D-InSAR 与 LT-1/Sentinel-1 单景影像生产的统一生产节点子系统设计，明确 LandSAR 集群 MVP、worker-only 部署、安全边界和后续本机/集群双模式路线。
+- [LANDSAR_LT1_SCENE_STACK_PRODUCTION_DESIGN_20260627.md](LANDSAR_LT1_SCENE_STACK_PRODUCTION_DESIGN_20260627.md)
+  LandSAR 陆探一号单景/多景生产 proID 与参数链探索，设计 `100016/100206` 导入产品化、结果 catalog、本机/集群双模式和后续影像产品验证路线。
 - [UNC_SOURCE_ARCHIVE_AND_MATERIALIZE_DESIGN_20260615.md](UNC_SOURCE_ARCHIVE_AND_MATERIALIZE_DESIGN_20260615.md)  
   LT-1/Sentinel-1 鏈湴婧愬帇缂╁寘绠＄悊銆佸寘鍐?XML/manifest 璧勪骇鍖栥€佹湰鍦?Task_Pool materialize锛屼互鍙?UNC 閫€鍑哄悗鐨勬湰鏈洪儴缃茶竟鐣屻€?
 - [SOURCE_ARCHIVE_INTEGRITY_AUDIT_20260620.md](SOURCE_ARCHIVE_INTEGRITY_AUDIT_20260620.md)  

docs/LANDSAR_LT1_SCENE_STACK_PRODUCTION_DESIGN_20260627.md

@@ -0,0 +1,642 @@
+# LandSAR 陆探一号单景/多景生产链路探索与系统设计（2026-06-27）
+
+## 1. 结论
+
+LandSAR 不只承担 LT-1 D-InSAR。仓库内 LandSAR 工具和文档显示，LandSAR 已有一条明确的 LT-1 数据生产基础链：
+
+```text
+LT-1 源数据
+  -> 100016 LT-1 数据导入
+  -> 100206 LT-1 精密轨道导入
+  -> Task_*/Input_Data
+```
+
+这条链可以支撑两类非 D-InSAR 生产能力：
+
+1. **单景生产基础产品**：把一景 LT-1 源数据导入为 LandSAR 统一 `Input_Data` 格式，形成后续处理可复用的标准输入。
+2. **多景生产基础产品**：把同轨道、同模式、同极化的一组 LT-1 场景导入并注入精密轨道，形成 LandSAR 时序栈 `Task_TS_*/Input_Data`。
+
+当前系统的问题不是 LandSAR 没能力，而是这条能力没有被后端产品化：
+
+- 现有后端只在 `LandsarEngine.run()` 的 D-InSAR 前置阶段调用 `100016`。
+- `100206` 精轨导入和多景导入逻辑主要沉淀在 `third_party/LandSAR/lt1_import_gui.py`，还没有进入后端生产服务。
+- 单景/多景导入结果还没有独立 catalog、运行记录和本机/集群双模式。
+- 地理编码、正射、强度图这类“业务影像产品”还需要进一步验证 LandSAR 的 `180016`、`180044`、`200016`、`200046` 等 proID 参数链，不能直接把 `100016` 导入结果命名为正射影像。
+
+因此第一阶段建议先产品化：
+
+```text
+landsar.import.lt1.scene.v1
+landsar.import.lt1.stack.v1
+landsar.orbit.lt1.v1
+```
+
+第二阶段再在真实样例参数和运行验证基础上开放：
+
+```text
+landsar.image.lt1.geocode.v1
+landsar.image.lt1.ortho.v1
+```
+
+## 1.1 当前实现状态
+
+截至 2026-06-27，系统已落地第一阶段的本机生产入口：
+
+- 后端新增 `LANDSAR_LT1_IMPORT` 任务类型。
+- 后端新增 `/api/landsar-lt1-production/*` API。
+- 已按 LandSAR GUI 中的真实参数格式生成 `100016.txt` 与可选 `100206.txt`。
+- 运行结果以 `catalog_name=lt1_landsar` 写入 `result_products/result_assets`。
+- 前端“生产管理 -> 陆探一工作台 -> 陆探一影像生产”已可提交单景或多景 LT-1 源资产/目录导入任务。
+- 选择 `source_product_assets` 中的 LT-1 源资产时，任务会先 materialize 到 `LANDSAR_WORK_ROOT/lt1_import_tasks/<task_id>/scenes/`，再把解包后的 scene 目录交给 LandSAR。
+- `manifest.summary.source_asset_ids` 会记录源资产 id；资产台账和检索列表根据 `result_products.summary_json.source_asset_ids` 下发 `lt1_landsar_produced` 标识。
+- 已经登记为 READY 的 LT-1 LandSAR 产品会在生产面板中禁止再次选择；后端任务执行前也会再次拒绝已生产源资产。
+
+当前实现边界：
+
+- 输入支持资产台账中的 LT-1 源资产，或人工指定的已 materialize/解包 LT-1 scene 目录；人工目录无法可靠反查源资产去重状态。
+- 输出产品语义是 LandSAR `Input_Data` 标准化生产结果，不是正射影像、地理编码强度图或 D-InSAR 结果。
+- 集群执行尚未接入这一任务类型；当前先采用主服务器本机 LandSAR 执行，并通过同一 manifest/catalog 结构为后续生产节点适配保留边界。
+
+## 2. 已确认的 LandSAR proID 与参数链
+
+### 2.1 已有可复用参数生成器
+
+当前仓库中 `third_party/LandSAR/lt1_import_gui.py` 已有以下参数生成器：
+
+| 能力 | proID | 现有函数 | 状态 |
+| --- | --- | --- | --- |
+| LT-1 数据导入 | `100016` | `generate_param_file()` | 已有，偏 master/slave 两目录 |
+| LT-1 多景导入 | `100016` | `generate_lt1_multiscene_import_param_file()` | 已有，支持 `文件夹导入个数=N` |
+| LT-1 精密轨道导入 | `100206` | `generate_orbit_param_file()` | 已有 |
+| D-InSAR | `200014` | `generate_dinsar_param_file()` | 已接入后端 |
+| SBAS 一体化 | `280039` | `generate_sbas_param_file()` | 已有参数生成器，运行授权/能力需另行验证 |
+| PS-InSAR 分步 | `280000~280032` | `generate_psinsar_step_param_file()` | 已有参数生成器，运行链路需另行验证 |
+| Stacking | `300001` | `generate_stacking_param_file()` | 已有参数生成器 |
+
+这说明 `100016 + 100206` 不是猜测能力，已经有明确参数格式、GUI 调用方式和成功判定逻辑。
+
+### 2.2 已确认的第一阶段链路
+
+#### `100016`: LT-1 数据导入
+
+用途：
+
+- 从 LT-1 源 scene 目录读取 XML/TIFF。
+- 输出 LandSAR 统一格式 `Input_Data`。
+- 可用于单景，也可用于多景。
+
+关键参数形态：
+
+```text
+卫星数据导入LT-1
+处理编号       100016
+设置数据导入形式_0文件夹导入_1数据导入  文件夹导入
+读取成像参数文件_0否_1是 1
+读取SLC数据文件_0否_1是 1
+文件夹导入标识  TRUE
+文件夹导入个数  N
+文件夹1路径  <scene_dir_1>
+...
+设置数据导出目标路径_0原目录_1新目录  1
+设置输出文件目录  <Input_Data>
+```
+
+成功判定：
+
+- 日志包含 `module [LT-1数据导入] success`。
+- 或 `console success`。
+- 输出目录存在 `LT1*_SLC.xml` 和对应 `LT1*_SLC.tif`。
+
+注意：
+
+- 当前后端 `backend/app/dinsar_engines/landsar_engine.py` 的 `_generate_import_param_file()` 写死 `文件夹导入个数 2`，适合 D-InSAR pair 前置导入。
+- 单景/多景产品化应改用 N 景参数生成逻辑，而不是复用 pair-shaped 参数。
+
+#### `100206`: LT-1 精密轨道导入
+
+用途：
+
+- 对 `Input_Data` 中的 LT-1 XML 注入或关联精密轨道。
+- 为后续 D-InSAR、SBAS、PS、Stacking 或影像处理提供已校正输入。
+
+关键参数形态：
+
+```text
+LT-1精密轨道数据导入
+处理编号       100206
+输入数据个数  N
+输入数据1的xml  <xml_path_1>
+...
+输入精密轨道数据文件夹  <orbit_dir>
+选择XML文件保存方式  0
+设置数据导出目录形式0原目录1新目录  0
+输出更新处理后数据目录  <Input_Data>
+```
+
+成功判定：
+
+- 日志包含 `module [LT-1精密轨道数据导入] success`。
+- 或日志同时包含 `精密轨道` 和 `success`。
+- 或 `console success`。
+
+### 2.3 候选但未验证的影像产品链
+
+LandSAR 文档列出了以下与单景影像产品相关的 proID：
+
+| proID | 功能 | 当前判断 |
+| --- | --- | --- |
+| `180044` | 多视处理 | 可能用于单景强度/幅度产品前置，但参数格式未在后端沉淀 |
+| `180016` | 地理编码 | 可能用于单景地理编码产品，但缺少样例参数 |
+| `180070` | SLC 处理 | 可能用于单景 SLC 派生处理，但语义需验证 |
+| `200016` | 地理编码（流程） | 可能是一体化地理编码流程，但缺少样例参数 |
+| `200046` | SLC 处理（流程） | 可能是一体化 SLC 处理流程，但缺少样例参数 |
+| `280032` | SLC 数据多视 | PS/MTInSAR 链路中的多视步骤，不应直接等同于通用单景影像生产 |
+
+这些 proID 不能直接进入正式 UI。需要先从 LandSAR GUI 生成真实参数文件，拿一景样本跑通，再决定产品定义。
+
+## 3. 产品能力分层
+
+### 3.1 第一层：导入型生产产品
+
+这是近期可落地层。
+
+#### `landsar.import.lt1.scene.v1`
+
+```text
+输入：
+  LT-1 单景源压缩包或 materialized scene 目录
+
+处理：
+  100016 LT-1 数据导入
+  可选 100206 LT-1 精密轨道导入
+
+输出：
+  Input_Data/
+    LT1*_SLC.xml
+    LT1*_SLC.tif
+    *.thumb.jpg
+  params/
+    100016.txt
+    100206.txt
+  logs/
+    100016_console.log
+    100206_console.log
+  import_manifest.json
+
+catalog:
+  catalog_name = lt1_landsar
+  product_family = lt1_scene_import
+  product_type = landsar_input_data
+```
+
+产品语义：
+
+- 这是 LandSAR 输入标准化产品。
+- 不是正射影像。
+- 不是地理编码强度图。
+- 可作为 D-InSAR、SBAS、PS、后续影像产品的上游缓存。
+
+#### `landsar.import.lt1.stack.v1`
+
+```text
+输入：
+  同一轨道/模式/极化/方向的一组 LT-1 scene
+
+处理：
+  100016 LT-1 多景导入
+  100206 LT-1 精密轨道导入
+
+输出：
+  Task_TS_<track>_<pol>_<orbit_direction>_<start>_<end>_<count>/
+    Input_Data/
+    Output_Data/
+    stack_import_manifest.json
+    时序数据构建报告.txt
+
+catalog:
+  catalog_name = lt1_landsar
+  product_family = lt1_stack_import
+  product_type = landsar_timeseries_input_data
+```
+
+产品语义：
+
+- 这是 LandSAR 多景时序输入产品。
+- 可作为 PS/SBAS/MT-InSAR 的上游准备结果。
+- 不直接表示形变结果。
+
+### 3.2 第二层：影像型生产产品
+
+这层需要先验证 LandSAR 影像处理 proID。
+
+候选 profile：
+
+```text
+landsar.image.lt1.multilook.v1
+landsar.image.lt1.geocode.v1
+landsar.image.lt1.ortho.v1
+```
+
+可能链路：
+
+```text
+landsar.import.lt1.scene.v1
+  -> 180044 多视处理
+  -> 180016 地理编码
+```
+
+或：
+
+```text
+landsar.import.lt1.scene.v1
+  -> 200046 SLC 处理（流程）
+  -> 200016 地理编码（流程）
+```
+
+当前必须标记为待验证：
+
+- 缺少真实参数文件。
+- 缺少真实输出样例。
+- 缺少对输出单位、坐标系、辐射定标、nodata、分辨率的确认。
+- 缺少成功判定和错误摘要规则。
+
+## 4. 系统架构设计
+
+### 4.1 后端模块
+
+建议新增独立模块，不放进 `dinsar_engines`：
+
+```text
+backend/app/landsar_lt1/
+  contracts.py
+  param_files.py
+  runtime.py
+  discovery.py
+  scene_import_adapter.py
+  stack_import_adapter.py
+  result_package.py
+```
+
+职责：
+
+- `contracts.py`：定义 scene/stack 输入 manifest、结果 manifest、能力描述。
+- `param_files.py`：沉淀 `100016`、`100206` 参数文件生成器，不再依赖 GUI 代码。
+- `runtime.py`：统一调用 `InSAR_Console.exe`、日志捕获、超时、成功判定、错误摘要。
+- `discovery.py`：从资产表或 materialized 目录解析 LT-1 scene，按轨道/极化/日期分组。
+- `scene_import_adapter.py`：执行 `landsar.import.lt1.scene.v1`。
+- `stack_import_adapter.py`：执行 `landsar.import.lt1.stack.v1`。
+- `result_package.py`：生成标准发布包、manifest、current 指针。
+
+LandSAR D-InSAR 当前已有的 runtime 检查、授权服务启动、DLL 校验逻辑可以抽取共用，但不要把单景/多景生产继续塞进 `LandsarEngine.run()`。
+
+### 4.2 调度模型
+
+建议走统一生产节点协议：
+
+```text
+主服务器创建 production run
+  -> 每个 scene 或 stack group 生成 production item
+  -> 本机 worker 或远端 production node 领取
+  -> adapter 执行 LandSAR
+  -> 上传/登记标准产品包
+```
+
+执行模式：
+
+| 模式 | 说明 |
+| --- | --- |
+| `local` | 主服务器本机执行 |
+| `cluster` | 指定远端生产节点执行 |
+| `auto` | 按节点能力、负载、数据缓存选择 |
+
+节点能力：
+
+```json
+{
+  "capabilities": [
+    "landsar.import.lt1.scene.v1",
+    "landsar.import.lt1.stack.v1",
+    "landsar.orbit.lt1.v1"
+  ]
+}
+```
+
+### 4.3 运行记录模型
+
+现有 `dinsar_production_runs` 虽然有 `product_family` 字段，但表名、字段和 item 语义都偏 pair。为了避免技术债，不建议把单景/多景陆探生产继续塞进 D-InSAR run 表。
+
+推荐新增通用生产表：
+
+```text
+production_runs
+  run_id
+  product_family
+  processor_code
+  profile_code
+  execution_mode
+  source_scope
+  status
+  total_items
+  completed_items
+  failed_items
+  params_json
+
+production_run_items
+  item_id
+  run_id
+  item_key
+  item_type              # scene / stack_group
+  source_asset_ids_json
+  source_paths_json
+  target_key             # scene_uid / stack_key
+  status
+  latest_run_key
+  latest_manifest_path
+  metrics_json
+
+production_executions
+  execution_id
+  run_id
+  item_id
+  node_id
+  run_key
+  status
+  output_dir
+  manifest_path
+  log_path
+  error_message
+```
+
+也可以短期复用 `system_jobs` 做执行队列，但正式 UI、重试、批次统计、集群调度和结果追溯需要上述通用运行表。
+
+### 4.4 结果 catalog
+
+现有 `result_products` / `result_assets` 表可以承载单景/多景产品，因为它们已经有：
+
+- `catalog_name`
+- `product_family`
+- `product_type`
+- `engine_code`
+- `processor_code`
+- `profile_code`
+- `stack_key`
+- `summary_json`
+- `assets`
+
+但现有 `result_catalog_service._load_manifest()` 明确拒绝非 `dinsar` 的 manifest。需要拆出通用结果登记服务：
+
+```text
+result_package_registry
+  register_manifest(manifest_path)
+  validate_manifest(product_family)
+  upsert_result_product()
+  upsert_result_assets()
+```
+
+LandSAR LT-1 生产建议使用：
+
+```text
+catalog_name   = lt1_landsar
+product_family = lt1_scene_import / lt1_stack_import
+product_type   = landsar_input_data / landsar_timeseries_input_data
+engine_code    = landsar
+processor_code = landsar.import.lt1.scene / landsar.import.lt1.stack
+profile_code   = landsar.import.lt1.scene.v1 / landsar.import.lt1.stack.v1
+```
+
+## 5. 输入与分组设计
+
+### 5.1 单景输入
+
+来源：
+
+- `source_product_assets` 中的 `LT1_ARCHIVE`。
+- 已 materialized 的 LT-1 scene 目录。
+- 人工指定的受控服务器目录。
+
+流程：
+
+```text
+source asset
+  -> materialize scene
+  -> run 100016
+  -> optional run 100206
+  -> publish result package
+```
+
+### 5.2 多景输入
+
+分组键建议：
+
+```text
+satellite_family = LT1
+track / orbit number
+imaging_mode
+polarization
+orbit_direction
+product_type = SLC
+admin/aoi 或用户选择范围
+date range
+```
+
+多景生产不应简单把用户勾选的所有 LT-1 都丢给 LandSAR。需要先做分组预检：
+
+- 是否同一轨道或可构成同一时序栈。
+- 是否同一极化。
+- 是否同一成像模式。
+- 日期是否可解析。
+- 是否都有源包。
+- 精轨是否匹配。
+- scene footprint 是否满足业务区域覆盖要求。
+
+输出 `stack_key` 示例：
+
+```text
+lt1_stack_<track>_<pol>_<orbit_direction>_<start_date>_<end_date>_<scene_count>_<hash>
+```
+
+## 6. 发布目录设计
+
+```text
+D:\production_results\lt1_landsar\
+  scene_import\
+    <scene_uid>\
+      current\
+        landsar.import.lt1.scene.v1.json
+      runs\
+        <run_key>\
+          manifest.json
+          execution_manifest.json
+          native\
+            Input_Data\
+            params\
+            logs\
+          assets\
+            input_data\
+            thumb\
+            metadata\
+
+  stack_import\
+    <stack_key>\
+      current\
+        landsar.import.lt1.stack.v1.json
+      runs\
+        <run_key>\
+          manifest.json
+          execution_manifest.json
+          native\
+            Task_TS_...\Input_Data\
+            Task_TS_...\Output_Data\
+            params\
+            logs\
+          assets\
+            input_data_manifest.json
+            stack_report.txt
+            scene_index.json
+```
+
+`native/` 保留 LandSAR 原始结构，`assets/` 放系统标准化索引文件和必要缩略图。不要把完整 `Input_Data` 再复制两份；标准资产层可以用 manifest 指向 native 内的相对路径。
+
+## 7. API 与前端入口
+
+### 7.1 API
+
+建议新增：
+
+```text
+GET  /api/landsar-lt1-production/capabilities
+POST /api/landsar-lt1-production/preview
+POST /api/landsar-lt1-production/run
+GET  /api/landsar-lt1-production/products
+GET  /api/landsar-lt1-production/products/{product_db_id}
+GET  /api/landsar-lt1-production/products/{product_db_id}/assets/{asset_id}
+```
+
+`preview` 必须先返回可执行性：
+
+- 选中 scene 数。
+- 分组结果。
+- 缺失源包。
+- 缺失精轨。
+- 预计输出目录。
+- 是否可本机执行。
+- 是否有集群节点支持。
+- 源资产是否已经存在 READY 状态的 LT-1 LandSAR 产品。
+
+### 7.2 前端
+
+生产管理里将 `陆探一生产占位` 改成实际工作台：
+
+```text
+陆探一生产
+  ├─ 单景导入
+  ├─ 多景时序输入构建
+  ├─ 运行记录
+  └─ 产品结果
+```
+
+第一版按钮只开放：
+
+- 预检。
+- 提交单景导入。
+- 提交多景导入。
+- 查看日志。
+- 打开结果目录。
+- 查看 catalog 资产。
+
+不要第一版就开放：
+
+- 正射产品。
+- 地理编码强度图。
+- PS/SBAS 自动执行。
+- Stacking 自动执行。
+
+这些应建立在第一层 `Input_Data` 产品稳定之后。
+
+## 8. 集群化设计
+
+单景/多景导入非常适合纳入生产节点：
+
+- 输入大但结构明确。
+- 输出可通过 manifest 回传。
+- 不需要主服务器承担长时间 LandSAR 进程。
+- `Input_Data` 可作为远端缓存，后续 D-InSAR/SBAS 复用。
+
+远端节点能力：
+
+```text
+landsar.import.lt1.scene.v1
+landsar.import.lt1.stack.v1
+landsar.orbit.lt1.v1
+```
+
+第一版并发建议：
+
+- LandSAR 进程并发：每节点 1。
+- 多 scene 导入内部由 LandSAR 控制，不在外层并发拆太碎。
+- 多个单景任务可以排队，但不要同节点同时启动多个 `InSAR_Console.exe`，除非实测证明安全。
+
+数据搬运：
+
+- 主服务器给 input manifest。
+- worker 下载源包或 materialized scene。
+- worker 执行 `100016/100206`。
+- worker 上传 manifest 和必要产物。
+- 大体量 `Input_Data` 是否全量回传可配置：第一版建议回传完整受管产品；后续可做远端缓存引用。
+
+## 9. 实施路线
+
+### 阶段 1：参数链固化
+
+- 从 `third_party/LandSAR/lt1_import_gui.py` 抽取 `100016`、`100206` 参数生成逻辑。
+- 增加参数文件 golden tests。
+- 不接 UI，不跑真实任务。
+
+### 阶段 2：本机单景导入
+
+- 实现 `landsar.import.lt1.scene.v1` adapter。
+- 输入一个 LT-1 scene。
+- 执行 `100016`。
+- 可选执行 `100206`。
+- 生成标准 manifest。
+- 登记到 `result_products`，catalog 为 `lt1_landsar`。
+
+### 阶段 3：本机多景导入
+
+- 实现分组预检。
+- 实现 `landsar.import.lt1.stack.v1` adapter。
+- 复用 `generate_lt1_multiscene_import_param_file()` 语义。
+- 执行 `100016 -> 100206`。
+- 发布 `Task_TS_*/Input_Data` 产品。
+
+### 阶段 4：生产节点接入
+
+- 把 scene/stack import adapter 接入生产节点协议。
+- 远端节点上报能力。
+- 实现输入下载、结果回传、日志上报。
+
+### 阶段 5：影像产品验证
+
+- 用 LandSAR GUI 对单景生成多视、地理编码或正射产品。
+- 收集真实参数文件。
+- 确认 proID、输出命名、坐标系、单位和成功判定。
+- 再实现 `landsar.image.lt1.*`。
+
+## 10. 需要运行验证的问题
+
+1. `100016` 单景导入时 `文件夹导入个数=1` 是否被当前 LandSAR runtime 接受。
+2. `100016` 多景导入最大稳定 scene 数是多少。
+3. `100206` 对已导入 XML 是原地改写还是复制输出。
+4. `100206` 精轨注入后 XML 中可验证字段是什么。
+5. `180044 -> 180016` 是否能独立从单景 `Input_Data` 生成地理编码影像。
+6. `200046/200016` 是否比单步 `180xxx` 更适合作为正式影像产品链。
+7. LandSAR 同一台机器是否允许多个导入任务并发。
+8. 导入输出是否可跨机器复用，还是强依赖本机路径。
+
+## 11. 近期不建议做的事
+
+- 不建议把 `100016` 单景导入继续藏在 D-InSAR 前置步骤里。
+- 不建议把 `100016` 输出命名为正射或地理编码产品。
+- 不建议把单景/多景生产塞进 `dinsar_production_runs`。
+- 不建议在未验证 `180016/200016` 参数前开放“LandSAR 正射生产”按钮。
+- 不建议先做复杂 UI。应先做 adapter、manifest、catalog、真实样例验证。

docs/LT1_GEOCODED_GEOTIFF_PRODUCTION_20260628.md

@@ -0,0 +1,68 @@
+# LT-1 Geocoded GeoTIFF Production Update (2026-06-28)
+
+## Decision
+
+The LT-1 production button must produce a usable geocoded GeoTIFF, not only prepare LandSAR `Input_Data` for later D-InSAR work.
+
+The current implemented production path is:
+
+```text
+LT-1 source asset
+  -> radar_data record
+  -> SAR_SCENE_PREPROCESS job
+  -> lt_gamma single-scene pipeline
+  -> SARSceneGeoORM.analysis_tif_path = analysis_ready.tif
+```
+
+This is the platform's real LT-1 single-scene backscatter image product for now. It performs the Gamma single-scene preprocessing chain: LT source product to Gamma SLC, multilook amplitude, geocode, speckle filtering in the linear-power domain, dB conversion, and analysis-ready GeoTIFF registration.
+
+The chain must not silently fall back to unrelated DEM sources. The default production contract is SRTM-derived on the current server:
+
+- `SAR_ANALYSIS_DEM_PATH=D:\DEM\SRTMDEM_RSP_SARscape.wgs84`
+- `SAR_ANALYSIS_TARGET_GRID_SIZE_M=30.0`
+- `SAR_ANALYSIS_DEM_RESOLUTION_M=30.0`
+- `SAR_ANALYSIS_RANGE_LOOKS=6`
+- `SAR_ANALYSIS_AZIMUTH_LOOKS=5`
+- `SAR_ANALYSIS_SPECKLE_FILTER_ENABLED=true`
+- `SAR_ANALYSIS_SPECKLE_FILTER_METHOD=lee`
+- `SAR_ANALYSIS_SPECKLE_FILTER_SIZE=5`
+- `PYINT_GEO_INTERP=1`
+
+The runtime clips the configured SRTM-derived DEM to the scene footprint with a small margin, converts that clip to Gamma DEM format, runs `generate_rdc_dem.py`, geocodes the multilooked amplitude with `geocode_back`, exports a GeoTIFF with `data2geotiff`, applies a Lee speckle filter to the linear power raster, then converts power to dB. The output `pixel_size_m` stored in `sar_scene_geo` is derived from the GeoTIFF transform; WGS84 degree grids are converted to approximate meters before registration.
+
+Multilook is already part of the Gamma preprocessing path through `generate_rdc_dem.py`; it is controlled by `SAR_ANALYSIS_RANGE_LOOKS` and `SAR_ANALYSIS_AZIMUTH_LOOKS`. Speckle filtering is a separate post-geocode raster operation before dB conversion. The filter manifest records the method, window size, domain, and equivalent number of looks used for the Lee weighting.
+
+For SRTM-derived DEMs, the configured 30 m analysis grid must be translated into Gamma `dem_lat_ovr` and `dem_lon_ovr` from the actual converted `.dem.par` spacing. Do not assume that `SAR_ANALYSIS_DEM_RESOLUTION_M=30.0` alone changes the output GeoTIFF grid. A 3 arc-second source DEM with `dem_lat_ovr=1` and `dem_lon_ovr=1` will still produce about 90 m latitude spacing. The runner now reads `post_lat`, `post_lon`, and scene latitude from the converted Gamma DEM parameter file, then writes the derived oversampling into the template before `generate_rdc_dem.py`.
+
+The previous `D:\DEM\HeiLongJiang10M_DEM.tif` default is not the production default. It is an interpolated regional DEM and must not be mixed silently with SRTM-derived products. If a future production profile intentionally uses it, the selected DEM and output grid must be recorded in the product manifest.
+
+## What Changed
+
+- `/api/landsar-lt1-production/run` queues `SAR_SCENE_PREPROCESS` jobs with `engine=lt_gamma`.
+- Each selected LT-1 source asset resolves to a `radar_data` scene and produces one independent `SARSceneGeoORM` record.
+- Batch mode means batch single-scene GeoTIFF production. It does not create a D-InSAR pair/stack product.
+- The product list under `/api/landsar-lt1-production/products` reads from `sar_scene_geo`, not from `result_products.catalog_name=lt1_landsar`.
+- Asset inventory and radar search mark LT-1 assets as produced only when `sar_scene_geo.status = DONE` and `analysis_tif_path` exists for the LT-1 `lt_gamma` profile.
+
+## UI And Query Contract
+
+- The LT-1 GeoTIFF production UI does not accept arbitrary LT-1 scene directories. Operators must select scanned source assets so each output can be linked back to `radar_data` and `sar_scene_geo`.
+- The UI does not expose a satellite-mode/BIST selector. Acquisition mode should come from scanned source metadata, and the current Gamma single-scene pipeline does not require the operator to choose LandSAR import mode manually.
+- The production candidate list reuses `/radar-data/search` with `satellite_family=LT1` and `source_format=LT1_ARCHIVE`, so operators can plan production by acquisition date, administrative AOI, orbit, polarization, and product name.
+- `/assets/sources` remains the asset-led inventory view. It is not the main LT-1 production planning surface because it lacks the full image search/AOI workflow.
+- Items that already have a completed LT-1 GeoTIFF product are shown as produced and are not selectable for a new production task.
+
+## What Is Not A Finished Image Product
+
+LandSAR `100016` and `100206` are still useful, but they only prepare/import LT-1 data:
+
+```text
+100016 -> LandSAR Input_Data
+100206 -> precise-orbit injection for imported XML
+```
+
+Those outputs must not be displayed as "image production complete" and must not block reprocessing as if they were geocoded images.
+
+## Open LandSAR Work
+
+LandSAR single-scene geocoded image production may still be possible through `180044`, `180016`, `200046`, or `200016`, but the repository does not yet contain a verified parameter chain for those modules. Do not expose those proIDs in the formal UI until a real parameter file and sample run are verified.

docs/PRODUCTION_NODE_SUBSYSTEM_DESIGN_20260627.md

@@ -0,0 +1,462 @@
+# 生产节点子系统设计：D-InSAR 与单景影像生产（2026-06-27）
+
+## 1. 结论
+
+当前 `LANDSAR_CLUSTER_ITEM` 已经证明：LandSAR D-InSAR 可以从主服务器拆分 pair，并在远端 Windows 节点完成输入搬运、LandSAR 执行和结果回传。
+
+但这仍是 LandSAR D-InSAR 的集群 MVP，不应直接扩展成长期架构。后续陆探一号和 Sentinel-1 的“只生产影像、不做 D-InSAR”能力也会进入生产管理域。陆探一号这条线应优先承认 LandSAR 已有的 `100016` LT-1 数据导入/统一格式转换能力，再决定是否继续扩展为地理编码或正射影像产品。因此远端节点不能只理解 `LANDSAR_CLUSTER_ITEM`，而应该抽象成一个受控的“生产节点子系统”。
+
+建议把后续设计目标调整为：
+
+1. 主服务器继续负责资产索引、任务编排、调度策略、结果 catalog 和权限边界。
+2. 子服务器只部署生产节点运行包，不部署完整项目仓库、前端、管理后台和无关源码。
+3. 所有生产任务按“产品类型 + 处理器能力”分发，同一任务可以选择本机执行或集群执行。
+4. LandSAR、Gamma/PyINT、未来 Sentinel-1 影像生产处理器都通过 adapter 接入生产节点协议。
+5. 结果以标准产品 manifest 回传，由主服务器统一入库，而不是让子服务器直接写主库或扫描任意目录。
+
+## 2. 当前事实
+
+### 2.1 已有设计边界
+
+- [THREE_SENSOR_LOCAL_PRODUCTION_CONTRACT_20260616.md](THREE_SENSOR_LOCAL_PRODUCTION_CONTRACT_20260616.md) 明确 LT-1、Sentinel-1 当前管理对象是本机压缩包源池，生产时才按任务 materialize 到 `Task_Pool`。
+- [DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md](DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md) 明确 D-InSAR 保留 `sarscape`、`landsar`、`pyint` 三条主线，其中 LandSAR 只处理 LT-1，Gamma/PyINT 同时支持 LT-1 和 Sentinel-1。
+- [LANDSAR_CLUSTER_DATA_TRANSPORT_DESIGN_20260625.md](LANDSAR_CLUSTER_DATA_TRANSPORT_DESIGN_20260625.md) 已经为 LandSAR D-InSAR 定义了输入下载和结果上传链路。
+- 当前 192.168.1.6 节点已能执行 LandSAR D-InSAR 集群 item，并调用与本机一致的 `LandsarEngine.run()`。
+- `third_party/LandSAR/LT-1_数据导入功能说明.md` 明确 `100016` 是 LT-1 数据导入算法 ID；当前 `backend/app/dinsar_engines/landsar_engine.py` 已经能生成 `100016.txt` 并调用 `InSAR_Console.exe`，但这段能力目前只作为 D-InSAR 前置导入阶段存在。
+
+### 2.2 仍未完成的能力
+
+- 生产管理里的陆探一号已接入第一阶段本机生产链：`100016` LT-1 导入生成 LandSAR `Input_Data`，并支持可选 `100206` 精轨注入。它仍不是正射/地理编码影像产品。
+- 生产管理里的 Sentinel-1“只生产影像”仍是占位，不是已实现链路。
+- 陆探一号单景生产至少应拆成两层：`landsar.import.lt1` 表示 LandSAR `100016` 导入/统一格式转换，`landsar.image.lt1` 表示后续地理编码、正射或业务可用影像产品。前者已在本机任务/API/前端/catalog 中产品化；后者仍需要确认 LandSAR 调用链和输出规格。
+- Sentinel-1 影像生产的处理器尚未最终确认，不能把 Sentinel-1 影像生产硬编码到 LandSAR 集群链路。
+- 当前集群 worker 更接近“把后端生产代码部署到远端执行”，还不是一个最小权限、最小源码暴露的生产节点运行包。
+
+## 3. 需要解决的问题
+
+### 3.1 不要把集群等同于 LandSAR D-InSAR
+
+如果继续按 `LANDSAR_CLUSTER_ITEM` 的方式增长，后续很容易出现：
+
+- `LANDSAR_IMAGE_CLUSTER_ITEM`
+- `S1_IMAGE_CLUSTER_ITEM`
+- `PYINT_CLUSTER_ITEM`
+- `SBAS_CLUSTER_ITEM`
+
+每新增一种生产能力都复制一套领取、搬运、执行、上传、入库逻辑，技术债会快速扩大。
+
+更稳妥的边界是：
+
+```text
+生产任务协议
+  ├─ 输入 manifest
+  ├─ 处理器 adapter
+  ├─ 执行状态上报
+  ├─ 结果 manifest
+  └─ 结果上传与 catalog
+
+具体处理器
+  ├─ landsar.dinsar.lt1
+  ├─ landsar.import.lt1
+  ├─ landsar.image.lt1
+  ├─ pyint.dinsar.lt1
+  ├─ pyint.dinsar.s1
+  └─ s1.image.<待定处理器>
+```
+
+### 3.2 单景影像生产也需要本机/集群双模式
+
+LT-1 和 Sentinel-1 的影像生产虽然不是 D-InSAR，但仍可能是重计算、重 IO、长耗时任务。它们不应该只作为本机按钮实现。
+
+推荐统一执行模式：
+
+| 模式 | 含义 | 适用场景 |
+| --- | --- | --- |
+| `local` | 主服务器本机执行 adapter | 调试、小批量、没有可用节点 |
+| `cluster` | 远端生产节点领取执行 | 大批量、长耗时、需要释放主服务器 |
+| `auto` | 主服务器按能力、负载、数据位置选择 | 正式生产默认模式 |
+
+前端可以先只暴露“本机执行 / 集群执行”，内部仍按统一任务协议创建任务。
+
+### 3.3 子服务器不应长期部署完整代码仓库
+
+当前 MVP 为了快速跑通，子服务器需要较完整的项目运行环境。这对验证是可接受的，但长期有三个问题：
+
+1. 源码暴露面过大：子服务器不需要前端、后台管理、资产扫描、用户接口等源码。
+2. 配置权限过宽：子服务器不应持有主库高权限连接信息。
+3. 升级不可控：完整仓库部署容易出现主服务器和子服务器代码版本漂移。
+
+长期应改为生产节点运行包：
+
+```text
+production-node/
+  worker_service.py
+  config.py
+  client.py
+  adapters/
+    landsar_dinsar.py
+    landsar_lt1_image.py
+    pyint_dinsar.py
+    s1_image.py
+  contracts/
+    job_manifest.py
+    product_manifest.py
+    status_event.py
+  scripts/
+    install_windows_service.ps1
+  requirements.lock
+```
+
+这个运行包只包含：
+
+- 任务领取和心跳客户端。
+- 输入下载和结果上传客户端。
+- 必要的生产 adapter。
+- 与主服务器共享的 manifest schema。
+- Windows 服务安装脚本。
+
+不包含：
+
+- 前端源码。
+- 管理后台路由。
+- 数据扫描入口。
+- 用户认证管理。
+- 数据库迁移脚本。
+- 与该节点能力无关的处理器源码。
+
+## 4. 目标架构
+
+```mermaid
+flowchart LR
+  UI["生产管理前端"] --> API["主服务器 API"]
+  API --> Scheduler["调度器"]
+  Scheduler --> Queue["生产任务队列"]
+  API --> Catalog["结果 catalog"]
+  API --> Assets["源数据/精轨资产库"]
+
+  NodeA["本机生产节点"] --> Queue
+  NodeB["远端生产节点 1.6"] --> Queue
+  NodeC["远端生产节点 N"] --> Queue
+
+  NodeB --> Adapter1["landsar.dinsar.lt1"]
+  NodeB --> Adapter2["landsar.image.lt1"]
+  NodeC --> Adapter3["pyint.dinsar.s1"]
+  NodeC --> Adapter4["s1.image.<待定>"]
+
+  Queue --> Manifest["输入 manifest"]
+  Manifest --> NodeB
+  NodeB --> Upload["结果上传 API"]
+  Upload --> Catalog
+```
+
+### 4.1 主服务器职责
+
+- 维护源数据、精轨、DEM、Task_Pool、结果 catalog。
+- 根据资产状态生成生产任务。
+- 决定任务执行模式：本机、指定节点、自动调度。
+- 为 worker 生成输入 manifest，包含文件清单、hash、大小、产品类型、处理器 profile。
+- 接收 worker 状态、日志摘要、进度事件和结果包。
+- 校验结果 manifest 后入库。
+- 维护节点注册、能力、版本、心跳和并发上限。
+
+### 4.2 生产节点职责
+
+- 启动后向主服务器注册或发送心跳。
+- 上报能力，例如 `landsar.dinsar.lt1`、`landsar.import.lt1`、`landsar.image.lt1`、`pyint.dinsar.s1`。
+- 按能力领取任务。
+- 下载输入文件或复用本地缓存。
+- 调用本机已安装的生产软件或 adapter。
+- 将运行日志、状态、结果 manifest 和产品文件上传回主服务器。
+- 清理本地临时目录，保留可配置缓存。
+
+### 4.3 Adapter 职责
+
+Adapter 是生产节点中唯一知道具体软件细节的层：
+
+| Adapter | 输入 | 输出 | 备注 |
+| --- | --- | --- | --- |
+| `landsar.dinsar.lt1` | LT-1 pair Task_Pool | D-InSAR 标准产品包 | 当前集群 MVP 已覆盖核心执行 |
+| `landsar.import.lt1` | LT-1 单景源包、解包 scene，或多景导入目录 | LandSAR `Input_Data` 统一格式、缩略图、导入 manifest | 基于 `100016`，当前代码已有 pair-shaped 前置调用，需要拆成一等单景 adapter |
+| `landsar.image.lt1` | `landsar.import.lt1` 输出 + 可选精轨/DEM | LT-1 地理编码、正射或业务影像产品 | 需要确认 LandSAR 后续 proID/参数和产品规格 |
+| `pyint.dinsar.lt1` | LT-1 pair Task_Pool | D-InSAR 标准产品包 | 可后续接入 |
+| `pyint.dinsar.s1` | S1 pair Task_Pool + EOF | D-InSAR 标准产品包 | 当前只应按 Gamma/PyINT 能力开放 |
+| `s1.image.<待定>` | S1 ZIP/SAFE + EOF | S1 单景影像产品 | 处理器未确定前保持占位 |
+
+主服务器不应该把某个 adapter 的内部目录结构暴露给前端；前端只看到任务类型、执行位置、状态和结果。
+
+## 5. 统一任务类型
+
+### 5.1 产品族
+
+建议把生产任务按产品族建模，而不是按按钮建模：
+
+| 产品族 | 数据粒度 | 当前状态 | 目标执行模式 |
+| --- | --- | --- | --- |
+| `dinsar_pair` | 两景 pair | LandSAR LT-1 集群 MVP 已跑通 | 本机 + 集群 |
+| `single_scene_import` | 单景或多景导入 | LT-1 LandSAR `100016/100206` 已作为本机 `LANDSAR_LT1_IMPORT` 任务、API、前端入口和 `lt1_landsar` catalog 产品发布；集群执行尚未接入 | 本机 + 集群 |
+| `single_scene_image` | 单景 | LT-1 后续影像产品和 S1 均为占位 | 本机 + 集群 |
+| `sbas_stack` | 多景 stack | 当前不纳入本轮集群化 | 后续再设计 |
+| `gf3_native_register` | 外部结果登记 | 本机登记 `_geo` | 不建议进入生产节点 |
+
+### 5.2 推荐任务字段
+
+```json
+{
+  "job_id": 123,
+  "product_family": "single_scene_image",
+  "sensor": "LT1",
+  "processor": "landsar",
+  "profile": "landsar.image.lt1",
+  "execution_mode": "cluster",
+  "input_manifest_url": "/api/production-node/jobs/123/input-manifest",
+  "result_contract": "standard_product_manifest.v1",
+  "priority": 50,
+  "retry_policy": {
+    "max_retries": 2,
+    "timeout_seconds": 7200
+  }
+}
+```
+
+### 5.3 结果 manifest
+
+D-InSAR 和单景影像生产都应该回传标准 manifest，差异放在 `product_family` 和 `product_type` 中：
+
+```json
+{
+  "manifest_version": 1,
+  "product_family": "single_scene_image",
+  "sensor": "LT1",
+  "processor": "landsar",
+  "profile": "landsar.image.lt1",
+  "scene_id": "LT1A_MONO_KSC_STRIP1_...",
+  "run_key": "run_20260627T010203Z_landsar_image_lt1_456",
+  "products": [
+    {
+      "role": "main_image",
+      "path": "products/main.tif",
+      "format": "GeoTIFF",
+      "crs": "EPSG:4326"
+    },
+    {
+      "role": "preview",
+      "path": "preview/main.webp",
+      "format": "WEBP"
+    },
+    {
+      "role": "metadata",
+      "path": "metadata/product.json",
+      "format": "JSON"
+    }
+  ]
+}
+```
+
+## 6. 陆探一号单景生产设计方向
+
+陆探一号单景生产如果由 LandSAR 承担，应先把“导入/统一格式转换”和“正式影像产品”分开。
+
+### 6.1 `landsar.import.lt1`
+
+这是当前最清楚、风险最低的第一版能力。
+
+LandSAR `100016` 的语义是 LT-1 数据导入：把 LT-1A/LT-1B SLC XML/TIFF 转成 LandSAR 统一内部格式，形成 `Task_*/Input_Data` 可消费的 XML/TIF 组织，并生成缩略图等辅助文件。当前代码已经在 `_ensure_imported_input_data()` 中调用这条链路，但有两个限制：
+
+- 它被包在 D-InSAR 执行内部，只在缺少 `Input_Data` 时作为前置阶段触发。
+- 当前参数生成器按 `master/slave` 两文件夹导入写死，不是正式的单景产品 adapter。
+
+第一版应把它产品化为：
+
+```text
+landsar.import.lt1
+  输入：LT-1 单景源包、解包 scene，或显式 scene 目录
+  执行：InSAR_Console.exe + 100016.txt
+  输出：LandSAR Input_Data 统一格式 + import_manifest.json + 缩略图/日志
+  入库：单景预处理/影像生产 catalog
+  执行模式：local / cluster / auto
+```
+
+这个产品不应伪装成正射影像或地理编码强度图。它的价值是把陆探源数据转成 LandSAR 后续 D-InSAR、SBAS、影像处理可复用的标准输入。
+
+### 6.2 `landsar.image.lt1`
+
+如果“只生产影像”指的是业务可用影像，例如地理编码强度图、幅度图、正射 GeoTIFF、洪涝分析输入图，那么还需要确认 LandSAR 是否有对应单景 proID 或可复用处理链。不能把 `100016` 的导入输出直接命名为正射产品。
+
+需要确认的产品规格：
+
+- 输入是源压缩包、解包目录，还是现有 Task_Pool scene 目录。
+- 输出是 SLC/SSC 的标准化影像、地理编码强度图、幅度图、还是系统用于浏览和洪水分析的 GeoTIFF。
+- 是否需要精轨。
+- 是否需要 DEM。
+- 是否需要生成 WebP 预览。
+- 是否进入 `radar_data`、`source_product_assets`、D-InSAR catalog，还是新的影像产品 catalog。
+
+如果后续确认 LandSAR 能从 `Input_Data` 继续生成地理编码/正射产品，再实现第二层：
+
+```text
+LT-1 single scene image product
+  输入：landsar.import.lt1 输出 + 可选精轨 + 可选 DEM
+  执行器：LandSAR
+  输出：标准产品目录 + product_manifest.json + preview.webp
+  入库：影像产品 catalog
+  执行模式：local / cluster / auto
+```
+
+不要在第一版同时承诺“原始归档标准化、地理编码、洪水分析输入、全部极化派生物、可视化浏览缓存”这些目标。先把一个产品闭环做对，再扩展产品角色。
+
+## 7. Sentinel-1 影像生产设计方向
+
+Sentinel-1 单景影像生产目前不能直接套用 LandSAR。需要先确定处理器：
+
+- 如果走 Gamma/PyINT，需要定义单景预处理 profile。
+- 如果走 GDAL/SNAP/其他工具，需要单独 adapter。
+- 如果只是生成浏览预览，应该归入资产扫描/预览缓存，不应叫正式生产任务。
+
+建议在处理器未确认前只保留协议占位：
+
+```text
+s1.image.<processor>
+  状态：设计占位
+  不进入正式调度
+  不在 UI 上展示为可执行生产能力
+```
+
+这样可以避免前端提前出现“哨兵影像集群生产”按钮，但后端没有可信处理链。
+
+## 8. 调度与效率
+
+### 8.1 节点能力上报
+
+生产节点心跳应包含：
+
+```json
+{
+  "node_id": "production-node-192-168-1-6",
+  "version": "2026.06.27",
+  "capabilities": [
+    "landsar.dinsar.lt1",
+    "landsar.import.lt1",
+    "landsar.image.lt1"
+  ],
+  "max_concurrency": 1,
+  "active_jobs": 0,
+  "free_disk_gb": 512,
+  "runtime": {
+    "os": "windows",
+    "landsar_available": true,
+    "python_version": "3.12"
+  }
+}
+```
+
+LandSAR 类任务的并发不能只看 CPU 核心数。需要同时考虑：
+
+- LandSAR 是否支持多实例并发。
+- 许可证或硬件锁是否允许并行。
+- 工作目录是否互相隔离。
+- 磁盘 IO 是否成为瓶颈。
+- 单任务内部是否已经使用多线程。
+
+因此第一版远端 LandSAR 节点建议 `max_concurrency=1`。等确认 LandSAR 多实例隔离和资源占用后，再按节点开放 2 个或更多并发。
+
+### 8.2 缓存策略
+
+单景影像生产和 D-InSAR 可以共享部分输入缓存：
+
+- LT-1 源包下载缓存。
+- LT-1 解包缓存。
+- LandSAR 导入后的中间目录。
+- DEM 裁剪缓存。
+- Sentinel-1 ZIP/SAFE 和 EOF 缓存。
+
+缓存键应基于源文件 hash、mtime、size、processor profile 和关键参数，不应只基于文件名。否则源包被替换后容易复用错误缓存。
+
+### 8.3 数据搬运策略
+
+优先级建议：
+
+1. 第一阶段：沿用 HTTP manifest + file download + result upload，路径最清楚。
+2. 第二阶段：增加断点续传和文件级 hash 校验。
+3. 第三阶段：支持节点本地缓存命中，避免重复下载同一源包。
+4. 第四阶段：在受控环境下可选共享只读源池，但不作为默认安全模型。
+
+不要让 worker 任意访问主服务器磁盘路径。worker 应只根据主服务器签发的 manifest 下载白名单文件。
+
+## 9. 安全边界
+
+长期目标：
+
+- worker 不持有主数据库账号。
+- worker 只持有节点 token。
+- token 按节点、能力和有效期管理。
+- 所有输入下载和结果上传都走主服务器 API。
+- 主服务器校验每个上传文件的相对路径，拒绝目录逃逸。
+- 主服务器校验 result manifest，只有白名单产品角色进入 catalog。
+- worker 运行包只包含生产节点必要代码。
+- worker 版本和 adapter 版本必须上报，主服务器可以拒绝过旧节点领取任务。
+
+当前 LandSAR 集群 MVP 可以作为过渡，但文档上应明确：完整仓库部署、DB 直接领取队列、共享 token 都不是长期安全边界。
+
+## 10. 实施路线
+
+### 阶段 0：保持现状可用
+
+- 保留当前 LandSAR D-InSAR 集群能力。
+- 不在未设计清楚前扩展新的集群 job type。
+- 继续记录 1.6 节点运行结果、失败原因、传输耗时和 LandSAR 执行耗时。
+
+### 阶段 1：抽取生产节点协议
+
+- 定义 `job_manifest`、`input_manifest`、`product_manifest`、`status_event`。
+- 把 LandSAR D-InSAR 当前输入下载、执行、上传流程映射到协议。
+- 主服务器保留当前 API，同时新增通用 `/api/production-node/*` 命名空间。
+
+### 阶段 2：拆出 worker-only 运行包
+
+- 从完整仓库部署改成生产节点运行包部署。
+- Windows 节点用服务方式启动。
+- 节点只配置主服务器 URL、节点 token、工作根、结果根、缓存根和能力列表。
+- 先支持 `landsar.dinsar.lt1`。
+
+### 阶段 3：陆探一号单景生产
+
+- 先实现 `landsar.import.lt1` adapter，把 LandSAR `100016` 从 D-InSAR 前置阶段拆成一等生产能力。
+- 当前 `_generate_import_param_file()` 按 master/slave 两文件夹导入写死，单景 adapter 需要支持单 scene 输入、单文件夹导入或显式 file import。
+- 本机模式和集群模式同时接入同一任务协议。
+- 结果进入单景预处理/影像产品 catalog，而不是混入 D-InSAR 结果 catalog。
+- 确认 LandSAR 后续单景地理编码或正射处理链后，再实现 `landsar.image.lt1`。
+
+### 阶段 4：Sentinel-1 单景影像生产
+
+- 先确认处理器和产品规格。
+- 再实现 `s1.image.<processor>` adapter。
+- 未确认前不开放 UI 执行入口。
+
+### 阶段 5：节点运维和调度完善
+
+- 节点版本管理。
+- 能力矩阵管理。
+- 节点禁用/启用。
+- 任务重分配。
+- 节点磁盘清理。
+- 节点运行日志集中查看。
+
+## 11. 近期不建议做的事
+
+- 不建议继续复制 `LANDSAR_CLUSTER_ITEM` 形成多个专用 cluster item。
+- 不建议在子服务器长期部署完整项目仓库。
+- 不建议让子服务器直接扫描主服务器源数据目录。
+- 不建议让子服务器直接写主数据库结果表。
+- 不建议在 Sentinel-1 处理器未确认前实现“哨兵影像生产”按钮。
+- 不建议把资产扫描阶段的 WebP 预览生成混同为正式影像生产。
+
+## 12. 待确认问题
+
+1. 陆探一号“只生产影像”的正式产品定义是什么：只做 LandSAR `100016` 导入/统一格式转换，还是继续生成地理编码强度图、幅度图、正射 GeoTIFF？
+2. 陆探一号单景影像生产是否必须使用精轨和 DEM？
+3. Sentinel-1 单景影像生产准备用哪个处理器承担？
+4. 单景影像产品是否需要新建 catalog，还是复用现有 `radar_data` 资产表加产品 manifest？
+5. 远端节点是否允许访问只读共享源池，还是严格走 HTTP 下载？
+6. LandSAR 在同一台 Windows 节点上是否允许多个实例并发？
+
+这些问题确认前，可以继续完善 LandSAR D-InSAR 集群，但不宜把新的影像生产能力直接硬接到当前 MVP worker 上。

docs/RESULT_EXTRACTION_ACCESS_CONTROL_AUDIT_20260630.md

@@ -0,0 +1,219 @@
+# 结果提取与用户权限审计（2026-06-30）
+
+## 1. 审计范围
+
+本次审计聚焦“结果提取”相关入口和用户权限边界，覆盖：
+
+- 前端结果提取工作台：`frontend/src/ResultExtractionPanel.jsx`
+- D-InSAR 结果管理页：`frontend/src/DinsarProductsPanel.jsx`
+- D-InSAR 结果导出接口：`POST /api/dinsar-results/export`
+- D-InSAR 生产结果提取与登记接口：`POST /api/idl/extract-disp`
+- 用户与权限模型：`auth_users.role`、全局认证守卫、用户管理页
+
+本次文档只记录审计结论和后续设计约束，不包含代码修复。
+
+## 2. 当前实现事实
+
+### 2.1 两条“提取”链路
+
+当前系统里“结果提取”实际包含两种不同语义：
+
+1. **生产结果入库**
+   - 前端入口：`DinsarProductsPanel.jsx`
+   - 后端入口：`POST /api/idl/extract-disp`
+   - 后台任务：`EXTRACT_DINSAR_PRODUCTS`
+   - 作用：从生产目录提取 D-InSAR 位移结果，发布成标准结果包，并重建结果 catalog。
+
+2. **成果交付导出**
+   - 前端入口：`ResultExtractionPanel.jsx`
+   - 后端入口：`POST /api/dinsar-results/export`
+   - 作用：从已经登记的 D-InSAR catalog 中选择成果，复制到服务器指定交付目录。
+
+这两条链路目前在产品文案上都叫“提取”，容易让用户混淆“入库”和“交付”。
+
+### 2.2 当前接入状态
+
+`ResultExtractionPanel.jsx` 中的通道状态：
+
+| 通道 | 当前状态 | 说明 |
+| --- | --- | --- |
+| D-InSAR 结果 | 已接入 | 支持查询已登记结果并导出到服务器目录 |
+| SBAS-InSAR 结果 | 半接入 | 可读取目录样例，但统一提取接口未实现 |
+| LT-1 正射结果 | 占位 | 单景/正射结果 catalog 与导出链路未完成 |
+| Sentinel-1 正射结果 | 占位 | 生产和导出链路未完成 |
+| GF3 SARscape `_geo` | 占位 | 登记/标准化思路存在，统一导出接口未完成 |
+
+## 3. 当前权限模型
+
+系统当前只有两类角色：
+
+- `admin`
+- `viewer`
+
+定义位置：`backend/app/auth_service.py`
+
+全局认证守卫位于 `backend/app/routers/dependencies.py`：
+
+- `GET / HEAD / OPTIONS` 默认视为只读操作，登录用户可访问。
+- 除少数显式安全 POST 外，非只读请求要求 `admin`。
+- 非管理员执行写操作会被拒绝，返回 `403 Read-only account cannot perform this operation.`
+
+前端在 `App.jsx` 中把非管理员账号映射为 `readOnly`：
+
+- viewer 可以浏览结果、查看任务、查看 catalog。
+- viewer 不能提交生产、扫描、提取、导出、删除、修改。
+- admin 拥有所有写权限，包括生产、扫描、结果入库、结果导出、用户管理和运维配置。
+
+后端没有依赖前端按钮禁用来保护写操作。`/api/idl/extract-disp` 和 `/api/dinsar-results/export` 都显式要求 `admin`，这一点是正确的。
+
+## 4. 审计发现
+
+### P1：成果交付权限与系统管理员权限耦合过重
+
+当前只有 `admin` 能执行成果导出，但 `admin` 同时拥有用户管理、系统配置、生产扫描、删除记录等高权限。
+
+从业务职责看，成果交付导出不应天然等同于系统管理员权限。后续应拆出更细的权限，例如：
+
+- `operator`：可提交生产任务、结果入库、目录重建。
+- `exporter`：可导出已登记成果到受控交付目录。
+- `viewer`：只读浏览、预览、查询。
+- `admin`：用户管理、系统配置、根目录维护、许可证和高风险运维。
+
+### P1：结果导出是同步请求，存在 504 风险
+
+`POST /api/dinsar-results/export` 在请求线程内执行文件复制，最多允许 500 个结果 ID。成果文件较大或目标目录较慢时，容易再次触发前端或 Nginx 超时。
+
+后续应改成后台任务：
+
+- 接口只创建任务并返回 `task_id`。
+- 文件复制由 worker 执行。
+- 前端通过任务中心/结果提取工作台展示进度、成功数、失败数和目标目录。
+
+### P1：生产结果入库缺少显式操作审计
+
+`/api/dinsar-results/export` 已写入 `dinsar_results_exported` 审计日志。
+
+`/api/idl/extract-disp` 当前会创建系统任务，但缺少独立的操作审计记录。它会改变结果 catalog，应记录：
+
+- 操作用户
+- 源生产目录
+- 目标发布目录
+- 创建的 `task_id` / `job_id`
+- 完成后的 processed/copied/failed/published/registered 数量
+
+### P2：页面命名和工作流边界不清
+
+当前“D-InSAR 结果提取与登记”和“结果提取工作台”容易混淆。
+
+建议命名：
+
+- “生产结果入库”：从生产目录提取并登记为系统 catalog。
+- “成果交付导出”：从已登记 catalog 选择成果并复制到交付目录。
+
+这两个动作应该放在同一结果管理域下，但用不同分区和不同权限提示。
+
+### P2：占位通道需要降低可执行暗示
+
+SBAS、LT-1 正射、Sentinel-1 正射、GF3 `_geo` 目前不应被呈现成可执行导出能力。
+
+建议 UI 明确显示：
+
+- `已接入`
+- `目录可查，导出未接入`
+- `规划中`
+- `不可执行`
+
+并隐藏或禁用导出按钮，避免用户误以为功能已经上线。
+
+### P2：导出目录策略需要产品化
+
+当前后端已有 `_validate_export_path()` 和 `ALLOWED_EXPORT_DIRS` 约束能力，但前端仍允许用户输入服务器绝对路径。
+
+后续建议：
+
+- 普通业务用户不输入任意服务器路径。
+- 管理员在系统配置中维护“交付目录白名单”。
+- 结果导出页只让用户选择白名单目录和子任务名。
+- 审计记录保存最终解析后的服务器路径。
+
+### P3：部分前端文案存在历史编码损坏
+
+`DinsarProductsPanel.jsx`、`ResultExtractionPanel.jsx`、`UserAdminPanel.jsx` 等文件存在局部中文乱码。功能不一定受影响，但会降低维护性和产品可信度。
+
+建议后续单独做一次 UTF-8 文案修复，不与权限重构混在同一次提交中。
+
+## 5. 建议目标模型
+
+### 5.1 功能分区
+
+结果管理应拆成三个清晰分区：
+
+1. **产品目录**
+   - 查看已登记成果。
+   - 预览、筛选、查看详情。
+   - viewer 可访问。
+
+2. **生产结果入库**
+   - 从生产结果根目录扫描、提取、发布、登记。
+   - operator/admin 可执行。
+
+3. **成果交付导出**
+   - 从 catalog 选择成果，导出到受控交付目录。
+   - exporter/operator/admin 可执行。
+
+### 5.2 权限矩阵建议
+
+| 操作 | viewer | exporter | operator | admin |
+| --- | --- | --- | --- | --- |
+| 查看结果 catalog | yes | yes | yes | yes |
+| 查看预览与详情 | yes | yes | yes | yes |
+| 生产结果入库 | no | no | yes | yes |
+| 目录重建/发布 | no | no | yes | yes |
+| 成果交付导出 | no | yes | yes | yes |
+| 生产任务提交 | no | no | yes | yes |
+| 用户管理 | no | no | no | yes |
+| 根目录/许可证/运维配置 | no | no | no | yes |
+
+实现上可以先保留 `role` 字段，扩展角色枚举；长期可引入权限位表，避免角色继续膨胀。
+
+## 6. 推荐实施顺序
+
+### 阶段 1：修正产品语义和审计
+
+- 页面文案区分“生产结果入库”和“成果交付导出”。
+- `/api/idl/extract-disp` 增加操作审计。
+- 结果提取工作台明确标注未接入通道。
+- 修复相关页面乱码文案。
+
+### 阶段 2：导出任务化
+
+- 新增 `EXPORT_DINSAR_RESULTS` 后台任务类型。
+- `/api/dinsar-results/export` 改为返回 `task_id`。
+- 前端展示导出任务进度和失败明细。
+- 导出结果保留 task log 和 audit log。
+
+### 阶段 3：权限细分
+
+- 扩展角色：`viewer/exporter/operator/admin`。
+- 用户管理页支持新角色说明。
+- 后端增加能力级依赖，例如 `require_capability("result.export")`。
+- 所有高风险写操作按 capability 而不是只按 admin 判断。
+
+### 阶段 4：交付目录白名单产品化
+
+- 将 `ALLOWED_EXPORT_DIRS` 从环境变量能力升级为系统配置/受控根目录。
+- 前端从白名单选择交付根目录。
+- 用户只输入子目录名或交付批次名。
+
+## 7. 验收标准
+
+完成上述改造后，应满足：
+
+1. viewer 能看结果，不能导出、不能入库。
+2. exporter 能导出已登记成果，但不能提交生产、不能用户管理。
+3. operator 能生产、入库、导出，但不能用户管理和系统配置。
+4. admin 保留全部权限。
+5. 所有入库和导出动作都有 task log 和 audit log。
+6. 大批量导出不再产生 HTTP 504。
+7. 未实现通道在 UI 上不会被误认为可执行功能。
+

docs/SOURCE_ORBIT_ASSET_SCAN_OPERATIONS_20260626.md

@@ -61,6 +61,15 @@ The binding step is currently a full re-evaluation of active LT-1/Sentinel-1 sou
 
 If a scan must be stopped before retrying with new concurrency settings, stop the running worker processes and mark the active `system_jobs`, `system_tasks`, and `asset_inventory_states` rows as terminal failed states. This prevents the job queue from recovering and re-claiming the old job.
 
+The main application worker is expected to support more than one queued job at a time so long-running preview generation does not block independent production jobs. Current main-server baseline:
+
+```env
+JOB_WORKER_CONCURRENCY=2
+JOB_WORKER_ALLOWED_TYPES=
+```
+
+Do not start ad-hoc one-off workers during formal testing. Change the configured worker concurrency, stop stale processes, and let the operator restart the application normally.
+
 Recommended health checks during a source scan:
 
 - Task log should show `workers=16` and `pending=64` / `active_or_queued=64` after the parser pool fills.