Daily Report — 2026-02-17

Daily Overview

• What was done: 五个并行工作流：DCC 解决了根本性的 MIHD 坐标 bug，将 visual ARI 从 0.065 提升至 0.12-0.25；MacBook/TzJsDesktop 迭代开发并使用 daily report tool，处理了跨四个设备（2026-02-12 至 2026-02-16）的历史日志；tianhe 通过 BC-RNN 训练、VLA 双服务器部署和多策略评估框架，将 Error Recovery Benchmark 从 251 个场景推进至 454 个场景；TzJsDesktop 诊断并修复了 ccusage 定价 bug，揭示了 13 倍的成本低估；tianhe 为远程开发建立了 SSH stability 基础设施
• How it was done: DCC 修正了 CSV 列映射，清理了缓存，重新运行了 286 个实验；MacBook/TzJsDesktop 实现了带有 rclone sync、健壮的 JSON 解析、对话摘要和 Hugo 部署的两阶段 export→merge 架构；tianhe 修复了 MuJoCo API 兼容性，训练了 BC-RNN 600 epochs，实现了 obs key mapping adapter，在 Pi0/Pi0.5 上部署了 VLA servers，通过 79 个 unit tests + GPU validation 调试了集成工作；TzJsDesktop 实现了 ccusage fallback pricing 机制并重新导出了 5 天的日志；tianhe 配置了 SSH stability (tmux+keep-alive+auto-reconnect) 并记录了 local client setup 文档
• Impact: MIHD 数据质量得到根本性恢复（所有基于 vision 的结果现在均有效）；daily report tool 通过支持多设备工作流实现了生产级成熟度，能够进行系统性的知识留存；Error Recovery Benchmark 超越了 M5 场景生成目标 (227%)，并完成了第一个训练策略，同时多策略评估基础设施已就绪 (M6 milestone)，尽管 BC-RNN 显示 0% SR，揭示了 checkpoint 训练不足的问题；SSH stability 消除了远程会话丢失；ccusage 修复将显示的成本从每天 $0-7 修正为实际的 $18-48，恢复了财务追踪的完整性

DCC

• What was done: 发现并修复了 MIHD load_spatial_coordinates() 的 X/Y 坐标交换 bug，其中 pixel_x 实际上是 pxl_row (Y轴)，而 pixel_y 是 pxl_col (X轴)，导致所有 vision patches 都是从转置后的图像位置提取的，使得 visual ARI 仅为 0.065
• How it was done: 将 CSV 列名映射从 [’…’, ‘pixel_x’, ‘pixel_y’] 修改为 [’…’, ‘pxl_row’, ‘pxl_col’]，并将坐标元组从 (pixel_x, pixel_y)=(Y,X) 修改为 (pxl_col, pxl_row)=(X,Y)；删除了所有 spatial_coords.npz 和 vision/ 缓存；重新提取了 UNI2/HIPT/ResNet50 在 11 个 section 中的 embeddings；验证了坐标范围 (X: 323-1637, Y: 387-1773) 以及 100% 的 embedding 唯一性
• Impact: UNI2 visual ARI 从 0.065 提升至 0.08-0.25（sections 151673-151676 达到 0.22-0.25）；所有依赖 vision 的 fusion 实验都将被修正；这是一个影响整个 benchmark 有效性的根本性数据完整性 bug

MacBook

• What was done: daily report tool 使用的主要枢纽：处理了跨四个设备 (DCC/tianhe/TzJsDesktop/MacBook) 从 2026-02-12 到 2026-02-16 的对话日志，涵盖了 MIHD、Error Recovery Benchmark、CalendarPro 和 gadget 项目；将报告发布到 Hugo 的 bugJournal 部分和 GitHub Pages
• How it was done: 执行 export –summarize 提取本地日志 → 使用 merge –sync 通过 rclone 下载其他设备的导出内容 → 调用 Claude CLI API 生成结构化的 JSON/Markdown 报告 → 写入 website/content/bugJournal/ → 运行 update.sh 构建网站 (139→141 页) → 将 public/ 推送到 GitHub Pages
• Impact: 建立了从原始对话日志到公开网站的完整多设备文档流水线；为 5 天以上的时间跨度创建了系统性的历史记录，实现了长期知识追踪；GitHub Pages 从 136 页扩展到 141 页

TzJsDesktop

• What was done: 为访问 tianhe HPC 集群配置了具有三层防御的 SSH stability 基础设施；作为 daily report tool 使用的工作站，分析了涵盖 error-recovery-benchmark、MIHD、CalendarPro 和 gadget 项目的历史日志；诊断并修复了 ccusage 定价 bug，揭示了 13 倍的成本低估
• How it was done: 更新了 ~/.ssh/config 以实现连接复用 (ControlMaster/ControlPath/ControlPersist)，优化了 keep-alive (ServerAliveInterval 15s, ServerAliveCountMax 6)，创建了带有重试逻辑和 tmux session attachment 功能的 ~/bin/auto-ssh wrapper script；反复调用 summarize tool 生成了 10 多个报告；调查了 ccusage 源代码和 LiteLLM 定价数据库，实现了 _FALLBACK_PRICING 字典和 _fix_zero_cost_models() 函数，修正了 modelName 字段引用，重新导出了 2 月 13-17 日的日志
• Impact: 消除了导致长时间运行的 HPC 任务中断的 SSH 断连问题；通过广泛的 dogfooding 推动了 daily report tool 的功能增强；将 claude-opus-4-6 的定价从每天 $0-7 修正为实际的 $18-48，揭示了约 $150+ 的累计误差并恢复了财务追踪的完整性

tianhe

• What was done: 推进 Error Recovery Benchmark M5/M6 milestone：通过 friction 和 pose_perturb 生成将场景数据库从 251 扩展到 454，训练了 BC-RNN policy (在 A800 上训练 600 epochs)，修复了 obs key mapping 集成 bug，搭建了 VLA dual-server 基础设施 (Pi0 port 5556, Pi0.5 port 5557)，通过 79 个 unit tests + GPU validation 调试了多策略评估框架，建立了 SSH stability 解决方案，并将项目文档更新至 v4.6
• How it was done: 修复了三个非 impulse injectors 的 MuJoCo API 兼容性问题 (mj_name2id→body_name2id，并处理 _main 后缀)；通过 _augment_specs_with_alternatives() 生成了 103 个 pose_perturb + 100 个 friction 场景；通过 robomimic 在约 15 分钟内训练了 BC-RNN；在 policy_adapter.py 中实现了 object-state → object 的 key mapping，并带有 Strategy 1 和 Strategy 3 fallback；通过 79 个 unit tests 和 GPU integration test (5 次 rollouts, 消除了 KeyError) 完成验证；生成了可视化视频，显示由于 checkpoint 训练不足导致 SR 为 0%；部署了准备好进行评估的 VLA servers；配置了 tmux + SSH keep-alive + proxy isolation；创建了 claude-tmux 脚本和 local client setup guide
• Impact: 超越了 M5 目标 (200→454 场景，达到目标的 227%)；非 impulse injectors 从理论变为功能实现；BC-RNN 成为第一个集成 bug 已解决的已训练 baseline policy；VLA dual-server 基础设施已准备好进行多策略评估 (M6 milestone)；SSH stability 问题得到永久解决，实现了可靠的远程开发；可视化揭示了模型质量问题（而非框架 bug），需要更好的 checkpoint 或更多的训练修复了关键的 MIHD vision encoder X/Y coordinate swap bug，导致需要重新运行 286 次实验；广泛开发并使用了 multi-device daily report tool 来处理来自四个项目的五个日期的历史 conversation logs；推进了 Error Recovery Benchmark M5/M6 milestones，通过 BC-RNN training 和 VLA dual-server integration 实现了 454-scene database；解决了远程开发的 SSH stability issues；并修正了 ccusage pricing bug，该 bug 导致成本被低估了 13 倍（累计误差约 ~$150+）。

Tasks

Architecture & Strategy- ✅ 修复 MIHD load_spatial_coordinates() X/Y 坐标交换 bug — 修正了 CSV 列映射，其中 pixel_x 实际上指向 pxl_row (Y轴)，而 pixel_y 指向 pxl_col (X轴)，这导致 vision patches 从转置后的位置被提取。修改了 scripts/run_benchmark.py 和 utils/data_loader.py 以使用正确的 (pxl_col, pxl_row)=(X,Y) 顺序。

