• v0.11.2 f08fcc9b80

    v0.11.2 Stable

    ktg released this 2026-08-14 18:19:16 +00:00 | 9 commits to main since this release

    Signed by ktg
    SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q

    Changed

    • Register: ms-ai-architect removed from locales. Four sweeps in a row
      (04–07) held a correct README-LANGUAGE WARN against 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.2 accepted 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 test prints the test count; the check
      table (20 rows) is the canonical check list.

    Fixed

    • FILE-MISSING named the class even when a TRAIT required the file.
      securitySECURITY.md read as "missing required file for class
      standalone", sending the operator looking for a requirement the class
      never listed. requirementsFor now carries the source (class vs. trait)
      alongside each required file, and the message names whichever actually
      required it. 245 tests, from 243.
    Downloads
  • v0.11.1 f422b63bb3

    v0.11.1 Stable

    ktg released this 2026-08-13 08:54:43 +00:00 | 11 commits to main since this release

    Signed by ktg
    SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q

    Fixed

    • TAGS-SIGNED, the affirmative verdict, was near-unreachable. It was gated
      on findings.length === 0, so the presence of a TAG-SIGNED-PREPOLICY OK
      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-SIGNED and TAG-SIGNED-PREPOLICY,
      3 TAG-SIGNED-NONE, still 0 ERROR and 0 WARN. 243 tests, from 241.

    Downloads
  • v0.11.0 e6cd8983ca

    v0.11.0 Stable

    ktg released this 2026-08-13 08:52:15 +00:00 | 12 commits to main since this release

    Signed by ktg
    SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q

    Added

    • 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 as TAG-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
      killed VERSION-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: 158 v* 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_from lives 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 a notRun SKIP, 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 fire ERROR. 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, a byDesign skip naming TAG-ANNOTATED as the
      owner), and a pre-policy tag was correct when it was cut
      (TAG-SIGNED-PREPOLICY, an OK — 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.

    Changed

    • The engine reads tag signature and creation date alongside the object type, in
      the same single for-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
  • v0.10.1 9f08ebc5ed

    ktg released this 2026-08-12 21:28:37 +00:00 | 13 commits to main since this release

    Patch release, because the catalog pins by tag: the SKILL.md fix in commit 009c911 reaches 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-COMMAND at 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. Writing npm test into a README because the finding mentioned it, with no scripts.test behind it, turns a WARN about 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
  • v0.10.0 e00ed3340c

    ktg released this 2026-08-12 21:21:54 +00:00 | 15 commits to main since this release

    See 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 its OK says 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-ASSETS is rejected permanently for having no subject (0 of 21 READMEs mention an asset download); TAG-SIGNED is 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 test from a clean clone.

    Downloads
  • v0.3.0 f28615f3b6

    v0.3.0 Stable

    ktg released this 2026-08-04 20:29:12 +00:00 | 39 commits to main since this release

    Added

    • 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 as checkInternalLinks.

    Fixed

    • LINK-DEAD false positive on API endpoint paths: URL_REF matched
      open/<name> anywhere in a URL, so a Forgejo API call like
      .../api/v1/orgs/open/repos read as a dead reference to a repo named
      "repos". open must now be the first path segment after the host,
      matching how every real repo URL is shaped. Measured twice against the
      catalog's own RUNBOOK.md.
    • 429 backoff was tuned for a hard IP ban that does not exist. Measured
      directly against the live forge: nginx never sends Retry-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. fetchWithRetry now
      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
      real register/repos.json — a typo in the real register would have
      drifted past them silently. Both now read the live register via
      loadRegister().
    Downloads
  • v0.2.2 f85b9d3229

    v0.2.2 Stable

    ktg released this 2026-08-04 11:12:36 +00:00 | 45 commits to main since this release

    Fixed

    • The engine never printed its own version, which is how a stale plugin cache
      went unnoticed: two repos independently proved the /repo-standard skill
      had resolved ${CLAUDE_PLUGIN_ROOT} to a cached 0.1.1 while 0.2.0 was
      installed and the catalog pinned it — same instruction, wrong engine, and
      0.1.1 has neither BADGE-COUNT nor README-LANGUAGE, so the run looked
      clean instead of incomplete. The header line and --json output now both
      carry repo-standard v<version>; SKILL.md tells 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