Repository navigation
refactor(layering): 首批下移工具适配层，并加装分层门禁与首个 CI - #1
Conversation
四 crate 的设计意图是 core（契约）← runtime（执行）← adapters（工具适配） ← cli（组装），但实际倒挂：adapters 已持有 ESLint/Checkstyle/Cargo/Go 的诊断 类型，其身份映射逻辑却住在二进制 crate，使 cli 顶层模块达 145 个、远超 core。 本 PR 不做一次性大搬迁（diff 无法审阅），而是先搬最干净的一族并装上门禁： - 4 个 *_finding_identity（eslint/cargo_build/go/rustdoc，共 332 行）从 codeguard-cli 迁至 codeguard-adapters。四个模块本就直接依赖 adapters 的诊断 类型，跨 crate 后改为 crate 根 re-export；eslint 的 validate_records 由 pub(crate) 提升为 pub。cli 顶层模块 145 → 141，adapters 61 → 65。 - scripts/check_layering.py + layer-baseline.json：把倒挂变成显式债务。 cli 中剩余的 13 个领域形态模块（9 个 *_probe、2 个 *_module_graph、 npm_input_state、tool_identity）逐条登记归属与理由，额度只减不增—— 新增未登记的领域模块会失败，模块下移后基线未同步收紧也会失败。 两个方向都做了负向验证。 - .github/workflows/ci.yml：本仓此前没有任何 CI，995 个测试无自动门禁。 门禁跑 layering check + build + test。 关于固定语料的一个坑：corpus_integrity 会按 sha256 校验来自 codeguard-plugin@9e4adb1 的真实文件，只建空目录不够（实测摘要不匹配）， CI 必须把该 commit 检出到兄弟目录。 验证：995 通过 / 0 失败（重构前后一致，无测试增减）。
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8808478d97
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| stem = rel[:-3] | ||
| if stem.endswith(CLI_ALLOWED[:-1]) or stem in ("main", "lib"): | ||
| continue | ||
| for suffix, home in HOME_FOR.items(): | ||
| if stem.endswith(suffix): |
There was a problem hiding this comment.
When a conventional directory module such as src/foo_identity/mod.rs is added and declared from lib.rs, stem becomes foo_identity/mod, so none of the suffix checks match; lib.rs is also explicitly skipped. I verified that adding this structure leaves the gate reporting “Layering OK,” allowing exactly the new adapter-shaped CLI module this check is intended to reject. Inspect the parent directory name when the file is mod.rs.
Useful? React with 👍 / 👎.
| run: python3 scripts/check_layering.py | ||
|
|
||
| - name: Build workspace | ||
| run: cargo build --workspace --all-targets |
There was a problem hiding this comment.
When a PR changes Cargo.toml but omits the corresponding Cargo.lock update, this command may resolve dependencies and rewrite the lockfile only inside the ephemeral runner, allowing CI to pass even though the repository's documented locked build/test commands will fail for users. The local cargo build --help describes --locked as “Assert that Cargo.lock will remain unchanged”; add it here so CI detects stale lockfiles.
Useful? React with 👍 / 👎.
| # ubuntu-latest 预装稳定版 Rust；Cargo.toml 声明 rust-version = 1.85 / edition = 2024。 | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
The repository declares Rust 1.85 as its minimum, but this job uses whichever newer stable toolchain happens to be preinstalled on ubuntu-latest. A change using an API or language feature introduced after 1.85 will therefore pass CI while failing for users on the supported minimum compiler; install and select Rust 1.85 for at least one build/test job.
Useful? React with 👍 / 👎.
PR #1 的门禁按「命名像领域模块就应下移到 adapters」判定，这是错的。 本仓 `crates/codeguard-cli/tests/crate_boundaries.rs` 早已用测试强制： codeguard-adapters 仅可依赖 core / serde / serde_json / roxmltree / toml / sha2 codeguard-runtime 承担进程执行 codeguard-cli 编排，可依赖以上三者 据此，`*_probe` 探针调用 `run_process_recorded`、需要 runtime，而 adapters 被 明确禁止依赖 runtime——**探针留在 cli 是正确的，把它们"下移"会被 crate_boundaries 直接判失败**。PR #1 的基线把 9 个探针登记为债务，等于在 引导后来者走一条注定被本仓测试拒绝的路。 实测 13 项登记项的真实依赖： - 10 项依赖 codeguard_runtime → 依边界不得进 adapters - module_graph / cargo_module_graph 虽不依赖 runtime，但依赖 cli 本地的 crate::discovery，不能单独下移 → 真正错位者为 0。 本 PR 改用「依赖」而非「命名」判定：只有既不需要 runtime、也不引用 cli 本地 类型的领域模块才算错位，并删除 layer-baseline.json（纠正后无已知债务）。 双向负向验证： - 新增自足领域模型 → 失败（正确捕获） - 新增依赖 runtime 的探针 → 放行（不再误报） crates/ 零改动；测试 997 通过 / 0 失败。
1 participant
问题
四 crate 的设计意图是
core（契约）←runtime（执行）←adapters（工具适配）←cli（组装），但实际倒挂：adapters已持有 ESLint / Checkstyle / Cargo / Go 的诊断类型，其身份映射逻辑却住在二进制 crate，使codeguard-cli顶层模块达 145 个、远超codeguard-core。一次性大搬迁会让 diff 无法审阅。本 PR 先搬最干净的一族，并装上防回退的门禁。
内容
1. 首批真实搬移（4 文件 / 332 行）
*_finding_identity（eslint / cargo_build / go / rustdoc）从codeguard-cli→codeguard-adapters。四者本就依赖 adapters 的诊断类型，跨 crate 后改用 crate 根 re-export；eslint 的validate_records由pub(crate)提升为pub。codeguard-cli顶层模块 145 → 141codeguard-adapters模块 61 → 652. 分层门禁（
scripts/check_layering.py+layer-baseline.json）把倒挂变成显式债务而不是静默增长：
*_probe、2 个*_module_graph、npm_input_state、tool_identity）逐条登记归属 crate 与理由3. 首个 CI（
.github/workflows/ci.yml）本仓此前没有任何 CI，995 个测试无自动门禁。现在跑 layering check + build + test。
一个值得记下的坑
corpus_integrity会按 sha256 校验来自codeguard-plugin@9e4adb1的真实文件。我最初在 CI 里写mkdir -p ../codeguard-plugin占位，实测不够（摘要不匹配，测试仍失败）——必须把该 commit 真正检出到兄弟目录。CI 已按后者实现。验证
重构前后均为 995 通过 / 0 失败，无测试增减。
CI 首次运行即为该仓建立基线；预期后续 PR 会暴露此前从未被自动检查过的问题。