Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Persona: let Show one card succeed independently of unrelated library items

Open
  • Is something wrong?
#171 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, swift
Domain
desktop

Research direction

Start with Sources/StageKit/Persona.swift, especially showOverlayChecked and its candidate-loading limits, then read the prepared-session limits in Sources/StageKit/PersonaSession.swift. Use an isolated disposable library to test the acceptance cases; do not create or delete damaged fixtures in the real library. Done means one-card display and cycling remain independent of unrelated failures while bounded decoding and prepared multi-overlay limits are preserved.

Written by the indexing model from the issue text.

Description

Outcome and priority

P2 functional defect, source-confirmed. Showing one valid card should not fail because the saved library contains 33 cards, an unrelated missing image, or too much combined decoded imagery.

Evidence

Pinned to Preview 2.3.0, build 20260928054038, clean source 00be555139f87d4557f48fcffc132b8621c251a2; macOS 26.5.1 (25F80), built-in display. Verified through Copy build details in the running app and bundle metadata.

No large or damaged fixture was introduced into the user's library. This finding is source-confirmed; isolated fixture and installed reproduction remain acceptance work.

showOverlayChecked uses the active group's entire membership, or every saved item in All saved, as candidates. It rejects more than 32 at line 673, then decodes every candidate and applies a combined 256 MB limit at lines 675–683. Any unreadable candidate fails the whole launch. The archive itself permits 10,000 items and 1,000 group members. Prepared-session limits are therefore also blocking a valid one-card workflow.

Chosen behaviour

One-card launch validates and displays the requested card independently of unrelated items. Freeze candidate identities and appearance/source snapshots needed for predictable cycling, while keeping decoded image memory bounded to current/nearby use within the existing 256 MB decoded-image budget, accounting for retained and pending decoded buffers. Preserve immutable artwork guarantees without eagerly decoding the entire library.

If a requested Next/Previous candidate cannot load, retain the visible card and name the unavailable candidate safely. An oversized requested candidate fails safely under that same budget. A later Next can continue to other valid candidates; do not trap cycling permanently at one bad item. Validate replacement before removing the currently shown artwork.

Prepared multi-overlay limits and all-or-nothing preflight remain unchanged.

Acceptance

  • In an isolated disposable library, Show one card succeeds with 33 valid small items.
  • Selected valid A shows with an unrelated missing/unreadable B, and with combined decoded library size above 256 MB while A is small.
  • Requesting bad B leaves A visible, explains the specific failure and still permits moving to valid C.
  • An oversized requested candidate preserves A, stays within the decoded-image budget and does not trap later cycling.
  • Metadata/source snapshots preserve frozen appearance during library editing and bounded decoding does not regress memory limits.
  • Prepared multi-overlay sessions still enforce their existing limits for 8 groups, 8 copies, 32 candidates and image memory.
  • Native retest corrected installed one-card launch and cycling after isolated cases pass; record build details.
  • Do not create or delete a large damaged fixture in the user's real library.

Coordination

Second-pass request under #164. This is distinct from #157 movement and #158 voice appearance. Coordinate the frozen snapshot representation with the new shape and selected-versus-shown requests.

Dominant language
Swift
Stars
0
Forks
1
Avg merge
8h 5m
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ship-Work/workbench

All issues in Ship-Work/workbench

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.