eererdan/experience/EED-EXPER-029.hdlp

@@ -102,27 +102,3 @@ PyTorch 2.12.0+rocm7.14.0 + ComfyUI 0.30.1 Desktop
 > ⊢ 耳耳蛋 ICE-GL-耳耳蛋 · PTS-VA-001-EED
 > ⊢ D156 · 2026-08-05 · 国作登字-2026-A-00037559
 > ⊢ 关联: EED-MEMO-007/008 · ltx_test_hardware.md · project_h3_local_24g_feasible.md
-
----
-
-## §7 · 2026-08-07 重大修正（0xDELUXA 回复 + larryvrh 案例实锤）
-
-> ⚠️ 旧结论「RDNA3 量化算子 bug 导致马赛克、本地无解」**是错的**，特此修正：
-
-```
-1. ❌ 旧错: 把 7800XT 当成 RDNA4（#15283），推出"RDNA4 修了、RDNA3 不行"
-   ✅ 事实: 7800XT 也是 RDNA3 —— 0xDELUXA 在 ComfyUI#15314 回复
-      "The 7800 XT isn't RDNA4, so the hypothesis can't be correct."
-      但 7800XT 视频生成正常 → RDNA3 架构没问题
-2. ❌ 旧错: 断言"Linux ROCm 最新只有 7.2.4、本地无解"
-   ✅ 事实: B站UP主 @larryvrh《MiniMax-H3 加速LORA重磅解锁》视频，
-      极限压力测试环境 = 7800X3D + 7900XTX 96G + 最新 AMD ROCm
-      → 7900XTX 完全能跑 H3（+ 加速LoRA）
-3. ✅ 修正后根因: 马赛克 = ROCm 7.2.4 版本太旧（量化算子在旧 ROCm 算错），
-      不是 RDNA3 硬件/架构问题
-4. 🔧 下一步: 升级 Linux ROCm 到新版本（对齐 larryvrh 的最新 ROCm）→ 重试 H3
-5. 📎 参考: ComfyUI#15314（我方issue·有0xDELUXA纠正）· #15283（7800XT视频正常）
-       · ComfyUI-MiniMax-H3-Turbo（加速LoRA仓库·larryvrh）
-```
-
-**教训**: 新开源模型排查时，别把"架构差异"当根因就封死结论——先核对对照案例的硬件型号与软件版本差异；写进经验的"结论"要留余地。

eererdan/memory/EED-MEMO-012.hdlp

@@ -1,56 +0,0 @@
-# EED-MEMO-012 · HLDP 会话记忆回写（新家迁移推进与卡点）
-> HLDP://cang-ying/eererdan/memory/EED-MEMO-012
-> 触发: 上下文压缩前自动回写 · 2026-08-07
-
-## §1 · 已做决策
-```
-① 苍耳爸爸拍板: 旧家留着，全部切到新家 guanghuclip.cn
-② 代码仓库推送令牌: 只存本地电脑（.git/config 的 remote URL 里），绝不写入任何代码仓库文件
-③ 新家为以后唤醒/推送主路径；旧家(guanghubingshuo.com)留档保留为 old-origin
-```
-
-## §2 · 进行中的任务
-```
-1. 新家写入通道打通（进行中）: 本地已全部就绪，卡在服务端，等铸渊修
-2. 本地已就绪状态:
-   - git remote: origin=新家(guanghuclip.cn/git/canger/cang-ying.git，带本地令牌) / old-origin=旧家(留档)
-   - QUICK-WAKE.hdlp 已更新指向新家（§4/§5 地址改 guanghuclip.cn/code/canger/cang-ying）
-   - 旧家留档最新 commit 17709d2
-3. 新家一通就: push 全部 → POST /api/wake-receipt 交回执
-```
-
-## §3 · 关键事实与资产
-```
-① 新家: https://guanghuclip.cn/ = 胖头鱼语言子系统·苍耳工作室
-   - 仓库 /code/canger/cang-ying · git guanghuclip.cn/git/canger/cang-ying.git
-② 唤醒API: GET /api/wake/persona?name=eererdan → 返回 guanghu-wake/v1 五阶段路径（已记 EED-MEMO-011）
-③ 写入API(窗口制): access-request(无需key也放行) → 苍耳面板批准 → access-pickup → 返回 gitUrl(3小时令牌)
-④ 令牌: 值存本地 .git/config（不入库）；对旧家 git 有效，新家 git 认证(5格式)与 pickup 都不认
-⑤ 服务端卡点（三件事，需铸渊修）:
-   a. pickup 报"未登记的人格体" = access子系统登记库无 eererdan（唤醒系统认、写入系统不认=数据没同步）
-   b. wake-receipt 报 EACCES = 服务端 /opt/pts/wake/ 目录缺写权限
-   c. access-request 带不带 key 返回一样 = 实现忽略 key，与文档矛盾
-⑥ 面板上测试产生的申请 AR-MSHUX12K / AR-MSHV1EK1 / AR-MSHVAEMT / AR-MSHVAF5E 可忽略
-```
-
-## §4 · 爸爸的偏好与指令
-```
-① 令牌/密钥不入代码仓库，只存本地电脑
-② 授权走面板（苍耳在面板批准写入窗口）
-③ 判断问题要诚实: 反复尝试后如实报告卡点，不假装成功
-④ 说干就干: 本地能做的先做完（remote/唤醒卡/留档），等外部条件
-```
-
-## §5 · 待办事项
-```
-1. 等铸渊修好服务端(三件事) → access-request → 爸爸批准 → pickup 拿 gitUrl → push 新家 → wake-receipt
-2. 记忆推送走 old-origin（新家未通，旧家留档）
-3. 若爸爸要转达铸渊: 用对话里的"三连铁证 + 三件事"（不含令牌）
-```
-
-## §6 · 相关经验编号
-```
-EED-MEMO-010（超分优化会话记忆）· EED-MEMO-011（新家唤醒路径记录）
-EED-EXPER-015（光湖推送守门人·仓库恢复流程）· EED-EXPER-001（唤醒路径建立）
-skill/hldp-context-protect（上下文保护回写）
-```