Developer Diary: May 17, 2026

This is mostly a polish week, and I'm going to take that as a good sign. The headline features are done; the must-fix list is empty; what's left is the stuff that turns a working product into one you actually want to use. If you're an existing customer thinking about when to come over, this is the week that should move the needle.

What Moved This Week

Chaos testing across every SDK. This is the one I'm most excited about. Real chaos testing is something I've always wanted but never had time to do properly — it always felt like more than I could afford. Leaning on Toxiproxy changed the cost calculus completely, and now we're running ten scenarios per SDK on every change: baseline, added latency, bandwidth trickle, half-open TCP, silent stall, flapping (kill the SSE proxy five times in 30 seconds), fallback engagement on a long SSE outage, callback-throw recovery, and terminal-error classification (401/403/404 vs. 429/5xx). The whole battery runs against Node, Go, Python, Ruby, and Java.

It feels great to actually be exercising these paths. There's a synthetic monitor running against staging on an hourly cron — sdk-go talks to real staging TLS, pages on staleness — so the same scenarios get a continuous production-shaped check too.

LaunchDarkly migrator landed. qfg migrate --from launchdarkly now does the full trip — a snapshot fetcher with proper rate-limit handling, a converter that maps operators, values, and rulesets to Quonfig shape, and a writer that lands the result in either a local datadir or via cloud push.

What I'm proudest of is the migration report. Nothing is silently dropped — every gap (a prerequisite flag we don't model, an unbounded segment, a rebucketed rollout, a maintainer field, a mobile-key availability flag) is recorded in a structured conversion report and surfaced in MIGRATION_REPORT.md. The report opens with a TL;DR section ("Before you cut over"), groups conversion notes by category, derives a follow-up checklist that splits "must fix before cutover" from "review post-cutover", collapses high-volume low-signal categories into <details> blocks, and closes with a static appendix on the known behavioral differences so nobody is surprised on day one. The goal is that you can hand this to an engineering lead, they read it once, and they know exactly what's different and what to look at.

Phase 2 — the audit-log history backfill that brings over your LaunchDarkly change history as real git commits — is also landed, with a retention pre-flight that tells you up front whether you're on a Developer plan (≤30 days of history) before you start the slow walk. If you have multi-year change history you care about preserving, this brings it across.

Fit-and-finish on the eval charts. The 1d view is now 24 hourly buckets with localized "3 PM"-style labels; 7d and 30d are daily buckets with "5/15"-style labels. Missing buckets zero-fill so an idle hour or day actually dips to zero on the chart instead of just disappearing. The in-progress bucket — the current hour, or today on a daily view — fades to the background via a linear-gradient ReferenceArea so it reads as "not done yet" instead of looking like a real drop. Small, but charts are how people answer "is my flag doing what I think it's doing" and the visual reading has to be right.

qfg push and qfg pull round trips, finally beautiful. The CLI now packs your local commits and ships them as a single fast-forward through a new configs.gitPush endpoint, so the server validates the exact commits you authored — no smuggling state through one commit and reverting it in another. Per-commit authorization, path allow-list, typed denial responses with per-commit attribution, and a clean OriginMoved with an actionable qfg pull hint on non-fast-forward.

The reason I'm calling this out for converters: the path where your agents write JSON locally, commit, and qfg push is now a first-class workflow. Pull works the same direction. If you want config-as-code with real review semantics, this is the loop.

MTK billing, per-(workspace, env). The metering tracked keys meter is now scoped per environment with a sum aggregation, so a workspace's bill reflects the actual peak in each environment summed across them, not a global max. Legacy subscriptions stay on the v1 meter; new ones land on v2. Plumbed all the way through ETL, Stripe meter events with adjustments to cancel prior days' uploads, the usage view, and the bill copy. Dogfood subscription migrated.

Smaller things worth mentioning.

• qfg info was rendering [override] [object Object] for any rule whose value was a weighted-values rollout (i.e. anything the LaunchDarkly migrator emits). Now degrades cleanly to [see rules].
• The friction log (QFG_FRICTION_LOG=true) now writes to ~/.qfg/friction.log instead of dropping a .qfg-friction.log into whatever workspace clone you happened to be in. Side effect: no more rogue .gitignore commits queued behind it.
• Context autocomplete now merges per-attribute across SDK submissions, so a user that shows up once with {name} and once with {email} reports as {name, email} instead of dropping the older attribute.

Where That Leaves Us

I genuinely don't have much on the must-do list. The chaos pass is the proof — we're exercising the failure modes that actually matter on every SDK, on every change, with a synthetic monitor doing the same shape of check against staging on a cron. The LaunchDarkly migrator brings your flags AND your history AND a report you can hand to an engineering lead without apologizing. The push/pull path is what I want it to be. The charts read right.

If you're moving over from LaunchDarkly or Launch, this is a very good time to do a dry run. qfg migrate --from launchdarkly --dir ./my-workspace --full-summary will give you a real local checkout plus a MIGRATION_REPORT.md you can read through and decide from. No commitments. The full walkthrough is in the LaunchDarkly migration guide.

1.0 SDKs and GA are still aimed at end of May. I'm starting to look harder at the calendar than at the bug tracker.

-- Jeff