This was a building week, not a migration week. The brand ports slowed down and a brand-new tool took most of the hours: an engine that turns a library of proven ad layouts into finished ads for any brand. Around it, the framework grew a desktop release lane, the agent workflow engine learned to ask for proof, and a VS Code extension stopped going quiet for an hour at a time. Adforge: the AI writes the plan, scripts do everything else Adforge is new this week. The pitch: a template is a wireframe with named slots and knobs, and it carries no brand. A brand kit is pulled from the live site with headless Chromium: exact colors, fonts, logo, and two screenshots. Merge the two and you get an ad. The design rule I am happiest about: the plan is the ONLY AI step. One claude -p call reads the recipe, the brand kit, and the template library, and writes a single plan.json: which templates, what copy, which brand value lands in which slot. The plan is validated against the recipe and the library, retried once with the errors, then it throws. Everything after that is a script. Merge, render every size with Playwright, cut each ad to video with ffmpeg from the same page its PNG came from, build the review gallery. Why it matters: the AI cannot break the layout. Brand values reach a template only as CSS custom properties, so one plan renders on-brand for any kit, and over-length copy or a missing slot fails loudly instead of producing a slightly wrong ad. What the library holds after one week: Sixteen templates across five families, including six "disguise" layouts that look like a note, a search result, a push notification, a social post, a meme, or an article card, with the brand's message sitting inside. Seven sizes, from square feed to 9:16 story to 2:3 pin. A recipe that names no sizes gets the default three. Five stock themes (classy, neobrutalist, mono, retro, pastel) that swap the whole color, font, and shape kit while the logo, images, and copy stay the brand's. Neobrutalist goes square with hard offset shadows; classy keeps a hairline and no lift. Four campaign recipes. The ten-ad rounds hold the template and knobs still so the only thing being tested is the message: one ad per ad set, ten dollars a day, ten days. The layouts come from a harvest of scouted Meta ads, transcribed once into wireframes and owned from then on. A failing ad no longer stops a run; it shows up in the gallery as a red card saying what was missing. And adforge results closes the loop: drop the ad account's numbers in, and every template gets a running score with the best hook it ever carried. No public site yet. OMEGA: a desktop release lane that rehearses in a throwaway repo OMEGA is the framework under every product I own. This week the desktop target got the release plumbing it was missing. Desktop builds are the hard case because they must run on a Windows signing box inside GitHub Actions, and the framework repo is private. The answer is a rehearsal: one command renders the workflow, composes the brand's secrets the same way the push-secrets verb does, snapshots the working tree through a temporary index onto a rehearsal ref (no local branch, main untouched), force-pushes it to a private throwaway repo, and dispatches the run. The snapshot repo exists only so a public build never publishes framework source. The public half is a -releases repo per brand: release artifacts plus the auto-update feed, managed by the desktop package. Assets carry versionless names from one catalog, so releases/latest/download/<asset> is a stable link and releasing a version never touches the website. A brand's source repo now derives as <brand.id>-omega, sitting beside <brand.id>-releases, and the release verbs read the repo from config, never from a git remote. Two other pieces landed: The seven @omega.js packages ship in lockstep: one version, exact pins in a brand's manifests, and a boot check that refuses to run on a drifted target and names the fix. User connections got a rework. A provider is one context per step (identity, authorize, exchange, refresh, revoke, status), the route owns the already-connected check so reconnecting your own account works, and the account page's cards come from config alone. Twitch and Kick ship built in. workkit: the QA stage demands proof workkit is the engine that runs my Claude Code sessions against GitHub issues. It cut 0.51.0 with a rule I should have had from the start. An issue parked at status:qa used to say "this is built, check it." Now a park comment must carry a Proof: line naming every test layer the change has a surface on: unit, integration, end to end, or why a layer was skipped. The verifier agent checks the layers, and the standards heal names every parked issue without the line. Eleven issues on my own dotfiles board failed that check the first time it ran, which is the point. Alongside it: a checkpoint skill that applies a long chat to the board before compaction (every verdict, decision, and question filed or commented onto its issue, and a spoken pass flips the status), a Parity lens in the review skill that names each changed file's siblings and reports where the new code's shape differs, and one fixed shape for every question put to the human. Claude Meters: a silent hour, fixed Claude Meters is a VS Code extension that shows Claude usage in the status bar. After an account switch, the API answered with a 429 carrying a long Retry-After, and the extension obeyed it perfectly: it went silent for up to an hour, showing a bare "Claude" with no reason. The fix in 1.4.10: backoff caps at ten minutes, a window inheriting the deadline from the shared cache reports it instead of hiding it, jitter stops N windows racing the same fetch, and the status bar reads "usage unavailable" with the reason in the tooltip. Plus the first unit tests for the status bar, through a vscode stub. Small but satisfying My Claude Code harness shipped 3.22.0: the footer patcher now mounts a context dial at runtime, a reaper job ends orphaned MCP router process trees every ten minutes, and keep-awake holds the Mac up until a scheduled wakeup fires. Last week's post scheduled itself. The dev.to API reference does not document scheduling, but front matter with published: true and a future published_at works: the post stores as published with a future date, the public URL returns 404 until then, and the slug is assigned at once. This post is going out the same way. Next week: the first adforge batch against a real ad account, and the desktop rehearsal producing a signed Windows build. If you have built a pipeline where the model writes a plan and code does the rest, I would like to know where you drew the line. Comments open. Cover photo by Maranda Vandergriff on Unsplash.