choudoufu

Compatibility reference

Mon, 01 Jan 0001 00:00:00 +0000

Compatibility reference#

What choudoufu admits and refuses: the provider and resource types, how a configuration must be written, and how it may be run.

This is the enumerated list. For why static evaluability is the rule behind most of it, see Identity. To check your own configuration against this list, see How to check a configuration before migrating.

Your provider#

AWS only. Every google_*, azurerm_*, kubernetes_* and helm_* resource is refused. There is no second cloud on the roadmap (#5).

How to check a configuration before migrating

Mon, 01 Jan 0001 00:00:00 +0000

How to check a configuration before migrating#

Run choudoufu live-check against any OpenTofu configuration:

choudoufu live-check ./

Point it at any OpenTofu configuration. No live block, no cloud calls, no requirement that the directory has heard of this fork. It prints a verdict, then every refusal that fired with its site count, the types responsible, and what to do about each.

Run choudoufu init first if you can. With provider schemas available it judges types from the provider’s own identity schema as well as the built-in table, and admits more. Without them it says the answer is pessimistic.

How to scope a role to an estate

Mon, 01 Jan 0001 00:00:00 +0000

How to scope a role to an estate#

The whole estate#

Two statements, because creating and mutating are conditioned by different keys.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "MutateOnlyThisEstate",
 "Effect": "Allow",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags", "ec2:TerminateInstances"],
 "Resource": "*",
 "Condition": {
 "StringEquals": {"aws:ResourceTag/tofu-estate": "prod-networking"}
 }
 },
 {
 "Sid": "CreateOnlyIntoThisEstate",
 "Effect": "Allow",
 "Action": ["ec2:RunInstances", "ec2:CreateTags"],
 "Resource": "*",
 "Condition": {
 "StringEquals": {"aws:RequestTag/tofu-estate": "prod-networking"}
 }
 }
 ]
}

aws:ResourceTag reads a tag off a resource that already exists, so it governs everything the estate acts on. It cannot govern a create, because no resource exists yet to carry the tag. What the creating principal supplies is aws:RequestTag, and conditioning on that is what makes the second statement a grant to create into this estate rather than a grant to create anything.

Identity

Mon, 01 Jan 0001 00:00:00 +0000

Identity#

Which real resource a configuration address refers to. AWS already knows this, once you tell it.

Two tags, written as the resource is created.

tofu-estate = prod-networking
tofu-address = aws_vpc.main

That pair is the entire ownership contract. Any tool that can write two tags can adopt a resource. Any tool that can read them can tell you what an estate contains.

Tutorial: see markers work

Mon, 01 Jan 0001 00:00:00 +0000

Tutorial: see markers work#

In about two minutes, a real VPC, subnet, security group, S3 bucket and log group will exist inside a local AWS emulator. choudoufu will build them, delete its own state file, and rebuild its bookkeeping from nothing but two tags read straight off those live resources. Then it will drift three of them behind its own back, out of band, and correct exactly what drifted and nothing else. Every claim in this walkthrough is checked by the same run, not described after the fact.

How to stop a staging role reaching production

Mon, 01 Jan 0001 00:00:00 +0000

How to stop a staging role reaching production#

Pointing a staging configuration at a production account is a familiar outage. Nothing structurally prevents it today, because it is the same principal making the same API calls either way. IAM has nothing to tell the two runs apart.

Markers give it something to tell them apart by.

The policy#

Attach this to the role your staging runs use.

{
 "Sid": "NeverMutateAnotherEstate",
 "Effect": "Deny",
 "Action": [
 "ec2:TerminateInstances",
 "ec2:DeleteSubnet",
 "ec2:DeleteVpc",
 "rds:DeleteDBInstance"
 ],
 "Resource": "*",
 "Condition": {
 "StringNotEquals": {"aws:ResourceTag/tofu-estate": "staging"}
 }
}

A mistake now fails at the cloud rather than at review. The guardrail sits below the tool, so it holds whatever the tool was pointed at, whatever directory someone was standing in, and whatever the plan said.

Migrate an existing estate

Mon, 01 Jan 0001 00:00:00 +0000

Migrate an existing estate#

Most people arrive here, with an OpenTofu configuration already managing live AWS resources.

Migrating means binding those resources to your configuration, one marker at a time, until each carries its own ownership record. It does not happen automatically and the failure mode is quiet.

Turning on live markers does not bind resources you already manage. A resource with no marker is not yours yet, so the first plan reads it as absent and proposes a second one beside it. Applying that plan does not fail. It creates the duplicate.

Values

Mon, 01 Jan 0001 00:00:00 +0000

Values#

Most resources need nothing here. A resource with a cloud twin recovers its values by reading the live object, the same way it recovers its identity.

The exceptions are resources with no twin at all. Nothing in AWS knows a null_resource ran a script, a time_static captured a timestamp, or a random_pet generated a name.

Those persist as one small record each. Declare a store and they are admitted. Without one they are refused.

Day-2 operations

Mon, 01 Jan 0001 00:00:00 +0000

Day-2 operations#

Running an estate after the first apply. Renaming, removing, recording effects the cloud cannot report, and working with other people.

Task	Page
Rename a resource	How to rename a resource
Stop managing or destroy a resource	How to stop managing or destroy a resource
Record an effect the cloud cannot report	How to record an effect the cloud cannot report
Look up what a `policy` setting does	The ownership policy matrix
Understand what happens when two runs overlap	Two runs at once

There is no remote state to read. live/OUTPUTS.md covers the cross-estate pattern, and data "terraform_remote_state" is refused.

Effects

Mon, 01 Jan 0001 00:00:00 +0000

Effects#

A migration that ran. A cache that was invalidated. A notification that was sent. None of them leaves anything in the cloud to read back, so no plan can tell you whether it already happened.

A receipt is how you make it visible.

What a receipt is#

An ordinary resource you declare, by convention an SSM parameter at /tofu-receipts/<estate>/<effect> holding a hash of the effect’s input.

How to cover every team with one policy

Mon, 01 Jan 0001 00:00:00 +0000

How to cover every team with one policy#

This is attribute-based access control, ABAC, applied to the resources your configuration manages.

A policy per team is a policy set that grows with the org chart and drifts between its members. ABAC exists to avoid that, and it needs an attribute on the resource to match against. Markers are one, written on every resource the estate manages rather than applied by a convention someone has to remember.

How to deny creating anything unowned

Mon, 01 Jan 0001 00:00:00 +0000

How to deny creating anything unowned#

Tag compliance is normally retroactive. A scanner finds untagged resources, a ticket asks someone to explain them, and the backlog never empties because new ones arrive faster than old ones are resolved.

Conditioning creation inverts it. Ownership stops being something a resource acquires later and becomes a precondition of existing.

The policy#

As a service control policy, applied to the accounts that hold estates.

How to rename a resource

Mon, 01 Jan 0001 00:00:00 +0000

How to rename a resource#

Rename the resource block, then rewrite the marker.

choudoufu live-mv aws_vpc.old aws_vpc.new

That rewrites the tofu-address tag on the live resource carrying the old address. The tag write is the move, so moved blocks are refused. Resources never adopted are left alone.

A destination address absent from your configuration is refused unless you pass -allow-missing-config. -dry-run shows what it would write. Full options in choudoufu live-mv -help.

Start a new estate

Mon, 01 Jan 0001 00:00:00 +0000

Start a new estate#

For an estate with nothing in it yet, where choudoufu creates every resource.

If AWS already holds resources this configuration should manage, read Migrate an existing estate first. Nothing binds a live resource to your configuration until its markers are on it, so applying against unmarked resources creates a second copy beside them.

Install#

Every tagged release carries prebuilt binaries for macOS, Linux and Windows on amd64 and arm64, plus a SHA256SUMS file.

Two runs at once

Mon, 01 Jan 0001 00:00:00 +0000

Two runs at once#

Ownership lives on the resources themselves, and records settle concurrent writes by conditional write. Two simultaneous applies against one estate resolve one of four ways.

Race	Outcome
Two creates of the same client-named resource	The cloud’s uniqueness constraint rejects the second. The loser re-plans, binds to the winner’s resource, and comes back clean.
Two creates of the same server-assigned resource	Both are created. The next plan reports a marker collision naming both live IDs and refuses rather than guessing. A human deletes one.
Divergent in-place updates	Last writer wins at the API. The next plan reads the live system and converges.
An update racing a destroy	The loser gets not-found, re-plans, and converges.

