`get()`-regexens verdi-gren brukte `\s*`, som inkluderer linjeskift. Enhver
key med tom rest-av-linje slukte dermed den neste ikke-tomme linja. Utslaget
var bredere enn list-keys: en tom `title:` returnerte neste keys hele linje
("type: OKR"), og et tomt `description:` dempet okf-checks anbefalt-felt-
advarsel med data som tilhorte en annen key.
Verdi-grenen strammet til `[ \t]*`. Innrykk-ankeret (`^\s*`) er urort -- det
er load-bearing for inject-okr-context.mjs:69s nestede organisasjon:-lesing.
Kontrakt-kommentaren i :13-16 lovet allerede null for list-keys; den er naa
sann i stedet for aa bli rettet ned.
Sju RED-verifiserte tester: (L1) list-key gir null - (L2) tom skalar sluker
ikke neste rot-key - (L3) tom key foran list-blokk - (L4) innrykk-toleransen
bevart, forelder gir null - (L5) tab-separert verdi - (L6) tomt anbefalt felt
demper ikke okf-check-advarselen (rootLevelGet arvet defekten) - (L7)
broedtekst-fallbacken plukker ikke list-verdi fra frontmatter.
(L7) gjor S57s latente begrunnelse maalbar: uttrekket i okf-check.mjs:125 ble
beholdt mot nettopp denne defekten, og naar fm-laget endelig taper for
list-keys er `body = raw` foerste gang en roednende mutasjon.
Mutasjons-verifisert (M1 revert, M3 anker-fjerning, M4 uttrekk-fjerning). M2
viste at (L5) ikke vokter tegnklassen -- .trim() gjor `[ \t]*` og `[ ]*`
ekvivalente -- saa testen er omskrevet til aa paastaa det den faktisk viser.
Suite 321 -> 328.
