# Cige Product Defect Escalation

> Use when cige-failure-classification identifies a Product Defect -- execution reached a healthy system with current steps, but the outcome contradicts Intent. Fetches specRef and buildRef to file a defect or, only with human approval, propose an Intent update.

- Skill: `vivekkrishna/cige-product-defect-escalation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vivekkrishna/cige-product-defect-escalation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vivekkrishna/cige-product-defect-escalation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vivekkrishna (https://skillmd.com/u/vivekkrishna)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vivekkrishna/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

| Field | Permission |
|---|---|
| `Context` | Read-only (uses `specRef` and `buildRef`) |
| `Intent` | May *propose* update — **human approval required**, Case B only |
| `Guardrails` | Never touch |
| `Execution[]` | Never touch |

## 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.