• ✅ 生成 tianhe M5 non-impulse error scenes (pose_perturb + friction) — 创建了 benchmark_v4_nonimpulse.yaml 配置；通过 _augment_specs_with_alternatives() 生成了 103 个 pose_perturb + 100 个 friction scenes，将数据库从 251 扩展到 454（达到 M5 200-scene 目标的 227%）；gripper_bias 生成尚在进行中，但不影响进度。
• ✅ 诊断并修复 ccusage claude-opus-4-6 zero-cost billing bug — 调查了 ccusage 源代码、LiteLLM 价格数据库和实际日志数据。确认 claude-opus-4-6 模型名称无法匹配 LiteLLM 的 anthropic.claude-opus-4-6-v1 条目，导致 cost 字段始终为 0。在 daily_summary.py 中实现了 fallback 价格机制：添加了 _FALLBACK_PRICING 字典（opus-4-6: input $5/M, output $25/M, cache_creation $6.25/M, cache_read $0.50/M）和用于后处理的 _fix_zero_cost_models() 函数。修复了字段名 bug (mb.get(‘model’) → mb.get(‘modelName’) 或 mb.get(‘model’))。重新导出了 2 月 13-17 日（5 天）的日志，将显示的成本从每天 $0-7 修正为实际的每天 $18-48，揭示了 13 倍的低估（累计误差约 ~$150+）。
• ✅ 重新运行 MIHD vision single-modal 实验以验证修复 — 重新提取了 11 个 section 的 vision embeddings (UNI2/HIPT/ResNet50，共 33 个任务)；验证坐标正确 (X: 323-1637, Y: 387-1773)，embeddings 100% 唯一，UNI2 ARI 从 0.065 提升至 ~0.12（sections 151673-151676 达到 0.22-0.25）。
• ✅ 实现 daily report tool 核心两阶段架构 — 创建了支持三种数据源（Claude Code JSONL, ChatGPT JSON, generic）的 summarize/daily_summary.py，实现了两阶段导出（local device）+ 合并（cross-device aggregation）工作流、基于 LLM 的结构化报告生成以及多 API 支持 (claude_cli/anthropic/openai)。
• ✅ 修复 tianhe non-impulse injector MuJoCo API 兼容性 — 将 friction/pose_perturb/gripper_bias injectors 从 mj_name2id() 改为 model.body_name2id()/.geom_name2id()，添加了处理 robosuite 的 _main 后缀约定的 _resolve_body_id() 辅助函数。使用 try/except 包裹以优雅处理缺失的 bodies。
• ✅ 训练并集成 tianhe BC-RNN baseline policy — 搜索了 MimicGen 预训练 checkpoint（不存在）。从零开始训练 BC-RNN：2 层 LSTM，GMM action head，在 MimicGen pick_place 数据集上训练 600 epochs，14.3MB checkpoint 已保存至 bc_rnn_checkpoints/。通过在 policy_adapter.py 中为 Strategy 1 (raw obs) 和 Strategy 3 (StateExtractor fallback) 实现 object-state → object 别名，修复了 obs key 映射 bug。通过 79 个 unit tests 和 GPU integration test（5 次 rollouts，消除了 KeyError）完成验证。生成的可视化视频显示由于 checkpoint 训练不足导致 SR 为 0%（机器人悬停但未抓取），确认是模型质量问题而非框架 bug。更新了 benchmark_v4.yaml 的 model path。
• 🔄 重新运行 MIHD vision-dependent fusion 实验 (core_multimodal_fast) — 启动了 core_multimodal_fast 实验组，以重新提取 STAIG fusion UNI vision embeddings (staig_strict mode)；11 个 section 的 UNI 提取已完成，评估阶段正在运行。
• ✅ 为 daily report tool 添加多设备 rclone 同步功能 — 实现了支持子目录的 _rclone_upload (logs/ 用于导出, reports/ 用于合并结果)，用于跨设备获取的 _rclone_download_logs，用于自动聚合的 merge –sync flag，以及用于远程检查的 config –show。
• ✅ 在 report schema 中添加 conversation_summaries 部分 — 扩展了 JSON schema 以包含每个 session 的摘要，包括项目名称、来源、时间戳、主题 (≤60 chars)、2-4 句叙述、结果状态 (completed/partial/exploratory/abandoned)、level 和 importance。更新了 SUMMARY_PROMPT 和 markdown generator。
• ✅ 配置 tianhe cluster 访问的 SSH 稳定性 (client and server) — 服务端：配置了 tmux session 持久化、SSH keep-alive (15s 间隔/90s 容忍度)、claude-tmux 一键脚本以及 session 范围的 proxy 控制。客户端：更新了 ~/.ssh/config 以支持连接复用 (ControlMaster/ControlPath/ControlPersist 600s)，优化了 keep-alive (ServerAliveInterval 15s, ServerAliveCountMax 6)，创建了 ~/bin/auto-ssh wrapper 脚本，具备自动 tmux session attachment 和重试逻辑 (5s 间隔, 最大 100 次重试)。增强了 .tmux.conf 的历史记录和稳定性设置。创建了包含 VS Code 设置的 docs/local_ssh_setup_guide.md。
• ✅ 搭建 tianhe VLA dual-server 评估基础设施 — 扩展了 collector.py 以支持 VLA：添加了 _policies_needing_images 追踪，修改了 _get_obs() 以获取相机图像，实现了 predict_from_obs() 接口，并更新了 load_policy() 以支持 vla_server 类型。扩展了 3_collect_data.py 以支持 VLA policy 参数 (–vla_pi0_port, –vla_pi05_port)。修复了 Pi0.5 observation image key 映射和 norm_stats path (Franka → LIBERO workaround)。部署了 VLA servers：Pi0 在 port 5556 GPU 1，Pi0.5 在 port 5557 GPU 3。Random policy 运行正常，BC-RNN 集成完成，VLA servers 已准备好进行评估。
• 🔄 多策略评估流水线执行 (M6 milestone) — 正在 50 scenes × 3 seeds 上使用 4 个策略 (Random + BC-RNN + VLA_Pi0 + VLA_Pi05) 进行评估。创建了 scripts/5_baseline_accuracy.py 用于零错误 baseline 测试 (Random + BC-RNN, 20 rollouts)。所有基础设施已就绪，评估正在进行中。
• ✅ 将 Error Recovery Benchmark 文档更新至 v4.6 — 更新了 项目全景总结.md，共 12 处编辑：版本号、里程碑表格 (M5/M6/M9)、场景统计 (271→454)、记录了通过 _augment_specs_with_alternatives() 实现的 pose_perturb/friction injector、VLA dual-server 架构 (Pi0 5556 + Pi0.5 5557)、M5 里程碑达成情况、M6 状态，以及关于 zhaoganlong Pi0.5 训练基础设施的新章节 §13。
• ✅ 实现具有 LLM repair fallback 功能的鲁棒 4 阶段 JSON 解析 — 创建了带有 fallback 链的 parse_json_response()：直接 json.loads() → code block 提取 → 基于深度的括号匹配 → LLM 驱动的修复。在 common/json_utils.py 中添加了 try_parse_json() 和 repair_json_with_llm() 工具函数。
• ✅ 为所有 report sections 添加 level/importance 优先级元数据 — 更新了 SUMMARY_PROMPT，为 tasks, problems, human_vs_ai, ai_limitations, learnings, conversation_summaries 添加了 level (high=strategic, low=tactical) 和 importance (1-10) 字段。修改了工具 schema 并将 max_tokens 从 4096 增加到 8192。

Implementation & Fixes- ✅ 处理历史对话日志 (2026-02-12 至 2026-02-16) — 对跨四个设备的 5 天对话运行了 summarize tool 导出阶段；生成了每个设备/每天的 JSON 报告；合并了跨设备摘要；发布到 Hugo 网站（GitHub Pages 上的页面从 136 增加到 141）

