Listings: supportingCards install with examples but stay out of the detail view (CS-12116)#664
Conversation
… detail view Query-based examples find their data by query, not linksTo, so the relationship walk in install/submission can never discover it. The new supportingCards field declares those cards explicitly. They flow through create, install (and therefore remix), use, and submission identically to examples; the only difference is the catalog detail page doesn't render them. Listing creation now classifies open cards by type: instances of the listed codeRef become examples, everything else becomes supportingCards. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Staging Submissions PreviewThis PR's content is pushed to the staging submissions realm: https://realms-staging.stack.cards/submissions/ Changed folders:
Updated at 2026-07-17 10:39:32 UTC for commit |
There was a problem hiding this comment.
Pull request overview
This PR introduces a new supportingCards relationship on catalog Listing cards to allow “data/dependency” cards to be installed/remixed/collected alongside examples without being rendered on the listing detail page.
Changes:
- Add
supportingCards(linksToMany(CardDef)) toListing. - Include
supportingCardsin install/use flows and submission snapshot collection. - Update listing creation to classify open cards into
examplesvssupportingCardsbased on whether they are instances of the selectedcodeRef.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| catalog-app/listing/listing.gts | Adds the supportingCards field to the Listing card schema. |
| commands/listing-install.ts | Installs/expands supporting cards alongside examples while keeping primary-example redirect behavior example-only. |
| commands/listing-use.ts | Copies supporting cards alongside examples into the install folder. |
| commands/collect-submission-files.ts | Includes supporting cards in the expanded submission snapshot set. |
| commands/listing-create.ts | Classifies open cards into visible examples vs invisible supporting cards using runtime type ancestry checks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const sourceCards = [ | ||
| ...((listing.examples ?? []) as CardAPI.CardDef[]), | ||
| ...((listing.supportingCards ?? []) as CardAPI.CardDef[]), | ||
| ]; | ||
| for (const card of sourceCards) { | ||
| await new CopyCardToRealmCommand(this.commandContext).execute({ | ||
| sourceCard: card, | ||
| targetRealm: realmUrl, | ||
| localDir, | ||
| }); | ||
| } |
There was a problem hiding this comment.
[Claude Code 🤖] Fixed in bea1e78 — the copy loop now dedupes by card id across the two fields. Install and submission were already safe because expandInstances tracks visited ids.
| let hasPrimaryExamples = (listing.examples?.length ?? 0) > 0; | ||
| let examplesToInstall = [ | ||
| ...(listing.examples ?? []), | ||
| ...(listing.supportingCards ?? []), | ||
| ]; |
There was a problem hiding this comment.
[Claude Code 🤖] Agreed on coverage, but the listing install/create/use acceptance modules are currently module.skip pending the skipped-catalog-tests re-enablement effort, so a new test here wouldn't execute. Supporting-card scenarios (copied on install, supporting-only listing leaves exampleCardId/selectedCodeRef unset) are on the list for when those modules are unskipped.
| // Open cards that are instances of the listed type become examples; other | ||
| // open cards (e.g. data a query-based example depends on) become | ||
| // supportingCards, which install but don't render in the listing detail. | ||
| private async classifyOpenCards( | ||
| openCardIds: string[] | undefined, |
There was a problem hiding this comment.
[Claude Code 🤖] Same constraint as the install-test note: the listing-create acceptance module is currently module.skip, so classification coverage (non-instance open card lands in supportingCards, load-failure falls back to examples) will be added when that suite is re-enabled. The host-side modal behavior is covered by tests in cardstack/boxel#5536.
Callers (e.g. the host create-listing modal) can now pass supporting cards explicitly instead of relying on type classification. Explicit ids are taken verbatim; a card also selected as an example stays an example. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A card linked as both an example and a supporting card was copied twice into the install folder. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
What
Adds a
supportingCardslinksToMany field to the Listing card. Supporting cards behave identically toexamplesin every command flow — create, install (and therefore remix), use, and submission collection — but the catalog listing detail page does not render them.Why
Query-based examples find their data by query, not
linksTo, so the relationship walk (expandInstances) in install/submission can never discover those cards automatically. Without them, an installed or remixed query-based example renders empty. Linking them as regularexamplesworks but pollutes the Examples tab with data cards that aren't showcases.supportingCardsdeclares them explicitly while keeping the detail view clean.How
catalog-app/listing/listing.gts— new@field supportingCards = linksToMany(() => CardDef). The detail template only iterates@fields.examples, so no template change is needed.commands/listing-install.ts— seedsexpandInstanceswith examples first, then supporting cards, so the primary example remains the first planned instance.exampleCardId/selectedCodeRefare only derived when primary examples exist, so a supporting-cards-only listing can't redirect remix navigation. Remix inherits all of this since it delegates copying to install.commands/listing-use.ts— copies supporting cards alongside examples into the same install folder.commands/collect-submission-files.ts— includes supporting cards in the submission snapshot so they land in catalog PRs.commands/listing-create.ts— open cards are now classified by type: instances of the listedcodeRef(including subtypes) becomeexamples; other open cards becomesupportingCards. Screenshot capture, AI example auto-fill, and the spec dependency walk stay primary-example-only. Cards that fail to load during classification fall back toexamples.Behavior change
Previously, every open card at creation time became a visible example. Now open cards that aren't instances of the listed type become invisible supporting cards. This is intentional — it stops supporting data cards from appearing in the Examples tab.
CS-12116
🤖 Generated with Claude Code