Persona: let Show one card succeed independently of unrelated library items
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Swift
- Stelle
- 0
- Fork
- 1
- Merge medio
- 8h 16m
- PR unite (30g)
- 210
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Ship-Work/workbench
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue help wanted
Difficoltà 2/5 Mezza giornata Idoneità per principianti 74/100
Ship-Work/workbench#29 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Ship-Work/workbench
Issue simili
-
swift.md: `Date(myString, strategy: .iso8601)` example omits `try` — the initializer is throwingAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
core: RAC_LLM_OPTIONS_DEFAULT.min_p disagrees with the IDL's annotated defaultForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug core p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
RunanywhereAI/runanywhere-sdks#1083 ·
I maintainer di solito rispondono entro 5 giorni
-
bug/fix needs: triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
capawesome-team/capacitor-firebase#1054 ·
I maintainer di solito rispondono entro 1 giorno
-
area: docs eco: swift good first issue help wanted lane: free-agent roadmap size: XS type: docs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
arminazimi/evergreen#441 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno