Follow-up: remaining paper-* token gaps after #367/#373

[chiptus]

PR #373 (issue #367) moved role tokens (background, foreground, muted-foreground, ring, border) from .edition-view-scoped to global :root, and introduced a paper-* token family as a stopgap for light/white admin and shared shadcn chrome. Branch claude/implement-367-zrn4kp has the latest work (rebased onto current main after #373 merged), including a fix already pushed there for the Textarea focus ring and Tabs active state.

Remaining items surfaced during PR #373 review:

Needs a real fix (architectural)

• MarkdownText renders white-on-white in admin. src/pages/admin/ArtistsManagement/BulkEditor/TextareaCell.tsx renders populated artist descriptions through src/components/ui/markdown-text.tsx, whose prose-headings:text-foreground/prose-p:text-foreground/prose-code:text-foreground classes now resolve to white (the global --foreground). On the white admin card this text is unreadable. Can't just swap to paper-* globally — MarkdownText is also used on dark edition-view surfaces (SetInfoCard, IndividualArtistCard, SetDescription, InfoText, etc.) where text-foreground (white) is correct. Needs a variant/prop so the component can pick paper-* vs. default tokens by context.

Needs a small fix (missing border-paper-border)

Same root cause as the fixed items below — these paper-surfaced components still use an unqualified border, which resolves to the global translucent purple --border instead of the intended paper border:

• src/components/ui/alert-dialog.tsx:37 — AlertDialogContent's border needs border-paper-border alongside it.
• src/components/ui/alert.tsx:11 — the default Alert variant needs border-paper-border added.
• src/components/ui/toast.tsx:30 — the default Radix toast variant needs border-paper-border added.

Already fixed (no action needed, listed for completeness)

• Toast ToastClose white-on-white — fixed via paper-foreground.
• Textarea focus ring (ring-ring → ring-paper-ring) and Tabs active state (bg-background/text-foreground → paper-*) — fixed on branch claude/implement-367-zrn4kp (commit def1d36).

Branch

All follow-up work should build on claude/implement-367-zrn4kp, which is rebased onto current main.

[chiptus]

This was generated by AI during triage.

This issue has a mix of straightforward fixes and a design decision:

Straightforward fixes (ready for agent):

• Add border-paper-border to AlertDialogContent, Alert, and Toast variants

Design decision (needs maintainer input):

• The MarkdownText component issue requires deciding on how to add a variant/prop for switching between paper-* and default tokens. This architectural decision should be made before implementation.

Consider splitting this into two issues: one for the straightforward border fixes (ready-for-agent) and one for the MarkdownText variant design (ready-for-human).

---

Generated by Claude Code

[chiptus]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Fix remaining paper-* token gaps on light/white-chrome components left over from the role-token globalization (#367/#373)

Current behavior:
Several components render as light ("paper") surfaces against the app's now-global dark role tokens. Two classes of bug remain:

1. MarkdownText (used to render artist descriptions) hardcodes prose-*:text-foreground-style classes, which resolve to white in the global token scheme. On dark edition-view surfaces this is correct (white text), but on paper-surfaced admin contexts (e.g. an admin bulk-editor textarea cell) the same white-on-white result is unreadable. It has no way to render with the paper-appropriate foreground color in a paper context.
2. Several paper-surfaced shared components (an alert dialog, the default alert variant, the default toast variant) use an unqualified border class, which resolves to the global translucent purple --border instead of the intended paper border — a visible mismatch, though not full invisibility like case 1.

Desired behavior:
MarkdownText can render with paper-appropriate text tokens when used in a paper context (e.g. admin) while continuing to use the default (white) tokens on dark edition-view surfaces — callers control this, the component doesn't guess from its surroundings. The affected paper-surfaced components (alert dialog, default alert variant, default toast variant) render with the paper border token, matching their other paper-styled chrome, instead of the global dark border.

Key interfaces:

• MarkdownText's props gain a way to select paper vs. default text-token styling for its prose classes, defaulting to current (non-paper) behavior so dark-surface callers are unaffected.
• The affected components' border class needs the paper border token added alongside it, consistent with how other paper-surfaced components in the same family already do this.

Acceptance criteria:

• Populated artist descriptions render with readable (non-white) text when shown inside a paper-surfaced admin context (e.g. the admin bulk editor)
• MarkdownText on dark edition-view surfaces (set info card, artist card, set description, etc.) is visually unchanged
• The alert dialog, default alert variant, and default toast variant render with the paper border token, matching other paper-surfaced chrome
• No regression to the toast ToastClose fix, or the Textarea focus ring / Tabs active-state fixes already on claude/implement-367-zrn4kp

Out of scope:

• The body { bg-background text-foreground } latent-bug audit and the broader component list tracked in the companion issue (Audit remaining bg-background/text-foreground usages for white-on-white regressions (#367 follow-up) #377) — that's a separate, broader sweep
• Folding paper-* into themed tokens once light/dark theming (data-edition-theme) lands — paper-* is an intentional interim stopgap

---

Generated by Claude Code

[chiptus]

This was generated by AI during the autonomic fix-worker firing.

Triage Notes

What we've established so far:

• This issue is a follow-up to Admin tokenization: pull admin surfaces onto the role tokens #367/feat(admin): migrate admin surfaces onto role tokens #373, which introduced a paper-* token family (paper-background, paper-foreground, paper-border, paper-ring, paper-muted-foreground) as a stopgap for light/white admin and shared shadcn chrome.
• feat(theme): flip app to festival v2 identity #383 ("feat(theme): flip app to festival v2 identity"), merged 2026-08-25 — two days after feat(admin): migrate admin surfaces onto role tokens #373 and before this issue's last update — removed the entire paper-* token system. Confirmed against current main: grep -rn "paper" --include="*.css" --include="*.ts" --include="*.tsx" across the repo returns zero matches, and tailwind.config.ts has no paper entries at all.
• The specific files this issue calls out (alert-dialog.tsx, alert.tsx, toast.tsx) now style via border + bg-popover text-popover-foreground, not the paper tokens described here. MarkdownText/TextareaCell still exist, but the "white admin card vs. dark edition-view" framing this issue is built on may no longer match the current (single, v2) theme.
• The branch this issue says to build on, claude/implement-367-zrn4kp, is stale: its merge-base with main is ddfa3eb (the feat(admin): migrate admin surfaces onto role tokens #373 commit itself) — 356 files and ~4,600/13,000 lines behind current main. It isn't usable as a base as written.

What we still need from you (@chiptus):

• Does the white-admin-vs-dark-edition-view color split (and the paper-* token architecture) still apply after feat(theme): flip app to festival v2 identity #383's theme flip, or did that PR fold admin surfaces into the unified v2 theme? This decides whether the issue's premise still holds.
• If a real readability/contrast bug remains today (e.g. MarkdownText prose classes, or borders on light-surfaced components), can you confirm which components exhibit it against current main — the paper-* class names this issue cites no longer exist to search for, so it can't be re-derived from the code alone.
• Should this be closed as superseded by feat(theme): flip app to festival v2 identity #383 (with a fresh issue filed against the current theme if a bug remains), or re-scoped in place against the current token set?

Routing to needs-info pending your read on the above.

---

Generated by Claude Code

[chiptus]

admin is already with the v2 colors themes, just need to clear the paper tokens

if paper is not exist in this codebase, so yes, please close

[chiptus]

I see it only in docs/design/edition-color-vocabulary.md, so let's remove them from there