How close AWS is on choudoufu

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

Clear. Every active stage passes.

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	pass	choudoufu: changing module.sessions_table_renamed’s ForceNew table_name argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old table (arn:aws:dynamodb:us-west-2:000000000000:table/evtx-development-sessions) is confirmed gone and the new table (evtx-development-sessions-v2) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new table’s name, not the destroyed one (evtx-development-sessions -> evtx-development-sessions-v2); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace at the same address (plan only, not applied - it shares floci’s account with $ESTATE); BREAK=replace confirms a manufactured marker collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment.
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 4baf67832e on 2026-08-25T18:34:37Z, 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

Clear. Every active stage passes.

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	pass	choudoufu: changing module.crossplane_final’s ForceNew installation_name argument proposed a 6 add / 0 change / 6 destroy cascade with the role and the managed policy each explicitly named ‘must be replaced’ at their same declared addresses, applied cleanly; the old role (giantswarm-gsprereqs-crossplane) is confirmed gone and the new role (giantswarm-gsprereqs-v2-crossplane) carries the marker, both via the AWS CLI; the local record store’s record at the role’s address now names the new role, not the destroyed one (giantswarm-gsprereqs-crossplane -> giantswarm-gsprereqs-v2-crossplane); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes an equal add/destroy cascade (>=2) with role and policy both replaced at the same addresses (plan only, not applied - it shares floci’s account with $ESTATE); BREAK=replace confirms a manufactured marker collision is reported loudly (a named ‘Live resource displaced from the address it is marked for’ warning, the scalar-resource shape) rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment and corpus-sqs-basic’s matching one.
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 a750d0c786 on 2026-08-25T18:42:28Z, 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

Clear. Every active stage passes.

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

Clear. Every active stage passes.

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	pass	choudoufu: changing labelbox_service_account_name proposed exactly one role replace at module.labelbox_iam_role_renamed’s declared address, cascading into its untaggable inline policy (also replaced, role and name are both ForceNew there) - 2 to add, 0 to change, 2 to destroy, matching F-ORACLE’s own plan shape; applied cleanly; the old role is confirmed terminated (NoSuchEntity) and the new role carries the marker, both via the AWS CLI; the local record store’s records at the same addresses now name the new role’s import_id and the new role:name pair, not the destroyed ones (role LabelboxRole-hm-labelbox -> LabelboxRole-hm-labelbox-v2; policy LabelboxRole-hm-labelbox:LabelboxRoleS3Policy-hm-labelbox -> LabelboxRole-hm-labelbox-v2:LabelboxRoleS3Policy-hm-labelbox-v2) - the same untaggable-identity path this estate’s greenfield fix resolves for a from-nothing apply, now proven under a real replace; the next plan proposes no resource action. Scope notes: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names (module lifecycle blocks are rejected by OpenTofu core, and the vendored module stays byte-identical to the pinned commit throughout - see this section’s own header); and a manufactured live-object collision (this stage’s own Break text) goes undetected by an ordinary plan for this resource shape, confirmed by instrumenting discovery.bind() directly - a fully record-backed type’s declared population is excluded from that function’s per-type claimant sweep, a real finding this unit records rather than fixes (identity-path change, HANDOFF’s stop-and-report territory); BREAK_REPLACE instead proves this section’s own plan-shape assertion is load-bearing.
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 (bucket, CORS config, role, untaggable inline role policy), 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, marker tags never compared
Strict profile (planned)	not run

Last run at commit ddfaef3c6d on 2026-08-25T19:30:09Z, exit code 0.

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

Clear. Every active stage passes.

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 a0fb2c16-8568-4a3d-a419-ffb8cd549413 -> 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	pass	choudoufu: changing module.kafka_kms_key_renamed’s aws_kms_key_name argument proposed exactly one forced replace at the same declared address (the untaggable, client-named alias - 1 add, 1 change, 1 destroy overall) plus one in-place tag update on the taggable key itself, applied cleanly; the old alias (alias/hongbomiao-storage-crossing-hm-kafka-kms-key) is confirmed gone and the new alias (alias/hongbomiao-storage-crossing-hm-kafka-kms-key-v2) points at the SAME key (a0fb2c16-8568-4a3d-a419-ffb8cd549413, read via the AWS CLI) - the key was never replaced; the local record store’s record at the alias’s address now names the new alias, not the destroyed one (alias/hongbomiao-storage-crossing-hm-kafka-kms-key -> alias/hongbomiao-storage-crossing-hm-kafka-kms-key-v2), while the key’s own record at its own address is unchanged; the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace (the alias) plus one in-place key update. Scope notes: (1) this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see corpus-sqs-basic’s own PART F; (2) BREAK=replace’s marker-collision control is not exercised here - aws_kms_alias is untaggable and resolved by its own name, with no marker to plant a collision on, so that control’s load-bearing-ness is proven instead by corpus-evoteum-modules and corpus-giantswarm-crossplane’s own PART F sections against the taggable shape.
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 f2a5623437 on 2026-08-25T18:59:41Z, 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