No race orphans a resource silently. Each case is a clean re-plan or a named collision.

Questions

Mon, 01 Jan 0001 00:00:00 +0000

Questions#

Two questions with no other home. Everything else that used to live on this page has a real page now: what changes for you is in The three pieces, self-service tagging and IAM in Scoping a role, storage in Where things are stored, migration in Migrate an existing estate, marker stripping in Identity, and concurrent applies in Two runs at once.

Why is it called choudoufu?#

Stinky tofu. Off-putting at first, and people who like it like it a lot.

Where AWS honours the condition

Mon, 01 Jan 0001 00:00:00 +0000

Where AWS honours the condition#

Where the key is confirmed#

17 of 180 services in AWS’s Service Authorization Reference name aws:ResourceTag on their tagging action. That is a lower bound. The reference is authoritative about what it names and silent about what it omits, and AWS documents tag-based authorization for services it says nothing about, Lambda among them.

Service	IAM prefix	Actions naming it	Of total
EC2	`ec2`	495	793
ResilienceHub	`resiliencehub`	57	128
SES	`ses`	48	228
AutoScaling	`autoscaling`	42	68
ECS	`ecs`	37	81
Kinesis	`kinesis`	31	40
CertificateManager	`acm`	20	41
CleanRooms	`cleanrooms`	12	107
ElastiCache	`elasticache`	11	77
CloudWatch	`cloudwatch`	7	67
SageMaker	`sagemaker`	7	444
WorkSpaces	`workspaces`	7	101
KafkaConnect	`kafkaconnect`	2	18
AuditManager	`auditmanager`	1	62
Batch	`batch`	1	45
CUR	`cur`	1	12
SSMQuickSetup	`ssm-quicksetup`	1	14

Services with no verdict#

The reference states nothing either way for these. Check them against AWS’s own IAM documentation and test the policy. This is not a list of services where scoping fails.

How to stop managing or destroy a resource

Mon, 01 Jan 0001 00:00:00 +0000

How to stop managing or destroy a resource#

Deleting a resource block leaves its marker on the live object, and the sweep destroys a marked, undeclared, taggable resource on the next plan. That matches upstream without a removed block.

To stop managing something without destroying it, change what happens to a resource you no longer declare.

# estate.chdf.hcl
estate = "my-estate"

policy {
 undeclared_tagged = "untag"
}

untag removes this estate’s marker and leaves the resource running. keep leaves both alone. The ownership policy matrix has the rest of the verbs.

How to write markers inside a for_each'd module

Mon, 01 Jan 0001 00:00:00 +0000

How to write markers inside a for_each’d module#

Instances of a for_each’d module share one HCL body for tags, so no single literal address is correct for all of them and auto-stamping cannot reach inside. choudoufu leaves such a resource alone when it already declares tags, and raises a must-stamp error when it declares none and its type needs discovery.

Thread the module’s own each.key through and build the address from it.

How to record an effect the cloud cannot report

Mon, 01 Jan 0001 00:00:00 +0000

How to record an effect the cloud cannot report#

Nothing in the live system records that a database migration, a script, or a one-shot API call happened, so no marker reads back.

null_resource, terraform_data, time_* and non-secret random_* work once the live configuration declares a record_store.

# estate.chdf.hcl
estate = "my-estate"

record_store "ssm" {}

The label picks the backend, one of local, ssm or s3. Where things are stored has “Choosing a record store backend” for which one to pick, what each holds, and why a receipt must not go in there. Those resources then run the stock provider lifecycle exactly as upstream.

Where things are stored

Mon, 01 Jan 0001 00:00:00 +0000

Where things are stored#

choudoufu writes in three places. Two can both end up as SSM parameters, which is why they get confused. They do different jobs and have different owners.

What	Where it lives	Who reads it	Losing it costs
Ownership markers	Two tags on the resource itself	choudoufu, and you, with any cloud tool	The resource goes invisible and the next plan proposes a duplicate
Micro-state records	A local directory beside the module unless you declare a `record_store` on SSM or S3	choudoufu only	Churn, since the effect re-runs or its value regenerates
Receipts	Ordinary resources you declare, by convention SSM parameters	You, your reviewers, your incident responder	Nothing structural. It is your data, in your configuration

The first is the product. The second is plumbing that is there by default and that you point somewhere else when a team needs to share it. The third you write yourself, and choudoufu only lints it.

How the compatibility numbers are measured

Mon, 01 Jan 0001 00:00:00 +0000

How the compatibility numbers are measured#

live/corpus-refusals.json measures which refusals fire and how often across the corpus. Compatibility reference copies no count from it, because a copied count goes stale the moment the corpus re-runs.

That measured ranking is why the static-evaluability rule (see Identity) leads the reference page. Several of the most frequent refusals are that one rule under different diagnostics.

Do not read the fixture or module-example populations as a compatibility rate. Module examples/ directories demonstrate a module’s full surface, so they lean far harder on variables, conditionals and dynamic blocks than a configuration describing one deployment, and refuse almost across the board. Those populations are marked as a ranking, settled by #118. One population can honestly carry a rate since #147, whole deployment root modules published by their operators, pinned by commit, marked reads_as: rate.

The ownership policy matrix

Mon, 01 Jan 0001 00:00:00 +0000

The ownership policy matrix#

Every resource choudoufu sees falls into one of four situations, decided by whether your configuration declares it and whether it carries this estate’s marker. The policy block sets what happens in each.

With no policy block you get the defaults below, which are today’s behaviour.

The situation you are in	Setting	Default	What the default does
You declare it, and it carries your marker. The ordinary case.	`declared_tagged`	`converge`	Plans and applies it against your configuration, like any resource.
You declare it, but no live resource carries your marker for it.	`declared_untagged`	`refuse`	Declines to touch it until you adopt it.
You removed it from your configuration, and it still carries your marker.	`undeclared_tagged`	`delete`	Destroys it on the next plan.
It carries no marker, and you never declared it. Somebody else’s.	`undeclared_untagged`	`keep`	Leaves it alone.

The third row is the one to know before deleting a resource block. Removing the block does not mean “stop managing this”, it means “destroy this”, which is also what upstream does without a removed block. Set undeclared_tagged to untag or keep first if the resource should survive. How to stop managing or destroy a resource walks through it.

Reference

Mon, 01 Jan 0001 00:00:00 +0000

Reference#

The normative specifications live in the repository beside the code and the tests holding them to it. This page indexes them.

They are for people integrating with choudoufu or working on it. To get an estate running, use the path pages.

Specifications#

Document	What it settles
`live/MARKERS.md`	The marker tag spec. Key names, the escaping rule, continuation tags, ownership semantics, the rename rule, and what protects the tags. The one surface external tooling can rely on.
`live/LIMITATIONS.md`	Every construct the mode bounds or rejects, per rule, each with its lint rule and fixture.
`live/RECEIPTS.md`	Recording an effect that leaves nothing in the live system to read back, and the guards on the pattern.
`live/OUTPUTS.md`	Sharing values between estates with no remote state.

Coverage and evidence#

Document	What it settles
`live/COVERAGE.md`	Which AWS resource types are covered, in layers, and what each layer means.
`live/SURVEY.md`	How admission is decided per type, the method, and the raw signals behind it.

The demo, which is also the test suite#

live/e2e/README.md documents the harness, what each step proves, the environment knobs, and each exit code.

Add an estate

Mon, 01 Jan 0001 00:00:00 +0000

An estate is any real OpenTofu or Terraform configuration, pinned by tag or commit. Adding one is a manifest entry and a script, and the site picks it up on the next run.

go run ./tools/gauntlet add <name> <repo-url> <tag-or-commit> -lane <lane> [-core -reason "..."] -source "<one line>"

That writes the entry and a script stub at live/e2e/<name>/run.sh with every stage wired to the protocol and marked not_run. Fill the stub in, using the script of a similar estate as the template (live/e2e/corpus-vpc-complete/run.sh is the fullest), then:

Contribute compute

Mon, 01 Jan 0001 00:00:00 +0000

Anyone can move the bars by spending tokens rather than time. The loop is deterministic, so it needs no coordinator:

go run ./tools/gauntlet next # the next unit: an estate and the first active stage it does not pass
just contribute [max-usd] # one worker run on that unit, in a fresh worktree, with your own key

