zudo-slack-wisdom
GitHub repository

Type to search...

to open search from anywhere

Source Map and Versioning

The Flue 2.0.3 evidence hierarchy, package checks, breaking changes, and known source drift

Verified Baseline

Verified 2026-08-08. This section targets Flue 2.0.3 and Node.js >=22.19.0. The release is recorded in the tagged 2.0.3 changelog, and the Node.js floor appears in each tagged package manifest, including @flue/runtime and @flue/cli.

This is a versioned snapshot, not a claim about every future latest. Re-run the checks below and review the changelog before upgrading any @flue/* package.

Authority Order

When Flue sources disagree, use this order. Every source in one decision must match the package version being documented.

  1. Matching tagged changelog and runtime contracts. Breaking-change records and executable types/validation resolve version-sensitive API questions. Start with the v2.0.3 changelog and tagged dispatch contract.

  2. Tagged runnable examples. Use the example at the same tag to confirm how the contracts fit together, especially the Cloudflare example and Slack channel example.

  3. Installed flue docs. The CLI reads version-matched bundled prose without a network request; see the official flue docs reference. Use it for discovery, but still reconcile executable snippets because bundled 2.0.3 prose contains the Cloudflare discrepancy recorded below.

  4. Live prose. The website is useful for discovery, but it may move ahead of or drift within a release. Never let an unversioned snippet overrule a matching tagged contract.

Reconciliation rule

Do not copy a version-sensitive snippet from one page. Reconcile it against the matching tagged changelog, runtime types or validation, and runnable tagged example; record any unresolved mismatch as unverified behavior.

Package and Engine Checks

Run the installed CLI first, then query the exact registry versions rather than an unqualified latest tag:

flue --version
flue docs search "Cloudflare Vite"
flue docs read reference/configuration
npm view @flue/runtime@2.0.3 version engines --json
npm view @flue/cli@2.0.3 version engines --json
npm view @flue/vite@2.0.3 version engines --json
npm view @flue/slack@2.0.3 version engines --json

The registry checks returned the following on 2026-08-08:

PackageExact versionNode.js enginePrimary metadata
@flue/runtime2.0.3>=22.19.0registry, tagged manifest
@flue/cli2.0.3>=22.19.0registry, tagged manifest
@flue/vite2.0.3>=22.19.0registry, tagged manifest
@flue/slack2.0.3>=22.19.0registry, tagged manifest

Keep these packages on one reviewed Flue release unless the changelog explicitly documents a safe mixed-version arrangement. Package metadata proves what was published; it does not prove that an application's lockfile installed the same versions, so inspect the lockfile too.

Flue 2 Contract Changes

Flue 2 is a Vite-based application model. The 2.0.0 changelog makes these breaking changes explicit:

  • flue() from @flue/vite participates in Vite; removed flue dev and flue build commands are replaced by Vite's commands.

  • app.ts is the explicit route map. File location no longer creates HTTP routes automatically.

  • A module beginning with 'use agent' registers its capitalized exported agent functions; defineAgent is removed.

  • The older built-in workflow abstraction, including defineWorkflow, is removed. Conversations remain the durable framework unit; orchestration outside that unit belongs in application code or an external workflow engine.

All four claims come from the tagged Flue 2.0.0 breaking changes. Do not present beta-era APIs or automatic routing as current behavior.

Known v2.0.3 Source Drift

Cloudflare Vite snippet

The tagged Cloudflare deployment proseshows plugins: [flue(), cloudflare()] and omits flueWorkerConfig(). That form conflicts with the same release'sconfiguration contract,2.0.0 changelog, and runnable Cloudflare example, which require flue() first and cloudflare({ config: flueWorkerConfig() }) second. Use the latter form for 2.0.3.

Slack delivery dedupe

The tagged Slack blueprint'sdispatch(...) examplerecords payload.event_id as a signal attribute but omits idempotencyKey. The taggedruntime admission contractsupports a caller-chosen idempotencyKey, and the tagged@flue/slack contractrecommends idempotencyKey: payload.event_id so an Events API redelivery converges on the original admission. Follow the runtime/channel contract; do not silently copy the blueprint omission.

Both entries began as verified source differences. The Cloudflare one has since been settled by execution rather than by reading: building a real Flue 2.0.3 Worker (zudolab/zudo-text#4625) confirmed that the flueWorkerConfig()-less form does not build and the runnable-example form does. Treat the plugin-order resolution as tested behavior; the Slack dedupe entry remains a source reconciliation only. The later technical guides must preserve that distinction and link back to this baseline when showing version-sensitive code.

The same build work exercised several 2.0.3 behaviors the tagged prose leaves unstated — peer version floors, the compatibility_date minimum, the providers bundle lever, and the build-before-deploy ordering. Those are recorded where they are actionable, on Getting Started on Cloudflare, and the HTTP conversation contract pinned by the same effort is on Core Concepts and API.

Revision History

CreatedUpdated