Clear. Every active stage passes.

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	pass	choudoufu: changing module.iam_policy_renamed2’s ForceNew name_prefix argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old policy (arn:aws:iam::000000000000:policy/example-705074fc1b8486f4ed75110fc3) is confirmed gone and the new policy (arn:aws:iam::000000000000:policy/example-v2-5727543ca22583d547626a365d) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new object’s ARN, not the destroyed one (arn:aws:iam::000000000000:policy/example-705074fc1b8486f4ed75110fc3 -> arn:aws:iam::000000000000:policy/example-v2-5727543ca22583d547626a365d); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (STAGE 1.5.6) also proposes exactly one replace at the same address (plan only, not applied). Scope notes: (1) this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment and corpus-sqs-basic’s matching one; (2) BREAK=replace’s manufactured marker collision is NOT reported for this type - VERIFIED FINDING, not fixed here: aws_iam_policy’s ServerAssigned/ARN identity is resolved record-primary, so a second live object carrying a duplicate tofu-address/tofu-slot marker is never compared against the record and the plan proceeds silently (rc=0, bare ‘No changes.’), unlike corpus-sqs-basic’s fungible-set hard refusal or corpus-evoteum-modules’/corpus-giantswarm-crossplane’s/corpus-hongbomiao-harbor’s named warning - see PART F’s own header and its BREAK=replace branch for the full reasoning; plausibly reaches every ServerAssigned/ARN-identity type under a fungible set.
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 cdab585cf4 on 2026-08-25T19:21:46Z, 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

Clear. Every active stage passes.

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-8b9fc1e61577a393f03ec0f5e7’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	pass	choudoufu: changing module.read_only_iam_policy_final’s ForceNew description argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old object (arn:aws:iam::000000000000:policy/example/ex-iam-read-only-policy-8b9fc1e61577a393f03ec0f5e7) is confirmed gone and the new object (arn:aws:iam::000000000000:policy/example/ex-iam-read-only-policy-2fe4ae6814d2725a3c1874cf73) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new object’s import_id, not the destroyed one (arn:aws:iam::000000000000:policy/example/ex-iam-read-only-policy-8b9fc1e61577a393f03ec0f5e7 -> arn:aws:iam::000000000000:policy/example/ex-iam-read-only-policy-2fe4ae6814d2725a3c1874cf73); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace at the same address (plan only, not applied); BREAK=replace confirms a manufactured marker collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment.
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 4baf67832e on 2026-08-25T18:37:45Z, 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

Clear. Every active stage passes.

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	pass	choudoufu: deleting module.lambda_function_final’s block proposed 7 destroys (the function, the role, its inline aws_iam_role_policy.logs[0] CloudWatch Logs policy, and all three record-located children always; the log group’s only when floci’s GetResources happens to index it - a documented emulator gap, confirmed by reading logs:list-tags-for-resource directly against the same live object), applied cleanly, the function, the role and the inline log policy genuinely gone from the live account (read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no further resource action; classifyOrphans did not withhold any destroy as a possible rename. WANT_DESTROY_COUNT moved from 5/6 to 6/7 in this same commit: the inline log policy was previously missing from this stage’s own checklist entirely - a genuine leak (an untaggable IAM permission left behind on every destroy of this estate), not a stale assertion, fixed as part of the day2_replace unit that re-measured this stage
Change count (planned)	not run
Replace with create_before_destroy	pass	choudoufu: changing module.lambda_function_final’s ForceNew logging_log_group-derived name proposed exactly one replace at the same declared address (the log group; -/+ destroy and then create) cascading into two expected in-place updates (the function’s logging_config, the inline log policy’s document) and nothing else beyond the module’s own pre-existing null_resource.archive[0] package-timestamp noise; applied cleanly; the old object (arn:aws:logs:eu-west-1:000000000000:log-group:/aws/lambda/relaxing-dingo-lambda-simple) is confirmed gone and the new object (arn:aws:logs:eu-west-1:000000000000:log-group:/aws/lambda/relaxing-dingo-lambda-simple-v2) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new object’s import_id, not the destroyed one (/aws/lambda/relaxing-dingo-lambda-simple -> /aws/lambda/relaxing-dingo-lambda-simple-v2); the next plan proposes no resource action beyond the same known noise; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace plus the same in-place cascade (plan only, not applied); BREAK=replace confirms a manufactured marker collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment.
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 7fb1993c9d on 2026-08-25T18:54:27Z, exit code 0.

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

Clear. Every active stage passes.

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	pass	choudoufu: changing s3_requests_spike_renamed’s ForceNew alarm_name argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old object (S3GetRequestsSpike) is confirmed gone and the new object (arn:aws:cloudwatch:us-west-2:000000000000:alarm:S3GetRequestsSpikeV2) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new object’s import_id, not the destroyed one (S3GetRequestsSpike -> S3GetRequestsSpikeV2); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace at the same address (plan only, not applied); BREAK=replace confirms a manufactured marker collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment.
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 a2e11fa735 on 2026-08-25T18:58:42Z, 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.

Clear. Every active stage passes.

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	pass	choudoufu: changing aws_route53_record.status’s ForceNew name argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old object (status.datacite.org./CNAME) is confirmed gone and the new object (ZXDVCKMG54APS4G_status2.datacite.org_CNAME) exists, both via the AWS CLI; the local record store’s record at the same address now names the new object’s identity, not the destroyed one (ZXDVCKMG54APS4G_status.datacite.org_CNAME -> ZXDVCKMG54APS4G_status2.datacite.org_CNAME); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace at the same address (plan only, not applied); F-ORACLE also confirms the four apex NS records this estate’s DELTA 5 manages can never take this same path (Route 53 refuses to delete the NS/SOA record at a zone’s apex), which is why status was chosen instead; BREAK=replace confirms a manufactured identity collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment.
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 da8a74fa9f on 2026-08-25T19:41:38Z, 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.