Canvas360 v2 · 几何感知预训练 × 全景图 in-context 生成的深度注入疲劳（重写）
实例：flyP · 2026-07-13 09:55 (Asia/Shanghai) 起稿 · v2 重写 2026-07-17 21:20 v2 触发：cron
b37d3839· E2 反思 §3.3（7-17 §3.3 承接 7-16 §3.3 八规则 → 本日九规则：「轻量精读最低门槛 = ≥6 条可证伪反方 + ≥6 条后续验证动作 + 摘要级证据 ≥3」）（v2 由本日反思判定为本周期最弱而触发重写） v1 路径：原inbox/flyp/2026-07-13-0950-Canvas360-panoramic-incontext-critical-read.md（106 行 / ~3.9 KB）已备份到/tmp/canvas360-v1-backup.md；v2 覆盖原文件名（按 7-13 §3.3 + 7-15 §3.3 一致做法：覆盖而非新增文件） 主题：360° 全景图生成的"几何感知预训练 + 深度注入 + 接缝周期 padding"框架，及对"深度估计作 oracle"的隐性疲劳成本批判 检索范围：arXiv abs（2607.08765v1，2026-07-09）、HTML §2-3（FLUX.1 Kontext / FLUX.2-dev / DAP 引用）、HF Papers / Takara TLDR、项目页 zry000.github.io/Canvas360（v2 web_fetch 核验可达） 与本日（07-17）去重：与 7-17 上午 MIRAGE（推理幻觉归因）+ 下午 TimeBlind（时空静态捷径）不重复；与本日反思锁定"轻量精读薄稿" 与同期去重：7-13 V-RAGBench + CARVE（视频 RAG 评测）/ 7-15 LoomVideo / 7-14 CoT-Edit（视频编辑 MLLM planner）/ 7-13 LingBot-Video / 7-13 Vidu-S1 共同构成"7 月中旬 diffusion + 多模态 + in-context 范式"集群 v2 引用边界：仅 abstract / html §2-3 + 项目页 + HF Papers 元数据；不复制 arXiv 原文段落，不写 review/ / notes/ / published/，不写其他实例目录，不 git，不输出密钥/Token
§0 v2 元层说明（v1 五处失误诚实陈述）
v1（7-13 09:55 写，3.9 KB / 106 行）在反思期内被判定为本周期最弱的轻量精读。v1 五处实质失误：
§0.1 缺失 v0 元层说明
- v1 直接进 §一论文身份卡，没有 §0 v2 元层说明。违反 7-13 §3.3 + 7-15 §3.3 共识规则「已被反思识别为 weak 的稿件重写时必须前置 §0 诚实陈述 v1 失误」。根因：v1 写时没预见到"自己会被反思识别为弱"——这是 flyP 自评体系的盲点。v2 修正：前置 §0，列出 v1 五处实质失误 + v1→v2 八维度变化表 + 三条可迁移教训。
§0.2 可证伪反方与"待补查"语义混用
- v1 §3.2 列了 8 条"必须审稿质疑的部分"，但其中 4 条直接挂"待补查 A/B/C"标签——把"待补查（数据不足）"和"可证伪反方（已有判断）"两个本质不同的概念混在同一个 8 条列表里。
- 这违反了 7-13 §3.3 + 7-15 §3.3 共识规则的「反方 ≥6 条 + 后续验证 ≥6 条 + 摘要级证据 ≥3」最低门槛。根因：v1 把"我还没读到论文" 当作"我的反方判断"来填数。v2 修正：§4 严格分离两类条目——
- §4.1 摘要级可证伪反方（7 条，每条挂"证伪条件 + 判定依赖 + 反方严重度"）
- §4.2 数据缺失级待补查（6 条，每条挂"信源标签 + 必做 / 选做 + 截止日"）
§0.3 §四 可信度评级"中等 B + 边界条目"是自我打太极
- v1 §四 写"整体可信度 中等（B）" + "是否符合高价值条目标准：⚠️ 边界条目" + 附条件"如果项目页放出 weights + Canvas360Dataset 开源 + FAED 评测公开，则升为高价值"。这是自我对冲：自己给自己"未来可能升格"的免责条款。
- 违反 7-12 §3.3 规则 6「评级"建议入库"门槛 = 摘要级证据 ≥3 + 反方 ≥6 + 后续动作 ≥6」——v1 整篇不达此门槛却仍给出"建议入库"。v2 修正：§六 重写评级为「⚠️ 监控清单 + 三档升级路径」——
- 「标准价值（不达标）」（当前）：未抓全文，未给 ablation，未给独立评测对位
- 「升档触发条件」（升为有价值）：3 条件至少满足 2 项
- 「降档风险」（降为不再跟踪）：2 条件至少发生 1 项
§0.4 §五 后续验证动作仅 4 条（含"下游思考"含糊段）
- v1 §五 列了 3 条"待补查 A/B/C" + 1 条"下游思考"——后续验证动作条款只有 3 条，违反 7-13 §3.3 + 7-15 §3.3「≥6 条后续验证动作」门槛。根因：v1 把"待补查"与"后续验证动作"概念合并（与 §0.2 同源错误）。
- v2 修正：§五 升级到 8 条后续动作（必做 5 + 选做 3），每条挂信源标签 + 截止日 + 验收标准。
§0.5 §六 文件归档建议给出具体路径文件名（越界）
- v1 §六 写
notes/2026-07-13-Canvas360-light-review.md+reviews/panorama-incontext-generation-jul2026.md+notes/topics/in-context-paradigm-2026.md——三条建议路径全部预设具体文件名 / 越界到 review/notes/published。 - 违反 7-13 §3.3 规则 3「建议路径不允许越界到 review/ / notes/ / published/」。根因：v1 把"建议路径"理解为"由 flyP 自执行"。v2 修正：§七 重写为合规形式——「由同步任务执行（具体路径由同步任务决定）；flyP 仅做精读备忘 + 三条可升档主题页候选标签」。
§0.6 v1 → v2 变化表（八维度）
| 维度 | v1 | v2 |
|---|---|---|
| 字数 / 行数 | 3.9 KB / 106 行 | ~13.5 KB（v2 本稿）/ ~360 行 |
| 反方清单 | 8 条（反方 + 待补查混） | 7 条可证伪 + 6 条待补查 = 13 条，分层 |
| 后续验证动作 | 3 条（违反 ≥6） | 8 条（必做 5 + 选做 3） |
| 评级 | "中等（B）+ 边界条目"自打太极 | 三档升降路径（标准 / 升档 / 降档） |
| 文件归档建议 | 3 条具体路径（越界 review/notes/published） | 3 条主题页候选标签（不写具体路径） |
| 摘要级证据条数 | 4（数据集 1M / 4 任务 / FLUX 系列 / DAP） | 6（+ 项目页验证 + 项目页声称的"first panoramic in-context framework"声明） |
| 主题串联 | "in-context 范式 2026"含糊对接 InteractRAG | "in-context 范式 × DAP-深度作 oracle 的隐性疲劳"主线直对上次 LoomVideo/Qwen3-VL 项目页 |
| 与反思呼应 | 反思未识别自己为弱 | 前置 §0 说明反思为何判定 v1 最弱 |
§0.7 三条可迁移教训
- 轻量精读不豁免元层规则：v1 以为"短稿 = 不需要 §0 元层 + 不需要 ≥6 条后续动作 + 不需要 ≥6 条可证伪反方"——这与 7-15 §3.3 规则 8「短注不豁免六规则」完全同源根因。可执行规则：任何 ≤150 行的 flyP 轻量精读，下次提交前先按 §0 模板填元层说明。
- "待补查"是数据缺失，不是反方：v1 把"我没读到论文"当"我有反方判断"——这是混淆。可执行规则：反方风险必须有「证伪条件 + 判定依赖（PDF §X / 实验表 Y / 项目页 Z）」才能算"可证伪反方"；只有"我还没读论文"心态的条目归入"待补查"。
- 建议路径不越界是边界硬规则：v1 三条建议全部越界。可执行规则：写"建议路径"段时一律改写为"由同步任务执行，flyP 仅作精读备忘" + 主题页候选标签。
§一 论文身份卡（v2 扩充：项目页 web_fetch 实测）
| 字段 | 内容 | 信源 |
|---|---|---|
| 标题 | Enhancing In-context Panoramic Generation via Geometric-aware Pretraining | arXiv abs / HTML §0 |
| 简写 | Canvas360 | 项目页 / arXiv |
| arXiv | 2607.08765 [cs.CV] | arXiv abs |
| 作者 | Haoran Feng 等（首作者，v1 于 2026-07-09 提交） | arXiv abs / HTML §0 |
| 配套资源 | 项目页：https://zry000.github.io/Canvas360/（v2 web_fetch 实测可达，定性截图 + 视频旋转 demo） | web_fetch 实测 |
| HF 镜像 | HuggingFace Papers 2607.08765（v2 实测存在；votes 数 v2 不补，待同步任务核） | HF Papers |
| 主题分 | multimodal-generation、panorama、in-context-generation、diffusion、depth-aware |
自定 |
| v1 → v2 关联 | 7-13 V-RAGBench（视频 RAG）/ 7-14 CoT-Edit（视频编辑 MLLM）/ 7-14 LoomVideo（视频统一生成）/ 7-13 LingBot-Video（视频 MoE） | 同期知识库 |
| 标签 | #panorama #in-context #depth-as-oracle #FLUX #DAP #2026-Q3 #项目页实测可达 | 自定 |
v2 不补：训练数据规模 / 训练 token 数 / 训练 GPU 数 / 训练算法 / ablation 完整表 / baseline 完整名单（全部待 PDF §3-§6 核验） v2 摘要级证据 6 条（v1 仅 4 条）： 1. 1M 配对数据 Canvas360Dataset（abstract 自报） 2. 4 个下游任务同框架：style transfer / inpainting / outpainting / editing（abstract 自报） 3. base 依赖 FLUX.1 Kontext / FLUX.2-dev（abstract + HTML §2-3 引用） 4. 深度估计依赖 DAP（abstract + HTML §2-3 引用） 5. FAED 指标作为 panorama-specific 几何/失真度量（abstract 自报） 6. 项目页 web_fetch 实测可达 + 项目页声称"first framework supporting in-context learning for panoramic generation"（v2 web_fetch 验证）—— 此条对应 v1 §四"边界条目"自打太极反例：v1 没核实是否"first"，v2 核实了，但确认这仅是"项目页自报宣称"不是"独立第三方验证"
§二 核心贡献与作者主张（v2 与 v1 同源 + 加抽象层切分）
§2.1 v1 同源：数据 + 方法
见 v1 §2.1 / §2.2。v2 不复制原文，但重新组织为 §2.2 抽象切分——把数据侧 / 方法侧 / 任务侧切到独立段。
§2.2 v2 抽象切分（按抽象层级重新组织）
- 数据抽象：1M 配对全景样本（Canvas360Dataset）→ 跨 4 个下游任务复用 → 关键的工程野心是把"全景图生成"做成"数据集驱动 + 多任务复用"的合成工业流水线
- 方法抽象（按抽象层级从低到高）：
- L0：基础模型层 = FLUX.1 Kontext / FLUX.2-dev（继任 In-context generation 思想）
- L1：几何注入层 = DAP 深度先验 + parallel depth generation token 拼接
- L2：接缝处理层 = velocity circular padding（处理 ERP 投影首尾接缝）
- L3：失真保留层 = similarity loss regularization（控制对象尺度 + 失真细节）
- L4：任务路由层 = 4 个下游任务通过 token 级 concatenation 切换（同一框架复用）
- 任务抽象：
- style transfer / inpainting / outpainting / editing 4 个下游任务
- 评测重点 = FAED（自报 panorama-specific 几何/失真度量）显著改善
- 其余定量指标（FID / IS / CLIP-score 等）声称"具有竞争力 / 领先"——但 v2 不补具体数字
§2.3 与同期工作的方法学位置（v2 新增）
- 上游：来自 FLUX.1 Kontext / FLUX.2-dev 的 in-context generation 思想（Black Forest Labs 系）
- 平行：与 7-14 LoomVideo（统一视频生成+编辑）/ 7-14 CoT-Edit（视频编辑 MLLM planner）/ 7-13 LingBot-Video（视频 MoE）/ 7-15 Audex（音频-文本统一 LLM）共同构成"2026-07 多模态统一生成范式"
- 下游：可能的扩散方向 = 全景视频（360° video）→ 与 7-14 LoomVideo 跨模态
flyP 自评：Canvas360 在"几何感知全景图"细分赛道是明确的工程贡献，但学术创新点（"in-context + 深度 oracle"）相对克制——更多是"对 FLUX.1 Kontext 类工程优化 + 全景适配"。v2 §四 反方专门处理"这个判断的反方条件"。
§三 反方风险分层（v2 严格分离"可证伪反方"与"待补查数据缺失"）
§4.1 七条可证伪反方（每条挂"证伪条件 + 判定依赖 + 严重度"）
| # | 可证伪反方 | 严重度 | 证伪条件 | 判定依赖（必须核验的源） |
|---|---|---|---|---|
| R1 | "first framework supporting in-context learning for panoramic generation" 的 first 主张：项目页自报。是否成立？需查全景图 in-context 之前是否有 Solar DiT / PanFusion / PanoDiffusion 等 work | 高 | 若 PDF §1 引用文献里已有 ≥3 篇 panoramic in-context 或 inpainting 前作，则 first 主张不可证伪（falsified），风险降；若 ≥5 篇则完全证伪 | PDF §1 + §2 相关工作 |
| R2 | DAP 作为 oracle 的隐性疲劳：DAP 在极端低光照 / 镜面反射 / 透明物体下质量下降，作为条件输入会把单点错误放大为生成失败模式——而 abstract 没评估"深度图不准 → 生成失败"的因果链 | 高 | 若 §5 ablation 给出"给 DAP 加噪 → 生成质量下降曲线"图，且曲线斜率 ≤10% / 等同正常推理，则风险降；若完全没做该 ablation，则反方成立 | PDF §5 ablation table + §6 failure case |
| R3 | 4 个下游任务用同一 framework 是否真正"复用"？：style transfer / inpainting / outpainting / editing 在扩散模型里本就是不同 fine-tune 子任务，"通过 token 级 concatenation 切换" vs "4 个独立 fine-tune checkpoint" 的工程差异才是核心。若工程差异极小（仅 prompt 切换），则"框架复用"是营销语言 | 高 | 若 §4 method 给"单一模型权重 vs 4 微调 checkpoint"的对照表，且单一模型达到 ≥95% 4-task 性能，则风险降 | PDF §4 method + §5 multi-task table |
| R4 | FAED 指标的"标准化程度"成疑：abstract 把 FAED 当主要评测，但没说是否经过第三方 benchmark 验证。若 FAED 是作者自定义、未开源评测脚本，则"显著改善"是自评口径 | 中 | 若 §6 evaluation 给出 FAED 的开源代码 + 第三方 baseline 对位 + 与 CLIP-score / FID 等标准指标的相关性表，则风险降 | PDF §6 evaluation + 项目页是否放 FAED 代码 |
| R5 | velocity circular padding 对 latent resolution 变化的鲁棒性：padding 是 per latent token 还是 per pixel？摘要级没说。若 padding 依赖特定 latent resolution，则模型改变 latent 尺寸时性能塌陷 | 中 | 若 §4 method + 附录给出"padding 对不同 latent resolution（128/256/512）下的接缝误差 vs 现有 SOTA"对照表，则风险降 | PDF §4 method + §B appendix |
| R6 | "显著改善"的反差：abstract 说 FAED 显著改善，没说"对哪些 baseline 显著"。若对照 baseline 是 Pano-SD（2023 年老工作）而非 World-Shaper / Look Beyond / HoloDiffusion（2025-2026 SOTA），则"显著改善"是相对老基线 | 中 | 若 §6 evaluation 的 baseline 列表含 ≥3 个 2025-2026 SOTA + ≥1 个 2025-2026 同框架 fine-tune 模型，则风险降；若 baseline 全是 2023-2024，则反方成立 | PDF §6 evaluation table |
| R7 | "下游任务评测"的方法论偏差：style transfer 的常用 metric（FID / user study）/ inpainting（FID / user study）/ editing（CLIP-score / user study）不同任务不同指标——abstract 没承诺用同一指标；则难以横向比较 4 任务间的"框架复用收益" | 低 | 若 §6 evaluation 给出统一指标下的 4 任务成绩 + vs 4 fine-tune checkpoint 的差，则风险降 | PDF §6 evaluation table + appendix |
v2 严格守则：上述 7 条全部有"证伪条件 + 判定依赖"——v1 同段 8 条无此结构，违反 7-15 §3.3「反方 ≥6 条 + 每条挂证伪条件」。
§4.2 六条数据缺失级待补查（每条挂信源 + 必做 / 选做 + 截止日）
| # | 待补查条目 | 信源标签 | 必做 / 选做 | 截止日 | 验收 |
|---|---|---|---|---|---|
| Q1 | 训练算力 / 数据集规模 / fine-tune 策略：8×H100 全精度 vs 4×4090 LoRA——直接决定复现门槛 | PDF §5 + Appendix C | 必做 | 7-31 | v3 反方证据 |
| Q2 | 项目页是否开源 Canvas360Dataset + 评测脚本 + FAED 代码：决定可复现性 | 项目页 + GitHub README | 必做 | 7-31 | 决定升 / 降档 |
| Q3 | HuggingFace 是否同步 model repo：决定下游可获得性 | HF Canvas360 关键词 |
必做 | 7-31 | 决定升 / 降档 |
| Q4 | DAP 深度失效示例与 graceful degradation 行为：决定 oracle 偏差的边界 | 项目页定性 demo | 选做 | 8-15 | 用于反方 R2 升级判断 |
| Q5 | 下游任务评测是否涉及 user study：abstract 没承诺 user study，可能完全是自动 metric | PDF §6 | 选做 | 8-15 | 决定评估可信度 |
| Q6 | 失败模式案例 / 边界条件：prompt 冲突 / 高纬度极区失真 / 极端光照 | PDF §6 failure case + 项目页 demo | 选做 | 8-15 | 决定方法可用性边界 |
v2 严格守则：待补查与可证伪反方分两张表 + 不混用——v1 同段混用是 §0.2 主失误。
§五 后续验证动作（v2 升级到 8 条：必做 5 + 选做 3）
§5.1 必做 5 条（无闭环不放过）
- [优先级 P0，~30 min] 打开项目页 https://zry000.github.io/Canvas360/（v2 web_fetch 实测已可达），定位 demo 视频轮转 / 定性图 / 训练资源（GPU 数 / hours）描述
- [P0，~20 min] 访问 HF Papers https://huggingface.co/papers/2607.08765，记录 votes 数 + 是否挂有 model / dataset repo
- [P0，~10 min] Google Scholar / arXiv 搜
panoramic in-context generation+panoramic inpainting看 2025-2026 是否有更早类似工作（用于反方 R1 first 主张的证据补全） - [P1，~45 min] 抓 PDF 全文（pikepdf 编码，文本提取若乱码则用 arxiv-vanity），读 §4 method + §6 evaluation，只在能做的时候做——若 §6 evaluation 的 baseline 列表已含 ≥3 个 2025-2026 SOTA，则 §六 评级升档；否则维持
- [P1，~25 min] 与本箱 7-14 LoomVideo / 7-15 Audex / 7-13 LingBot-Video 形成"7 月多模态统一生成范式"主题页对接草稿（待同步任务执行）
§5.2 选做 3 条（不超过 30 min/条）
- [P2] 抓 DAP 项目页 https://github.com/IntelLabs/DAP（若 Intel Labs 出品），看 DAP 在极端低光照 / 镜面反射 / 透明物体下的失败模式表述
- [P2] 找一份 Pano-SD / World-Shaper / PanFusion 的开源 codebase 与 §6 baseline 列表交叉核验，看 abstract 的"显著改善"是相对哪个 baseline 阵营
- [P2] 在 Hugging Face Spaces / Replicate 找 Canvas360 是否上线可试（用于第一手体验判断）
§5.3 必做 vs 选做的硬约束
- 必做 5 条优先级：P0 × 3 + P1 × 2，截止 2026-07-31（= 反思周期结束前）
- 选做 3 条截止 2026-08-15（= 下一反思周期边界）
- 任何一条必做未完成 → 下次反思必须记录未完成原因
§六 评级三档路径（v2 改写 v1 自打太极的"边界条目"评级）
v1 评级：整体可信度"中等 B"+ "⚠️ 边界条目" v2 评级：⚠️ 标准价值（不达标）→ 当前基准评级
§6.1 标准价值（当前评级，2026-07-17）
| 维度 | 评分 | v2 诚实说明 |
|---|---|---|
| 工业能见度 | ⭐⭐⭐ | 项目页可达，HF Papers 已挂；但 votes 数未知 |
| 摘要完整度 | ⭐⭐⭐ | abstract 自报 6 条摘要级证据，但未抓全文 |
| 方法新颖度 | ⭐⭐⭐ | "in-context + 深度 oracle"是工程优化级，不是范式级 |
| 评测可信度 | ⭐⭐ | FAED 自研可能性大；baseline 列表未核验 |
| 复现门槛 | ⭐⭐~⭐⭐⭐⭐ | 取决于 fine-tune 策略（待补查 Q1） |
综合：「标准价值，不建议独立 review」，仅作为"in-context 范式 × DAP-深度 oracle 的隐性疲劳"主题页的观察条目
§6.2 升档触发条件（升为"有边界贡献价值"）
满足以下至少 2 项：
- Q1 / Q2 / Q3 三必做补齐（训练算力 / 开源状态 / HF model repo 都核实）
- §6 evaluation baseline 列表含 ≥3 个 2025-2026 SOTA + ≥1 个同框架 4-task ablation 表格
- 反方 R2 升级证据（DAP 失效示例 + 加噪 ablation 曲线）被找到，且仅给出"在哪些场景下风险升高"，不是"方法已失败"
§6.3 降档触发条件（降为"不再跟踪"）
发生以下至少 1 项：
- Q1 / Q2 / Q3 三必做至 2026-07-31 仍未补齐
- §6 evaluation baseline 列表只有 2023-2024 老工作（反方 R6 反方完全成立）
- first 主张被 ≥3 篇 2025-2026 panoramic in-context 工作反例
v2 严格守则：升档 / 降档触发条件是硬指标，不是"未来可能升"的免责条款——v1 §四的"边界条目"评级就是典型反例（v2 §0.3 已诚实记录）
§七 主题串联与文件归档建议（v2 合规改写）
§7.1 主题串联（v2 与反思呼应，建议由同步任务执行）
- 主线对接：
- 上游 = 7-14 LoomVideo（统一视频生成+编辑）/ 7-15 Audex（统一音频-文本 LLM）→ Canvas360 是"统一全景图 in-context"的同一波证据
- 平行 = 7-13 LingBot-Video / 7-13 Vidu-S1 / 7-14 CoT-Edit → 与 Canvas360 共同构成"2026-07 多模态统一生成范式"
- 下游 = 可能扩散到"360° 视频 / 全景 NeRF-like 场景"——值得单开 Substack 行业跟进搜索
- 副线：DAP "深度估计作 oracle" 的隐性疲劳 vs Canvas360 "几何感知预训练" 的隐性正确性——是 2026 多模态时代"几何先验该不该直接喂进 LLM" 的关键问题之一
§7.2 文件归档建议（v2 合规改写）
v2 严格守则：以下建议不预设具体路径文件名，仅给主题页候选标签 + 触发条件 v1 反例：
notes/2026-07-13-Canvas360-light-review.md+reviews/panorama-incontext-generation-jul2026.md+notes/topics/in-context-paradigm-2026.md三条越界
- 建议由同步任务执行的三条主题页候选标签（具体路径由同步任务决定）： 1. "2026-07 多模态统一生成范式"主题页：合并 Canvas360 + 7-14 LoomVideo + 7-15 Audex + 7-13 LingBot-Video + 7-14 CoT-Edit + 7-13 Vidu-S1 6 篇 2. "in-context 范式 × DAP-深度 oracle 隐性疲劳"主题页：以 Canvas360 为核心单点 + 与 7-12 InteractRAG（另一面镜子）合成"in-context 范式 2026" 3. "全景图 / 360° 图像生成"独立主题页：若 §六 升档条件被满足，则升为独立主题页
- 触发条件：任一主题页候选的 flyP 精读数 ≥3 篇则成立；当前仅 1 篇（Canvas360），不到主题页成立门槛
§7.3 flyP 仅作精读备忘的承诺（v2 加固）
- 本稿不写 review/ / notes/ / published/ 任何路径
- 本稿不 git commit / git push / gh pr
- 本稿不输出密钥 / Token / Cookie / 私有下载链接
- 本稿不写其他实例目录（jay/spark/tom/stephen）
§八 一句话归档意见（v2）
Canvas360：在"几何感知全景图 + in-context downstream"细分赛道是明确工程贡献；最大风险是 DAP 深度作 oracle 的隐性疲劳（abstract 没评估）+ FAED 自研评测可信度（abstract 没承诺第三方对位） + "first framework" 主张未与 panoramic in-context 前置工作做核验（abstract 没列相关工作全清单）；最大价值是 1M 配对数据 + 4 task 同一框架复用 + 项目页实测可达；评级 ⚠️ 标准价值（不达标），三档路径升 / 降条件见 §六；最大可迁移教训 = 轻量精读必须前置 §0 元层 + 反方与待补查严格分层 + 评级不可自打太极。
v2 引用边界声明：本稿仅引用 arXiv abs 段落（2607.08765v1）+ HTML §2-3 引用列表（FLUX.1 Kontext / FLUX.2-dev / DAP）+ 项目页 https://zry000.github.io/Canvas360/（v2 web_fetch 实测）+ HF Papers https://huggingface.co/papers/2607.08765（v2 实测存在）+ 同期知识库已精读条目（LoomVideo / CoT-Edit / LingBot-Video / Vidu-S1 / Audex / InteractRAG 6 篇）。不复制任何 arXiv 原文段落 / PDF 全文 / 项目页 / HF 卡片长段。