[P3] evlog map: no Hono/Workers adapter, revisit later

[baronunread]

Verdict: not usable today. No Hono or Cloudflare Workers adapter.

I ran it against this repo rather than reading about it.

$ bunx @evlog/cli@latest map
evlog map v0.5.0
Could not detect a supported framework (nuxt, nitro, next, tanstack-start)
→ Use --framework <name> to override detection

Forcing an adapter gets a report, but an empty one:

$ bunx @evlog/cli@latest map --framework nitro
score /100    rdyrct · Nitro
100           0 entry points scanned
COVERAGE
(nothing)

A 100/100 over zero entry points. It writes evlog.map.json as a side effect
even when it found nothing, so a CI gate on --min-score 80 would pass forever
and tell us nothing. I deleted the file; the working tree is clean.

What evlog is

Two packages from the same author (HugoRCD):

• evlog — a structured logger (~6 kB, zero deps): levels, wide events that
  accumulate context across one request and emit a single entry, and errors
  carrying why/fix/link. Claims Cloudflare Workers support. Adapters for
  Sentry, PostHog, and others.
• @evlog/cli (v0.5.0, published 2026-08-05) — static analysis, no traffic
  needed. evlog map finds entry points, scores what each one would tell you
  when it breaks, and lists the fixes with file and line. --min-score <n>
  and --baseline are the CI gates. Author calls it early and says scores move
  between releases.

The idea is right for us: Lighthouse for observability, deterministic, prints
file and line, so it hands cleanly to an agent. The problem is only reach.

Why it finds nothing here

Framework detection is a fixed list: nuxt, nitro, next,
tanstack-start. Our entry points are a Hono router mounted in a Cloudflare
Worker (src/worker/index.ts plus src/worker/routes/*), which is not on it.
The --framework override only picks which of those four parsers to use, so it
finds no routes to score. Nothing to tune, nothing to configure around.

Ironically their own marketing screenshot scores ANY /api/auth/:all*, which
is a Hono-shaped route, so an adapter is plausibly coming.

What we would get if the adapter existed

Our worker logs are thin in the places that matter. evlog map would flag the
same paths #31 (structured observability, SLOs, runbooks) is about, but as a
scored list with line numbers instead of an essay. That is worth having.

Recommendation

Do nothing now. No PR, no dependency.

Two triggers to revisit:

1. @evlog/cli ships a Hono or Cloudflare Workers adapter. Then run
   evlog map, and if the list is honest, add bunx evlog map --min-score <n>
   to CI next to react-doctor.
2. We pick up [P2][18] Add structured observability, SLOs, and runbooks #31 or Migrate from Better Stack to Sentry (Cloudflare Workers module) for error logging #59 (Better Stack → Sentry). At that point the evlog
   logger itself is worth weighing on its own merits, separately from the CLI:
   wide events suit a Worker where one request is one log line, and it has a
   Sentry adapter. That is a decision for Migrate from Better Stack to Sentry (Cloudflare Workers module) for error logging #59, not this issue.

Also worth noting: this scanner and fallow and react-doctor all occupy the
same shelf. A fourth gate needs to earn its place, not just exist.