DEV Community: Cristian Deluxe

Reserving an ad slot before it moves the page

Cristian Deluxe — Tue, 29 Sep 2026 14:28:18 +0000

Originally published at https://cristiandeluxe.dev/blog/mobile-cls-ad-slot-reservation/.

An ad-size change exposed a layout shift on a financial-media site I worked on. Google Search Console flagged roughly 2,000 mobile URLs. The ad framework inserted a slot above the article after the page had painted, pushing the content down.

I kept the larger ad sizes and changed how the page made room for them.

Reproduce the shift under mobile conditions

I measured with Puppeteer using an iPhone 14 viewport, Fast 3G network throttling and a 4× CPU throttle. The run included scrolling so it could catch shifts from lazy-loaded slots.

That was an emulated test profile. The roughly 2,000 URLs came from Search Console; I did not run a before-and-after test on every one of them. The reproduced baseline CLS was 0.181.

I inspected which element moved and what appeared above it. The ad code created its own wrapper in JavaScript after the initial document loaded. Increasing the ad size made the missing reservation more visible.

A shifted element is a clue to the cause. It can be the content displaced by a new element, rather than the element responsible for the insertion. Google's layout-shift debugging guidance makes the same distinction.

Render the space before the ad arrives

I changed the server-rendered template to emit the ad placeholder, with CSS reserving its height for the relevant layout. The ad code then checked for that slot and reused it instead of inserting a second wrapper.

Both sides had to agree on the slot's identity and geometry. If the client couldn't find the server-rendered element, it would still insert its own. If it found the element but changed its size, content could still move. Reserving space only after JavaScript ran would also leave the initial paint exposed.

I kept the existing insertion path for slots without a server-rendered placeholder. That made it possible to apply the fix to the affected layouts without changing every ad placement at once.

Check where a placeholder does not belong

Some layouts had no leaderboard ad. Those needed to stay out of the placeholder path. Reserving a blank band on a page that would never fill it would have introduced a visible regression.

This is the part I would check carefully on another site: test both the layout with the slot and the layout without it. On the first, inspect the document before the ad request finishes, then confirm that initialization reuses the same element. On the second, confirm that the template leaves no reserved gap.

I would also repeat the throttled run through a scroll, rather than stopping at first paint. Later ad loading can still move content below the fold.

The LEDs weren't listening: a reverse-engineering story

Cristian Deluxe — Tue, 29 Sep 2026 14:27:42 +0000

Originally published at https://cristiandeluxe.dev/blog/reverse-engineering-mvave-smc-pad-leds/.

I wanted the buttons on my M-VAVE SMC-PAD to show what my lighting setup was doing. I use it with QLC+, and the feedback I wanted was fairly ordinary: press AUTO and have the AUTO pad glow green; while a flash is live, have its pad go white. There is an RGB LED under every button. The official app can set the colors. I wanted to control them from my own code.

I couldn't find public documentation for the LED commands, so I started with the obvious test. I swept every note across every channel and tested control-change messages. Nothing lit up. Those tests gave me no working LED command. It didn't mean the LEDs couldn't be controlled over MIDI; I hadn't found the right kind of message yet.

The app could do it, so the next useful thing to read was the app.

MidiSuite on Android is built with Flutter. I used Blutter to turn its Dart AOT snapshot into readable assembly, then followed the color path: sendColorData → writeData → makeWritePacket. It led to Bluetooth GATT. That explained why tracing the Android app wasn't producing the USB MIDI command I was looking for, but it did give me a way into the packet construction.

I was pairing with AI on the decompiling and byte-tracing work. There was plenty of mechanical reading for it to do, and it helped turn that reading into hypotheses I could test. Those hypotheses still needed checking. Later, the hardware caught mistakes in both the framing constant and the address we were using.

There was also a desktop editor: MidiSuite for macOS, also built with Flutter. That was the more useful app for following the USB path. I exported a preset from its editor. Before trying to read more assembly, I could compare the saved file with the colors visible in the editor.

