Add Releases Index (release notes registry + MCP)

[zachdunn]

Summary

Adds Releases Index (releases.sh) under Community Plugins → Development & Workflow.

Open release-notes registry with MCP and CLI so agents can search and fetch product changelogs.

Related: buildinternet/uploads#989

[github-actions]

✅ Contribution check passed. @zachdunn, catalog validation succeeded.

scan findings

HOL centralized scan reported findings or did not pass: failure. This is advisory and does not block listing.

Recommended: add scanner CI for security

This listing can merge without it. HOL still scans buildinternet/releases independently.

We recommend including hashgraph-online/ai-plugin-scanner-action under .github/workflows/ on push and pull_request. Continuous scanning keeps this catalog safer for MCP servers, skills, plugins, and other agent extensions people install from HOL.

Adding it:

• protects the ecosystem by catching secrets, dangerous hooks, and supply-chain issues before they ship;
• keeps the listing at the full trust score (without maintainer CI it stays eligible, with a 10% trust-score reduction);
• can surface findings in GitHub code scanning.

See CONTRIBUTING.md and SCANNER_GUIDE.md.

HOL's centralized scan reported findings. This does not block listing.

View the latest sweep.

[kantorcodes]

The centralized scan is 71/100, below the required 80, with 76 high, 1 medium, and 2 low findings. The README also begins with an extraneous downloaded-file SHA line; remove that line, remediate or document the rule-level findings, add the pinned scanner workflow for reproducible source-side results, rerun the scans, and request review once the score reaches at least 80; this PR remains unmerged.

[zachdunn]

Thanks for the review. Local plugin-scanner scan on buildinternet/releases matches your ~71–76 score band: mostly “high” findings that aren’t real issues for this monorepo.

1. Hardcoded secret — nearly all hits are test fixtures, planning docs with placeholder keys, and CI that derives a publish key via openssl at runtime (nothing secret committed). Without an exemption path for tests/docs, this isn’t a workable ≥80 gate on a product repo.
2. Dynamic code execution — largely false positives on our tests/evals/*.eval.ts harness files (filename/string matches on “eval”), plus noise in a generated MCP UI bundle. Not something we’re going to “fix” by deleting eval harnesses.

We’re fine adding a root SECURITY.md and keeping this PR README-only so your workflow regenerates marketplace artifacts.

We won’t add the scanner Action as permanent CI on this monorepo. If listing requires ≥80 with no highs under the current rules, we may close rather than chase false positives — unless you can scope the scan to the plugin package or provide exemptions for tests/docs/generated bundles.

[kantorcodes]

The latest head now contains only the intended README entry, but the centralized scan is 71/100, below the required 80, with 76 high, 1 medium, and 2 low findings. Please remediate or document the rule-level findings, rerun the source and catalog scans, and request review once the score reaches at least 80; the pinned source scanner workflow is recommended because scanner CI is not detected, but it is not a merge prerequisite.

[kantorcodes]

Centralized HOL scan is 71/100, below the 80 merge threshold, with 77 high, 1 medium, and 2 low findings. Fix the hardcoded-secret and eval/Function findings, Claude marketplace structure, and missing Dependabot coverage. The source has no HOL scanner workflow, so add the SHA-pinned workflow from SCANNER_GUIDE.md, run the same pinned scanner in source CI, link that run, then rerun the catalog scan.