just contribute runs Claude Code headless under the brief in .claude/agents/gauntlet-worker.md, which does exactly one unit: run the estate, classify every difference from stock with the five-row table in HANDOFF.md, fix it generically, re-run, render, and open a pull request whose title carries the unit ID. It never merges. The same thing runs on GitHub Actions from your fork: .github/workflows/contribute.yml is workflow_dispatch, reads your fork’s ANTHROPIC_API_KEY secret, and opens the pull request against this repository when a CONTRIBUTE_TOKEN with pull-request scope is present, or prints the compare URL when it is not. There is no hosted path; every worker runs under the key of whoever started it.

corpus-alb-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-alb examples/complete-alb (tag v9.9.0), its flagship application-load-balancer example

Source: https://github.com/terraform-aws-modules/terraform-aws-alb.git at v9.9.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	80 resources, once for real (floci fixes #58, #61, #62)
Migrate	pass	51 of 80 stamped, 1 recorded, 0 failed, 28 skipped
Replan from nothing	pass	empty live-plan with no state file; 0 Error diagnostics; the two record-rung aws_route53_record.validation identities verified by value against route53 list-resource-record-sets
No-op apply	pass	genuine no-op (0 added, 0 changed, 0 destroyed); 50 tofu-estate-tagged objects before, 50 after
Drift and reconverge	pass	one object tampered (the ALB’s Example tag), plan proposed fixing exactly module.alb.aws_lb.this[0], apply changed 1 and the Example tag reconverged
Rename	pass	moved block: aws_instance.this renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_instance.other renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state (positioned right after stage 1, before migrate ever touches these shared objects) also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting aws_instance.other_renamed’s block (and its one target-group-attachment reference) proposed exactly 2 destroys (0 add, 0 change, 2 destroy), matching the stock oracle and applied cleanly; the instance is confirmed terminated via the AWS CLI, not through choudoufu’s own report; the next plan proposes no resource action; stock oracle on cold_deploy’s own state (D-REMOVE-ORACLE) also proposes exactly 2 destroys for the same two objects
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	80 resources from nothing, matching stock’s own cold-deploy count; the ALB’s markers verified via the AWS CLI; 80 records in the local record store including untaggable types; replan empty; a representative EC2 instance’s own shape (type/ami) matches stock’s cold deploy, via the AWS CLI on both endpoints, marker tags never compared; 50 objects carry the estate tag
Strict profile (planned)	not run

Last run at commit df0cc6a075 on 2026-08-25T17:32:35Z, exit code 0.

