bowei/skills-win
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
62 Commits 1 Branch 0 Tags
f04667c9247c393023b4a05036cfd75b79fa325f
Commit Graph
62 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
bowei f04667c924 Add shared PetaLinux eMMC and HJX9009 TF production skill 2026-09-16 02:46:29 +08:00
bowei 84fbcae620 Make bmem Gitea sync failures trigger immediate server repair and acceptance 2026-09-15 18:24:08 +08:00
bowei a36cbfda2a stabilize hjx9009 qspi cache profile 2026-09-15 03:23:25 +08:00
bowei 188d067d31 add petalinux qspi transition workflow 2026-09-15 03:17:59 +08:00
Myfro9 170f4eb53f sync: HP_BOWEI 2026-09-09 2026-09-09 09:51:06 +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 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 58b90f16a6 tools-sync: 合并 gitea 自愈与 junction/ingest 两条演进线 
rebase 到 origin/main 时 tools-sync 三个文件都冲突——上游（SHANGHAI-U9）加了
gitea 传输自愈与 ls-remote 同步闸门，本机加了 registry 双向 ingest/修复模型。
两者互不相干，按并集合并：

- sync_repos.ps1: 保留 -NoDoctor/-AllowDestructive 与 Test-TransportFault /
  Invoke-Doctor / ls-remote 闸门，叠加 -Registry/-MirrorRegistry/-NoIngest 与
  registry 对账。上游末尾那段 stale-junction 清理引用了已删除的 $CodexSkills，
  且已被新 registry 循环覆盖，故弃用。
- SKILL.md: 保留阶段 1.5（gitea 医生）整节，阶段 2 换成 registry 对账；
  description 与阶段 6 报告模板取两侧并集。
- test_sync_repos_registries.ps1: 阶段 1 的成功串改成上游 ls-remote 闸门的
  "verified: origin/main ="。两个测试套件均通过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01438Zbcx49e4o46uSA71mFF
 2026-09-07 16:23:13 +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
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
boweiandMyfro9 d631dfef5c sync: BOWEI 2026-08-29 新增 dpd-mig-flow / sim-rtl-flow 两个 skill，去硬编码 
- dpd-mig-flow、sim-rtl-flow 首次入库
- 两者的 LangGraph 检出路径、SMOD 参考工程路径、N9320B/板卡 IP 改为
  引用 ~/skills_env.md（新增 DPD_MIG_FLOW_ROOT / SIM_RTL_FLOW_ROOT /
  XILINX_SMOD_ROOT / SMOD_ATSC_REF 等条目）
- sim-rtl-flow 示例里写死的 /c/Users/Administrator 临时路径改为 $TMPDIR
- 撤出上次遗留的误入库 __pycache__/run_fpga_local.cpython-311.pyc
- .gitignore 忽略 orca-cli（指向 ~/.agents/skills 的外部链接）
 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 5 7d81f59ee0 zynq-imx6-flow: analyze 阶段增加频谱仪取证要求 
RF/发射类验收不能只靠数字侧证据。analyze 节点新增一节，规定用已注册的
频谱仪 MCP（N9320B / DSA815）取证：需求点名哪台就用哪台，未点名默认
DSA815；只读抓图优先，改了设置要还原；artifact 路径、峰值频率/功率与
扫描设置一并写进 analysis_log。频谱仪连不上时报缺证，不得仅凭数字证据
判定 RF 需求通过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015tMFjKGgxdmxJ28dyXdx1u
 2026-09-02 14:54:09 -05:00
Myfro9andClaude Opus 5 bb71470e07 sync: WIN11-BOWEI 2026-09-02 新增 bmem 记忆 skill；imx6-flow/plan-review 文档与脚本更新 
远端 pack 服务仍故障（git-upload-pack 返回 0008NAK 后截断），push 待服务器恢复。
未跟踪的 5 个归档临时副本（rtl-ip-replace / sim-rtl-flow / simulink_rtl_dev /
simulink-rtl-redev / zynq-imx6-flow）刻意不入库，待 pull 后由远端提供。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0135YszNe4pwwJxwaLqKTCKG
 2026-09-02 14:53:28 -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 42edf13936 sync: Shanghai-U9 2026-09-03 硬编码审计清掉 0819/0826 挂了两轮的文档类遗留 
smod_atsc_dev（SKILL.md / references/imx6.md / references/fpga.md）、
fpga_update（SKILL.md / references/protocol.md）、fpga-imx6-flow（SKILL.md）
正文表格与 shell 示例里的 E:\Xilinx_design\smod\SMOD_ATSC\... 和 192.168.1.143
改成引用 skills_env.md 的 SMOD_REPO_ROOT / SMOD_BOARD_IP；shell 块统一用 $BOARD
并在块内注明取值出处。13 处锚点全部唯一命中，无行为改动。

