Cige Failure Classification

CIGE: Failure Classification (Dispatcher)

Use this skill immediately after any CIGE test run completes — pass or fail — and before any repair action is taken. It classifies the outcome and names which skill, if any, is allowed to act on it. Classification is not optional and not skippable: no agent may repair a test it has not been dispatched to.

When to invoke

• A test run just finished, regardless of result
• You are deciding whether a "pass" was actually a false positive
• You need to know which self-healing skill is allowed to touch a given failure

For the CIGE format itself, see cige-test-authoring. This skill only decides what happens after a run.

The Decision Flow

This mirrors the CIGE runtime workflow: reveal minimal context → run execution with guardrails → classify → repair → replay → human review → commit.

Run execution with guardrails
        │
        ▼
   Failure? ──No──▶ False Positive? ──No──▶ Store evidence, mark pass
        │                   │
       Yes                 Yes
        │                   │
        ▼                   ▼
  Classify failure    Dispatch to cige-stale-execution-repair
        │              (Mode B — guardrail strengthening)
        │
   ┌────┼────────────────┐
   ▼    ▼                ▼
Infra  Outdated        Product
Fail   Test Logic      Defect
   │    │                │
   ▼    ▼                ▼
cige-   cige-stale-      cige-product-
environ execution-       defect-
ment-   repair (Mode A)  escalation
recovery
   │    │                │
   └────┴────────────────┘
             │
             ▼
   Replay in isolated environment
             │
             ▼
      Human review and commit

A false positive — the run reports pass, but the pass doesn't hold up (a shortcut satisfied the letter of Execution without the evidence Guardrails actually require) — is checked even when there was no Failure. Don't skip this check just because the run looked clean.

Classifying a Failure

Classify by elimination in this order: check Infrastructure first (did execution even reach the system?), then Outdated Test Logic vs. Product Defect (does specRef still describe today's expected behavior?), and treat False Positive as a check on every apparent pass, not just failures.

Rule: If you cannot confidently classify, do not guess and do not repair. Halt and surface the ambiguity — an unclassified failure routed to the wrong skill is exactly how a field-mutation boundary gets violated.

Field Mutation Rules (master table)

This is the single source of truth for which field each self-healing skill may write. Each agent skill restates only its own row — if you find a discrepancy, this table wins.

Two invariants hold regardless of classification:

• No skill may modify Intent autonomously — cige-product-defect-escalation may only propose, and only under the supervised-intent-evolution sequence.
• No skill may ever loosen or remove a Guardrail. The one write path to Guardrails is strictly additive, human-gated, and scoped to cige-stale-execution-repair's Mode B.

An agent that reaches outside its field boundaries has misclassified the failure — stop and reclassify, don't let the write happen.

Run Summaries

Every classification produces a short summary, whether or not a repair followed:

{
  "testId": "checkout-happy-path",
  "runDate": "2026-04-16",
  "result": "pass | fail | self-healed",
  "failedStep": "e3",
  "failureType": "outdated-test-logic | product-defect | infrastructure | false-positive",
  "recoveryAction": "StaleExecutionAgent updated e2, e3 — approved by human",
  "intentUnchanged": true
}

Write this even for a clean pass (failureType omitted, recoveryAction omitted) — future runs read the summary history first to spot patterns (e.g. the same step repeatedly needing execution repair may itself be a signal worth escalating) before deciding whether to run the full test or investigate first.

Rule: Never let a repair happen without this classification step first, and never let a dispatched skill run without this step having named it explicitly.