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 headline stage passes.
| Stage | Verdict | Duration | Detail |
|---|---|---|---|
| Cold deploy | pass | 16s | 4 resources added, 0 objects carry tofu-estate=hongbomiao-labelbox-crossing before migration |
| Migrate | pass | 38s | 2 of 4 stamped (2 skipped, untaggable), 0 failed; markers read back via the AWS CLI |
| Replan from nothing | pass | 3s | no resource change proposed; bucket and role tofu-address unchanged, CORS origins and inline policy resource match config |
| No-op apply | pass | 4s | no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, no state file |
| Drift and reconverge | pass | 6s | bucket tag drifted; exactly module.amazon_s3_bucket_hm_labelbox.aws_s3_bucket.main proposed, applied (1 changed), reconverged to hongbomiao |
| Rename | pass | 11s | 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 | 8s | 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 | pass | 25s | choudoufu: scaling aws_iam_policy.count_test from 2 to 1 destroyed exactly count_test[1] (0 add, 0 change, 1 destroy), leaving count_test[0]’s live PolicyId and tofu-address/tofu-slot markers unchanged, and tombstoning count_test[1]’s own record in place (has tombstone, no identity - the #398-guard shape, not file absence); scaling back from 1 to 2 created exactly count_test[1] under the SAME ARN (deterministic from name+path) but a NEW PolicyId (0 add, 0 change -> 1 add, 0 change, 0 destroy) while count_test[0] stayed untouched throughout, and its record regained a live identity alongside its kept tombstone; the next plan is empty; the G-ORACLE stock oracle on the same 2-instance count block, applied fresh in the idle greenfield account, shows the identical shape: destroy the higher index only, create the higher index back under the same ARN but a new PolicyId, the lower index’s PolicyId unchanged both times; BREAK_COUNT=1 confirms the wrong-instance assertion above is load-bearing |
| Replace with create_before_destroy | pass | 8s | 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 | not run | ||
| Teardown | not run | ||
| Plan, review, apply | pass | 15s | one argument edited (labelbox_iam_role’s common_tags gain Reviewed=yes), “plan -out=approved.tfplan” wrote a 11140-byte stock-format plan file whose whole change set is one update on module.labelbox_iam_role.aws_iam_role.labelbox_iam_role; the world then moved out of band (hongbomiao-labelbox-crossing-hm-labelbox’s hm_team 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.amazon_s3_bucket_hm_labelbox.aws_s3_bucket.main and the live hongbomiao-labelbox-crossing-hm-labelbox it was computed against, with “Exit status 3” spelled out for a pipeline; nothing was applied - LabelboxRole-hm-labelbox 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 LabelboxRole-hm-labelbox read back with Reviewed=yes, so the refusal is earned by the drift and not handed out to every plan file. BREAK_APPROVAL=1 asserts stage 12’s own recorded Break line (apply the planfile after a mutation and expect success) and correctly fails |
| Greenfield apply | pass | 49s | 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 (not a headline stage) | not run |
Last run at commit 933618dec4 on 2026-09-08T22:17:50Z, exit code 0, against emulator image ghcr.io/lex00/floci@sha256:a39185cc3971d0188663d61043cb038dff1260d8a975b1aa72c4e2bb1feac3cb. Stale: the current pin is ghcr.io/lex00/floci@sha256:d9207de14c919f4bfa50e956376cc441970f3679aabfdd43f3dbf4b779b20805. Total run time 3m2.6s.
Oracle: stock terraform 1.16.1, stock tofu 1.12.6 (matches the current pin).
Landed 2026-08-18 as the second estate in the OpenTofu-native lane and the first to clear all five stages there. Stronger OpenTofu-native evidence than corpus-sumaform-aws (which only describes itself as OpenTofu-native but ships plain .tf once its .example template is copied in): every file under infrastructure/opentofu/ genuinely uses the .tofu extension, its own justfile drives init/plan/apply/refresh/destroy exclusively via tofu, and common_tags carries “hm_managed_by” = “opentofu” - proven rather than asserted, since the crossing script’s own stock terraform init against this estate reports “The directory has no Terraform configuration files.” Scoped to the self-contained “Labelbox” slice (S3 bucket, its CORS configuration, an IAM role with an inline S3-read policy - three real leaf modules copied byte-identical from the pinned commit, diffed programmatically in the script) out of a much larger monorepo (AWS+Nebius+Cloudflare+Snowflake+EKS, cross-wired via terraform_remote_state) too large to stand up in one sitting - the same scoping convention corpus-sumaform-aws’s module.base stand-in uses. All five stages verified for real: cold_deploy (tofu apply, 4 resources, confirmed unmarked via resourcegroupstaggingapi), migrate (live-import: “2 of 4 resource instance(s) are eligible for stamping” - 2 correctly UNTAGGABLE, the CORS config via provider-schema fallback and the inline policy via the generated table’s composite ROLENAME:POLICYNAME identity; -approve stamped both taggable resources, markers verified directly via aws s3api get-bucket-tagging / aws iam list-role-tags), test_plan (state deleted, live-plan “No changes”, identities re-checked against the AWS CLI including the two untaggable resources’ own content - CORS AllowedOrigins, inline policy’s Resource ARN - since they carry no tag to re-read), test_apply (genuine no-op, 2 tagged objects before and after), and drift_reconverge (the bucket’s hm_team tag tampered out of band, plan proposed fixing exactly that object, apply reconverged it; BREAK=1 verified load-bearing for both stage 2’s identity check and stage 5’s single-object assertion, tested in isolation for stage 5 per the corpus-vpc-complete convention since the shared BREAK var fails fast at stage 2 otherwise). Two non-blocking findings documented in the script’s own header rather than routed around: aws_s3_bucket/aws_iam_role report DRIFTED during verification from AWS’s own deprecated cors_rule/inline_policy shadow attributes reflecting a sibling resource created after the state snapshot (harmless, resolves by plan time), and the schema-admitted aws_s3_bucket_cors_configuration triggers the already-documented “Resource type has no orphan recovery” warning (live/LIMITATIONS.md, not a new gap). No choudoufu or floci gaps found - nothing filed. Merged to local main as c7fb650f4c (fix itself: 30577f6a56); justfile gained recipe demo-corpus-hongbomiao-labelbox; live/corpus-manifest.json gained the pin (reproducibility only, same convention as the sumaform entry - contributes nothing to a corpus-gen number).
Reproduce it#
go run ./tools/gauntlet run corpus-hongbomiao-labelboxNeeds 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-hongbomiao-labelbox/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.