chore(qa): 🤖 relax constraints on "latest" tag usage

[punkbit]

Why?

The latest tag is a reserved tag that indicates the default version in npm. Safeguards were previously introduced to incentivise the release cycle to help maintain quality standards, e.g., pre-release (test or release candidate) -> stable -> latest. The recent introduction of the "skip pre-release" mode (#983) gives maintainers immediate control over defining a "stable" release. As a result, we are relaxing the previous safeguards around the latest tag to support this new flexibility

How?

• Remove "create-release" guard "Validate branch for latest release"
• Update documentation

Contribution checklist?

• You've done enough research before writing
• You have reviewed the PR
• The commit messages are detailed
• The build command runs locally
• Assets or static content are linked and stored in the project
• For documentation, guides or references, you've tested the commands

Security checklist?

• All user inputs are validated and sanitized
• No usage of dangerouslySetInnerHTML
• Sensitive data has been identified and is being protected properly
• Build output contains no secrets or API keys

Preview?

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: c682d88

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Claude finished @punkbit's task in 51s —— View job

---

PR Review

Clean, minimal change that does exactly what it says on the tin. ✅

What's removed: The hard guard in create-release.yml that blocked latest releases from any branch other than main.

What's preserved (all other safeguards remain intact):

• Validate release confirmation — still requires typing both the release type and branch name for stable/latest releases
• Validate latest release eligibility — still enforces that a pre-release version must exist before promoting to stable/latest
• Maintenance branch safeguard check — still prevents releasing from main when a maintenance branch already exists for that version
• Check if version already published — duplicate publish protection still in place

Documentation update (docs/package-release.md) is accurate and the [!WARNING] callout clearly communicates the downgrade risk for users who haven't pinned a version. That's the right level of visibility for a footgun this significant.

💡 Suggestion (non-blocking)

• Consider making the [!WARNING] in the docs even more actionable — e.g., linking to the npm docs on dist-tags or adding a note about how to check the current latest tag (npm dist-tag ls @clickhouse/click-ui) before deciding to overwrite it. Not required — the current warning is already clear.

✅ No bugs, no regressions, no missing guards. The trade-off is intentional and well-documented. Nice work! 🙌

[workflow-authentication-public]

📚 Storybook Preview Deployed

✅ Preview URL: https://click-b3t3tds5u-clickhouse.vercel.app

Built from commit: d786d8275f0fb2c860430fe308f75194cdd54eb4