open/ktg-plugin-marketplace
1
0
Fork 0
Code Issues Releases Activity

docs(catalog): record that the TAG-ANNOTATED acceptance is inert

Browse source 
Follow-up measurement to acdd606. The ERROR this repo carries is not an
unmade decision -- it is a made decision the checker structurally cannot see.

repo-standard's register already lists v7.7.2 under
tags_lightweight_accepted["ktg-plugin-marketplace"] (register/repos.json:231),
accepted 2026-08-14, with the rationale recorded at :211-223: monorepo-era
llm-security tag, pre-split, no install path consumes it. But
checkTagIntegrity judges the newest tag at :711 BEFORE reading the register at
:719, and applies `accepted` only to tags.slice(0, -1). The entry is therefore
inert.

Measured, not reasoned: importing repo-standard's own exported
checkTagIntegrity with its real register and `git for-each-ref refs/tags/v*`
returns exactly two findings for this repo -- [ERROR] TAG-ANNOTATED on v7.7.2,
and [OK] TAG-ANNOTATED-ACCEPTED covering the other 7 lightweight tags. No
TAG-ANNOTATED-HISTORY WARN: tag history here is fully claimed already.

That is the "we decided this" / "nobody looked" collapse the register was
built to prevent, reappearing one level up. Fix belongs in repo-standard;
reported to them and to .claude, not patched from here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FLwHvGkH2kV4XLjUHorhLu
This commit is contained in:
Kjell Tore Guttormsen 2026-08-17 13:46:06 +02:00
commit 91fc0e6195
1 changed files with 16 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

16
CLAUDE.md
View file

@ -41,6 +41,22 @@ their own Forgejo repositories under `https://git.fromaitochitta.com/open/`.
And "newest" is `compareTags` order (semver triple), so a fresh-start `v1.0.0` would NOT clear it —
a clearing tag must sort above `v7.7.2`. Non-semver tags (`config-audit/v5.0.0`,
`pre-polyrepo-archive`) parse to `[0,0,0,…]` and never rank.
**The ERROR is one the org ALREADY ACCEPTED, and the acceptance cannot land — measured 2026-08-17.**
repo-standard's register (`register/repos.json:231`) lists `v7.7.2` under
`tags_lightweight_accepted["ktg-plugin-marketplace"]`, accepted 2026-08-14 with a rationale recorded
at `:211-223`: it is a monorepo-era llm-security tag (2026-05-19, pre-split), not a catalog release;
the README install block pins no ref and all 12 `marketplace.json` refs are plugin-repo tags, so
**zero install paths consume it**. But `checkTagIntegrity` judges the newest tag at `:711` **before**
it reads the register at `:719`, and `accepted` is only ever applied to `tags.slice(0, -1)`. So the
entry for `v7.7.2` is inert: the decision is written down and the gate cannot honour it.
Run against this repo (importing repo-standard's own exported `checkTagIntegrity`, its real register,
and `git for-each-ref refs/tags/v*`), the catalog scores exactly two findings:
`[ERROR] TAG-ANNOTATED` on `v7.7.2`, and `[OK] TAG-ANNOTATED-ACCEPTED` covering the other 7
lightweight tags. **There is no `TAG-ANNOTATED-HISTORY` WARN — history is fully claimed.**
Consequence for whoever reads the next org-wide run: this repo's single ERROR is not an unmade
decision, it is a made decision the checker structurally cannot see. That is the same
"we decided this" / "nobody looked" collapse the register exists to prevent, one level up. The fix
belongs in repo-standard, not here — reported, not patched.
Note: `~/.gitconfig` sets `tag.gpgsign true`, which makes a bare `git tag <name>` **fail**
("no tag message?") rather than silently cut a lightweight one. Measured 2026-08-17, the probe's
`-a` tag came out **unsigned** all the same (0 PGP blocks) — so this config is an accident that