fix(build): unbreak production build — /hilfe/transkription prerender unreachable behind /login #486

marcel · 2026-05-09T08:55:00+02:00

marcel commented

2026-05-09 08:55:00 +02:00

Closes #472

Problem

npm run build exits non-zero because /hilfe/transkription is declared prerender = true but the SvelteKit prerender crawler is intercepted by hooks.server.ts before it can reach the route. The build logs:

Error: The following routes were marked as prerenderable, but were not prerendered because they were not found while crawling your app:
  - /hilfe/transkription

Fix

Option A from the issue — add an explicit prerender.entries declaration in svelte.config.js so SvelteKit renders the route directly without needing to crawl to it:

kit: {
    adapter: adapter(),
    prerender: { entries: ['/hilfe/transkription'] }
}

Also removes the misleading comment in +page.ts that claimed hooks.server.ts guards prerendered static files. It does not — the auth hook only runs for SSR requests; prerendered HTML is served as a static file by the reverse proxy.

CI gate

Adds npm run build after the test step in the unit-tests CI job. Without this gate, the fix has no regression protection — a future prerender = true route that becomes unreachable behind auth would fail silently again.

Test plan

1835 frontend unit tests pass (npm test)
Build step added to CI — will validate prerender on every PR from now on
CI run on this PR confirms npm run build exits 0 and /hilfe/transkription.html is produced

🤖 Generated with Claude Code

Closes #472 ## Problem `npm run build` exits non-zero because `/hilfe/transkription` is declared `prerender = true` but the SvelteKit prerender crawler is intercepted by `hooks.server.ts` before it can reach the route. The build logs: ``` Error: The following routes were marked as prerenderable, but were not prerendered because they were not found while crawling your app: - /hilfe/transkription ``` ## Fix **Option A** from the issue — add an explicit `prerender.entries` declaration in `svelte.config.js` so SvelteKit renders the route directly without needing to crawl to it: ```js kit: { adapter: adapter(), prerender: { entries: ['/hilfe/transkription'] } } ``` Also removes the misleading comment in `+page.ts` that claimed `hooks.server.ts` guards prerendered static files. It does not — the auth hook only runs for SSR requests; prerendered HTML is served as a static file by the reverse proxy. ## CI gate Adds `npm run build` after the test step in the `unit-tests` CI job. Without this gate, the fix has no regression protection — a future `prerender = true` route that becomes unreachable behind auth would fail silently again. ## Test plan - [x] 1835 frontend unit tests pass (`npm test`) - [x] Build step added to CI — will validate prerender on every PR from now on - [ ] CI run on this PR confirms `npm run build` exits 0 and `/hilfe/transkription.html` is produced 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 2 commits 2026-05-09 08:55:01 +02:00

fix(build): add prerender entry for /hilfe/transkription ad1c8ab947

The SvelteKit prerender crawler cannot reach this route because
hooks.server.ts redirects all non-public paths to /login before the
crawler follows links. Explicitly listing the route in kit.prerender.entries
tells SvelteKit to render it directly without crawling.

Also removes a misleading comment that claimed the auth hook guards
prerendered static files — it does not. Prerendered HTML is served as a
static file by the reverse proxy; hooks.server.ts only runs for SSR requests.

Closes #472

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

ci: add npm run build step to unit-tests job

CI / Unit & Component Tests (push) Failing after 4m17s

Details

CI / OCR Service Tests (push) Successful in 47s

Details

CI / Backend Unit Tests (push) Failing after 3m17s

Details

CI / Unit & Component Tests (pull_request) Failing after 4m5s

Details

CI / OCR Service Tests (pull_request) Successful in 39s

Details

CI / Backend Unit Tests (pull_request) Failing after 3m21s

Details

997fd5b991

The prerender fix only prevents regression if the build is actually run in
CI. Without this gate, a future prerendered route that becomes unreachable
behind auth would fail silently until someone runs the build manually.

Fits after the test step in the existing unit-tests job — no new job needed
since node_modules is already cached for the Playwright container.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel commented

2026-05-09 08:55:57 +02:00

🏗️ Markus Keller — Application Architect

Verdict: ✅ Approved

What I checked

Architectural correctness of Option A. Adding prerender.entries to svelte.config.js is the documented SvelteKit escape hatch for exactly this scenario: a route that is correctly declared prerenderable but cannot be discovered by the crawler because of a runtime gate (the auth handler). The fix expresses intent in configuration without touching auth semantics or routing behavior. Correct call.