刻意未改：各 skill 的 YAML description 里的同名字面量（那是触发关键词，不是
脚本取值，改了降低匹配率）；脚本里 _env_lookup(KEY, 字面量) 形式的回落默认值；
fpga_flash/SKILL.md 的 SMOD_DTMB_CG 命令示例（属另一个工程，无对应 env 键）。

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
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 120dc66925 sync: SHANGHAI-U9 2026-08-26 fpga_update/gen_update_mcs.py 的 REPO 改读 skills_env.md 的 SMOD_REPO_ROOT（0819 遗漏的第三个文件） 2026-08-26 07:50:48 +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 effa9361ac sync: SHANGHAI-U9 2026-08-19 硬编码审计：imx6_app REPO / fpga_ru --host 改读 skills_env.md（新增 SMOD_REPO_ROOT） 2026-08-19 12:56:36 +08:00
bowei 6535dd83d4 sync: SHANGHAI-U9 2026-08-19 sim-rtl-flow 增约束原语阶段与版本说明树文件重命名，新增 ledger 迁移脚本 2026-08-19 12:50:44 +08:00
bowei d77d025c59 sync: SHANGHAI-U9 2026-08-12 2026-08-19 12:50:44 +08:00
boweiandClaude Opus 5 0b5583a5c0 sync: WIN-BOWEI 2026-08-10 硬编码审计：两个 flow driver 的工程根改读 skills_env.md 
- run_fpga_local.py: FPGA_FLOW_ROOT 写死 E:\LangGraph_Design\fpga-goldenref-flow
  -> _env_lookup(FPGA_GOLDENREF_ROOT)，未配置时给出明确提示。
- run_imx6_flow.py: DEFAULT_PROJECT 写死 -> _env_lookup(FPGA_IMX6_FLOW_ROOT)，
  --project-dir 为空时报错而不是拿错路径继续。
与 sim-rtl-flow / zynq-imx6-flow 已有写法一致。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-19 12:50:44 +08:00
boweiandClaude Opus 5 e07cfaa6d1 sync: WIN-BOWEI 2026-08-10 fpga_flash 增 Zynq BOOT.bin/QSPI 脚本，rtl-ip-replace 与 sim-rtl-flow 更新 
- fpga_flash: 新增 build_zynq_boot.py / program_zynq_qspi.py（bootgen + program_flash，
  含备份、SHA-256/容量/marker 守卫）；vivado_env.py 增 resolve_sdk_dir（SDK_ROOT/SDK_PATH）；
  SKILL.md 补 Zynq 烧写流程，示例去掉写死的 D:\Xilinx\SDK\2018.1，改由 skills_env.md 解析。
- rtl-ip-replace: gen_ip.tcl / namespace_ip.py 更新。
- sim-rtl-flow: SKILL.md 与 run_sim_rtl_flow.py 更新。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-19 12:50:44 +08:00
Myfro9andClaude Opus 5 7a11bac29d fix(fpga_flash): 修复写入 Vivado cfgmem 器件表的 w25q128bv 行格式错误 
check_flash_csv.py 里 NEW_ROW 是硬编码的 9 字段、从 NAME 开头，而 Vivado
2018.1 的 xicom_cfgmem_part_table.csv 是 14 列、首列为数字 CFGMEM_ID。
Vivado 于是拿 "w25q128bv-spi-x1_x2_x4" 去转 int，抛

    bad lexical cast: source type value could not be interpreted as target

这条错误同时打挂 get_cfgmem_parts 和 refresh_hw_device。后者最具误导性：
它报在硬件刷新阶段，看起来像 probe/.ltx/debug core 的问题，与 CSV 毫无关联，
实际上 refresh_hw_device 内部也读这张表。SMOD 板实测因此完全无法烧写 flash。

改为动态生成：克隆 Vivado 自带的 mt25ql128-spi-x1_x2_x4 行（同为 spi /
x1_x2_x4，COMPATIBLE_DEVICES 含 xc7a200t），只替换 Winbond 相关字段，
字段位置按表头列名定位而非写死下标，换 Vivado 版本 schema 变了也不会写出
畸形行。CFGMEM_ID 取现有最大值 +1。

MEM_DEVICE_ALIAS 指向 n25q128-3.3v-spi-x1_x2_x4 —— Vivado 真正带数据的那个
定义（mt25ql128 也别名到它）。不需要 Winbond 专属数据文件：flash loader
比特流按 FPGA 型号索引（bitfile.zip 里是 spi_xc7a200t_pullnone.bit），
与 flash 型号无关。

其它改动：
- 识别并替换旧版本留下的畸形行（退出码 2），而不是因为 "名字已出现在文件里"
  就误判为已安装直接返回 0
- 改写前自动备份 CSV
- 保留原文件的行尾风格，不整体改写 CRLF/LF

实测（Vivado 2018.1 + SMOD Artix-7 xc7a200t + 真实 W25Q128BV）：
- 三条路径均正确：已存在且格式正确→exit 0 且不改文件；全新→exit 2；
  注入 9 字段畸形行→识别并修复→exit 2
