The TypeScript helper refactor exposed a separate production risk: builds can fail when the sitemap-endpoints API returns a transient 5xx during Pagefind index generation. Move that fetch into a small helper with retry logic and add a focused prebuild test so this failure mode is caught without waiting on a full deploy.
Constraint: Must keep Pagefind index generation behavior the same when the endpoint is healthy
Rejected: Ignore the failure as external-only | transient 5xx responses can still block deploys and CI repeatedly
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When external build inputs can fail transiently, add a small retryable helper plus a direct test before relying on full deploy verification
Tested: pnpm exec vitest run test/prebuild/load-sitemap-endpoints.test.ts; pnpm run typecheck; pnpm run test-prebuild
Not-tested: Full production redeploy completion before push
Convert the scanner's plist parser and Node-style file shim to TypeScript and add small unit tests so common parser and file-reader failures are caught before we need to lean on Playwright or the higher-level scanner test.
Constraint: Must preserve current scanner behavior while tightening the lowest-level helper surface
Rejected: Jump straight to Mach-O parser conversion | harder to isolate regressions without first proving the smaller helper-test pattern
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Add small module-level regression tests for repeatable scanner breakage before expanding browser coverage
Tested: pnpm run typecheck; pnpm exec vitest run test/scanner/plist.test.ts test/scanner/file-api.test.ts test/scanner/client.test.ts; pnpm run test; pnpm run test:browser
Not-tested: Production deploy behavior prior to push
The previous verbiage fallback loaded package.json via createRequire(), which broke Astro/Netlify prerender bundling because the relative package.json path is not available inside the generated chunk layout. Replace it with static fallback strings so the app-test text stays populated without depending on runtime file access.
Constraint: Must restore Netlify production builds immediately
Rejected: Revert the verbiage fix entirely | would reintroduce the blank app-test subtitle in production
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep public runtime fallbacks bundle-safe; do not require repo files from prerender/runtime chunks
Tested: pnpm run typecheck (workspace); GitHub Actions failure analysis for netlify-build
Not-tested: Full redeploy completion at commit time
The app-test page could render blank processor/mac verbiage when pnpm did not supply npm_package_config_verbiage_* in the runtime environment. Fall back to package.json config and the page-level computed value so the subtitle and description stay populated in builds and production.
Constraint: Must not change scanner behavior or app-test submission flow
Rejected: Patch only the Vue page text | leaves the public runtime config inconsistent for other consumers
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep publicRuntimeConfig resilient to missing npm_package_config_* env values until the config source is normalized repo-wide
Tested: pnpm run typecheck (workspace); node --input-type=module import of publicRuntimeConfig (workspace)
Not-tested: Full browser rerun for this exact commit beyond the already-green production smoke suite
Move the worker scanner surface into TypeScript, add a direct worker regression, and make the version=2 app-test path populate the same visible result data and final status as the legacy scanner. This keeps the refactor bounded while making the worker route safe to exercise.
Constraint: Must preserve the existing Apple Silicon app-test behavior while changing the worker internals
Rejected: Flip production to the worker path immediately | still needs the normal deploy path and broader production soak
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep the version=2 adapter using the shared finishFileScan path until the legacy scanner can be removed entirely
Tested: pnpm run typecheck; pnpm exec vitest run test/scanner/client.test.ts; pnpm run test:browser (original workspace); netlify build --context deploy-preview (original workspace)
Not-tested: Browser suite from the clean clone environment (local Astro dev server startup timed out there)
Resolve the Pagefind browser loader in Vite dev and cap filter-only
result hydration so broad filters render promptly instead of stalling
behind thousands of fragment fetches.
Add Pagefind indexing and browser search adapters behind a provider switch.
This lets prebuild generate either Stork or Pagefind search artifacts and lets the existing search UI run against Pagefind while preserving scoped filters, excerpts, and result metadata.
Share filter parsing and provider mapping logic between Stork and upcoming search adapters.
This keeps the existing Stork API stable while adding Pagefind-oriented filter serialization under test.
Align local version markers and GitHub Actions with Node 24, switch the default test entrypoint to the maintained Vitest runner, and replace pnpm-incompatible npm helpers in repo scripts.
This also removes the obsolete AVA plus esm path and excludes disabled test fixtures from generic Vitest discovery so CI reflects the supported test surface.
Switch Stork downloads to artifacts that match current runtimes and fix the runtime detection path that Node 22 changed.
This keeps the existing Stork pipeline working on Netlify's Noble image and on Apple Silicon development machines.
