DevForgeKit 3.0.1: the first stable release
npm install -g devforgekit, or brew install nouradinabdurahman/devforgekit/devforgekit. Both channels are live, independently verified, and the recommended way to install; no git clone required.

v3.0.1-rc1 asked one question: does this hold up outside a single development machine? A real npm publish, a real Homebrew tap, a real scratch-prefix install/uninstall cycle, and a full regression suite later, the answer was yes, with no release-blocking issues. v3.0.1 promotes the release candidate to stable. No code changed between the two; this is the same, verified build.
npm install -g devforgekit
devforgekit install
# or
brew install nouradinabdurahman/devforgekit/devforgekit
devforgekit installTwo real, verified channels
npm install -g devforgekit installs a self-healing dispatcher: if npm's own postinstall step gets skipped (confirmed live: npm 11.x's allow-scripts gate can do this silently), the CLI populates its own dependencies on first run instead of failing cold. brew install nouradinabdurahman/devforgekit/devforgekit ships through a dedicated tap, verified end-to-end with a real brew install --build-from-source, brew test, and brew uninstall cycle, not just a syntax check. Shell completions for bash, zsh, and fish are generated from the CLI's real command tree and installed automatically by the Homebrew formula.
A release-process bug, caught by the release process itself
The first attempt to tag v3.0.1 failed on purpose. devforgekit doctor --release-check, the same gate that runs before every tag, correctly refused to proceed because the Homebrew formula still referenced the previous version. That's not a bug in the product; it's the release gate doing exactly its job. The real fix exposed something more interesting: the formula file lives inside the same repository whose tag it describes, so updating its checksum changes the very archive that checksum is supposed to describe: a genuine circular dependency, not just a typo. It was resolved by computing the checksum against the actual, final tagged archive rather than guessing, verified with a real brew install --build-from-source before anything shipped. The underlying pipeline ordering is a known rough edge, scoped honestly for a future redesign rather than patched around.
What's actually verified
1,350 tests passing. npm audit: 0 vulnerabilities. gitleaks: 0 secrets found. The GitHub Release is published, marked Latest, not a draft, not a prerelease, with real SHA256 checksums and an SBOM in both CycloneDX and SPDX formats attached, not generated on request. Every claim on this site's registry, features, and CLI pages is checked against the same repository this release shipped from.
What's next
A live remote registry and the hosted plugin marketplace the SDK was designed for remain genuinely on the roadmap; see the roadmap page for the full, honestly-scoped list. Real hardware validation beyond macOS Apple Silicon (Intel Mac, Ubuntu, Fedora, Windows 11) is the immediate next step now that shipping is done and using it for real is what matters.