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/slides/slides-shapes.md`:
- Line 398: Add the missing OOXML alias mapping by inserting the alias entry
"homePlate -> pentagonArrow" into the OOXML alias table in slides-shapes.md so
the canonical alias list matches the roadmap; ensure the new row uses the same
table format and ordering/style as the other alias rows in the OOXML alignment
section.

In `@docs/tasks/active/20260517-pptx-unsupported-shapes-todo.md`:
- Around line 75-78: Update the bracket/brace note under the "Brackets render
via a single PathBuilder" paragraph to reflect current rendering: instead of
saying filled open paths "auto-close acceptably," state that for open-path kinds
the renderer skips applying fill (only stroke is used). Keep the existing
mention of using a single open path and the adj: corner radius note (percent of
min(w,h)/2, default 8333), but replace the sentence about auto-closing with an
explicit statement that fills are omitted for open-path bracket/brace shapes.
- Around line 5-6: Remove the embedded absolute local path that contains the
username from the task note (the /Users/... path shown in the diff) and replace
it with a sanitized sample or placeholder (e.g. <path/to/file>.pptx or
Downloads/YourFile.pptx) so the note is non‑identifying and portable; update the
sentence mentioning slide 7 to reference the sanitized filename/placeholder
instead of the original absolute path and keep the descriptive text about the
empty rotated centre shape unchanged.

In `@packages/slides/src/view/canvas/shapes/basic/left-bracket.ts`:
- Around line 48-55: The bracket handle currently ignores the shape's stored
radius and mis-maps pointer drags: update position to call
bracketCornerRadius(size, /*current radius value from shape data*/ ) instead of
passing undefined so the handle location reflects the actual radius; in apply,
compute the pointer-to-radius mapping using the same geometry as
bracketCornerRadius (use min(w,h) and half of that for the vertical scale)
rather than h/2, keep the DEF_BRACKET_RADIUS fallback when height is
non-positive, and clamp the resulting raw value into [0,50000] as before (refer
to position, bracketCornerRadius, insetAlongAxis, apply, and DEF_BRACKET_RADIUS
to locate the changes).

In `@packages/slides/src/view/canvas/shapes/basic/right-bracket.ts`:
- Around line 21-28: The bracket handle mapping uses the frame height only,
desynchronizing radius when the frame is non-square; update the position and
apply logic in the right-bracket shape so the handle is computed relative to the
geometry's min(width,height) basis: in position (function position) compute the
corner inset using bracketCornerRadius(size, undefined) and call insetAlongAxis
with that radius against the min of size.w and size.h (instead of size.h), and
in apply ({ h }, _start, pointer) replace h/2 bounds with (Math.min(w, h) / 2)
(use the geometry width/height min) when clamping pointer.y and when deriving
raw (fall back to DEF_BRACKET_RADIUS as before); reference bracketCornerRadius,
insetAlongAxis, position and apply to locate the changes.

In `@packages/slides/src/view/canvas/shapes/callouts/right-arrow-callout.ts`:
- Around line 67-86: The handle compute in apply can produce adj4 values that
place the handle past the body/head seam for deep heads; reproduce the same
dx1/seam calculation used in buildRightArrowCallout and clamp pointer.x against
w - dx1 before converting to the 0..100000 adj4 value: derive dx1 from the
current head/depth parameters (start[1], start[2]) using the same formula/build
helper as buildRightArrowCallout, compute maxX = Math.max(0, w - dx1), clamp x =
Math.max(0, Math.min(maxX, pointer.x)), then compute newA4 = maxX > 0 ?
Math.round((x / w) * 100000) (or divide by maxX if buildRightArrowCallout maps
over that range) and finally bound newA4 to 0..100000 as before so the handle
cannot enter the dead range.

---

Nitpick comments:
In `@packages/slides/test/view/canvas/shapes/basic/brackets.test.ts`:
- Around line 30-35: The rightBracket test lacks the explanatory geometric
comment present in leftBracket; add a brief comment in the it('rightBracket...')
block explaining why points (39,1) and (39,199) were chosen — i.e., they sit
just inside the bracket's carved top-right and bottom-right corners given
buildRightBracket({ w: 40, h: 200 }, [50000]) — so future readers understand the
geometric reasoning used to assert ctx.isPointInPath results for the
buildRightBracket path.