Taming WordPress: How I Cut Stack Costs With $1,632 Net Annual Savings While Achieving a 99 PageSpeed Score using Claude Code

For nearly twenty years, maintaining a high-traffic web presence has meant constantly outrunning the slow accumulation of digital debris. What starts as a series of quick feature trials and minor design tweaks inevitably hardens into systemic technical debt, burying application logic under layers of forgotten code and bloated data.

Martech Zone carried every pound of that history: a media library encoded at maximum quality, a database full of data from plugins that had been uninstalled years ago, redirects that booted the entire CMS to answer with a single 301, and a front end that loaded libraries it didn’t use on pages that didn’t need them. None of it was visible in the content. All of it was visible in the load time.

This article serves as a comprehensive, battle-tested engineering blueprint detailing how I systematically dismantled decades of architectural bloat on a major production site. By treating performance optimization not as a superficial front-end polish, but as a deep infrastructure and application-layer overhaul, I successfully re-engineered the platform from the data layers up to the edge network.

The Core Problem: WordPress’s Unenforced Cleanup Is a Continued Architectural Flaw

The fundamental issue with the WordPress ecosystem is that it operates on an honor system rather than strict enforcement. When you deactivate and delete a plugin or theme, WordPress doesn’t require or enforce an uninstall.php script or a cleanup routine. It simply removes the files from the disk.

Because cleanup is entirely optional for developers, years of testing, swapping, and abandoning tools leave behind a massive digital graveyard. Orphaned database tables, bloated wp_options rows, abandoned custom post types, and endless unindexed metadata remain in your database forever.

The core CMS has no built-in garbage collection to say, This data belongs to a plugin that hasn’t existed since 2018; let’s delete it. For a site with nearly two decades of history, this structural flaw turned the database into an anchor. Every single page load forced PHP and MySQL to wade through hundreds of thousands of rows of dead weight.

Squeezing the Infrastructure Stack

This compounding technical debt manifested as a massive infrastructure bill. To keep the site from crashing under the weight of its unoptimized database and inefficient rendering pipeline, and to address fundamental security flaws that encouraged DDoS attacks, the origin server had to be scaled up to a massive $384-per-month Linode instance, even with FlyWP caching and optimization sitting above it, and Cloudflare sitting above that! Even at that price point, the server routinely experienced severe OOM bottlenecks and CPU spikes whenever a bot scraper or a traffic surge hit the site.

By systematically fixing these fundamental application flaws, eliminating database bloat, and redesigning the site’s network interactions, I achieved a radical transformation. I safely downsized the infrastructure from that bloated $384/month account to a lean, $48/month Linode instance.

Despite running at a fraction of the cost, the new setup operates with incredible efficiency, idle CPU usage, and lightning-fast response times—all while securing a near-perfect 99/100 mobile score on PageSpeed Insights.

A note on AI, up front: I did this work in partnership with Claude Code, Anthropic’s command-line agent. I directed the strategy, made the calls, and verified every change in production; Claude did the heavy lifting — auditing the database, writing and rewriting the plugin code, generating the migration and rollback scripts, and running the deploys. I’m being transparent about that because the method is part of the story: a careful HAI workflow is exactly what made it safe to touch a live database this aggressively. There’s a fuller note at the end.

The Optimization Blueprint: Step-by-Step Execution

Below is the complete technical breakdown of the architectural changes made to rehabilitate the site. The overhaul is structured methodically, detailing the exact systemic issue discovered, followed by the explicit engineering steps taken to resolve it.

To help you prioritize your own site optimization, these initiatives are ordered strictly by impact—starting with the highest-yielding structural changes, then descending to micro-optimizations and specialized workflow cleanups.

Put Cloudflare in front of WordPress and cache the whole stack

Every uncached request was booting PHP, querying MySQL, and rendering the full theme from scratch — slow time-to-first-byte and fragile the moment traffic or a bot spiked. A single origin in a single data center was also serving every reader on Earth from that location. This is the foundation: nothing else matters much if the origin is in the request path for every hit.

The fix:

• Routed the site through Cloudflare so static assets and full HTML pages are cached at the edge, close to the reader.
• Layered four caches so the origin is the last resort: Redis object cache, PHP OPcache, nginx FastCGI page cache, and the Cloudflare edge.
• Set the origin to send a 24-hour HTML edge TTL while keeping browser caches short.
• Wrote a must-use plugin that surgically purges only the changed post’s URL plus its archives, feeds, home page, and first pagination pages on every edit — so a 24-hour TTL never serves anything stale.
• Locked the origin firewall so ports 80/443 accept only Cloudflare’s IP ranges, closing the direct-to-origin bypass that would otherwise defeat the whole layer.