Each pad's color record had this form:

09 <id> 00 7F R G B FF

The color itself was plain 24-bit RGB. I checked the bytes against the on-screen colors, and they matched byte-for-byte. I now had a verified representation of the color in a preset. That was useful, but it wasn't yet a command the pad would accept. A saved record doesn't tell you how the editor sends it, or where the device expects it to go.

Getting the macOS app into readable form needed some work of its own. Blutter expected ELF, while the snapshot I needed to inspect was in Mach-O. I patched Blutter's experimental Mach-O branch to build a macOS-target Dart runtime. With that in place, the decompile worked, and I could read sysex_codec.dart.

Over USB, the color command is manufacturer-specific MIDI SysEx. The logical packet contains ordinary bytes, but SysEx data must stay within 7 bits, so the codec re-encodes the payload as an 8→7-bit bitstream. Knowing the RGB values was only part of the job. I also needed to reproduce that encoding and the framing around it.

I checked the decoder against the pad's own captured status frames. The test was to round-trip real data through the codec and reproduce what the hardware had sent. That gave me something firmer than an interpretation of decompiled code: either the bytes matched or they didn't.

They exposed the first mistake. The AI's initial read had given the framing constant as 0xB2. The correct constant was 0x59. Passing toMidi([00,0x59,…]) reproduced the device's real F0 00 32 … header. I corrected the constant on that evidence. Without the captured frames, I would have been debugging writes with a codec that was already wrong.

The USB color-write packets I captured began with:

F0 00 32 09 59 …

Before the 8→7-bit encoding, the logical color-write packet is:

00 59 22 <len24> 05 <flash-addr-le32> 03 00 00 R G B <checksum>

The checksum is checksum = ~sum(data) & 0xFF, where data is the payload starting at 05, excluding the logical header and length field. These are different views of the command: the logical bytes and their SysEx representation. Keeping them separate mattered when comparing what I had decoded with what was actually being sent over USB.

The address needed its own check. The AI pair had also confused an offset in the file with an address on the device. I checked against the config dump read live from the pad and used the actual device flash addresses. In the configuration I tested, bank A pad 1 was at 0x418, with a 26-byte stride between pads. The preset had established how the color was represented; the live dump established where it belonged on the hardware.

At that point I had checked the transport, codec, framing, checksum and addresses. My writes still did nothing.

This was the part that held me up. The desktop app could send identical bytes through the identical CoreMIDI path and light the LED immediately. My code sent them and the pad ignored them. I had corrected real mistakes, but neither correction explained that remaining difference. Looking at the color-write packet on its own wasn't getting me any further.

The comparison needed to include what had happened before the write. I used a CoreMIDI output spy to capture the app's traffic from the very first packet, including the connection sequence. Until then, I had the command I wanted to reproduce without the complete conversation that made it work.

The app began with discovery, then read the entire configuration back through a run of requests with incrementing addresses. The color write happened after that exchange. I replayed the whole connect handshake and injected my write into the session. The pad changed color the instant the write landed.

In my tests, writes were gated by the session. A one-shot send was ignored. After discovery and the full config read, the pad accepted the color command. I had been comparing identical payloads on the same transport while leaving out the state established by the earlier packets.

The fix I verified was replaying the complete session. I wouldn't shorten that to "send a connect packet first," because the working sequence included the full configuration read. That distinction matters to anyone trying to repeat it: the capture contains the exchange that worked, not just a color command extracted from the middle of it.

Once the session was replayed, I could put a rainbow across all 16 pads. That was the visible result I had been missing through all the byte comparisons. I also got it working over Bluetooth GATT, so the LED control worked wirelessly too. The working Bluetooth replay sends logical packets through service AE40, with AE41 for writes and AE42 for notifications, without the USB 7-bit transform.

