tfcmt plan result isn't intuitive when moved block is used

[suzuki-shunsuke]

Versions

$ tfcmt -v
tfcmt version 3.2.5 (904dacccd7081d9ef2a74f5ba31f833e470fd559)

$ terraform version
Terraform v1.2.4
on darwin_arm64
+ provider registry.terraform.io/hashicorp/null v3.1.1

How to reproduce

Run terraform apply to create.

main.tf

resource "null_resource" "foo" {}

$ terraform apply -auto-approve

Then update main.tf using moved block.

resource "null_resource" "bar" {}

moved {
  from = null_resource.foo
  to   = null_resource.bar
}

And run tfcmt plan.

$ tfcmt plan -- terraform plan
null_resource.bar: Refreshing state... [id=1968536679283731966]

Terraform will perform the following actions:

  # null_resource.foo has moved to null_resource.bar
    resource "null_resource" "bar" {
        id = "1968536679283731966"
    }

Plan: 0 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

Expected Behavior

The plan result is no change.

Actual Behavior

tfcmt treats the result as add-or-update, so tfcmt adds a pull request label add-or-update.

Note

The exit code of terraform plan -detailed-exitcode is not zero but two.

-detailed-exitcode Return detailed exit codes when the command exits. This
will change the meaning of exit codes to:
0 - Succeeded, diff is empty (no changes)
1 - Errored
2 - Succeeded, there is a diff

$ terraform plan -detailed-exitcod
$ echo $?
2

It means Terraform itself treats the result as there is a diff.
So tfcmt's current behavior isn't wrong.

But I guess it would not be intuitive.

[suzuki-shunsuke]

I don't think this is a bug, but maybe it is useful to add an option to treat the result as no change.