vivekkrishna CIGE: StaleExecutionAgent
Invoked by cige-failure-classification in two situations: Outdated Test Logic (Mode A — repair Execution[]) and a confirmed False Positive (Mode B — strengthen Guardrails). These are different repairs with different targets; do not conflate them.
When to invoke
- Mode A: Execution steps fail mid-flow (element not found, endpoint 404, workflow step no longer exists), and
specRefconfirms the intended outcome is still a valid product requirement. - Mode B: A run reported pass, but
cige-failure-classificationconfirmed it was a false positive — the evidence backing the pass was weak or gameable, not that the steps were wrong.
If neither condition is confirmed, do not use this skill.
Mode A — Repair Execution
- Read
Intent(the goal to preserve) andGuardrails(constraints that apply during repair). - Fetch
specRefto confirm the intended outcome is still a stated product requirement. - Inspect the current system state (live UI, API schema, current workflow) to understand what changed.
- Propose new
Execution[]steps that achieveIntentwithinGuardrails. - Dry-run the proposed steps to verify
Intentcan still be confirmed. - Surface the proposed diff to a human for approval — do not commit without sign-off.
Escalation rule: If no execution path can confirm Intent within the existing Guardrails, stop — this may be a misclassified Product Defect. Escalate to cige-product-defect-escalation rather than forcing a repair that technically passes.
Mode B — Strengthen Guardrails (the narrow exception)
A false positive means the steps "worked," but the pass shouldn't have counted — the test's evidence bar was too weak to catch an invalid end-state (e.g. it accepted UI success text without checking the backend record it implies). The fix targets Guardrails, not Execution.
- Read the false-positive report from
cige-failure-classification: what state was accepted as a pass, and why it shouldn't have been. - Propose an additive guardrail or evidence rule that would have caught this specific gap (e.g. "require backend order-service confirmation, not UI text alone").
- Never remove, weaken, or relax an existing guardrail as part of this repair — this mode only adds constraints, it never loosens them.
- Replay the test with the proposed guardrail in an isolated environment to confirm it still allows the true-positive path to pass and correctly blocks the false-positive path.
- Surface the proposed diff (old Guardrails, new Guardrails, the false positive it addresses) to a human for approval — do not commit without sign-off.
Field permissions
| Field | Permission |
|---|---|
Context |
Never touch |
Intent |
Never touch |
Guardrails |
Write — Mode B only, additive/strengthening only, never loosen or remove, human approval required |
Execution[] |
Write — Mode A only, human approval required |
This is the only skill in the CIGE self-healing set permitted to write to Guardrails, and even here the write is one-directional (stricter only) and always human-gated. If a proposed change would remove or weaken any existing guardrail, that is out of scope for this skill — halt and escalate for human review instead of applying it.
Human gate
Required before committing either an updated Execution[] (Mode A) or a strengthened Guardrails entry (Mode B). This skill proposes; a human approves. This is what prevents silent intent drift disguised as execution repair, and what prevents guardrail creep disguised as test-quality improvement.