How it works

A sluiceway is a channel with a gate. Changes queue up behind the gate, and you decide what passes.

1. After a merge to the default branch, and once a day, a scan previews the stacks in the repo.
2. The scan writes the dashboard issue: one row per stack, and a box on every stack that has changes waiting.
3. You tick a box. That asks for that stack to be deployed exactly as its row shows it.
4. Sluiceway checks that you may tick that stack, and previews it again. It deploys only if the fresh preview still matches the row.
5. The row goes back to in sync, or says why the deploy failed, with a link to the run.

The issue is a view and never the source of truth. What is pending is always worked out again from a fresh preview. It works with Pulumi and OpenTofu, side by side in one repo if you like. For OpenTofu, a tick deploys the very plan file whose diff was approved. CONTEXT.md defines the words used here and in the code.