corpus-autoscaling-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-autoscaling examples/complete (tag v9.3.0), its only/flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-autoscaling.git at v9.3.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 68 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=autoscaling-complete-crossing before migration
Migrate	pass	41 resource(s) newly stamped, 0 already stamped, 0 newly recorded, 0 re-recorded for sensitivity only, 0 already recorded, 0 failed, 27 skipped; 41 objects carry tofu-estate=autoscaling-complete-crossing
Replan from nothing	pass	empty plan; identity re-check unchanged: module.complete.aws_launch_template.this:0, aws_iam_role.ssm
No-op apply	pass	genuine no-op: 41 objects before, 41 after, no state file either time
Drift and reconverge	pass	one object tampered (SQS queue ‘complete’s Example tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag
Rename	pass	moved block: module.asg_sg renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place on its security group; live-mv: aws_sqs_queue.this renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.default’s block proposed exactly 2 destroys (0 add, 0 change, 2 destroy), matching the stock oracle’s own count and applied cleanly; the live ASG count dropped by exactly one and the tagged object count dropped too, both confirmed via the AWS CLI, not through choudoufu’s own report; the next plan proposes no resource action; stock oracle on cold_deploy’s own state (D-REMOVE-ORACLE) also proposes exactly 2 destroys for the same module
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	68 resources from nothing, matching stock’s own cold-deploy count (68); the sqs queue’s markers verified via the AWS CLI; 68 records in the local record store including the untaggable ASGs (#364 A2); replan empty; the asg_sg security group’s rule counts match stock’s cold deploy structurally, via the AWS CLI on both endpoints, marker tags never compared; 41 objects carry the estate tag
Strict profile (planned)	not run

Last run at commit df0cc6a075 on 2026-08-25T17:28:03Z, exit code 0.

corpus-dynamodb-table-basic

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-dynamodb-table, examples/basic (tag v5.5.1, commit 02b2d66ad2396389381c8dbe3423682114ed5350)

Source: https://github.com/terraform-aws-modules/terraform-aws-dynamodb-table.git at v5.5.1.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 3 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=dynamodb-table-basic-crossing before migration
Migrate	pass	1 resource(s) newly stamped, 0 already stamped, 1 newly recorded, 0 re-recorded for sensitivity only, 0 already recorded, 0 failed, 1 skipped.; Apply complete! Resources: 0 added, 0 changed, 1 destroyed. (tofu-slot convergence)
Replan from nothing	pass	no resource change proposed, nothing foreign; identity re-check (via the AWS CLI) unchanged
No-op apply	pass	genuine no-op: 1 objects before, 1 after, no state file either time
Drift and reconverge	pass	one object tampered (arn:aws:dynamodb:eu-west-1:000000000000:table/my-table-delicate-mantis’s Terraform tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag
Rename	pass	moved block: module.dynamodb_table renamed to module.dynamodb_table_moved with zero churn (0 add, 1 change, 0 destroy) - the table’s own marker rewritten in place, the untaggable resource policy unaffected; live-mv: module.dynamodb_table_moved renamed to module.dynamodb_table_final with zero churn, marker rewritten in place; stock oracle over the same net module rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); the table’s ARN unchanged throughout, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.dynamodb_table_final’s block proposed exactly two destroys (0 add, 0 change, 2 destroy: the table and its untaggable resource policy), applied cleanly (0 added, 0 changed, 2 destroyed), the table is genuinely gone from the live account (dynamodb describe-table on the old name now returns ResourceNotFoundException, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (D-REMOVE-ORACLE) also proposes exactly two destroys for the same two objects; classifyOrphans did not withhold either destroy because module.disabled_dynamodb_table declares zero instances of the same block key (create_table=false), so nothing is ever pending against it
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	3 resources from nothing (random_pet + table + resource policy), the table’s markers verified via the AWS CLI, 3 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally on key schema/attributes/table class/deletion protection/on-demand billing/GSI/resource policy
Strict profile (planned)	not run

Last run at commit df0cc6a075 on 2026-08-25T17:22:59Z, exit code 0.

corpus-ec2-instance-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-ec2-instance examples/complete (tag v6.4.0), the most-downloaded module on the registry; absent from the measurement set until 2026-08-23

Source: https://github.com/terraform-aws-modules/terraform-aws-ec2-instance.git at v6.4.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Clear. Every active stage passes.

corpus-ecs-fargate

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-ecs examples/fargate (tag v7.6.0), its Fargate flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-ecs.git at v7.6.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	62 resources, once for real
Migrate	pass	46 of 62 stamped
Replan from nothing	pass	genuinely empty replan (“No changes. Your infrastructure matches the configuration.”) - #371, #378, #372, #110, #395 and #376 all fixed and stay fixed; the standalone task definition’s essential/mountPoints[].readOnly wall is gone (lex00/floci#131, published and repinned this unit) and essential defaulting to true was never an independent wall on its own (this unit’s own re-measurement). #395/#376: choudoufu keeps no persisted state, so every plan re-derives PriorState through ImportResourceState’s bare stub; internal/live/projection/build.go’s configuredAttrsSeed generalizes the tags-only import-stub seed (issue #287 item 8) to every Required-or-Optional-non-Computed attribute (fixing #376’s track_latest/skip_destroy directly), and internal/live/projection/residue.go’s residueConfigSourced widening of classifyResidue plus the new builder.residueSeedFor pre-read seed close #395’s managed-reference case (task_definition = aws_ecs_task_definition.this[0].arn) that configuredAttrsSeed’s static evaluator alone could not reach. Identities confirmed by value against the AWS CLI: $CLUSTER_ARN, $TD_SVC_ARN, $TD_STANDALONE_ARN, and #368’s scalable target $GOT_TARGET_RID.
No-op apply	pass	genuine no-op (0 added, 0 changed, 0 destroyed); 46 tofu-estate-tagged objects before, 46 after, no state file either time
Drift and reconverge	pass	one object tampered (VPC’s Name tag), plan proposed fixing exactly module.vpc.aws_vpc.this[0], apply changed 1 and the Name tag reconverged
Rename	pass	moved block: module.alb renamed with zero churn (0 add, 9 change, 0 destroy), marker rewritten in place; live-mv: aws_service_discovery_http_namespace.this renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.ecs_task_definition’s block proposed exactly 8 destroys (0 add, 0 change, 8 destroy), address-for-address identical to stock’s oracle on cold_deploy’s own state; applied cleanly (0 added, 0 changed, 8 destroyed); the standalone task definition family (ex-fargate-standalone) genuinely has 0 active revisions afterward, read via the AWS CLI, not choudoufu’s own report; classifyOrphans did not withhold any destroy because no other module.ecs_task_definition block is declared anywhere in this config; the next plan is empty
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	62 resources from nothing, cluster marker verified via the AWS CLI, 60 of 62 records in the local record store (#364 A2; the 2 aws_ecs_task_definition instances are excluded by a numeric-wire-identity-component gap in internal/live/identity/located.go’s LocatedIdentityPlanFor, documented in this script and not fixed here - their markers and plans are unaffected), replan empty, stock oracle in its own namespace matches structurally on cluster/service/standalone-task-definition/CloudMap-namespace/ALB/VPC
Strict profile (planned)	not run

Last run at commit 4ba0356d2c on 2026-08-25T17:44:48Z, exit code 0.

corpus-eks-basic

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-eks examples/basic (tag v9.0.0)

Source: https://github.com/terraform-aws-modules/terraform-aws-eks.git at v9.0.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	54 resources, genuinely cold, genuinely unmarked
Migrate	pass	25 of 54 resource instances stamped, 25 of 25 confirmed via the AWS CLI; 5 record-backed instances seeded into the implied local record store (#364)
Replan from nothing	pass	live-plan runs to completion with ZERO Error diagnostics and reports “No changes. Your infrastructure matches the configuration.” - the record-backed worker launch configuration’s enable_monitoring/root_block_device/user_data all now agree with the config’s own desired value (lex00/floci#132 for the first two, configuredAttrsSeed’s residue-record pre-read seed in internal/live/projection/build.go for the third)
No-op apply	pass	genuine no-op (0 added, 0 changed, 0 destroyed); 25 tofu-estate-tagged objects before, 25 after
Drift and reconverge	pass	one object tampered (VPC’s Name tag), plan proposed fixing exactly module.vpc.aws_vpc.this[0], apply changed 1 and the Name tag reconverged
Rename	pass	moved block: aws_security_group.worker_group_mgmt_two renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_security_group.all_worker_mgmt renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting aws_security_group.worker_group_mgmt_one’s block (plus emptying the one argument that referenced it) proposed 2 resource action(s), address-for-address and action-for-action identical to stock’s oracle on cold_deploy’s own state; applied cleanly; the security group is genuinely gone from the live account, read via the AWS CLI, not choudoufu’s own report; classifyOrphans did not withhold any destroy because no other aws_security_group.worker_group_mgmt_one block is declared anywhere in this config; the next plan is empty
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	54 resources from nothing, cluster marker verified via the AWS CLI, 54 records under the implied local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally on cluster status/version, ASG count/desired-capacities, and cluster-owned security-group count
Strict profile (planned)	not run

Last run at commit ab52115aec on 2026-08-25T17:36:35Z, exit code 0.

corpus-evoteum-modules

Mon, 01 Jan 0001 00:00:00 +0000

evoteum/tofu-modules, the aws/networking and aws/dynamodb modules (pinned by commit 7e8764035c50d1cb2a6ac04636a9f85ba6708d39; no tags published)

Source: https://github.com/evoteum/tofu-modules.git at 7e8764035c50d1cb2a6ac04636a9f85ba6708d39.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	10 resources added (1 vpc, 3 subnets, 1 igw, 1 route table, 3 associations, 1 dynamodb table); confirmed unmarked
Migrate	pass	7 of 10 verified and stamped, 0 failed, 3 correctly UNTAGGABLE; markers read back via the AWS CLI
Replan from nothing	pass	no changes; VPC and table markers unchanged, all three untaggable associations resolved by their composite identity
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 7, no state file
Drift and reconverge	pass	VPC Name tag tampered out of band, exactly 1 object proposed and reconverged, marker survived the incremental tag update
Rename	pass	moved block: module.networking renamed with zero churn (0 add, 6 change, 0 destroy), marker rewritten in place across its taggable objects including the untaggable route-table-association children resolving structurally; live-mv: module.sessions_table renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.sessions_table_renamed’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), address-for-address identical to stock’s oracle on cold_deploy’s own state (module.sessions_table); applied cleanly (0 added, 0 changed, 1 destroyed); the table is genuinely gone from the live account (describe-table now returns ResourceNotFoundException, read via the AWS CLI, not choudoufu’s own report), and the next plan is empty; classifyOrphans did not withhold the destroy because no other module.sessions_table* block is declared anywhere in this config
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	10 resources from nothing (1 vpc, 3 subnets, 1 igw, 1 route table, 3 untaggable associations, 1 dynamodb table), VPC marker verified via the AWS CLI, 10 records in the local record store (#364 A2, one per managed instance), replan empty, stock oracle in its own namespace matches structurally on vpc/subnets/igw/route-table/dynamodb-table
Strict profile (planned)	not run

Last run at commit 24c75b68f9 on 2026-08-25T17:25:09Z, exit code 0.

corpus-giantswarm-crossplane

Mon, 01 Jan 0001 00:00:00 +0000

giantswarm/giantswarm-aws-account-prerequisites, the crossplane/ module (pinned tag v8.2.2, commit f1a7d8d51086824a97749b1a8a13327c6f081f72)

Source: https://github.com/giantswarm/giantswarm-aws-account-prerequisites.git at v8.2.2.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	6 resource instances added, 0 already tofu-estate-marked before migration
Migrate	pass	2 of 6 stamped (role, managed policy), 4 untaggable skipped, module’s own tags survived the stamp
Replan from nothing	pass	live-plan empty, role/policy tofu-address unchanged, both *_exclusive resources re-derived by value
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, both exclusive sets unchanged
Drift and reconverge	pass	role’s installation tag tampered, exactly the IAM role proposed and reconciled, apply changed 1, tag reads back as configured
Rename	pass	moved block: module.crossplane renamed to .crossplane_renamed with zero churn (0 add, 2 change, 0 destroy - role and policy), markers rewritten in place; live-mv: .crossplane_renamed renamed to .crossplane_final with zero churn, both markers rewritten in place (one live-mv call per taggable object); stock oracle over the same chained module rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.crossplane_final’s block proposed 6 resource action(s), address-for-address and action-for-action identical to stock’s oracle on cold_deploy’s own state; applied cleanly; the role is genuinely gone from the live account (get-role now returns NoSuchEntity, read via the AWS CLI, not choudoufu’s own report); classifyOrphans did not withhold any destroy because no other module.crossplane* block is declared anywhere in this config; the next plan is empty
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	6 resources from nothing (role, managed policy, 4 untaggable), role marker verified via the AWS CLI, 6 records in the local record store (#364 A2, one per managed instance), replan empty, stock oracle in its own namespace matches structurally on the role and the managed policy
Strict profile (planned)	not run

Last run at commit 7ff51b84d3 on 2026-08-25T17:26:53Z, exit code 0.

corpus-hongbomiao-harbor

Mon, 01 Jan 0001 00:00:00 +0000

hongbo-miao/hongbomiao.com, a third disjoint slice: environments/production/aws/kubernetes/main.tofu’s self-contained Harbor section (commit 3f69ab9c37211e163bbd4434bad39780b6d4b92b, same pin as corpus-hongbomiao-labelbox and corpus-hongbomiao-storage)

Source: https://github.com/hongbo-miao/hongbomiao.com.git at 3f69ab9c37211e163bbd4434bad39780b6d4b92b.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 3 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=hongbomiao-harbor-crossing before migration
Migrate	pass	2 of 3 stamped (bucket, user), 1 UNTAGGABLE (inline policy); bucket hongbomiao-harbor-crossing-hm-harbor -> tofu-address=module.s3_bucket_hm_harbor.aws_s3_bucket.main, user hongbomiao-harbor-crossing-hm-harbor-user -> tofu-address=module.harbor_iam_user.aws_iam_user.hm_harbor_iam_user
Replan from nothing	pass	empty plan; identity re-check: bucket and user tofu-address unchanged, inline policy’s resource ARN still matches the configuration
No-op apply	pass	genuine no-op: 2 objects before, 2 after, no state file either time
Drift and reconverge	pass	the plan proposed fixing 1 object(s) after the out-of-band tag mutation: module.s3_bucket_hm_harbor.aws_s3_bucket.main
Rename	pass	moved block: module.s3_bucket_hm_harbor renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.harbor_iam_user renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.harbor_iam_user_renamed’s block proposed exactly two destroys (0 add, 0 change, 2 destroy - the untaggable inline policy and its taggable parent user), applied cleanly (0 added, 0 changed, 2 destroyed) in an order IAM accepted, the user is genuinely gone from the live account (iam get-user on the old name now returns NoSuchEntity, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly two destroys for the same objects
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	3 resources from nothing (bucket, user, untaggable inline policy), markers verified via the AWS CLI, 3 records in the local record store (#364 A2), replan empty both with and without the local record store, all objects match stock’s cold-deploy container (STAGE 1, untouched) object by object, marker tags never compared
Strict profile (planned)	not run

Last run at commit ed39ad1948 on 2026-08-25T17:46:42Z, exit code 0.

corpus-hongbomiao-labelbox

Mon, 01 Jan 0001 00:00:00 +0000

hongbo-miao/hongbomiao.com, the “Labelbox” section of infrastructure/opentofu/aws/general/main.tofu (commit 3f69ab9c37211e163bbd4434bad39780b6d4b92b, no tag)

Source: https://github.com/hongbo-miao/hongbomiao.com.git at 3f69ab9c37211e163bbd4434bad39780b6d4b92b.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	4 resources added, 0 objects carry tofu-estate=hongbomiao-labelbox-crossing before migration
Migrate	pass	2 of 4 stamped (2 skipped, untaggable), 0 failed; markers read back via the AWS CLI
Replan from nothing	pass	no resource change proposed; bucket and role tofu-address unchanged, CORS origins and inline policy resource match config
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, no state file
Drift and reconverge	pass	bucket tag drifted; exactly module.amazon_s3_bucket_hm_labelbox.aws_s3_bucket.main proposed, applied (1 changed), reconverged to hongbomiao
Rename	pass	moved block: module.amazon_s3_bucket_hm_labelbox renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.labelbox_iam_role renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.labelbox_iam_role_renamed’s block proposed exactly two destroys (0 add, 0 change, 2 destroy - the untaggable inline policy and its taggable parent role), applied cleanly (0 added, 0 changed, 2 destroyed) in an order IAM accepted, the role is genuinely gone from the live account (iam get-role on the old name now returns NoSuchEntity, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly two destroys for the same objects
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	FAIL	the greenfield apply failed
Strict profile (planned)	not run

Last run at commit 81634a7f65 on 2026-08-25T17:39:06Z, exit code 1.

corpus-hongbomiao-storage

Mon, 01 Jan 0001 00:00:00 +0000

hongbo-miao/hongbomiao.com, a second disjoint slice: environments/production/aws/storage/main.tofu’s remote-state-free bootstrap section (commit 3f69ab9c37211e163bbd4434bad39780b6d4b92b, same pin as corpus-hongbomiao-labelbox)

Source: https://github.com/hongbo-miao/hongbomiao.com.git at 3f69ab9c37211e163bbd4434bad39780b6d4b92b.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 4 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=hongbomiao-storage-crossing before migration
Migrate	pass	3 of 4 stamped (2 buckets, KMS key), 1 UNTAGGABLE (KMS alias); bucket hongbomiao-storage-crossing-hm-production -> tofu-address=module.hm_production_bucket.aws_s3_bucket.main, bucket hongbomiao-storage-crossing-hm-iot-data -> tofu-address=module.s3_bucket_iot_data.aws_s3_bucket.main, key a99ac700-93aa-4714-9b11-0e0e1e8a7f5e -> tofu-address=module.kafka_kms_key.aws_kms_key.main
Replan from nothing	pass	empty plan; identity re-check: both buckets’ and the key’s tofu-address unchanged, KMS alias still points at the same key
No-op apply	pass	genuine no-op: 3 objects before, 3 after, no state file either time
Drift and reconverge	pass	the plan proposed fixing 1 object(s) after the out-of-band tag mutation: module.s3_bucket_iot_data.aws_s3_bucket.main
Rename	pass	moved block: module.hm_production_bucket renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.kafka_kms_key renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.kafka_kms_key_renamed’s block proposed exactly two destroys (0 add, 0 change, 2 destroy - the untaggable alias and its taggable parent key), applied cleanly (0 added, 0 changed, 2 destroyed) in an order the cloud accepted, the key is genuinely PendingDeletion and the alias is gone (read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly two destroys for the same objects
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	4 resources from nothing (2 buckets under aws.production, KMS key and untaggable alias under the default aws provider), markers verified via the AWS CLI, 4 records in the local record store (#364 A2), replan empty both with and without the local record store, all objects match stock’s cold-deploy container (STAGE 1, untouched) object by object per provider namespace, marker tags never compared
Strict profile (planned)	not run

Last run at commit 24b7a008e9 on 2026-08-25T17:27:21Z, exit code 0.

corpus-iam-policy

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-iam examples/iam-policy

Source: https://github.com/terraform-aws-modules/terraform-aws-iam.git at v6.8.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 2 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=iam-policy-crossing before migration
Migrate	pass	2 of 2 stamped, both carrying tofu-slot=0/0 read back through IAM (choudoufu #372); Apply complete! Resources: 0 added, 0 changed, 0 destroyed. - nothing left to converge
Replan from nothing	pass	no resource change proposed, nothing foreign; identity re-check (via the AWS CLI) both unchanged
No-op apply	pass	genuine no-op: 2 objects before, 2 after, no state file either time
Drift and reconverge	pass	one object tampered (arn:aws:iam::000000000000:policy/example_from_data_source’s Example tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag
Rename	pass	moved block: module.iam_policy_from_data_source renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.iam_policy renamed with zero churn, marker rewritten in place (found and fixed live-mv’s own missing issue #266 tag-index fallback and the arnJoinTable’s missing iam:policy entry to get here); stock oracle over the same two-module rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both ARNs unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.iam_policy_renamed’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the object is genuinely gone from the live account (iam get-policy on the old ARN now returns NoSuchEntity, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (STAGE 1.5.5) also proposes exactly one destroy for the same object; classifyOrphans did not withhold the destroy even though module.iam_policy_renamed2’s policy shares the same block key, because that surviving instance is bound, not unclaimed
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	2 resources from nothing (both aws_iam_policy), markers verified via the AWS CLI, 2 records in the local record store (#364 A2), replan empty both with and without the local record store, both policies’ documents and paths match stock’s cold-deploy container (STAGE 1, untouched) object by object, marker tags never compared
Strict profile (planned)	not run

Last run at commit a2b7eb7f4c on 2026-08-25T17:28:43Z, exit code 0.

corpus-iam-read-only-policy

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-iam examples/iam-read-only-policy

Source: https://github.com/terraform-aws-modules/terraform-aws-iam.git at v6.8.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 1 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=iam-read-only-policy-crossing before migration
Migrate	pass	1 of 1 stamped, carrying tofu-slot=0 read back through IAM (choudoufu #372); Apply complete! Resources: 0 added, 0 changed, 0 destroyed. - nothing left to converge
Replan from nothing	pass	no resource change proposed, nothing foreign; identity re-check (via the AWS CLI) unchanged
No-op apply	pass	genuine no-op: 1 objects before, 1 after, no state file either time
Drift and reconverge	pass	one object tampered (arn:aws:iam::000000000000:policy/example/ex-iam-read-only-policy-82e4bb26d77dc89263bfa1c0be’s Example tag), plan proposed fixing exactly module.read_only_iam_policy.aws_iam_policy.policy[0], apply changed 1 and reconverged the tag
Rename	pass	moved block: module.read_only_iam_policy renamed to module.read_only_iam_policy_moved with zero churn (0 add, 1 change, 0 destroy), tofu-address marker rewritten in place; live-mv: module.read_only_iam_policy_moved renamed to module.read_only_iam_policy_final with zero churn, marker rewritten in place; stock oracle over the identical net rename on cold_deploy’s own state also shows a true no-op (0 add, 0 change, 0 destroy, outputs unchanged in value); the live policy ARN unchanged throughout, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.read_only_iam_policy_final’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the object is genuinely gone from the live account (iam get-policy on the old ARN now returns NoSuchEntity, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; classifyOrphans did not withhold the destroy because no other aws_iam_policy.policy block anywhere in this config ever declares a real instance (count=0 on both remaining module calls)
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	1 resource from nothing, marker verified via the AWS CLI, 1 record in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally (path, description, policy document)
Strict profile (planned)	not run

Last run at commit 2d8978675e on 2026-08-25T17:48:36Z, exit code 0.

corpus-lambda-simple

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-lambda examples/simple (tag v8.8.1)

Source: https://github.com/terraform-aws-modules/terraform-aws-lambda.git at v8.8.1.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	8 resources, genuinely cold, genuinely unmarked
Migrate	pass	3 stamped, 4 recorded, 0 failed, 1 skipped
Replan from nothing	pass	no resource change proposed
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); tofu-estate-tagged object count unchanged at 3; markers and record store intact
Drift and reconverge	pass	one object tampered (memory_size 128->256), exactly module.lambda_function.aws_lambda_function.this[0] proposed by both choudoufu and stock with the identical change, apply changed 1 and memory_size reads back as 128
Rename	pass	moved block: module.lambda_function renamed to module.lambda_function_moved with zero churn (0 add, 3 change, 0 destroy) across all seven of its stateful children, three taggable markers rewritten in place, three record-located children moved via their own per-resource moved blocks with zero diff, one config-derived child (aws_iam_role_policy.logs) needing none; stock oracle over the identical seven-resource move on cold_deploy’s own state also shows zero churn beyond the module’s own pre-existing null_resource.archive[0] package-timestamp noise (confirmed present on an unrelated baseline replan too); live-mv: module.lambda_function_moved renamed to module.lambda_function_final across all three taggable children (the function, the role, the log group), one call each, zero churn, markers rewritten in place - the internal/live/mv/mv.go materialize() RecordStore wiring gap (build.go:1676’s “Record-backed instance with no record store”) is fixed; all three live objects unchanged throughout, read via the AWS CLI; final replan is empty
Remove a block	FAIL	choudoufu’s remove plan proposes 7 destroys, expected exactly 6
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	8 resources from nothing (3 taggable + 5 record-backed/config-derived), all three module-nested markers verified via the AWS CLI, 8 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally (runtime, handler, memory, timeout, log-group retention)
Strict profile (planned)	not run

Last run at commit db15df773b on 2026-08-25T17:47:34Z, exit code 1.

corpus-leynos-monitoring

Mon, 01 Jan 0001 00:00:00 +0000

leynos/df12-www, the modules/monitoring module (pinned by commit alone - no tags published - e59eabba112b2a4c731123f26845a20f0ae0d938)

Source: https://github.com/leynos/df12-www.git at e59eabba112b2a4c731123f26845a20f0ae0d938.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	3 resources added (2 alarms + dashboard), 0 objects carry tofu-estate=leynos-monitoring-crossing before migration
Migrate	pass	2 of 3 stamped (1 skipped, untaggable dashboard), 0 failed; both alarm markers read back via the AWS CLI
Replan from nothing	pass	no resource change proposed; both alarms’ tofu-address unchanged, dashboard body re-derived and matches distribution_id
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, no state file
Drift and reconverge	pass	S3 alarm’s alarm_description tampered, exactly 1 object proposed and applied, reconverged to its configured description
Rename	pass	moved block: aws_cloudwatch_metric_alarm.s3_requests_spike renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_cloudwatch_metric_alarm.cf_requests_spike renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting the CloudFront alarm’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the object is genuinely gone from the live account (describe-alarms on its name no longer returns it, read via the AWS CLI, not choudoufu’s own report), and the next plan is empty; classifyOrphans did not withhold the destroy because the S3-requests alarm, the surviving aws_cloudwatch_metric_alarm instance, is bound, not unclaimed
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	3 resources from nothing (2 tagged alarms + the untaggable dashboard), both alarm markers verified via the AWS CLI, 3 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally on both alarms
Strict profile (planned)	not run

Last run at commit 20afe6d42d on 2026-08-25T17:28:16Z, exit code 0.

corpus-mastino-dns

Mon, 01 Jan 0001 00:00:00 +0000

datacite/mastino, global/dns - DataCite’s own global DNS root module (.corpus/mastino/global/dns)

Source: https://github.com/datacite/mastino.git at 4d8c1f1bebd91e73195017ce44a243002e9e36e5.

Set: growing. Lane: published-deployment.

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	63 resources from stock terraform; 4 live zones confirmed unmarked
Migrate	pass	4 of 63 stamped, 59 skipped as untaggable, 0 failed; 59 identity records written (#364), 14 of them also carrying residue (#341), DataCite’s own tags survived
Replan from nothing	pass	plan empty across 63 instances, no state file; 14 record sets and 4 zones filled residue from the store
No-op apply	pass	genuine no-op: 4 zones / 63 record sets unchanged, all 4 markers unmoved, all 59 identity records intact (14 residue-bearing)
Drift and reconverge	pass	one untaggable record drifted, exactly aws_route53_record.wp-prod-staging[0]/ttl proposed and applied, reconverged to 300, marker intact
Rename	pass	moved block: aws_route53_zone.production renamed with zero churn (0 add, 1 change, 0 destroy) - only the zone’s own marker rewritten, none of its 45 record children moved; live-mv: aws_route53_zone.internal renamed with zero churn, marker rewritten in place; stock oracle over the same two-zone rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live zone ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting aws_route53_zone.eu and aws_route53_record.eu-ns’s blocks - both destroys proposed (matching stock’s own oracle exactly) and applied cleanly (Apply complete! Resources: 0 added, 0 changed, 2 destroyed.), the zone genuinely gone from the live account (read via the AWS CLI, not choudoufu’s own report); the next plan is empty. The parent-scoped removal sweep gap this estate named (gauntlet:parent-scoped-sweep) is closed: recordOrphanReadSweep composes aws_route53_record’s identity from its migrate-seeded record correctly (composeImportIDFromComponents’s OmitIfAbsent fix) and carries a destroy-before-parent ordering hint (identity.Resolution.DestroyDependsOn) so the record’s own destroy is never raced against its zone’s force_destroy cascade.
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	63 resources from nothing (4 tagged zones + 59 untaggable records), the production zone’s marker verified via the AWS CLI, 63 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches on zone count (4) and total record-set count (63)
Strict profile (planned)	not run

Last run at commit 2b52ff8eb7 on 2026-08-25T17:36:46Z, exit code 0.

corpus-overture-tiles

Mon, 01 Jan 0001 00:00:00 +0000

OvertureMaps/terraform-aws-overture-tiles (Overture Maps Foundation), pinned by tag AND commit (v1.2.0, 3f44cebc297db8626705e99784f412b4a2c4eda1) - the first OpenTofu-native lane entry with a real tagged release to pin against

Source: https://github.com/OvertureMaps/terraform-aws-overture-tiles.git at v1.2.0.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

corpus-rds-complete-postgres

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-rds examples/complete-postgres (tag v7.2.1)

Source: https://github.com/terraform-aws-modules/terraform-aws-rds.git at v7.2.1.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	39 resources, once for real
Migrate	pass	26 of 39 stamped
Replan from nothing	pass	genuinely empty replan (No changes. Your infrastructure matches the configuration.) with no local state file. lex00/floci#120’s round-trip gap, this estate’s last recorded wall, is CONFIRMED FIXED: round 8 (PR #128/ff815779, ghcr.io/lex00/floci:main-20260824d sha256:25fc9687, #124’s RDS colliding-port isolation) closed the last of its eight fields for this estate - module.db_default’s own port (module.db and module.db_default both declare port=5432, a genuine collision; module.db_default is the second-created instance and gets its own distinct loopback bind address with the declared port honored). The other seven fields (backup_window, monitoring_interval, monitoring_role_arn, performance_insights_retention_period, engine_lifecycle_support, enabled_cloudwatch_logs_exports, max_allocated_storage) and the parameter block’s apply_method were already fixed by earlier rounds (round 5 and round 6’s own #120 passes) that this estate had not been re-crossed since - the artifact’s recorded ‘3 in-place updates’ detail was stale before this round’s own fix even landed. Confirmed three independent ways, not merely inferred from the empty plan: a direct describe-db-parameters –source user probe of the live parameter group (autovacuum=1, client_encoding=utf8, matching config exactly, no tofu in the loop), a direct describe-db-instances probe of the second instance’s own Endpoint.Port (5432, the declared port), and all eight attribute names individually confirmed absent from choudoufu’s plan. INTENTIUS/choudoufu#393 (skip_final_snapshot’s phantom true->false update) remains fixed, confirmed absent. Stock’s own replan against its own never-deleted state file still shows tag noise plus the two parameter blocks; ruled out as a live discrepancy by the same direct API probe (informational only, not this stage’s oracle - HANDOFF row 3, a property of that one state file’s own apply-time fidelity).
No-op apply	pass	genuine no-op: 26 objects before, 26 after, no state file, primary DB instance marker unmoved
Drift and reconverge	pass	one object tampered (primary DB instance’s Example tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag
Rename	pass	moved block: module.security_group renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.db_default’s db instance renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.db_default_renamed’s block proposed exactly two destroys (the db instance and its own local random_id.snapshot_identifier, no cloud representation - issue #340), applied cleanly, the db instance is genuinely gone from the live account (read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on the same renamed oracle tree also proposes exactly the same two destroys; the target was chosen (see header) because its own nested module.db_instance call has no untaggable AWS-side sibling under this estate’s create_db_option_group=false/create_db_parameter_group=false, unlike the shapes that surfaced issue #410 for corpus-s3-bucket-complete and corpus-overture-tiles
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	39 resources from nothing (same DELTA reduction cold_deploy itself needs - two emulator gaps, floci-io/floci#51 and lex00/floci#52), primary DB instance and security group markers verified via the AWS CLI, 39 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally (DB engine/version/class/storage/port, security-group rule count)
Strict profile (planned)	not run

Last run at commit e99a19e074 on 2026-08-25T17:57:14Z, exit code 0.

corpus-s3-bucket-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-s3-bucket examples/complete (tag v5.9.1), its flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git at v5.9.1.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	30 resources added by plain terraform, 4 buckets confirmed live, no tofu-address tag
Migrate	pass	6 of 30 stamped, 1 recorded (random_pet, issue #340), 23 skipped (untaggable), 0 failed, 26 identities recorded (#364 unit A2); markers survived the residue-classification apply
Replan from nothing	pass	no resource action proposed; 29 rendered identity occurrences (11 distinct), all naming known roots
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); bucket count unchanged at 4
Drift and reconverge	pass	accelerate config drifted to Enabled, exactly 1 change proposed and applied, reconverged to Suspended, final plan empty
Rename	pass	moved block: module.cloudfront_log_bucket renamed to module.cloudfront_log_bucket_renamed with zero churn (0 add, 1 change, 0 destroy), the bucket’s tofu-address marker rewritten in place; live-mv: module.simple_bucket renamed to module.simple_bucket_renamed with zero churn, marker rewritten in place; both live bucket names unchanged, read via the AWS CLI; the post-rename plan proposes no resource action
Remove a block	pass	choudoufu: deleting module.simple_bucket_renamed’s block proposed exactly two destroys (0 add, 0 change, 2 destroy: the bucket and its untaggable public_access_block child), applied cleanly (0 added, 0 changed, 2 destroyed), the bucket is genuinely gone from the live account (head-bucket on simple-welcomed-gnu now fails, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state also proposes exactly the same two destroys for the same two objects; the target was chosen to avoid issue #404’s shape (a sibling policy re-reading the removed bucket’s own ARN) - module.log_bucket and module.s3_bucket are both left untouched
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	29 resources from nothing (SCOPE REDUCTION’s own reduced count, random_pet pinned to a literal on both sides), 3 of 4 bucket markers verified via the AWS CLI, 26 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally on all 4 buckets (versioning, default encryption, policy presence)
Strict profile (planned)	not run

Last run at commit fa5a6bd3bd on 2026-08-25T17:34:52Z, exit code 0.

corpus-security-group-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-security-group examples/complete (tag v6.0.0), its flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-security-group.git at v6.0.0.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	67 resources (DELTA 2, lex00/floci#57)
Migrate	pass	58 of 67 stamped, 67 identities recorded (#364 unit A2)
Replan from nothing	pass	the plan is genuinely empty: every choudoufu wall (#305, #307, #313 A and B, #321, #332) and both confirmed floci gaps (#102, #104) are fixed or absent this run; default route table identities asserted by value against the AWS CLI in step 3a
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); tofu-estate-tagged object count unchanged at 58 objects, read through resourcegroupstaggingapi
Drift and reconverge	pass	one object tampered (DriftProbe tag on the main security group), exactly module.security_group.aws_security_group.this[0] proposed, apply changed 1 and the tag is gone, confirmed via the AWS CLI
Rename	pass	moved block: module.postgresql renamed to module.postgresql_renamed with zero churn (0 add, 4 change, 0 destroy) - the rule-children case, its own SG plus ingress/egress rules and rules_exclusive all moving under one moved block; live-mv: aws_security_group.app renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.postgresql_renamed’s block proposed exactly 5 destroys (0 add, 0 change, 5 destroy: SG + 2 ingress + 1 egress + 1 untaggable rules_exclusive), applied cleanly (0 added, 0 changed, 5 destroyed), the security group is genuinely gone from the live account (0 matches on describe-security-groups for the old id, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes nothing; stock oracle on cold_deploy’s own state (D-ORACLE remove) also proposes exactly 5 destroys for the same 5 objects; classifyOrphans did not withhold the untaggable rules_exclusive destroy even though module.security_group’s and module.consul’s own rules_exclusive instances share its block key, because both surviving instances are bound, not unclaimed
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	67 resources from nothing, all markers verified via the AWS CLI, 67 records in the local record store (#364 A2), replan empty, 6 tagged security groups (4 named + 2 default adopters) and every named one’s rule shape matches $PLAIN_EST’s own stage-1 apply object by object, tags stripped
Strict profile (planned)	not run

Last run at commit 8f904b06dc on 2026-08-25T17:39:23Z, exit code 0.

corpus-simpleinfra-dns

Mon, 01 Jan 0001 00:00:00 +0000

rust-lang/simpleinfra, terraform/dns (live/corpus-manifest.json) - the Rust project’s production DNS for seven domains it owns, crates.io included

Source: https://github.com/rust-lang/simpleinfra.git at 1f7f2e775a5bb567bc96b0f246f2e4656302b70c.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	35 instances (7 zones, 28 records) from plain terraform, 0 of 7 zones carry tofu-estate
Migrate	pass	7 stamped, 7 distinct hosted zones, one per module call
Replan from nothing	pass	no resource change proposed, nothing foreign; all 35 rendered identities name a live hosted zone or record set
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); 7 zones / 28 records unchanged, all 7 markers unmoved
Drift and reconverge	pass	one untaggable record drifted, exactly module.rustconf_com.aws_route53_record.cname[“2016”] proposed and applied, TTL reconverged to 300, 28 records and the parent marker intact
Rename	FAIL	the post-rename plan proposes a resource change
Remove a block	pass	choudoufu: deleting module.cratesio_com_final’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the hosted zone is genuinely gone from the live account (route53 get-hosted-zone on the old id now errors, read via the AWS CLI, not choudoufu’s own report; 7 zones down to 6), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly one destroy for the same zone (before any rename ever touched it)
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	35 instances from nothing (7 zones, 28 records), all 7 markers verified via the AWS CLI, replan empty, stock oracle in its own namespace matches structurally on all 7 zones (28 records)
Strict profile (planned)	not run

Last run at commit 57013bfa28 on 2026-08-25T18:05:03Z, exit code 1.

corpus-sqs-basic

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-sqs examples/complete (tag v5.2.2, commit dd73a96c0155bc324dda5256f3e7a9ea2c710195), reduced to four self-contained module calls per the script’s header

Source: https://github.com/terraform-aws-modules/terraform-aws-sqs.git at v5.2.2.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Clear. Every active stage passes.

corpus-sumaform-aws

Mon, 01 Jan 0001 00:00:00 +0000

uyuni-project/sumaform (github.com/uyuni-project/sumaform, 79 stars, pinned by commit not tag), module.server slice of its AWS backend

Source: https://github.com/uyuni-project/sumaform.git at c8a590801d0c7f60d9667f03391455a897900078.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	11 managed resource instances, genuinely cold, genuinely unmarked
Migrate	pass	7 stamped, 2 recorded (markers = record honoured at migrate time, GitHub issue #365 slice 2), 0 failed, 2 skipped
Replan from nothing	pass	Items 4, 5 and 6 (this script’s header) are all FIXED and the plan is genuinely empty (“No changes. Your infrastructure matches the configuration.”): live-import honours markers = record (located records for aws_instance.instance[0] and aws_ebs_volume.data_disk[0], confirmed at the store and by value against the AWS CLI both right after migrate and again after this empty replan), residue now covers NestingList/NestingSet/NestingMap blocks (internal/live/projection’s residueEligibleBlock, widened from the block’s SHAPE - whether carriesNoInformation can tell its absence from a real empty answer - never from a type name), and lex00/floci#103 (published in ghcr.io/lex00/floci@sha256:e16d9007a03093b6a6edd22273dee9d8253131f18581b0fa20ae6d34178a3079) now honours RunInstances’ BlockDeviceMapping.Ebs.VolumeSize for the root device, closing the one line (root_block_device.volume_size = 8 -> 200) that was this crossing’s own last wall. Plan moved 3 to add/0/0 (the original ABSENT gap) -> 2 to add/0/2 to destroy (item 4 fixed, item 5’s replacement exposed) -> 0 to add/1 to change/0 to destroy (item 5 fixed) -> empty (item 6 fixed by the emulator).
No-op apply	pass	genuine no-op: 7 tagged objects before, 7 after, no state file either time; module.server’s record-based instance and volume identities unchanged
Drift and reconverge	pass	the crossing VPC’s Name tag tampered out of band, plan proposed fixing exactly aws_vpc.crossing, apply changed 1 and reconverged the tag to sumaform-crossing-vpc; module.server’s record-based identities unaffected
Rename	pass	moved block: aws_eip.crossing_nat renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_route_table.crossing_public renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting module.server’s block proposed exactly three destroys (0 add, 0 change, 3 destroy: the record-based instance and EBS volume, plus the untaggable/derived volume attachment), applied cleanly (0 added, 0 changed, 3 destroyed), the instance and volume are genuinely gone from the live account (instance State=terminated, volume absent, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes the same three destroys
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	FAIL	the crossing VPC’s cidr differs: greenfield=172.31.0.0/16 oracle=172.16.0.0/16
Strict profile (planned)	not run

Last run at commit 28035177a6 on 2026-08-25T17:47:54Z, exit code 0.

corpus-vpc-complete

Mon, 01 Jan 0001 00:00:00 +0000

terraform-aws-modules/terraform-aws-vpc examples/complete (tag v6.6.1), its flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-vpc.git at v6.6.1.

Set: core. Lane: terraform-popular.

Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	Apply complete! Resources: 62 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=vpc-complete-crossing before migration
Migrate	pass	40 stamped, 22 skipped, 0 recorded, 0 failed; 39 objects carry tofu-estate=vpc-complete-crossing; the VPC’s tofu-slot reads 0 off EC2, written by the migration itself (choudoufu #372)
Replan from nothing	pass	empty plan; identity re-check unchanged: module.vpc.aws_vpc.this:0, aws_security_group.rds, module.vpc_endpoints.aws_vpc_endpoint.this:s3
No-op apply	pass	genuine no-op: 39 objects before, 39 after, no state file either time
Drift and reconverge	pass	one subnet tampered (Example tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag to ex-complete
Rename	pass	moved block: module.vpc_endpoints renamed with zero churn (0 add, 7 change, 0 destroy), marker rewritten in place across its taggable objects; live-mv: aws_security_group.rds renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting the dynamodb endpoint’s map entry (module.vpc_endpoints_renamed.aws_vpc_endpoint.this[“dynamodb”]) proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the endpoint is genuinely gone from the live account (State=absent, read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly one destroy for the same object
Change count (planned)	not run
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	62 resources from nothing (40 tag-stamped, 22 untaggable/derived), replan empty, stock oracle in its own namespace matches on vpc cidr, subnet count (18) and the s3 endpoint’s presence
Strict profile (planned)	not run

Last run at commit 8195358eaf on 2026-08-25T17:42:40Z, exit code 0.

corpus-xancloud-iac

Mon, 01 Jan 0001 00:00:00 +0000

XanCloud/xancloud-iac, blueprints/landing-zone-basic (an AWS landing-zone accelerator: VPC + CloudTrail + account-level IAM baseline), pinned by tag v0.2.0 and commit 7bc78ff79df4f914921cf04fd9728d09526c93bd

Source: https://github.com/XanCloud/xancloud-iac.git at v0.2.0.

Set: core. Lane: opentofu-native.

Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised

Not clear yet.

reference-ec2-vpc

Mon, 01 Jan 0001 00:00:00 +0000

hand-written reference project: the plainest getting-started shape (VPC/subnet/SG/IGW/EC2)

Set: core. Lane: reference.

Why it is in the core set: the plainest hand-written reference shape, kept in this repository

Not clear yet.

Stage	Verdict	Detail
Cold deploy	pass	5 resources from plain terraform, a real terraform.tfstate, zero markers
Migrate	pass	5 of 5 verified, 5 stamped, 0 skipped
Replan from nothing	pass	post-adoption plan is empty; markers read back through the AWS CLI in part A
No-op apply	pass	no-op apply (0 added, 0 changed, 0 destroyed); tofu-estate-tagged object count unchanged at 5
Drift and reconverge	pass	one object tampered, exactly aws_instance.main proposed, apply changed 1 and the tag reads back as configured
Rename	pass	moved block: aws_security_group renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_internet_gateway renamed with zero churn, marker rewritten in place; stock oracle over the same two-resource rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI
Remove a block	pass	choudoufu: deleting aws_internet_gateway.renamed’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the object is genuinely gone from the live account (describe-internet-gateways on the old id no longer returns it, read via the AWS CLI, not choudoufu’s own report), and the next plan is empty; stock oracle on cold_deploy’s own state (B1.6) also proposes exactly one destroy for the same object; classifyOrphans did not withhold the destroy because no other aws_internet_gateway block is declared anywhere in this config
Change count (planned)	FAIL	choudoufu’s scale-down plan does not destroy count_test[1]
Replace with create_before_destroy	not run
Crash between create and destroy (planned)	not run
Teardown (planned)	not run
Plan, review, apply (planned)	not run
Greenfield apply	pass	5-object structural comparison (vpc/subnet/igw/sg/instance) between the greenfield estate and stock’s cold deploy matches, via the AWS CLI on both endpoints, marker tags never compared; local record store held 5 records, one per instance (#364 A2); replanned empty both with and without the local record store
Strict profile (planned)	not run

Last run at commit 10e3f76bcd on 2026-08-25T18:04:37Z, exit code 1.

choudoufu

Compatibility reference

Compatibility reference#

Your provider#

How to check a configuration before migrating

How to check a configuration before migrating#

How to scope a role to an estate

How to scope a role to an estate#

The whole estate#

Identity

Identity#

Tutorial: see markers work

Tutorial: see markers work#

How to stop a staging role reaching production

How to stop a staging role reaching production#

The policy#

Migrate an existing estate

Migrate an existing estate#

Values

Values#

Day-2 operations

Day-2 operations#

Sharing values between estates#

Effects

Effects#

What a receipt is#

How to cover every team with one policy

How to cover every team with one policy#

How to deny creating anything unowned

How to deny creating anything unowned#

The policy#

How to rename a resource

How to rename a resource#

Start a new estate

Start a new estate#

Install#

Two runs at once

Two runs at once#

Questions

Questions#

Why is it called choudoufu?#

Where AWS honours the condition

Where AWS honours the condition#

Where the key is confirmed#

Services with no verdict#

How to stop managing or destroy a resource

How to stop managing or destroy a resource#

How to write markers inside a for_each'd module

How to write markers inside a for_each’d module#

How to record an effect the cloud cannot report

How to record an effect the cloud cannot report#

Where things are stored

Where things are stored#

How the compatibility numbers are measured

How the compatibility numbers are measured#

The ownership policy matrix

The ownership policy matrix#

Reference

Reference#

Specifications#

Coverage and evidence#

The demo, which is also the test suite#

Add an estate

Contribute compute

corpus-alb-complete

corpus-autoscaling-complete

corpus-dynamodb-table-basic

corpus-ec2-instance-complete

corpus-ecs-fargate

corpus-eks-basic

corpus-evoteum-modules

corpus-giantswarm-crossplane

corpus-hongbomiao-harbor

corpus-hongbomiao-labelbox

corpus-hongbomiao-storage

corpus-iam-policy

corpus-iam-read-only-policy

corpus-lambda-simple

corpus-leynos-monitoring

corpus-mastino-dns