Add content_type to DocumentationDocument for site search parity

[Mpdreamz]

Why

Site-wide search combines documentation with other surfaces that classify documents in _source differently than our plain type field alone. We need a persisted keyword that can diverge from type when JSON carries an explicit classification, while staying aligned with website-ai-search so a future shared DocumentationDocument can round-trip the same shape. The intentional duplication supports wider site search filtering across those indices and clients.

What

• Add content_type on DocumentationDocument with the same JSON-first normalization pattern used on the site side (stored value omitted when it matches type for stable round-trips).
• Document in XML why type and content_type coexist (polymorphic $type / JSON-ignored CLR type on the other repo; persisted filter via content_type).
• Extend serialization tests for emit, override-from-JSON, and round-trip.

Made with Cursor

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: ca3c3c75-605c-4485-9f69-c5e6e8464791

📥 Commits

Reviewing files that changed from the base of the PR and between 2b69bd0 and 887e10b.

📒 Files selected for processing (1)

• tests/Elastic.Markdown.Tests/Search/DocumentationDocumentSerializationTests.cs

🚧 Files skipped from review as they are similar to previous changes (1)

• tests/Elastic.Markdown.Tests/Search/DocumentationDocumentSerializationTests.cs

---

📝 Walkthrough

Walkthrough

This PR adds a ContentType property to DocumentationDocument that enables explicit specification of content type in serialized JSON. The property uses a three-tier fallback: returns the explicitly set _contentType value, falls back to the document's Type, and defaults to "doc". The setter normalizes values matching the document's Type to null, keeping JSON output stable. Tests verify serialization includes the content_type field and that deserialization correctly applies provided content_type values while preserving round-trip data.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately captures the main change: adding a content_type field to DocumentationDocument for improved site search compatibility.
Description check	✅ Passed	The description clearly explains the rationale and implementation details, relating directly to the changeset's addition of content_type functionality.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/docs-search-content-type

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[theletterf]

Where would the ContentType value come from? I understand this is to leave the type: content-type frontmatter for other things?