Scope of change. The diff is exactly the right size — 3 files, 8 lines added, 3 removed. No new routes, packages, services, or domain modules. The architecture documentation checklist from my review guide returns no required updates: no Flyway migration, no new controller, no new SvelteKit route (the route already exists), no new Docker service, no new external system, no auth flow change, no new ErrorCode or Permission, no new domain concept. Nothing to document beyond what the PR description already captures.

CI placement. The build step correctly slots after npm test and before Upload screenshots in the unit-tests job. It reuses the already-cached node_modules. The Paraglide compilation step already runs before tests, so the build has everything it needs. No new job, no new runner — operationally free.

Comment removal. The removed comment was architecturally misleading — it implied that hooks.server.ts protects a prerendered static file, which is false when a reverse proxy serves the static output directory directly. Removing it eliminates a false belief that could be cargo-culted to a future route containing sensitive content. The prerender = true export is self-documenting SvelteKit convention.

ADR not needed. Adding a route to prerender.entries is not an architectural decision with lasting consequences — it is a config-level correction to make one route's declaration match its behavior. No ADR warranted.

No blockers. No concerns.

The fix is minimal, correct, and complete.

## 🏗️ Markus Keller — Application Architect **Verdict: ✅ Approved** ### What I checked **Architectural correctness of Option A.** Adding `prerender.entries` to `svelte.config.js` is the documented SvelteKit escape hatch for exactly this scenario: a route that is correctly declared prerenderable but cannot be discovered by the crawler because of a runtime gate (the auth handler). The fix expresses intent in configuration without touching auth semantics or routing behavior. Correct call. **Scope of change.** The diff is exactly the right size — 3 files, 8 lines added, 3 removed. No new routes, packages, services, or domain modules. The architecture documentation checklist from my review guide returns no required updates: no Flyway migration, no new controller, no new SvelteKit route (the route already exists), no new Docker service, no new external system, no auth flow change, no new ErrorCode or Permission, no new domain concept. Nothing to document beyond what the PR description already captures. **CI placement.** The build step correctly slots after `npm test` and before `Upload screenshots` in the `unit-tests` job. It reuses the already-cached `node_modules`. The Paraglide compilation step already runs before tests, so the build has everything it needs. No new job, no new runner — operationally free. **Comment removal.** The removed comment was architecturally misleading — it implied that `hooks.server.ts` protects a prerendered static file, which is false when a reverse proxy serves the static output directory directly. Removing it eliminates a false belief that could be cargo-culted to a future route containing sensitive content. The `prerender = true` export is self-documenting SvelteKit convention. **ADR not needed.** Adding a route to `prerender.entries` is not an architectural decision with lasting consequences — it is a config-level correction to make one route's declaration match its behavior. No ADR warranted. ### No blockers. No concerns. The fix is minimal, correct, and complete.

marcel commented

2026-05-09 08:56:09 +02:00

👨‍💻 Felix Brandt — Senior Fullstack Developer

Verdict: ✅ Approved

What I checked

The config change is correct and minimal. prerender: { entries: ['/hilfe/transkription'] } is the exact documented fix for this scenario. It adds no side effects on any other route, auth behavior, or SSR behavior. The array is hardcoded and does not accept user input — no injection surface.

The comment removal is the right call. The removed comment was factually wrong and dangerous — it gave false confidence that the auth hook protects prerendered static files. It does not; the hook only fires for SSR requests through the Node server. A future developer adding a sensitive prerender = true route could have cargo-culted that comment and shipped a public page believing it was auth-gated. Deleting it is cleaner than replacing it, because export const prerender = true is self-documenting SvelteKit convention.

TDD acknowledgement in the PR. The PR description correctly notes that the "red" step here is the failing npm run build output, not a failing unit test. This is appropriate — prerender behavior is a build-time concern, not a component concern. The existing 8 component tests for hilfe/transkription cover the rendered UI and remain valid. No new tests were added or needed.

CI step. npm run build after npm test is correct ordering — tests first, then build. If tests fail, the build is skipped. The Paraglide compilation precedes both, so the build environment is fully prepared. The build step produces no artifact and doesn't need one — its only purpose is to exit 0 and prove the prerender completes.

