Default new realms to a Workspace index card

[lukemelia]

What

create-realm.ts seeds every new realm's index.json. Point it at Workspace instead of CardsGrid, so a newly created realm opens to the Workspace experience. This is the "replace CardsGrid" keystone — the card, the recognition, and the migration are only meaningful once the default flips.

CardsGrid stays available for existing/bespoke realms; only the default for freshly created realms changes.

Depends on

• The Workspace card must exist (so a new realm's index resolves).
• The publish handler + prerender fast-path must recognize Workspace (so a new realm still gets the prerendered default-index treatment on publish, and the realm-server tests that assumed a CardsGrid default stay correct). This PR is stacked on that recognition branch.

Blast radius (audited)

The realm-server test helper createRealm seeds its own fileSystem, so it does not go through this handler — most realm-server tests are unaffected. Of the tests that hit the real /_create-realm endpoint:

• index-responses and realm-lifecycle seed their own index.json → unaffected.
• realm-routing's deadlock guard uses a mock fixture, not a real create+prerender → unaffected (comment now slightly historical).
• publish-unpublish creates its source realm via the endpoint and did rely on the default being CardsGrid → updated here: the default-index case now exercises Workspace, and the explicit case is repurposed to cover the legacy CardsGrid path, so both recognized defaults stay tested; the bespoke-index negative case is unchanged.

Also fixed software-factory comments that described the old CardsGrid default (the factory overwrites the index regardless, so it's behavior-neutral).

Test plan

realm-server ember-tsc, eslint, prettier clean. Not run locally — the realm-server publish/create suites need test-pg + their own prerender, which isn't wired up in this session; they run in CI. Given the default flip is behaviorally significant, CI's full realm-server + matrix suites (which create realms via /_create-realm) are the real confirmation. The publish test changes mirror the existing passing tests' structure.

🤖 Generated with Claude Code

[github-actions]

Host Test Results

122 tests   122 ✅  2m 30s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit 675d1d1.

Realm Server Test Results

    1 files  ±0      1 suites  ±0   13m 6s ⏱️ +3s
1 934 tests ±0  1 934 ✅ ±0  0 💤 ±0  0 ❌ ±0 
2 013 runs  ±0  2 013 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 675d1d1. ± Comparison against earlier commit 1d5c822.

[lukemelia]

[Claude Code 🤖] Code review (high effort) — PR #5587

The diff itself is correct and internally consistent: the create-realm.ts adoptsFrom swap is the one behavioral change, and the realm-server publish tests were updated in step (the bespoke-index case correctly uses assert.notStrictEqual(..., true), and the publish handler's isDefaultRealmIndexAdoption already recognizes both CardsGrid and Workspace on the base branch).

The findings are about the downstream reach of flipping the default index — which is also why CI is red:

1. (inline) Acceptance tests that assert the created realm's CardsGrid sidebar weren't updated — matrix/tests/create-realm.spec.ts:35 fails deterministically, and likely siblings.
2. (inline) Making the heavy Workspace card the default index broadens where its module graph is loaded — plausibly behind the Host Memory Baseline regression and the 'browser closed' crashes in the matrix shard.

Minor (not blocking): realm-server/tests/realm-routing-test.ts:190's comment ("The CardsGrid in index.json fires _federated-search") is now stale — the seeded index is a Workspace. The test should still pass if Workspace fires the same federated search during its prerender, but the comment should be refreshed.

CI status: Matrix Client Tests (1,3)/(3,3) + Matrix Playwright fail — create-realm.spec.ts is the deterministic, PR-caused one; Host Memory Baseline fails (see finding 2).

[lukemelia]

[Claude Code 🤖] Migrated the matrix tests that assumed a CardsGrid index — pushed in ed3f3c1:

• Added data-test hooks to the Workspace card (index root + Home/Library/Activity tabs; it had none).
• showAllCards now handles both index types (CardsGrid "All Cards" filter, or the Workspace Library tab — same live CardsGridLayout grid).
• Fixed create-realm.spec.ts (asserts the Workspace index rendered) and live-cards.spec.ts test 1 (asserts the shared cards grid).

Two items intentionally left for you (not fixed):

1. live-cards.spec.ts "can specify a card by URL in the card chooser" — this one clicks [data-test-create-new-card-button] (CardsGrid's AddButton). The Workspace index doesn't render that button; its create affordances are the per-type rail + and a "New card" welcome button. So it's not a selector swap — it needs either a create-card affordance added to the Workspace index or a reworked flow. Decide which fits the product intent.
2. correctness-checks.spec.ts "browser has been closed" — this reads as memory pressure from loading the ~4000-line Workspace card as the default index (see review finding far-match animate Sprite C moving between animation contexts in Basic example #2), not a selector issue. Worth confirming the prerender/host-test memory impact before this lands.

I couldn't run the matrix suite locally (needs the full synapse/docker stack), so the pushed fixes are CI-verified — watch the next Matrix Client Tests run.

[lukemelia]

[Claude Code 🤖] Update — the card-chooser coupling is fixed (1781bfe), superseding item 1 in my earlier note.

The [data-test-create-new-card-button] (CardsGrid's AddButton) was used to open the card chooser in live-cards, skills, and tools — all of which broke on the Workspace index. Rather than depend on any index affordance, they now open the chooser via the operator-mode New button ([data-test-new-file-button] → "Choose a card type…"), which calls the same chooseCard() and pops the same modal. skills.spec.ts:352 and tools.spec.ts (30/87/141/296) were failing on this in shard 3 too and are covered by the same swap.

Still open:

• correctness-checks.spec.ts "browser has been closed" — reads as memory pressure from the heavy Workspace card as default index (review finding far-match animate Sprite C moving between animation contexts in Basic example #2), not a selector issue.
• registration-with-token.spec.ts:50 failed in shard 3 but is unrelated to the index change — likely a flake; worth a re-run to confirm.

All CI-verified on the next Matrix run.

[habdelra]

[Claude Code 🤖] This review focused on how flipping the default realm index lands downstream — the seeding path, the recognizer it depends on, the acceptance-test migration, and the memory/render cost — since the behavioral change itself is a two-line swap.

Bottom line: the core change is correct and well-covered; no blocking correctness issue in the diff. One new latent test-flake (inline on showAllCards), plus the memory question — now the only red CI signal — still needs a confirm-benign before merge.

What lands right

• The seed swap in create-realm.ts matches the base recognizer exactly: isDefaultRealmIndexAdoption (handle-publish-realm.ts:62-89) accepts both CardsGrid and Workspace, so a freshly created realm still gets includePrerenderedDefaultRealmIndex on publish. realm-index-boilerplate.ts already speaks "CardsGrid or Workspace." Nothing on the seeding path was left assuming CardsGrid.
• The publish suite is real regression coverage, not shape-only: the source realm is created through /_create-realm in beforeEach, so the "default Workspace index" test exercises the handler default rather than a hand-seeded fixture. All three cases stay covered — default Workspace → flag set, bespoke CardDef → flag not set (assert.notStrictEqual(..., true)), legacy CardsGrid → flag set.
• The showAllCards Library path is semantically equivalent to CardsGrid's "All Cards": Workspace's default everythingFilter returns all cards except Cards Grid/Workspace index instances, and every migrated caller asserts only non-index items, so the visible set matches. [data-test-cards-grid-cards] lives in the shared cards-grid-layout.gts, so the assertion holds against either index.
• The card-chooser rework is genuinely index-agnostic — the operator-mode New button → "Choose a card type…" calls the same chooseCard() the CardsGrid + did. The matrix migration is complete; no spec still references [data-test-create-new-card-button].

Findings

1. (inline, packages/matrix/helpers/index.ts) showAllCards swapped an auto-waiting .click() for a non-waiting .count(), so a slow index render makes it a silent no-op and the caller times out waiting for a grid that was never opened. Non-blocking, but it's a latent flake in the exact paths this change touches — see the thread for the mechanism and a one-line wait fix.
2. (non-blocking, needs a confirm) Making the heavier Workspace card the default index is the concern already open in the thread on create-realm.ts. Fresh signal in its favor: Host Memory Baseline is now green on the head commit, which softens the host-side worry. What remains is the matrix "browser has been closed" crash — Matrix Client Tests (1,3) and (3,3) are the only red checks on the head commit. Worth attributing that crash from the uploaded Playwright trace (memory-driven vs. the separate registration-with-token flake) before merging, since it's the last thing between this and green.
3. (minor, follow-up) packages/realm-server/tests/realm-routing-test.ts — the deadlock-guard comment still reads "The CardsGrid in index.json fires _federated-search…", but the seeded default is now Workspace. The test uses a mock fixture so it still passes; the comment is just historical and reads as describing current behavior.

Recommendations

1. Add the waitFor guard to showAllCards (finding 1) so the helper can't no-op under a slow render.
2. Confirm the matrix "browser closed" crash is not caused by the heavier default index before merge (finding 2); Host Memory Baseline being green is reassuring but not conclusive for the matrix runner.
3. Refresh the realm-routing-test.ts comment to name Workspace (finding 3).

---

Generated by Claude Code