mirror of
https://github.com/nexu-io/open-design.git
synced 2026-10-27 09:51:12 +01:00
* 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.
139 lines
5.9 KiB
TypeScript
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;
|
|
}
|