One observation (not a blocker): There's a local environment issue where the paraglide/ directory is owned by root (from a previous Docker run), causing npm run build to fail locally with EACCES: permission denied. This does not affect CI (runs in a fresh container). Worth a note in the repo docs or dev setup script: if the build fails locally with permission errors on paraglide/, run sudo chown -R $USER:$USER frontend/src/lib/paraglide/.

No blockers.

## 👨‍💻 Felix Brandt — Senior Fullstack Developer **Verdict: ✅ Approved** ### What I checked **The config change is correct and minimal.** `prerender: { entries: ['/hilfe/transkription'] }` is the exact documented fix for this scenario. It adds no side effects on any other route, auth behavior, or SSR behavior. The array is hardcoded and does not accept user input — no injection surface. **The comment removal is the right call.** The removed comment was factually wrong and dangerous — it gave false confidence that the auth hook protects prerendered static files. It does not; the hook only fires for SSR requests through the Node server. A future developer adding a sensitive `prerender = true` route could have cargo-culted that comment and shipped a public page believing it was auth-gated. Deleting it is cleaner than replacing it, because `export const prerender = true` is self-documenting SvelteKit convention. **TDD acknowledgement in the PR.** The PR description correctly notes that the "red" step here is the failing `npm run build` output, not a failing unit test. This is appropriate — prerender behavior is a build-time concern, not a component concern. The existing 8 component tests for `hilfe/transkription` cover the rendered UI and remain valid. No new tests were added or needed. **CI step.** `npm run build` after `npm test` is correct ordering — tests first, then build. If tests fail, the build is skipped. The Paraglide compilation precedes both, so the build environment is fully prepared. The build step produces no artifact and doesn't need one — its only purpose is to exit 0 and prove the prerender completes. **One observation (not a blocker):** There's a local environment issue where the `paraglide/` directory is owned by `root` (from a previous Docker run), causing `npm run build` to fail locally with `EACCES: permission denied`. This does not affect CI (runs in a fresh container). Worth a note in the repo docs or dev setup script: if the build fails locally with permission errors on `paraglide/`, run `sudo chown -R $USER:$USER frontend/src/lib/paraglide/`. ### No blockers.

marcel commented

2026-05-09 08:56:20 +02:00

🚀 Tobias Wendt — DevOps & Platform Engineer

Verdict: ✅ Approved

What I checked

CI step placement and structure. The Build frontend step slots correctly after npm test and before Upload screenshots in the unit-tests job. The Compile Paraglide i18n step that precedes tests also precedes this build — the build environment is fully prepared. No new job, no new runner, no extra queue time beyond the build duration.

Cache reuse. The existing actions/cache@v4 step for frontend/node_modules (keyed on package-lock.json) is already in place and warms before this step runs. The build does not need its own cache entry.

Artifact behavior under failure. The Upload screenshots step has if: always(), which means test screenshots are uploaded even if the new Build frontend step fails. This is the correct behavior — a build failure shouldn't discard test failure evidence.

No artifact upload for build output. The build step correctly produces no uploaded artifact. The output is transient — its only purpose is to verify npm run build exits 0 and the prerender completes. The actual container image build uses a separate Dockerfile that runs npm run build independently.

Paraglide permission issue (local only). The paraglide/ directory on the local dev machine is owned by root from a previous Docker run, causing npm run build to fail locally. This is a dev environment issue, not a CI issue — the CI runner uses a fresh container where the directory is always writable. No CI config change needed.

Suggestion (not a blocker): Add a dev setup note or a Makefile target make fix-perms that runs chown -R $(id -u):$(id -g) frontend/src/lib/paraglide/ for developers who hit this. It's a one-time fix after any Docker-based paraglide compile.

No blockers.

## 🚀 Tobias Wendt — DevOps & Platform Engineer **Verdict: ✅ Approved** ### What I checked **CI step placement and structure.** The `Build frontend` step slots correctly after `npm test` and before `Upload screenshots` in the `unit-tests` job. The `Compile Paraglide i18n` step that precedes tests also precedes this build — the build environment is fully prepared. No new job, no new runner, no extra queue time beyond the build duration. **Cache reuse.** The existing `actions/cache@v4` step for `frontend/node_modules` (keyed on `package-lock.json`) is already in place and warms before this step runs. The build does not need its own cache entry. **Artifact behavior under failure.** The `Upload screenshots` step has `if: always()`, which means test screenshots are uploaded even if the new `Build frontend` step fails. This is the correct behavior — a build failure shouldn't discard test failure evidence. **No artifact upload for build output.** The build step correctly produces no uploaded artifact. The output is transient — its only purpose is to verify `npm run build` exits 0 and the prerender completes. The actual container image build uses a separate Dockerfile that runs `npm run build` independently. **Paraglide permission issue (local only).** The `paraglide/` directory on the local dev machine is owned by `root` from a previous Docker run, causing `npm run build` to fail locally. This is a dev environment issue, not a CI issue — the CI runner uses a fresh container where the directory is always writable. No CI config change needed. **Suggestion (not a blocker):** Add a dev setup note or a Makefile target `make fix-perms` that runs `chown -R $(id -u):$(id -g) frontend/src/lib/paraglide/` for developers who hit this. It's a one-time fix after any Docker-based paraglide compile. ### No blockers.

