Finish the portability report

Portability is a measured property of your app, not a slogan on the framework homepage. Finish the bookmarks API, run the same tests on both targets, and write down what actually matched.

The report lists shared routes and tests, adapter code, binding implementations, unsupported APIs, and operating limits:

## Shared unchanged
- src/app.js routes and middleware
- Vitest suite via app.request()
- JSON error shapes and status codes

## Adapted per runtime
- Entry: src/node-server.js vs src/worker.js
- Storage: PostgresBookmarkStore vs D1BookmarkStore
- Logging sink: stdout vs Workers console

## Platform-specific
- Node: long-lived process, SIGTERM shutdown
- Workers: env.DB binding, CPU time limits
- Not portable: node:fs imports in import pipeline

Paste real test output, not summaries. Example Vitest on Node:

✓ bookmarks API (12 tests) 48ms
Tests  12 passed (12)

Run the same suite against a Worker dev server or a Wrangler-integrated test harness. If three tests fail only on Workers, the report names them: e.g. “POST /bookmarks returns 500 on Workers when D1 binding missing; passes on Node with in-memory store.”

Attach curl evidence for both deployments:

curl -s -w '\n%{http_code}\n' http://localhost:3000/bookmarks
curl -s -w '\n%{http_code}\n' http://localhost:8787/bookmarks

Both should return 200 and [] when storage is wired. If Worker returns 500, note the response body and the missing binding in the report.

A realistic failure: you declare the app portable after hello-world matches, then production bookmark creation fails because Node imports node:crypto in middleware Workers cannot load. The report should list that import under “Not portable” and point to the Web Crypto fix.

Then decide whether the shared core is worth its abstraction cost. Honest numbers beat marketing.

Record cold start and bundle size for Workers separately from Node memory use. An API can be correct on both platforms and still be expensive to run at the edge.

The appendix should list every npm dependency you tried to import on Workers and whether it succeeded. That saves the next person a day of bundler errors.

If five tests fail only on Workers, name the failing assertion and the binding or import that caused it. Future you will thank present you.

Try this on your own project: write the three-section report before you declare the app portable, and attach test output from both runtimes.