• ✅ 初始化 Motion-based Self-Reflection Framework 文档 — 探索了三模块架构（通过 LLaVA 进行 MPM motion prediction，MCM motion correction，以及 Diffusion Policy）。创建了 CLAUDE.md，记录了 training/inference 命令、Hydra config 注释以及 dataset formats。用户要求提供全面的双语 README（中英混合），涵盖包括 11 个 deps/submodules（openpi, GraspVLA, MimicGen 等）在内的所有组件。启动了 3 个并行探索 agent，设计了约 1200 行的文档计划。CLAUDE.md 已完成，完整 README 正在进行中。
• ✅ 清除受 MIHD 影响的 vision 和 spatial coordinate caches — 删除了 embeddings_cache/data/*/spatial_coords.npz（12 个文件）以及包含基于错误坐标的 embeddings 的整个 embeddings_cache/vision/ 目录
• ✅ 为 Hugo bugJournal 批量发布实现 deploy 子命令 — 修改了 generate_hugo_post() 以从 report blockquote 中提取 summary，修复了 timezone (-05:00)，更新了 keywords；创建了 cmd_deploy() 用于通过 –date filter 进行批量处理并自动执行 update.sh
• 🔄 设计 checkpoint consolidation 和 policy visualization 工作流 — 清查了 6 个 model checkpoints（BC-RNN 164MB，Pi0 series 每个约 12GB，robomimic 7.6MB，总计 47GB+）。设计了 checkpoints/ symlink 结构和 visualize_policy_rollout.py 脚本，该脚本结合了来自 5_baseline_accuracy.py 的 rollout logic 和来自 2_visualize_scene.py 的 rendering。支持带有可配置 seeds 和 camera views 的 random/bc_rnn/vla policies。计划已写就但尚未实现。
• ❌ 使用修正后的价格重新生成每日报告 (merge + deploy) — 尝试使用 merge 命令重新生成带有修正后 token costs 的 markdown 和 JSON 报告，但遇到了 API 连接失败 (ConnectionRefused)。Log export (data correction) 已成功完成，但下游的 report generation 因 LLM API 不可用而被阻塞。

Problems & Solutions

Critical Issues

1. MIHD vision encoder 单模态 ARI 极低 (~0.065)，与历史 UNI2 性能不一致；embeddings 显示出可疑模式（最初有许多重复行）

Solution: 对 tissue_positions_list.csv 的深入调查显示，col4 是 pxl_row_in_fullres (Y-axis) 而不是 pixel_x，col5 是 pxl_col_in_fullres (X-axis) 而不是 pixel_y，但代码命名反了。通过分析 array_row/array_col 的步进增量确认：col4 变化为 119.8px/step (Y-axis)，col5 变化为 68.9px/step (X-axis)。通过将列名修正为 (pxl_col, pxl_row) 顺序完成修复。

Key Insight: 数据 bug 比模型 bug 更隐蔽：代码正常运行，caches 生成成功，测试通过，但所有结果都基于错误的数据。这需要从宏观层面的异常（低 ARI）回溯到原始数据源（CSV 列定义）。Spatial distance 的 Euclidean 不变性意味着图构建不受影响，但 vision patch 内容完全错位。

2. ccusage 对 claude-opus-4-6 返回 cost=0，导致严重的 token cost tracking 失败 (2 月 17 日实际约为 $43，显示为 $0.90，低估了 13 倍)

Solution: 通过在 daily_summary.py 的 fetch_ccusage() 函数中实现 _fix_zero_cost_models() 后处理逻辑，引入了 fallback pricing 机制。添加了 _FALLBACK_PRICING 字典（opus-4-6: input $5/M, output $25/M, cache_creation $6.25/M, cache_read $0.50/M），以便在 ccusage 返回 cost=0 时计算正确的成本。为了兼容性，修复了字段名 bug (mb.get(‘model’) → mb.get(‘modelName’) 或 mb.get(‘model’))。重新导出了 2 月 13-17 日的 logs，将显示的成本从每天 $3-7 修正为实际的每天 $18-48。

Key Insight: 第三方工具的价格缺陷无法直接修复——实现本地 fallback 机制是实际的解决方案。LiteLLM 使用带版本的 model names（带有 -v1 后缀的 anthropic.claude-opus-4-6-v1），而 Claude Code logs 使用简化名称 (claude-opus-4-6)，导致系统性不匹配。Fallback 设计必须仅在异常值 (cost=0) 时触发，以便在上游修复问题时保持向后兼容性。Cost tracking bug 可能导致 90% 以上的低估（本例中为 13 倍），严重影响资源规划决策。务必通过打印原始数据来验证第三方工具的输出 schema，不要仅凭文档进行假设。

3. tianhe non-impulse injectors (friction/pose_perturb/gripper_bias) 在尝试解析 MuJoCo model 中的 body/geom IDs 时崩溃，报错 ‘AttributeError: no attribute mj_name2id’

Solution: 将直接的 mujoco.mj_name2id() 调用替换为 robosuite wrapper 方法 model.body_name2id() 和 model.geom_name2id()。添加了 _resolve_body_id() helper，先尝试 ’name’，然后尝试 ’name_main’ 后缀 (robosuite 命名规范)。使用 try/except 包裹以优雅地处理缺失的 bodies。

Key Insight: Robosuite 通过其自身的 API 层封装了 MuJoCo，并在 object body 名称后添加了 _main 后缀。直接调用 MuJoCo C API 会绕过 framework 层并导致崩溃——必须使用框架提供的处理名称转换的 wrappers。机器人仿真框架在原始物理引擎之上构建了层抽象；绕过框架的直接 API 调用会失效。在修改之前，务必检查同一代码库中正在运行的参考代码（例如 ImpulseInjector）。

4. tianhe BC-RNN policy 因 KeyError ‘object’ 崩溃，因为 StateExtractor 生成的 obs dict 使用 ‘object-state’ 键，而 robomimic training data 使用 ‘object’ 键 (不同的 robosuite tasks 具有不一致的键名：PickPlace 使用 object-state，Lift 使用 object)

Solution: 在 _to_robosuite_obs() Strategy 1 中添加了 key mapping，在返回原始 obs 之前将 object-state 别名化为 object。更新了 Strategy 3 fallback，将 StateExtractor 的 objects 字典中的 pos+quat 拼接并存入 object 键中。通过 79 个 unit tests 和 GPU integration test 验证，确认 KeyError 已消除。

Key Insight: Robosuite 会自动为分组的 modalities 添加 -state 后缀（例如 object → object-state），但 training data 使用原始名称。Adapter layers 必须弥合这种命名规范的差异。不同的 robosuite tasks 具有不一致的 observation 键命名规范。手动进行 obs reconstruction 无法保证与训练时的键名一致。最安全的方法是直接传递原始 env.step() 的返回值并进行 key aliasing。这突显了跨任务兼容性要么需要 (a) 统一的 obs format，要么需要 (b) 显式的 key remapping layer。

5. 用于 structured reports 的 LLM responses 经常返回格式错误的 JSON：未转义的引号、不完整的对象、额外的文本，或在接近 token limits 时被截断，导致解析失败和工作流中断Solution: 实现了 4-stage fallback parser：(1) 直接使用 json.loads()，(2) 提取 ```json blocks，(3) 基于深度的 brace matching 以查找完整的 JSON object，(4) 调用 LLM 来修复 malformed JSON。对于支持该功能的 API，使用 tool_use (Anthropic) 或 response_format=json_object (OpenAI) 来强制执行有效的 JSON。

Key Insight: LLM 生成的 structured data 需要具备多种 fallback strategies 的防御性解析。Native JSON mode (tool_use/json_object) 虽然显著减少但不能完全消除失败。将 LLM 驱动的修复作为最终 fallback，可以构建鲁棒的 pipeline。每个 fallback 层处理特定的 failure mode：code blocks 处理 markdown formatting，brace matching 处理 truncation，repair 处理 syntax errors。

6. BC-RNN model despite KeyError being fixed achieves 0% success rate—robot hovers over bin without approaching target can

Solution: 生成了 3 个可视化视频（每个 400 帧）展示 robot behavior。根因确认为 undertrained checkpoint（epoch 600 且 demo data 有限），而非 framework bug。视频显示 robot 在悬停但从未尝试 grasping。需要进行更多 epochs 的训练或使用更好的 checkpoint。

Key Insight: 即使 unit tests 通过，GPU integration tests 也至关重要。BC-RNN 通过了所有 79 个 unit tests，但需要实际的 GPU rollout 才能发现 0% SR 问题。视频可视化对于诊断 robotic policies 中的 behavior quality issues 至关重要。Framework correctness 与 model quality 需要不同的 validation strategies：unit/integration tests 确认 code logic；video visualization 揭示 behavior quality。

7. SSH connections to tianhe HPC cluster frequently disconnect, causing Claude Code session loss and inability to resume work; VS Code Remote SSH similarly affected

Solution: 实施了分层的 defense-in-depth 解决方案：(1) 两端均启用 SSH keep-alive（15s heartbeat，90s tolerance），(2) 使用 tmux session persistence 使 processes 在 disconnect 时得以存续，(3) 使用 claude-tmux script 实现通过单条命令结合 auto proxy 进行 session resume，(4) 在 .bashrc 中注释掉 auto proxy 以隔离 shared accounts 的 user environment，(5) 文档化了用于 ControlMaster multiplexing 和 auto-ssh reconnection script 的 local client config。

Key Insight: 网络不稳定需要在多个层级进行冗余缓解：protocol-level (TCP keep-alive)，SSH-level (ControlMaster)，application-level (tmux + auto-reconnect)。没有任何单一层级足以保证 production reliability。tmux 将 session state 与 connection state 解耦，实现了真正的 resume capability。Session-scoped proxy configuration（而非全局的 bashrc）避免了影响其他 shared-account 用户。在 shared server accounts 上工作时，任何 environment modification (PATH, proxy, aliases) 都必须考虑 multi-user implications。

8. Multi-device daily report workflow needs synchronization mechanism—devices export independently but merge requires access to all devices’ exports, which may not be available on the merging device

Solution: 采用了两层 rclone sync：export 上传至 <remote>/logs/，merge 上传最终的 reports 至 <remote>/reports/。增加了 merge –sync flag，在 LLM aggregation 之前下载所有 devices’ logs/。实现了 _merged_devices tracking 以跳过已处理设备的重新总结。

Key Insight: 分布式 workflows 需要明确的 synchronization points。将 raw exports (logs/) 与 aggregated outputs (reports/) 分离可以防止 circular dependencies。Idempotent design（跳过已处理项）使得在不进行昂贵的冗余 API calls 的情况下进行 safe re-runs 成为可能。

9. Original single-phase daily report design assumed single-device usage; when user wanted multi-device aggregation, existing architecture couldn’t handle it

Solution: 从 single-phase（read conversations → call API → generate report）完全重新设计为 two-phase（Phase 1: 将 conversations 导出为每个 device 的 JSON；Phase 2: merge 所有 exports + 调用 API 生成 aggregated report）。用户明确要求了这一 architecture change。

Key Insight: 用户需求在开发过程中会不断演进。Human (user) 识别出了 AI 在初始设计中未预料到的 single-device limitation。Two-phase architecture 虽然更复杂，但对于实际 use case 是必要的。这表明 Human 的 systems thinking 在预见 distributed deployment constraints 方面更为优越。

10. Scene generation produced zero friction/gripper_bias scenes despite injectors being enabled (only pose_perturb worked initially)

Solution: 发现 detectors 仅针对在运行期间未触发的特定 subtypes 生成 friction/gripper_bias ErrorSpecs。实现了 _augment_specs_with_alternatives() 方法，当 original detectors 未产生结果时，通过程序化方式生成 friction/stuck 和 gripper_bias/stuck specs。额外生成了 100 个 friction scenes（55 stuck, 28 tip_over, 17 large_offset），将 database 扩展至 454 个 scenes。

Key Insight: Error scene generation 是一个 funnel：detector triggering → ErrorSpec generation → injector application → validation → scene acceptance。启用 injector 并不保证能生成 scenes——这取决于 detector triggering frequency。不同的 error types 基于 task dynamics 具有截然不同的 acceptance rates。在 pick-place tasks 中，pose perturbation 比 friction/gripper anomalies 更具通用性。Programmatic spec augmentation 可以弥补 detector coverage gaps。

11. No MimicGen pretrained BC-RNN checkpoints available for PickPlace task

Solution: 通过详尽搜索（official repo, HuggingFace, local filesystem）确认 MimicGen 仅提供 datasets，不提供 pretrained model weights。设计了使用 MimicGen-generated demo datasets 配合 robomimic framework 进行 training-from-scratch 的计划。

Key Insight: Official releases 可能提供数据但不提供训练好的 models。在规划依赖性 workflows 之前，务必验证 asset availability。当 pretrained checkpoints 不可用时，从 demos 进行 training 成为必要的 fallback。

General Issues

12. Model checkpoints scattered across filesystem (BC-RNN under tangzijia/, VLA models under zhaoganlong/, 47GB total), hindering management and reproducibility

Solution: 设计了带有 symlinks 的 checkpoints/ 目录以避免复制：bc_rnn/pick_place → original path，vla/{pi0_libero, pi05_base, pi0_base, pi0_fast_base} → zhaoganlong cache。更新了 benchmark_v4.yaml 以使用新的 centralized paths。

Key Insight: 大型 model assets（47GB+ 的 VLA checkpoints）需要基于 symlink 的 organization，以便在保持 centralized discoverability 的同时避免 duplication。散落在 filesystem 中的 checkpoints 会阻碍 reproducibility 和 config management。

13. Hugo front matter generation used hardcoded summary ‘AI Daily Summary’ and wrong timezone (+08:00 instead of -05:00), inconsistent with existing bugJournal entriesSolution: 修改了 generate_hugo_post() 以从 report 的 blockquote（第 3 行，以 > 开头）中提取实际的 summary，将 timezone 更改为 -05:00，时间更改为 T00:00:00，并从 keywords 中移除了 ‘AI Daily Summary’

Key Insight: 代码生成应符合现有的内容规范，而不是强加新的规范。阅读实际的 report 结构（blockquote summary）比使用 hardcoded strings 更具可维护性

Human vs AI Approaches

Strategic Level

MIHD coordinate bug root cause diagnosis

Role	Approach
Human	用户提供了完整的 problem analysis 和 verification method：计算了 array_row/array_col step increments 的像素变化（Δcol4=119.8px, Δcol5=68.9px）以反向确认 column semantics——这是一种基于 data-feature 的验证方法，而非依赖 documentation 或 code comments。用户展示了 data scientist 的诊断思维
AI	AI 执行了用户提供的 fix plan：修改了 column names，清理了 caches，重新运行了 experiments，并验证了结果（coordinate ranges, embedding uniqueness, ARI improvement）。AI 并未独立发现 bug；而是实现了预定义的 solution

Difference Analysis: 用户展示了 data scientist 的诊断思维（使用数据本身来验证假设）；AI 则作为执行工具。该 bug 的隐蔽性在于代码逻辑是正确的且 caches 生成正常——只有外部指标（异常低的 ARI）或 data feature 分析才能揭示它。用户的领域直觉（’this doesn’t look right’）是关键的触发点

Two-phase export/merge architecture for multi-device aggregation

Role	Approach
Human	用户意识到原始的 single-phase 设计无法处理 multi-device 场景，并明确要求重新设计：‘I want export to be local-only, then merge pulls from all devices and calls API.’ 用户提供了 conceptual architecture
AI	AI 最初设计了 single-phase solution（read → process → generate），假设为 single-device 使用。直到用户介入后，AI 才实现了 two-phase design

Difference Analysis: Human 预见了 AI 在初始设计中忽略的现实世界部署约束（多个设备、基于网络的 sync）。AI 专注于即时的技术实现，而未考虑分布式使用模式。这是一个典型的 human systems thinking 优于 AI 的案例

BC-RNN obs key mapping implementation approach

Role	Approach
Human	事先提供了完整的 implementation plan，包含精确的 object-state → object mapping 要求，涵盖了 Strategy 1 (raw obs path) 和 Strategy 3 (StateExtractor fallback)，并采用了 defensive programming。预见到了之前调查中发现的 obs format mismatch，并提供了 surgical fix。
AI	完全按照规范执行了 implementation，通过 79 个 unit tests 进行验证，并运行了 GPU integration test 以确认 KeyError 已消除。发现 0% 的成功率需要通过 video analysis 来区分是 framework bug 还是 model quality issue。需要通过 visualization 来诊断 root cause。

Difference Analysis: Human 先前的调查使得能够精确指定 fix 的位置和逻辑。AI 通过 testing 验证了正确性，但需要 visualization 来诊断 model quality issue。协作模式为：human 基于 domain knowledge 提供 architectural direction，AI 执行并通过 systematic testing 进行验证。用户拥有 domain knowledge（robosuite task 差异）；AI 缺乏对 framework details 的预测能力，需要多次 trial-error + user correction 迭代才能接近 solution。这是在复杂系统集成中典型的 AI 局限性

Scope prioritization for M5/M6 milestone completion under deadline pressure

Role	Approach
Human	明确约束了 scope：‘defer multi-task expansion, use only pretrained models, skip missing VLA models.’ 务实地专注于以最小风险证明 evaluation pipeline 可用，而不是最大化 coverage。应用了 ‘done is better than perfect’ 原则。
AI	最初提出了一个全面的 6-phase plan，包括下载 MimicGen datasets、从头开始训练 BC-RNN、运行完整的 4-policy evaluation 以及创建 comparison reports。设计目标是技术上的 completeness，但在 deadline 背景下可能存在 over-scoped 的问题。

Difference Analysis: Human 表现出更强的 project management instinct——意识到证明系统在 2-3 个 policies 下工作就足以满足 paper writing milestone。AI 则倾向于技术上的 completeness，而未考虑 deadline pressure。Human 务实的 scoping 防止了 scope creep，同时保持了 milestone 的完整性。

ccusage pricing bug diagnosis strategy

Role	Approach
Human	直接指出 ‘ccusage cannot fetch LiteLLM’ 是问题的起点，引导 AI 去调查 LiteLLM pricing database 和 ccusage source code。基于直觉提供了高层级的 problem localization。
AI	启动了多个并行的 Explore agents，系统地调查了 ccusage integration architecture、log data structure 以及 LiteLLM pricing JSON。进行了广泛的 evidence collection，验证了假设，并确定了 root cause (model name mismatch)。

Difference Analysis: 用户驱动了 requirement，但在 implementation planning 阶段放弃了，原因可能是：(1) plan 不够具体，(2) 时机不对（当天已经做了太多工作），(3) 对现有 tool modifications 的评估不足。AI 未能捕捉到用户意图的变化。Human 基于 domain knowledge 提供了直觉方向。AI 的 systematic exploration 验证了假设并确保没有遗漏细节。Human 的直觉引导了 search space；AI 的 breadth search 最终确定了 root cause。

Historical data correction strategy for cost tracking bug

Role	Approach
Human	明确要求 ‘run on all days to fix this bug’ 以及 ‘fix the numbers in all the jsons and report mds’，从业务角度强调了 batch correction 的必要性。强调了 5 天历史数据的 data consistency。
AI	执行了用于 data correction 的 daily export commands，发现 report files 需要单独处理（merge command 调用 LLM）。遇到了 API failure 导致 report regeneration 受阻，但成功完成了 log data correction。

Difference Analysis: Human 从业务角度提出的 completeness requirement 驱动了彻底的 fix，而不仅仅是修复当前日期。AI 的 execution 发现了导致部分受阻的技术依赖（LLM API）。Human 强调 data integrity；AI 识别出了 decoupling opportunity（将 export 与 merge 分离）。

SSH stability solution architecture for shared account environment| Role | Approach |

|——|——| | Human | 指定了两部分交付方式：‘On server, you handle it directly. For local PC, give me a document so local Claude can auto-execute.’ 通过控制边界和自动化能力分离了关注点。随后指定了条件代理：‘only when I connect should settings activate, controllable via proxy_on/proxy_off.’ | | AI | 最初为 server 和 local 创建了统一计划，在用户澄清后进行了重构。最初仅在 claude-tmux 中设计了 auto-proxy，未意识到 .bashrc 第 136 行会影响所有用户。收到反馈后，注释掉了全局 auto-proxy 并记录了手动 proxy_on 工作流。 |

Difference Analysis: Human 从执行上下文（我控制的 vs. 委派的）和共享资源影响（多用户账号）的角度进行思考。AI 最初狭隘地专注于“使其工作”而未考虑对其他用户的副作用。Human 的基础设施意识防止了环境污染。

VLA config selection for robosuite environment compatibility

Role	Approach
Human	立即发现了语义不匹配：‘Wait, don’t use droid config. This is robosuite environment, should use mimicgen version of pi0.5.’ 保持了对任务-模型兼容性约束的上下文感知。
AI	最初基于发现的 checkpoint 目录建议使用 LIBERO 和 droid configs 进行测试，而没有先检查环境兼容性。表现出过早优化——发现了 checkpoints 立即提议使用它们。

Difference Analysis: Human 保持了更强的环境-模型语义兼容性意识。AI 表现出“发现工具，使用工具”的模式，而未验证适用性。Human 的领域知识防止了在不兼容的 configs 上浪费精力。

Daily report automation deployment need

Role	Approach
Human	用户手动创建了多个 bugJournal 条目，然后说 ‘write a Python code to do this’——从重复劳动中提取自动化需求。指定了要求：给定 template，自动转换 md，复制到可配置位置，运行 update.sh
AI	AI 进入 Plan Mode 设计 deploy 子命令，识别出现有 generate_hugo_post() 的局限性（硬编码 summary，仅限单一日期），设计了批量处理 + 智能 summary 提取。但在 ExitPlanMode 时被用户拒绝

Difference Analysis: 用户驱动了需求，但在实现规划阶段放弃了，原因可能是：(1) 计划不够具体，(2) 时机不对（当天已经做了太多工作），(3) 对现有工具修改的评估不足。AI 未能捕捉到用户意图的变化。

JSON repair strategy selection

Role	Approach
Human	用户接受了 AI 提出的 4 阶段 fallback，但未指定具体方法——信任 AI 在解析策略上的技术判断
AI	AI 自主设计了多阶段 fallback：direct parse → code block extraction → brace matching → LLM repair。AI 还为支持的 APIs 添加了 tool_use/json_object 模式建议

Difference Analysis: 在这里，AI 对 JSON 解析失败模式和 fallback 策略具有更优越的技术知识。Human 提供需求（‘fix JSON parsing’），AI 提供解决方案架构。协作模式：human 设置需求，AI 提供技术解决方案。

conversation_summaries feature requirement

Role	Approach
Human	用户明确要求在 session 级别增加一个 section 来 ‘summarize the conversation with AI’，意识到 task lists 无法捕捉实际讨论的内容
AI	AI 提出了技术 schema（JSON 结构、markdown 渲染、prompt 修改），但没有预见到用户对叙述性 summary 的需求

Difference Analysis: 用户驱动产品愿景（用户需要什么），AI 提供实现设计（如何构建它）。功能差距在于用户的洞察力，而非 AI 的建议。这表明 Human 的产品感优于 AI。

AI Limitations

Critical Limitations

• 未能独立诊断 MIHD 坐标 bug 的根本原因；完全依赖用户提供的分析和修复计划。面对 ‘abnormally low ARI’ 这一宏观指标，AI 缺乏自主数据源溯源的能力（从结果 → embeddings → patch extraction → coordinates → CSV column definitions 的逆向链条）。
• tianhe BC-RNN 的集成在两个 session 中经历了三次失败的修复尝试；AI 未能预见到 robosuite 不同任务（PickPlace vs Lift）具有不一致的 observation key 命名，也未意识到在第一次修复时 StateExtractor 重建的 obs 无法保证 key name 的一致性。需要用户多次纠正才接近正确解决方案。使用了已弃用的 MuJoCo C API (mujoco.mj_name2id) 而不是先检查 robosuite wrapper API，导致三个 injectors 立即崩溃。应该在修改其他 injectors 之前检查现有的工作代码 (ImpulseInjector) 以理解正确的 API 模式。
• 在初始的 daily report 工具设计中，未能预见到多设备分布式使用模式——假设了单设备工作流，导致用户需要请求两阶段架构重设计。
• 在生成接近 token 限制的 JSON 时，AI 可能会在结构中间截断输出，产生 malformed JSON，这在生产系统中需要防御性解析和 repair 逻辑。
• ccusage 修复的初始实现错误地使用了 mb.get(‘model’) 字段，而实际 JSON 中是 modelName，且未先验证第三方工具的输出结构。导致修复完全无效，直到 human 发现数字仍然错误并重新调查。此外，还启动了过多的并行探索任务，进行冗余的信息收集（多次读取相同的 log files）。
• 最初提议使用 LIBERO/droid configs 测试 VLA models，而未验证环境兼容性。未能维持目标环境是 robosuite/mimicgen 而非 LIBERO 的语义上下文。需要 human 纠正才能转向适当的 configs。
• 跨 session 记忆缺失：AI 在 2026-02-16 tianhe session 中无法自主回想起之前 session 的 VLA checkpoint 下载情况，需要用户 prompt 才能搜索更广泛的 server 路径。
• 无法主动预见用户对 conversation summaries 等功能的需求——这些产品洞察来自于用户对生成报告中缺失部分的观察。
• 难以处理深度嵌套的 meta-tasks：当对话中包含关于对话的对话时，如果没有关于任务范围和预期输出的明确指导，AI 很难确定分析哪一层级。
• 在生成 2026-02-17 daily report 时，AI 作为 daily report analyst 本身成为了观察对象——存在“观察者被观察”的 meta-level 复杂度。AI 需要分析自己当天的行为（生成 daily reports 的行为），这需要一定的自我意识能力。

General Limitations- Daily report automation deployment Plan Mode design 被用户拒绝；AI 未能捕捉到用户意图的变化，也未能评估实施方案的具体程度是否符合用户预期，而是直接进入了 ExitPlanMode，而不是首先征求用户反馈。多次失败的 ExitPlanMode 尝试表明，AI 在判断“方案完善已完成”与“用户想要继续迭代”之间存在困难。用户在不同 session 中拒绝了 3 次 plan exits，这表明 AI 应该询问“这个 plan 准备好了吗？”，而不是假设已经完成。

• 无法直接分析 video 内容来评估 policy 质量。BC-RNN rollout videos 需要手动提取 keyframe 并进行人工检查才能识别出 robot 悬停行为（忽略了 grasp target）。在没有视觉确认的情况下，无法推断出 0% success rate 所代表的模型质量问题。
• 在 report regeneration 过程中遇到 API ConnectionRefused 错误时，没有主动提出 fallback solution（先完成数据校正，稍后再单独处理 report generation）。在 workflow decoupling 方面的灵活性不足。
• 创建了冗长的统一 plan 文档，将 server-side 和 local-client 指令混在一起，而没有考虑执行边界。需要用户反馈才能将其重构为可操作的、独立的 deliverables。项目分解（project decomposition）本能较弱。
• 当用户用中文询问“我们现在进行到哪一步了？”时，启动了 exploratory agents 并阅读大量文档，而不是首先检查最近的 session context 或 TODO tracking systems。在对话 context 可能已经足够的情况下，过度依赖 file reading。

Learnings

Key Learnings- Data bugs 比 model bugs 更具隐蔽性和破坏性：MIHD 的 coordinate swap bug 使所有 vision 实验结果失效，然而代码逻辑完全正常且所有测试均已通过。这需要从宏观层面的指标异常 (ARI) 回溯到数据源 (CSV column definitions)。这要求具备完整的 data scientist 思维链；仅靠 unit testing 无法发现此类 bugs。

• Cross-framework integration 的命名规范差异是隐藏陷阱：robosuite 的 _main 后缀、不同 task 的 observation key name 差异 (object vs object-state)、LiteLLM 的 model name -v1 后缀——这些细节在 documentation 中并不显著，但会导致 runtime errors。Robot simulation frameworks 在原始 physics engines 之上构建了抽象层 (robosuite 封装了 MuJoCo)。绕过 framework layer 的直接 API 调用会失效——必须使用 framework 提供的 wrappers 来处理命名规范 (例如 _main 后缀) 和 state management。Robosuite 的 observation key 命名规范：environment 会自动为分组后的 modalities 添加 -state 后缀 (例如 object → object-state)，但 training data 通常使用原始名称。Adapter layers 必须处理这种不匹配。最安全的策略是：(1) 使用 framework-wrapped APIs 而非 low-level APIs，(2) 传递原始数据结构而非手动重构，(3) 打印实际输出以验证 field names 而非从 docs 中推断。在修改之前，务必检查同一 codebase 中正在运行的 reference code。
• Framework correctness 与 model quality 需要不同的 validation strategies。Unit/integration tests 用于确认代码逻辑并消除 KeyError 等错误。Video visualization 则用于揭示行为质量问题 (robot hovering vs grasping)。即使 unit tests 通过，GPU integration tests 也至关重要——BC-RNN 通过了 79 个 unit tests，但需要通过 GPU rollout 才发现 0% SR，并通过 visualization 诊断出 undertrained checkpoint。每个 validation layer 都有不同的用途。
• Multi-device collaboration daily report tool 的闭环已建立：每个 device 导出 local logs → central hub 合并 remote logs → 统一 deployment 到 Hugo → GitHub Pages 发布。该 workflow 在 2026-02-17 被密集使用 (处理了 4 个 historical dates)，证明了 two-phase architecture 的可行性。下一步是 automation (用户已提出但尚未实现)。Meta-tooling (用于分析 tool usage 的工具) 需要仔细思考 workflow distribution——每个 device 上会发生什么，数据如何同步，以及如何处理 partial information。对于分布式场景，Two-phase architectures (local export + centralized aggregation) 比 monolithic single-phase designs 更具鲁棒性。
• Error Recovery Benchmark scene library 从 251 扩展到 454 是 incremental extension 的成功案例：首先实现 impulse injectors (M4) → 发现对 non-impulse types (M5) 的需求 → 修复 MuJoCo API 兼容性问题 → 通过 detector candidate expansion mechanism 生成 multi-type scenes。这展示了从 minimum viable product (MVP) 到 feature-complete 的迭代路径。Error scene generation 是一个漏斗模型：detector triggering → ErrorSpec generation → injector application → validation → scene acceptance。启用一个 injector 并不能保证生成 scenes——这取决于 detector triggering 的频率。基于 task dynamics，不同的 error types 具有截然不同的 acceptance rates。在 pick-place tasks 中，Pose perturbation 比 friction/gripper anomalies 更具普适性。Programmatic spec augmentation (_augment_specs_with_alternatives()) 可以弥补 detector coverage gaps。
• Third-party tool integration 的防御性编程：patch cost==0 (ccusage)、field name 兼容性 (modelName 或 model)、为未来的修复预留 self-degradation (当 LiteLLM 修复后，fallback 将变为 no-op)。这种“仅在必要时激活”的 patch 策略最大限度地降低了维护成本。Third-party tool 的定价缺陷应通过 local fallback mechanism 来解决，而不是等待 upstream fix。设计 fallback 时，应使其仅在异常值 (cost=0) 时触发，以保持 backward compatibility。LiteLLM 使用 versioned model names (带有可选 :0 后缀的 anthropic.{model}-v1)，而 Claude Code logs 使用简化名称，导致了系统性的 mismatch。Cost tracking bugs 可能导致 90%+ 的低估 (观察到 13x)，严重影响 financial planning。定期对 cost metrics 进行 audit 至关重要。
• 当人类指定 system architecture 和 strategic decisions，而 AI 处理 technical implementation 和 optimization 时，Human-AI collaboration 的效果最好。在本 session 中，用户的 architectural insights (two-phase design, multi-device sync) 起到了关键作用；AI 的技术执行（parsing fallbacks, config optimization）填补了空白。Domain expert 的定性判断对于发现系统性问题至关重要。AI 的数据驱动分析与人类的经验直觉形成了有效的互补性。
• 在不稳定连接上的 Remote development 需要多层级的 defense in depth：connection keep-alive（预防）、session persistence（生存）、multiplexing（快速重连）以及 automation scripts（恢复）。单层解决方案在真实的网络条件下会失效。对于 shared server accounts，用户特定的定制化内容应属于 conditional blocks 或独立的 launcher scripts，而不应是影响所有人的通用 .bashrc 条目。tmux 同时承担着 state persistence 和 environment boundary 的双重角色。Session-scoped proxy configuration（而非全局的 bashrc）可以避免影响其他 shared-account 用户。
• LLM 生成的 structured data 需要具备多种 fallback 策略的 defensive parsing。Native JSON modes（Anthropic 的 tool_use，OpenAI 的 json_object）有所帮助但不能完全消除失败——务必将 repair 作为最终的 fallback。每一层 fallback 处理特定的 failure mode：code blocks 处理 markdown 格式，brace matching 处理 truncation，repair 处理 syntax errors。
• Daily summary tools 受益于 incremental schema evolution：从基础的 task/problem lists 开始，添加用于提供 context 的 session summaries，再添加用于 filtering 的 prioritization metadata。每一层都服务于不同的读者需求。Batch documentation workflows 受益于两阶段架构：(1) 带有 local context 的 per-source extraction，(2) 带有 global deduplication 的 cross-source consolidation。这种模式出现在 summarize tool (export→merge)、MIHD pipeline (Phase 1 cache embeddings→Phase 2 fuse) 以及 error-recovery-benchmark (generate scenes→collect data) 中。
• MimicGen 发布策略：仅提供 datasets，不提供 pretrained model checkpoints。Official releases 可能提供数据但不提供训练好的 models——在规划前务必验证 asset availability。BC-RNN (Behavioral Cloning with RNN) 是直接的 supervised learning：收集 human demo (state, action) pairs，训练 LSTM 来预测 actions，并将其作为 policy 部署。当存在足够的 demos 时，它是 manipulation tasks 的一个简单但有效的 baseline。当 pretrained checkpoints 不可用时，从 demos 进行 training 成为了必要的 fallback。
• Retroactive work log analysis（总结过去一周）是一种有价值的实践，它将原始的 conversation logs 转化为 structured knowledge artifacts，从而实现长周期内的 pattern recognition 和 progress tracking。- Idempotent design patterns（追踪已处理内容，跳过冗余工作）对于可能被中断或重新运行的工作流至关重要。_merged_devices 追踪机制防止了在重新处理部分完成的 aggregations 时产生昂贵的冗余 API 调用。
• 大型 model asset 管理（47GB+ VLA checkpoints）需要基于 symlink 的组织方式，以在保持集中可发现性的同时避免重复。散落在 filesystem 中的 checkpoints 会阻碍 reproducibility 和 config management。集中化的 checkpoint 目录提高了可发现性。
• 在修复历史数据中的 data quality bugs 时，应将数据修正（export）与下游消费（report generation）解耦。避免因下游依赖失败（例如 LLM API 不可用）而阻塞整个 pipeline。Export 阶段依赖 Node.js 工具 (ccusage)，merge 阶段依赖 LLM API——即使 merge 被阻塞，也可以继续进行 export。

Practical Learnings

• 复杂的 research project 文档范围不仅应涵盖主模块，还应包括 deps/ submodules（在 Motion framework 中发现了 11 个）、data conversion pipelines 以及跨 repo 的 integration points (LeRobot, OpenPI, MimicGen)。彻底的探索可以防止因文档不完整而阻碍 onboarding。

Conversation Summaries

MIHD

🔄 Fix vision encoder X/Y coordinate swap bug and prepare experiment reruns 18:50:27.298 | claude_code 用户发现 UNI2 clustering 结果异常（151670 仅有 1 个 cluster，ARI≈0.065）。深度调试发现了两个严重 bug：(1) coordinate space 不匹配（hires vs full-res），(2) X/Y 坐标交换（CSV col4=Y/col5=X 但代码命名相反）。通过分析 array_row/array_col 与 pixel coordinate 的相关性确认了根本原因。修复了 load_spatial_coordinates() 和 VisionEncoder 的 coordinate handling 逻辑，并编写了重新运行 66 个 single-modal experiments（3 个 gene encoders + 3 个 vision encoders × 11 个 sections）的执行计划，但用户在 plan mode 退出时中断了任务。

🔄 Complete coordinate bug fix and validate through experiment reruns 21:28:38.729 | claude_code 修复了 load_spatial_coordinates() 的 CSV column mapping 错误（pixel_x 实际上是 Y/pxl_row，pixel_y 是 X/pxl_col），该错误导致所有 vision patches 从转置后的位置提取，导致 vision ARI 仅为 0.065。修改了 scripts/run_benchmark.py 和 utils/data_loader.py 的 column names 和 coordinate order，清除了所有 spatial_coords 和 vision caches，重新提取了 11 个 sections 的 UNI2/HIPT/ResNet50 embeddings，验证了 coordinates 正确且 embeddings 100% unique，UNI2 ARI 提升至 0.12-0.25。启动了 core_multimodal_fast fusion experiment 的重新运行（STAIG UNI extraction 已完成，evaluation 正在进行中）。

gadget-summarize

✅ Generate consolidated 2026-02-13 report spanning 4 devices 13:56:41.357 | claude_code 对 2026-02-13 在 DCC (MIHD 286-experiment benchmark automation)、tianhe (error recovery code cleanup v4.0→v4.1, GPU smoke test)、MacBook (使用两阶段架构创建 daily report tool) 和 Windows (CalendarPro P0 fixes) 的工作进行了大规模汇总。AI 生成了一个 general-purpose agent 来处理复杂的多设备聚合。

✅ Implement deploy subcommand for Hugo bugJournal batch publishing 14:52:54.146 | claude_code 用户请求为 daily reports 提供批量部署到 Hugo website 的功能。AI 实现了三项更改：修复了 generate_hugo_post()（从 blockquote 提取 summary，修复 timezone/time，更新 keywords），添加了用于使用 –date filter 进行批量处理的 cmd_deploy()，并连接了 argparse dispatcher。验证显示 deploy –help 工作正常。

🔄 Process Feb 15/16 date reports and deploy to Hugo, plan automation 03:57:32.066 | claude_code 用户请求处理 2026-02-15 和 2026-02-16 的 daily reports。执行了 export –summarize (15th) → merge –sync (15/16th 来自 4 个 devices) → 创建 Hugo bugJournal entries → 运行 update.sh deploy (网站页面从 139→140/141)。在 rclone sync 后发现了额外的 02-07/08/09/17 reports，并为每个报告创建了 bugJournal entries。用户请求编写 Python script 来自动化此流程（template conversion + copy + update.sh），AI 进入 Plan Mode 设计 deploy subcommand 但被用户中断。

✅ Configure local SSH client for stable tianhe connection (TzJsDesktop) 05:12:10.522 | claude_code 用户从 tianhe session 获得了 server-side SSH stability guide，并请求进行 local-side 配置。AI 使用 keep-alive 和 connection multiplexing 更新了 ~/.ssh/config，创建了带有 retry logic 的 ~/bin/auto-ssh wrapper script，并通过新的 .bashrc 文件将 ~/bin 添加到 PATH。完成了具有 tmux session persistence 功能的自动重连 SSH 的设置。

Error Recovery Benchmark

✅ Fix ccusage opus-4-6 zero-cost bug and apply to historical dates 16:31:06.227 | claude_code 发现由于 LiteLLM database 使用了 anthropic.claude-opus-4-6-v1（带有 -v1 后缀）导致匹配失败，使得 ccusage reports 中 claude-opus-4-6 的 cost 显示为 $0（实际 2026-02-17 的 25M+ tokens 应约为 $21）。在 daily_summary.py 中添加了 _FALLBACK_PRICING 和 _fix_zero_cost_models() 后处理。初始实现错误地使用了 ‘model’ 字段（实际应为 ‘modelName’），完全无效。在打印原始 JSON 后修复了此问题。重新导出了 2026-02-13 至 2026-02-17 共五天的数据，2026-02-14 的 cost 从 $3.14 正确更新为 $39.07。

✅ M5 milestone completion: non-impulse scene generation with multiple injectors 2026-02-17 | claude_code 实现了 M5 non-impulse scene generation 的完整 pipeline。创建了 benchmark_v4_nonimpulse.yaml 配置，通过将直接的 mj_name2id 调用替换为 robosuite wrapper methods 并添加 _main suffix handling，修复了三个 injectors (pose_perturb, friction, gripper_bias) 中的 MuJoCo API bugs。初始运行生成了 103 个 pose_perturb scenes，但 friction/gripper_bias scenes 为零。实现了 _augment_specs_with_alternatives() 方法，以便在 detectors 未触发时通过程序化方式生成 specs。最终数据库包含：454 个 scenes (121 impulse + 130 natural + 103 pose_perturb + 100 friction)，达到了 M5 目标的 227%。

🔄 Advance tianhe M5/M6 milestones (SSH, non-impulse scenes, BC-RNN, VLA) 21:47:07.960 | claude_code 实现了 SSH stability (tmux + keep-alive + claude-tmux script + session-scoped proxy)。修复了 friction/pose_perturb/gripper_bias injectors 的 MuJoCo API 兼容性 (mj_name2id→body_name2id + _main suffix handling)，生成了 103 个 pose_perturb + 100 个 friction scenes (数据库从 251→454)。训练了 BC-RNN 600 epochs (15 min/A800)。修复了 VLA server openpi API calls 和 image key mapping (Pi0/Pi0.5 dual servers 已就绪)。调试了 M6 multi-policy evaluation——Random 工作正常，但 BC-RNN 因 obs format 不兼容（object vs object-state key names + dimension 37≠65）而崩溃，目前仍在修复中。✅ BC-RNN integration: training, obs key mapping fix, and multi-policy evaluation setup 2026-02-17 | claude_code 全面的 BC-RNN 集成工作流。搜索了 MimicGen 预训练 checkpoint，确认不存在（仅有 dataset）。使用 robomimic 从头开始训练 BC-RNN（2-layer LSTM, GMM head，在 pick_place dataset 上运行 600 epochs，checkpoint 大小 14.3MB）。修复了 obs key mapping bug：在 policy_adapter.py 中为 Strategy 1 (raw obs) 和 Strategy 3 (StateExtractor fallback) 实现了 object-state → object 的 aliasing。通过 79 个 unit tests 和 GPU integration test（5 次 rollouts，消除了 KeyError 但 SR 为 0%）进行了验证。生成的 visualization videos 显示机器人存在 hovering 行为，确认是 checkpoint 训练不足而非 framework bug。将项目文档更新至 v4.6。部署了 VLA servers (Pi0 port 5556 GPU 1, Pi0.5 port 5557 GPU 3)。创建了 scripts/5_baseline_accuracy.py 用于 zero-error baseline 测试。启动了 multi-policy evaluation 运行（50 scenes × 3 seeds × 4 policies）。

✅ SSH connection stability solution for remote development over jump host 2026-02-17 | claude_code 诊断了导致 Claude Code session 丢失的不稳定的基于 proxy 的 SSH 连接。设计并实现了五层解决方案：(1) SSH keep-alive 配置 (ServerAliveInterval 15s)，(2) 增强了带有 history 和 stability 设置的 .tmux.conf，(3) 带有 auto proxy_on 功能的 ~/bin/claude-tmux launcher script，(4) 在 .bashrc 中注释掉了全局 auto-proxy 以实现共享账号下的用户隔离（手动 proxy_on/proxy_off），(5) 创建了 docs/local_ssh_setup_guide.md，包含 client-side ControlMaster、auto-ssh script 和 VS Code settings。所有组件均已验证工作正常。建立了稳定的 remote development 工作流，防止 session 丢失。

🔄 Model checkpoint consolidation and visualization workflow design 2026-02-17 | claude_code 盘点了 6 个 model checkpoints：BC-RNN PickPlace (164MB, 12 epochs), Pi0 LIBERO (12GB), Pi0.5 Base (12GB), Pi0 Base (12GB), Pi0 Fast Base (11GB), Robomimic Lift (7.6MB)。总计 47GB+。发现现有 scripts 仅处理 error scene replay，而不支持 live policy rollout visualization。设计了 checkpoints/ symlink 结构以避免重复，并设计了 visualize_policy_rollout.py script，结合了来自 5_baseline_accuracy.py 的 rollout logic 和来自 2_visualize_scene.py 的 rendering。支持 random/bc_rnn/vla policies，并具有可配置的 seeds 和 camera views。计划已编写但实现尚未完成。

gadget (summarize tool)

🔄 Diagnose and fix ccusage opus-4-6 pricing bug revealing 13x cost underestimation 2026-02-17 | claude_code 人工报告 ccusage 在处理 claude-opus-4-6 model 时返回 cost=0，导致 token cost tracking 失败。AI 对 ccusage source、LiteLLM pricing database 和实际 log data 进行了并行探索。确认了 model name mismatch：Claude Code 使用 ‘claude-opus-4-6’，而 LiteLLM database 使用 ‘anthropic.claude-opus-4-6-v1’。在 daily_summary.py 中实现了 fallback pricing mechanism：添加了 _FALLBACK_PRICING dictionary (opus-4-6: input $5/M, output $25/M, cache_creation $6.25/M, cache_read $0.50/M) 和 _fix_zero_cost_models() post-processing function。第一次实现因 field name bug 失败（使用了 ‘model’ 但 ccusage 输出的是 ‘modelName’）。修复为 mb.get(‘modelName’) 或 mb.get(‘model’)。重新导出了 2 月 13-17 日（5 天）的 logs。修正后显示实际成本为每天 $18-48，而之前显示为每天 $0-7（低估了 13 倍，累计误差约 $150+）。尝试重新生成报告 (merge + deploy) 但因 LLM API connection failure 被阻塞。数据修正已完成，报告生成待 API 可用后进行。

gadget (daily report system)

✅ Daily report consolidation for Feb 13-16 multi-device work 2026-02-17 | claude_code 用户对 2 月 13-16 日的 conversation logs 调用了 daily report analyzer，涵盖了跨多个设备的多个项目：CalendarPro (JSON parsing, AI timeout handling, message queue stability, learning data collection, 2 月 13 日的 Random Thoughts feature)，MIHD benchmark optimization + Error Recovery framework (visualization fixes, force injection debugging, 2 月 14 日的 PreGrasp detector)，Error Recovery VLA work (Pi0/MimicGen checkpoint research, Gemini VLM integration, 2 月 16 日通过 50-rollout natural error capture 生成了 150 个 scenarios)。系统处理了所有 conversations 并生成了结构化的 JSON reports，包含 tasks, problems/solutions, human_vs_ai analyses 以及 conversation summaries，用于知识管理和跨设备进度追踪。

Motion-based Self-Reflection Framework

🔄 Initialize comprehensive bilingual documentation (CLAUDE.md + README/Tutorial) 2026-02-17 | claude_code 执行了 /init 命令，探索了三模块架构：MPM (via LLaVA 的 motion prediction), MCM (motion correction), Diffusion Policy。创建了 CLAUDE.md，记录了 training/inference commands, Hydra configs 和 dataset formats。用户要求编写详细的双语 README (中英混合)，涵盖包括 11 个 deps/ submodules (openpi, GraspVLA, MimicGen, LeRobot, robosuite, robomimic 等) 在内的所有组件。启动了 3 个并行探索 agents 来分析 diffusion_policy/, llava/, failure_case_analysis/ 以及完整的 deps/ tree。设计了约 1200 行的 documentation plan，涵盖 architecture, data conversion pipelines (RLDS → LeRobot → robomimic), training workflows (三阶段：LLaVA finetuning, MCM training, Diffusion Policy) 以及所有 cross-repo integration points。CLAUDE.md 已完成，全面的 README 文档尚未编写。

CalendarPro

✅ Fix Google Calendar 403 + Batch Delete Feature 00:50:22.155 | claude_code 修复了 calendar_service.py，使其使用 settings().get() API 而不是 calendarList().get() (避免 403 insufficientPermissions)。实现了 batch delete：扩展了 DeleteData model 以包含 date_from/date_until/batch 字段，更新了 LLM prompt，使 search_events 支持自定义时间范围，重写了用于 batch operations 的 _handle_delete，并添加了 BatchDeleteApprovalView Discord confirmation UI。修复了 LLM timeout fallback 导致的 regex extraction 问题以及 empty message 导致的 Discord crash。

Token Usage