The stat-badge gate skips any axis the plugin does not badge, so those numbers are structurally unverifiable and rot in silence. Hand-audited every remaining one against ground truth extracted from the pinned tag (git archive <ref>, never the sibling working tree). 12 of 13 measured exact. The one defect: voyage's `500+ tests`, which is 832 at v5.9.1 — true as a lower bound, so the gate could never have seen it, but a 40% understatement to a reader comparing plugin blocks. Also corrects CLAUDE.md's own worked example: `1441 tests` was the number the ref-defect produced by reading config-audit's working tree; 1398 is what v5.13.0 installs. Records the two counting rules calibrated against the badged plugins — hooks = hook command entries (events and matchers both diverge from the badge), tests = `ℹ tests` and not `ℹ pass`. Gate: 11 OK / 0 WARN / 0 ERROR. Tests 120/120. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D6Sy2bjLWXjh59g1WsAe4X
5.2 KiB
5.2 KiB
ktg-plugin-marketplace (catalog)
Catalog repository for the ktg-plugin-marketplace. After the polyrepo migration this repo hosts only
the marketplace manifest and the catalog-level docs; every plugin and the shared design-system live in
their own Forgejo repositories under https://git.fromaitochitta.com/open/.
What lives here
.claude-plugin/marketplace.json— the marketplace manifest (plugin entries point at external repos)README.md— the landing/catalog pageCONVENTIONS.md— marketplace-wide conventions inherited by every plugin repoGOVERNANCE.md— governance + fork-and-own model.mailmap,.gitleaks.toml,.gitleaksignore— shared git-hygiene baselines
Catalog maintenance
- Marketplace conventions: see CONVENTIONS.md.
- Adding/updating a plugin entry: edit
.claude-plugin/marketplace.json(externalsource: "url"with a pinnedref) and re-state the plugin in README.md with its verified version. - Plugin source, issues, and releases live in each plugin's own repository — not here.
- Releasing a plugin (canonical path —
scripts/release-plugin.mjs): since the polyrepo split, a release is a TWO-repo act — tag the plugin repo AND bump the catalogref. Forgetting the second step strands users on the old version (the exact drift this helper exists to prevent). Runnode scripts/release-plugin.mjs <plugin> [--version X.Y.Z]— dry-run by default; it REFUSES unlessplugin.json== README badge == the target version AND thevX.Y.Ztag exists, then prints the planned bump. Apply with--write [--commit] [--push];--create-tagmints+pushes a missing plugin tag first. On--writeit bumps the catalogrefAND the catalog README's per-plugin`vX.Y.Z`label together (andgit adds both on--commit). Because it only moves both to a verified, tagged, consistent version,check-versions.mjsis green by construction. Never hand-edit arefor a README label for a release — use this. Pure planner + label reconciler covered byscripts/release-plugin.test.mjs. - Version-consistency gate: run
node scripts/check-versions.mjsbefore committing anyrefchange. For each plugin it checks (against the sibling repo) that the catalogrefresolves to a real git tag (ERROR if dangling — breaks install), thatplugin.jsonversion == README version-badge (ERROR), that the catalog README's per-plugin`vX.Y.Z`label == the catalogref(ERROR — the human-facing doc must not misstate the installed version), and that the catalogrefmatchesplugin.jsonversion (WARN — catalog lags or an unreleased bump). Exit 1 on any ERROR;--strictalso fails on WARN. Pure-function core covered byscripts/check-versions.test.mjs(node --test scripts/check-versions.test.mjs). - Stat-badge mirroring (part of the same gate): each plugin block in the catalog README ends in a
stat line (
7 agents · 16 scanners · 21 commands · 1398 tests · [Full documentation →]). The gate compares every number on that line against the plugin's own shields badge for the same axis, and ERRORs when they disagree — the catalog must not overstate a plugin. The rule is per-AXIS, not per-plugin: an axis the plugin does not badge is skipped silently, so there is no exception list to maintain. Measured 2026-08-02: 24 axis-pairs badge-covered · 15 axes badge-less across 7 of the 11 plugins and therefore ungated. All 15 have now been hand-audited at their pinned tags — 14 were exact; the two defects found were repo-mailbox (6 CLI scripts/251 selftest checksagainst a true 8 / 370) and voyage (500+ testsagainst a measured 832).N+in the catalog is read as a lower bound, not an equality, so500+was never gate-visible — ungated axes rot in silence and need a periodic re-run of this pass. Never hand-edit a stat line to silence the gate — the plugin's badge is the source for every stat number; fix the catalog to match it. - Counting rules for a badge-less axis (calibrated against the badged plugins, 2026-08-02). When
the catalog must count an axis itself, count it the way the badges do, or the numbers stop being
comparable across plugin blocks: hooks = hook COMMAND entries in
hooks/hooks.json(not events, not matchers — the three diverge, andcommandsis what matched the badge on all 6 badged plugins), and tests =ℹ testsfromnode --test, notℹ pass(config-audit's badge 1398 is itstestscount;passwas 1375). Measure in an extraction of the tag (git archive <ref> | tar -x -C <tmp>), never the sibling working tree. - The stat mirror reads the plugin README AT THE PINNED
ref, never the sibling working tree. The catalog documents what installs, and that is the tag. A plugin that commits past its tag without bumping its version — measured 2026-08-02 on both llm-security (scanners 23→22, tests 2013→2034) and config-audit (tests 1398→1441) — would otherwise make the gate demand that the catalog restate unreleased numbers, which is exactly backwards. When the gate flags a stat, checkgit show <ref>:README.mdin the plugin repo before believing the working tree.