bowei/skills-win
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
52 Commits 1 Branch 0 Tags
aca7c799a804ad619d592f73e3a1f1666ba53794
Commit Graph
19 Commits
Author SHA1 Message Date
boweiandMyfro9 aca7c799a8 tools-sync: MCP 审计改用 codex mcp list --json 作为 Codex 侧权威口径 
Codex 26.825 起不再把用户 MCP 注册写入 ~/.codex/config.toml，导致原来解析
config.toml 的审计每次都把 7 个已注册 MCP 误报成 "Claude only" 并重复 add。

- Get-CodexMcps 优先调用 `codex mcp list --json`，CLI 不可用时回落到原 TOML 解析
- cua_repl（Codex 自带 ChatGPT.exe 运行时，装在 WindowsApps 下，原 .codex/runtimes
  正则匹配不到）纳入 Test-CodexManaged 自动排除，不再需要每次 -ExcludeName
 2026-09-07 16:17:45 +08:00
bowei 24b9c271e1 sync: SHANGHAI-U9 2026-09-03 2026-09-03 05:12:51 +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
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
Myfro9andClaude Opus 4.8 9c1012f5b8 sync: WIN11-BOWEI 2026-08-10 MCP审计脚本python回退到conda(MS Store存根修复) 
sync_mcp_registrations.ps1 默认用 PATH 上的 python 解析 Codex TOML，
但 Windows 上常见的是 Microsoft Store python 存根(exit 49, 无 stdlib)。
新增 Resolve-PythonCommand: python 不带 tomllib 时自动回退到 skills_env.md
的 CONDA_LANGGRAPH_PYTHON, 再退到 python3/py。显式 -PythonCommand 仍优先。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-09-02 14:53:28 -05:00
boweiandClaude Opus 5 ecc913c4f1 sync: Shanghai-U9 2026-09-03 MCP 排除清单补 Codex 桌面自带的 cua_repl（WindowsApps 路径原先认不出） 
Test-CodexManaged 原来只按名字认 node_repl、按路径认 .codex\runtimes 与
.codex\plugins\cache。Codex 更新后新增的 cua_repl 的 command 在
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\ChatGPT.exe，两条都不命中，
于是被当成"Codex 独有的可移植 MCP"报进差集，险些复制到 Claude 侧。
名字集合加 cua_repl，路径再认 WindowsApps\OpenAI.Codex 与 OpenAI\Codex\。
原有的 .codex 路径正则一字未动。tests PASS；重跑审计 exit 0，四项 Matched。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018FykpdV2Y4RUWXU5PtoLqh
 2026-09-03 02:52:05 +08: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 28307b12f6 sync: SHANGHAI-U9 2026-08-19 skills_env 模板补回漂移的 12 个键（LangGraph flow 根 / SDK_ROOT / SMOD+VM 段，凭据一律占位符） 2026-08-19 12:58:21 +08:00
bowei 6dddab8923 sync: SHANGHAI-U9 2026-07-27 修复 MCP 双向同步向 Claude 注册失败 
Add-ToClaude 改用 `claude mcp add ... --` 标志形式，不再走 add-json：
Windows PowerShell 5.1 会吞掉传给原生 exe 的 JSON 参数里的双引号，
claude.exe 收到残缺 JSON 后报 "Invalid configuration: : Invalid input"。

另外 add-json 即使在引号完好时也拒绝反斜杠路径，故新增
ConvertTo-PortablePath，把带盘符的路径统一成正斜杠；同一函数也用于
比较，避免 C:\x 与 C:/x 被误判成 drift。

实测：drawio（Codex 独有）现已能由 -Apply 自动补齐到 Claude 并连通。
 2026-07-27 01:15:27 +08:00
bowei 17632bea27 sync: Shanghai-U9 2026-07-22 tools-sync MCP双向同步脚本+MATLAB专项节；撤出误入库的__pycache__ 2026-07-22 03:55:54 +08:00
Myfro9andClaude Opus 4.8 88f96fa5fa vivado: resolve install path from ~/skills_env.md instead of hardcoding D:\Xilinx 
The Vivado install root differs per machine (C:\Xilinx here, D:\Xilinx on the
box these skills were written on), so every hardcoded path was already wrong
on this machine.

- new fpga_flash/scripts/vivado_env.py: resolves --vivado-dir > env var >
  VIVADO_ROOT (falling back to VIVADO_PATH) from ~/skills_env.md
- gen_mcs / program_flash / check_flash_csv: --vivado-dir now optional
- fpga_update/gen_update_mcs.py: same precedence for --vivado
- fpga_flash / smod_atsc_dev / vivado-prj-create SKILL.md: document the
  lookup instead of naming a drive letter
- skills_env template: VIVADO_ROOT/VIVADO_PATH are now blanks to fill in,
  so a new machine can't inherit a wrong default

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 07:48:04 -05: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 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