-
v0.11.2 Stable
released this
2026-08-14 18:19:16 +00:00 | 9 commits to main since this releaseChanged
- Register:
ms-ai-architectremoved fromlocales. Four sweeps in a row
(04–07) held a correctREADME-LANGUAGEWARNagainst an entry that was
itself wrong: the repo's published README disavows a Norway-only audience in
its own words ("useful for any enterprise context", line 17, verified against
the forge), and its 24 Norway markers are traits — what the code does — not
audience. The register was the wrong side; the prose stands. Decided on
org-ops' measured case (their D35). - Register:
ktg-plugin-marketplace v7.7.2accepted as lightweight
history. Previously deliberately absent because the newest tag has the one
safe remedy. The catalog's measured counter: v7.7.2 is a monorepo-era
llm-security tag (2026-05-19, pre-split), not a catalog release, and zero
install paths consume it — force-moving a published ref for no consumer costs
more than the finding. The catalog committed to annotating every future tag,
which the check itself enforces. - README: the two prose counts that had gone stale are now count-free.
"170 tests" (actual: 245) and "twelve checks" survived two releases
unchanged — the ungated copy of a number is the defect, so the copies are
removed rather than corrected.npm testprints the test count; the check
table (20 rows) is the canonical check list.
Fixed
FILE-MISSINGnamed the class even when a TRAIT required the file.
security→SECURITY.mdread as "missing required file for class
standalone", sending the operator looking for a requirement the class
never listed.requirementsFornow carries the source (classvs.trait)
alongside each required file, and the message names whichever actually
required it. 245 tests, from 243.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Register:
-
v0.11.1 Stable
released this
2026-08-13 08:54:43 +00:00 | 11 commits to main since this releaseFixed
-
TAGS-SIGNED, the affirmative verdict, was near-unreachable. It was gated
onfindings.length === 0, so the presence of aTAG-SIGNED-PREPOLICYOK
suppressed it — and every repo in the org has pre-policy tags. Caught by
dogfooding the v0.11.0 release: this repo signed the first tag the check ever
judged, and the gate did not say so.The status was green either way, which is what made it worth fixing rather
than shrugging at: a reader could not tell this repo signed its new tag from
this repo has cut no tag since the policy. Two different facts wearing one
silence — the same defect as an exemption nobody can see, which this engine
already refuses to ship one check over. The gate now keys the affirmative on
the JUDGED findings only, and the two cases carry different sentences.Measured after: 18 repos emit both
TAGS-SIGNEDandTAG-SIGNED-PREPOLICY,
3TAG-SIGNED-NONE, still 0 ERROR and 0 WARN. 243 tests, from 241.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
-
v0.11.0 Stable
released this
2026-08-13 08:52:15 +00:00 | 12 commits to main since this releaseAdded
-
TAG-SIGNED— a release tag that names a signer, not just whoever could
write to the forge. The catalog pins plugins by tag, so this sits on the
same supply-chain axis asTAG-ANNOTATED: annotation makes a tag
immovable-without-a-trace, a signature makes it attributable.The check had been parked for a release as "blocked on an operator decision",
on the strength of 0 of 18 repos signing. That zero was never evidence against
it — it is what a practice nobody has adopted yet looks like, and reasoning
from it makes the gate ratify the status quo it exists to move. The rule that
settled it (operator, 2026-08-13) asks something else entirely: would a public
AAA+ repository do this? Yes. Unlike the two legitimate conventions that
killedVERSION-DRIFT, there is no second convention under which release tags
are better left unattributable.The policy is a DATE, and the date is what made the check shippable.
Measured across 20 clones before the rule was locked: 158v*tags, 144
annotated, 14 lightweight, 0 signed, and not one tag dated after 2026-08-12. A
boolean "this org signs" would have failed 20 correct repositories the day it
landed, with force-moving 144 published refs as its only remedy — the mechanism
that gets gates switched off.tags_signed_fromlives in the register, never
in the engine (the rule that keeps the org-profile exemption a flag rather than
a class name in a classifier); absent it, the check is anotRunSKIP, because
the gate never assumes a policy nobody recorded.Verified both directions: a sweep of 21 repos yields 18
TAG-SIGNED-PREPOLICY- 3
TAG-SIGNED-NONE, 0 ERROR, 0 WARN — then, against real git objects, an
unsigned post-policy newest tag does fireERROR. A sweep returning zero
proves nothing alone; a dead check returns zero too.
Two exclusions keep one defect from being counted twice under two codes: a
lightweight tag has no tag object to carry a signature at all
(TAG-SIGNED-LIGHTWEIGHT, abyDesignskip namingTAG-ANNOTATEDas the
owner), and a pre-policy tag was correct when it was cut
(TAG-SIGNED-PREPOLICY, anOK— said out loud, never as silence).It answers is this tag signed and never does the forge vouch for it: the
signature is read from the clone, while the forge's "Verified" badge needs a
key registered there. - 3
Changed
- The engine reads tag signature and creation date alongside the object type, in
the same singlefor-each-ref. The signature is read with
%(if)%(contents:signature)%(then)…rather than by printing the block, which
is multi-line and would break the line-oriented parser on exactly the tags the
check cares about. No new API call — this stays at three. - 241 tests, from 230.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
-
released this
2026-08-12 21:28:37 +00:00 | 13 commits to main since this releasePatch release, because the catalog pins by tag: the SKILL.md fix in commit
009c911reaches no installed reader until a tag carries it.0.10.0 canonized "a new check is not shipped until its row exists" and shipped with the skill still saying "the two network calls" — after the third had been added — and with no mention of
VERIFY-COMMANDat all. The invariant was violated one file over, in the same release that wrote it.The skill now also names the trap in fixing a
VERIFY-MISSING: document the command that already exists, after running it. Writingnpm testinto a README because the finding mentioned it, with noscripts.testbehind it, turns aWARNabout missing documentation into a false claim on the first screen — a worse defect than the one being fixed, and one this gate can never catch, because it runs nothing.No engine change. 230 tests.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
Source code (ZIP)
-
v0.10.0 — VERIFY-COMMAND Stable
released this
2026-08-12 21:21:54 +00:00 | 15 commits to main since this releaseSee CHANGELOG.md for the full entry.
VERIFY-COMMAND— a repository with something runnable and no command in its README to run it. This org publishes no CI badge (the forge has no Actions runners registered), so that one command from a clean clone is the only evidence a stranger gets. The subject is measured, never read off a class; the check runs nothing, so itsOKsays documented, never passing. Measured across all 21 registered clones: 10 document a command, 6 do not, 5 have nothing runnable at all.- Not built, with distinct reasons:
RELEASE-ASSETSis rejected permanently for having no subject (0 of 21 READMEs mention an asset download);TAG-SIGNEDis blocked on an operator decision, which is not the same as rejected. - This repository's own README had drifted behind its engine: four checks with no row in the check table, and a stale "two network calls" after the third had been added.
230 tests.
npm testfrom a clean clone.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
v0.3.0 Stable
released this
2026-08-04 20:29:12 +00:00 | 39 commits to main since this releaseAdded
BADGE-DEAD-LINK: a linked badge making a run claim ("tests", "build",
"CI", "passing") is now resolved against the repo's tracked files when the
link target is relative. Being wrapped in a link previously ended all
scrutiny — the link-target capture group was missing from the regex
outright, so a badge linked to a dead relative path passed silently.
External targets (the ordinary case — a CI provider) still need the
network and stay out of scope, same precedent ascheckInternalLinks.
Fixed
LINK-DEADfalse positive on API endpoint paths:URL_REFmatched
open/<name>anywhere in a URL, so a Forgejo API call like
.../api/v1/orgs/open/reposread as a dead reference to a repo named
"repos".openmust now be the first path segment after the host,
matching how every real repo URL is shaped. Measured twice against the
catalog's ownRUNBOOK.md.- 429 backoff was tuned for a hard IP ban that does not exist. Measured
directly against the live forge: nginx never sendsRetry-After(the
branch handling it is dead code in practice), the limit is a leaky bucket
that can take up to ~15s to drain, and it is IP-based rather than
token-quota-based — a valid token made no difference.fetchWithRetrynow
defaults to a 23s worst-case budget (retries: 5,maxDelayMs: 8000), up
from 7s.CLAUDE.md's "13 calls in a loop" explanation corrected to match. - Two tests asserted facts about their own local test fixture instead of the
realregister/repos.json— a typo in the real register would have
drifted past them silently. Both now read the live register via
loadRegister().
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
v0.2.2 Stable
released this
2026-08-04 11:12:36 +00:00 | 45 commits to main since this releaseFixed
- The engine never printed its own version, which is how a stale plugin cache
went unnoticed: two repos independently proved the/repo-standardskill
had resolved${CLAUDE_PLUGIN_ROOT}to a cached0.1.1while0.2.0was
installed and the catalog pinned it — same instruction, wrong engine, and
0.1.1has neitherBADGE-COUNTnorREADME-LANGUAGE, so the run looked
clean instead of incomplete. The header line and--jsonoutput now both
carryrepo-standard v<version>;SKILL.mdtells the reader to confirm it
against the catalog pin before trusting a green result. The cache
resolution itself is the harness's, not this repo's, and is not fixed here.
Downloads
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
- The engine never printed its own version, which is how a stale plugin cache