packages/docs/demo.ts (1)

133-137: Harden toggle handler: use closest() and textContent.

Lines 135-137 work today, but closest('button') is more robust than direct tagName checks, and textContent avoids innerHTML assignment.

🔧 Suggested patch

 document.getElementById('log-panel-toggle')!.addEventListener('click', (e) => {
   // Don't toggle when clicking buttons inside the header
-  if ((e.target as HTMLElement).tagName === 'BUTTON') return;
+  if ((e.target as HTMLElement).closest('button')) return;
   logPanel.classList.toggle('collapsed');
-  toggleArrow.innerHTML = logPanel.classList.contains('collapsed') ? '▼' : '▲';
+  toggleArrow.textContent = logPanel.classList.contains('collapsed') ? '▼' : '▲';
 });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/docs/demo.ts` around lines 133 - 137, Update the click handler
attached to document.getElementById('log-panel-toggle') to use (e.target as
HTMLElement).closest('button') instead of checking tagName, and set
toggleArrow.textContent rather than toggleArrow.innerHTML; specifically change
the early-return check in the anonymous listener to use closest('button') and
replace the assignment that sets the arrow glyph using innerHTML with a
textContent assignment so the toggle is more robust and avoids injecting HTML.

packages/docs/index.html (1)

87-93: Add keyboard/ARIA semantics to the log-panel toggle.

Line 87 introduces a clickable <div> for collapsing, but it currently lacks keyboard accessibility and expanded-state semantics.

♿ Suggested improvement

-    <div class="log-panel-header" id="log-panel-toggle">
+    <div
+      class="log-panel-header"
+      id="log-panel-toggle"
+      role="button"
+      tabindex="0"
+      aria-expanded="true"
+      aria-controls="event-log"
+    >

+    .log-panel-header:focus-visible {
+      outline: 2px solid `#8ab4f8`;
+      outline-offset: -2px;
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/docs/index.html` around lines 87 - 93, The log-panel header
currently uses a plain <div id="log-panel-toggle"> (with child <span
id="toggle-arrow"> and target <div id="event-log">) but lacks keyboard/ARIA
semantics; update the markup and/or script so the toggle is keyboard-accessible
and announces state: either replace the div with a <button> or add role="button"
and tabindex="0" to `#log-panel-toggle`, add aria-expanded="true|false" on
`#log-panel-toggle` and aria-controls="event-log", and ensure the toggle handler
(the function that collapses/expands the log, referenced by the click listener
on `#log-panel-toggle`) also listens for keydown of Enter/Space to trigger the
same toggle and updates `#toggle-arrow` and aria-expanded accordingly.

packages/docs/test/view/incremental-layout.test.ts (1)

38-46: Consider adding a test for cache invalidation when block is removed.

The current tests cover dirty block recomputation well, but there's no test verifying behavior when a block is removed from the blocks array between layout calls. This is a structural change scenario that could reveal cache staleness issues.

💡 Suggested additional test case

it('does not crash when cached block is removed', () => {
  const blocks = [makeBlock('Hello'), makeBlock('World'), makeBlock('Foo')];
  const first = computeLayout(blocks, mockCtx(), 500);
  // Remove middle block
  blocks.splice(1, 1);
  const second = computeLayout(blocks, mockCtx(), 500, new Set(), first.cache);
  expect(second.layout.blocks.length).toBe(2);
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/docs/test/view/incremental-layout.test.ts` around lines 38 - 46, Add
a test that verifies computeLayout handles cache entries for blocks that were
removed between runs: create three blocks via makeBlock, call computeLayout to
get first.cache, remove the middle block (blocks.splice(1,1)), then call
computeLayout(blocks, mockCtx(), 500, new Set(), first.cache) and assert the
resulting layout has length 2 and no crash; include this under a descriptive
it('does not crash when cached block is removed') and reference computeLayout,
first.cache, and blocks so cache invalidation behavior for removed blocks is
exercised.

packages/docs/src/view/text-editor.ts (1)

175-194: Consider adding markDirty for composition preview updates.

During active composition, the document is modified (lines 181-186) but no dirty tracking is triggered. If the layout cache exists, the preview text may render with stale layout information.

This is lower priority than the handleCompositionEnd fix since composition previews are transient, but for consistency with the incremental layout system, consider marking the block dirty here as well.

♻️ Optional fix

       this.composition.currentLength = newText.length;
       this.cursor.moveTo({
         blockId: startPosition.blockId,
         offset: startPosition.offset + newText.length,
       });
+      this.markDirty(startPosition.blockId);
       this.requestRender();
       return;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/docs/src/view/text-editor.ts` around lines 175 - 194, When handling
an active composition in the composition branch (the block using
this.composition, this.doc.deleteText/insertText,
this.composition.currentLength, this.cursor.moveTo, this.requestRender), ensure
you also mark the affected block dirty so the incremental layout cache is
updated for the transient preview; call the appropriate markDirty API (e.g.,
this.markDirty or the layout manager's markDirty) with the composing block id
(startPosition.blockId) after modifying the document and before requestRender so
the preview re-layout uses fresh layout data.