Skip to content

fix: auto-frontmatter legacy wiki pages#381

Open
Jacob Weyer (JacobWeyer) wants to merge 1 commit into
langchain-ai:mainfrom
JacobWeyer:codex/auto-frontmatter-index
Open

fix: auto-frontmatter legacy wiki pages#381
Jacob Weyer (JacobWeyer) wants to merge 1 commit into
langchain-ai:mainfrom
JacobWeyer:codex/auto-frontmatter-index

Conversation

@JacobWeyer

Copy link
Copy Markdown

Summary

  • auto-add minimal OKF front matter to legacy Markdown pages before deterministic index sync
  • derive fallback metadata from the first H1, first prose paragraph, and filename when needed
  • keep malformed YAML front matter as a hard failure so ambiguous metadata is not silently rewritten

Why

OpenWiki now treats front matter as part of its generated-doc contract: the index synchronizer parses page metadata to render directory indexes, and the write validator warns when new wiki pages omit required OKF fields. That works for fresh pages, but update runs can fail on existing generated docs that predate the front-matter requirement.

Observed failure while running openwiki@0.2.0 against an existing repository wiki:

/openwiki/access-and-users.md lacks YAML front matter.

This meant a user had to manually add front matter before OpenWiki could finish indexing. The tool should handle that migration itself.

Behavior

For Markdown files included in wiki indexes:

  • if a page already starts with front matter, existing parsing/validation behavior is preserved
  • if a page has no leading front matter, OpenWiki prepends:
    • type: Reference
    • title from the first H1, or filename fallback
    • description from the first prose paragraph, or a generic fallback
  • malformed or duplicate YAML still fails loudly

Validation

  • pnpm exec vitest run test/index-middleware.test.ts
  • pnpm exec vitest run test/frontmatter-validator.test.ts test/index-middleware.test.ts
  • pnpm run typecheck
  • pnpm run build
  • pnpm run lint:check
  • pnpm test

@colifran

Copy link
Copy Markdown
Contributor

Thanks Jacob Weyer (@JacobWeyer). Definitely agree with what I'm reading in your PR description. Migration shouldn't be a user concern. Taking a look at your PR!

@colifran

Copy link
Copy Markdown
Contributor

Q about, "keep malformed YAML front matter as a hard failure so ambiguous metadata is not silently rewritten". I'm not sure having a hard failure here was ever the right choice. I think we could have maybe a degraded front matter rather than a hard failure. Something deterministic that maybe we just attempt to pull from the markdown file. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants