ci: adopt canonical product versioning

[pcvantol]

Canonical product versioning

Canonical source: product-version.json (forge, 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 can validate a declared helper, isolate its candidate, verify its allowlisted receipt/projection diff and bind exact-head qualification evidence. It is not installed-runtime evidence, a version grant, protected merge authority or publication proof.

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 de productpolicy forge-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 a0602ba702fcf0ec3807599526257c410084b02f. Shared design findings and acceptance matrix are on pcvantol/forge-platform#17, comment 5581036398; EP-specific projection/build findings on pcvantol/engineering-platform#100, comment 5581045514. Review only: no source, runtime, grant, release or merge mutation.

Not merge-qualified as the complete claimed versioning capability. One canonical product version, distinct from Mission/schema/producer/protocol versions, is a good boundary. Remaining owning findings:

1. .github/workflows/canonical-versioning.yml creates a new version commit after only checking the manifest. It uses checkout's default GITHUB_TOKEN. Token-generated push events do not automatically start push workflows, and qualifying PR events can require manual workflow approval under current GitHub behavior. The actual final head needs an explicit qualification path; the previously green SHA cannot qualify the new one. This is especially important with Forge's exact-head gates and its goal of avoiding owner-message relay. Normal git push may be denied by branch protection; do not add a bypass.
2. Per-ref concurrency serializes only these jobs, not repository users or EP. Event checkouts can become stale; non-fast-forward rejection is safe but leaves the promised bump semantics incomplete. Default concurrency may replace pending runs. Subject-only git log origin/main..HEAD can trust an inherited/unrelated/matching human commit as the branch marker; main reruns lack durable event idempotency. Add expected-head reconciliation and explicit operation identity, with multi-push/retry/rebase/squash/inherited-marker tests.
3. release-* is only excluded. No release-X.Y.Z parser/setter/check is added; the helper supports patch/minor/check only. Do not claim release behavior parity with EP. Explicitly scope it as deferred or implement the approved bounded contract.
4. The canonical source here is product-version.json, not pyproject.toml. --check verifies only its shape/version, not installed package/runtime projections. This is valid as a foundation if clearly scoped, not proof of a complete installed-product version contract.
5. advance() writes directly with Path.write_text. current() accepts schema_version=true and empty/wrong product strings, and a JSON array raises AttributeError at payload.get. These cases were reproduced using the retrieved helper logic in disposable files, not by running Forge's full suite. Validate exact root/schema/product identity and use atomic replacement/recoverable interruption semantics. Add focused tests; none are introduced in this patch beyond invoking --check on the happy-path manifest.
6. The shared policy document says baseline 0.1.0, but this manifest is 2.3.0. Reconcile the approved baseline without resetting history. A common baseline does not imply synchronized versions or compatibility across products. Intentional branch-event numbering still needs an explicit stable-release SemVer/compatibility boundary and immutable artifact identity.

Preserve product-version versus runtime schema/Mission/contract versions. Fix these bounded versioning concerns in this owning lane, without pulling the consumer #46 or Forge Server work into it. Official behavior 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]

Architectuurclarificatie — bounded version-preparation delivery, geen nieuwe Forge releaseplanner

Naar aanleiding van Peters gemelde SemVer-blocker. Gelezen: Forge #49 269675b7, Workspace #14 3522a5ee, Forge Platform #17 2987e29e; EP #100 metadata 34b9b344. De Workspace-helper en read-only workflow zijn geïnspecteerd, evenals EP main fea81e81 (execution_repository.py, providers.py) en de gemergde Forge policyarchitectuur. Dit is een beperkte architectuur-/integratiebeslissing voor de bestaande lanes, geen nieuwe codekwalificatie, actorcredential, grant, mergeapproval of runtimeactivatie. De hostauth en installed version-preparation route zijn hier niet geverifieerd.

1. Eigenaarschap en gekozen uitvoeringsroute

De productrepository bezit de versiebron, projectiepaden en versiepolicy. EP bezit de begrensde uitvoering die een expliciete version-operation toepast en als kandidaat aanbiedt, via de bestaande Managed repository-/Git-/GitHub-deliverygrenzen. GitHub en de repository behouden required checks, reviews en mergebescherming. Forge/Workspace/Forge Platform hoeven geen eigen privileged dispatcher of releasebot te bezitten. De toekomstige Forge releaseplanner kan later dezelfde expliciete opdracht produceren; hij is nu geen voorwaarde.

EP main heeft reeds GitProvider, GitHubProvider (via gh) en GhCliClient voor repository-/PR-coördinatie. Dat is de geselecteerde providergrens, NIET bewijs dat de speciale version-operation-adapter of zijn installed credentials al gekwalificeerd zijn. Implementeer/kwalificeer de minimale binding van het bestaande operationcontract aan die route; geen nieuwe execution mode, eventserver of tweede queue. De writer moet de allowlist en operation/baselinebinding zelf afdwingen; een vrij shellcommando of door een model samengesteld plan is daarvoor niet voldoende.

De bestaande geautoriseerde bootstrap-developmentroute mag, binnen haar echte actuele scope, deze aansluiting en tests opleveren zoals andere implementation-PRs. Zij is geen permanente alternatieve runtimewriter en een geslaagde Codex/connector-PR is geen bewijs van unattended EP-uitvoering. Een bronwijziging voor de adapter hoeft niet circulair te wachten op een reeds geïnstalleerde kopie van zichzelf.

2. Credentialkeuze is geen gok over aanwezige GitHub Apps

Gebruik de voor de bestaande EP Git/GitHub-provider daadwerkelijk geconfigureerde en toegestane identity. Verifieer zonder secrets te loggen actor, repositoryscope, benodigde branch/PR-rechten en het type/authmechanisme. Geen nieuwe brede PAT, geen credentialexport vanuit ChatGPT, geen verzonnen App-ID/private key en geen bypass van main/reviewbescherming.

De gekoppelde ChatGPT GitHub App heeft eerder PRs kunnen maken, maar dat betekent NIET dat haar credentials lokaal in Codex/EP/Actions beschikbaar zijn. Ontbreekt een geschikte unattended identity echt, rapporteer het specifieke provisioningvereiste; noem dat niet een onbekende architectuureigenaar of eis voor Forge's toekomstige planner.

Read-only CI mag read-only blijven. Een legaal geautoriseerde featurebranch/PR-write met GITHUB_TOKEN is niet intrinsiek een protection bypass; het probleem van de oude variant was extra ongekwalificeerde SHA's en onvoldoende operation/eventbinding. GitHub documenteert dat token-generated PR-events workflowapproval kunnen vereisen en token-pushes niet vanzelf reguliere push-CI starten. De gekozen EP-providerroute moet zijn uiteindelijke exacte kandidaat daarom aantoonbaar door de echte kwalificatieketen sturen, zonder zelf groene statussen te schrijven. Zie https://docs.github.com/en/actions/concepts/security/github_token en https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax .

3. Minimale keten en evidence

approved explicit operation -> EP admission/ownership -> apply product helper on expected baseline -> verify manifest + receipt + allowlisted diff -> candidate commit/PR -> exact-candidate qualification -> protected authorized merge -> delivery readback.

Bind minimaal repository/product/component, operation-ID, policyrevision + digest, bron-event/lineage (of expliciete bevroren eventset), expected source head, expected target-branch head waar relevant, baseline/targetversie, toegestane paden, geverifieerde actor/grantreferentie, prepared-receiptdigest, candidate commit/tree, PR-identiteit, echte qualification-run/checkreferenties en uiteindelijke merge/deliveryrevision. Voor een bestaande featurelane mag de version-preparation-step in haar bevoegde kandidaat plaatsvinden; geen tweede writer of concurrerende version-PR op dezelfde featurebranch. Een main-origin version-preparation krijgt een eigen beschermde kandidaat, nooit een direct-main-write.

De tracked prepared receipt is geen autorisatie en geen qualification receipt. Controleer authority onafhankelijk via de bestaande governancegrens. De receipt kan niet haar eigen bevattende commit-SHA of toekomstige CI-uitkomst opslaan zonder een nieuwe commit te creëren. Houd de vooraf vastgelegde operatie/receipt immutable; bind de resulterende SHA en checks achteraf in EP-owned deliveryevidence of echte GitHub qualification artifacts/readback. Geen result_commit-amend-loop die steeds opnieuw een ongekwalificeerde head maakt.

Volledige relevante checks en reviews gelden voor iedere laatste kandidaat; een read-only workflow kan dat prima bewijzen. Kwalificatie van de synthetische merge-ref mag aanvullend bestaan, met expliciete binding aan head én base; geef die SHA niet uit voor de bronhead. Hoofd-/basewijzigingen, rebase, repair en late versionwrites invalideren toepasselijk bewijs. Geen 'manifestcheck PASS' als vervanging voor de normale repositorychecks.

4. Eventbeleid: allocatie per unieke kwalificerende brongebeurtenis, niet per CI-kandidaat

Behoud de eerder gekozen nummeringspolicy: één feature-patch per featurelineage, één main-minor per unieke kwalificerende brongebeurtenis, expliciete release-X.Y.Z en geen automatische major. Een retry, bot-generated versiecommit, candidate-repair, requalification of het afleveren/finaliseren van dezelfde version-preparation telt niet als nieuw business/source-event.

Events en kandidaatpogingen zijn verschillende identiteiten. Behoud/verifieer bron-events en verwerk elk hoogstens eenmaal; een git commitonderwerp, willekeurige event_lineage-string of een CI-run-ID bewijst geen geautoriseerde brongebeurtenis. Voor PR-protected main bind de eventprovenance aan de feitelijke owning delivery/merge en voorkom dubbeltelling via meerdere notificaties.

Bundelen mag uitvoering besparen, niet nummering wijzigen. Twee nog onverwerkte minor-events vanaf 2.3.0 kunnen in één begrensde kandidaat resulteren in 2.5.0, met beide eventidentiteiten en de reductie vastgelegd. Dit claimt geen gepubliceerde 2.4.0-release. Twee herkwalificaties van één event leveren nog steeds slechts één bump op. Een batch wordt bevroren vóór zijn kandidaatpublicatie; later arriverende events worden zichtbaar bewaard voor een volgende operatie. Stale-baseline-herstel blijft gelinkt aan dezelfde bronallocaties; nooit onzichtbaar nogmaals tellen. Event-catch-up vóór policyactivatie is niet impliciet toegestaan.

Als coalescing de policy werkelijk moet veranderen naar 'één bump per gekwalificeerde verzamelde delivery' in plaats van 'per bron-event', vraagt dat een expliciete policywijziging; doe dat niet stilzwijgend als concurrencyfix.

5. Oplevering en afbakening

De concrete blocker heet nu: EP version-operation delivery adapter + verified writer binding + exact-head qualification wiring. Niet: 'Forge/Workspace moeten een eigen geprivilegieerde workflow hebben'. Geen generieke Forge releaseplanner, Workspace UI, installer, App Store/CD-adapter of nieuwe privilegescope toevoegen.

Voeg gerichte proeven toe voor candidate-creation via de echte bevoegde provider, manifest/receipt in dezelfde commit, rejected out-of-scope paths, dubbele/ambigue PR-create recovery, stale head, nieuwe candidatechecks, preserved branch protection, event batching zonder verlies/dubbeltelling, self-induced event exclusion en receipt/SHA-binding zonder self-reference. Onderscheid source qualification, controlled bootstrap publication, installed EP proof en automatisch eventbedrijf; geen ervan bewijst automatisch het volgende.

Behoud bestaande helpers en reeds behaalde tests; geen herbouw zonder regressie. EP #100 blijft daarnaast zijn onafhankelijke assurance/queue/SemVerbevindingen behouden. Geen merge, publicatie, deployment, credentialwijziging of budgetreset door deze comment. Laat de owning lane deze keuze en de echte bewijsstatus in haar contractdocumentatie reconciliëren voordat volledige feature/main-eventautomatisering als READY wordt geclaimd.