tracking: 工程门禁与测试有效性（2 项）—— 门禁看起来在把关，实际没把住
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 15/100
調査の方向性
This is a tracking issue, so start from its two sub-issues, #184 and #185, rather than from this body. For #184, read scripts/check-new-deps.sh around line 38, where the grep filter matches every line starting with + or -, and the CI workflow at .github/workflows/ci.yml around line 27 for the fetch-depth setting. For #185, read the ENV_LOCK definition in crates/recursive-cli/src/cli/builder.rs and the unlocked set_var calls in main.rs. Done means the sub-issues' acceptance checks pass, not this issue.
索引モデルが issue の本文から書いたものです。
説明
优先级 P2 · 依赖：无 · 类型：tracking（簇设计入口，不产出代码；子单全部落地后关闭）
记号：正文中的「不变量 #N」指.dev/AGENTS.md编号，不是 issue 编号；#150这类才是 issue。本簇子单头部写depends-on: #N表示落地串行（同文件/同契约），不会与语义阻塞混淆。
基线 HEAD = 14bac15a（子单同基线）。本单来自一次全仓审计：先按根因归簇，再拆成可独立验收的子单。
共同根因
两条都是「门禁看起来在把关，实际没把住」：
- 不变量 #6 空转（#184）：
scripts/check-new-deps.sh:38的grep -v '^[+-]\+\|...'里\+是「一个或多个」，于是所有+/-开头的行都被过滤，DEP_CHANGES恒空、脚本恒打印 OK；CI 用默认fetch-depth: 1（.github/workflows/ci.yml:27），HEAD~1不存在而:31用2>/dev/null吞错，于是走「unchanged」分支；tests/invariants/dep_justification.rs:68-79只找关键字，永远通过。另:49用了grep -P（GNU 扩展）。 - 测试隔离失效（#185）：
crates/recursive-cli/src/cli/builder.rs:1155-1177的ENV_LOCK是模块私有，而main.rs的测试另起一套直接set_var不取锁（:583、:3992、:4193-4229、:4372-4418、:4628-4695），二者在同一个测试二进制里并行跑。
本轮审计的普遍教训：多条真 bug 的测试执行到了但断言太弱——src/kernel/tests.rs:215-261 只断言非空（真 pinned #156 的丢消息）、src/compact/mod.rs:717 只测 should_compact 不测 runtime（#162 漏网）、handlers.rs:5771 只验层不被清空（#151 漏网）、scripts/check-new-deps.sh 自身（#184）、并行跑必红（#185）。
子单与依赖
| 子单 | 依赖 | 范围 |
|---|---|---|
| #184 | 无 | 修过滤器（只排除 ^+++/^---）＋ CI fetch-depth: 2 ＋ base ref 缺失即失败；夹具仓库自检 |
| #185 | 无 | 把 ENV_LOCK 提到 crate 级共享（或改为显式 env 视图）；并行跑 20 次全绿 |
落地思路
- 两单互不冲突，可并行。
- 建议同时确立一条 review 约定（写进
.dev/AGENTS.md的质量门一节）：凡修 bug 的 PR，必须包含「把复现该 bug 的弱断言改强」的一步——否则同一处会二次漂移。这条约定不属于本簇子单，需要单独决定是否入库。 - #184 属治理门禁（不改运行时行为）故 P2，但它是自改进 flow 的 rollback 判据之一，建议优先于其它 P2。
簇级验收
- 含新增依赖、无 journal 说明的夹具仓库让
check-new-deps.sh以非零退出； - CI 内
git rev-parse HEAD~1可用（fetch-depth: 2生效），base ref 缺失时门禁失败而非静默通过； cargo test -p recursive-cli --bin recursive连续 20 次（默认并行）全绿。
边界
不含本簇之外的功能类修复；不含「给每个仓库装上 mutation 门禁」这类更大的工程动作。
实施顺序与验收矩阵（补充 · 2026-10-10）
- 两单互不冲突，可并行；但 #184 建议优先：它是自改进 flow 的 rollback 判据之一，空转意味着"新增依赖无说明"这类改动永远不会被拦。
- 两单都不改运行时行为，因此不需要跑 e2e；验收就是"门禁真的会把坏的拦下来"。
- 建议同时决定是否把这条写进
.dev/AGENTS.md的质量门：凡修 bug 的 PR 必须包含"把复现该 bug 的弱断言改强"。本轮审计里 5 处弱断言（kernel/tests.rs:215-261、compact/mod.rs:717、compact/mod.rs:1322、handlers.rs:5771、本单 #184 自身）都是"测试跑到过、断言太松"。
- 主要言語
- Rust
- スター
- 4
- フォーク
- 0
- 平均マージ
- 5時間 32分
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
jeffkit/recursive のほかの issue
-
needs-human
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
jeffkit/recursive#159 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 53/100
jeffkit/recursive#195 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 15/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 8/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
メンテナーはふだん 1 日以内に返信
jeffkit/recursive の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 69/100
router-for-me/EasyCLIProxyAPI#406 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
ai-priority/P2 bug db/oracle user-priority/P1
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
Sweep stale notesオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 63/100