我的 WSL2 Ubuntu-24.04 突然无法启动，主要目标不是恢复整个 Linux，而是尽可能恢复其中 Hermes Agent 的自定义 skills。
原 WSL VHDX：
E:\WSL\Ubuntu-24.04\ext4.vhdx
Windows 报错：
无法启动分发，因为其虚拟磁盘已损坏。
Wsl/Service/CreateInstance/WSL_E_DISK_CORRUPTED
这个 VHDX 是动态磁盘，Windows 文件大小约 44 GB，但虚拟容量是 1 TB。
后来检查宿主 E 盘，发现 E 盘本身是 exFAT（据说这种格式很不适合），并且：
chkdsk E: /scan
报告：
Windows 在磁盘上发现错误
检查卷位图时发现损坏
文件存在交叉链接
坏扇区 0 KB
所以目前怀疑是宿主 exFAT 文件系统损坏，进而破坏了 WSL 的 ext4.vhdx。
我另外安装了 Debian WSL 作为救援系统，并以 bare 方式挂载旧 VHDX：
wsl --mount "E:\WSL\Ubuntu-24.04\ext4.vhdx" --vhd --bare
旧盘在 Debian 中对应：
/dev/sdd
新的 Debian 是另一块设备，未对其操作。
最初：
e2fsck -fn /dev/sdd
显示：
Bad magic number in super-block
Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 
这里我犯了一个比较严重的错误（这是GPT搞出来的，我对技术是完全不懂，他妈的）：之后执行过一次：
e2fsck -f -y /dev/sdd
它出现过：
Root inode is not a directory. Clear? yes
Root inode not allocated. Allocate? yes
/lost+found not found. Create? yes
Recreate journal? yes
所以 ext4 元数据显然已经进一步被修改。之后 debugfs 看到根目录基本只剩：
/
└── lost+found
而 lost+found 为空。
从那以后，我已经停止一切对旧 /dev/sdd 的写操作，当前只做只读恢复。
现在正在使用 PhotoRec 对整个 /dev/sdd 做 raw carving：
Disk /dev/sdd - 1099 GB / 1024 GiB (RO)
恢复结果写到健康的 D 盘：
D:\HermesRecovery.1
D:\HermesRecovery.2
...
PhotoRec 会不断生成新的 HermesRecovery.N 目录。
目前已经恢复出 6 万多个文件，包括大量：
.txt
.py
.gz
.sqlite
.java
...
我的真正目标是恢复原来的：
~/.hermes/skills/
尤其是我自己通过 Hermes /learn 或自动学习生成的 custom skills。
问题是 PhotoRec 不保留原始文件名和目录结构，因此原本类似：
~/.hermes/skills/my-skill/
├── SKILL.md
├── scripts/xxx.py
└── references/xxx.txt
现在可能变成：
f123456.txt
f123789.py
f124000.txt
目前我已经从恢复文件中识别出约 214 个真正符合 Hermes SKILL.md 格式的文件，其典型格式为：
name: xxx
description: xxx
但是这些 214 个里大量是 Hermes 官方/公共 skill，例如：
llama-cpp
tensorrt-llm
stable-diffusion
github
pdf
xlsx
powerpoint
playwright-cli
browser-use
...
因此目前还没有确认找到我自己的 custom skill。
我还尝试寻找 Hermes 的一些辅助数据：
~/.hermes/skills/.usage.json
~/.hermes/skills/.bundled_manifest
~/.hermes/skills/.hub/lock.json
~/.hermes/skills/.curator_ledger.jsonl
~/.hermes/state.db
~/.hermes/skills/.curator_backups/.../skills.tar.gz
目前结果如下：
真正 .usage.json：未找到
真正 Hermes state.db：未找到
curator ledger：未确认找到
custom skill：未确认找到
真正 SKILL.md 内容：已找到约 214 个，但看起来主要是官方/公共 skills
找到了 7 个 SQLite 文件，但检查 schema 后都不像 Hermes state.db：
SQLite 候选: 7
Hermes-like DB: 0
skill_manage / /learn 命中: 0
还找到过一个包含 SKILL.md 的 .gz：
package/lib/tools/skills/playwright-cli/SKILL.md
package/lib/tools/skills/playwright-component-testing/SKILL.md
package/lib/tools/skills/playwright-trace/SKILL.md
但这个明显是某个软件包 archive，不是 ~/.hermes/skills 的备份。
现在主要想请教以下问题：
在 ext4 元数据已经严重损坏、而且 root inode 曾被错误的 e2fsck -y 重建过的情况下，除了 PhotoRec/file carving，还有没有更适合恢复原目录结构、inode 或文件名的方法？
有没有办法从 ext4 的残余 inode、directory entry、journal、backup metadata 中，针对性恢复原来的：
/home/<user>/.hermes/skills/
而不是全盘 raw carving？
PhotoRec 已经恢复出大量 SKILL.md 内容，但没有目录结构。有没有比较可靠的方法判断哪些是：
Hermes bundled skill
Hub 安装的 skill
用户 /learn 创建的 custom skill
agent 自动生成的 skill
如果 .usage.json、state.db、.curator_ledger.jsonl 都没恢复出来，还有没有 Hermes 自己留下的其他 provenance/index/cache 能帮助确定 custom skill 名称？
PhotoRec 当前扫描的是 1 TB 逻辑 VHDX，但实际动态 VHDX 文件只有约 44 GB。有没有更高效的方法只扫描实际已分配的 VHDX blocks，而不是把整个 1 TB 虚拟地址空间扫完？
如果有人熟悉 ext4, WSL2 ext4.vhdx, PhotoRec/TestDisk, debugfs, extundelete, ext4magic 或 Hermes Agent，非常希望能给我一个以“恢复原来的 custom skills”为目标的方案，而不是恢复整个 Ubuntu。
目前旧 VHDX 已经停止写入，PhotoRec 也是只读扫描，恢复结果全部写到 D 盘。
如果需要，我可以继续提供：
lsblk
dumpe2fs/debugfs 输出
e2fsck 日志
PhotoRec 当前进度
恢复出来的 SKILL.md 示例
恢复出来的 SQLite schema
VHDX 文件信息
我现在最想避免的是继续对原 VHDX 做任何可能破坏数据的写操作。