feat(markdown): render frontmatter in file previews - #8202

💭 I'm checking the current PR head at ae9eea8, comparing it against prior review comments on earlier commits. The diff shows MarkdownFrontmatterTable.tsx now uses Badge and ScrollArea components, and the CSS was restructured to remove the min-width constraint on the markdown table while scoping the text-align rules more narrowly. I want to verify the current CSS reflects these changes properly.

1. git_tools — 082e6ea..ae9eea8

2. browse_code — apps/web/src/index.css

💭 Both prior findings look addressed. I want to double-check the current MarkdownFrontmatterTable.tsx web file and confirm the chat table min-width rule wasn't accidentally removed—looks like it's still intact, so I'll go look at the current web component now.

3. browse_code — apps/web/src/components/files/MarkdownFrontmatterTable.tsx

4. git_tools — f737f14..ae9eea8

💭 The remaining PR-specific changes beyond the merge are the reorganized table CSS rules and dropping !text-right, plus the frontmatter wrapping fix — both prior review comments look addressed. Now I'm checking the current CSS state for new issues, specifically whether removing min-width: max-content and the overflow-wrap/word-break overrides from .markdown-table still lets values wrap properly, while making sure .chat-markdown table doesn't inherit conflicting overflow-wrap behavior. Since the frontmatter table in FilePreviewPanel renders as a sibling div outside .chat-markdown, it doesn't inherit that wrapping rule, so no conflict there. The thead rule and text-align changes also seem harmless since the component doesn't use a thead and relies on Tailwind utilities instead. I'm now considering whether removing the min-width constraint could cause the table to overflow unexpectedly within its ScrollArea, given the scroll fade and hidden scrollbar settings.

5. git_tools — chat-markdown-table-container

💭 The frontmatter table styling matches the ChatMarkdown pattern, and the border behavior on table rows is consistent. The mobile file is out of scope, so I'm narrowing my review to files within apps/web/src to check for remaining issues. I'm now looking at FilePreviewPanel.tsx, where the wrapper div takes over the padding/margin classes that ChatMarkdown previously applied — that seems fine since cn handles empty strings gracefully. But there's a subtler concern: since the frontmatter table now sits outside the .chat-markdown scope, I need to verify whether --contrast-border and related CSS variables are defined at that scope or globally, since rendering outside that boundary could cause the table to fall back to inherited values instead of the intended theme variables.

6. git_tools — --contrast-border:

7. browse_code — apps/web/src/index.css

💭 I'm noticing that the frontmatter table uses Tailwind's foreground utilities while chat markdown tables use the contrast role variables, which conflicts with the instruction that runtime-adjusted roles need to be shared custom properties everywhere, so headings, chrome, menus, and previews don't end up split between adjusted and unadjusted colors. This looks like a real internal split: the markdown table's borders inherit --contrast-border so they respond to contrast adjustments, but its text stays on unadjusted --foreground, meaning raising contrast brightens the separators while leaving the key/value text stuck at the old shade, right next to markdown body text that does adjust properly.

8. git_tools — contrast-foreground

💭 I'm trying to figure out whether --foreground itself is runtime-adjusted or if only --contrast-foreground is meant to be treated that way, since the guidance suggests auditing literal uses of var(--foreground) separately. I want to check whether the markdown body's base styles apply --contrast-foreground only to headings or more broadly.

9. browse_code — apps/web/src/index.css

💭 I need to find where the base text color for .chat-markdown is defined in the styles.

10. git_tools — ^.chat-markdown {

💭 I'm noting there's no dedicated markdown color block, so the text color inherits from the parent surface—likely text-foreground from the app root—while the --contrast-* variables just handle chrome like borders, code, and links. That makes the frontmatter table's foreground usage roughly consistent with how the markdown body inherits its color. Now I want to check the wider FilePreviewPanel context for regressions, particularly whether ChatMarkdown's default className handling and RenderedMarkdownSurface's scroll behavior still work correctly with the updated wrapper spacing.

11. git_tools — function RenderedMarkdownSurface

💭 I notice the frontmatter's bodyOffset is computed from the contents prop, but currentContents could be optimistic data that differs slightly—this is an edge case in existing behavior, not really a UI consistency issue. I'm also noticing that MarkdownFrontmatterTable gets used in a surface that isn't .chat-markdown, which might matter for styling. Now I'm weighing whether .markdown-table deserves to be a global CSS class given it only has one consumer. Since it shares declarations with .chat-markdown table, which legitimately needs global styling for generated markdown, this seems like a defensible shared visual contract, though there's a dead selector for thead th that never actually matches anything. I also confirm there's no real cascade conflict between the global text-align: left rule and the component's Tailwind classes—td doesn't clash, and removing th from that rule means the text-right utility applies cleanly without needing an override. The unlayered global padding rule on th/td would override any Tailwind p-* classes a consumer might want, but since there's only one consumer, this isn't currently a problem. I'm also noting that removing the previous overflow-wrap: normal rule means long unbroken strings like URLs could overflow the table, though the ScrollArea's horizontal scroll and fade effect should handle that gracefully. The whitespace-pre-wrap styling combined with no min-width: max-content should let multi-line scalars wrap fine too. Now I'm trying to determine if there's still a real issue worth flagging, looking at how the ScrollArea component's chaining props are configured. Checking accessibility of the table structure, the scoped row headers look correct, and I'm noting that the nested pre element's horizontal auto-scroll is effectively unused since the text wraps anyway — a minor inefficiency but not a bug. I'm also confirming that duplicate keys shouldn't occur since the schema decoding guarantees uniqueness, and verifying that the Badge component renders as a span (which would be valid inside a td regardless). Checking the Badge component's outline variant styling now to make sure text sizing works correctly within the smaller font context... Now I'm confirming the CSS refactor splitting the shared and chat-specific table rules preserves the original behavior exactly — the padding and text-alignment rules for the markdown table variant look equivalent to before, just reorganized to apply more broadly. The .chat-markdown tbody th addition is a subtle behavior change, but since GFM tables never actually render th in the body, it's harmless in practice. I want to keep double-checking for anything I might be missing before concluding the review is clean. Revisiting the earlier long-scalar wrapping concern, removing the max-content width seems to have fixed it, and the key column shrinking with whitespace-nowrap should be fine since keys are typically short. The value column with auto table layout and pre-wrap should handle wrapping properly, so that part looks solid. I'm also checking that the frontmatter table sits outside the chat markdown container, using contrast borders and no outer radius, which looks intentional rather than accidental, and confirming the ScrollArea props like chainVerticalScroll and scrollFade are actually valid and already used elsewhere in ChatMarkdown. I'm tracing whether this PR touches any shared renderers tied to environment actions, but the new call site just passes a scoped thread reference into ChatMarkdown, and the frontmatter table only renders raw text without file chips, so that path looks clean. I'm now just double-checking a text color value against the markdown body's color to make sure they're consistent.

12. git_tools — ^(pre|code|table|th|td)[ ,{]

💭 I'm checking whether the ScrollArea component needs extra props like chainVerticalScroll alongside hideScrollbars and scrollFade, and confirming it handles table content without clipping, similar to how it's used in ChatMarkdown. Double checking that removing min-width: max-content from the shared rule doesn't create a specificity conflict with .chat-markdown table — it doesn't, since the two declarations don't overlap. Given no new violations found, I'll report success with a concise title and summary of "All clear," and there's nothing further to flag.