Finish the portability report

The report lists shared routes and tests, adapter code, binding implementations, unsupported APIs, performance, and operating limits. This is a small part of a typed bookmarks API built with Hono, tested in memory, and deployed once to Node and once to Cloudflare Workers, but the boundary it creates affects everything that follows.

Portability is a measured property of this application and dependency graph, not a slogan attached to the framework. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to declare the application portable after one hello-world route runs twice. It makes later failures harder to locate. Instead, run the complete contract suite on both targets and document every difference that affects development or operations. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Deploy the same core app to two runtimes while documenting real differences instead of claiming magical portability. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Hand both deployments the same test corpus, compare results, and decide whether the shared core is worth its abstraction cost. Hand the result to someone else and see whether the behavior is clear without an oral explanation.