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

Not clear yet.

StageVerdictDetail
Cold deploypass3 resources added (2 alarms + dashboard), 0 objects carry tofu-estate=leynos-monitoring-crossing before migration
Migratepass2 of 3 stamped (1 skipped, untaggable dashboard), 0 failed; both alarm markers read back via the AWS CLI
Replan from nothingpassno resource change proposed; both alarms’ tofu-address unchanged, dashboard body re-derived and matches distribution_id
No-op applypassno-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, no state file
Drift and reconvergepassS3 alarm’s alarm_description tampered, exactly 1 object proposed and applied, reconverged to its configured description
Renamepassmoved 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 blockpasschoudoufu: 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_destroynot run
Crash between create and destroy (planned)not run
Teardown (planned)not run
Plan, review, apply (planned)not run
Greenfield applypass3 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 20afe6d42d on 2026-08-25T17:28:16Z, exit code 0.

FIVE OF FIVE, real, as of 2026-08-21 (crossing 77be0bc336 base). datapoints_to_alarm DELTA applied per lex00/floci#93’s own suggested workaround (explicit value = evaluation_periods on both alarms, AWS’s own create-time default, so nothing about what stage 1 creates changes) - verified for real, not assumed: the ‘1 -> null’ diff is gone from both stock tofu plan and choudoufu live-plan against the same live alarms. Getting stage 3’s automated assertion to actually SEE the empty plan uncovered a second, real, unrelated choudoufu bug: choudoufu live-plan’s delegation to plain choudoufu plan when a live block is present (plan.Run(originalArgs)) kept originalArgs as a second slice header over live-plan’s own rawArgs backing array rather than an independent copy, and arguments.ParseView’s in-place compaction of recognized flags (like -no-color) silently corrupted it whenever a flag followed -no-color - -target being the realistic case, since every -target/-exclude run hits this same alias. Effect: -no-color never reached the delegate, so live-plan’s output for every -target run (this estate included) carried real ANSI escape codes despite the flag, invisibly breaking any exact-string assertion like stage 3’s “No changes.” check - not a semantics bug (a manual rerun confirmed the plan was already empty before the fix), but the automated proof of it was blind. Fixed in internal/command/live_plan.go (originalArgs := append([]string(nil), rawArgs…)), regression-tested in internal/command/live_mode_test.go (confirmed to fail without the fix, pass with it). Stage 5 then hit a third, distinct, real bug - floci’s: CloudWatch PutMetricAlarm is documented (AWS CLI’s own bundled help) as create-only for tags, so a real out-of-band update can never touch existing tags; floci’s PutMetricAlarm wipes them instead, confirmed directly (list-tags-for-resource: two markers before, empty after an update with no –tags), destroying this crossing’s ownership marker. Filed as https://github.com/lex00/floci/issues/95. Worked around in this harness only (not floci, not a change to what stage 5 tests) by re-applying the known tags via TagResource immediately after each drift call. Re-crossed for real with all three fixes/workarounds in place: cold_deploy 3 resources added; migrate 2 of 3 stamped (dashboard correctly UNTAGGABLE), both tofu-address markers verified via the AWS CLI; test_plan genuinely EMPTY with both alarms’ markers and the dashboard’s re-derived identity re-verified after the state file was deleted; test_apply a genuine no-op, 2 objects before and after, no state file either time; drift_reconverge proposes fixing exactly the one drifted alarm, applies it, and the live value reads back correct. just ci green. BREAK=1 still verified failing at stage 2’s identity assertion (unchanged by this update - that check sits before stage 3 and exits the script before stage 5 is ever reached, a pre-existing property of the script’s control flow, not something this update touched).

