What Is LiveGuard?

The forge builds your software. LiveGuard watches the gates after it ships.

The Problem LiveGuard Solves

Plan Forge sessions end when the code ships. The forge hardens your plan, executes your slices, and pushes a clean commit. Then it stops, because that's the right boundary for a build-time tool.

But software doesn't stop when the build does. Secrets drift into environment variables. Dependencies acquire CVEs. Configuration diverges between environments. The regression gate you wrote last month no longer covers the new payment flow. None of these are build-time failures, they're post-coding failures. And without a watch on the gates, they grow silently until they become incidents.

LiveGuard is what watches after the forge stops.

LiveGuard Intelligence

LiveGuard doesn't just observe, it learns. Every finding feeds back into the system:

• Recurring Incident Detection, When the same files trigger incidents 3+ times in 30 days, LiveGuard auto-escalates the severity and marks the pattern as systemic.
• Fix Proposal Outcome Tracking, When a regression guard passes after a fix proposal was generated, the proposal is marked as "effective." Over time, the system learns which fix patterns work.
• Hotspot Test Priority, High-churn files (from forge_hotspot) are tested first by the regression guard. Risk-based testing, test the code most likely to break.
• Project Health DNA, A composite fingerprint combining drift score, incident rate, test pass rate, model success rate, and cost per slice. Persisted to .forge/health-dna.json for cross-session decay detection.

The Lifecycle Position

LiveGuard occupies the operational phase, after code is shipped but before (and alongside) production APM:

The forge pipeline (Chapters 1–14) covers everything left of the arrow. LiveGuard picks up at the right.

What LiveGuard Is Not

LiveGuard is not an APM (Application Performance Monitoring) system. It doesn't instrument your production runtime, collect request traces, or measure p99 latency. Tools like Datadog, New Relic, and Application Insights already do that well.

LiveGuard operates at the project level, not the request level. It watches your codebase, your environment files, your dependency tree, and your deployment history, the things that change between builds, not between HTTP requests. Think of it as a quality gate that stays active between coding sessions.

The Guardian Metaphor

In the forge metaphor, the build pipeline is the smith, it shapes raw material into a finished product. LiveGuard is the guardian posted at the gate after the smith finishes. The guardian doesn't shape the metal; it watches for cracks, drift, and intrusions that appear over time.

Each LiveGuard tool is a different kind of watch:

• Drift watch, architecture diverging from the plan baseline (forge_drift_report)
• Incident watch, production failures and MTTR tracking (forge_incident_capture)
• Dependency watch, new CVEs in your dependency tree (forge_dep_watch)
• Regression watch, validation gates that used to pass now fail (forge_regression_guard)
• Churn watch, files that change too frequently signal instability (forge_hotspot)
• Secret watch, high-entropy strings committed in diffs (forge_secret_scan)
• Env watch, configuration key divergence across environments (forge_env_diff)

When to Run LiveGuard Tools

LiveGuard tools are designed for three trigger points:

In v2.29, lifecycle hooks automate this, PreDeploy runs secret scan and env diff automatically before any deploy command, and PostSlice runs drift analysis after every commit.