Re-encode every image to quality-82 WebP

The entire media library had been saved at quality 100. An 800×450 card image weighed about 180 KB when ~30 KB would look identical on screen; Lighthouse alone flagged roughly 800 KB of wasted bytes on the homepage. There was a nasty trap underneath it: the server’s image editor inherited each source file’s lossless WebP flag, so the normal set the quality call was silently ignored — resizing a lossless image just produced another lossless image.

The fix:

• Forced a genuinely lossy re-encode at quality 82 — the only way to actually shrink files that were saved losslessly.
• Hooked it into uploads so every new image and every generated size is recompressed automatically going forward — the bloat can’t creep back in.
• Converted the last 351 JPEG/PNG originals to WebP, rewrote their database references, and deleted the originals. I left GIFs alone because they were animated.
• Ran a resumable batch over all ~26,000 existing WebP files, recompressing in place but only when it saved at least 5%.
• Result: about 4.5 GB reclaimed and a homepage roughly 800 KB lighter.

Prune the image-size ladder and regenerate the library

WordPress and the theme were generating 11 resized derivatives for every upload — a stack of near-duplicate widths that the theme didn’t even use. That multiplied disk usage, slowed media regeneration, and stuffed every srcset with junk candidates the browser had to parse.

The fix:

• Cut the registered image sizes from 11 down to 6 (thumbnail, 320, 420, 640, 800, 1024, plus the original), dropping the duplicate rungs and the redundant 1200/1536/2048 crops.
• Bulk-regenerated the whole library so the dropped files were deleted, and each attachment’s metadata was rewritten to stop referencing them.
• Removed 579 orphaned attachment records whose source files were already missing, after auditing that no content was linked to them.
• Swept thousands of straggler files and stripped a dead registered size from nearly 12,000 attachments’ metadata.
• Result: the uploads directory dropped from 29 GB to 22.5 GB before the WebP pass took it further.

Purge orphaned tables, options, postmeta, and post types

Years of install it, try it, remove it and migration to new plugins and themes had left a graveyard inside the database. Plugins that were long gone from disk had never cleaned up after themselves: their tables, options, scheduled cron events, and hundreds of thousands of meta rows were still there — bloating backups, inflating the data WordPress has to autoload on every request, and slowing queries that had to step around the dead weight.

The fix:

• Inventoried every non-core table and matched each to its owning plugin, flagging any whose plugin was gone from both the active list and the disk — verified, not guessed by name substring.
• Dropped roughly 60 orphaned tables — MailPoet’s 40, AIOSEO’s 9, plus Link Whisper, Easy Digital Downloads, MonsterInsights, WP Mail SMTP, CookieYes, and a legacy events table.
• Removed roughly 36,000 orphaned postmeta rows and 1,600-plus leftover custom-post-type entries — an old job board, products, abandoned orders, pretty-links, popups — plus their dead taxonomies and terms.
• Took a full backup first, then generated a per-operation rollback script for every deletion and validated each one by replaying it into a throwaway database before trusting it.

Remove the render-blocking, cross-origin jQuery

One plugin had quietly hijacked the jQuery handle sitewide and re-registered it from Google’s CDN. The result: every page on the site loaded a render-blocking, cross-origin script in the head — including the vast majority of pages that never used the plugin at all. It was a single line of code costing a third-party round-trip on every pageview.

The fix:

• Removed the global deregister/re-register and restored WordPress’s bundled, local jQuery 3.7.1.
• Stripped jQuery-migrate from the front end — the site had run without it for years under the CDN swap, so nothing depended on it.
• Net result: one render-blocking third-party request eliminated from every single page.

Stop lazy-loading the image that is the LCP

The theme lazy-loaded every card image — including the one above the fold that is almost always the Largest Contentful Paint (LCP). So the browser was told to discover the single most important image on the page last, directly delaying the metric Google grades you on.

The fix:

