feat(route-tls)!: require explicit route_name input

.github/workflows/pr-open.yml

@@ -423,6 +423,7 @@ jobs:
         uses: $/route-tls
         with:
           hostname: myapp.bcgov.ca
+          route_name: actions-openshift-vanity-url
           target_service: my-test-service
           tls_certificate: ${{ env.DUMMY_CERT }}
           tls_private_key: ${{ env.DUMMY_KEY }}
@@ -589,6 +590,7 @@ jobs:
         uses: $/route-tls
         with:
           hostname: myapp.bcgov.ca
+          route_name: actions-openshift-vanity-url
           target_service: my-test-service
           tls_certificate: ${{ env.FORK_CERT }}
           tls_private_key: ${{ env.FORK_KEY }}

AGENTS.md

@@ -25,6 +25,7 @@ Repository facts and constraints for automated coding assistants.
 ## Action Architecture & Rules
 
 - **`route-tls` is standalone only**: When assisting downstream repositories with custom vanity Route TLS, always implement it as an independent on-demand workflow (`.github/workflows/route-tls.yml` on `workflow_dispatch` with `dry_run` choice defaulting to `true`). **NEVER** embed `route-tls` into `merge.yml`, `release.yml`, or continuous deployment pipelines.
+- **`route_name` is required on `route-tls`**: Never assume a default route name. Check the target repository's deployment templates or existing OpenShift routes. For existing repositories migrated from legacy templates, pass `route_name: ${{ github.event.repository.name }}-prod-frontend-vanity` explicitly; for new standalone routes, use `<repository>-vanity-url` so PR-close sweeps do not delete it.
 - **Secret Management**: Certificates belong in the `prod` GitHub Environment (`TLS_CERTIFICATE`, `TLS_PRIVATE_KEY`, `TLS_CA_CERTIFICATE`). Automated assistants must never manage secrets directly; draft copy-pasteable `gh secret set` commands in chat for human maintainers.
 - **Entrust Certificate Mapping**:
   - `TLS_CERTIFICATE`: leaf only (`<host>.pem`).

route-tls/README.md

@@ -45,6 +45,7 @@ Do not embed `route-tls` into `merge.yml`, `release.yml`, or continuous deployme
 - uses: bcgov/actions-openshift/route-tls@vX.Y.Z
   with:
     hostname: app.example.gov.bc.ca
+    route_name: myapp-prod-frontend-vanity
     target_service: myapp-prod
     tls_certificate: ${{ secrets.TLS_CERTIFICATE }}
     tls_private_key: ${{ secrets.TLS_PRIVATE_KEY }}
@@ -54,7 +55,7 @@ Do not embed `route-tls` into `merge.yml`, `release.yml`, or continuous deployme
     oc_token: ${{ secrets.OC_TOKEN }}
 ```
 
-`route_name` defaults to `<repository>-vanity-url` (e.g. `myapp-vanity-url`) so PR-close `app=` sweeps do not delete it. Override `route_name` if you already have a name.
+`route_name` is required. For existing repositories migrated from legacy templates, use the existing OpenShift Route name (typically `<repository>-prod-frontend-vanity`). For new greenfield routes, use `<repository>-vanity-url` so PR-close `app=` sweeps do not delete it.
 
 The action `dry_run` input defaults to `false`. For a manual **Run workflow** form, keep `dry_run` as a choice that defaults to `true`. GitHub shows one `description` string for that input; the dropdown options are still `true` and `false`. Copy this workflow into the app repo (hostname, route, and service are per app). `run-name` and the extra `description` input are workflow UI. They are not action inputs.
 

route-tls/action.yml

@@ -5,9 +5,8 @@ inputs:
     description: "Route spec.host (e.g. myapp.gov.bc.ca). Hostname only, no scheme."
     required: true
   route_name:
-    description: "OpenShift Route name. Defaults to <repository>-vanity-url so it is not swept up with app= label cleanup."
-    required: false
-    default: ${{ github.event.repository.name }}-vanity-url
+    description: "OpenShift Route name (e.g. <repository>-prod-frontend-vanity or <repository>-vanity-url)."
+    required: true
   target_service:
     description: "The OpenShift Service to send traffic to"
     required: true