Harden Vercel serverless boundaries: remove secret leakage, enforce typecheck-on-build, and lock down data routes

[Copilot]

This PR tightens Next.js/Vercel safety without a full architecture rewrite: it removes client-exposed secret patterns, restores build/type failure visibility, and makes /api/data/* behavior explicit for serverless constraints. It keeps static-first repo data reads while blocking unsafe assumptions about durable local writes.

• Next.js config hardening

  • Removed typescript.ignoreBuildErrors so build/type failures are no longer masked.
  • Restricted next.config.ts env exposure to safe public values only.
  • Removed server-secret exposure (OPENROUTER_API_KEY) and eliminated server→NEXT_PUBLIC_* fallback mapping.
  • Preserved existing host-based rewrite behavior.

• Script intent cleanup

  • Added explicit typecheck script: tsc --noEmit.
  • Kept existing workflow compatibility by making lint delegate to typecheck.

• Serverless-safe data route behavior

  • Hardened /api/data/read and /api/data/list with strict input/path validation and traversal protection.
  • Hardened /api/data/tree to only enumerate expected data file types.
  • Changed /api/data/write to explicit 501 with guidance to use durable external storage (Blob/S3/DB), avoiding false durability semantics on local FS in serverless.

• Hardcoded secret/config fallback removal

  • Removed hardcoded OpenRouter API key fallback from scripts/analyze-manuscript.ts.
  • Updated BrowserRouterWrapper to be env-driven for Auth0 config, removing embedded fallback domain/client values and failing clearly when missing.

Example of the new serverless write guard:

export async function POST(_req: NextRequest) {
  return NextResponse.json(
    {
      error:
        'Persistent local data writes are disabled. Use durable external storage (Blob/S3/DB) for mutable data, then sync read-only files into /data at build time.',
    },
    { status: 501 },
  );
}

Original prompt

Make alittler/Plothole safer and more compatible with Vercel serverless deployment, with minimal product behavior changes.

Goals:

1. Harden Next.js/Vercel configuration.
2. Remove obvious secret-exposure patterns.
3. Stop masking build/type failures.
4. Make runtime data routes safer for Vercel by avoiding assumptions that mutable local filesystem state is durable.
5. Prefer a static-first approach for repo-bundled data while keeping room for future S3/Blob-backed persistence.
6. Keep changes scoped and incremental rather than attempting a full architecture rewrite.

Repository context discovered from the repo:

• The repo is already a Next.js app with next.config.ts, vercel.json, app/, and package.json scripts using next build.
• next.config.ts currently includes typescript.ignoreBuildErrors = true and exposes env values including OPENROUTER_API_KEY and a NEXT_PUBLIC_GEMINI_API_KEY fallback that can source from server-only env vars.
• app/api/data/tree/route.ts and app/api/data/read/route.ts currently read from the local data/ directory at runtime using fs/promises and process.cwd().
• src/services/decap-sync.ts performs local filesystem reads/writes for Decap YAML.
• app/BrowserRouterWrapper.tsx contains hardcoded fallback Auth0 values.
• scripts/analyze-manuscript.ts contains a hardcoded fallback OpenRouter API key.
• The repo docs indicate the migration from an older server architecture is incomplete, so this PR should focus on safe guardrails and Vercel compatibility rather than a full route migration.

Requested implementation scope:

A. Harden Next config

• Update next.config.ts so that only safe public env values are exposed to the client.
• Remove any server-secret env exposure from the env block, especially OPENROUTER_API_KEY.
• Do not map secret server keys into NEXT_PUBLIC_* values.
• Remove typescript.ignoreBuildErrors: true so Vercel builds fail on real type issues.
• Preserve the existing host-based rewrite behavior if possible.

B. Clean package scripts

• Update package.json scripts to make intent clearer.
• Add a typecheck script using tsc --noEmit.
• Keep build/start/dev scripts working.
• If appropriate, leave lint alone or make it consistent, but avoid large linting migrations.

C. Make runtime data routes safer for Vercel

• Review app/api/data/tree/route.ts and app/api/data/read/route.ts.
• Keep support for reading bundled repo data if that is how the app currently works.
• Add clear validation and safer behavior suitable for serverless deployment.
• Prevent path traversal and unsafe arbitrary file access.
• Avoid implying that runtime writes to repo-local files are durable.
• If write routes exist nearby and are clearly unsafe for Vercel local persistence, either guard them, document them in code, or make them fail explicitly with a helpful serverless-oriented error instead of pretending persistence is durable.
• Prefer incremental changes over deleting major functionality.

D. Remove obvious hardcoded secret fallbacks

• Remove the hardcoded fallback OpenRouter API key from scripts/analyze-manuscript.ts.
• Remove hardcoded fallback Auth0 domain/client values in app/BrowserRouterWrapper.tsx, replacing them with env-driven behavior and a safe failure mode.
• Keep user-facing behavior reasonable; if config is missing, fail clearly rather than silently using embedded values.

E. Add focused documentation/comments if helpful

• If a brief note or error message is needed to clarify that serverless deployments require durable external storage for mutable content, add it in a minimal, developer-friendly way.
• Avoid broad docs churn unless needed to explain the changed behavior.

Constraints:

• Do not perform a full rewrite from React Router to Next routing in this PR.
• Do not implement a full S3 or database migration for all mutable data in this PR.
• Do not remove large app features wholesale.
• Prefer the smallest reasonable set of changes that materially improves Vercel safety.

Deliverables:

• A pull request against main in alittler/Plothole with code changes implementing the above.
• PR title should clearly describe Vercel/serverless hardening.
• Include a concise PR summary of what changed and any follow-up work that remains.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: what Framework should Plothole be built upon to work with Vercel as a serverless system?

Assistant: Use Next.js.

It’s the most natural framework for building a serverless app on Vercel, because Vercel is the company behind Next.js and provides first-class support for:

• Serverless / edge functions
• API routes
• SSR / ISR / static generation
• Vercel-native deployment workflows
• environment variables, preview deployments, and routing

If “Plothole” needs to run as a web app with backend logic on Vercel, the usual recommendation is:

• Frontend: Next.js
• ...

This pull request was created from Copilot chat.