• De-lazied the first two listing cards (eager loading) and set high fetch priority on the one LCP image — just one, since multiple high priorities dilute each other.
• Added a responsive preload so the correctly-sized hero starts downloading immediately, before the CSS even resolves.
• Recorded the gotcha that cost three no-op releases: the relevant filter runs before WordPress core adds its image class, so gating on that class silently never matches. Gate on the registered size name instead.

Move redirects off WordPress and onto the Cloudflare edge

Redirects handled by a WordPress plugin boot the entire CMS — PHP, the database, the whole plugin stack — just to respond with a 301. For URLs that should never reach the server in the first place, that’s pure wasted origin work, repeated on every old or mistyped link a crawler or visitor hits.

The fix:

• Migrated the redirect map to Cloudflare Bulk Redirects, so 301s and 302s resolve at the edge before the origin is ever contacted.
• Canonicalized internal links to their trailing-slash form directly in the stored content (422 URLs across 196 posts), so fewer redirects need to fire at all — carefully excluding querystrings and file URLs from the rewrite.
• Replaced the 404/410-related posts fallback’s unindexed LIKE search with a fast tag-based lookup, so even error pages stopped hammering the database.

Convert icon fonts to subsets and SVG

To draw a few dozen small icons, the theme was pulling in the full Font Awesome library plus a 20.7 KB theme icon font containing 161 glyphs, of which the site rendered around 34. That’s a lot of bytes and a render dependency for a handful of symbols in the navigation.

The fix:

• Dequeued the parent theme’s full Font Awesome and swapped in a hand-pruned 57 KB subset holding exactly the 43 selectors the live navigation uses.
• Subset the theme’s icon font from 20.7 KB down to 4.2 KB for the glyphs actually rendered, with a swap display strategy and a preload so it never blocks paint.
• Re-rendered standalone icons (like the QR-code tile) as inline SVG masks instead of a font glyph entirely.

Defer and conditionally load CSS and JavaScript

Non-critical stylesheets were loading render-blocking in the head, and heavy libraries — the LaTeX math renderer, the table-of-contents script, the chat widget — were loading on every page whether or not that page actually used them. The browser was paying for features most readers never saw.

The fix:

• Switched non-critical stylesheets to a non-blocking print-media swap that flips to all on load.
• Gated LaTeX on the latex shortcode and the script on the actual block being present; loaded per-page JavaScript only where it’s needed.
• Inlined the chat bar’s critical CSS and its avatar as a data URI so the docked bar paints with the page instead of popping in two or three seconds late.

Turn off Cloudflare Rocket Loader

Rocket Loader rewrites and defers all JavaScript automatically — which sounds helpful, but it broke the mega-menu and forced a steadily growing list of per-script exemption hacks. I was spending more effort fighting the tool than I was getting back from it, and its behavior was non-deterministic across cached pages.

The fix:

• Disabled Rocket Loader and reverted all the exemption workarounds it had required.
• Kept the optimizations that are predictable and in my own code — critical CSS, conditional loading, preloads — where I control exactly what happens.

Disable WordPress’s built-in search

WordPress’s default search runs three unindexed LIKE scans per request with no caching layer — trivially cheap to request, near-unbounded to serve. A single bot spraying random search terms drove origin load past 100, with MySQL pegged at 425% CPU. It’s a known denial-of-service amplifier on every WordPress site.

The fix:

• Disabled internal search at the application layer — the site doesn’t depend on it — killing the secondary search queries and the SQL clause itself, not just the form.
• Leaned on the already-locked origin firewall: with the server reachable only through Cloudflare, the surface can’t be hit directly either.

Minify the HTML and rewrite URLs root-relative

Pages shipped with avoidable whitespace and fully qualified, absolute internal URLs repeated dozens of times per page — small per URL, but it adds up across a long article with many links and images.

The fix:

• Minified the HTML output through an output buffer at render time.
• Rewrote every same-origin URL to root-relative form — and locked it to the always-root-relative mode after a shortest form variant caused intermittent broken images on cached pages.
• Deliberately left feeds and srcset untouched, since feed consumers fetch from another domain.

Prefetch the next page on hover

Even when individual pages are fast, the gap between a click and the next paint is dead time that the reader feels. With the pages now genuinely cheap to serve, that gap was the next thing worth closing.

The fix:

• Enabled WordPress’s Speculation Rules API at moderate eagerness, so likely next pages will prefetch on hover.
• Kept it on prefetch rather than prerender deliberately — prerendering would have inflated ad and analytics counts with pages nobody actually viewed.

De-fork templates and delete orphaned code

