Delivering an urgent design system hotfix

WHAT THIS TESTS: This evaluates whether you understand release hygiene under pressure: isolating an urgent fix from in-progress work and following semantic versioning.

A GOOD ANSWER COVERS: Do not ship from main, which contains two weeks of unreleased, unverified changes. Instead, create a hotfix branch from the git tag of the version the consumer currently uses. Apply the smallest possible change that fixes the reported bug, avoiding scope creep. Add a regression test that reproduces the bug so it cannot recur, and run the full CI suite plus any visual regression checks. Publish a patch release under semantic versioning, for example bumping the third number, since this is a backward-compatible bug fix. Communicate the new version and changelog entry to the consumer team so they can bump and verify. Finally, forward-port the fix into main, by merging the hotfix branch back or cherry-picking the commit, so the next planned release also contains it and the fix is not silently lost. This delivers the fix fast while keeping releases clean and traceable.

COMMON WRONG ANSWERS: Releasing from main and forcing the consumer to absorb two weeks of unrelated, untested changes. Skipping the regression test. Bumping a minor or major version for a backward-compatible fix, or not versioning at all. Forgetting to forward-port, so the bug returns in the next release. Telling the consumer to patch locally with no upstream fix.

LIKELY FOLLOW-UPS: When would the urgent fix justify a temporary local override for the consumer while the patch ships. How do you decide patch versus minor. How do you prevent the same bug regressing across branches.

ONE CONCRETE EXAMPLE: The consumer is on 3.4.0; you branch hotfix from the 3.4.0 tag, fix the broken focus outline, add a test, release 3.4.1, tell the team to upgrade, then merge the fix into main so the upcoming 3.5.0 includes it too.