Looking back, I got useful evidence whenever I made a different part of the system readable. The Android decompile showed the GATT path. The exported preset let me check RGB values against the GUI. The macOS decompile exposed the USB codec, and the output spy finally showed the session that a single captured write couldn't explain. None of those views was enough by itself.

The same applies to the AI work. It helped with the mechanical reads and proposed explanations, but I had to test those explanations against the device. The wrong constant failed the status-frame round-trip. The file-offset assumption failed the comparison with the live config addresses. Both were concrete errors I could correct because I had an independent reference.

If I hit the identical-bytes problem again, I'll capture from the beginning of the connection sooner. Here, the deciding test was replaying what the editor did before it changed a color. I kept the working code and captured session in spectalive/smc-pad, including the sequence I used to get the pad listening.

Running my companies’ software with an agent fleet

Cristian Deluxe — Tue, 29 Sep 2026 14:26:55 +0000

Originally published at https://cristiandeluxe.dev/blog/running-a-company-on-an-agent-fleet/.

I use concurrent coding-agent sessions to work on my companies' software. I built the shared infrastructure those sessions use, including a private knowledge wiki and a pipeline for adding sources to it. I also operate the memory service behind that work.

The useful details are in the failures. In August 2026, I was dealing with a growing local memory store, competing writers and model fallbacks that could undermine review. These are the checks and measurements from that period.

Give each session a place to start

My context layer is a cross-linked Markdown wiki, versioned in Git. It holds project setup and past decisions, with links back to the sources. A new session can look up why something was done before proposing to change it.

I built an ingest pipeline for captured web content. A bulk model classifies the captures; a stronger model synthesizes the selected material into wiki pages. Validation rejects pages with no incoming links and writes outside the allowed paths. The workflow also requires a human diff review before publication.

On August 7, I captured a batch of 103 open research tabs. The log records 94 threads reaching classification: 50 selected for ingestion and 44 rejected. I kept the raw captures alongside the synthesis so I could check a page against what I had actually read.

Keep the author and verifier separate

The synthesis workflow uses a second model to grade pages against their sources. I enforce author/verifier separation in code: the grader must not resolve to the model that wrote the page. That includes fallback selection. Otherwise a routing failure can quietly turn an independent check into the author reviewing its own output.

I route large classification passes to a model tier with enough quota to finish them. Synthesis and grading use the scarcer tier. The selectors reject unrecognized model names, so a typo stops the job instead of silently changing its routing.

That separation gives me a check to inspect. It does not make the generated pages correct by itself; I still need the source links and the diff.

Measure the memory service under load

At the time, the local semantic store contained roughly 700,000 entries mined from repositories and session transcripts. I ran a fork of the memory engine because several operational fixes needed to live in the code.

One project-mine measurement on August 4 took 5.3 seconds against an empty store and 190 seconds against a store with 653,000 entries, for the same 448-item project. That was roughly 36 times slower. The mining path checked each file with a collection-wide query. I replaced those repeated lookups with a prefetch scan for larger projects, keeping a final check under the write lock.

A separate curation run showed why adding writers was the wrong response to a queue. Serial processing produced about 7.5 entries per minute. Parallel reads with batched writes reached about 33 entries per minute, a 4.4-fold increase. The writes still went through one writer. The gain came from batching work through that writer, not from letting multiple processes update the vector index.

The store had already suffered index divergence twice. I kept the single-writer lock and treated it as a constraint when changing throughput.

Make recovery stop where it should

I added a watchdog that checks the daemon and index every 15 minutes. It can restart a wedged daemon, but it abstains when a command-line mining job holds the writer lock. The recovery path depends on what failed; a running process alone is not enough to call the service healthy.

Concurrent sessions also share Git repositories. I require each session to stage only its own paths and push completed commits promptly. A formatting hook catches another source of avoidable conflicts. Before restoring a file, the session has to check whether another session changed it.

Those rules let me keep several sessions working without treating another session's unfinished work as something to clean up. When a check fails, I want the job to stop with enough evidence to tell me which operation failed and what it had already written.