Cige Product Defect Escalation

CIGE: ProductDefectAgent

Invoked by cige-failure-classification when a run is classified as a Product Defect: execution reached the system under test, the environment is healthy, execution steps are current — but the outcome does not match Intent.

When to invoke

• Execution reached the system under test
• Environment is healthy (ruled out by cige-failure-classification as Infrastructure Failure)
• Execution steps are current (ruled out as Outdated Test Logic)
• The observed outcome contradicts Intent

This is also the escalation target when cige-stale-execution-repair (Mode A) cannot find any execution path that satisfies Intent within Guardrails — that usually means the failure was misclassified as stale execution when it's really a defect.

What it does

1. Read Intent (what was expected) and capture actual system behavior (what happened).
2. Fetch specRef (the BRD / product spec) and buildRef (the tested build's release documentation) to determine ground truth. Four cases:

Case A — specRef unchanged, system diverged. The system broke. This is a confirmed product defect. → File a bug report with: Intent, actual behavior, specRef snapshot, execution trace. → Do not modify the test definition.

Case B — specRef was recently updated, buildRef's release documentation confirms the tested build actually includes that update, and system behavior matches the new spec. The product intentionally changed, and this build actually shipped it. The Intent in the test is now stale. → Propose an Intent update that aligns with the new specRef. → Surface the proposed change for human approval before any write. → Guardrails are never touched, even though the spec changed.

A spec being updated and behavior superficially matching it is not sufficient for Case B on its own — the spec could have been edited ahead of the actual release, or the match could be coincidental. Confirming the build correlation via buildRef is what separates Case B from Case D.

Case C — specRef is unreachable or missing. Classification cannot be completed. → Halt and flag the missing specRef as a test-authoring gap. → Do not guess — require specRef to be provided before proceeding.

Case D — specRef was updated and behavior matches the new spec, but buildRef is missing/unreachable, or its release documentation does not confirm the change shipped in this build. The build/spec correlation needed for Case B cannot be confirmed. → Do not propose an Intent update — a superficial match is not evidence of an intentional change without build confirmation. → Flag the missing or inconclusive buildRef as a test-authoring gap, the same way Case C requires specRef. → Treat the underlying failure conservatively: log it as an unconfirmed defect pending human confirmation of the build/spec correlation, rather than filing a bug (Case A) or proposing an Intent change (Case B) on incomplete evidence.

Field permissions

Supervised Intent Evolution — the only path Intent may change

Intent is the most protected field in CIGE. It evolves under exactly one sequence, never as a side effect of a failing test:

1. specRef is updated by a product owner or author.
2. This skill detects that system behavior now matches the new spec, and confirms via buildRef that the tested build actually shipped that change (Case B above).
3. Propose the Intent update with a diff: old Intent, new spec language, proposed new Intent.
4. A human reviews and approves the change.

This is not self-healing — it is supervised intent evolution: acknowledging the product changed, not that the test failed.

Rule: Never modify Intent to make a failing test pass. That is intent corruption, not self-healing. If you find yourself proposing an Intent change without both a specRef diff and a buildRef confirmation to point to, stop — you're in Case A, C, or D, not Case B.

Human gate

Always required. No autonomous writes to Intent under any condition — this skill only ever proposes.