Skip to content

Release governance: define canonical product metadata and make documentation drift fail CI #381

Description

@AminChirazi

Parent

Split from #377.

Why this is human-owned

The docs-only child of #377 can correct today’s stale prose, but it cannot decide which source owns FlowProof’s release version and maturity language or modify the checks that govern future pull requests.

This issue requires a maintainer to choose that policy and wire it into CI. Changes under .github/workflows/**, scripts/gate/**, scripts/loop/**, CLAUDE.md, or CHARTER.md are constitution-protected and must be human-authored. Keep needs-human until the policy and protected-path work have landed.

Scope

Define one repository-owned contract covering:

  • the current package/workspace version;
  • the current maturity designation;
  • the maintained package description and supported installation paths;
  • which files are authoritative and which are generated or checked consumers.

Extend the existing versions agree protection instead of introducing a competing source of truth. Begin after the docs-only child has corrected the current stale statements; do not duplicate those prose edits here.

Acceptance criteria

  • Record a maintainer-approved contract naming the canonical source for version, maturity, package description, and supported installation paths.
  • Preserve Cargo.toml as the version source used by versions agree, unless a maintainer explicitly approves an atomic migration of every consumer.
  • Add a deterministic checker with tests that rejects stale current versions, obsolete maturity labels, and known placeholder or future-tense package descriptions.
  • Explicitly exempt historical material such as CHANGELOG.md, release notes, test fixtures, and version-bearing examples.
  • Ensure sdk/python/pyproject.toml and sdk/js/package.json descriptions either derive from the approved source or are compared against it exactly.
  • Run the checker in pull-request CI through a human-authored protected-workflow change.
  • Include a deliberately stale fixture proving the check exits non-zero.
  • Keep the checker read-only; CI reports drift and never rewrites documentation.
  • Document how a release owner intentionally changes maturity or positioning without weakening the check.

Out of scope

  • Correcting current prose in sdk/python/README.md, CONTRIBUTING.md, README, or package documentation; that belongs to the docs-only child.
  • Registry installation tests, platform matrices, release dispatch, registry propagation, or website updates.
  • Editing historical changelog entries to satisfy a current-state check.

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-humanA loop escalated this: it needs a decision or a protected-path change

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions