Build a deterministic multi-host release and registry publication pipeline

[huiyu]

Context

DevMuse has one canonical workflow source in plugin/skills plus host adapters for Claude Code, Codex, Gemini CLI, Hermes Agent, and OpenClaw compatibility. The repository currently has adapter build and validation scripts but no GitHub Actions release pipeline.

Some Git-source installs still fetch development docs and tests. Runtime-only archives help, but archives are outputs of the release system rather than the goal.

Goal

Build one deterministic, auditable pipeline that validates, packages, tests, releases, and publishes every supported host distribution from the canonical source.

Pipeline

1. Pull request validation

• Build all generated adapters from plugin/skills.
• Fail when regeneration produces an uncommitted diff.
• Verify version and manifest consistency.
• Run the cross-platform contract, host validators, skill validators, and deterministic hook tests.
• Never publish from a pull request.

2. Release candidate and tag

• Support a non-publishing workflow_dispatch dry run.
• On a version tag, build runtime-only artifacts for Claude, Codex, Gemini, and Hermes.
• Exercise OpenClaw compatibility against the applicable bundle instead of inventing a duplicate runtime.
• Produce deterministic archives with checksums and build provenance.
• Run install, update, and uninstall smoke tests on macOS, Linux, and Windows where the host supports those platforms.

3. Publication

• Create the GitHub Release only after build and validation succeed.
• Publish each supported registry through an isolated downstream job with its own credentials and environment approval.
• Make retries idempotent and prevent one registry failure from corrupting another publication.
• Where a marketplace has no publishing API, generate a ready-to-submit artifact and checklist for manual review.

Constraints

• plugin/skills remains the source of truth.
• Runtime artifacts exclude repository docs and tests unless a file is an actual runtime dependency.
• Registry jobs cannot bypass host validators or weaken host-native policy.
• Publishing credentials remain isolated from pull request jobs.
• Packaging logic is testable locally and is not embedded only in workflow YAML.
• npm remains a distribution option until registry coverage makes a separate decision possible.

Acceptance criteria

• The same version tag produces equivalent file manifests and checksums from a clean checkout.
• A generated-adapter drift, validator failure, or smoke-test failure blocks release publication.
• A dry run exercises the complete build and test graph without external publication.
• A successful tag creates a GitHub Release and invokes only the configured registry jobs.
• Re-running a partially failed publication is safe and does not duplicate versions.
• Installation documentation points users to the smallest supported distribution path for each host.

Suggested workstreams

1. CI and generated-diff enforcement.
2. Local deterministic packaging command.
3. Cross-OS installation smoke-test matrix.
4. Tag-to-GitHub-Release workflow.
5. Per-registry publishing jobs and manual submission packets.
6. Checksums, provenance, and release documentation.
7. Follow-up decision on npm distribution.

[huiyu]

Phase 1 landed on feature/guidance-over-enforcement in f4afe66: read-only PR CI builds adapters, rejects tracked or untracked generated drift, validates manifests/host contracts/skills/routing/hooks/Mermaid, and never publishes. Keeping this issue open for deterministic packaging, cross-OS install smoke tests, tag/release, provenance, and registry publication workstreams.