Flue
Every signal accepted for Flue. Each links to the run that produced it. The Flue profile carries the current evergreen state.
June 2026
-
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.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
-
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.
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
-
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).
Run: 2026-06-03-weekly-digest-2026-05-28_2026-06-03-frontier-v0
May 2026
-
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.
Run: 2026-05-12-partial-cycle-flue-2026-05-07_2026-05-12-frontier-v0