The child theme contained forked copies of the parent templates that differed by a line or two, plus 27 child-only files that were no longer referenced. Dead weight like that doesn’t cost much in bytes, but it makes every future change riskier and slower to reason about — and it’s exactly where stale assets hide.

The fix:

• Removed redundant template overrides (header, footer, archive) so the child only customizes what it genuinely changes.
• Deleted 27 orphaned child-only files after confirming nothing loaded them.
• Extracted self-contained features — SVG support, security headers, Google News markup, Markdown rendering, the acronyms system — out of the theme into proper versioned plugins, so they’re portable and independently maintainable.

Strip paste-junk from content, at the source

Writing in other tools and running the Grammarly browser extension quietly injects cruft into posts — stray meta-charset tags, inline paste styles, and zero-width characters — that bloats the stored markup and occasionally corrupts the visible text. And because I paste content regularly, it kept coming back.

The fix:

• Built a cleanup plugin that fixed the back catalog (61 posts on the first run) and now runs every cleaner on save, so the junk never reaches the database again.
• Cleaned the content byte-exactly in PHP, never with collation-aware SQL, which treats zero-width characters as equal to emoji joiners and would mangle real content.

Self-heal nonces on edge-cached pages

Aggressive caching has a sharp edge: caching full HTML for 24 hours also caches the one-time security tokens (nonces) baked into interactive tools. By the time a visitor lands on a day-old cached page and clicks, that token can be expired — and the action fails silently. This is the correctness tax you pay for the speed of the first step.

The fix:

• Added a small client-side step that fetches a fresh nonce just before submitting, so the tools work no matter how long the page sat in cache.
• Applied the same self-heal pattern across every cached app endpoint that embeds a token, rather than weakening the cache to accommodate them.

How every change was verified

Touching a live database and a production cache stack this aggressively is only safe with discipline around proving each change. The repeatable rules I worked to:

• Backup first. A full database dump before any destructive sweep, plus a validated per-operation rollback for every deletion — replayed into a throwaway database to confirm the row counts matched before trusting it.
• Verify in the real runtime. Confirm changes through the actual PHP-FPM workers, not just the command line — they’re different processes and don’t reset together.
• Cache-bust to test. A unique querystring bypasses both the nginx page cache and Cloudflare, so I could see fresh PHP output before purging anything.
• Flush all four layers. After a server-side change, every layer — Redis, OPcache, nginx FastCGI, Cloudflare — gets cleared in order, because any single stale layer keeps serving the old output.
• Measure honestly. Mobile Lighthouse with the Cloudflare bot challenge blocked (it pollutes headless runs with JS real users never get), median of three runs, on a warm cache — the repeat-visitor condition that actually matters.

About doing this with Claude

I want to be straightforward about how the work got done, because the approach is genuinely part of why it worked. Every step above was carried out with Claude Code, Anthropic’s command-line agent, running against the real codebase and the production server.

The division of labor was consistent: I set the direction and made the judgment calls — what to delete, what to keep, what was worth the risk — and Claude did the labor that would otherwise drag a job like this on for weeks by hand. It read the whole database and matched orphaned tables to long-dead plugins. It wrote and rewrote the plugin code, generated the migration scripts and their rollbacks, and walked the four-layer cache flush every time.

What it did not do was run unsupervised. Every destructive change had a validated rollback before it ran, and I verified the outcome in production myself. The reason a near-twenty-year-old database could be cleaned this aggressively without breakage isn’t that the AI was infallible — it’s that the human-plus-AI loop made it cheap to be careful: cheap to take the backup, cheap to write the rollback, cheap to check the result. That’s the part I’d encourage anyone to copy.

The Ultimate ROI: Claude Code and Peace of Mind

When evaluating the cost of maintaining an optimized ecosystem of this scale, the final financial blueprint makes perfect operational sense. Rather than treating Claude Code as a one-time patch, keeping it as an ongoing $200 monthly operational expense turns the AI into a permanent dev partner that continuously manages, monitors, and optimizes the codebase alongside the new infrastructure.

When you treat both sides as ongoing monthly commitments, the annualized ROI breaks down like this:

The Net Financial Return

By shifting budget away from raw, wasted server hardware and reallocating a portion of it into an active AI subscription, the math still works out heavily in the site’s favor:

• Gross Infrastructure Savings: $336 saved per month ($4,032 annually).
• Net ROI (Savings Minus AI Expense): $136 in pure savings every month.

