[Alexanderamiri]

Why

Onboarding javaBin/moresleep (sleepingpill) without architectural changes hits two pipeline gaps:

1. Deploy jobs in javabin.yml were gated on github.ref == 'refs/heads/main'. moresleep's default branch is master, so it would build and plan but never apply or deploy.
2. build-jvm runs mvn verify with no database. moresleep's test suite needs a real PostgreSQL on localhost:5432, which is common for JVM apps.

What

• javabin.yml: the docker-build, tf-apply, ecs-deploy and eb-deploy gates are now github.event_name != 'pull_request' && github.ref == format('refs/heads/{0}', github.event.repository.default_branch). The full ref is compared (review fix), so a tag named like the default branch (refs/tags/master) never deploys; the broker/apply-gate doesn't check the app ref, so this gate is the only branch control. Repos on main behave exactly as before.
• tf-plan.yml: the HIGH-risk Slack NOTIFY flag uses the same default-branch test.
• build-jvm.yml: an optional services.postgres container. Its image comes from the new test_postgres_image input; GitHub skips a service whose image is an empty string (actions/runner#822), so nothing changes for existing callers. Its health check is pg_isready -h 127.0.0.1, with no input interpolated into the docker options string (review fix; 127.0.0.1 also skips the socket-only server the image runs while initialising). The export step fails early unless test_postgres_db / test_postgres_user are plain identifiers and the password has no newline, because the values are written to $GITHUB_ENV. The build step gets PGHOST/PGPORT/PGDATABASE/PGUSER/PGPASSWORD.
• javabin.yml passes new inputs through: test_postgres_image, test_postgres_db, test_postgres_user, test_postgres_password (each defaults to test), and the existing maven_args / gradle_args that build-jvm already accepted but the orchestrator never passed on.
• Docs: docs/reusable-workflows.md (inputs, default-branch rule, a Postgres example) and one line in docs/app-yaml-reference.md.

Not changed: OIDC trust and the broker/apply-gate still pin the platform workflow refs to javaBin/platform@refs/heads/main. They already accept any app repo branch (sub = repo:javaBin/*:*), so nothing in IAM depends on the app's branch name.

How verified

• actionlint on javabin.yml, build-jvm.yml and tf-plan.yml: clean.
• github.event.repository.default_branch is in the payload for push and workflow_dispatch, which are the only events that can reach the deploy jobs (pull requests are excluded explicitly).
• End-to-end proof comes with the moresleep stack PR that calls javabin.yml@main with test_postgres_image: postgres:17.

Follow-ups

• Companion PR: feat(app-yaml): adopt an existing RDS instance and Route53 record (independent; no shared files).
• moresleep migration plan: inventory, cutover and rollback (kept outside the repo).

🤖 Generated with Claude Code

[github-actions]

Terraform Plan

✅ No changes — infrastructure is up to date.

Plan output

Acquiring state lock. This may take a few moments...
aws_ssm_parameter.atlassian_org_id: Refreshing state... [id=/javabin/platform/atlassian-org-id]
aws_ssm_parameter.atlassian_api_key: Refreshing state... [id=/javabin/platform/atlassian-api-key]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

[github-actions]

Terraform Plan

✅ No changes — infrastructure is up to date.

Plan output

Acquiring state lock. This may take a few moments...
aws_ssm_parameter.atlassian_org_id: Refreshing state... [id=/javabin/platform/atlassian-org-id]
aws_ssm_parameter.atlassian_api_key: Refreshing state... [id=/javabin/platform/atlassian-api-key]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

[github-actions]

Terraform Plan

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

Plan output

Acquiring state lock. This may take a few moments...
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.identity.aws_cognito_identity_provider.internal_google[0] will be updated in-place
  ~ resource "aws_cognito_identity_provider" "internal_google" {
        id                = "eu-central-1_Icikv3dtD:Google"
      ~ provider_details  = {
          ~ "authorize_url"                 = "https://accounts.google.com/o/oauth2/v2/auth" -> "https://accounts.google.com/o/oauth2/v2/auth?hd=java.no&prompt=select_account"
            # (8 unchanged elements hidden)
        }
        # (5 unchanged attributes 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 one in-place update to a Cognito Google identity provider, changing only the authorize_url to add an hd=java.no domain hint and prompt=select_account parameter; no creates or destroys.

• ✅ [routine] Single in-place update (0 to add, 1 to change, 0 to destroy) to module.identity.aws_cognito_identity_provider.internal_google[0]. Resource is not replaced and no data is lost.
• 🔒 [security] The hd=java.no parameter is a domain hint that asks Google to restrict or prefer java.no Google Workspace accounts at sign-in. This is a positive change for an internal login flow. Note that hd is a UI hint and is not a server-side enforcement control; Google will still accept accounts from other domains if the user chooses them, so enforcement depends on the app or post-auth checks.
• ✅ [routine] prompt=select_account forces the Google account chooser to appear on each sign-in, which is a UX change with no infrastructure impact.
• 💰 [cost] No new billable resources are created. No cost impact.