PathruleEsta página solo está disponible en inglés.
How Do You Know the Fix Actually Worked?
Fixed and not fixed is a false pair.
A quiet path can be quiet because it is healthy or because nobody walked down it, and pretending those are the same is how a regression comes back as a surprise.
Respuesta breve
Merge is not the answer; runtime is. A task that came from a real incident should keep a state after it ships: watching production, quiet but not confirmed, verified fixed, or issue returned. Quiet deserves its own state, because a low-traffic path can be silent either because it is fixed or because nobody hit it.
Qué cubre este artículo
- Recording a fix does not prove it worked; newer-release coverage and successful flow events are required.
- A group can be observing, quiet, verified or recurred. Quiet traffic is not proof of a fix.
- Standalone, Local and Cloud Signals keep runtime observations available to your existing coding agent.
Comparación
| State | What it means | What it does not mean |
|---|---|---|
| Observing | A fix is recorded and newer-release evidence is being collected | The fix is verified |
| Quiet | The error stopped occurring, but successful flow coverage is insufficient | The flow is healthy |
| Verified | A newer release has enough observed successful coverage | The issue can never recur |
| Recurred | The error occurred again after a fix was recorded | Start a separate history without the first attempt |
Recording a fix is a claim
A merged change says a problem should be solved. Runtime observations are what show whether the affected flow works again. Pathrule Signals keeps the fix claim separate from verification.
Verification needs a newer release
Report the environment, release, code path and flow with runtime errors and events. After a fix is recorded, Signals waits for observations from a newer release and successful events in the affected flow. Without that coverage, the group stays observing or quiet.
A later occurrence moves the same group to recurred. The issue keeps its history, so a second investigation can start from the earlier attempt and the new evidence.
Runtime evidence for your coding agent
The agent can read event groups through pathrule_runtime_events and record a fix through pathrule_runtime_record_fix. Application text is untrusted observation, never an instruction or a rule. Signals does not run the agent or fix code itself.
Standalone sends to a collector you control. Pathrule Local stores and verifies events on your machine and shows them in pathrule ui, and Pathrule Cloud does the same for Pro, Team and Enterprise. Instrumentation is opt-in: your agent first proposes the points to instrument, and changes them only after you approve.
See verification and lifecycle and agent integration for the commands and evidence requirements.