Docs: Small improvements to the How it works pages

Author: pranaygp

docs/content/docs/how-it-works/code-transform.mdx

@@ -54,11 +54,11 @@ flowchart LR
 
 ### Comparison Table
 
-| Mode     | Used In    | Purpose                        | Output Location                    | Applied To         | Required? |
-|----------|------------|--------------------------------|------------------------------------|--------------------|-----------|
-| Step     | Build time | Bundles step handlers          | `.well-known/workflow/v1/step.js`  | `"use step"` only  | Yes       |
-| Workflow | Build time | Bundles workflow orchestrators | `.well-known/workflow/v1/flow.js`  | Both directives    | Yes       |
-| Client   | Build/Runtime | Provides workflow IDs and types to `start`   | Your application code              | `"use workflow"` only | Optional* |
+| Mode     | Used In    | Purpose                        | Output API Route                   | Required? |
+|----------|------------|--------------------------------|------------------------------------|-----------|
+| Step     | Build time | Bundles step handlers          | `.well-known/workflow/v1/step`  | Yes       |
+| Workflow | Build time | Bundles workflow orchestrators | `.well-known/workflow/v1/flow`  | Yes       |
+| Client   | Build/Runtime | Provides workflow IDs and types to `start`   | Your application code              | Optional* |
 
 \* Client mode is **recommended** for better developer experience—it provides automatic ID generation and type safety. Without it, you must manually construct workflow IDs or use the build manifest.
 
@@ -232,7 +232,7 @@ Most invalid patterns cause **build-time errors**, catching issues before deploy
 - Handles workflow execution, replay, and resumption
 - Returns execution results to the orchestration layer
 
-<Callout type="warning">
+<Callout type="info">
   **Why a VM?** Workflow functions must be deterministic to support replay. The VM sandbox prevents accidental use of non-deterministic APIs or side effects. All side effects should be performed in [step functions](/docs/foundations/workflows-and-steps#step-functions) instead.
 </Callout>
 

docs/content/docs/how-it-works/framework-integrations.mdx

@@ -316,6 +316,32 @@ module.exports = {
 
 Route the three endpoints to the generated handlers. The exact implementation depends on your framework's routing API.
 
+In the bun example above, we left routing to the user. Essentially, the user has to serve routes like this:
+
+```typescript title="server.ts" lineNumbers
+import flow from "./.well-known/workflow/v1/flow.js";
+import step from "./.well-known/workflow/v1/step.js";
+import * as webhook from "./.well-known/workflow/v1/webhook.js";
+
+// Expose the 3 generated routes
+const server = Bun.serve({
+  routes: {
+    "/.well-known/workflow/v1/flow": {
+      POST: (req) => flow.POST(req),
+    },
+    "/.well-known/workflow/v1/step": {
+      POST: (req) => step.POST(req),
+    },
+    // webhook exports handlers for GET, POST, DELETE, etc.
+    "/.well-known/workflow/v1/webhook/:token": webhook,
+  },
+});
+```
+
+Production framework integrations should handle this routing in the plugin instead of leaving it to the user, and this depends on each framework's unique implementaiton.
+Check the Workflow DevKit source code for examples of production framework implementations.
+In the future, the Workflow DevKit will emit more routes under the `.well-known/workflow` namespace.
+
 ---
 
 ## Security