fix(deps): re-pin decmpfs to 0.1.0 so musl targets build

[jdx]

main's musl builds are broken. #1226 bumped decmpfs to =0.1.2 — the exact version the comment directly above the pin warns about:

# Pinned to 0.1.0: 0.1.2's FICLONE reflink path types the ioctl request as
# `libc::c_ulong`, which is `libc::Ioctl` on glibc but `c_int` on musl, so it
# fails to compile for *-unknown-linux-musl. Unpin once
# https://github.com/SocketDev/decmpfs releases a fix.
decmpfs = { version = "=0.1.2", features = ["addon"] }   # ← contradicts the comment

The compile failure, from the linux-x64-musl job:

error[E0308]: mismatched types
  --> decmpfs-0.1.2/src/linux.rs:296:60
   | libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd())
   |                                    ^^^^^^^ expected `i32`, found `u64`

This takes out linux-x64-musl and linux-arm64-musl in both the ffi and node-addon workflows — the jobs that build the musl npm packages — so the next release would publish without them.

Why it landed green

Neither workflow watched Cargo.toml or Cargo.lock. Their path filters list crate sources only, so a dependency-only change can't trigger the musl matrix. #1226 touched nothing but the manifest and lockfile and was therefore never built for musl.

I hit this on #1231, which happens to touch crates/aube-codes/** and so does trigger both workflows — that PR's musl failures are inherited from main, not caused by it.

Changes

• Re-pin decmpfs to =0.1.0 and downgrade the lockfile, restoring the state the comment describes. Still waiting on an upstream fix in https://github.com/SocketDev/decmpfs before it can move.
• Add Cargo.toml and Cargo.lock to the pull_request and push path filters of both workflows, so dependency bumps run the musl matrix instead of skipping it. That's also what makes this PR's own musl jobs run — they're the proof the pin fixes it.

Testing

cargo build, cargo clippy --all-targets -- -D warnings, and cargo test -p aube-store (110 tests) pass locally with the downgrade. I could not reproduce the musl compile locally — cargo check --target x86_64-unknown-linux-musl stops earlier on zstd-sys needing musl-gcc, which the CI runners install via musl-tools. The musl jobs on this PR are the real verification; worth confirming they're green before merging.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: unavailable.

---

Note

Low Risk
Dependency downgrade to a known-good pin plus CI path-filter tweaks; no runtime logic changes.

Overview
Restores musl builds by downgrading the workspace decmpfs pin from =0.1.2 back to =0.1.0 (with matching Cargo.lock), aligning with the existing comment about 0.1.2 failing on *-unknown-linux-musl due to an FICLONE ioctl type mismatch.

Updates ffi and node-addon GitHub Actions path filters so pull_request and push runs also trigger when only Cargo.toml or Cargo.lock change, so future dependency bumps exercise the musl matrix instead of skipping CI.

^{Reviewed by Cursor Bugbot for commit 92fab10. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Warning

Review limit reached

@jdx, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 18 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 24a98cab-2bfb-4343-8922-256b198453cc

📥 Commits

Reviewing files that changed from the base of the PR and between 6233612 and 92fab10.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• .github/workflows/ffi.yml
• .github/workflows/node-addon.yml
• Cargo.toml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	cargo/​decmpfs@​0.1.2 ⏵ 0.1.0	+28

View full report

[greptile-apps]

Greptile Summary

Re-pins decmpfs to the musl-compatible 0.1.0 release and updates both native-binding workflows so dependency-only changes exercise their build matrices.

• Downgrades the manifest and lockfile entries from 0.1.2 to 0.1.0.
• Adds the root Cargo manifest and lockfile to pull-request and main-push path filters for the FFI and Node-addon workflows.

Confidence Score: 5/5

The PR appears safe to merge, with the dependency pin and workflow triggers aligned with the stated musl build repair.

The lockfile matches the exact manifest pin, and dependency-only changes now reach unconditional FFI and Node-addon build matrices containing both musl targets; no actionable regression remains.

Important Files Changed

Filename	Overview
Cargo.toml	Restores the exact decmpfs 0.1.0 pin documented as necessary for musl compilation.
Cargo.lock	Consistently downgrades the resolved decmpfs package and checksum to 0.1.0.
.github/workflows/ffi.yml	Ensures root Rust dependency changes trigger the FFI workflow, including both musl matrix targets.
.github/workflows/node-addon.yml	Ensures root Rust dependency changes trigger the Node-addon workflow, including both musl matrix targets.

_{Reviews (1): Last reviewed commit: "fix(deps): re-pin decmpfs to 0.1.0 so mu..." | Re-trigger Greptile}

[github-actions]

Instruction counts

benchmark	trend	instructions	Δ	wall (min)	Δ
graph	▃▁▇▁▂▁▃██▁▂▂▃▂▃▂	17,554,975 → 17,544,479	-0.06%	4.53 → 4.38ms	-3.35%
install	▄▄▅▄▇▁▂▃▁▃▆▂▆▆█▄	150,344,890 → 131,809,604	-12.33%	32.55 → 32.99ms	+1.36%
startup	▁██▄▄▆▄▆▆▃▅▅▅▆▆▇	7,462,679 → 7,463,414	+0.01%	3.45 → 3.38ms	-1.92%
tree	▁▃▃▂▅▄▇▇▇▅▆▆▆▆▆█	17,729,364 → 17,740,325	+0.06%	4.54 → 4.76ms	+4.87%

No instruction-count regression above 1%.

_{Only instruction counts gate. Wall clock is shown for context — on identical hardware it moves 4-20% run to run.}

_{Measured by tak — instruction-counted CLI benchmarks, stored in this repository's git notes.}

_{92fab1096523 vs 62336120c643 · measured on this runner, not pushed to the history.}

[jdx]

Verification is in — all four musl jobs pass on this PR (both targets × both workflows):

Job	Result
linux-x64-musl (ffi)	pass 8m28s
linux-arm64-musl (ffi)	pass 11m36s
linux-x64-musl (node-addon)	pass 9m23s
linux-arm64-musl (node-addon)	pass 9m4s

They only run here because this PR adds Cargo.toml / Cargo.lock to the path filters, which is the same gap that let the bump land unbuilt.

For the other side of the comparison, I dispatched node-addon against main directly (empty tag, so signing and npm publish are both gated off — the workflow calls that a smoke build): https://github.com/jdx/aube/actions/runs/30955921912. Both musl jobs fail there. So it is main itself, not an artifact of any PR merge commit:

• main (decmpfs =0.1.2) → linux-x64-musl fail, linux-arm64-musl fail
• this PR (decmpfs =0.1.0) → all four musl jobs pass

That also closes the one thing I had flagged as unproven in the description: 0.1.0 does build for musl, not merely "was green before the bump".

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: unavailable.