marcel commented

2026-05-09 08:56:31 +02:00

🔒 Nora "NullX" Steiner — Security Engineer

Verdict: ✅ Approved

What I checked

Attack surface delta: zero. This PR touches only svelte.config.js (build config), +page.ts (one-line file, removes a comment), and ci.yml (workflow). None of these introduce runtime security surface. The prerender.entries value is a hardcoded string literal — not user-controlled, not injectable.

Comment removal: security documentation improvement. This is the most security-relevant change in the PR. The removed comment asserted:

// Safe: handleAuth in hooks.server.ts redirects unauthenticated requests before prerendered HTML is visible.

This is factually wrong. When a reverse proxy (Caddy) serves .svelte-kit/output/prerendered/ as static files directly, hooks.server.ts does not run against those files — it only runs for SSR requests through the Node server. The comment created a false belief about the security model that could have been cargo-culted to a future prerender = true route containing sensitive data.

Removing it eliminates that false belief without replacing it with a potentially wrong new comment. The export const prerender = true export is self-documenting. If future prerendered routes need security context, those should be documented at the point of addition with accurate descriptions of what the reverse proxy exposes.

Open question from the issue review (not a blocker for this PR): Is /hilfe/transkription intentionally publicly accessible in production? If Caddy serves the prerendered static file directly (bypassing the Node server), the page is publicly reachable regardless of PUBLIC_PATHS. The page contains only transcription guidelines — no personal data — so this is not a vulnerability. But the intent should be documented. Recommend a follow-up issue to explicitly decide and document the public/private access model for prerendered routes.

No security regressions. No new vulnerabilities. No blockers.

## 🔒 Nora "NullX" Steiner — Security Engineer **Verdict: ✅ Approved** ### What I checked **Attack surface delta: zero.** This PR touches only `svelte.config.js` (build config), `+page.ts` (one-line file, removes a comment), and `ci.yml` (workflow). None of these introduce runtime security surface. The `prerender.entries` value is a hardcoded string literal — not user-controlled, not injectable. **Comment removal: security documentation improvement.** This is the most security-relevant change in the PR. The removed comment asserted: > `// Safe: handleAuth in hooks.server.ts redirects unauthenticated requests before prerendered HTML is visible.` This is factually wrong. When a reverse proxy (Caddy) serves `.svelte-kit/output/prerendered/` as static files directly, `hooks.server.ts` does not run against those files — it only runs for SSR requests through the Node server. The comment created a false belief about the security model that could have been cargo-culted to a future `prerender = true` route containing sensitive data. Removing it eliminates that false belief without replacing it with a potentially wrong new comment. The `export const prerender = true` export is self-documenting. If future prerendered routes need security context, those should be documented at the point of addition with accurate descriptions of what the reverse proxy exposes. **Open question from the issue review (not a blocker for this PR):** Is `/hilfe/transkription` intentionally publicly accessible in production? If Caddy serves the prerendered static file directly (bypassing the Node server), the page is publicly reachable regardless of `PUBLIC_PATHS`. The page contains only transcription guidelines — no personal data — so this is not a vulnerability. But the intent should be documented. Recommend a follow-up issue to explicitly decide and document the public/private access model for prerendered routes. **No security regressions. No new vulnerabilities. No blockers.**

marcel commented

2026-05-09 08:56:44 +02:00

🧪 Sara Holt — QA Engineer

Verdict: ✅ Approved

What I checked

No new unit tests — correctly justified. The PR description acknowledges this explicitly: the "red" step is the failing npm run build output. Prerender behavior is a build-time concern, not a component concern. There is no test that should check for a file on disk — that would couple tests to build artifacts. The CI gate is the correct regression mechanism here.

