Files
open-design/apps/web/src/artifacts/markdown-context.ts
DongsenandGitHub 12ce5ad38b fix(web): ignore <artifact> tags inside markdown code spans and fences (#1132)
* test(web): add failing parser cases for <artifact> recitation in markdown code

Cover the three real-world prose contexts where the model legitimately
quotes the artifact tag without intending to emit one:

- inside an inline backtick span
- inside a fenced code block
- spread across streaming chunks crossing the fence boundary

Establishes the RED baseline before parser code-fence awareness lands.

* fix(web): ignore <artifact> tags inside markdown code spans and fences

The streaming artifact parser scanned the buffer with a raw indexOf,
guarded only by 'next char must be whitespace'. That meant any literal
<artifact ...> the model recited while documenting the protocol — even
inside backticks or a ```html fence — flipped the parser into artifact
mode, swallowed the rest of the reply from the chat UI, and (when a
matching </artifact> appeared in the recitation) silently wrote a
spurious file to disk via persistArtifact.

Replace findOpenTag with a linear scan that tracks fenced code blocks
(```) and inline code spans (`), skipping any <artifact prefix found
inside either. If the buffer ends mid-fence, return a partial match
anchored at the fence start so the next streaming chunk can resolve
the boundary without losing fence context.

Closes #1130.

* fix(web): match renderer fence/inline-code rules in artifact parser

Codex review on PR #1132 caught that the previous fix toggled inFence on
any triple-backtick run anywhere in the buffer, including mid-line, while
the chat renderer (apps/web/src/runtime/markdown.tsx) only treats ``` as
a fence when it occupies a whole line matching /^[ ]{0,3}```(\w[\w+-]*)?\s*$/.
That asymmetry would suppress a real <artifact> tag emitted after a prose
sentence like "the opening marker is ```html and the response then writes:".

Rework findOpenTag in three passes that mirror the renderer:

  1. Walk \n-terminated lines; only a line that matches FENCE_LINE_RE
     toggles fence state. Open fences without a close (or with an
     unterminated tail line) return partial so the next chunk can resolve.
  2. Collect inline code spans with /`[^`]+`/g — the same regex used by
     renderInline — so what the parser skips matches what the user sees as
     code. Unmatched trailing backticks after the last \n hold back.
  3. Find the first <artifact …> outside any skip range; preserve the
     existing partial-prefix tail handling.

Adds a regression test covering the exact case Codex reported.

* test(web): pin parser behavior on double-backtick and in-fence string literal recitation

Two cases raised in PR #1132 review:

- a real artifact tag wrapped in '``<artifact …>``' (double-backtick
  inline code span) should not be treated as a real artifact
- a fenced JS example whose body contains a string literal like
  'const fence = "```";' should not pop fence state early and let a
  later literal <artifact> be parsed as real

Both already pass on 96e88ca because the line-anchored fence regex and
the renderer-aligned inline regex handle them correctly. Pinning the
behavior so future regressions surface as test failures.

* fix(web): make stripArtifact markdown-aware to stop truncating literal recitations

The streaming artifact parser was hardened in 96e88ca to skip <artifact>
recitations inside backticks and fences, but the post-stream stripper at
AssistantMessage.tsx still ran a naive 'content.indexOf("<artifact")' over
the same text events. As reported by lefarcen on PR #1132, that meant
chat replies with literal protocol recitations could still get silently
truncated mid-explanation — even though the parser preserved them in the
text stream and the file panel was no longer polluted with ghost files.

Extract the renderer-aligned classification (FENCE_LINE_RE, INLINE_CODE_RE,
computeSkipRanges, rangeContains) into a single source of truth at
apps/web/src/artifacts/markdown-context.ts so the parser and the stripper
agree on what counts as code. Add apps/web/src/artifacts/strip.ts with a
markdown-aware stripArtifact that:

- ignores any <artifact open inside a fenced block or inline code span
- looks for </artifact> with the same skip-range filter, so a real open
  paired with a literal close inside backticks does not strip a literal
  body that is meant to render
- returns content unchanged when an open exists with no matching real
  close (the previous implementation sliced to end-of-string, which would
  nuke trailing prose on a malformed or still-streaming tag)

Refactor parser.ts to import the shared helpers; behavior preserved (all
seven existing parser tests still pass). New strip.test.ts covers six
cases including the empirically-verified inline-backtick regression.

* fix(web): align artifact stripper/parser fence rules with renderer exactly

Two gaps surfaced in review at a0bf05f:

- markdown-context.ts used a single FENCE_LINE_RE that allowed 0-3 leading
  spaces and reused the same pattern for opening and closing fences. The
  chat renderer (runtime/markdown.tsx:44 and :49) is asymmetric — opens
  with /^```(\w[\w+-]*)?\s*$/, closes with /^```\s*$/, and rejects any
  leading indentation on either side. Indented "   ```html" was being
  treated as a code fence even though the renderer keeps it as a paragraph,
  and a literal "```html" line inside an open fenced example was closing
  the skip range early — both could expose a real or literal <artifact …>
  to the wrong handler.
