Founding member access recorded.
Checkout cancelled.

Signals · Flue profile

Flue

Every signal accepted for Flue. Each links to the run that produced it. The Flue profile carries the current evergreen state.

June 2026

  1. 2026-06-03 · Flue

    v0.9.0 breaking app-config migration: routing/provider imports, provider-ID format, SDK mount paths, and beta session-state reset

    • Upgrading to v0.9.0 forces a developer to rewrite application imports: routing moves from `@flue/runtime/app` to `@flue/runtime/routing`, provider APIs and `observe` come from `@flue/runtime`, and Workers AI types from `@flue/runtime/cloudflare` — code will not compile until updated.
    • Provider model values now require `provider-id/model-id` format and `registerProvider()`/`configureProvider()` must share one ID; SDK mount paths now derive from `baseUrl` pathname — both are silent runtime-behavior changes that mis-route calls if not updated.
    • Persisted beta session state is now rejected; the operator must clear or migrate the session store before upgrading or sessions fail to restore — a distinct destructive pre-upgrade step gated on the same v0.9.0 cutover.
    • All of these share one verb (update-before-upgrade) for one persona (the Flue app developer) and one verification path (build + smoke-test against v0.9.0), so they route as a single platform migration signal.
  2. 2026-06-03 · Flue

    v0.9.1 strips WebSocket URL credentials and rejects blank requestIds

    • Operators deploying Flue on Cloudflare WebSockets get two upstream hardening fixes by upgrading to v0.9.1: query strings and fragments are stripped before attachment persistence, so URL-carried handshake credentials are no longer retained, and agent/workflow frames reject blank or whitespace-only `requestId` values.
    • Both are the same consequence for one persona (the Cloudflare WebSocket operator) gated on the same upgrade, so they stay one signal; the operator action is to upgrade and confirm credentials are no longer in persisted attachments.
  3. 2026-06-03 · Flue

    v0.9.2 adds an activate_skill tool letting agents load skills autonomously

    • Operators configuring skills now get a new agent-facing `activate_skill` tool: agents load full skill instructions on demand before matching work, shifting skill loading from operator-orchestrated to agent-initiated — a proactivity/authority change the operator should be aware of when scoping which skills are available.
    • Workspace skills are reread on activation, so edits during an active session take effect (lazy loading preserved); verification is concrete (configure a skill, confirm the agent self-activates it and picks up an edit mid-session).

May 2026

  1. 2026-05-12 · Flue

    Flue: programmable harness with run observability, virtual sandbox, and shell env security fix

    • Operators using shell env for credentials in pre-v0.4.1 Flue sessions should verify their session store does not contain unredacted values — the v0.4.1 shell env redaction fix is a security patch.
    • Operators using `sandbox: 'local'` should re-test: it is now genuinely local (direct host access, no just-bash), changing the isolation boundary for agents running in CI.
    • Operators building on Flue should evaluate `flue logs` and run history (v0.5.0) as the primary evidence trail for autonomous agent invocations.

← All signals