Generate expected alpha/beta content-page records from concrete entry values. Missing routes and client-only content stay distinct from readable server-rendered targets.
Pin the project version before copying configuration
SvelteKit's official static adapter guide describes adapter-static and prerendering. The current guide includes the SvelteKit 3 configuration change: configuration now belongs in vite.config.js, and the old svelte.config.js arrangement is no longer supported for that version.
That does not establish which version is installed in your project. Record the installed SvelteKit, adapter, Vite, and runtime versions; lockfile and source revision; configuration filename; and the version-matched configuration shape before implementation.
The authoring plan should name adapter-static and the intended page options. Choose their actual placement after confirming the installed version. Do not combine a current configuration snippet with an older project and report it as a tested setup.
When you build, record the command and its result with the installed versions and source revision.
Give the note routes distinct content
Use an index at /notes and a parameterized route /notes/[slug]. The original records are:
| Slug | Intended URL | Page title | Visible heading | Body text |
|---|---|---|---|---|
| alpha | /notes/alpha | Alpha note | Alpha note | Keep the green folder on shelf A. |
| beta | /notes/beta | Beta note | Beta note | Keep the blue folder on shelf B. |
The two note bodies are fictional and independently authored. They are short enough to inspect directly and distinct enough to catch a beta route accidentally rendering alpha.
The index visibly links only to alpha. It has no beta link. Neither note links to beta, and there are no other prerendered links, route-entry declarations, or discovery hooks that introduce beta in the linked-only case.
The expected content-page set is {/notes/alpha, /notes/beta}. Record the index separately. Client assets, stylesheet files, an index page, and a fallback do not increase the count of accepted note pages.
This fixture contains no database, authentication, forms, private data, server-only action, or remote content fetch. Those requirements would need a different static-build assessment.
Compare linked-only discovery with explicit entries
The official page-options documentation describes crawling prerenderable links and declaring entries for dynamic routes. A parameterized path needs concrete values; the route pattern alone does not enumerate every record.
In case L, specify prerendering and server rendering for the note pages, but provide no explicit beta entry. The index link introduces alpha. Under the fixture's deliberately complete discovery restrictions, beta remains undiscovered.
In case E, provide explicit dynamic-route entries for both slugs:
[
{ slug: 'alpha' },
{ slug: 'beta' }
]
This is the intended parameter list for a later entries function, not a native file or a completed configuration. Keep prerendering enabled and server rendering enabled for both pages. Confirm inheritance and any route-level overrides in the actual project.
An alternative version-supported configuration can list concrete prerender paths, but choose and record one mechanism for the test. Do not assume that a global entries setting and a route entries function have identical placement or behavior in every version.
Case E's target is two emitted, readable note pages. Explicit discovery supplies the missing parameter values; it does not prove that loading the records, building their pages, or emitting the files succeeded.
Specify URL-to-file mapping independently
An intended URL and its output filename are related but not interchangeable. Record the chosen base path, trailing-slash policy, adapter pages directory, and actual URL-to-file mapping.
For a trailingSlash policy of always, the adapter guide describes directory-index output. The authored note-file targets, relative to the configured pages directory, are notes/alpha/index.html and notes/beta/index.html. Confirm those actual paths with the installed version and build output. Static adapter path guidance
Preserve expected and actual outcomes by case
| Case | Discovery | Server rendering | Expected disposition |
|---|---|---|---|
| L | Alpha linked; beta omitted | Enabled | Beta coverage failure |
| E | Explicit alpha and beta | Enabled | Two readable note-page targets; actual checks pending |
| S | Explicit alpha and beta | Disabled | Shell output fails readable-content acceptance |
| F | Beta omitted; fallback considered | Record actual setting | Fallback does not satisfy beta's prerendered-page target |
Try the worked example
Build with alpha alone to identify missing beta. Add beta and build a complete expected manifest. Switch SSR off and keep coverage 2/2 while identifying the unreadable-shell failure. Native output and no-JavaScript checks remain necessary. A fallback file is not the missing prerendered note.
This creates an expected manifest locally, not a SvelteKit build, emitted HTML inspection, fallback host, or deployment.
Recreate this example
Build one complete self-contained HTML page for this task: build a route coverage and expected content manifest for the two-note static fixture.
Use these exact original practice data and worked expectations: Expect /notes/alpha and /notes/beta. Alpha has title “Alpha note” and body “Keep the green folder on shelf A.” Beta has title “Beta note” and body “Keep the blue folder on shelf B.” The index links only to alpha. With trailingSlash set to always, each proposed output is notes/slug/index.html.
Implement the following useful local interactions: Concrete entry-slugs field; SSR-on/off buttons; Build manifest. Linked alpha remains discovered, explicit beta adds coverage. Unknown/duplicate entry names held. Show missing targets, expected filenames and title/body; SSR off fails readable initial HTML. No actual build files or host claims. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. This creates an expected manifest locally, not a SvelteKit build, emitted HTML inspection, fallback host, or deployment. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the route-coverage manifest builder in NOS
Compare the manifest with fresh native output and inspect each note without JavaScript. Use the route explanation in NOS to review beta's discovery and its distinct blue-folder text, then revise eligible static acceptance instructions in visual editing mode before the next build.