- stripArtifact discarded computeSkipRanges' unclosedFenceStart, so a
  fenced literal that ends at EOF without a trailing newline (very common
  for chat output) leaked the inner <artifact …> recitation to the
  stripper, reproducing the original #1130 truncation symptom on a
  narrower input shape.

Split FENCE_LINE_RE into FENCE_OPEN_RE / FENCE_CLOSE_RE with no leading
indentation, gate the fence state machine on the right side of the toggle,
and have stripArtifact extend skip ranges to end-of-content when a fence
is left open. Also tightened the parser's tail-line hold-back regex to
match the renderer's no-leading-space rule. Added regression tests for the
EOF-unclosed-fence case, the indented pseudo-fence (renderer treats as
paragraph, stripper must strip the real artifact), and a "```html" line
inside an open fence.

Refs nexu-io/open-design#1130

* refactor(web): align streaming tail-line fence guard with FENCE_OPEN_RE

The streaming parser's tail-line hold-back used a stricter local regex
(/^```\w*$/) than the renderer's FENCE_OPEN_RE (/^```(\w[\w+-]*)?\s*$/),
missing valid opener tails like ```c++, ```ts-, or ``` (trailing space).

In practice these tails are still held back by the unmatched-backtick
parity scan that runs immediately after — three backticks in a tail line
are odd, so firstUnmatched stays set and the parser holds from that
position. So this wasn't a runtime correctness bug, just a regex
divergence that future readers could trip on.

Drop the local regex and reuse FENCE_OPEN_RE so the tail check matches
the same shape the rest of the pipeline already uses. Pinned the
behavior with three new parser tests (`+`/`-` info-string suffix and
trailing-space tails arriving as the first chunk) — they pass at HEAD,
proving the parity scan was already covering these cases.

Refs nexu-io/open-design#1132 (lefarcen polish P2)

* fix(web): scope inline-code skip ranges per block and reject <artifact prefix-shared opens

INLINE_CODE_RE previously ran over the whole buffer, so an unmatched
backtick in one paragraph could pair with a backtick in a later
paragraph and create a phantom inline span that swallowed any real
<artifact …> between them. Mirror runtime/markdown.tsx by splitting the
buffer on fence / blank / heading / list / hr boundaries and running
INLINE_CODE_RE per block region instead.

stripArtifact accepted any unskipped `<artifact` substring as a real
open, while the streaming parser already required a following whitespace
character — so prose like `<artifactual>demo</artifact>` was being
truncated to `prefix  suffix`. Extract the parser's real-open guard into
isRealArtifactOpenAt and reuse it from both sides.

While reordering findOpenTag for the shared guard, also fix the related
hold-back ordering issue tracked at #1141: a stray tail-line backtick or
fence-opener prefix used to suppress an artifact already complete
earlier in the buffer. Scan for the earliest complete real open first,
then pick the earliest hold-back position only when no complete tag was
found.

Regressions pinned in parser.test.ts and strip.test.ts for both new
finding shapes.

* fix(web): keep HR-shaped lines inside paragraph regions for inline-code scanning

The previous walker closed inline-scan regions on lines matching the HR
regex, but `parseBlocks()` in runtime/markdown.tsx does not break a
paragraph on HR — its inner accumulation loop only breaks on blank /
fence / heading / ul / ol (runtime/markdown.tsx:95-104). HR is only an
HR block in the outer loop's first-look, never mid-paragraph.

So inputs like `intro \`\n---\n<artifact …>…</artifact>\n---\nclosing \``
are one paragraph in the renderer, whose two stray backticks pair to
cover the literal artifact recitation — but the walker was splitting on
the `---` lines, leaving the recitation outside skip ranges, and the
parser/stripper would treat it as a real tag.

Drop HR from the paragraph-break list (HR-shaped lines carry no
backticks of their own, so keeping them inside the surrounding region
is benign either way) and document the renderer-mirror rationale.

Regressions pinned on both sides.
2026-05-11 19:29:22 +08:00

139 lines
5.9 KiB
TypeScript

