Evidence · How close AWS is

corpus-evoteum-modules

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 headline stage passes.

Stale: since the run recorded above, this estate’s own files have changed (live/e2e/corpus-evoteum-modules/run.sh differs from the version that run measured), and the shared protocol library live/e2e/lib that this script sources has changed (live/e2e/lib/gauntlet.sh differs from the version that run measured). Every verdict in the table above was measured against the earlier version, so a stage those edits fixed still reads fail here, and a stage they broke still reads pass; only a re-run of this estate settles it (#1264, #1292).

StageVerdictDurationDetail
Cold deploypass33s10 resources added (1 vpc, 3 subnets, 1 igw, 1 route table, 3 associations, 1 dynamodb table); confirmed unmarked
Migratepass24s7 of 10 verified and stamped, 0 failed, 3 correctly UNTAGGABLE; markers read back via the AWS CLI
Replan from nothingpass5sno changes; VPC and table markers unchanged, all three untaggable associations resolved by their composite identity
No-op applypass3sno-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 7, no state file
Drift and reconvergepass8sVPC Name tag tampered out of band, exactly 1 object proposed and reconverged, marker survived the incremental tag update
Renamepass14smoved 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 blockpass10schoudoufu: 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 countpass19schoudoufu: dropping the last public_subnets CIDR (10.0.103.0/24) destroyed exactly its subnet and route-table-association instances (0 add, 0 change, 2 destroy), leaving both survivor subnets’ live ids and tofu-address markers unchanged; the destroyed subnet’s local record is tombstoned, not deleted (#398-guard shape, asserted by value); restoring the CIDR created exactly the same two instances under NEW live ids (subnet id and association id both server-minted, verified directly against floci with no tofu in the loop before writing this assertion) while both survivors stayed untouched throughout; the next plan is empty; the G-ORACLE stock oracle on the identical public_subnets edit, applied plan-only on cold_deploy’s own state, shows the identical shape: destroy the dropped CIDR’s subnet and association only, create them back under new ids, every other subnet/association’s id unchanged both times
Replace with create_before_destroypass16schoudoufu: 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 mid-applynot run
Teardownnot run
Plan, review, applypass17sone argument edited (module.networking’s internet gateway gains a Reviewed=yes tag; an in-place update, never a replace, because PART G below re-reads this estate’s subnet ids by value), “plan -out=approved.tfplan” wrote a 17815-byte stock-format plan file whose whole change set is one update on module.networking.aws_internet_gateway.main; the world then moved out of band (vpc-9f8c0f5f’s Name tag, through the AWS CLI, never through choudoufu) and “apply approved.tfplan” refused with “The approved plan no longer matches the live system” at exit 3, classifying the drift under “This apply would do, and the approved plan does not include:” and naming both module.networking.aws_vpc.main and the live vpc-9f8c0f5f it was computed against, with “Exit status 3” spelled out for a pipeline; nothing was applied - igw-e2d8ed6d still carried no Reviewed tag, read back through the AWS CLI rather than from the absence of an “Apply complete!” line. Inverted control on the same run (the shape live/smoke/scenarios/apply-what-was-approved.sh reasons out): with the tag put back and nothing else changed, the IDENTICAL file applied - 0 added, 1 changed, 0 destroyed - and igw-e2d8ed6d read back with Reviewed=yes, so the refusal is earned by the drift and not handed out to every plan file. The revert is proven byte-for-byte against the corpus pin (copy_modules’ own diff, re-run) and the three subnets PART G re-reads are still the three cold_deploy minted. BREAK_APPROVAL=1 asserts stage 12’s own recorded Break line (apply the planfile after a mutation and expect success) and correctly fails
Greenfield applypass33s10 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 (not a headline stage)not run
Plan with no local state (not a headline stage)not run

Last run at commit f707182267 on 2026-10-02T19:19:40Z, exit code 0, against emulator image ghcr.io/lex00/floci@sha256:6c3d5c2dac72209e6f2e45c08902e783480d4d34f48d25daba8da94b9f882072. Stale: the current pin is ghcr.io/lex00/floci@sha256:ff46eb8d1b73a9727948d1a194a660972e44cc64164a486548da7cb468a09144. Total run time 3m2.1s. Oracle: stock terraform 1.16.1, stock tofu 1.13.0 (matches the current pin). Engine: OpenTofu base 1.13.0 (matches the current base).

Landed 2026-08-19 (crossing f388f7891c, merge a749395e48), the eighth OpenTofu-native estate and the second from a commercial vendor. OpenTofu-native evidence, four independent kinds, all asserted by the script: self-description as OpenTofu’s with no compatibility claim; zero .tf files in the whole pinned tree (109 .tofu, 0 .tf); .pre-commit-config.yaml running tofuutils/pre-commit-opentofu’s tofu_validate/tofu_fmt with no Terraform hook; and .tofutest.hcl unit tests, the first evidence in this lane Terraform could not parse. Production code - the org’s own estate-config repo calls aws/bucket from it over a setproduct() for_each. Scoped to the two of eleven AWS modules that are self-contained; nine excluded with stated reasons, aws/bucket because its name folds random_password.result (the secret-bearing twin of the random_pet wall corpus-lambda-simple already hits). One delta, asserted at exactly one line: aws/networking/main.tofu’s aws constraint ~> 5.0 -> = 6.59.0 (tofu init refuses the root’s own pin otherwise); aws/dynamodb byte-identical. Real run rc=0. cold_deploy: 10 instances, both for_each expansions confirmed at 3 keys. migrate: 7 of 10 stamped, 3 UNTAGGABLE route table associations. test_plan: EMPTY with the state file deleted, VPC/subnet/route-table/table markers re-read through the AWS CLI and all three untaggable associations independently confirmed as their {route_table_id}/{subnet_id} composite says. test_apply: genuine no-op, 7 objects before and after, no state file either time. drift_reconverge: exactly module.networking.aws_vpc.main proposed and fixed, marker surviving the incremental tag update. Both negative controls (BREAK=1, BREAK_STAGE5=1) verified failing in real full runs. First estate in either lane whose for_each keys fall outside the AWS tag-value charset ([A-Za-z0-9 _.:/=+@-]), so EscapeAddress is load-bearing: the marker is module.networking.aws_subnet.public:10@d0@d101@d0/24, and the expected values are hand-written from internal/live/markers/markers.go:196’s own rule rather than computed by the code under test, each checked to be inside the AWS charset. No Go code touched; nothing in this estate refused - live-plan’s diagnostic surface is empty, not merely small. justfile gained demo-corpus-evoteum-modules (port 4730); live/corpus-manifest.json gained the pin; HANDOFF.md section 3 updated, including a correction of its own stale ‘four of six’ figure to three of six (this manifest was always the source of truth and never agreed with that prose claim).

Reproduce it

go run ./tools/gauntlet run corpus-evoteum-modules

Needs Docker (the emulator is pulled at the pinned digest), the AWS CLI, and a stock terraform or tofu binary on PATH for the cold deploy. The script is live/e2e/corpus-evoteum-modules/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.