ci: adopt canonical product versioning

[pcvantol]

Canonical product versioning

Canonical source: product-version.json (forge-platform, schema 1), baseline 2.3.0 (not publication evidence). This PR validates strict manifest identity and stable SemVer, supports explicit patch/minor or exact-version application with stale-baseline protection, and writes the single source atomically.

The prior self-pushing workflow was removed: it could create an unqualified bot SHA and did not supply durable exactly-once/event provenance. CI is read-only. Engineering Platform #105 is the pending source-level bounded version-preparation adapter: it verifies declared helper identity, an isolated allowlisted candidate and exact-head qualification evidence. It is not an installed writer, active authorization grant, merge authority, artifact publication or universal-installer readiness.

No build/release publication, runtime, grant or merge occurs here. Remaining: install/authorize the bounded delivery route where separately approved, then qualify its resulting final head through the repository's real gates.

Bootstrap release cadence V2

BOOTSTRAP_RELEASE_CADENCE_V2: nieuwe operations gebruiken forge-platform-bootstrap-release-cadence-v2; PATCH is de incrementdefault, docs-only is NO_BUMP en dezelfde operation-ID kan niet stil naar een andere class veranderen. Main merge, repair en requalification alloceren niet opnieuw.

[pcvantol]

Automated cross-product SemVer/design review of exact head dee34d2685037ae8621ef878c19626fcc9723625. Related pins: Forge #49 a0602ba702fcf0ec3807599526257c410084b02f, Workspace #14 fcda180e7e6323c54b54e5b3186ef0056514d52e, EP #100 b385d29886d625cf6d6cabaaa268abb0d68312a8. Source review plus isolated helper reproductions; not a full checkout/host qualification, human security approval, or authorization to publish/merge/deploy. No source, host or grant changes performed.

Verdict: retain one canonical version per product, but do not enable the proposed automation as qualified yet. The user's deliberately requested branch-event policy is understood; the issues below concern its safety, actual implementation and the distinction from semantic compatibility.

SV1 — Claimed common source/projection contract differs from implementation. EP reads [project].version from pyproject.toml; these three product PRs introduce product-version.json and validate only that document. Different formats per product are fine if the policy explicitly declares each owner/source and treats package/UI/runtime values as derived projections. They do not yet prove a cross-surface installed-product version check. This document says every product starts at 0.1.0, while the manifests are 2.3.0; reconcile the documented approved baseline, do not automatically downgrade or imply historical release qualification. Matching initial numbers across products do not imply lockstep release or compatibility.

SV2 — Branch-event counting is not sufficient SemVer policy. Automatically patching any feature branch and incrementing minor on every main push does not classify public-API compatibility. It can be an internal numbering policy, but stable published releases must separately enforce compatible fix/addition versus incompatible change and immutable released package content. Define product public compatibility guarantees and the explicit major-release decision boundary. Independent branches can all carry the same proposed 2.3.1; that is only safe if these are unpublished candidates and unique build/source/artifact identities prevent stable-release ambiguity. No requirement to build a full release platform in this PR; define and enforce what this foundation does and does not qualify.

SV3 — New bot SHA is not automatically qualified. The workflow uses checkout's default GITHUB_TOKEN, changes the branch/main, and pushes a new commit after validating only its local manifest. GitHub's current documented behavior suppresses push-triggered runs from GITHUB_TOKEN events; qualifying PR events can require manual workflow approval. There is no explicit final-head qualification/handoff in this workflow. Therefore the old head's CI/reviewer/authorization evidence must not qualify the bot-created head. For EP this also invalidates a SHA-pinned quality review after it has run. Prefer generating the version change before final candidate qualification, or explicitly qualify the resulting pinned head via an authorized mechanism without adding an owner-relay loop. Do not solve this by weakening protections or granting blanket admin tokens. Official reference: https://docs.github.com/en/actions/concepts/security/github_token .

