补齐 bin/lc 的测试覆盖：16 个命令里只有 4 个有门禁

[LouisDM]

现状

bin/lc 已经 1137 行、16 个命令，但 ci.yml 的断言只钉住其中 4 个：

有门禁	sync（配置生成器输出）、doctor（tool calling 探测，test-doctor-probe.sh）、export（打包内容，test-export.sh）、code（仅 --help 能跑）
没有任何断言	init、add、ls、use、rm、up、down、status、logs、test、e2e、migrate

对没覆盖的那 12 个，CI 唯一能保证的是 py_compile 过得去——语法对，行为完全没验证。

为什么现在提

这个仓库的改动很大比例由 issue-agent 自动产生。它遵守「CI 覆盖不到的不自动合并」这条规则，所以覆盖缺口会直接变成吞吐瓶颈：碰到没门禁的命令，它只能开 PR 然后停下来等人工审核。

反过来，覆盖不足时「CI 全绿」会给出虚假的安全感。这个坑已经踩过一次：PR #9 在版本比对零断言的情况下被合并，agent 把「没破坏既有断言」误读成「新代码被验证」。

优先级建议

第一梯队（写坏了会静默毁掉用户配置或泄密）

• init / add —— 交互式写入 .env 和 registry.json。要断言：密钥只进 .env 从不进 registry；headers 的值走 KEY_*_HEADER_* 变量名而不是明文（这是 团队场景：registry.json 被 gitignore，导致每个人都要重新 lc init #4 的成果，现在没有任何东西防止它回归）；.env 权限是 0600
• rm —— 要断言删上游时对应的 KEY_* / KEY_*_BASE / header 变量一并从 .env 清掉，不留孤儿密钥
• migrate —— 迁移逻辑写错会破坏已有用户的配置，且不可逆

第二梯队（错了会浪费排查时间但不致命）

• use —— 切换后 codex/config.toml 的默认 model 真的变了
• ls —— 不泄漏密钥值到 stdout（现在只显示 base URL，但没有断言防止有人「顺手」把 key 也打出来）
• status / up / down —— 至少断言参数拼装正确、网关不可达时给干净报错而不是 traceback

第三梯队

• test / e2e —— 本身就是测试入口，断言它们在网关不可达时干净失败即可
• logs —— 薄封装，优先级最低

实现约束

• 不引入第三方依赖。pytest 也不要——用 scripts/test-*.sh + python3 标准库，和现有的 test-doctor-probe.sh / test-export.sh 保持一致
• 不碰开发机的真实配置。现有两个测试脚本都在临时目录里造假 registry.json / .env，沿用这个模式
• 交互式命令需要喂输入。init / add 走 input()，用管道喂或者加一个 --non-interactive 入口，后者更好测也更适合脚本化使用，可以顺带做掉
• 每条断言都要做变异测试。参考 test-export.sh 的做法：故意把代码改坏，确认断言真的变红。写了抓不到东西的断言比没有断言更糟——它制造虚假安全感

分批交付

一次性写 12 个命令的测试太大，PR 会没法 review。建议按上面的梯队分三个 PR，每个 PR 只动一个梯队，并在描述里列出 ci.yml 需要加的行（agent 推不了 .github/，那几行由人工补）。

一个额外收益

做这件事的过程中大概率会发现现存缺陷——写测试逼着你想清楚边界条件。发现了就单独开 issue，不要夹带在测试 PR 里。

[github-actions]

🤖 由 issue-agent 自动发布

已交付第一梯队：PR #14。不能自动合并，卡在两行 ci.yml 上，细节在文末。

做了什么

只新增 scripts/test-lc-secrets.sh，40 条断言，覆盖 init / add / rm / migrate。没有碰 bin/lc，产品行为一字未改。

按 issue 里的实现约束逐条对齐：

• 零依赖 —— 只用 bash + Python 标准库，没引 pytest
• 不碰开发机真实配置 —— 整份测试在 mktemp -d 里跑，只复制 bin/lc（lc 的 ROOT 由 __file__ 上两级推导，所以它读写的 registry.json / .env / litellm/ / codex/ 全落在临时目录）。跑完 git status --short 干净
• 交互式命令用管道喂答案 —— 没做 --non-interactive。那是改 CLI 表面的独立决策，不该夹带进一个纯加测试的 PR；管道喂答案已经够用。代价是答案顺序和提问顺序耦合（提问顺序变了测试会红，而且是以「已取消」的形式红），这点写进脚本注释了。要不要做 --non-interactive 留给你决定
• 哨兵值运行时现生成 —— test-export.sh 注释里记的那个坑：脚本自己也是仓库源码，写死的字面量会让「按值搜」的断言被脚本自身内容误触发

