Found while addressing Copilot's QR slug-pick feedback in PR #3 (which fixed the same bug in src/api/qr.ts and src/mcp/server.ts).
The admin UI (src/client.ts) uses two different patterns to answer "which slug represents this link":
src/client.ts:1508 — link.slugs.find(s => s.is_primary) || link.slugs[0] ✓ (matches the canonical-redirect-target intent)src/client.ts:153, 250, 1130, 1166 — link.slugs.find(s => !s.is_custom) (picks the auto-generated slug specifically, ignoring is_primary)
After SlugRepository.setPrimary flips primary to a custom slug, or after a primary custom slug is disabled/removed (which auto-promotes the auto-slug back to primary), the two patterns return different rows. The four !s.is_custom call sites were likely written when "primary" and "auto-generated" were synonymous; they no longer are.
Question for the fix: should the four !s.is_custom sites switch to s.is_primary, or do those specific UI paths genuinely need "the original system slug" regardless of primary? The intent is unclear from the surrounding code — pinning down which is which needs a UX-level decision before the code change.
No regression in PR #3 — those four sites only affect admin UI rendering, not the QR API or redirect path.
Found while addressing Copilot's QR slug-pick feedback in PR #3 (which fixed the same bug in
src/api/qr.tsandsrc/mcp/server.ts).The admin UI (
src/client.ts) uses two different patterns to answer "which slug represents this link":src/client.ts:1508—link.slugs.find(s => s.is_primary) || link.slugs[0]✓ (matches the canonical-redirect-target intent)src/client.ts:153, 250, 1130, 1166—link.slugs.find(s => !s.is_custom)(picks the auto-generated slug specifically, ignoringis_primary)After
SlugRepository.setPrimaryflips primary to a custom slug, or after a primary custom slug is disabled/removed (which auto-promotes the auto-slug back to primary), the two patterns return different rows. The four!s.is_customcall sites were likely written when "primary" and "auto-generated" were synonymous; they no longer are.Question for the fix: should the four
!s.is_customsites switch tos.is_primary, or do those specific UI paths genuinely need "the original system slug" regardless of primary? The intent is unclear from the surrounding code — pinning down which is which needs a UX-level decision before the code change.No regression in PR #3 — those four sites only affect admin UI rendering, not the QR API or redirect path.