Self-Healing Patches

When Overseer detects a production error, it classifies the fix type and applies the appropriate delivery strategy. Four fix types cover the full spectrum, from instant config changes to complete rebuilds.

Fix types

Every proposed patch is classified into one of four types based on what needs to change. The classification determines the delivery mechanism and the approval policy.

DATA_FIX

Config, database record, or feature flag changes. Applied via Vercel Edge Config. Instant, no rebuild needed. Safe DATA_FIX patches can be auto-approved when autoApplyDataFix is enabled.

EDGE_FIX

UI and frontend patches delivered via Client-side Runtime Patching (CRP). The SDK's PatchRuntime polls a manifest endpoint and applies DOM operations: text-replace, css-inject, attr-modify, html-replace, and script-inject. Seconds to apply.

INCREMENTAL

Backend code changes. Overseer commits the fix to a branch and triggers a Vercel micro-deployment targeting only the affected service. Minutes to apply.

STANDARD

Complete rebuild. Overseer suggests a fix, creates a pull request against main, runs the full CI pipeline, and waits for explicit approval. Once approved and merged, a full production build and deployment is triggered. Used for cross-cutting changes, migrations, and dependency updates.

Patch lifecycle

Every patch follows a deterministic pipeline from detection to monitoring.

DetectOverseer captures the error via the SDK and creates an issue.

ClassifyThe fix is classified as DATA_FIX, EDGE_FIX, INCREMENTAL, or STANDARD based on the affected files and error context.

ProposeA concrete patch is generated with code diffs, config changes, or DOM operations.

ValidateThe patch is validated against type checks, test suites, or manifest schemas.

Review gateAn Inbox notification is created. Safe DATA_FIX patches can be auto-approved; all others require explicit approval.

ApplyThe patch is delivered through the appropriate channel (Edge Config, CRP manifest, or micro-deployment).

MonitorOverseer watches for regressions. If the error resurfaces, the patch is flagged for manual review.

SDK configuration

Enable self-healing in your Codmir.init() call. The selfHealing block controls which fix types are auto-applied and how frequently the PatchRuntime polls for new manifests.

import * as Codmir from '@codmir/sdk/nextjs';

Codmir.init({
  dsn: process.env.NEXT_PUBLIC_OVERSEER_DSN,
  selfHealing: {
    enabled: true,
    autoApplyDataFix: true,
    autoApplyEdgeFix: false,
    manifestPollInterval: 30, // seconds
  },
});

enabledMaster switch. When false, the PatchRuntime is not initialized.

autoApplyDataFixAutomatically apply DATA_FIX patches that pass validation. Skips the Inbox review gate for safe config changes.

autoApplyEdgeFixAutomatically apply EDGE_FIX patches. Defaults to false because DOM mutations carry higher risk.

manifestPollIntervalHow often (in seconds) the PatchRuntime checks for new EDGE_FIX manifests. Default is 30.

CRP operations

The Client-side Runtime Patching engine supports five DOM operation types. Each operation in the manifest specifies a CSS selector, the operation type, and the payload.

text-replaceReplace text content within a matched element.

css-injectInject or override CSS rules on matched elements.

attr-modifyAdd, update, or remove HTML attributes.

html-replaceReplace the inner HTML of a matched element.

script-injectInject a script tag. Restricted to same-origin URLs for security.

Security

Self-healing patches modify production behavior, so every layer is authenticated and auditable.

Manifest signingAll CRP manifests are signed with HMAC-SHA256. The PatchRuntime verifies the signature before applying any operations. Tampered manifests are rejected and logged.

Script origin policyscript-inject operations are restricted to same-origin URLs. Cross-origin scripts are blocked by the runtime.

Audit trailEvery patch action is recorded as a PatchEvent with the actor ID, timestamp, action type (propose, approve, reject, apply, rollback), and the full patch payload.

Deploy authBranch commits and Vercel deployments use scoped tokens. The deployment targets only the affected service, not the full application.

Review gate

Every proposed patch creates an Inbox notification with the full diff, risk assessment, and one-click approve/reject actions. The review gate ensures no patch reaches production without accountability.

Auto-approveOnly available for DATA_FIX (when autoApplyDataFix is true) and EDGE_FIX (when autoApplyEdgeFix is true). INCREMENTAL and STANDARD always require manual approval.

RollbackApplied patches can be rolled back from the Inbox at any time. DATA_FIX reverts the Edge Config value, EDGE_FIX removes the manifest entry, INCREMENTAL promotes the previous deployment, and STANDARD triggers a revert commit on main.

EscalationIf a patch is pending review for too long, the notification escalation chain is triggered: Inbox, email, mobile push, and eventually phone call for P0 issues.

Time to resolution

Patch delivery speed depends on the fix type. All times measured from approval to production.

DATA_FIXInstant. Edge Config propagation is sub-second.

EDGE_FIXSeconds. Limited by the manifestPollInterval (default 30s).

INCREMENTALMinutes. Includes branch commit, CI validation, and Vercel micro-deployment.

STANDARD5–15 minutes. Full cycle: PR creation, CI pipeline, review approval, merge to main, and complete production rebuild.

Error Tracking SDK Documentation Performance Monitoring