cms: a new FastStore section cannot be seen at all until it is authored in the shared production CMS

[JonasJesus42]

Context

Built five sections for the Electrolux /cuida home. The question "can I see this locally before shipping it?" has no answer today, and that shapes the whole workflow badly.

Why

FastStore v4 has no local content source. discovery.config.js takes:

contentSource: { type: "CP", project: "electrolux" }

and @faststore/core/src/server/cms/index.ts unconditionally instantiates a remote client from it:

export const clientCMS = new ClientCMS({
  workspace: config.api.workspace,
  tenant: config.api.storeId,
  builder: (config.contentSource as Record<string, string>)?.project ?? 'faststore',
  host: sanitizeHost(new URL(getStoreURL()).origin),
})

There is no type: "local", no filesystem fallback, no fixture path. yarn dev renders whatever the production CP currently says.

The consequence

A section is invisible until all of this is done, in this order, against shared infrastructure:

1. schema uploaded to the account (see cms: doctor reports the gap it cannot close — no parity cms schema push #343 — not scriptable)
2. entry authored in the CP
3. only then does it render — local or published

So the first time anyone sees a new section is on the real page, in the real CMS, with real content. There is no way to check spacing, a breakpoint, a dark band, or whether an overlay lands where you meant it, without first committing content to production. For a migration tool whose whole job is visual fidelity, that is a rough inner loop — and it means every layout iteration costs a CP write.

It also blocks parity section --computed-styles as a pre-merge check: you cannot diff a candidate section against the legacy one until the candidate exists in production content.

Possible shapes

Roughly in order of effort:

1. parity cms preview <entry.json> — serve the site locally with one pulled entry file swapped in for the remote fetch. parity cms pull already writes entries in the authoring shape with entryId/contentType/branch/baseHash, so the file format exists; this is the read side of the same thing.
2. A section harness — render a single registered section with props from a JSON fixture, no CMS at all. Enough for spacing/breakpoint/token work, which is most of it.
3. Push for a local content source upstream in @faststore/core — the correct fix, the slowest.

(2) alone would have covered every iteration in this batch.

Repro

# add a section to src/components/index.tsx and cms/faststore/
yarn dev
# open any page — there is no way to make it appear