[Alexanderamiri]

Summary

The registry group sync kept adding JavaZone volunteers to javazone@java.no. That is the JavaZone coordination group's list, and only koordineringsgruppa may be in it. A group marked manual: true in the registry's groups.yaml is now kept by hand: nothing syncs into it or plans removals from it.

 provision-groups.py   resolve_memberships
+  manual group → members [] (still sent, so access groups can nest it)
 team-provisioner      handle_sync_groups_and_heros / handle_sync_groups
+  skip manual groups (no Google, Cognito or Identity Center sync)
 reconcile-groups.py   generate_plan
+  no removals planned from manual groups
 provision-groups.py / diff-groups.py
+  no removal warning or membership plan lines for manual groups; plan shows the `manual` flag
 sync-members.py       GROUP_MAP
-  "JavaZone": "javazone"
+  "JavaZone": None   (known choice, no group, no warning)
 sort-members.py       GROUP_PRIORITY drops javazone

Background, from the Google audit log: admin removed ~35 synced users from javazone@java.no on 2026-08-04, and the provisioner re-added ~37 on 2026-10-23, because the registry listed javazone for 36 heroes. Jan Erik cleaned the group by hand on 2026-11-11. It now holds only the nested jz-koordineringsgruppen and three coordinators.

Evidence

• Before: with the new tests and the old code, python3 -m unittest scripts/tests/test_manual_groups.py terraform/lambda-src/tests/test_team_provisioner_google_group.py → FAILED (failures=6)
  After: python3 -m unittest discover -s scripts/tests → 228 OK, python3 -m unittest discover -s terraform/lambda-src/tests → 267 OK

Review focus

• handler.py handle_sync_groups_and_heros: manual groups are left out of Step 3 only. They stay in the Step 6 maps, so an access group can still nest them.
• provision-groups.py: a manual group goes to the Lambda with members: [] and manual: true. An older Lambda therefore only ensures the group exists.

Out of scope: validation skips bot-opened registry PRs; sheet syncs overwrite memberships added by hand; the Apps Script never adds helter. All three predate this PR.

Merge danger

Door: two-way
Blast radius: registry group sync

Applies to prod (single account) via platform CI. Merge this before javaBin/registry fix/javazone-manual-group. Either order is safe against new additions. Revert restores the old behaviour, but the registry no longer lists javazone memberships, so nobody would be re-added.

OpenSpec

spec-free: the repo has no openspec/; this is a bug fix to registry sync behaviour, documented in docs/lambda-functions.md.

🤖 Generated with Claude Code

[github-actions]

Terraform Plan

🚧 Changes detected — Plan: 0 to add, 1 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.team_provisioner will be updated in-place
  ~ resource "aws_lambda_function" "team_provisioner" {
        id                             = "javabin-team-provisioner"
      ~ last_modified                  = "2026-10-31T14:54:15.000+0000" -> (known after apply)
      ~ source_code_hash               = "tpW4OZM/7/EBE9sKi6c6DAazYfsyHZV2rG/JJUYTTng=" -> "WAVhnqy7u14WWq5Jd9Cm0Gl3MjAcj0FTvfjPWPYUxkc="
        tags                           = {}
        # (21 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 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 makes a single in-place update to the Lambda function javabin-team-provisioner, changing only its deployment package (source_code_hash), with no creates or destroys.

• ✅ [routine] Plan: 0 to add, 1 to change, 0 to destroy. The only change is an in-place update to aws_lambda_function.team_provisioner (module.lambdas), which is a routine code deployment.
• ✅ [routine] source_code_hash changes from tpW4OZM/... to WAVhnqy7u14... , indicating new function code is being deployed. last_modified is computed by AWS and will update on apply. The function name, role, and configuration are unchanged in this plan.
• 🔒 [security] No IAM, security group, networking, or public-access changes are present in this plan. The function's execution role and any permissions are not modified. Worth confirming the new package contents came from a reviewed commit, since this plan only shows the hash change.
• 💰 [cost] No new billable resources are created. No NAT gateways, RDS instances, or load balancers are involved. Cost impact is negligible.
• 💥 [destruction] No resources are destroyed and no data-loss risk is present. The update is in-place, so the function is not replaced.