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 headline stage passes.
| Stage | Verdict | Duration | Detail |
|---|---|---|---|
| Cold deploy | pass | 20s | Apply complete! Resources: 4 added, 0 changed, 0 destroyed.; 0 objects carry tofu-estate=hongbomiao-storage-crossing before migration |
| Migrate | pass | 42s | 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 6adcacec-9273-4dcb-b5f2-61b27810cb74 -> tofu-address=module.kafka_kms_key.aws_kms_key.main |
| Replan from nothing | pass | 3s | 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 | 3s | genuine no-op: 3 objects before, 3 after, no state file either time |
| Drift and reconverge | pass | 6s | 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 | 14s | 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 | 7s | 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 | pass | 24s | choudoufu: scaling aws_s3_bucket.count_test from 2 to 1 destroyed exactly count_test[1] (0 add, 0 change, 1 destroy), leaving count_test[0]’s live CreationDate and tofu-address marker unchanged and tombstoning count_test[1]’s local record (has tombstone, no identity - the #398-guard shape); scaling back from 1 to 2 created exactly count_test[1] under the SAME bucket name (deterministic) but a NEW CreationDate (0 add, 0 change -> 1 add, 0 change, 0 destroy) while count_test[0] stayed untouched throughout; the next plan is empty; the G-ORACLE stock oracle on the same 2-instance count block, applied for real in the idle greenfield real-leg account, shows the identical shape: destroy the higher index only, create the higher index back under the same bucket name but a new CreationDate, the lower index’s CreationDate unchanged both times |
| Replace with create_before_destroy | pass | 13s | 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 (6adcacec-9273-4dcb-b5f2-61b27810cb74, 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 | not run | ||
| Teardown | not run | ||
| Plan, review, apply | pass | 15s | one argument edited (hm_production_bucket’s common_tags gain Reviewed=yes), “plan -out=approved.tfplan” wrote a 10485-byte stock-format plan file whose whole change set is one update on module.hm_production_bucket.aws_s3_bucket.main; the world then moved out of band (hongbomiao-storage-crossing-hm-iot-data’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.s3_bucket_iot_data.aws_s3_bucket.main and the live hongbomiao-storage-crossing-hm-iot-data it was computed against, with “Exit status 3” spelled out for a pipeline; nothing was applied - hongbomiao-storage-crossing-hm-production 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 hongbomiao-storage-crossing-hm-production 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 | 1m4s | 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 (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 3m31.2s.
Oracle: stock terraform 1.16.1, stock tofu 1.12.6 (matches the current pin).
Landed 2026-08-18, the third estate in the OpenTofu-native lane and the second to clear all five stages, reusing corpus-hongbomiao-labelbox’s already-pinned commit rather than a fresh sourcing search (the repo’s OpenTofu-native bona fides and the pinned commit’s clone were already established by that crossing). Scoped after surveying every section of the monorepo’s aws/general and aws/storage files via the GitHub API against the pinned commit, no clone needed for scouting: Kafka Manager, two Amazon EMR sections and AWS Batch all read another environment’s terraform_remote_state (out of scope, same reason corpus-hongbomiao-labelbox’s own scoping excluded them); Amazon SageMaker was ruled out with a real, confirmed floci gap - aws sagemaker create-notebook-instance against a live floci container returns “UnknownOperationException: Operation CreateNotebookInstance is not supported by floci”, and the type has zero entries anywhere in live/floci-capabilities.json’s Cloud Control sweep - documented in the script’s header as evidence for whoever picks up SageMaker next, not filed as an issue since it was routed around rather than blocking anything. The real candidate: aws/storage/main.tofu’s first three module calls (hm_production_bucket, kafka_kms_key, s3_bucket_iot_data) read no remote state at all, unlike everything after them in that file - two amazon_s3_bucket module calls plus one aws_kms_key module call (aws_kms_key + aws_kms_alias). All five stages verified for real against a live floci container: cold_deploy (tofu apply, “4 added, 0 changed, 0 destroyed”, confirmed 0 objects pre-tagged), migrate (live-import: “3 of 4 resource instance(s) are eligible for stamping”, 1 UNTAGGABLE - the KMS alias; -approve: “3 resource(s) newly stamped, 0 already stamped, 0 failed, 1 skipped”; markers for all three read back via raw AWS CLI matched exactly: module.hm_production_bucket.aws_s3_bucket.main, module.s3_bucket_iot_data.aws_s3_bucket.main, module.kafka_kms_key.aws_kms_key.main), test_plan (state deleted, live-plan “No changes”, all three identities re-verified against the AWS CLI, including the untaggable KMS alias’s live target), test_apply (genuine no-op, “0 added, 0 changed, 0 destroyed”, object count unchanged at 3), and drift_reconverge (the IoT-data bucket’s tag tampered out of band, plan proposed fixing exactly module.s3_bucket_iot_data.aws_s3_bucket.main and nothing else, reconverge apply changed exactly 1 resource). BREAK=1 verified load-bearing: correctly fails the stage-2 identity assertion (asserts the KMS key’s tofu-address against a deliberately wrong resource name). No choudoufu gaps found beyond the SageMaker floci evidence above - nothing filed against this repo. Merged to local main as a720266bcc (fix itself: 3335f16893); justfile gained recipe demo-corpus-hongbomiao-storage (port 4725); no new live/corpus-manifest.json entry needed, reuses the existing hongbomiao pin.
Reproduce it#
go run ./tools/gauntlet run corpus-hongbomiao-storageNeeds 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-storage/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.