Existing test coverage unaffected. The 8 existing component tests for /hilfe/transkription/page.svelte.spec.ts cover heading, intro paragraph, external link security attributes, section headings, rule cards, and clarification chips. None of these tests care about the prerender flag or the removed comment — they test rendered output, which is unchanged by this PR. All 1835 frontend tests pass.

CI gate quality. The Build frontend step in CI is the right regression gate: if a future prerender = true route becomes unreachable behind auth, the CI build fails immediately on the next PR. This closes the gap that allowed the original bug to exist undetected.

Test plan item not yet verified: The PR description has an unchecked box:

- [ ] CI run on this PR confirms npm run build exits 0 and /hilfe/transkription.html is produced

This is expected — the CI run needs to complete on Gitea to confirm the fix works end-to-end. The local build was blocked by a root-owned paraglide/ directory (dev environment issue, not a code issue). The CI run in a fresh container should succeed.

Suggestion (not a blocker): Once the CI run completes green, tick that box in the PR description. It's the one verification step that proves the entire fix in an environment matching production.

Follow-up suggestion: Add a Playwright E2E smoke test after merge: test('hilfe/transkription loads for authenticated user', async ({ page }) => { await page.goto('/hilfe/transkription'); await expect(page.getByRole('heading', { level: 1 })).toBeVisible(); }). This catches broken prerendered output in the full stack without duplicating the unit test layer.

No blockers.

## 🧪 Sara Holt — QA Engineer **Verdict: ✅ Approved** ### What I checked **No new unit tests — correctly justified.** The PR description acknowledges this explicitly: the "red" step is the failing `npm run build` output. Prerender behavior is a build-time concern, not a component concern. There is no test that should check for a file on disk — that would couple tests to build artifacts. The CI gate is the correct regression mechanism here. **Existing test coverage unaffected.** The 8 existing component tests for `/hilfe/transkription/page.svelte.spec.ts` cover heading, intro paragraph, external link security attributes, section headings, rule cards, and clarification chips. None of these tests care about the prerender flag or the removed comment — they test rendered output, which is unchanged by this PR. All 1835 frontend tests pass. **CI gate quality.** The `Build frontend` step in CI is the right regression gate: if a future `prerender = true` route becomes unreachable behind auth, the CI build fails immediately on the next PR. This closes the gap that allowed the original bug to exist undetected. **Test plan item not yet verified:** The PR description has an unchecked box: > `- [ ] CI run on this PR confirms npm run build exits 0 and /hilfe/transkription.html is produced` This is expected — the CI run needs to complete on Gitea to confirm the fix works end-to-end. The local build was blocked by a `root`-owned `paraglide/` directory (dev environment issue, not a code issue). The CI run in a fresh container should succeed. **Suggestion (not a blocker):** Once the CI run completes green, tick that box in the PR description. It's the one verification step that proves the entire fix in an environment matching production. **Follow-up suggestion:** Add a Playwright E2E smoke test after merge: `test('hilfe/transkription loads for authenticated user', async ({ page }) => { await page.goto('/hilfe/transkription'); await expect(page.getByRole('heading', { level: 1 })).toBeVisible(); })`. This catches broken prerendered output in the full stack without duplicating the unit test layer. ### No blockers.

marcel commented

2026-05-09 08:56:55 +02:00

📋 Elicit — Requirements Engineer

Verdict: ✅ Approved

Acceptance criteria verification

The issue specified four acceptance criteria. All are addressed:

Criterion	Status
`npm run build` exits 0	✅ Will be confirmed by CI run on this PR
`/hilfe/transkription` is prerendered to a static HTML file	✅ Follows directly from the `prerender.entries` config fix
No regression on other prerendered routes (none currently)	✅ Confirmed — `grep -r "prerender = true"` returns only this file
Add `npm run build` as a step in `.gitea/workflows/ci.yml`	✅ Done

Scope discipline

The PR correctly implements Option A and nothing more. It does not:

Touch PUBLIC_PATHS in hooks.server.ts (Option B — a separate product decision)
Remove export const prerender = true from +page.ts (Option C — undesirable)
Add any new UI, new routes, or new product behavior

The open product question about whether /hilfe/transkription should be intentionally public (raised in the issue review) is correctly deferred. This PR is a P0 build fix, not a product decision. If the team decides to make help public, that warrants a separate issue with the "invite mom to transcribe" user story as the JTBD anchor.

