[Alexanderamiri]

Follow-up to #147, which merged before this review fix was pushed.

Why

With no ceiling, a plan beyond Haiku 5.5's 1M-token context fails the review with a Bedrock ValidationException, which blocks the apply until a board override. The review of #147 recommended a ceiling well above any real plan.

What changed

• REVIEW_MAX_PLAN_CHARS defaults to 2,000,000 chars, about 500–800k tokens and 2.4× the largest real plan (fix(ci): create team CI roles only for registry teams #135, 830k chars). Real plans are still sent whole. Only a pathological plan falls back to the change-list mode (every change listed, diff cut at a resource boundary, with a notice).
• The prompt's (known after apply) explanation is corrected: the value is derived from other resources too, so judge the expression, not a value.
• post-plan-comment.sh removes its temp file.

Checks

Both test suites pass, with new tests for real-size plans sent whole and the fallback above the ceiling.

🤖 Generated with Claude Code

[github-actions]

Terraform Plan

🚧 Changes detected — Plan: 0 to add, 2 to change, 0 to destroy.

Plan output

aws_ssm_parameter.atlassian_api_key: Refreshing state... [id=/javabin/platform/atlassian-api-key]
aws_ssm_parameter.atlassian_org_id: Refreshing state... [id=/javabin/platform/atlassian-org-id]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.lambdas.aws_lambda_function.plan_review will be updated in-place
  ~ resource "aws_lambda_function" "plan_review" {
        id                             = "javabin-plan-review"
      ~ last_modified                  = "2026-10-24T10:10:00.000+0000" -> (known after apply)
      ~ source_code_hash               = "/8yu4g6XvIIadpmJIe8NpYaMwirjOXaELSMURiUMWjA=" -> "e9X15ZWURfd4volxoEzZ3Pio4Ye7IRZdyO+wqk0tJQk="
        tags                           = {}
        # (21 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

  # module.lambdas.aws_lambda_function.team_provisioner will be updated in-place
  ~ resource "aws_lambda_function" "team_provisioner" {
        id                             = "javabin-team-provisioner"
      ~ last_modified                  = "2026-10-24T10:10:06.000+0000" -> (known after apply)
      ~ source_code_hash               = "1ifiVECetMs6R67lL80m2pjRucXGxeHaYxQZOle4QgU=" -> "FAeZVoTR17JeVhPKvfbv/DFKxW9BcEfhSFcdISb7rKo="
        tags                           = {}
        # (21 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

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

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

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

---

LLM Review

Risk: 🟢 LOW

Plan updates two existing Lambda functions in place (javabin-plan-review and javabin-team-provisioner) with new source code hashes; no resources are created or destroyed.

• ✅ [routine] module.lambdas.aws_lambda_function.plan_review: in-place update of source_code_hash only (code deployment). No configuration, IAM role, or environment changes are shown in the diff.
• ✅ [routine] module.lambdas.aws_lambda_function.team_provisioner: in-place update of source_code_hash only (code deployment). No configuration, IAM role, or environment changes are shown in the diff.
• 💥 [destruction] Plan shows 0 destroys and 0 replacements. Both functions keep their identity (id unchanged), so no downtime from recreation is expected.
• 🔒 [security] No IAM, security group, or public-access changes appear in this plan. The unchanged attributes are hidden by Terraform, so any role or policy changes would have appeared in the diff; none are present.
• 💰 [cost] No new billable resources are added. Lambda code updates do not change cost meaningfully.