Architecture

A change moves through five steps.

1. The preview job runs pulumi preview --json on every stack the pull request reaches.
2. plywood groups the previews into one change set with a digest per stack and one over the set. It posts one note.
3. A reviewer runs plywood approve, which records an approval of that digest.
4. The canary wave updates first after merge, and each later wave follows it. A wave whose preview no longer matches the approved digest waits at its own gate.
5. Each step leaves a row in the chant workspace ledger in your repository.

Who does each part

Part	Owner
The program, the engine, providers and the backend	Pulumi (or plunge)
Change sets, gates, the workspace ledger, target locks, and the one product pipeline that posts notes and statuses	chant
plywood.yml, defaults, the words on notes, statuses and comments (/plywood up), init templates and these docs	plywood

plywood holds opinion and chant holds capability. plywood and terragucci share every chant CI feature, and each page here links chant’s own docs for the feature it switches on. The update itself runs through chant’s Pulumi lexicon, the same way terragucci’s applies run through chant’s Terraform lexicon.

Where things live

Nothing is hosted. Approvals and overrides are rows in the chant workspace ledger on your repository’s chant/lifecycle branch, and so are gate decisions and run records. The stack export after each update goes to refs/chant/snapshots, and state stays in your backend. Approvals are records.