Even with Claude Code running as a permanent line item on the balance sheet, the site still yields $1,632 in net annual savings dropped straight back to the bottom line compared to the legacy setup.

But looking strictly at the budget sheets misses the true return on investment. The real ROI is found in things that are far harder to quantify but vastly more valuable: total peace of mind and structural stability.

Managing a high-traffic site that welcomes hundreds of thousands of visitors every month usually comes with a baseline level of low-grade anxiety. You are constantly waiting for the next traffic spike, bot scrape, or erratic plugin cron job to peg the CPU and drop the origin server. You spend hours digging through server logs, reacting to sudden outages, and obsessing over the Chrome User Experience Report (CrUX) metrics, worrying that a sudden dip in Core Web Vitals will quietly erode your hard-earned search rankings.

Today, that anxiety is entirely gone. By shifting the heavy lifting to the edge network and keeping the database pristine, the origin server barely registers a heartbeat, even under heavy automated traffic. The site is fast, resilient, and inherently stable. You cannot easily put a price tag on no longer troubleshooting midnight outages or worrying about Google’s performance penalties—but for a site of this size and history, that peace of mind is worth far more than the subscription cost it takes to secure it.

Bonus: A Comprehensive Prompt for Claude Code

To execute this optimization strategy at scale without risking production downtime, the entire process can be operationalized into a structured AI state machine. The following system prompt establishes a rigorous, continuous loop that guides an AI agent through environmental checking, database pruning, and layout verification.

By enforcing deterministic state transitions, checking for missing server extensions (such as Imagick or WebP binaries), and embedding mandatory human-approval milestones, it transforms an AI assistant into a safe, predictable co-pilot capable of carefully modernizing a complex WordPress application.

NOTE: While I have all the steps for backing up and restoring, I would absolutely recommend doing a complete file and database backup before starting this process.

# The AI WordPress Optimization State Machine Loop

You are a deterministic optimization engine operating as an automated state machine. You must maintain the loop by evaluating the current system state, running the active state instructions, and concluding every single response with your next destination state.

---

## 🌀 Loop States Matrix

* `STATE_01_DISCOVER`: Extraction, inventory build, and server capability check.
* `STATE_02_EVALUATE`: Dependency mapping & performance profiling.
* `STATE_03_PLAN_DECOMPOSE`: Logic generation & writing specific migration/rollback code blocks.
* `STATE_04_HUMAN_GATE`: Full halt. Await explicit human verification and approval.
* `STATE_05_EXECUTE`: Apply isolation sandbox modifications, pre-flight checks, and systematic cache clearing.
* `STATE_06_CWV_VERIFY`: Core Web Vitals profiling loop across targeted templates (Home, Post, Archive).
* `STATE_07_EXCEPTION_ROLLBACK`: Safety exit path triggered on performance regressions or software errors.

---

## 🔄 Core Execution States

### [STATE_01_DISCOVER]
**Objective:** Programmatically catalog the application environment and underlying system capabilities without modifying any data.
1. Run target discovery sequences to log active/inactive themes, active/inactive plugins, custom table names, metadata row counts, registered image sizes, and active Custom Post Types (CPTs).
2. **Environmental Capability Auditing:** Check the server configuration for necessary processing extensions. Verify if `imagick` or `gd` are installed, check if WebP/AVIF generation formats are supported natively by the binary layer, and verify available shell execution permissions (e.g., availability of `exec`, `passthru`, or `wp-cli`).
3. If a required optimization service or library is missing (e.g., you want to re-encode to WebP but the server lacks the image manipulation libraries), **do not guess**. Note the limitation in the inventory array.
4. **Transition Rules:**
   * Success: Move to `[STATE_02_EVALUATE]`.
   * Error / Hard Blocking Missing Dependency: Output an environmental warning block explaining what is missing, provide explicit advice on how the human can enable it on the host server, and halt until acknowledged.

### [STATE_02_EVALUATE]
**Objective:** Parse the inventory to isolate architectural waste and dead dependencies.
1. Match non-core tables against active disk directories to uncover plugins missing `uninstall.php` routines.
2. Flag orphaned metadata, redundant child theme templates, unindexed string queries (like `LIKE` searches), and global scripts loading on zero-use pages.
3. Organize optimization vectors into an impact ranking, adjusting for any environmental constraints or missing capabilities logged during discovery.
4. **Transition Rules:**
   * Elements Found: Move to `[STATE_03_PLAN_DECOMPOSE]` for the highest-ranked item.
   * Tree Clean: Move to `[STATE_06_CWV_VERIFY]` for front-end template profiling.

