bowei/skills-win
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
70 Commits 1 Branch 0 Tags
858b7eb6dc08efe3775cdd8f0ddd4e18872370de
Commit Graph
12 Commits
Author SHA1 Message Date
Myfro9 858b7eb6dc tools-sync: mirror 阶段只链接含 SKILL.md 的目录 
Claude Code 会把账号侧下发的 skills 缓存进 ~\.claude\skills\synced\<guid>\，
它不是 skill（顶层没有 SKILL.md），但内层目录各自带 SKILL.md。旧逻辑无条件
镜像主副本下的每个非点开头目录，于是给 Codex 建了 synced 的 junction —— Codex
递归扫到内层那批，会把账号已经提供的 skills 再注册一遍。

改为以顶层 SKILL.md 作为判据（与脚本自己 '\' 检查、以及 Codex 的注册
规则一致），并把被跳过的目录打印出来。
 2026-09-23 17:02:24 +08:00
Myfro9andClaude Opus 5 8566e23f49 tools-sync: 修复会删掉宿主自装 skill 的 registry 对账缺陷 
本次同步实跑触发了数据丢失：orca-cli 的物理副本在 ~\.agents\skills（Orca 就是
这样装的——真目录放 .agents，再把每个工具链过去，本机 8 个工具全指向它），
而主副本里的同名条目本身是指向它的 junction。对账循环从不检查"主副本条目是不是
链接"，于是 fingerprint 比对经链接解析到同一份内容判为"identical"，删掉 registry
副本并建 junction → 主副本与 registry 互指成环，唯一的真副本没了。
orchestration 走 INGEST 分支，则把 Orca 的布局反了过来。

两者均已用 `orca skills install --skill <name>` 恢复为 Orca 自己的布局。

修复三处：
- 对账循环：主副本条目本身是链接时，判定该 skill 归宿主所有，计入 foreign 跳过。
- INGEST：新增 Get-SkillDirLinkers，若 ~\.* 下其他工具的 skills 目录有链接指向
  这个目录，说明它是宿主自装 skill 的物理家，不搬进主副本。
- 镜像阶段：跳过本身是链接的主副本条目，否则 Codex 会把同一 skill 注册两遍
  （.agents 与 .codex 都在扫）。

回归测试新增 hostowned 夹具（真目录在 registry、主副本是链接）：在修复前的脚本上
以"real dir was collapsed into a link"失败，修复后通过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01438Zbcx49e4o46uSA71mFF
 2026-09-07 16:29:20 +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
bowei 24b9c271e1 sync: SHANGHAI-U9 2026-09-03 2026-09-03 05:12:51 +08:00
Myfro9 f1d36bb082 sync: BOWEI_US 2026-09-02 2026-09-02 15:37:47 -05:00
Myfro9 67ca51b2c2 sync: BOWEI_US 2026-09-02 2026-09-02 15:37:08 -05:00
Myfro9 10f436cfde sync: BOWEI_US 2026-09-02 2026-09-02 15:35:47 -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
Myfro9 2b873a1f4d sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:28:34 +08:00
Myfro9 c15c5c51e8 sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:20:36 +08:00
Myfro9 96b014edb3 sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:18:50 +08:00
Myfro9 2ef32a9dcc sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:14:49 +08:00