# Stage 9: Harzva Plugin Registry

Stage 9 creates a controlled first-party registry for Harzva-maintained DSH
plugins. The recommended repository name is `Harzva/dsh-plugin-registry`.
Use `dsh-plugin-store` only for a later user interface; use `dsh-plugin-market`
only if the project eventually becomes a full multi-publisher marketplace.
`themes` is a content category, not the name of the authoritative registry.

## Why a separate repository

`dsh-control-plane` manages Runtime, Profile, Preset, Session, plan, and
knowledge-reference projections. It should not own the release index for every
plugin. A separate registry gives plugin publication, governance, review, and
rollback their own history while the control plane can consume a read-only
reference later.

The ecosystem already includes community discovery and storefront projects:
`awesome-dsh-plugin`, `dsh-market`, `dsh-marketplace`, `dsh-subscribe`,
`dsh.pub`, and `dsh.directory`. The Harzva registry should not compete by
copying their full catalog. It should be the authoritative source for
Harzva-maintained plugins and clearly label third-party entries as references.

## Public-safe registry contract

Each plugin has one public record under `registry/plugins/<plugin-id>.json`:

- stable ID, display name, owner, repository, and license;
- supported DSH versions and Bundle contract version;
- immutable source commit and public Release/tarball URL;
- category, capabilities, declared permissions, and required adapters;
- review status, review date, evidence links, and maintainer decision;
- enabled, deprecated, withdrawn, and rollback metadata.

The registry must never contain API keys, cookies, `.env` values, local paths,
real `DSH_HOME` values, raw chats, real Sessions, private knowledge, or source
archives copied from private machines. It publishes metadata and public release
references, not a secret-bearing install service.

## Delivery phases

1. **Schema and governance:** create the repository, JSON Schema, contribution
   policy, publisher ownership rules, review states, and generated index.
2. **First-party entries:** add `dsh-control-plane` and later Harzva plugins
   only after public-safe scans, isolated DSH checks, and DeepSeek Pro review.
3. **CI and distribution:** validate manifests, public URLs, source pins,
   release assets, licenses, compatibility, and generated indexes; publish a
   static GitHub Pages/API-compatible index.
4. **Optional Store UI:** build a read-only DSH/Web interface or use a separate
   `dsh-plugin-store` repository that consumes the registry without becoming a
   second source of truth.
5. **Control-plane integration:** add a reference-only registry provider to
   `dsh-control-plane`; installation still requires explicit user approval and
   an allowlisted adapter path.

## Exit criteria

- the registry repository is public-safe and independently versioned;
- CI rejects malformed records, unpinned sources, missing licenses, broken
  Release assets, private-path leakage, and unsupported DSH contracts;
- every first-party entry has a sanitized Review Pack and a reversible
  withdrawal/rollback path;
- generated indexes are deterministic;
- `dsh-control-plane` consumes metadata read-only and does not copy private
  runtime state.

Status: the first public registry skeleton is delivered at
`https://github.com/Harzva/dsh-plugin-registry` with one verified first-party
record. Multi-plugin governance, publisher workflows, and the optional Store UI
remain planned.