corpus-hongbomiao-storage • choudoufu

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

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

Set: core. Lane: opentofu-native.

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

Not clear yet.

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

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

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-storage

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-hongbomiao-storage/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.