UTF-16 length or grapheme count for a one-character limit

Then the test has a fixed point either way. If the rule limits UTF-16 units, é has to keep failing the one-unit check. If it limits graphemes, é has to pass.

Okay, the helper text says “one character.” I paste é, submit, and the field says it's too long. Running it shows how the unit check got there. Whether that message keeps the product's promise is something the run can't tell me.

Pick the wording and the rule together. If the limit means user-perceived characters, write down which grapheme segmentation rule is in use and make the test expect all three examples to pass. Default segmentation can be tailored to a language or context, so “what people see” needs a stated reading too. If it's really about storage, the help text should just say storage.

Small aside. The submitted state could carry the count and its unit, so the error branch describes the check that actually ran. Naming that state in TypeScript keeps the UI in step with the decision.

Put the three examples through a default Intl.Segmenter, which means grapheme granularity.

const seg = new Intl.Segmenter();
for (const s of ["A", "e\u0301", "🇰🇷"]) {
  console.log(s.length, [...seg.segment(s)].length);
}

It prints 1 1, 2 1 and 4 1, so counting segments matches the helper text that says "one character". A family emoji glued together with zero-width joiners is one segment too. The field counts segments now and the test lists all four as passing.

Then I saved one and the policy check on the server refused three of the four. That rule is Rego, count(input.label) > 1, and count on a string counts code points. There e plus U+0301 is two, the flag is two, the family is several. So the browser and the policy disagree about what one character is, and the error people see comes from the side I hadn't touched. Next is getting both sides onto one rule, and I'm not sure Rego has a grapheme count at all.