bowei/skills-win
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
81 Commits 1 Branch 0 Tags
479769eff0ae88f217a9f633f7fcee6f9c477989
Commit Graph
14 Commits
Author SHA1 Message Date
Myfro9 6ac3081321 sync: HP_BOWEI 2026-10-15 2026-10-15 02:00:16 +08:00
bowei 771acd4171 sync: SHANGHAI-U9 2026-10-12 tools-sync 全部改走 tailscale（公网 git.rpchannel.com 已停用） 2026-10-12 20:27:24 +08:00
bowei b07cc7b22e sync: SHANGHAI-U9 2026-10-12 tools-sync 增 OpenCode skills 注册（阶段 2.5 + sync_opencode_skills.ps1 + env 模板） 2026-10-12 20:14:27 +08:00
Myfro9 7df88445c5 tools-sync: Codex MCP 回退的定量实测——窗口 <25s，且是回退到陈旧快照而非清空 
2026-09-23 在 win-hp-bowei 上改完 stm32cubemx 解释器并补上 mcp_dsa815，T+0 验证
通过，T+25s 再查就已经退回去了，T+50/75s 保持。codex-cli 0.150.1 全程未升级。

两点修正旧记载：
- 窗口不是'几分钟'，是 25 秒以内；
- 不是'清空到只剩 cua_repl/node_repl'。13 个条目里 altium/kicad/matlab 等全在，
  只有本次增改被抹掉，stm32cubemx 精确退回修改前那一版。说明覆盖它的是一份
  有内容的远端快照，不是清零。

实践结论随之修正：这类机器上 Codex 侧 MCP 改动是徒劳的，-Apply 之后必须在 25s
后复验，没活下来就如实写'未能持久、该机仍在用旧配置'，不要在报告里记成已修复。
 2026-09-23 17:49:46 +08:00
Myfro9andClaude Opus 5 01b7a00b12 tools-sync: 订正 Codex MCP 消失的归因——与升级无关，且需放在同步最后一步 
原文把用户 MCP 消失归因于 codex-cli 升级。2026-09-07/08 一次同步内复现三次
（补齐→验证通过→几分钟后只剩自带的两个），说明升级只是其中一种触发。
补上本次排查的排除项：不是 cwd 作用域、不是 Syncthing、add/remove/list 本身正常；
config.toml 在 0.153.4 复验仍然惰性（手写 [mcp_servers.tomlprobe] 后 list 看不到）；
add 之后本地三处候选目录都没有文件被写过，怀疑存储在账号侧下发。
据此把"MCP 审计放在整次同步最后一步"写成明确做法。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01438Zbcx49e4o46uSA71mFF
 2026-09-08 05:41:19 +08:00
Myfro9andClaude Opus 5 17b7830f04 tools-sync: 文档补上宿主自装 skill 的方向与 MCP 再次被清空的事实 
- 阶段 2 决策表新增两行：主副本条目本身是链接、以及被其他工具 skills 目录
  链接指向的真实目录，均判为宿主自装、脚本让开；并写清 2026-09-07 实跑
  因此弄丢 orca-cli 的经过与用 `orca skills install` 恢复的办法。
- Codex MCP 存储模型：0.153.4 升级后 7 个用户 MCP 第二次全部消失；另记一次
  与升级无关、无法复现的消失。结论不变——每次同步必须重跑审计，退出码 2 就 -Apply。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01438Zbcx49e4o46uSA71mFF
 2026-09-08 05:26:09 +08:00
Myfro9andClaude Opus 5 f665448376 sync: BOWEI 2026-09-07 tools-sync 改为 junction 模型（registry 双向 ingest + 修复） 
- sync_repos.ps1: 每个 skill 只在 ~\.claude\skills 有一份物理副本，其余 registry
  一律 junction；新增 registry-only skill 的自动 ingest、MISDIRECTED 链接修复、
  同名内容分叉的 CONFLICT 报告，以及只对 -MirrorRegistry 做全量镜像。
- SKILL.md: 重写阶段 1/2，补 Codex MCP 存储模型（config.toml 惰性，
  codex mcp list --json 是唯一权威口径）与 CLI 升级会清空注册表的事实。
- sync_mcp_registrations.ps1 + references/codex_mcp_wanted_keys.json:
  报告 codex-cli 无接口可设的键（tool_timeout_sec / env_vars）为
  "registered, but incomplete" 而非失败。
- tests/test_sync_repos_registries.ps1: registry 对账的回归测试。
- .gitignore: orchestration（Orca 自带的发现桩，同 orca-cli）列为 local-only。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01438Zbcx49e4o46uSA71mFF
 2026-09-07 16:22:09 +08:00
Myfro9andClaude Opus 5 48a4c5601f tools-sync: 传输故障时登录 gitea 自愈，并让"同步成功"包含"别人拉得到" 
授权本 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
 2026-09-02 15:40:29 -05:00
Myfro9andClaude Opus 5 e39e852853 tools-sync: 增加 ls-remote 同步闸门，并记下 gitea 空 pack 故障的排查法 
这次同步事故的教训不是服务器坏了，而是坏了没人知道：pull --rebase 一失败脚本
就退出，push 从没走到，3 个 commit（含整个 bmem skill）在本机躺了 8 天，报告里
却算作"已知故障、待恢复"。而 ls-remote 这 8 天一直是好的。

- sync_repos.ps1 增 Assert-RemoteInSync：push 后（及 -DryRun 时）用 ls-remote 比对
  origin/<branch> 的实际 sha，不一致就 FAIL 并报出滞留/落后的 commit 数。
  远端分支不存在时单独报错，避免那两个计数被静默地按 HEAD 算出误导性数字。
- SKILL.md 阶段 1 写明闸门是硬性的：服务端故障是原因不是结果，不得报成已同步。
- SKILL.md 新增 bad pack header / early EOF 的排查阶梯（三步各排掉一层），并记下
  根因：全局 gitconfig 被注入 [uploadpack] packObjectsHook，把 pack-objects 换成
  了空转脚本。附带提醒 HOME 是 /data/gitea/home 而非 /data/git，以及这是一条
  完整 RCE 链、要连 hook 与 /tmp 载荷一起清。
- bmem/SKILL.md 的"已知边界"改为已修复，避免继续把普通的没 pull 误判成服务端故障。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015tMFjKGgxdmxJ28dyXdx1u
 2026-09-02 14:57:50 -05:00
bowei 307bc38d36 sync: SHANGHAI-U9 2026-08-19 tools-sync 增 504 恢复工具 recover_commits_via_gitea_api.py 并写进阶段1处置 2026-08-19 15:16:56 +08:00
bowei 17632bea27 sync: Shanghai-U9 2026-07-22 tools-sync MCP双向同步脚本+MATLAB专项节；撤出误入库的__pycache__ 2026-07-22 03:55:54 +08:00
Myfro9 2b873a1f4d sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:28:34 +08:00
Myfro9 1334ad4a64 sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:26:14 +08:00
Myfro9 2ef32a9dcc sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:14:49 +08:00