/**
* Shared Markdown-context helpers used by both the streaming artifact parser
* and the post-stream `<artifact>` stripper. The single source of truth for
* what counts as a fenced code block or an inline code span — kept in lock
* step with apps/web/src/runtime/markdown.tsx so the parser/stripper view of
* a buffer matches what the chat UI will actually render.
*
* Anything that "looks like" an artifact tag inside one of these regions is
* literal Markdown and must not be treated as a real protocol tag.
*/
// Line-anchored fence delimiters, mirror runtime/markdown.tsx:44 (open) and
// runtime/markdown.tsx:49 (close). The renderer is asymmetric on purpose:
// an opening fence may carry an info string (e.g. ```html), a closing fence
// must be a bare triple-backtick line. Neither permits leading indentation —
// an indented " ```" line is rendered as a paragraph, not a fence.
export const FENCE_OPEN_RE = /^```(\w[\w+-]*)?\s*$/;
export const FENCE_CLOSE_RE = /^```\s*$/;
// Inline code span (single-backtick pair), mirrors runtime/markdown.tsx:164.
export const INLINE_CODE_RE = /`[^`]+`/g;
// Paragraph-break recognizers — these mirror the inner paragraph-accumulation
// loop in `parseBlocks()` (runtime/markdown.tsx:95-104), which is what
// actually decides where a paragraph ends. The outer loop in `parseBlocks`
// has additional block-starters (HR, fenced-code with `^```` prefix, etc.)
// but those only take effect when no paragraph is currently being built;
// mid-paragraph they are paragraph content. The renderer therefore treats
// `intro \`` / `---` / `<artifact …>` / `---` / `closing \`` as ONE paragraph
// whose backticks pair across the recitation — so this walker must too.
//
// Notable omission: HR — see comment above. HR-shaped lines (`---` / `***`
// / `___`) carry no backticks of their own, so leaving them inside the
// surrounding paragraph region is benign for inline-code scanning either way.
const HEADING_RE = /^#{1,4}\s+/;
const UL_ITEM_RE = /^\s*[-*+]\s+/;
const OL_ITEM_RE = /^\s*\d+\.\s+/;
// `<artifact` followed by whitespace is a real protocol open tag; any other
// continuation (e.g. `<artifactual`) is a prefix-shared literal that must not
// be treated as a tag. Mirrors the parser's `findOpenTag` real-open guard so
// the parser and the stripper agree on what counts as a real tag.
export function isRealArtifactOpenAt(content: string, idx: number): boolean {
const next = content.charAt(idx + '<artifact'.length);
return next !== '' && /\s/.test(next);
}
export type Range = readonly [number, number];
/**
* Compute the half-open `[start, end)` ranges of `buffer` that the renderer
* would treat as fenced code blocks or inline code spans. The `unclosedFenceStart`
* is the index of an opening fence with no matching close in the buffer (or
* `null` if every fence is closed) — the streaming parser uses it to hold
* back; the stripper ignores it.
*
* Lines without a terminating `\n` (the trailing partial line during
* streaming) are not classified as fence delimiters here. Callers that care
* about partial-state behavior should inspect the tail themselves.
*/
export function computeSkipRanges(buffer: string): {
ranges: Range[];
unclosedFenceStart: number | null;
} {
const ranges: Range[] = [];
// Paragraph-block regions are contiguous spans of paragraph lines outside
// any fenced code block. `renderInline` runs once per block, so inline-code
// scanning is restricted to one block at a time — backticks never pair
// across a block boundary in the rendered output.
const blockRegions: Range[] = [];
let pos = 0;
let inFence = false;
let fenceStart = -1;
let blockStart = -1;
const closeBlockBefore = (idx: number) => {
if (blockStart !== -1 && idx > blockStart) blockRegions.push([blockStart, idx]);
blockStart = -1;
};
while (pos < buffer.length) {
const eol = buffer.indexOf('\n', pos);
const lineEnd = eol === -1 ? buffer.length : eol;
const line = buffer.slice(pos, lineEnd);
const lineHasNewline = eol !== -1;
if (!inFence) {
if (lineHasNewline && FENCE_OPEN_RE.test(line)) {
closeBlockBefore(pos);
inFence = true;
fenceStart = pos;
} else if (line.trim() === '') {
// Blank lines separate blocks.
closeBlockBefore(pos);
} else if (HEADING_RE.test(line) || UL_ITEM_RE.test(line) || OL_ITEM_RE.test(line)) {
// Heading and list-item lines are each their own block in the
// renderer (`renderInline` runs per item / per heading), so they get
// a one-line inline-scan region rather than joining adjacent
// paragraphs. The marker chars themselves are not backticks, so we
// can scan the whole line without stripping the marker first.
closeBlockBefore(pos);
blockRegions.push([pos, lineEnd]);
} else {
if (blockStart === -1) blockStart = pos;
}
} else if (lineHasNewline && FENCE_CLOSE_RE.test(line)) {
inFence = false;
ranges.push([fenceStart, eol + 1]);
fenceStart = -1;
}
if (!lineHasNewline) {
// Trailing partial line — already accounted for above (either folded
// into the current paragraph region, or skipped because it starts with
// a block-starter pattern). Stop walking.
break;
}
pos = eol + 1;
}
// Flush any open paragraph region at end-of-buffer (no trailing newline).
if (!inFence) closeBlockBefore(buffer.length);
for (const [s, e] of blockRegions) {
INLINE_CODE_RE.lastIndex = 0;
const segment = buffer.slice(s, e);
let m: RegExpExecArray | null = INLINE_CODE_RE.exec(segment);
while (m !== null) {
ranges.push([s + m.index, s + m.index + m[0].length]);
m = INLINE_CODE_RE.exec(segment);
}
}
return { ranges, unclosedFenceStart: inFence ? fenceStart : null };
}
export function rangeContains(ranges: ReadonlyArray<Range>, p: number): boolean {
for (const [s, e] of ranges) {
if (p >= s && p < e) return true;
}
return false;
}