EARLIER HISTORY. Landed 2026-08-21 (crossing 841d5dbdde base), the ninth OpenTofu-native estate: leynos/df12-www’s modules/monitoring, a real, actively-maintained personal-site deployment (241 commits, AGPL-3.0, dependabot-active) whose README opens “This repository contains the configuration for my static website deployment using OpenTofu” with no compatibility claim, and whose pinned tree is 34 .tofu files to exactly 1 .tf file (a Terraform test fixture outside this module). Scoped to modules/monitoring specifically: the one leaf module needing nothing else stood up first (bucket_name/distribution_id are free-form dimension strings, never looked up; no remote state, no data source). aws_budgets_budget targeted out of every stage - confirmed genuinely unimplemented by floci (absent from this pin’s floci-capabilities.json service list, absent from /_localstack/health, and a direct aws budgets create-budget call returns UnknownOperationException) - leaving the two aws_cloudwatch_metric_alarm resources and the one aws_cloudwatch_dashboard as the crossed set. cold_deploy: PASS for real, 3 resources added via -target (both alarms plus the dashboard), 0 pre-existing tofu-estate tags. UPDATE 2026-08-21 (re-pinned to sha256:d65baf42…, lex00/floci#88 fixed, build e61a987): migrate: PASS for real. live-import’s dry run verifies 2 of 3 eligible (the dashboard UNTAGGABLE, no tags argument in the provider’s schema); -approve stamps both alarms cleanly, and both tofu-address markers verify directly against CloudWatch through the AWS CLI, never through choudoufu’s own report. test_plan: was failing for real on a real, generalizable choudoufu parity defect, and no longer fails on it. internal/command/live_plan.go threaded args.Operation.Targets only into the final core tfCtx.Plan() call, while statelessResolve/statelessDataReads/statelessDiscover/statelessStamp walked the entire configs.Config regardless of -target and refused hard on the estate’s own aws_budgets_budget (‘Identity argument not set … module.monitoring.aws_budgets_budget.monthly_limit has no value for “account_id”, so its import identity (ACCOUNT_ID:NAME) cannot be built’), a resource scoped out by -target specifically because floci does not implement AWS Budgets. Verified NOT floci’s and NOT a normal admission gap before filing: a plain tofu plan with the identical -target set against the identical unmodified module succeeded cleanly (Plan: 3 to add, 0 to change, 0 to destroy) - stock prunes an untargeted resource out of the graph before ever evaluating it, HANDOFF.md label 2, ‘OpenTofu succeeds, choudoufu refuses’. Filed as https://github.com/INTENTIUS/choudoufu/issues/352 and FIXED there 2026-08-21: the stateless pipeline now reads which resource blocks survive -target/-exclude off the plan graph’s own TargetingTransformer, through a new tofu.Context.TargetedResources, and hands that scope to identity resolution and the data-read phase - so a block stock removed from the graph before evaluating it can no longer refuse the run, dependencies of a targeted resource stay in (the closure is the graph’s own, not a re-derivation), and an out-of-scope block that DOES resolve keeps its resolution so the marker sweep’s declared-address set stays complete. RE-CROSSED FOR REAL at the fix against the same pin (sha256:d65baf42…): that wall is gone - live-plan exits 0, resolves, discovers, stamps and renders a plan over the targeted set. test_plan is STILL ‘fail’, on a different wall one layer in and with a different label: both alarms render ‘- datapoints_to_alarm = 1 -> null’ for an argument this module’s config never sets, so the plan is not empty. Stock reproduces it identically - tofu plan in the stage-1 plain directory against the same live objects, no choudoufu in the process, proposes the same line for the same two alarms - and an ISOLATED minimal reproduction (one alarm, one directory, stock OpenTofu v1.12.5 + hashicorp/aws v5.100.0 against this same floci pin, no choudoufu at all) does not converge either: apply writes datapoints_to_alarm = 1 into state, floci’s DescribeAlarms returns no DatapointsToAlarm key at all, and every later plan wants to remove it. hashicorp/aws 6.x converges cleanly on the same image, so it is specific to the 5.x line this module’s own ‘~> 5.0’ constraint resolves to. HANDOFF.md label 1, ‘OpenTofu fails here too’ - PARITY, an emulator gap and not this fork’s defect. Filed as https://github.com/lex00/floci/issues/93. test_apply/drift_reconverge still not reached: test_plan’s own empty-plan assertion is what gates them. live/e2e/corpus-leynos-monitoring/run.sh’s header updated with both findings. BREAK=1 verified failing at stage 2’s identity assertion in an earlier real run (unaffected by this update - BREAK’s corrupted-marker check sits before stage 3).

Reproduce it#

go run ./tools/gauntlet run corpus-leynos-monitoring

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