SV4 — Per-ref concurrency does not provide exactly-once semantics or exclude other writers. Jobs start from their event checkout, while users/EP can push newer commits without participating in this concurrency group. A stale bot push can correctly fail non-fast-forward, but there is no reconciliation to deliver the promised event semantics. Default concurrency retains only one pending run, so intermediate events may be replaced even with cancel-in-progress:false. The subject-only git log origin/main..HEAD marker neither authenticates the bot nor binds the bump to a branch/event/base/version. An ordinary matching commit title or inherited marker from another branch can suppress a needed bump. Main reruns have no durable event-id check. Define whether the policy is per merge/delivery/event or latest main, use explicit idempotency/provenance and expected-head reconciliation, and test multi-push, rerun, squash/rebase, inherited/spoofed marker, and interrupted push. Official reference: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency .

SV5 — Release-branch contract is absent in these three implementations. release-* is excluded from both jobs and the helper only supports patch/minor/check. There is no exact release-X.Y.Z setter/check in the three PRs. Mark release handling explicitly deferred or implement its owned bounded contract; do not present parity with EP's separate release workflow. A branch name alone must not constitute approval for a new major or a replacement release.

SV6 — Helper is neither strict enough nor atomically writing. advance() uses direct Path.write_text, not temp/replace. current() calls payload.get even for a JSON list; schema_version=true is accepted as 1, an empty product ID passes, and a different product ID is not rejected. In an isolated execution of the retrieved current() logic, a normal manifest passed, schema_version:true with product:'other-product' passed, an empty product passed, and [] raised AttributeError. Leading-zero versions were correctly rejected. Validate exact root/field types and product identity; use atomic per-file replacement and controlled errors. Define interruption handling rather than claiming transactionality. No focused behavior tests are added by this PR; --check on one valid fixture does not test bump, retry or failure semantics.

Related EP blockers, owned by EP #100: the existing wheel builder still calls advance() on every build, creating a second version allocator; the projection writer uses whole-file text replacement and sequential writes; the consistency checker omits package.json/package-lock and imports source modules while labelling part of the result installed. These must be reconciled before claiming shared complete semantics.

Minimum acceptance: documented source/baseline parity; build never allocates a release version; repeat builds preserve committed version and clean source; field-aware projection changes preserve dependency/protocol versions; final source head is qualified; multi-event execution is idempotent; release candidates cannot silently reuse immutable published identities; wrong-product/malformed/interrupted-write negatives are tested. No full installer/discovery/Workspace expansion is requested.

[pcvantol]

Architecture handoff: bounded version-preparation delivery

The response to the owner-reported delivery blocker is recorded on Forge #49: pcvantol/forge#49 (comment) . It applies to the four repository-owned versioning lanes without building the future generic Forge releaseplanner.

Forge Platform keeps its own version source/helper and candidate qualification. It does not become a cross-product privileged version dispatcher. Select EP's existing Managed Git/GitHub provider boundary for applying/publishing an explicitly approved version-operation, with a minimal typed adapter, actual writer-scope verification and retained repository protections. No new App/PAT/production credentials or direct-main bypass are implicitly authorized. Current source availability does not prove installed unattended execution.

Prepared receipt + manifest form one candidate commit; actual candidate SHA/PR/checks/merge identity are bound in separate delivery evidence, not by amending the receipt with its own containing SHA. Branch/event identity and policy authorization must be independently validated; the receipt itself grants nothing. Existing final-head qualification is retained and tested for the complete delivery path.

Preserve per-unique-eligible-source-event allocation, feature once per lineage, no bump for retries/repair/checks or the version-operation's own delivery/finalization. Batching can combine execution but not silently drop/recount source events; the shared comment gives the 2 minor events -> one 2.3.0 to 2.5.0 candidate example. This does not publish a release or change installer/CD authority. Owning docs should reconcile the choice and remaining proof; no implementation, workflow, merge, runtime, grant or release change performed in this comment.