Myfro9andClaude Opus 5
48a4c5601f
授权本 skill 在同步传输出问题时登录 gitea 服务器诊断并修复。连接参数走 skills_env.md 的 GITEA_* 段（模板同步给出占位符与填写要点），不写死在脚本里。 新增 scripts/gitea_doctor.ps1（Windows 侧驱动）： - 分两个面探测传输——refs 面(ls-remote) 与 pack 面(--filter=tree:0 的极小 clone)。 两面独立坏，区别就是整个诊断：2026-08 那次只有 pack 面死了，push 和 ls-remote 全程正常，故障因此藏了 8 天。两面都好就直接返回，不连服务器。 - 坏了才 ssh，tailscale 直连优先、frps 跳板兜底。 - 修完不采信服务端自述，回到客户端重新探一次 pack 面才算数。 新增 scripts/gitea_triage.sh（服务端执行）：8 项检查各打 PASS/FAIL，--fix 只做 可逆修复（隔离被污染的 gitconfig 并重启让 gitea 重建、按 git 模板还原被篡改的 hook、删 /tmp 载荷、还原被包了一层的 git、拉起停掉的容器），破坏性操作另需 --allow-destructive。检查表把这次的两个坑固化下来：packgen 必须带 --stateless-rpc （clone file:// 走的不是 HTTP 那条码路，假阴性把上一轮排查带偏成"gitea 版本 bug"）， 以及全局 gitconfig 在 /data/gitea/home 而不是 /data/git。 sync_repos.ps1： - pull/push 报传输类错误时自动调医生并重试一次（-NoDoctor 可关）。 - 收尾增加 fetchability 探针。push 成功不等于同步成功——服务端发不出 pack 时， 刚推上去的东西别的机器照样拉不到，这轮就该判失败。ls-remote 闸门只验 ref 面， 测试中确实出现过"同步报成功而服务器仍是故障态"。 脚本用 scp 送到服务端执行而不是管道进 sh -s：PS 5.1 会给管道内容加 UTF-8 BOM， 糊在 shebang 上，sh 报的错会指向解释器而不是真原因。 验证：注入真实故障（packObjectsHook 指向 /bin/true，同样产出空 pack）后整链跑通 5 次——检出→隔离→重启→重建→客户端复验，包括从同步主流程自动触发的那次。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015tMFjKGgxdmxJ28dyXdx1u