Kjell Tore Guttormsen
9b1838f1d7
The polyrepo split made a plugin release a TWO-repo act: tag the plugin repo AND bump the catalog `ref`. The second step is manual and easily forgotten — that drift just stranded linkedin-studio on v0.4.0 while its plugin.json moved to 0.5.0. This adds the canonical release path that makes the catalog side impossible to do wrong. scripts/release-plugin.mjs: - Pure planner planRelease() — given the catalog + observed plugin state + target version, computes verdict (READY/NOOP/BLOCKED), the bumped marketplace object, and the commit subject. REFUSES (BLOCKED) unless plugin.json == README badge == target AND the vX.Y.Z tag exists, so a READY plan is check-versions- green by construction. Reuses normalizeVersion/classifyPlugin from check-versions.mjs (no duplicated rules). - I/O shell: dry-run by default; --write bumps the ref + re-runs the gate; --commit/--push apply; --create-tag mints+pushes a missing plugin tag first. - 10/10 unit tests (scripts/release-plugin.test.mjs); check-versions 9/9 still green. - Dogfooded: linkedin-studio → NOOP (already pinned v0.5.0); ms-ai-architect → BLOCKED (v1.16.0 in plugin.json was never tagged — refuses to publish it). Also: fix the stale LinkedIn Studio README label v0.4.0 -> v0.5.0 (loose end of the v0.5.0 release), and document the canonical release path in CLAUDE.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
35 lines
2.4 KiB
Markdown
35 lines
2.4 KiB
Markdown
# 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 page
|
|
- `CONVENTIONS.md` — marketplace-wide conventions inherited by every plugin repo
|
|
- `GOVERNANCE.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` (external `source: "url"` with
|
|
a pinned `ref`) 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 catalog `ref`. Forgetting the second
|
|
step strands users on the old version (the exact drift this helper exists to prevent). Run
|
|
`node scripts/release-plugin.mjs <plugin> [--version X.Y.Z]` — dry-run by default; it REFUSES unless
|
|
`plugin.json` == README badge == the target version AND the `vX.Y.Z` tag exists, then prints the
|
|
planned bump. Apply with `--write [--commit] [--push]`; `--create-tag` mints+pushes a missing plugin
|
|
tag first. Because it only moves the `ref` to a verified, tagged, consistent version,
|
|
`check-versions.mjs` is green by construction. Never hand-edit a `ref` for a release — use this.
|
|
Pure planner covered by `scripts/release-plugin.test.mjs`.
|
|
- **Version-consistency gate:** run `node scripts/check-versions.mjs` before committing any `ref`
|
|
change. For each plugin it checks (against the sibling repo) that the catalog `ref` resolves to a
|
|
real git tag (ERROR if dangling — breaks install), that `plugin.json` version == README
|
|
version-badge (ERROR), and that the catalog `ref` matches `plugin.json` version (WARN — catalog
|
|
lags or an unreleased bump). Exit 1 on any ERROR; `--strict` also fails on WARN. Pure-function
|
|
core covered by `scripts/check-versions.test.mjs` (`node --test scripts/check-versions.test.mjs`).
|