# CI Page UI

**Status:** Approved target-state behavior  
**Compact evidence earlier:** I1  
**Full activation:** I5.

## Page Job

Answer:

```text
What verification was required for this change?
What ran, reused, was omitted or failed?
Why did each check matter?
Is the result current for this exact candidate?
What blocks the next gate?
What remediation is happening?
```

The page is an AWP CI control-plane view, not a thin iframe/link collection over GitHub Actions.

## Header

Project/ChangeSet/CIExecution context, exact source/candidate identity, overall gate state, provider status, elapsed/latest update and primary action (`Resolve failure`, `Retry infrastructure`, `View correction`, etc.) when actionable.

## Expected vs Executed

Core table/list:

```text
Invariant / check        Expected   Execution            Evidence       Why
Architecture boundaries required   GitHub #... passed   current        changed domain
Unit behavior            required   reused receipt       current        affected module
Browser E2E              omitted    —                    —              no affected CUJ
Compatibility            required   oasdiff failed       blocking       public API
```

States explicitly distinguish expected, executed, not started, reused, omitted-with-reason, skipped, failed, infrastructure error and stale/invalidated.

## Why / Evidence

Each check opens context: requirement source (Task/Policy/CIInvariant/provider required check), exact definitions/revision, execution provider/job, logs/artifacts, retry history, candidate/environment identity and invalidation reason.

## Resolution

Failed items show classified failure and current remediation:

- deterministic retry/reconcile;
- correction AgentRun;
- resolver agent;
- human attention;
- missing connection/capability.

One primary next action follows policy/current resolution state.

## Provider Detail

Direct GitHub workflow/job links remain available. Raw provider topology/logs are drill-down, not the main interpretation layer.

## States

- planning/queued;
- running;
- blocked/failing;
- infrastructure degraded;
- waiting correction/attention;
- passed/current;
- stale/invalidated after candidate/config change;
- cancelled/superseded.

## Responsive / Accessibility

Wide tables may become grouped cards on small screens while preserving columns as labels. Keyboard can filter by status/invariant and open evidence. Progress updates use restrained live announcements.

## URL Truth

Stable CIExecution route; selected check/invariant/run may be URL state. Links back to exact ChangeSet and forward to Merge/Release gate.

## Increment Realization

I1 shows compact required-check/evidence summary inside Review. I5 activates dedicated page. I6 adds Release/Deployment gate relationships; I8 Incident/resolver links.

## High-Fidelity Requirements

Before I5: normal mixed expected/executed/reused state, active run, failed/resolving, stale evidence and provider-degraded variants.

## Target State

CI is the explainable verification-control surface over AWP CIExecution, invariants, impact planning and admitted evidence. It tells the user what correctness required and why, while GitHub Actions/ARC or another provider only executes mechanics.

## Primary Users / Jobs

- engineer/reviewer: determine whether the exact candidate has sufficient current evidence;
- delivery lead: understand blockers, omitted work and remediation state;
- CI owner/optimizer reviewer: inspect why checks were selected/reused/omitted and later evaluate proposed CI-policy improvements.

## Entry / Exit Points

Entry: Review evidence summary, `EXECUTION -> CI`, Project CI health/queue, Attention, Release gate, search. Exit: exact ChangeSet/Review, check evidence/log/artifact, correction AgentRun, Incident/Resolver, MergeGate or Release/Deployment.

## User Journeys

### J1 — Explain current CI result

```text
open CIExecution
 -> confirm exact candidate/definitions
 -> scan expected vs executed/reused/omitted
 -> inspect why each check is required or omitted
 -> open evidence for one check
 -> return to overall gate state
```

### J2 — Resolve a failure

```text
blocking check fails
 -> classify code/test/policy/infrastructure failure
 -> show current resolver/correction owner
 -> deterministic retry if safe, otherwise correction/resolver/attention
 -> new evidence admitted only for exact current candidate
 -> gate recomputes
```

### J3 — Handle stale evidence

```text
candidate/config/definition changes
 -> affected receipts become stale/invalidated
 -> page explains invalidation cause
 -> planner schedules smallest required replacement checks
 -> new/current evidence arrives
 -> gate becomes current or remains blocked
```

### J4 — Propose CI optimization later

```text
historical executions
 -> optimizer identifies redundancy/missing coverage
 -> proposal references evidence and expected effect
 -> normal AWP Decision/ChangeSet/Review flow
 -> policy changes only after review/verification
```

## Data / Source of Truth

CIExecution, CIInvariant/Check requirements, execution plan/result and VerificationEvidence are AWP truth. GitHub workflow/check/job identity and ARC runner data are provider mappings. Logs/artifacts are evidence. The agent/optimizer cannot declare CI green or silently weaken required policy.

## Actions / Authorization

Retry infrastructure, start correction/resolver, cancel and CI-policy mutation require their configured capabilities/policy. Provider retry is allowed only when it preserves correctness/idempotency. Changes to invariants/optimizer policy are normal reviewed changes, not hidden page toggles.

## Async / Duplicate-Mutation Safety

Retry/cancel/resolution actions acknowledge immediately, identify exact CIExecution/check attempt, prevent duplicate submit and survive navigation. Candidate/definition revisions are included in command preconditions. Stale/disconnected state is readable but protected actions require authoritative refresh.

## Invariants From Day 1

- expected and executed are distinct concepts;
- omitted/skipped always has an explicit reason and policy source;
- current evidence binds exact candidate/definitions/environment as required;
- retries never erase failed-attempt history;
- provider green status cannot bypass VerificationAuthority;
- optimizer may propose but never silently weaken CI.

## Current Implementation State

Target page only. I1 persists a thin final-form evidence summary in Review; dedicated CI page activates I5.

## Deferred Realization

Impact graph, full evidence ledger/invalidation, CI resolver/optimizer and efficiency analytics deepen at I5. I6 adds delivery gates; I8 generic Incident links.

## Temporary Dogfood Behavior

I1 can rely on actual GitHub required checks plus compact AWP evidence receipts. It must not introduce a temporary custom CI engine or treat a raw workflow-run page as product authority.

## Related Contracts / Decisions

- [`../domains/ci.md`](../domains/ci.md)
- [`../domains/verification.md`](../domains/verification.md)
- [`../workflows/change-to-ci.md`](../workflows/change-to-ci.md)
- [`../workflows/ci-resolution.md`](../workflows/ci-resolution.md)
- [`review.md`](review.md), [`incident.md`](incident.md), [`release-deployment.md`](release-deployment.md)
- GitHub Actions + ARC is the initial provider substrate, not CI semantics.

## Visual Mockup Authority

No dedicated I5 CI high-fi is approved yet. The required mixed/current, running, failed/resolving, stale and provider-degraded states must be approved before dedicated CI UI implementation.

## Acceptance

An engineer can tell exactly why CI is green/red/incomplete, what was intentionally not run and what happens next without interpreting a wall of workflow logs.