[Detail Bug] Markdown lists: closing code fences with 1–3 spaces indent aren’t recognized when opening fence is unindented

[detail-app]

Detail Bug Report

https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_c15a7c4c-e25f-43d3-a35a-60b263d38d57

Introduced in #141 by @WilliamAGH on Jul 28, 2026

Summary

• Context: The preprocessor handles AI streaming output.
• Bug: When an opening fence has 0 spaces of indentation from the list continuation point, closing fences with 1-3 spaces from continuation are not recognized as closing delimiters.
• Actual vs. expected: The code block displays "code\n ```" instead of just "code". The literal backticks and 4 spaces appear as text content.
• Impact: Code blocks display extraneous backtick characters as literal text content. Users see malformed code blocks in the rendered UI.

Code with Bug

maximumSourceIndentation =
  awaitedContinuationIndentation +
  COMMONMARK_MAX_FENCE_INDENTATION -
  bodyIndentation.length; // <-- BUG 🔴 subtracts bodyIndentation, preventing valid closing-fence indentation

Explanation

nestNumericListFences() calculates how far it should search (in source indentation) for a closing code fence inside a numeric list item. When the opening fence is flush with the list continuation (0 spaces from continuation), bodyIndentation becomes 3 spaces (for "1. "). Subtracting bodyIndentation.length reduces maximumSourceIndentation to the continuation indentation only, so a closing fence that is indented 1–3 spaces past the continuation (valid per CommonMark max fence indentation) is rejected and treated as literal content; a synthetic closing fence is then appended, producing rendered output containing the stray backticks.

Recommended Fix

In frontend/src/lib/services/numericListFenceNesting.ts, stop subtracting bodyIndentation.length:

- maximumSourceIndentation =
-   awaitedContinuationIndentation +
-   COMMONMARK_MAX_FENCE_INDENTATION -
-   bodyIndentation.length;
+ maximumSourceIndentation =
+   awaitedContinuationIndentation + COMMONMARK_MAX_FENCE_INDENTATION;

History

This bug was introduced in commit e57f73b. The commit message stated intent to "preserve CommonMark fence closing rules" when implementing numeric list fence nesting for streamed markdown, but the formula maximumSourceIndentation = awaitedContinuationIndentation + COMMONMARK_MAX_FENCE_INDENTATION - bodyIndentation.length incorrectly subtracts bodyIndentation.length, restricting closing fence recognition beyond what CommonMark allows.