变异测试：18 个变异，18 个被抓到

issue 里那句「写了抓不到东西的断言比没有断言更糟」是对的，所以每条断言都反向验过 —— 把 bin/lc 故意改坏再跑，确认真的变红：

变异
API Key / Base URL / header 值明文写进 registry（3 个）	🟢
.env 权限放宽成 0644	🟢
config.yaml 内联值而不走 os.environ/	🟢
rm 不清 header 变量（孤儿密钥）	🟢
rm 不清 KEY_* / 不回落 default / 误删其它上游（3 个）	🟢
init 无视已有 registry 重问 / 悄悄改掉已有上游的 ctx（2 个）	🟢
migrate 不更新 registry / 不写 .env / 不幂等 / 不提醒轮换（4 个）	🟢
sync 不再警告明文 header	🟢
master key 的值被写进 registry	🟢

最后那条一开始是漏网的，值得单独说，因为它正好证明了变异测试的必要性：原来写的是 refute ... "LITELLM_MASTER_KEY"，查的是变量名在不在 registry 里。可泄漏的形态是那串 sk-lc-… 的值出现在 registry 里 —— 变量名本身出现反而无害。查错了对象，那条断言永远不会红。改成从 .env 读出实际值再反查，变异立刻被抓到。

⚠️ 差哪条断言：ci.yml 的两处

我推不了 .github/，实测被 GitHub 拒绝：

! [remote rejected] feat/issue-12 -> feat/issue-12 (refusing to allow a Personal
Access Token to create or update workflow `.github/workflows/ci.yml` without `workflow` scope)

所以这个脚本现在不会被 CI 执行。这不是推测，我在分支上跑了一遍 CI 验证过 —— run 31412445199 static 和 docker 双绿，而整份日志里 test-lc-secrets 出现 0 次。这正是本 issue 说的「覆盖不足时 CI 全绿会给出虚假的安全感」，只不过这次虚假安全感的对象是测试脚本自己。

需要人工补的两处（PR #14 的描述里有可直接粘贴的完整片段）：

1. 第 31 行 bash -n 列表末尾加 scripts/test-lc-secrets.sh
2. 在「lc export 的包内容校验」之后插一个 step：run: bash scripts/test-lc-secrets.sh

补完之后 PR #14 才真的钉住了这些不变量，那时再合。脚本独立执行不需要 docker / 网络 / API Key，约 1 秒。

顺带说明

• 本 issue 不该被 PR test: 钉住「机密只进 .env」这个不变量（lc init / add / rm / migrate） #14 关掉，它是分三批交付的，test: 钉住「机密只进 .env」这个不变量（lc init / add / rm / migrate） #14 只完成第一批。第二 / 第三梯队等第一批合了再做，免得同时开三个 PR 互相打架。
• issue 结尾那句「做这件事的过程中大概率会发现现存缺陷」应验了：写 rm 那组断言的时候顺着想到了 add 的覆盖路径，确认那里有个真的孤儿密钥缺陷，已单独开 issue，没有夹带进 test: 钉住「机密只进 .env」这个不变量（lc init / add / rm / migrate） #14。

[github-actions]

🤖 由 issue-agent 自动发布

第一梯队（#14）已经合并，ci.yml 里那两行也补上了——scripts/test-lc-secrets.sh 现在是真的在跑的。顺带说一句：#15 那个 lc add 孤儿密钥缺陷（就是写第一梯队时顺手发现的那个）已经修完合并了（#22），补的 11 条断言直接加在同一个脚本里，所以没有再多一个 ci.yml 缺口。

已交付第二梯队：PR #25。同样不能自动合并，卡在一处 ci.yml 上。

覆盖

只新增 scripts/test-lc-commands.sh，34 条断言，没碰 bin/lc。

