---
name: loom-ci-cd-and-automation
description: "Use when changing pipeline or automation behavior itself: CI gates, build/deploy workflows, release automation, preview/staging/prod environments, credentials, artifacts, or pipeline-specific failure recovery."
---

# loom-ci-cd-and-automation

CI/CD and automation is a playbook for executable quality gates and release paths.

It specifies pipeline behavior, implements it in scoped tickets, records observed
pipeline results, and audits risky automation changes.

## Core Dependency

Use `loom-core` first. This playbook composes `loom-specs`, `loom-plans`,
`loom-tickets`, `loom-evidence`, `loom-audit`, `loom-research`, and
`loom-retrospective`.

## Use This Playbook When

Use this playbook when:

- setting up or changing CI checks
- adding lint, type check, test, build, security, bundle, or E2E gates
- configuring preview, staging, production, rollback, or release automation
- debugging CI failures
- changing deployment credentials, environments, or secrets handling
- adding automation that agents or humans will rely on for closure claims

## Route

Use this route:

```text
contract -> pipeline -> implement -> observe -> harden -> recover
```

## Contract

Use `loom-specs` when pipeline behavior is durable.

Specify:

- triggers
- required checks
- environments
- secret boundaries
- artifact retention
- branch or tag behavior
- failure behavior
- manual approval points
- rollback or retry behavior
- what evidence a passing run provides

Use `loom-plans` when the automation change spans several tickets or migration
stages.

## Pipeline Shape

Common gates:

- install with locked dependencies
- formatting or lint
- type check
- unit tests
- integration tests
- build
- E2E tests when critical flows require them
- security or dependency audit
- bundle or performance budget
- artifact upload on failure
- preview deploy
- staging verification

Gate order should fail early on cheap deterministic checks and preserve artifacts
for expensive failures.

## Implement

Use tickets for scoped changes.

Implementation guidelines:

- keep secrets in CI secret stores
- avoid logging credentials or tokens
- use least-privilege tokens
- pin versions when reproducibility matters
- cache dependencies without hiding stale lockfile failures
- keep generated artifacts out of Git unless the project expects them
- document local equivalents of CI checks when developers need them

## Observe

Record evidence for meaningful pipeline behavior:

- successful run URL and checked jobs
- failed run and diagnostic excerpt
- artifact paths
- local reproduction command and output
- before/after behavior for a pipeline fix
- skipped or unavailable checks

Use `loom-evidence` when a ticket or audit will rely on pipeline output.

## Harden

Use `loom-audit` when automation changes affect releases, secrets, production,
security gates, or deployment permissions.

Audit questions:

- can a bad change bypass required checks?
- are secrets exposed in logs or artifacts?
- do permissions exceed need?
- are deployment triggers correct?
- are rollback and failure modes observable?
- do artifacts contain sensitive data?

## Recover

When CI fails, use `loom-debugging-and-error-recovery`:

- preserve the failure output
- reproduce locally when possible
- fix root cause
- update evidence
- add prevention if the failure revealed a recurring trap

## Done Means

The CI/CD pass is done when:

- pipeline behavior is specified or scoped
- automation changes are implemented in bounded tickets
- passing and failing behavior was observed where relevant
- secrets and permissions were checked
- evidence supports the claimed gate
- risky automation changes received audit