Meet "Alfred", the Automated Tech Lead

Alfred is the tech-lead half of the agentic-employee model — the counterpart to Agatha on the QA side. Where Agatha checks pages after they exist, Alfred checks code while it's being written.

The idea: rather than pushing rules at Lovable with background scripts and fixing the output afterwards, Aegis becomes an MCP server that Lovable's AI consults during development. Lovable is the client, Aegis is the server, and bad code is caught at the source and rewritten before it's ever committed.

Status: built and live. This page used to be an unapproved proposal. The architecture below was implemented — see §4 for what actually shipped and where the remaining gap is.

1. Aegis as an MCP server

The Admin worker hosts an MCP server at POST /api/mcp, with a reduced Lovable-scoped surface at POST /api/mcp/lovable. Transport is Streamable HTTP, stateless — each request builds its own server instance, so there is no session affinity to reason about on Workers.

The Integrations panel in the Admin dashboard generates the connection URL you paste into Lovable's MCP settings.

2. The audit tools

Two static-analysis tools, backed by admin/src/auditLogic.js:

aegis_proxy_audit — for React apps served through the Aegis proxy:

  • no <iframe>
  • a basename in React Router (or base in vite.config.ts)

aegis_shopify_audit — for native Shopify pages, additionally:

  • no dangerouslySetInnerHTML — real JSX, with images imported explicitly
  • internal <a href> converted to React Router <Link>; external links carry target="_blank" rel="noopener noreferrer"
  • react-helmet (or equivalent) for title/meta/OpenGraph rather than hardcoded head tags
  • no double-slash paths (src="//…"), which break nested assets behind the proxy
  • Tailwind utility classes rather than inline style={{…}}

When code fails, the tool returns the specific rules broken, and Lovable's AI rewrites to comply. That feedback loop — a failure payload precise enough to act on — is the whole mechanism.

3. The auto-fix prompt library

Two MCP prompts carry the canonical guidance, loaded from the qabot_test_templates table so they can be edited without a deploy:

  • lovable_proxy_autofixes — routing/basename, no iframes, componentisation, Tailwind
  • lovable_shopify_autofixes — the full native-Shopify conversion rules

Known Lovable failure modes these address:

Failure Fix
Double-slash injection breaking nested CSS/JS/images Normalise URL concatenation
Missing trailing slashes breaking React Router inside Shopify Exact-match the route index against the basename
BrowserRouter colliding with Liquid routing Use MemoryRouter on export
Assets hardcoded to .lovable.app Strip origin domains from src=
Iframes Don't
Everything dumped into one Index.jsx Break into components under components/
Missing fonts/icons because the HTML <head> isn't deployed @import FontAwesome and Google Fonts at the top of the index file
Uncontrolled forms useState + onSubmit with preventDefault()
Missing SEO tags react-helmet

4. The deployment enforcer — and its gap

Promote in the Admin dashboard runs a final scan before anything goes live: it reads the repo tree from the GitHub API, pulls the entry file, runs the audit for the chosen destination, and returns DEPLOYMENT BLOCKED BY AEGIS MCP ENFORCER with the specific failures if it fails. This catches code that bypassed the MCP tool and was pushed straight to GitHub.

Two limitations to know about:

  1. It audits one file. The first match of src/App.tsx, src/pages/Index.jsx, src/pages/Index.tsx or index.html. A violation living in a component file isn't seen — which is a little ironic, given that componentisation is one of the things the rules ask for.
  2. It fails open. The whole enforcer is wrapped in a try/catch that logs and continues. If the GitHub call errors, the entry file isn't found, or the audit throws, promotion proceeds silently as though it passed.

So treat the enforcer as a strong nudge, not a hard gate. Closing these two gaps — auditing the full src/ tree and failing closed on enforcer errors — is tracked as remaining work.

5. Why client/server this way round

Making Lovable the client and Aegis the server is what makes this work. Aegis doesn't need to watch repos, poll for pushes, or reconcile after the fact — it answers questions during generation, at the point where the AI is still willing to rewrite. The enforcer at promote time is the backstop, not the primary mechanism.