Files
kandev/.github
João Salavisa 52946b9159 docs: document the plugin marketplace (#1805)
* docs: document the plugin marketplace

Add a public Plugin Marketplace page covering both audiences: operators
using the in-app catalog (Browse/Installed tabs, one-click install,
Update to vX, the Sources dialog for team/corporate registries, plugin
icons, feature-flag gating, sideloading still works) and plugin authors
publishing into it (one-repo-per-plugin GitHub Release assets, the
optional manifest icon field, submitting a plugins.yaml PR to the
official catalog, GitHub-stars-only ranking, and hosting your own
index.json source).

Also cross-link the new page from plugins.md (replacing the now-false
"No plugin marketplace" security note), plugins-authoring.md, and
plugins-manifest.md (new icon field row); register it in meta.json and
coverage.json.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: correct plugin-registry CI validation claims

The registry index-build workflow does not validate plugins.yaml against
schema.json, nor does build-index.mjs compare the entry id to the
manifest id — bad entries are skipped-and-logged, and CI only fails when
a non-empty list resolves to zero built entries. Reword the submission
steps (in both the marketplace docs page and plugin-registry/README.md)
to describe what the workflow actually does: it resolves each entry
against the GitHub API and requires a correctly named
<id>-<version>.tar.gz release asset, with maintainer approval as the real
gate. Also clarify that plugins.yaml `categories` are free-form curation
tags, not the manifest's category enum.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ci: split plugin-registry Pages deploy into its own job

The single build-and-deploy job bound the `github-pages` environment at
the job level, so GitHub evaluated that environment's protection rules on
every PR run — failing the check even though the deploy steps were gated
to non-PR events. This broke every PR touching plugin-registry/**, which
is exactly what a plugin-submission PR does.

Split into a PR-safe `build` job (no environment) and a non-PR-gated
`deploy` job that owns the `github-pages` environment and runs only
`deploy-pages`. Behavior on push/schedule/workflow_call is unchanged; PRs
now run build+tests without tripping the environment gate. The star
refresh calls this workflow by file path, so the job rename is safe.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs: describe index-build asset resolution accurately

build-index.mjs picks the <id>-<version>.tar.gz release asset when
present but falls back to the release's first .tar.gz otherwise, and only
errors when a release has no .tar.gz at all — it does not hard-fail a
misnamed asset. Reword the submission steps to present the exact asset
name as an authoring instruction (so the index resolves the right asset)
rather than a builder-enforced gate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Revert "ci: split plugin-registry Pages deploy into its own job"

This reverts commit 2c5f649146.

* Reapply "ci: split plugin-registry Pages deploy into its own job"

This reverts commit 3795cdb98a.

---------

Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-19 17:44:15 +01:00
..