Wevna

// stack

// architecture

// overview

Backend debugging usually means scattering console.log calls or tailing a log file, then reconstructing by hand which query belonged to which request and where the time actually went. Wevna gives you that view directly. One call at startup and a dashboard on localhost fills in live: a waterfall per request, an execution graph with real parent/child ordering, time attributed by category, and named insights like "the same query ran four times, 158ms in total". It is a six-package TypeScript monorepo built around a frozen protocol package that defines every event shape, envelope and session format — the SDK, server, intelligence layer and dashboard all conform to that contract rather than to each other. Local-first by design: no agent, no account, no network egress.

// what was built

• ·One call — `await wevna.start()` — and you get a live dashboard, every console.log captured, every HTTP request recorded with method, route, status and duration, and every uncaught exception attached to the request that produced it.
• ·Automatic correlation via AsyncLocalStorage: a SQL query, a Redis command or a log line fired anywhere in the call stack is attributed to the originating request, with no plumbing in application code.
• ·Architected @wevna/protocol as the single typed contract for the whole monorepo — event shapes, envelopes, session and recording file format — so the SDK, server, intelligence package and dashboard cannot drift apart.
• ·@wevna/intelligence performs deterministic analysis rather than LLM guesswork: request timelines, an execution graph with real parent/child ordering, time attribution by category, and repetition detection that names the N+1 query instead of leaving you to spot it.
• ·Database, cache and outgoing-fetch capture are opt-in by design — there is no global hook for "every pg.Pool", so you hand Wevna the client you already made, once, behind a stable plugin API.
• ·Framework enrichment for Express, Fastify and Nest, so route templates and error handling are understood rather than inferred.
• ·Fastify server with a WebSocket transport for live streaming, plus an offline session source that replays a recorded run — so a bug reproduced once can be inspected later.
• ·Local-first: no agent, no account, no network egress, nothing leaving the machine. A published STABILITY.md states exactly what semver covers and what the frozen protocol and plugin API guarantee.
• ·Also contributed the Plugin SDK proposal upstream, and the repo carries a written stability, testing and status contract rather than a roadmap presented as features.