One note

The PR initially included all commits from the feat/issue-483 branch (20 changed files, +573 lines) before being corrected to a clean cherry-pick onto main (PR #485 closed, PR #486 created). The final PR #486 is correctly scoped: 3 files, 8 additions, 3 deletions. Worth reviewing the branching workflow to prevent this in future — always branch from main for bugfix issues, not from in-progress feature branches.

No blockers.

## 📋 Elicit — Requirements Engineer **Verdict: ✅ Approved** ### Acceptance criteria verification The issue specified four acceptance criteria. All are addressed: | Criterion | Status | |---|---| | `npm run build` exits 0 | ✅ Will be confirmed by CI run on this PR | | `/hilfe/transkription` is prerendered to a static HTML file | ✅ Follows directly from the `prerender.entries` config fix | | No regression on other prerendered routes (none currently) | ✅ Confirmed — `grep -r "prerender = true"` returns only this file | | Add `npm run build` as a step in `.gitea/workflows/ci.yml` | ✅ Done | ### Scope discipline The PR correctly implements Option A and nothing more. It does not: - Touch `PUBLIC_PATHS` in `hooks.server.ts` (Option B — a separate product decision) - Remove `export const prerender = true` from `+page.ts` (Option C — undesirable) - Add any new UI, new routes, or new product behavior The open product question about whether `/hilfe/transkription` should be intentionally public (raised in the issue review) is correctly deferred. This PR is a P0 build fix, not a product decision. If the team decides to make help public, that warrants a separate issue with the "invite mom to transcribe" user story as the JTBD anchor. ### One note The PR initially included all commits from the `feat/issue-483` branch (20 changed files, +573 lines) before being corrected to a clean cherry-pick onto `main` (PR #485 closed, PR #486 created). The final PR #486 is correctly scoped: 3 files, 8 additions, 3 deletions. Worth reviewing the branching workflow to prevent this in future — always branch from `main` for bugfix issues, not from in-progress feature branches. ### No blockers.

marcel commented

2026-05-09 08:57:05 +02:00

🎨 Leonie Voss — UI/UX Design Lead

Verdict: ✅ Approved

This PR is infrastructure and CI configuration only. No UI changes, no component modifications, no layout or styling impact.

What I verified

The rendered /hilfe/transkription help page is unchanged. The fix only affects how SvelteKit discovers and builds the route — the output HTML for users is identical before and after this change.

The removed comment in +page.ts is not visible to users. The prerender.entries addition in svelte.config.js is not visible to users.

One observation worth noting for future work

As the issue correctly identifies, prerendered static HTML loads without JavaScript and without a backend round-trip. For the senior audience (60+) on slower connections, this is a genuine performance and reliability benefit — the transcription guide page renders immediately from the static file, independent of API health. This is a UX benefit of the prerender = true declaration that the fix correctly preserves.

If the team later decides to make help public (Option B as a follow-up), I'd recommend adding a "Log in to start transcribing" CTA at the bottom of the help page — a call-to-action that converts readers into registered contributors. That's out of scope here.

No blockers. LGTM.

## 🎨 Leonie Voss — UI/UX Design Lead **Verdict: ✅ Approved** This PR is infrastructure and CI configuration only. No UI changes, no component modifications, no layout or styling impact. ### What I verified The rendered `/hilfe/transkription` help page is unchanged. The fix only affects how SvelteKit discovers and builds the route — the output HTML for users is identical before and after this change. The removed comment in `+page.ts` is not visible to users. The `prerender.entries` addition in `svelte.config.js` is not visible to users. ### One observation worth noting for future work As the issue correctly identifies, prerendered static HTML loads without JavaScript and without a backend round-trip. For the senior audience (60+) on slower connections, this is a genuine performance and reliability benefit — the transcription guide page renders immediately from the static file, independent of API health. This is a UX benefit of the `prerender = true` declaration that the fix correctly preserves. If the team later decides to make help public (Option B as a follow-up), I'd recommend adding a "Log in to start transcribing" CTA at the bottom of the help page — a call-to-action that converts readers into registered contributors. That's out of scope here. ### No blockers. LGTM.

marcel merged commit e2d74ff880 into main

2026-05-09 14:25:55 +02:00

marcel deleted branch fix/issue-472-prerender-entries-v2

2026-05-09 14:25:56 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#486