v1.18.0

Added

• devp config set enable_dotnet_build true adds a twenty-fifth adapter: the .NET
  build output MSBuild writes. bin/ and obj/ are the most generic directory names a
  repository can hold, so the adapter demands proof before claiming either — NuGet's
  restore writes obj/project.assets.json recording exactly which project it restored,
  and only when that record names a project file in the same directory is obj/
  claimed, with bin/ going along only when it holds nothing but Debug/Release
  build output. A bin/ full of committed tools, or an obj/ someone made by hand, is
  never touched. Opt-in like every build-tree adapter and idle-gated by
  build_idle_days; the next dotnet build writes both directories again.

• devp caches now sizes ccache and sccache, the compiler caches behind most C,
  C++ and Rust CI recipes — routinely several gigabytes that no row accounted for
  before. ccache is asked where its cache is (ccache --get-config cache_dir) and
  cleared with its own ccache --clear; sccache ships neither a path query nor a clear
  command, so its row uses the documented locations (SCCACHE_DIR respected) and
  devp caches clear sccache deletes the directory — after sccache --stop-server
  if the daemon is holding it open, which the report says on the row.

Changed

• The first run now asks before installing anything. dev-prune used to put its
  integrations in place on the first command — a managed copy of the binary on
  PATH, Git hooks, and a scheduled task running devp run --yes — and open the
  settings walkthrough afterwards. Installing first and asking second is, from the
  outside, the exact shape of malware establishing persistence, and anti-virus
  classifiers flagged the 1.17.0 release executable for that behaviour. Now the
  walkthrough opens first, its opening screen lists exactly what finishing it will
  install, and nothing is installed until you finish it: accepting the recommended
  setup is still one key (a), everything it enables can still be switched off
  individually on the settings list, and quitting (q) installs nothing — durably,
  so no later upgrade installs it either. devp setup remains the standing way to say
  yes later, devp uninstall now clears the answer so a reinstall asks again, and
  machines upgrading from 1.17.0 or earlier are not re-asked — keeping the
  integrations the old flow installed already answered the question.

Fixed

• devp config project <PATH> --team now writes the public schema URL into the
  committed project.devprune.json. It used to inherit the personal file's preference
  for the locally installed schema copy, which put a file:///C:/Users/<name>/... path
  — username included — into a file whose whole purpose is to be committed, and broke
  IntelliSense on every clone but the author's. If you created one before this release,
  replace its $schema value with
  https://devprune.vkrishna04.me/schemas/v1/devprune.schema.json.

• A declared rebuild that starts with a shell builtin now says what to write
  instead. "rebuild": "cd docs && npm run build" was refused with "Install cd
  first" — advice that cannot be followed, because cd is not a program. The refusal
  now names the actual fix: put the tool first, as in npm --prefix docs run build.
  The check is also the same on every platform now; macOS ships a /usr/bin/cd shim
  that used to let such a declaration through there while Windows refused it.

For contributors

• The release build now fails if a shipping binary contains dropper-bait strings —
  the PowerShell obfuscation flags, Defender-exclusion cmdlets and injection API names
  that the 1.15.0 hardening removed by hand. scripts/check-binary-hygiene.sh holds
  the list and runs over every staged executable (the Windows zips unpacked,
  devpw.exe included) before anything is published, so a dependency that smuggles
  one back in fails in CI instead of in front of seventy antivirus engines.

---

Which download do I want?

Most people want none of them. The installers below verify the SHA-256
sidecar, put the binary somewhere already on PATH, and create the devp
alias — three things unzipping an archive does not do.

You are on	Run this
Windows (PowerShell)	iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex
Windows (Command Prompt)	powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex"
macOS / Linux	curl -fsSL https://devprune.vkrishna04.me/install.sh | sh
Python tooling	uv tool install dev-prune==1.18.0 / pipx install dev-prune==1.18.0
Rust, no compile	cargo binstall dev-prune@1.18.0
Rust, from source	cargo install dev-prune --version 1.18.0 (needs Rust 1.88+)

The PyPI packages contain these same binaries rather than downloading one
afterwards, so they work behind a registry mirror and offline. cargo install
is the only channel that compiles on your machine; cargo binstall reaches
for the archives on this page instead.

Full instructions: https://devprune.vkrishna04.me/#install

The assets, then

Take one only if you are packaging dev-prune yourself, air-gapping it, or
pinning it into a container image.

