用途：指导把 Dagster（或 Dagster+）项目迁移到 Astro Runtime 上的 Airflow 3。资料称迁移应是资产优先（Dagster 资产图对应 Airflow 资产与资产感知调度，而非扁平化 DAG）、增量式（按域推进，迁移期间 Dagster 仍为权威）、诚实（每个定义都有明确处置，语义差异必须记录而非掩盖）。
主要流程：先读 reference/quickstart.md 了解首小时命令、术语与风险；对源项目测试做基线，再用 scripts/inventory.py 只读盘点生成 manifest；依 reference/mapping.md 为每条记录标注 MECH/JUDG/REDESIGN/NONE，并做出 go/no-go 判定（迁移、带条件迁移、暂留 Dagster 三种结果）；试点迁移 2-3 个代表性单元，再按六个验证门逐域迁移，用 scripts/status.py 跟踪状态，失败类别参考 reference/troubleshooting.md 修复；之后映射平台层（密钥、告警、CI/CD、Deployments），并排运行后按域切换。
主要脚本：scripts/inventory.py 扫描 Dagster 仓库生成 JSON manifest（静态，可选运行时模式）；scripts/validate_dag.py 对生成的 Astro 项目执行门 1-3；scripts/status.py 管理单元状态机与完整性门。
硬性规则：禁止桩代码；不得静默遗漏，每个清单记录必须完成或带原因延迟；每个 schedule/sensor/automation 条件都要有等价行；修复模式而非单个实例；不得臆造 API。
版本与要求：资料称已验证 Airflow 3.3.0 / Astro Runtime 3.3-2 / astronomer-cosmos 1.15 / Dagster 1.13（2026-07）；目标需 Astro Runtime 3.3+，原生资产分区面要求 3.3+，低于 3.2 映射会严重退化，建议先升级。还需 Dagster 仓库（最好有运行实例）与目标项目的 astro CLI。
限制：迁移存在已知语义损失，如 code_version_changed 触发的 dbt 重建、freshness 驱动物化、按资产成本核算、列级血缘、深层 AutomationCondition 组合、sensor 游标事务性等，需按参考文件评估替代方案；运行历史不会迁移。