DevForgeKit v3.0.2: Platform Stabilization, and the same circular dependency again

v3.0.1 shipped with an honest gap: every platform claim beyond macOS Apple Silicon was either untested or optimistically assumed. v3.0.2 closes that gap the only way that actually counts - real containers, real installs, real command surfaces exercised end to end - and then goes through a full release-readiness audit before anything touches npm, Homebrew, or the website. No feature work. All verification.

npm install -g devforgekit had a real, silent failure mode on Linux/WSL2: install with sudo (the common case on a system Node.js), and npm 11.16+'s allow-scripts security gate quietly skips the postinstall step that populates cli/node_modules. The dispatcher's self-heal fallback then tries to npm install into cli/ on first run - and hits EACCES, because a sudo-installed package leaves that directory root-owned. The printed recovery command failed with the identical error. No working path forward.

Reproduced for real in a clean Ubuntu 22.04 + npm 11.18 container, not inferred from reading the code. The fix: a second-level fallback to a user-writable mirror under ~/.cache/devforgekit/cli-fallback/, auto-invalidated when a newer cli/src ships. Four new regression tests cover the mirror, registry resolution through it, cache reuse, and stale-mirror invalidation. Full root-cause writeup in docs/NpmGlobalInstallRootCause.md.

macOS Apple Silicon, Ubuntu 22.04, and Debian 12 are certified: full first-time-user lifecycle, the complete command surface, uninstall/reinstall, source-vs-npm-install parity. Debian ran side-by-side with Ubuntu specifically to catch any Ubuntu-specific assumption hiding in an apt-family-generic code path - none found, beyond one real bug: bootstrap.sh's generic EXIT trap printed a misleading "Bootstrap aborted unexpectedly" for its own deliberate, by-design non-macOS rejection. One-line fix, verified on both distros.

Fedora, Arch, and macOS Intel are recorded as not yet certified, not assumed to work - blocked this cycle by a local Docker Desktop environment issue unrelated to DevForgeKit itself (Fedora/Arch) and no hardware access (Intel Mac). docs/PlatformSupport.md's compatibility matrix says exactly that, and it's tracked as a real GitHub issue for the next pass rather than left as a silent gap.

Before touching npm, Homebrew, or the website, every claim across both repositories got cross-checked against the actual code one more time. Two genuinely new, previously-missed stale references turned up: the CLI page said "reach any of twelve subsystems directly" while every other page correctly said fifteen (the real count, from features.ts), and the interactive demo terminal's fake dashboard output had "v3.0.1" hand-typed into a template string instead of reading it live - now reads siteConfig.version, so it can't go stale the same way again.

A repo-settings gap turned up too: the GitHub repository's own Website field was empty despite package.json and the README linking to devforgekit.dev everywhere else - fixed directly, since that's a settings change, not a publish action. Everything genuinely deferred (Fedora/Arch/Intel certification, a version_of() timeout risk found live during testing, a harmless orphaned npm-uninstall cache directory, and the still-stale dashboard screenshots showing a two-releases-old version number) got filed as real GitHub issues against the v3.1 milestone instead of staying words in a markdown file no gate actually checks.

v3.0.1's release post covered this exact failure mode in detail. It happened again, live, tagging v3.0.2 - which is the expected outcome, not a regression: the underlying ordering problem (a Homebrew formula that lives inside the same repository whose tag it describes) was scoped honestly as a known rough edge for a future pipeline redesign, not something the v3.0.1 fix eliminated.

Same resolution, same discipline: delete the premature tag, land the formula's url bump on its own (the release-readiness gate only inspects the version-shaped tag reference in url, never sha256, so this alone is enough to pass it), re-tag, then download the now-real archive and hash it for real. Two small PRs, each verified independently with a real brew audit + brew install --build-from-source + brew test against a local test tap before merging - not just "the Ruby parses."

Verification didn't stop at merge. After the website deploy went live, a direct check of the production /cli page turned up a third stale number the earlier pass had missed: its SEO description said "12 command categories", not derived from any real source. lib/data/commands.ts's actual commandCategories array has 13 entries - a genuinely distinct concept from the "fifteen subsystems" figure used elsewhere on the same page (features.ts's count), so the fix was 13, not a copy-paste of the other number. Shipped directly to production and confirmed live with a real curl against the actual domain, not assumed from the deploy succeeding.

GitHub Release v3.0.2: published, not a draft, not a prerelease, with SBOMs in both CycloneDX and SPDX format, SHA256SUMS.txt, and a real health report attached. npm: devforgekit@3.0.2, latest dist-tag, verified with a genuine fresh global install against the real registry. Homebrew: the tap repository updated with a real, curl-and-hash-verified checksum, confirmed with an actual untap/re-tap/install cycle from GitHub, not a local clone. The website: live on devforgekit.dev, every subsystem count, install command, and platform claim checked against the same commit this release shipped from.