Feature: Release Readiness Dashboard with Artifact, Changelog, and Provenance Gates

[hoangsonww]

Summary

Add a release readiness workflow that gives maintainers a single CLI and dashboard view of whether Forge is ready to ship, including verification status, changelog coverage, package metadata, Docker image checks, signed artifact provenance, and release-note evidence.

Problem / Opportunity

Forge already has a serious release posture: npm publishing, multi-arch Docker images, GHCR, signed manifests, provenance, CI gates, release docs, and a release-check skill. The current release process is still spread across commands, workflows, docs, and manual judgment. Maintainers need a repeatable way to answer:

• Is the canonical verification chain green locally?
• Is the version bump consistent across package metadata and release artifacts?
• Are changelog and docs updates present for user-facing changes?
• Will Docker and npm release outputs match the expected package contents?
• Are release signatures, checksums, and provenance material ready?
• Which release gate is blocking shipment?

A release readiness dashboard would turn the existing release discipline into an inspectable product workflow.

Proposed Feature

Build a release readiness workflow available from CLI and dashboard:

• forge release status to evaluate local release readiness.
• forge release plan VERSION to generate a release checklist from the current repository state.
• Dashboard release view showing verification, changelog, docs, package, Docker, artifact, and provenance gates.
• Gate evidence records that can be exported with release notes.
• Preflight checks for version consistency, package contents, Docker build inputs, signed manifest readiness, and npm/GHCR metadata.
• Optional integration with GitHub Actions status when credentials/network access are available.

Scope

Expected implementation areas:

• src/cli/commands/changelog.ts, src/cli/commands/update.ts, and a new or expanded release command surface.
• src/release/download.ts and src/release/verify.ts as references for artifact verification behavior.
• src/core/validation.ts or a release-specific validation module for gate execution.
• src/ui/server.ts and src/ui/public/ for dashboard gate views.
• .github/workflows/ documentation alignment without requiring live CI in unit tests.
• Docs in docs/INSTALL.md, docs/SETUP.md, docs/CLI-REFERENCE.md, and release guidance.

Acceptance Criteria

• Maintainers can run a release readiness command that reports pass/fail/warn gates without publishing anything.
• Gates include format, lint, build, tests, package metadata, version consistency, changelog presence, docs presence, package file list, Docker inputs, and provenance/signing readiness.
• Dashboard view groups release gates by category and shows the latest evidence for each gate.
• Release readiness can export a redacted Markdown or JSON report for release notes or PR review.
• GitHub Actions status integration is optional and gracefully skipped when unavailable.
• The workflow never pushes tags, publishes packages, or uploads artifacts unless a separate explicit release command is used.
• Tests cover gate evaluation, version consistency checks, export formatting, and skipped external integrations with mocks.
• Documentation explains how readiness gates map to the repository's CI and release workflows.

Non-Goals

• Automatically publishing npm or Docker releases in the first iteration.
• Replacing GitHub Actions release workflows.
• Requiring network access for local readiness checks.
• Treating warnings as failures without a configurable policy.

Dependencies / Risks

• Release checks must remain fast enough for maintainers to run locally.
• Package and Docker checks should avoid introducing flaky environment assumptions.
• The dashboard must clearly distinguish local evidence from remote CI evidence.
• Any future publish action must be heavily permission-gated and outside the initial readiness workflow.

Open Questions

• Should release readiness live under forge release, forge changelog, or a new command group?
• Should warnings be configurable per project?
• Should the first version support prerelease channels such as beta or nightly?
• Should release evidence be persisted with task/session data or stored as standalone release records?