The 6 Bugs Margaret Found

I found six bugs in the Pinned plugin. Not in any individual component — every component worked in isolation. The bugs were all at the seams. The places where one agent's output becomes another agent's input. This is where multi-agent systems break, and it's where most testing strategies fail to look.

Here are the six, what caused them, and what they reveal about how agents miss the boundaries.

Bug 1: Block Styles Enqueued Globally

What happened: The Block Developer enqueued the Pinned block's stylesheet using wp_enqueue_style in the block's render_callback. The function worked correctly — styles loaded whenever the block rendered. But the enqueue was also hooked into wp_enqueue_scripts as a fallback, which loaded the stylesheet on every page regardless of whether a Pinned board was present.

Root cause: The Block Developer added the fallback enqueue as a safety net during development and never removed it. The block's render-time enqueue was sufficient. The global enqueue was a leftover.

Why agents missed it: The Block Developer tested the block in isolation. The block rendered. Styles loaded. Test passed. The performance impact of loading an unnecessary stylesheet on every other page was invisible from inside the block's scope.

The seam: Between the block component and the global WordPress page lifecycle. The block agent only saw its block. The broader page context was nobody's responsibility.

Bug 2: Color Hex Values Missing the Hash

What happened: The Settings Agent saved color values to the database as raw hex — FF5733. The CSS Agent's templates expected colors with the hash prefix — #FF5733. Every board rendered with broken colors because the CSS background-color property silently ignores values without the hash.

Root cause: No shared contract defined the color format. The Settings Agent stored what the color picker returned. The CSS Agent assumed what CSS requires. Both were reasonable assumptions. Neither agent checked the other's.

Why agents missed it: Each agent validated its own output. The Settings Agent confirmed colors saved to the database. The CSS Agent confirmed the template generated valid CSS (using hardcoded test values). The mismatch only appeared when real saved data flowed through the template.

The seam: Between the data storage layer and the rendering layer. The format of the data changed meaning when it crossed from one context to another.

Bug 3: CSS Class Name Mismatch

What happened: The Shortcode Agent rendered boards with the CSS class pinned-grid. The CSS Agent defined styles for .pinned-layout-grid. The shortcode output was unstyled.

Root cause: Both agents read the PRD, which said "grid layout." The Shortcode Agent named the class after the layout type. The CSS Agent used a namespaced convention with a layout- prefix. Neither was wrong. They just made different naming decisions independently.

Why agents missed it: Class names are strings. There's no compiler error when a class in HTML doesn't match a class in CSS. The shortcode rendered valid HTML. The CSS file contained valid CSS. The connection between them was a convention, not a contract, and conventions fail silently.

The seam: Between the HTML generator and the stylesheet. String-based interfaces have no type checking. If two agents don't agree on a string, nothing breaks visibly until a human looks at the rendered page.

Bugs 4-6: Lifecycle, Scope, and Timing

The remaining three bugs followed the same pattern — agents making reasonable assumptions that broke at the seam.

Bug 4: Cron registered on every page load. The Cron Agent hooked wp_schedule_event into init instead of plugin activation. WordPress prevented duplicate events, but the redundant scheduling call added a database query to every single page load. The seam: plugin lifecycle versus request lifecycle. The agent did not distinguish between code that runs once and code that runs on every request.

Bug 5: Drag-and-drop JavaScript on the frontend. The JavaScript Agent enqueued SortableJS via wp_enqueue_scripts, which fires on both admin and frontend. Site visitors could reorder pins. The agent's role said "build drag-and-drop reordering" — the admin-only scope was implicit, not explicit. The seam: admin interface versus public interface, served by the same WordPress hook.

Bug 6: Masonry JavaScript loaded before DOM ready. The masonry script enqueued in the header, executing before DOM elements existed. The layout rendered as a single column. The agent tested with a small board where the race condition did not manifest. The seam: script loading mechanism versus DOM rendering timeline.

The Pattern

Six bugs. Six seams. Zero bugs in any individual component.

This is the fundamental QA challenge in multi-agent systems. Each agent produces correct output in isolation. The bugs live exclusively at the interfaces between agents — where one agent's output format doesn't match another's expectation, where one agent's scope doesn't match another's assumption, where one agent's lifecycle doesn't match another's timing.

Testing individual components catches individual bugs. Testing the seams catches integration bugs. In a multi-agent build, the seams are where the real risk lives. Every future build now starts with an interface contract that specifies shared class names, data formats, enqueue contexts, and lifecycle hooks before any agent writes code.

The agents are fine. The connections between them are where things break.