# CI Resolution Workflow

**Status:** Approved target-state baseline  
**Activation:** I5.

## Target State

CI failures are resolved through the smallest trustworthy loop, preferring deterministic fixes and evidence reuse before agentic intervention.

```text
CIExecution / Verification gate blocked
  -> classify failure
       infrastructure/provider/transient?
          -> deterministic retry/reconcile recipe
       known mechanical project failure?
          -> deterministic ResolutionRecipe
       semantic/code/config failure?
          -> correction Task / AgentRun
       unknown persistent blocker?
          -> Resolver agent within policy
  -> proposed change or recovered execution
  -> focused re-verification
  -> gate re-evaluation
  -> close linked Incident/ResolutionAttempt when verified
```

## Failure Classification

At minimum distinguish:

- product/test failure;
- build/configuration failure;
- runner/provider infrastructure failure;
- dependency/network/transient failure;
- permission/secret/connection problem;
- flaky/retry-sensitive result;
- compatibility violation;
- missing/unavailable required check capability;
- cancelled/stale execution.

Classification determines whether code should change, infrastructure should retry, user authorization is required, or a resolver should intervene.

## Deterministic Before Agentic

Known safe remediation recipes execute before starting a resolver model. Recipes are versioned, scoped and verified. A newly generated script/recipe is not trusted automatically: it becomes a normal reviewed/verified artifact/change before reusable promotion.

## Evidence Rules

- reuse still-valid evidence from the candidate;
- rerun only failed/invalidated/required checks unless a concrete blast-radius reason requires broadening;
- retry history remains visible;
- pass-after-fail does not erase prior failure and can trigger flake treatment;
- correction ChangeSet revision invalidates only affected evidence where determinable.

## Resolver Agent

A resolver receives structured failure context, relevant logs/evidence, repository state and configured capabilities. It cannot merge, alter protected policy or broaden credentials. Any source/config change returns through Task -> ChangeSet -> Review -> Verification.

## Human-in-the-Loop

Policy can require attention for security findings, test deletion/modification, architecture changes, repeated flaky results, unusual privilege or unresolved ambiguity. Attention item explains blocker, recommendation and consequence.

## Failure / Recovery

Control-plane/provider restart resumes durable CI resolution workflow. If the resolver itself fails, preserve its Attempt and evidence, then retry/select another eligible resolver according to policy.

## Increment Realization

I1 exposes simple failed check/correction behavior. I5 activates classification, deterministic resolver catalog, VerificationAuthority integration and agentic resolution. I8 generalizes the same resolver model into cross-domain Incidents.

## Acceptance

A failing CI result cannot be turned green merely by retrying blindly or editing test expectations without governed evidence. User can see what failed, what remediation ran, what changed, and why the gate is now satisfied or still blocked.