- get_cfgmem_parts 可正常返回，属性 MEM_TYPE=spi / MEM_DENSITY=128
- 烧写读回 Mfg ID : ef  Memory Type : 40  Memory Capacity : 18（真实
  Winbond JEDEC ID），Erase / Program-Verify / completed successfully 全过

SKILL.md 排错表补上该症状，并注明报在 refresh_hw_device 上的误导性。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-30 22:19:56 +08:00
Myfro9 8eddd0985a sync: HP_BOWEI 2026-07-27 vivado-sim 去掉写死的 Vivado 盘符路径 
SKILL.md 把 Vivado 安装路径写死成 C:\Xilinx\Vivado\2018.1，但各机器盘符不同
（HP_BOWEI 上实际是 D:\），照抄命令会直接失败。改为从 ~\skills_env.md 的
VIVADO_ROOT 取值，命令块统一用 $VIVADO_BIN / $VIVADO_DATA 变量。
 2026-07-27 13:56:51 +08:00
bowei ea4541ee90 sync: SHANGHAI-U9 2026-07-27 三个 Simulink→RTL skill 转系统级 + 新增 simulink-rtl-redev 
- simulink_rtl_dev / rtl-ip-replace: 从工程级 .claude/skills 迁到用户级并去工程耦合
  (模型名/Notes 文档依赖/工程实测基线移出; addpath 与脚本路径改用户级)
- rtl-ip-replace/scripts/gen_cmp_tb.py: Vivado 路径不再写死, 改读 VIVADO_PATH /
  XILINX_VIVADO (兼容 install root / bin / bin\vivado.bat 三种写法), 回落时提示
  去设 skills_env.md 的 VIVADO_PATH
- simulink-rtl-redev: 新增。原生模型改动后的仿真模型同步规范, 含两个实测过的工具
  check_sync.py (三条时序链新鲜度闸门) 与 measure_k.m (时域/频域/包络三估计器互证)
- sim-rtl-flow/SKILL.md: 加入 sync_sim:* 步骤, 引用上述三个 skill
 2026-07-27 10:39:53 +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 8080703a0e sync: SHANGHAI-U9 2026-07-27 2026-07-27 01:08:42 +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 a7e20d807d imx6: document VM bootstrap, stop hardcoding the cross-compile VM's IP 
The VMware segment changed, so the VM moved from 192.168.223.128 to
192.168.154.128 and every hardcoded reference was stale. A freshly-installed
VM also has neither sshd nor the toolchain, which previously only surfaced
half-way through a modify_imx6 iteration.

- fpga-imx6-flow: new "VM prerequisite check" section -- how to detect a
  missing sshd (Connection refused) and reach the guest over vmrun/VMware
  Tools when SSH is impossible, plus the Yocto SDK install + ARM-ELF
  verification step. Records the real gotchas hit during install:
  unattended-upgrades holding the dpkg lock, EOL xenial repos, and CRLF
  breaking scripts pushed into the guest.
- smod_atsc_dev SKILL/imx6.md: refer to CROSS_VM_HOST/USER/PASS, no literal IP.
- imx6_app.py: drop the stale 192.168.223.128 default so a missing
  CROSS_VM_HOST fails loudly instead of dialing the wrong host.

Machine-local values (IP, credentials, vmx/vmrun paths, toolchain prefix)
live in ~/skills_env.md, which stays out of git.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 08:11:51 -05: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
boweiandClaude Opus 4.8 fbfa060b67 Portabilize hardcoded C:\Users\bowei paths across skill docs 
Replace machine-specific C:\Users\bowei\... paths in 7 skill docs with
%USERPROFILE% / $env:USERPROFILE (or $USERPROFILE in Git Bash blocks).
Conda paths use a two-layout resolver (miniconda3\envs vs .conda\envs) or
reference ~\skills_env.md CONDA_LANGGRAPH_PYTHON, since the conda location
is machine-specific. Fixes paths that resolved wrong on non-bowei machines.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-20 20:35:43 +08:00
Myfro9andClaude Opus 4.8 2ad9206a88 gitignore: ignore local-only skill dirs at directory level 
Upstream only listed the vercel/claude-hud/find-skills/web-design files
individually, so newly added files under those dirs still showed up as
untracked. Ignore the whole directory for every skill that does not
exist upstream.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 07:22:11 -05:00
Myfro9andClaude Opus 4.8 eedb92e9fe gitignore: exclude local-only skills from skills-win sync 
BMSv4_pincfg and cubemx-min-prj were removed upstream but are still
used on this machine; keep them on disk and untracked. Also ignore
.stfolder (syncthing metadata) and .claude.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 07:10:06 -05:00
boweiandClaude Opus 4.8 742bed62eb langgraph-plan-review: replace hardcoded C:\Users\bowei paths with Path.home()/relative resolution 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-20 19:19:17 +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 05c78c1cee sync: WIN10-I9-64G 2026-07-20 2026-07-20 18:21:13 +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
Myfro9 bceafcd58c Update FPGA and Vivado skills 2026-07-14 18:18:17 +08:00