[Governance] Centralize product metadata and require explicit source-art review attestations

[rwang23]

[Governance] Centralize product metadata and require explicit source-art review attestations

Draft status: ready to create; not submitted by the audit run.
Priority: P2
Findings: ACT-005, ACT-024, ACT-026, ACT-027, ACT-032, ACT-034

Summary

Theme counts, mode counts, tested versions, application versions, release channel, capability claims, and rights-review state are maintained in several places. Some values have drifted, and original-track art is automatically emitted as rightsVerified: true without a separate reviewer/date/checklist record bound to the exact source hash.

中文摘要：主题数量、模式数量、版本、发布通道、平台能力和权利审核状态分散在多处，已经发生 53/68、106/136、0.1.0/0.3.2 等漂移。原创素材不能仅因归类为 original 就自动标记已审核，需要显式审核证明。

Audit evidence

• Current catalog contains 68 themes and 136 light/dark modes, while site fallbacks/copy include stale 53 and 106 values.
• scripts/prepare-desktop.mjs hard-codes a 68-theme count.
• Root package version is 0.1.0 while Theme Manager/Cargo is 0.3.2.
• The desktop release is named Beta but the workflow config uses prerelease: false.
• rightsFor() automatically sets rightsVerified: true for non-fan-art source art.
• Provenance includes strong source/prompt hashes, but there is no independent reviewer, review time, checklist, decision, and source-hash-bound attestation.
• docs/adapters.md describes a manager-created image layer that no longer exactly matches the Blob-backed body-background implementation.
• macOS physical persistence testing is documented as pending, but product entry points should make capability differences more visible.
• The repository currently has a theme proposal form, while bug/performance/accessibility templates and clearer Issue lifecycle conventions are limited.

Proposed direction

1. Create one machine-readable release/catalog metadata source for theme/mode counts, catalog revision, manager/runtime/renderer versions, release channel, and tested capabilities.
2. Generate UI copy, README badges, release names, installer metadata, and capability matrices from that source.
3. Add a source-art review attestation bound to themeId + sourceSha256, with reviewer, timestamp, checklist, decision, and notes.
4. Set rightsVerified: true only when a valid approved attestation exists; source changes invalidate approval.
5. Add docs drift tests for architecture/runtime claims.
6. Add bug, performance, accessibility, and compatibility Issue templates; keep security reports private through the security policy.

Acceptance criteria

• Theme/mode counts and tested-version copy are derived rather than hand-maintained in multiple UI/docs locations.
• Root/desktop/runtime/renderer versions and release channel have a documented ownership model and CI drift check.
• Beta/alpha GitHub Releases are marked prerelease; stable releases require the stable gate.
• Each rightsVerified: true original theme has an approved attestation containing reviewer, date, checklist, decision, and matching source SHA.
• A source-art change automatically invalidates the previous attestation.
• Fan-art remains explicitly unofficial, non-commercial, and rightsVerified: false.
• Windows/macOS capability matrices are generated into Gallery/README/Manager and distinguish build availability from physical persistence verification and signing status.
• Runtime/adapter documentation is checked against current implementation or generated snapshots.
• Bug/performance/accessibility/compatibility templates collect sanitized versions, platform, reproduction, and diagnostics; completed Issues are closed or have an explicit remaining item.

Related audit findings

ACT-005, ACT-024, ACT-026, ACT-027, ACT-032, ACT-034.

A review-attestation schema and governance PR blueprint are available in demo/governance/review-attestation.schema.json and demo/pr-blueprints/PR-10-governance-and-metadata.md in the audit bundle.

[rwang23]

Implemented in #26 and re-verified on current main (e2ed6e8). npm run metadata:check is synchronized; source-art approvals are explicit and source-hash-bound; capability/release metadata is generated from the authoritative source; and the repository now includes the relevant reporting templates.

The remaining platform caveats are disclosed by generated metadata rather than being claimed as verified. Closing this governance implementation Issue.

[rwang23]

Release preflight found a current-state governance drift that needs to be tracked before the next Beta release:

• metadata/release.json and docs/release-metadata.md declare the GitHub release as a prerelease for the Beta channel.
• .github/workflows/desktop.yml creates a draft prerelease for version tags.
• The published v0.3.2 GitHub release is currently reported by the GitHub API as isPrerelease=false.

Reopening this issue so v0.3.3 includes an action-after verification of the published release state. This observation has not changed v0.3.2 artifacts, tags, or updater availability; any correction to the historical release will be handled as a separate, deliberate action.

[rwang23]

v0.3.3 is now published as the Beta prerelease. Action-after GitHub readback confirms isDraft=false and isPrerelease=true, with tag v0.3.3 pointing to b0f5651 and the 9-asset manifest unchanged. The updater feed remains unreleased, and the physical-app recapture and platform-signing caveats remain disclosed. The release-preflight drift tracked by this reopen is resolved; closing this issue.