Compute the version on the pull request instead of after the merge

[darksidemilk]

Part 2 of 2, stacked on #1357 so the diff shows only the incremental change. GitHub will retarget this to working-1.6 when #1357 merges.

Turns on sync_version, so a PR into working-1.6 arrives already carrying the version its merge commit will produce.

This PR is half a change. The other half is a ruleset, and GitHub reads no in-repo config for it. Apply the ruleset before merging this.

Why the ruleset is load-bearing, not a nice-to-have

FOG_VERSION is the commit count since master, so predicting it before the merge is only sound while working-1.6 enforces both:

• require branches to be up to date before merging — so base is an ancestor of head and the merge brings nothing in from base's side;
• merge commits as the only allowed merge method — so the merge adds exactly one commit.

Squash collapses N commits into one and makes the count unrecoverable. Rebase adds no merge commit at all. Either setting being off silently makes every version written here wrong by one. That's why the requirement is spelled out at the call site in tests.yml rather than living only in this description.

The workflow doesn't merely trust the setting: it re-checks at runtime that HEAD contains the tip of the base, and skips the version step rather than committing a number it can't stand behind if base moved in between.

Applying the ruleset

Full JSON body is in the fog-docs PR. Four things that will bite if skipped:

1. bypass_actors for the GitHub App is mandatory. A pull_request rule blocks direct pushes, and both the daily sweep and the merge-time sync push directly with the App token. Without a bypass, every sweep run turns red the moment the ruleset activates.
2. Confirm the seven check names against a real run before enabling. They're <caller job name> / <called job name> — e.g. fogproject / tests (PHP 7.4). A mistyped required check blocks every PR permanently while looking like a workflow that simply never ran.
3. Do not make regenerate a required check — it's skipped on fork PRs and on any PR its guards exclude, which would leave those unmergeable.
4. Do not enable "require linear history" — mutually exclusive with requiring merge commits.

sync-generated-files.yml is kept, not deleted

It stops being the mechanism and becomes the backstop, still covering what the prediction cannot: a squash or rebase that slipped past the ruleset, an admin bypass, a merged fork PR that never ran the PR-time job, and anything the regen guards skipped.

On a well-behaved same-repo PR it now finds nothing to do. That is the expected outcome, not a symptom — its header now says so, because a workflow that always no-ops otherwise reads as broken.

Before extending to dev-branch

dev-branch's tests.yml has no name: fogproject on its suite job, so it currently reports suite / … instead. Normalise that first, or half the required checks will never appear.

---

Generated by Claude Code