[nox]

The committed lockfile matches the lockfile embedded in the published boring-sys 5.4.0 archive. It pins the release dependency graph, including cc 1.10.0, so rerun package checksums remain stable.

[clanky-the-clanker]

💬 Approved with comments — One WARNING: the committed Cargo.lock only pins boring-sys's dependency graph, not the whole workspace. Everything else looks fine.

Findings: 1 warning (1 is an inline comment on the diff)

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

🔧 Fix with your agent

Paste the following into your coding agent to investigate and fix these issues.

Fix the following code review issues found in pull request #552.

Before making changes, review each issue and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g., the fix would require disproportionate changes
  for minimal ROI, or the finding is factually incorrect), explain why
- If you need to clarify something before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

## WARNING (1)

### [Code Quality] Cargo.lock pins only `boring-sys`'s graph, not the four-member workspace: cargo will rewrite the tracked file, and the other crates' dependency resolution stays unpinned.
- **File:** Cargo.lock:39

---

📋 Code Quality: ⚠️ 1 warning

The committed Cargo.lock covers only boring-sys, not the workspace.

Recommendation: 📝 Minor Comments

• [WARNING] Cargo.lock pins only boring-sys's graph, not the four-member workspace: cargo will rewrite the tracked file, and the other crates' dependency resolution stays unpinned. (Cargo.lock:39)

View full review

• Cargo.lock is the pruned lockfile from the published boring-sys archive. It lists boring-sys and its build dependencies only. There are no entries for the other workspace members (boring, tokio-boring, hyper-boring) or for their dependencies (tokio, hyper, http, futures, brotli and so on).
• The first workspace-wide resolve will add those packages to this tracked file: cargo build, cargo test, or cargo package in the release job. The existing boring-sys entries stay as they are.
• Archives for the other three crates are still resolved at publish time, so checksums for those crates on a rerun are not pinned by this change.
• Fix: commit a full workspace lockfile instead. Run cargo generate-lockfile and keep cc at 1.10.0 with cargo update -p cc --precise 1.10.0, or let cargo extend this file. Consider adding --locked to the package and publish steps so a drifting lockfile fails loudly.

The v-prefix normalization and the User-Agent changes in publish.yml look consistent.

---

✅ All other checks passed

🚀 Release: ✅ LGTM

Risk: Low

---

🔒 Security: ✅ LGTM

No security concerns in the workflow or lockfile changes.

---

📖 AGENTS.md: ✅ LGTM

No issues.

---

⚡ Performance: ✅ LGTM

No performance concerns.

---

📝 Documentation: ✅ LGTM

No documentation issues in the changed lines.

---

_{Reviewed commit: d5ea9c16}

[clanky-the-clanker]

⚠️ WARNING · Code Quality

Cargo.lock pins only boring-sys's graph, not the four-member workspace: cargo will rewrite the tracked file, and the other crates' dependency resolution stays unpinned.

This is the pruned lockfile from the published boring-sys archive, but the root Cargo.toml is a workspace with boring, boring-sys, tokio-boring and hyper-boring. The first workspace-wide cargo build, cargo test or cargo package will add the packages for the other three members (tokio, hyper, futures and so on) to this tracked file. Their archives are also resolved fresh at publish time, so checksums for those crates on a rerun are not pinned. Fix: commit a full workspace lockfile (cargo generate-lockfile, then cargo update -p cc --precise 1.10.0), and consider adding --locked to the release steps.