Asset	For
dev-prune-v1.18.0-windows-x64.zip	Windows on Intel/AMD — almost every Windows PC
dev-prune-v1.18.0-windows-arm64.zip	Windows on ARM — Surface Pro X, Snapdragon laptops, Windows in a Mac VM
dev-prune-v1.18.0-windows-x86.zip	32-bit Windows — locked-down corporate images, older industrial machines
dev-prune-v1.18.0-darwin-arm64.tar.gz	Apple Silicon Macs — M1 and later
dev-prune-v1.18.0-darwin-x64.tar.gz	Intel Macs — 2020 and earlier
dev-prune-v1.18.0-linux-x64.tar.gz	Linux on Intel/AMD
dev-prune-v1.18.0-linux-arm64.tar.gz	Linux on ARM — Raspberry Pi 4/5, Graviton, ARM CI runners

Both Linux builds are statically linked against musl, so they run on any
distribution including Alpine, with no glibc floor.

32-bit is published for Windows only. There is no 32-bit Linux, no 32-bit
macOS and no 32-bit ARM build on any platform; the install scripts refuse
rather than guess when they meet one.

There is no .vsix on this page. The VS Code extension has its own
version and its own release cadence, so it ships from its own tags:
the extension's releases.
Install it by name instead — VKrishna04.dev-prune, on the
VS Code Marketplace
and on Open VSX.

Windows: the binaries are not code-signed, and two separate features react
to that.

Windows protected your PC is SmartScreen, and it only challenges files
carrying a Mark of the Web — which your browser attaches to the download and
File Explorer copies onto everything it extracts. Clear the mark on the archive
before extracting and nothing inside it is ever marked:

Unblock-File .\dev-prune-v1.18.0-windows-x64.zip

The installers above already do this for you, on the archive and on both
installed copies.

A refusal with no dialog and no "run anyway" is something else: Smart App
Control, which blocks unsigned executables outright and never looks at the mark.
It is on by default on clean installs of Windows 11 22H2+ and always off on
upgraded ones, which is why the same release runs on one machine and not the
next. Unblock-File does not help, and neither does building from source.
The troubleshooting guide
covers what your options actually are.

Every archive ships a .sha256 sidecar. Check it before you trust it:

sha256sum -c dev-prune-v1.18.0-linux-x64.tar.gz.sha256

(Get-FileHash dev-prune-v1.18.0-windows-x64.zip).Hash -eq (Get-Content dev-prune-v1.18.0-windows-x64.zip.sha256).Split(' ')[0].ToUpper()

An archive's hash stops meaning anything the moment you unpack it, and the
unpacked files are the only ones your antivirus ever looks at. So each Windows
zip also ships a .zip.contents.sha256 listing the digest of every file inside
it — run this in the folder you extracted to, from Git Bash (sha256sum ships
with Git for Windows, and is what reads this format):

sha256sum -c dev-prune-v1.18.0-windows-x64.zip.contents.sha256

dev-prune.exe and devp.exe are one file under two names and share a digest
on purpose, so a scanner builds one reputation record instead of two.
devpw.exe — the console-free build the scheduled task runs — is compiled
separately and legitimately has a different one. devp trust prints the same
three digests for the copies already installed on your machine, so you can
compare them against this file without downloading anything again.

That sidecar proves the file was not altered in transit. It does not prove
where it came from — the same hand that swaps an archive swaps its sidecar.
Every archive on this page is also signed by GitHub's build provenance, which
binds it to this repository, this workflow and the commit it was built from:

gh attestation verify dev-prune-v1.18.0-linux-x64.tar.gz --repo Life-Experimentalist/dev-prune

gh attestation verify dev-prune-v1.18.0-windows-x64.zip --repo Life-Experimentalist/dev-prune

What's Changed

• The VirusTotal job slept through most of its own runtime by @VKrishna04 in #24
• Dogfooding polish: public schema URL in the team file, and a followable refusal for cd by @VKrishna04 in #25
• A generic bin/ is guilty until the assets file vouches for it by @VKrishna04 in #26
• The first run now asks before installing anything by @VKrishna04 in #27
• A stale "devp not found" in VS Code now heals itself by @VKrishna04 in #30
• The release now fails on strings that read as dropper tooling by @VKrishna04 in #31

Full Changelog: v1.17.0...v1.18.0