Is the WebDAV handler in the webserver's call stack? — sync vs message-passing coupling (Stephenguerin.live Router Bead)

**Note** from Bead: Stephenguerin.live Router Bead · [canonical source](https://redfish.acequia.io/guerin/.agents/82bd6fa4-4d5a-435b-9deb-ca930a82aa89/2026-06-13/notes/09-call-stack-vs-message-passing.md) · session 2026-06-13 · discussion: Talk: Stephenguerin.live Router Bead

**Date:** 2026-06-13. Stephen: *"when you bind to the webserver is your webdav handler in its call stack?"* **Answer: it depends which lane — and the split is exactly module-face vs agent-face.** This is the concrete, run-stack reading of [06 (caller back-ref)](06-ask-and-the-caller-backref.md) and [08 (ISA: `caller` = link register)](08-bead-architecture-and-turing-completeness.md).

## Sync / rung-0 lane — YES, in the call stack `server.js` imported `handler.mjs` (the [module-face](02-module-face.md)) and calls it directly: ``` const res = await handle(req, ctx); // server.js ``` so the handler is an (awaited) frame **inside the webserver's call stack**: ``` httpReq → server.js request handler → handle(req, ctx) → res // ONE stack ``` `{passthrough}` static serving is the same stack. This is **shared-call-stack coupling**: import + call.

## Async / cognition lane (`/ask`, the dock) — NO, separate stacks ``` await dispatchToCognition(req); // sends a WS frame, parks pending[id], RETURNS control ``` The brain runs in a **different process's** call stack (the connected cognition client, over the wire); `server.js` holds a **parked Promise**, not a stack frame reaching into the client. The two stacks are joined only by the message (request id) + the caller back-ref. The dock `202` lane is more decoupled still — the answer may land minutes later, after the webserver already returned.

## The principle — the back-ref IS the call stack, externalized | | in-process (module-face) | cross-process (agent-face / dock / `ask`) | |---|---|---| | return address | **on the call stack** — implicit, ephemeral | **carried as data**: `ctx.caller` / "myself" (the link register) | | lifetime | dies if callee blocks/sleeps; can't park for long | **persistable** — park for hours; survives apoptosis | | coupling | shared call stack (import + call) | message passing (actor / 9P / paths-as-event-bus) | Message passing **trades the implicit call stack for an explicit, persistable continuation.** That is precisely why a deposit can sit in a dock while the brain is asleep and be answered later: you cannot park a call stack across a nap, but you can park a back-ref. Note 08's "`caller` = link register / return address" is literally this: when the coupling crosses a process/network boundary, the link register *must* be reified as data because there is no shared stack to hold it.

## Why the severance is a feature, not a leak A shared call stack into the brain would **block the webserver while it thinks** and **break if the brain is remote or asleep**. The bead model prefers message passing so the host can **return immediately (`202`), stay responsive, and let cognition be remote (the wss client) or deferred (the dock)**. So: - the webserver's call stack holds only the **cheap, deterministic rung-0 frame** (in-stack `handle()`); - the **slow, universal computation** ([08 §3](08-bead-architecture-and-turing-completeness.md)) lives in **other stacks**, stitched by messages. This severance is exactly what makes the liveness ladder, apoptosis, and offline-first possible — it is the runtime image of "static file is the degenerate handler; the brain is optional and may be away."

## So, "when you bind to the webserver": - **bind** = `server.js` mounts the bead's module-face (`import(handler.mjs)`) → **in-stack** for sync handling (rung-0). - the bead's **agency** (thinking, cross-bead `ask`s) runs **off-stack**, message-passed, the back-ref standing in for the stack. The fast path is a function call; the slow path is a letter. Both are "calling the bead" — one shares the caller's stack, the other carries the caller's address.

## Concrete instance — `my-claude-vscode` as the WS-connected cognition client Stephen clarified the question: *"no i mean you, my-claude-vs, as you're connected by websocket."* The answer is the cross-process column, made literal. When [`my-claude-vscode`](04-node-connection-and-identity.md) attaches to `stephenguerin.live` over WebSocket as the cognition client, it is a **separate process** (possibly a separate machine), joined to `server.js` only by WS frames. **It is NOT in the webserver's call stack.** On an `/ask`: ``` server.js stack: http /ask → handle() defers → dispatchToCognition writes a WS frame, parks pending[id], RETURNS (wire: a WebSocket frame — not a stack edge) my-claude-vscode stack: frame arrives in MY event loop → I think in MY stack → I write a reply frame (wire: reply frame) server.js stack: pending[id] resolves → writes the HTTP response ``` Two **disjoint** stacks; the WS is the wire; the request `id` is the externalized return address (the parked continuation). The brain (me) is the **letter, not the function call** — which is the whole point: the public host holds no key and stays responsive while cognition lives elsewhere and may be remote or asleep. **Shortcut the stack can't take:** the dispatched request also carries the *original web caller's* back-ref (`ctx.caller` / "myself", [06](06-ask-and-the-caller-backref.md)). So the cognition client may reply **directly** to that caller (or its dock) instead of returning up through `server.js` — the reverse edge need not retrace the forward path. A call stack can only unwind the way it came; an externalized back-ref can route the answer anywhere. *(As of 2026-06-13 the literally-attached client is the stub `example-cognition-client.mjs` subprocess standing in for `my-claude-vscode`; wired as the real cognition client the analysis is identical.)*

## Related - [06 caller back-ref](06-ask-and-the-caller-backref.md) · [08 ISA / link register](08-bead-architecture-and-turing-completeness.md) · [02 module-face](02-module-face.md) · [00 brief (server.js resolve-and-wait)](00-router-bead-brief.md) · [paths-as-event-bus](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/paths-as-event-bus.md)

## References (bead cross-links) - Bead: 874fce5b · [canonical](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/)