e.repoPath 被直接插进双引号 shell 字符串（git cat-file --filters --path="${e.repoPath}"），而 repoPath 来自 git ls-tree -r -z 的原始路径——-z 模式路径永不转义，除 NUL 外任意字节都可能出现。数据仓里一个名为 sub"; cmd; ".jsonl.gz 的文件即可在导入方机器上执行任意命令（LFS 模式导入时触发）。旧路径 git cat-file -p ${e.oid} 只插十六进制 oid 是安全的，这条是本 PR 新开的注入面；仓内其它拼 shell 的点（sid / prefix / branch / remote 地址）都做了白名单校验，这里建议对齐：改用 spawnSync argv 形式（['cat-file', '--filters', \--path={e.repoPath}\`, e.oid]`）彻底绕开 shell，或对 repoPath 加 `^[\w./-]+` 校验。

同样的大写 B 缺口：CANNBay 规则只挂在 MD_RULES（仅 .md 生效），而 src 里有多处硬编码——src/cli/cpx-upload.ts:455 日志 'insight Web UI「CANNBay」列表可见'、src/cli/cpx-cli.ts 帮助文本的「无感上传 CANNBay」等，均随 files 白名单（src）进 context-cpx 成品；tests/context-pack.test.ts 的 forbidden 列表也只扫小写 'CANNbay'。cpx 源码里没有 CANNBay 形态的仓 URL（insight 侧才有 v1 URL 的坑），可以直接把 CANNBay → contextBay 提进 GLOBAL_RULES，哨兵同步补 'CANNBay' 扫描。

if (!fs.existsSync(gaPath)) 只在工作树无 .gitattributes 时才从 origin/main 物化，但同一镜像的工作树可能留有过期的剔除版：默认模式的 uploadFolder 会在本镜像 sparse-checkout 出的 .gitattributes 里剔除 filter=lfs 行并写回工作树（else if 分支），之后 cpx 以 LFS 模式上传会把该行重新加回 origin/main。此时 insight 侧设 CANNBAY2_LFS=1 导入指针会话：工作树 .gitattributes 存在但缺 *.gz filter=lfs 声明 → cat-file --filters 不做 smudge → LFS 指针文本被当作 gzip 内容落盘，导入在解压环节报出费解错误。建议与 ensureLfsGitattributes 的判定对齐：LFS 模式下只要工作树副本缺 ^\*\.gz\s+filter=lfs 声明就刷新（用 git show origin/main:.gitattributes 覆盖），而不是仅看文件是否存在。