ci: adopt canonical product versioning

[pcvantol]

Canonical product versioning

Canonical source: product-version.json (workspace, schema 1), baseline 2.3.0 (not publication evidence).

The helper provides read-only inspect/plan and explicit patch/minor or exact-version application. Every apply binds a durable operation ID, policy revision, source-event lineage, expected source HEAD and expected baseline, and writes a tracked receipt containing its determined result and sole permitted projection. Same inputs are idempotent; changed inputs conflict; stale heads fail; interrupted manifest-only local writes recover without a second bump.

--verify-release-source is a separate read-only release guard. It accepts only release-X.Y.Z, requires the canonical X.Y.Z to match, and requires candidate HEAD to equal the externally approved revision - not merely be its descendant. Workspace has no distributable runtime/artifact today, so artifact and installed checks are NOT_APPLICABLE.

The workflow remains read-only. Engineering Platform #105 is the pending source-level bounded adapter for future integration; it does not prove an installed writer, active grant, protected merge delivery or artifact publication. No self-push, bypass, publication, runtime, grant or merge occurs here.

Validation: bash scripts/validate.sh (eight focused operation regressions). Hosted checks must qualify this final PR head.

Bootstrap release cadence V2

BOOTSTRAP_RELEASE_CADENCE_V2: nieuwe operations gebruiken workspace-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 SemVer review of exact head fcda180e7e6323c54b54e5b3186ef0056514d52e. Shared policy review: pcvantol/forge-platform#17 comment 5581036398; equivalent Forge helper/workflow review: pcvantol/forge#49 comment 5581050095. Review only; no source, host, authority, version or merge mutation.

Keep one Workspace-owned product version independent of schema/protocol versions. The following gaps prevent treating this as the complete qualified versioning design:

• The workflow uses default GITHUB_TOKEN, then pushes a new version SHA after checking only the manifest. Push-triggered CI is not recursively started by that token; supported PR events can require manual approval. Qualify the actual resulting SHA explicitly, rather than inheriting old-head checks or requiring a new owner relay.
• Actions per-ref concurrency does not exclude users/EP pushes and its default pending behavior is not an exactly-once queue. Stale checkout pushes can fail non-fast-forward with no reconciliation. A matching commit subject in origin/main..HEAD is not a durable authenticated branch/event identity and can be inherited or spoofed. Test multi-push, rerun, interruption, squash/rebase and marker provenance.
• release-* is skipped by both jobs; no release-branch parser/setter or release matching check is implemented. Mark that behavior deferred instead of claiming parity with EP.
• This PR uses product-version.json, not pyproject.toml, and validates only the manifest. An installed Server/Client package-version projection is not implemented here. Define this clearly as the current foundation and wire future artifacts to this single source rather than inventing another independent version.
• advance() uses non-atomic Path.write_text. current() accepts boolean schema_version=true and empty/wrong product identity, and JSON [] produces AttributeError rather than its defined validation error. Isolated reproduction of the shared helper confirmed those paths; no full Workspace suite was run. Add strict manifest identity/types, atomic replacement, failure/retry tests and focused bump tests.
• The owning policy still says 0.1.0 while the manifest is 2.3.0. Align documentation to the explicitly approved baseline, without implying published history or lockstep compatibility. Branch-event numbering and public-release SemVer compatibility must be distinguished; a stable published version cannot stand for different contents.

Please close these bounded contract/implementation findings without adding Workspace Server/UI scope. Normal repository protection remains binding; do not grant bypass rights to make bot pushes work. Official references: https://docs.github.com/en/actions/concepts/security/github_token ; https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency ; https://semver.org/ .

[pcvantol]

Architecture handoff: version-preparation delivery owner resolved

The coordinated response to the owner-reported blocker is recorded on Forge #49: pcvantol/forge#49 (comment) . This is architecture/integration guidance for the current increment, not merge approval, runtime activation or new credential authority.

Workspace retains its product-version source/helper and read-only validation. It does NOT need its own privileged PR bot. The selected writer boundary is EP's existing Managed Git/GitHub delivery route, with a bounded version-operation adapter and the actually configured authorized identity; source existence is not installed readiness. Existing authorized bootstrap development can deliver that seam without requiring it to be installed first, but must not be mislabeled autonomous EP operation.

Apply/commit the explicit operation receipt and manifest as one qualified candidate, then bind actual candidate-SHA/PR/checks in external delivery evidence; do not amend the tracked receipt with its own containing SHA or future CI outcome. Bind actual operation authorization separately from the untrusted receipt. Main remains PR-protected and no new PAT/App/bypass is assumed.

Allocation remains per unique eligible source event (feature: once per lineage), not per check run or repair head. Batching may combine candidate delivery but must retain every counted event; version-operation-induced pushes/finalization must not recursively bump. Complete details and acceptance matrix are in the shared comment. Reconcile the owning adoption document with this selection, retaining unknown installed/writer qualification as an explicit implementation gap. No source, workflow, runtime, grant, version, merge or publication changed by this comment.