Generate the Clint update manifest only on the publish branch

[KarelJanVanHaute]

Why

clint/updates/index.json conflicted on essentially every branch that shipped a frontend update. Two update PRs open at once both append an entry at the same position, so the merge always failed — and the resolution was always mechanical (re-run the generator).

The file is derived data. Every field comes from the update folders: title/date/issues/pr/requires from each update.json, hasOps from whether it has a frontend/root block, legacyVersion from the semver folder name, and seq from a plain (date, id) sort. AppliedState already documents that seq is never stored in a project, precisely so it can be regenerated freely.

We also already have a derived publish branch: clint-publish-updates force-pushes develop to clint-updates, and consumers' indexGitUrl points at clint-updates — not at develop. So the manifest only ever needs to exist there, and clint-updates is never merged into anything.

The existing workflow header even anticipated this trade-off.

What changed

• Untracked and gitignored clint/updates/index.json. No development branch carries it, so the conflict becomes structurally impossible rather than just easier to resolve.
• clint-publish-updates is now the sole producer — it builds the CLI, runs update:index, commits the manifest on top of develop's tree, and force-pushes to clint-updates.
• clint-update-index dropped the "committed manifest is current" check and gained the inverse guard: it fails if index.json is re-committed by mistake. Workflow name and the Validate update manifest check-run name are unchanged so required-status-check rules keep matching.
• Author-facing surfaces updated so nothing asks you to commit the manifest: authorflow.ts, updateNew.ts, updateIndex.ts header, both Clint docs pages, and the authoring-clint-updates skill.

No consumer change. indexGitUrl, updateRef, updatePath and the runtime fetch path are all untouched — the file lands on clint-updates at exactly the same path.

Verification

• yarn build-cli succeeds; tsc reports no new errors (the pre-existing ora/open interop errors are unrelated).
• update:index runs clean and its output is correctly gitignored.
• The CI tracking guard was tested both ways: passes when clean, fails when the file is re-added.
• The publish job was rehearsed against a throwaway origin — develop stays manifest-free, clint-updates ends up as develop's commit plus one manifest commit, and a consumer clone of that branch finds the file where it expects it.

Note for reviewers with open branches

Merging this develop into a branch that still tracks the file produces a one-time CONFLICT (modify/delete). Resolve with:

git rm clint/updates/index.json

Once per open branch, then never again.

Also worth knowing: the committed manifest had already drifted from what the generator produces (two entries both at seq: 9) — the exact hazard this removes. It self-corrects on the first publish.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE