Default CombineFrontmatter renames short keys to longer, unrelated standard fields: id → video, key → keywords, list → unlisted, seo → description_seo

[matt-edmondson]

What's wrong

NameStandardizer.FindStandardPropertyMatch (Frontmatter/NameStandardizer.cs:116) accepts a containment match in both directions. One direction is the reverse case, normalizedStandard.Contains(normalizedKey). Because of it, any key that is a substring of a name in StandardOrder.PropertyNames gets renamed to that standard name.

This happens under the default options (Standard naming, Conservative merge), and it happens even when no other key in the document claims the standard name.

Reproduction (HEAD 43a9cdc)

Running the default overload, CombineFrontmatter($"---\n{k}: v\n---\nB\n"), gives these renames:

Key	Becomes
id	video
key	keywords
list	unlisted
seo	description_seo
order	nav_order
nav	nav_order
source	resource
ref	references
og	og_image
twitter	twitter_card
class	classes
script	scripts

A nested Jekyll-SEO style block seo: {title: S, description: D} comes out as description_seo: {title: S, description: D}.

Why it matters

id, key, order, source and seo are very common frontmatter keys. After these renames, a site generator reads the page's id as a video value, or reads list: false as the boolean unlisted. The original key is gone, and nothing warns the user.

#162 covers the opposite direction: a standard name contained in a longer key (author_email → author). Its acceptance criteria don't include this direction, so a fix for #162 alone would leave this bug in place.

Suggested fix / acceptance criteria

• Drop the standard ⊃ key direction in FindStandardPropertyMatch, or allow it only when the extra part of the standard name is known decoration. Explicit known mappings, such as excerpt → description, stay as they are.
• Acceptance: every key in the table passes through the default CombineFrontmatter unchanged. The fix can be combined with Default Standard naming renames compound keys to a different field: author_email → author, previous_version → version #162, which is in the same method.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. This runs under the default options of CombineFrontmatter, so every caller is affected. Very common keys (id, key, order, source, seo) are silently renamed to unrelated fields that site generators interpret differently, such as list: false becoming unlisted. The values survive, but the document's meaning is corrupted and nothing warns the user.
• Area / suggested assignment: Frontmatter/NameStandardizer.cs, FindStandardPropertyMatch (80-131). The containment check at 116 accepts normalizedStandard.Contains(normalizedKey), and 111 applies the MayMatchByContainment length gate (Frontmatter/PropertyNameNormalizer.cs:104-105). The caller is at NameStandardizer.cs:67.
• Related: Default Standard naming renames compound keys to a different field: author_email → author, previous_version → version #162 is the opposite direction in the same method (author_email → author), so fix the two together. Aggressive and Maximum merging delete properties whose name merely contains another key: subtitle, tagline, username, author_url, canonical_url and summary_image lose their values #175 is the same raw-substring containment heuristic in PropertyMerger.FindBasicCanonicalName. Delegate property-name fuzzy matching to ktsu.FuzzySearch #113 (delegating to FuzzySearch) touches the scoring used at 121.
• In progress? No open PR matches.
• Notes: The simplest safe change is to drop the standard ⊃ key direction entirely. If it is kept, allow it only when the leftover part of the standard name is a known decoration from PropertyNameNormalizer's prefix and suffix lists, or match on whole words via NormalizeToWords. In practice, fixing Default Standard naming renames compound keys to a different field: author_email → author, previous_version → version #162 the same way will likely leave containment matching doing very little, and known synonyms should come from PropertyMappings anyway. Add a data-driven test over every key in the table, including the nested seo: {title, description} block, asserting that each key round-trips unchanged under the default overload. Keep the existing tests for explicit mappings (excerpt → description).

---

Generated by Claude Code