CI/CD adapters

CI/CD adapters normalize repository, pipeline and deployment operations without giving AI direct write access to a protected branch.

Adapter matrix

Adapter	Mock behavior	Live boundary
GitHub Actions	Seeded devopsify-demo/app; pipeline reaches RUNNING, then SUCCEEDED	Connection validation and branch listing are wired; other live methods are explicit TODOs
GitLab CI	Seeded devopsify-demo/backend; same deterministic poll behavior	Connection validation and branch listing are wired; other live methods are explicit TODOs
Generic webhook	Delivery progresses QUEUED -> RUNNING -> SUCCEEDED	No fake live adapter; repository mutation and deployment are unsupported

The common adapter includes connection validation, branch/commit/file reads, patch branches, commits, pull requests, protected-branch checks, pipeline trigger/status/logs, deployment status and rollback. Unknown repositories, runs or deployments fail instead of silently succeeding.

Pipeline-to-deployment flow

trigger branch -> pipeline run -> poll status -> deployment request
       |                                      |
       +--> failed: stop                       +--> verify health
                                              |
                               failed verify +--> rollback available

The current API exposes repository, pipeline, pipeline-run, deployment and rollback routes. The worker's pipeline.monitor polls and can fan out to deployment.verify. Deployment-set waves are a stricter frozen-target contract described separately.

AI repository changes

AI repository changes follow proposal -> validated diff -> approval -> branch -> patch -> tests -> optional PR. The guardrail engine denies force pushes, direct protected-branch edits, path traversal, secret files and unauthorized workflow changes. A missing protected-branch fact defaults to protected. A model response is only input to this pure validation step; it cannot write directly to a repository.