# ci-github

Lane C implementation of AWP's I0 GitHub Actions `CIProvider` boundary.

## Dispatch and reconciliation

`GitHubCIProvider` dispatches a configured repository workflow and passes only two correlation inputs:

- `awp_operation_key` — deterministic `awp:<OperationId>:<candidate-prefix>`;
- `awp_candidate_digest` — exact candidate revision the workflow must verify.

The project-owned workflow must use the operation key as its `run-name` and check out/verify the candidate digest. This makes a retry discover the already-created workflow run instead of blindly dispatching a duplicate. A timeout after `workflow_dispatch` is reconciled before surfacing failure. If GitHub has accepted the dispatch but the run is not visible yet, the adapter returns a correlation reference and later `reconcile()` resolves it to the provider run ID.

The HTTP transport uses only GitHub Actions and branch-protection status-check endpoints. It has no ref-update, commit, merge or pull-request mutation method. Credential material is obtained by `CredentialReferenceId` for one operation and disposed after every HTTP request; it is never projected into ARC runner pods.

## Required project workflow contract

A compatible workflow includes the equivalent of:

```yaml
run-name: ${{ inputs.awp_operation_key }}
on:
  workflow_dispatch:
    inputs:
      awp_operation_key: { required: true, type: string }
      awp_candidate_digest: { required: true, type: string }
```

Its checkout/test steps must verify `awp_candidate_digest`; the dispatch ref is only the trusted location of the workflow definition.

## Required checks

`listRequiredChecks()` reads GitHub branch protection required contexts/checks. AWP I1 can consume these real provider requirements for MergeGate rather than fabricating an internally green receipt. Full CI planning/optimization remains I5.

## ARC

ARC is runner infrastructure only. Scale-set and trust-profile manifests live under `infra/arc/**`; no ARC native identity becomes an AWP CI identity.