The public Notation API never emits a `<stem>` element — shared-stave stem-role correctness depends entirely on Verovio's own MusicXML-import defaults, unmeasured and unverified by Gradus

MusicXML's `<stem>up</stem>` / `<stem>down</stem>` element lets an exporter explicitly fix stem direction per note, exactly what the JSX/VexFlow renderer does via `stem_direction` on every forced-role note. Verovio, like any MusicXML consumer, falls back to its own internal default (voice/layer-based, similar in spirit to the JSX convention but not guaranteed identical in every edge case — e.g. a 3-4 voice single-staff instrument, which Verovio was never told to auto-split) when no `<stem>` is present.

MusicXML specification (the `<stem>` element exists precisely so an exporter can pin this down rather than leave it to the importer); Gould's fixed-stem-role convention (voice-numbering-role-fixation) is the target behavior, but nothing in Gradus's own code asserts Verovio actually reproduces it — this is a genuine engine-parity gap between the two Gradus rendering surfaces, not a defect confirmed by reading Verovio's own source.

This rule needs the notated content and the rendered result together — the score says what should happen, the page says whether it did.