命令
use	切换后 codex/config.toml 的默认 model 真的跟着变；切到不存在的上游报错并列可用值、不改坏 registry；不给参数给用法
ls	该显示的都显示；API Key / header 值 / master key 一个都不许进 stdout；空注册表给指引
status / up / down	docker 参数拼装；up 之前先 sync；网关不可达时干净报错而不是 traceback

对着你在 issue 里列的第二梯队逐条对了一遍，都在。

use 那条按你写的「切换后默认 model 真的变了」实现，但只看 registry 是不够的——Codex 对不存在的 profile 静默回落，所以断言必须落到生成出来的 codex/config.toml 上。少了这一步，「registry 改了但忘了 sync」这个变异抓不到。

两个实现上的选择，供你评判

1. docker 用假桩（记录 argv 的 shell 脚本插在 PATH 最前）。断言的是「lc 交给 docker 的是什么」，不在 CI 里真起容器。
2. 网关用真的 HTTP 桩监听现取的空闲端口。不起它的话 lc up 会等满 45 秒——wait_gw 是 45 次 × 1 秒。整份脚本 1 秒跑完。

顺带：这也意味着「网关 45 秒没起来」那条分支没有被覆盖（覆盖它就得在 CI 里真等 45 秒）。它的兄弟分支（status 探活失败）覆盖到了。要不要为那条分支给 wait_gw 开一个可注入的超时，是改产品表面的独立决定，没夹带进来。

变异测试：6 个变异，6 个被抓到

细节在 PR 里。其中一个值得单独说，因为它是「断言抓到了但指错方向」的例子：把「探活异常直接冒出来」这个变异注进去之后，脚本一开始只以「lc status 执行失败」收场——红是红了，但读的人会以为是命令挂了，而不是「吐了 traceback」。根因是那一步的 runner 要求退出码为 0，异常一漏出来就先在那儿失败了。换成不看退出码、只看输出的 runner 之后，两条断言精确命中。

⚠️ 差哪一行 ci.yml

我推不了 .github/。需要在「机密只进 .env 这个不变量」之后插一步：

      - name: use / ls / up / down / status 的行为
        # issue #12 第二梯队的门禁：34 条断言，docker 用假桩、网关用 HTTP 桩，
        # 不需要 docker / 网络 / API Key，约 1 秒。
        run: bash scripts/test-lc-commands.sh

补完再合 #25。

第三梯队

test / e2e / logs，等第二批合了再做，免得同时开多个 PR 互相打架。

另外回应你 issue 结尾那句「大概率会发现现存缺陷」：这一批没有发现新缺陷，use / ls / status 现有实现的行为都是对的，缺的只是断言。第一梯队那次发现了一个（#15，已修）。

[LouisDM]

第一、二梯队已合（PR #14 / #25），继续推第三梯队。

当前覆盖状况

元断言（PR #31）现在保证「每个 scripts/test-* 都被 CI 执行」，10 个测试脚本全部接入或显式豁免。命令层面的覆盖：

	命令
已有行为门禁	sync、doctor、export、init、add、rm、migrate、use、ls、up、down、status
仍无覆盖	test、e2e、logs、code

第三梯队要什么

按 issue 正文里的分级，这四个是最后一批，价值低于前两批，所以不要写得比它们值得的复杂：

• test / e2e —— 它们本身是测试入口，别去测「测试跑得对不对」。只需断言：网关不可达 / profile 不存在时干净失败（明确一句话 + 非零退出码），而不是 traceback 或静默退出 0。e2e 还要断言那个防呆（profile 不存在时明确列出可用 profile，之前踩过「以为在测 A 其实在测 B」）。
• logs —— 薄封装，断言参数拼装正确即可，别真去起容器。
• code —— 断言网关不可达时不启动 Codex（现在是 die("网关没起来")），以及 CODEX_HOME 指向仓库内的 codex/ 而不是用户的 ~/.codex。后者很重要：写错了会污染用户全局配置。

完成后这个 issue 就可以关了

三批做完，16 个命令里除了 code 的交互路径（需要真模型，本来就该豁免）之外都有门禁。

关于 --non-interactive：不做。registry.json 已可提交，新人 clone + 写 .env 即可，不需要跑 lc init。测试继续用管道喂 stdin。等出现批量供给（Ansible / 镜像预置）的真实需求再议，届时改 ask() 一处收口读环境变量，不要加一堆 flag。