Changes in 0.4.7

Release 0.4.7 is on npm as @intentius/terragucci@0.4.7, and its GitHub release lists every change.

To upgrade	Run
Each repo	npx @intentius/terragucci@0.4.7 init, then merge the pipeline it writes
Each approver	terragucci approve where you ran chant approve; installing terragucci is enough (approve)

In 0.4.7

What	Where
A wave refused because its plans moved after the approval names the terragucci approve command for the new plans	Fix a refused wave

In 0.4.6

What	Where
Approvals are one command, terragucci approve, for waves, migrations, state exports, lock releases and pull request environments, and every printed hint names it	approve
The choudoufu image runs choudoufu 0.25.0. Resource history lists each choudoufu record’s past versions, and the estate page shows the count	Change history

From 0.4.5

0.4.6 carries every change of 0.4.5, listed by area below. Upgrading from 0.4.4 or earlier, also note:

From 0.4.4	Run
A Terragrunt repo that uses generate	terragucci generate again, so each unit’s state key reads the ephemeral suffix (In a Terragrunt repo)

• Changed default: a pull request that changes a Terragrunt unit also previews the units that depend on it, provisional and outside every digest. Set terragrunt.dependents: follow to keep the old behavior (The terragrunt block).
• Applies now run per root. With stock binaries, two overlapping pushes to one root can fail the newer apply with “Saved plan is stale”; run it again and it plans again (Two applies of one estate).

Applies and locking

What	Where
Pushes that change different roots apply at the same time; a root’s own applies take turns at its state lock, and a superseded push stands down	Applies side by side
With choudoufu, a wave waits only for a run changing one of its own resources	Two applies of one estate
The choudoufu image runs choudoufu 0.24.0: a killed apply leaves records for the resources it finished	Stock and choudoufu
One page for every lock layer, from the backend’s state lock to choudoufu, with the claims behind each by repo shape and forge	Locking and staleness
A gated choudoufu wave whose approved apply was killed or failed applies the rest under the same approval, and the resume job finds a killed one	Stopped applies
A choudoufu wave’s run view shows each resource done, in flight or waiting while it applies, read from the estate’s records	Progress

Plans and waves

What	Where
waves.after orders plain roots that no terraform_remote_state read links	Root order
The plan note’s blast radius lists each changed resource and the resources that depend on it, in its root and in roots that read an output it reaches	Resources in the radius
Every backend type gets a state address (local, pg, http, consul, kubernetes, remote), and config check names a read it cannot resolve	State addresses
ephemeral gives each open pull request its own copy of the roots you name, behind a gate, destroyed after a TTL; Terragrunt units and synthesized roots too	Ephemeral environments
apply.branches maps a branch to root or unit globs, and a push there applies those alone behind the gate; drift plans them from their branch	Apply from other branches
A re-plan started by workflow_dispatch, with a pull request and an optional root	Re-plans by dispatch

State

What	Where
oidc.roles gives each environment’s roots their own plan and apply roles, and config check warns when one role serves two	Keep each environment’s roles to its own state
terragucci state export downloads a state version locally, after a second person approves, with an audit entry	Export a state version
The estate page marks each cross-state read stale, current or unknown against the producer’s last apply	Cross-state edges
GitLab-managed state: each apply records its serial, and state export, unlock-state and ephemeral copies work on it	GitLab-managed state
gcs and azurerm roots get state versions, state export, unlock-state and migrations, and oidc.gcp.roles and oidc.azure.roles give each environment its own identity	GCP and Azure
A backend move reads an HCP Terraform, Scalr or OTF workspace over the TFE API, or an exported state file	Workspaces
With choudoufu, which keeps per-resource state with no database to run, migration files retag resources between roots and adopt a root from a state file	Estates
Migrations move state to and from pg, kubernetes, consul and http backends, which keep no versions	Unversioned backends

Repo shapes

What	Where
Terragrunt units get cost, steps, waves.jobs, drift pull requests and attribution, migrations, per-unit version pins, generate and state export	Differences
A Terragrunt pull request plans each later layer on the earlier layers’ planned outputs, never on mock_outputs	Later layers
Units a terragrunt.stack.hcl generates go through every stage	Explicit stacks
generate.disable_init: false, and the apply job has Terragrunt create the state bucket	Bucket bootstrap
Atmos instances as roots, in waves from dependencies.components, with roles by stack	Use Atmos
Terramate stacks as roots, in waves from after and before, with outputs sharing; stale generated code fails the job	Use Terramate

Binaries

What	Where
Terraform and choudoufu pass the core claims OpenTofu passes	Validation
Drift on a choudoufu root under live resource markers, from a normal plan	Live roots

Agents and review

What	Where
terragucci mcp, a read-only MCP server over what the runs wrote	Read the estate over MCP
agent.drift opens a pull request that fixes drift	Have an agent fix drift
The AI review runs from the default branch’s workflow, so a pull request cannot change the review it gets	The review
GitLab gets the agent comment, the AI review and waves.jobs	The agent comment

Your setup

What	Where
runner picks each stage’s runner: runs-on on GitHub and Forgejo, tags on GitLab	Self-hosted runners
pass hands named CI secrets and variables to the jobs that plan, apply and check drift	Secrets and variables
A JSON Schema for terragucci.yml, for config check and your editor	Schema
own_jobs keeps your own jobs in the pipeline across init runs	Jobs of your own
A Terraform and OpenTofu provider manages the control repo’s projects and defaults	Manage the control repo with Terraform
modules.registry serves module releases over the registry protocol from a bucket or Pages site	Serve a module registry

Estate and reports

What	Where
terragucci query runs SQL over the reports bucket, in process	Query the estate with SQL
An optional resource graph beside the estate page, with drift marked	A resource graph beside the page

Moving to terragucci

What	Where
terragucci import hcp, import otf and import scalr write terragucci.yml from a platform’s workspaces over its API	Import the workspaces
terragucci import spacelift and import env0 write terragucci.yml from their config files and admin Terraform	Coming from Spacelift or env zero
terragucci import terragrunt-scale keeps a Terragrunt Scale repo’s plan and apply roles per environment	Terragrunt Scale
Guides for HCP Terraform, Scalr and OTF, and for Spacelift and env zero	Coming from HCP Terraform, Scalr or OTF, Coming from Spacelift or env zero
A Standards section: the open standards terragucci uses, and its tacos.guru answers	Standards

Fixes

What	Where
unlock-state on a choudoufu root under live markers says there is nothing to release	Release a state lock
An Atmos pull request that changes a stack manifest locks the instances it reaches	Pull requests
A CDK Terrain pull request in a repo that synthesizes its stacks locks every stack	Pull request locks
On Forgejo, a pipeline with more than five levels of job dependencies plans	Pipeline
A pull request whose format fix was pushed gets its lock answer	Plan locks
A live block inside terraform makes a root	Choose a binary