Aeon Flux vs x-gnosis Hono imports

Why Gnosis examples (and some in-repo workers) use `@a0n/x-gnosis/compat/hono`

Code under open-source/gnosis—including examples and paths that must stay lightweight relative to the core language/runtime tree—often imports HTTP compat from @a0n/x-gnosis/compat/hono directly. That keeps the Gnosis package graph from taking a dependency on @a0n/aeon-flux, which would introduce a circular or unnecessarily heavy edge (Flux sits above Gnosis/x-gnosis in the product stack, not inside the core compiler/runtime kernel).

The same reasoning applies where forkjoin-app (or similar) workers still reference @a0n/x-gnosis/compat/hono: those bundles may predate the umbrella import or intentionally avoid pulling Flux when only the x-gnosis shim is required.

What app Workers should use (monorepo policy)

For application and Worker surfaces built as part of the Flux-oriented app stack, the supported import is the umbrella re-export:

import { Hono, cors } from '@a0n/aeon-flux/compat/hono';

That path re-exports @a0n/x-gnosis/compat/hono with the same API, pinned and documented with the Flux package. Prefer it for new Worker and edge app code unless you are intentionally staying in the Gnosis-only subtree (examples, gnosis-local tooling, or other leaves that must not depend on Flux).

forkjoin-ai/gnosis