[JohnVargas]

tools/ has no way to say that an entry is archived, discontinued or frozen-but-fine, so today that information lives in prose where it ages quietly. This adds a status field, fills it for 55 entries, and makes the catalogue report its own coverage.

What is in here

• TOOL_STATUSES in src/lib/taxonomy.js, next to the vocabularies that were already there.
• status, statusNote, statusChecked and successor on the tools schema.
• Four checks in scripts/validate.mjs: a successor must resolve to a real slug, any status other than active needs a statusNote, any status needs a statusChecked date, and successor is only accepted with eol.
• A badge on the tool page, the note in its own block with the date it was checked, and a link when there is a successor.
• A one-line summary on /tools, computed at build time.

Nothing is deleted and no existing field changes.

Why a vocabulary and not commit dates

I measured all 151 entries first — GitHub's archived flag and the last commit on the default branch for the 116 with a repo, the effective HTTP response for the 47 with a homepage — and then went back over the 44 findings one by one with sources rather than timestamps.

That second pass is the reason this PR proposes a vocabulary. Of the 34 entries that looked stale by date, roughly 14 turned out to be mature (frozen by design, still the right tool), 11 are EOL with an identifiable successor, about 7 are genuinely stale and 2 are research artefacts that were never products. A status field encoding age would have been wrong about four out of five.

Three cases that show it:

• gr-gsm — upstream frozen since 2021 and its GNU Radio 3.10 PR closed unmerged, but Debian and Kali do not package that repo: they package bkerler's maint-3.10 fork, which builds against current GNU Radio. The tool works; the page pointed at the wrong tree.
• waving-z vs scapy-radio — both attack Z-Wave, both untouched for years, opposite fates. waving-z is ten files of C++11 and Boost talking to rtl_sdr over stdin, and G.9959 did not change. scapy-radio carries Python 2 and the GNU Radio 3.7 API. Same age, different dependency surface.
• ubertooth-one vs ubertooth-tools — the same repository, and now two different statuses. Great Scott Gadgets lists the hardware as "a retired product… no plan to manufacture more" while the software is actively developed. This is why status belongs to the page and not to the repo; chip-tool and connectedhomeip have the same shape, as do killerbee and zbdsniff.

Two ways a repo looks more alive than it is

Worth writing down, because anything automated here will hit both:

• pushed_at counts pushes to any branch. scapy-radio is seven years away from its default-branch commit, mfcuk six, openbts 41 months, falcon 35, gr-gsm 46.
• The last commit can be a licence file. rtl-zwave's 2023 commit is "Create LICENSE.md" — the last code change is from 2015. mfdread's 2024 commit is "Create LICENSE"; its code is from 2020.

The part that is not a judgement call

Six entries pointed at an archived repository, and three of them did not say so: universal-radio-hacker (12,579★), crocodilehunter — whose README says EFF no longer maintains it and does not recommend it for new projects — and python-matter-server, whose README names 8.1.2 as the final release. The other three already said it in prose, which is the argument in miniature: this project is already tracking lifecycle by hand, so half of it goes stale unnoticed.

universal-radio-hacker also shows the label has consequences: it froze in a good state (v2.10.0 still installs from PyPI) but Homebrew marked it deprecated with reason repo_archived and a disable date of 2027-07-17.

Three wording corrections that come with it

• gr-zwave_poore said "a maintained GNU Radio block path". Its repo keeps a branch per GNU Radio version, so the reading was reasonable, but the last code commit is 2022-08-26. It is still functional because FISSURE vendors and builds it — which is what the statusNote now says.
• adsb-out said "Stable but inactive". Stable is true of the code and false of the experience: it is Python 2 and python3 -m py_compile fails on line 401, so it does not start on a current distribution.
• mdek1001 said Qorvo points new designs at the QM33 series. PCN 25-0154 declares no alternate part; the single-board DWM1001-DEV is still available, which is what the page says now. The PCN does confirm the page's dates.

Coverage

/tools now renders, at build time:

151 entries — active 6 · 4% | mature 17 · 11% | archived 3 · 2% | research 3 · 2% | eol 18 · 12% | stale 7 · 5% | 97 not assessed (64%)

status is optional on purpose. Defaulting to active would have asserted that 97 unreviewed entries are current; leaving it unset says plainly that nobody has looked, and makes the gap something a contributor can pick up.

Scope

The 55 values are a starting point, not a verdict. The call between mature, archived and stale is a judgement I would rather you made than I did — tell me where you disagree and I will change them. Related pages already open as separate PRs: #10, #12 and #13. I can post the full 151-row table with dates, HTTP codes and sources if that helps review.