Bug fixes

[MaryWylde]

No description provided.

[github-actions]

Claude finished @MaryWylde's task in 6m 28s —— View job

---

Review complete

Tasks

• Gather context (PR diff, changed files, AGENTS.md conventions)
• Review correctness & React best practices
• Review TypeScript quality
• Check project conventions (AGENTS.md)
• Check accessibility & UX
• Check security
• Check styling / SCSS hygiene
• Post inline comments for specific issues
• Post final summary

Summary

This is a well-scoped bug-fix batch touching the library tag-scoping/create-flow, the UXCAT calendar reminder (replacing react-icalendar-link with a hand-rolled RFC 5545 .ics builder + getSlimBiases), modal scroll clipping, and some widget/CSS polish. Overall quality is high — the diffs are heavily commented with the why, and several changes are genuine security/correctness fixes worth calling out:

• src/api/library/tag/getTagsList.ts now requires userId and filters server-side (filters[user][id][$eq]), refusing to fall back to the unscoped /api/tags list. This closes a real cross-account tag leak — all 5 call sites (Sidebar.tsx, AddObjectModal.tsx) were updated consistently.
• src/uxcore/lib/ics.ts is a solid, dependency-free .ics builder — correct RFC 5545 line folding by UTF-8 octet count (matters for Cyrillic SUMMARY/DESCRIPTION), text escaping, and a deterministic UID so re-downloads update rather than duplicate. getEventWindow/buildICS are pure and SSR-safe; downloadICS's document/URL.createObjectURL use is correctly confined to a click handler, not module scope.
• getSlimBiases (src/uxcore/api/biases.ts) fetches only the fields UXCAT actually reads (number/title/description/slug/mentionedQuestionsIds) — I traced every consumer now reachable via _app.tsx's new uxCoreData wiring (QuestionAnalyse, OngoingLayout, uxcat/test-result.tsx) and confirmed none of them dereference fields outside that slim set (e.g. UXCoreModalMobile, which does need usage/usageHr, is only used on /uxcore/[slug], which stays on the untouched null uxCoreData path — no schema/data concern here, this is a fetch-shape optimization, not a UX Core schema change).
• The QuestionAnalyse.tsx effect dependency fix ([] → [uxCoreData]) is correct: uxCoreData was previously hardcoded null in _app.tsx, so this effect never ran; it's now real and stable (set once), so no re-render loop risk.

Issue found (inline comment posted):

• StepIndicator.module.scss:106 — the new width: 79.5% over-constrains the absolutely-positioned .connector alongside left: 46px; right: 46px, so right gets silently recomputed per CSS spec and the symmetric circle-to-circle anchoring the adjacent comment describes breaks on viewport widths other than whatever this was tuned against.

Minor / non-blocking:

• react-icalendar-link is no longer imported anywhere (CalendarItems.tsx now uses the new ics.ts + a <button>) but is still listed in package.json:68 — worth an unyarn remove in a follow-up.
• Header.tsx and Home.tsx both independently added an identical hasLibrary/getMyLibrary(accountData.id) effect — same request fires twice when a logged-in user with a library hits the homepage. Not wrong, but a shared useHasLibrary() hook would avoid the duplication.
• Sidebar.tsx's tag-list refetches now pass accountData?.id, which is correct for the owner's own tags, but note it also fires (harmlessly) on visitor page loads since it's unconditional in the mount effect — the result is just unused there (displayedTags uses libraryTags for non-owners).

No SSR/hydration issues, no dangerouslySetInnerHTML/XSS surface, no App Router or forbidden-dependency violations, no barrel or import-order issues spotted.

Not run: no lint/typecheck script exists in package.json, and node_modules isn't installed in this environment, so I reviewed manually rather than via ESLint/tsc/build. Worth a CI check before merge if not already covered elsewhere.

[github-actions]

width: 79.5% over-constrains this absolutely-positioned element alongside left: 46px / right: 46px. Per CSS 10.3.7, when left, right, and width are all non-auto on an absolutely positioned box, right is recomputed from left + width and effectively ignored — so the symmetric "46px = circle + gap on each side" anchoring the comment above describes no longer holds. On any viewport where the parent width isn't the exact one this 79.5% was tuned against, the right end of the line will drift off the 46px anchor (and vice versa for left in RTL). Recommend dropping the width line (letting left/right alone determine the box) or removing right if width is the intended fix, and updating the comment either way.

Fix this →