### [STATE_03_PLAN_DECOMPOSE]
**Objective:** Write pristine, self-contained execution code for the selected candidate.
1. Generate the exact **Migration Script** (pure SQL, WP-CLI, or targeted PHP script).
2. Generate a matching, atomic **Rollback Script** capable of perfectly reversing the migration.
3. **Transition Rules:**
   * Scripts Generated: Move to `[STATE_04_HUMAN_GATE]`.

### [STATE_04_HUMAN_GATE]
**Objective:** Mandatory human-in-the-loop validation safety brake.
1. Present the explicit migration strategy and the rollback code block to the developer.
2. **STRICT RESTRAINT:** Stop all execution completely. Do not run any code blocks.
3. **Transition Rules:**
   * Human inputs "APPROVED": Move to `[STATE_05_EXECUTE]`.
   * Human inputs "REJECT / ABORT": Return to `[STATE_02_EVALUATE]` to select a different target or recalculate.

### [STATE_05_EXECUTE]
**Objective:** Isolate sandbox changes and run structural cache sweeps after verifying final environmental readiness.
1. **Pre-Flight Capability Verification:** Perform a final runtime sanity check right before script execution to guarantee the PHP environment or SQL engine can physically compute the instructions (e.g., confirming memory limits or execution timeouts won't crash mid-batch during an image or database compression routine).
2. If the capability validation fails unexpectedly: Halt execution immediately, skip the migration step, and report the specific environmental restriction back to the human along with actionable infrastructure mitigation advice.
3. Take a selective production database snapshot table backup.
4. Run the approved Migration Script.
5. Execute the deep application cache purging workflow:
   * **PHP Layer:** Clear OPcache compiled data.
   * **Application Layer:** Flush the Object Cache (Redis/Memcached).
   * **Server Layer:** Wipe Nginx FastCGI storage paths.
   * **Edge Network Layer:** Trigger a global Cloudflare edge cache purge.
6. **Transition Rules:**
   * Execution Successful: Move to `[STATE_06_CWV_VERIFY]`.
   * Pre-Flight Guardrail Tripped: Return to `[STATE_04_HUMAN_GATE]` with structural error logs and configuration advice.

### [STATE_06_CWV_VERIFY]
**Objective:** Core Web Vitals performance loop for targeted views (**Home Page** → **Single Post** → **Archive**).
1. Demand the human paste raw mobile Lighthouse metrics, Core Web Vitals indicators (LCP, INP, CLS), or server error logs for the current template under inspection.
2. Review the data against a strict constraint: **Changes must maintain 100% pixel-perfect visual fidelity**.
3. If bottlenecks or layout shifts are flagged, emit exact code diffs and repeat the **Deep Cache Purge Checklist**.
4. **Transition Rules:**
   * Regression / Error Detected: Move to `[STATE_07_EXCEPTION_ROLLBACK]`.
   * Mobile CWV Score Not Peaked: Repeat `[STATE_06_CWV_VERIFY]` for the same view.
   * Mobile CWV Score Peaked: Advance template view. If all views pass, terminate loop.

### [STATE_07_EXCEPTION_ROLLBACK]
**Objective:** Automated safety rescue mechanism.
1. Abort the runtime process immediately.
2. Execute the corresponding Rollback Script from `[STATE_03_PLAN_DECOMPOSE]`.
3. Re-run the deep cache-purging sequence across OPcache, Object Cache, FastCGI, and Cloudflare to scrub the broken application state.
4. Output a comprehensive failure diagnostic report.
5. **Transition Rules:**
   * Rollback Verified & Stack Restored: Return to `[STATE_02_EVALUATE]` with the item marked as blocked.

---

## 📋 Directives for Your Next Response

To begin the loop, look at my next message and respond strictly using this format:

```text
======================================================================
CURRENT STATE: [Insert Active State Name]
CURRENT TARGET: [Insert Current Component/Template Under Review]
======================================================================

[Your explicit analysis, environment capability warnings, code diffs, or instructions matching the active state directives]

======================================================================
NEXT STATE DESTINATION: [Insert State Matrix Code Here]
======================================================================