What is Molar Guard?

PR gating, production monitoring, shadow-prod diff, and Mender auto-fix — one scenario file across four surfaces.

What is Molar Guard?

Molar Guard is the continuous quality surface of the Molar platform. It turns Cartographer-generated scenarios (or your existing Playwright tests) into a closed loop:

PR gate → production monitor → shadow-prod diff → AI auto-fix PR

One scenario file runs locally, on every PR against deterministic Clones, in production against synthetic users, and drives autonomous fix PRs (Mender) against your application repository — with affected-scenario selection, shadow-prod diff, and fixes aimed at your product code.

Product page: guard.molar.it · Dashboard: app.molar.it/dashboard/guard

One scenario, four surfaces

The composability story is Guard's core mental model. The same .molar.md scenario (or Playwright spec discovered by Guard) runs in four contexts without re-authoring:

SurfaceWhere it runsWhat it proves
LocalYour machine or CI sandboxThe flow works against your dev stack
PR gatingEvery pull request, against fresh ClonesChanged code did not break affected user journeys
Production monitoringScheduled synthetics against real prodCritical flows still work for real users
Shadow-prod diffParallel prod + Clone runYour model of third-party vendors (Stripe, Twilio, Clerk) is still correct

When any surface fails, Mender triages root cause and can open a fix PR — against your application code, not just the test file.

.molar/scenarios/signup.molar.md
    ├── molar run signup              → local
    ├── PR webhook / GitHub Action    → Clones + affected selection
    ├── scheduled_checks (cron)       → prod synthetics
    └── shadow_prod: true             → prod ∥ Clone semantic diff
              │
              └── failure → Mender → [Molar Mender] fix PR

Three subsystems

Guard ships as three coupled subsystems over one scenario catalog, shared guard_runs data, and BullMQ workers.

A. PR gating

GitHub App (or standalone GitHub Action) runs affected scenarios on every pull request. Results appear as a Check Run on the PR — the primary merge gate — plus a sticky PR comment with failure cards and Mender previews.

Key capabilities:

  • Affected-scenario selection — static dependency graph + predictive reranker; only scenarios touched by the diff run (not the full suite every time)
  • Required vs advisory mode — block merge on failure, or comment-only during onboarding
  • Run caching — skip scenarios already green on an ancestor commit
  • Fresh Clones per PR — deterministic, isolated third-party state; destructive calls to real vendors blocked

Deep dive: PR gating

B. Production monitoring

Scheduled Playwright synthetics run against your real production URL on a cron (default every 5 minutes). Synthetic users are marked at the HTTP, browser, and database layers so they never pollute analytics or trigger real charges.

Key capabilities:

  • Multi-region fan-out — us-east-1, eu-west-1, ap-south-1 (additional regions on higher tiers)
  • Incidents — deduplicated failure groupings with ack, suppress, and auto-resolve
  • Alerting — generic webhooks, Slack, PagerDuty, Microsoft Teams, Opsgenie, and email (via your notification webhook)

Deep dive: Production monitoring

C. Mender (AI auto-fix)

When a scenario fails, Mender classifies the failure (flake, env, scenario_bug, product_bug), then optionally opens a GitHub PR prefixed [Molar Mender]. Humans always review; Mender never merges its own PRs.

Deep dive: Mender auto-fix

Shadow-prod diff

Guard can run the same scenario against real production and a Clones replica in parallel and diff the responses. Because Molar owns stateful vendor fakes (Stripe, Twilio, Email, Clerk, S3), Guard can alert when a third-party API shape drifts from your model — before your app code changes.

Examples: Stripe adds a field to customer.subscription.updated, Twilio changes MessageStatus callback format, Clerk adds a required JWT claim.

Deep dive: Shadow-prod diff

How Guard fits in the Molar platform

  • Cartographer produces .molar/scenarios/ and the scenario dependency graph Guard uses for affected selection.
  • Clones provide deterministic vendor state for PR runs and shadow-prod comparison.
  • Trace composes with Guard for run replay and step-level debugging (deep link from check run detail).

Guard also works standalone via the GitHub Action for hosted PR checks on a registered scenario — no Molar Molar API required in your repo.

Deployment modes

ModeWhoExperience
Molar-hostedMost customersSign up at app.molar.it, install GitHub App, use app.molar.it/dashboard/guard
Self-hostedAir-gapped / BYOCRun Guard API, worker, and dashboard from your self-host bundle; Postgres, Redis, object storage via Docker Compose
Action-onlyQuick adoptionRegister a scenario UUID, add guard.yml workflow with API key; zero @molar/* deps in your repo

Dashboard overview

At app.molar.it/dashboard/guard:

AreaPurpose
Overview / Production guardPR gate summary, monitoring health, open incidents
RunsRun explorer (PR, schedule, manual, shadow_diff)
Production guard → MonitoringScenarios × regions health grid (live from Guard API)
IncidentsOperational response with ack/suppress
Auto-fix (Fixbots)Human-in-the-loop Mender queue
Shadow-diffReview prod vs Clone drift for a run
SettingsGitHub install, synthetic safety, API keys, Mender policy

See Guard dashboard for page-by-page detail.

Getting started

  1. Quick start — local dev, CLI, Docker Compose, GitHub Action
  2. PR gating — GitHub App install, required checks, affected selection
  3. Production monitoring — schedules, synthetics, incidents
  4. Configuration — molar-guard.config.ts and scenario frontmatter

Next