Distribution

Current (API 1.0)

• Local file install in the Plugin Manager.
• .shiremod stored ZIP, manifest at the root, package SHA-256 shown and stored in the registry.
• Per-plugin directory, storage, logs and registry entry.
• Enable/disable, reload and remove.
• Permission approval and revocation.
• The Host never executes a package automatically on install; the user must enable it and approve capabilities.

Package identity

• id is the stable identity; version is the release label.
• The install records the SHA-256 of the whole package.
• An update to the same id replaces files and keeps approvals that are still declared.
• A package cannot choose its own storage path or escape the plugin directory.

Roadmap

The following are designed but not implemented in 1.0:

• A searchable catalogue and author pages.
• Install by URL with SHA-256 and optional signature verification.
• Version history and update channels.
• Dependency resolution and conflict reports.
• Reputation, reports and revocation lists.
• Automatic update opt-in.

Digital signatures will authenticate the origin of a package. They do not replace process isolation or per-call permission checks, and a signed package is still untrusted behavior until the user reviews it.

Publishing checklist

1. shire-plugin validate <dir> passes.
2. shire-plugin build <dir> passes for compiled languages.
3. shire-plugin test <dir> connects to the mock Host.
4. shire-plugin pack <dir> prints the SHA-256.
5. Install the package in a clean Shire profile, approve permissions and verify the UI/events.
6. Keep secrets out of the package, manifest, SDK files and logs.
7. Include a README and the exact supported Shire/API version.