Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/design/README.md`:
- Line 76: The README entry for slides-pasteboard.md incorrectly calls the
design "fixed margin"; update that table row to describe the implemented
"variable pasteboard" approach (reference slides-pasteboard.md) by replacing
"fixed margin around the slide" with wording like "variable pasteboard — sized
from the surrounding empty area so off-slide shapes remain visible,
hit-testable, selectable; renderer translates origin, overlay stays at slide
rect, ruler/thumb unchanged" and ensure the wording aligns with the task doc
20260610-slides-pasteboard-todo.md which documents the move away from
fixed-margin behavior.

In `@docs/design/slides/slides-pasteboard.md`:
- Around line 156-157: The sentence claiming "the shadow is painted into the
canvas" is incorrect; update the sentence to state that the shadow is not
painted into the canvas but is applied as a CSS box-shadow on the slideElevation
element. Change the text referencing canvas.style.boxShadow to instead reference
slideElevation's CSS box-shadow behavior and, if helpful, cite the related
implementation in slides-view.tsx (see drawSlide and the comment "Painting the
elevation in CSS — rather than as canvas paint inside `drawSlide`") to ensure
consistency with lines 113–115 and the slideElevation usage.

In `@docs/tasks/active/20260610-slides-pasteboard-todo.md`:
- Around line 78-80: The risk statement is incorrect: the drop shadow was not
moved into the canvas but remains as a CSS box-shadow applied to the
slideElevation element; update the doc text to state that the drop shadow and
hairline are NOT painted into the canvas and instead live as a CSS box-shadow on
slideElevation (see slides-view.tsx and the slideElevation element) and adjust
the sentence that currently reads "Drop shadow now painted into canvas (was CSS
`box-shadow`)" to reflect this correct behavior.

In `@packages/frontend/src/app/slides/slides-view.tsx`:
- Around line 707-710: The early return when sameSlide and sameCanvas skips
updating the ruler origin; before returning, explicitly resync the ruler scroll
using the existing routine that updates ruler origin based on
scrollLeft/scrollTop (i.e., call the function you already use to update
rulers/scroll origin) so the ruler state is corrected even when hostW/hostH and
canvasFullW/canvasFullH are unchanged; apply the same change to the other
identical check later (the block around the second sameSlide/sameCanvas check).
- Around line 697-706: The pasteboard growth logic currently expands
nextCanvasW/nextCanvasH whenever either axis is smaller than the viewport, which
allows one-axis-only pasteboard at absolute zoom; change the calculation so you
only grow the canvas to the scrollRect size when the view is in Fit zoom (e.g.
guard the Math.max calls by the Fit mode check — use your app's Fit detector
such as isFitZoom() or zoomMode === 'Fit'); compute nextCanvasW = isFit ?
Math.max(nextW, Math.floor(scrollRect.width)) : nextW and likewise for
nextCanvasH, and keep nextOffsetX/nextOffsetY derived from those guarded canvas
sizes so offsets remain correct.

---

Nitpick comments:
In `@docs/design/slides/slides-pasteboard.md`:
- Line 26: Replace the phrase "empty space" with "space" in the sentence
containing "to fill `scrollHost`. Whatever empty space sits between the slide"
inside slides-pasteboard.md; update that fragment so it reads "...to fill
`scrollHost`. Whatever space sits between the slide" to remove the redundancy.
- Line 67: Replace the bare fenced code blocks (the triple-backtick blocks used
for diagrams) with language-specified fences so the linter can apply proper
rendering; for each diagram block that currently uses ``` change it to a fenced
block with a language specifier such as ```text or ```plaintext so the diagram
content is annotated and will get syntax highlighting and satisfy the markdown
linter.

In `@packages/slides/src/view/editor/editor.ts`:
- Around line 1248-1260: Add a regression test that verifies the slide-offset
coordinate contract by exercising a non-zero offset and ensuring mappings and
hit-testing remain aligned: in the editor unit tests create an Editor instance
(or the test harness used by existing editor tests), call setSlideOffset(x, y)
with non-zero values, then invoke clientToLogical(clientX, clientY) and assert
the returned logical coordinates equal the expected values given the offset;
also exercise an off-slide hit-test or a simple selection/drag scenario (e.g.,
hitTest or the selection logic used in tests) to confirm hit results respect the
offset. Reference the setSlideOffset and clientToLogical methods (and any
off-slide hit-testing helper like hitTest or selection/drag handlers) so the
test guards against regressions in the mapping math.