# Incident Page UI

**Status:** Approved target-state behavior  
**Activation:** I8.

## Page Job

Answer:

```text
What broke and what is the impact?
Which lifecycle/project/resources are affected?
What has AWP already tried?
What is the current safe state?
What evidence/root cause do we have?
What action/resolution happens next?
Was the fix verified and learned for reuse?
```

## Header

Incident severity/status, concise impact statement, Project/affected primitive links, opened time/current owner, current resolution state and primary action if human intervention is required.

## Main Sections

```text
Impact / affected lifecycle
Timeline
Evidence / classification / root cause
Resolution attempts
Current action / waiting reason
Proposed code/config change links
Verification of resolution
Reusable ResolutionRecipe (if proposed/accepted)
```

## Timeline

Human-readable chronological events: detection, retries, deterministic recipe, resolver starts, proposed ChangeSet, review/merge/deployment, health verification, resolution/reopen. Raw logs linked secondarily.

## Resolution Attempts

Each shows deterministic/agentic resolver identity, capabilities, model/account if agentic, exact actions/outputs, result/evidence and whether another attempt is active.

## Human Attention

If approval/choice required, the relevant card appears near top with recommendation, consequence, safe current state and one primary action. Do not force user to inspect all logs before understanding the decision.

## Reusable Recipe

A learned recipe is shown only after review/verification; users can see applicability/scope/version and source Incident. Generated unreviewed script is clearly not trusted library state.

## States

open/triaged, resolving, waiting provider/human, verification/monitoring, resolved, reopened, degraded data/provider, stale telemetry.

## Responsive / Accessibility

Timeline and attempts stack cleanly; logs/evidence use drawers. Severity is text+icon, not color only. Focus jumps to newly required attention only when appropriate, not every realtime event.

## URL Truth

Stable Incident route; selected attempt/evidence/timeline anchor may be URL state. Links preserve affected primitive context.

## Increment Realization

Earlier domain-specific failure UI links to structured errors; I8 activates full Incident page. I9 may add support/on-call/reliability references.

## High-Fidelity Requirements

Before I8: active deterministic attempt, resolver agent attempt, human approval, resolved with verified recipe, reopened and provider-degraded state.

## Target State

Incident is the human-readable operational failure and resolution-history surface over canonical Incident/ResolutionAttempt/ResolutionRecipe state. It preserves what failed, what was tried, what changed, how recovery was verified and what knowledge became reusable without forcing users to reconstruct raw logs.

## Primary Users / Jobs

- owner/operator: understand impact, current safe state and whether human action is needed;
- resolver/engineering lead: inspect evidence and previous resolution attempts before selecting the next action;
- reviewer: verify that a proposed reusable recipe/fix has passed normal ChangeSet/Review/Verification before trust.

## Entry / Exit Points

Entry: failure state from Factory/CI/Deployment/Cluster, `OPERATIONS -> Incidents`, Attention, Home/Project health, search. Exit: affected primitive, ResolutionAttempt/Agent, ChangeSet/Review/CI/Deployment evidence, Approval, or reusable recipe detail.

## User Journeys

### J1 — Understand incident and current safe state

```text
open Incident
 -> read impact + affected primitives + current state
 -> scan timeline and attempts already made
 -> inspect current waiting/resolution owner
 -> open exact evidence/root cause only as needed
 -> understand next expected action
```

### J2 — Deterministic recovery first

```text
known failure classification
 -> choose qualified ResolutionRecipe/provider-native recovery
 -> capability/policy check
 -> durable ResolutionAttempt
 -> observe actions/result
 -> verify resolution against required health/evidence
 -> resolve or continue escalation
```

### J3 — Agentic resolver escalation

```text
no deterministic recipe / recipe failed
 -> launch bounded resolver AgentRun
 -> inspect diagnosis/proposed fix
 -> code/config fix enters ChangeSet -> Review -> Verification
 -> deploy/apply through normal lifecycle
 -> monitor health
 -> Incident resolves or reopens
```

### J4 — Learn a reusable recipe safely

```text
successful novel resolution
 -> resolver proposes candidate recipe
 -> review scope/preconditions/idempotency/rollback
 -> normal Review + Verification
 -> accepted versioned ResolutionRecipe
 -> future matching Incident can prefer it deterministically
```

## Data / Source of Truth

Incident, ResolutionAttempt and ResolutionRecipe state are authoritative. Source Factory/CI/Deployment/Cluster domains remain authoritative for their own lifecycle. Logs, telemetry and provider events are evidence with provenance/freshness. Agent-generated diagnosis is not trusted resolution fact until verified.

## Actions / Authorization

Retry, recipe execution, resolver launch, production/destructive remediation and recipe trust all use configured capabilities/Policy/Approval. A resolver never broadens its own authority. Code/config changes always follow normal ChangeSet/Review/Verification.

## Async / Duplicate-Mutation Safety

Resolution actions create durable ResolutionAttempt identity, acknowledge immediately, are idempotent/reconcilable and expose phase/result. Duplicate recipe execution cannot silently repeat destructive actions. Stale/degraded evidence remains readable, but protected remediation requires authoritative state/policy refresh.

## Invariants From Day 1

- retry success does not erase failure/attempt history;
- deterministic proven recovery precedes expensive agentic diagnosis when applicable;
- existing harvested Overdeck recovery knowledge is qualified before replacement;
- generated recipe is untrusted until reviewed/verified;
- resolver changes use the normal software-delivery lifecycle;
- resolved Incidents can reopen/link without losing history;
- raw logs are evidence, not the default explanation.

## Current Implementation State

Target page only. Earlier increments surface domain-specific structured failures; generic Incident product/UI activates I8.

## Deferred Realization

Advanced root-cause correlation, external on-call/support integration and enterprise reliability references are later/triggered capabilities, not baseline requirements.

## Temporary Dogfood Behavior

Before I8, a structured failure/Needs Attention surface may link retries and resolution history without a full Incident page. It must not create invisible shell-script recovery paths that bypass attribution/evidence.

## Related Contracts / Decisions

- [`../domains/incidents-resolvers.md`](../domains/incidents-resolvers.md)
- [`../workflows/incident-to-resolution.md`](../workflows/incident-to-resolution.md)
- [`factory-run.md`](factory-run.md), [`ci.md`](ci.md), [`release-deployment.md`](release-deployment.md), [`cluster.md`](cluster.md), [`approval.md`](approval.md)
- Overdeck recovery-script harvest and no-rebuild rules are binding inputs to deterministic recipe implementation.

## Decisions / ADRs

Resolver authority, recipe trust and provider/native recovery choices remain constrained by Policy/Approval and reuse/FOSS decisions. New trusted recovery subsystems require explicit Decision/spec amendment.

## Visual Mockup Authority

No I8 Incident high-fi is approved yet. Deterministic attempt, agentic resolver, human approval, resolved verified-recipe, reopened and provider-degraded states require explicit approval before Incident UI implementation.

## Acceptance

A user can understand an operational/software-delivery failure and AWP's remediation history without reconstructing events from Kubernetes/CI/deployment logs.