Add 'coming soon' flag and fix links

content/en/architecture/cli-secret-manager.md

@@ -13,14 +13,14 @@ The Secret Manager CLI is the primary way to manage secrets used in CI workflows
 - List, delete and update existing secrets
 - Retrieve authentication information for the service account tied to a secret collection
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 In the future, we may provide a GUI (e.g., a web interface),
 but currently, the CLI is the only interface available.
-{{< / alert >}}
+{{% /alert %}}
 
-{{< alert title="Security model" color="warning" >}}
+{{% alert title="Security model" color="warning" %}}
 Members of a Rover group can create, update, and delete secrets in their collections, but **cannot read secret values back**. Only the CI infrastructure reads secrets during job execution. This is by design to protect sensitive data.
-{{< /alert >}}
+{{% /alert %}}
 
 ## Prerequisites
 
@@ -157,10 +157,10 @@ Also see [commands cheat sheet](#commands-cheat-sheet) for quick reference.
 
 ## Creating a new secret
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 A secret must belong to both a [collection and a group](#understanding-secret-collections-and-groups).
 Before creating a new secret, make sure you have access to the target collection, or [create a new collection](#creating-a-new-secret-collection).
-{{< / alert >}}
+{{% /alert %}}
 
 To create a new secret, specify the collection and the secret path in `group/field` format:
 
@@ -188,9 +188,9 @@ After you enter the metadata, a secret at `my-collection/aws/access-key-id` will
 Once created, the secret is immediately available for use in CI jobs that reference it via `collection`/`group` in their credential stanzas. 
 For secrets that are part of a [bundle](/how-tos/adding-a-new-secret-to-ci-gsm/#composed-secrets-bundles) (e.g., cluster profile secrets), it may take 1-2 hours for the changes to be propagated.
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 We encourage users to automate secret rotation using the dedicated write-only service account provided for each collection. [Learn more](#getting-the-service-account-associated-with-a-collection).
-{{< /alert >}}
+{{% /alert %}}
 
 ### Creating a secret from a literal string
 
@@ -241,9 +241,9 @@ sm list --rover-group=my-rover-group
 
 This lists all collections configured for the `my-rover-group` Rover group, as defined in [the configuration file](https://github.com/openshift/release/tree/master/core-services/sync-rover-groups/_config.yaml).
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 `--rover-group` refers to your **Rover group** (for access control), which is different from **secret groups** (the organizational hierarchy within collections like `aws`, `gcp`, etc.).
-{{< / alert >}}
+{{% /alert %}}
 
 ### Listing all secret collections
 
@@ -263,9 +263,9 @@ The update takes effect immediately, and the new secret value will be used the n
 
 Previous versions of the secret are retained automatically by the underlying storage. However, the CLI always uses the latest version, and there is currently no way to roll back to a previous version through the CLI.
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 You can only update secrets in collections you have access to. To check which secret collections you have access to, use `sm list --rover-group=<my-rover-group>` or see [the configuration file](https://github.com/openshift/release/tree/master/core-services/sync-rover-groups/_config.yaml).
-{{< / alert >}}
+{{% /alert %}}
 
 ### Updating a secret from file
 
@@ -293,9 +293,9 @@ sm update --help
 
 To remove a secret from a collection, use the `delete` command.
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 You can only delete secrets in collections you have access to. To check which secret collections you have access to, use `sm list --rover-group=<my-rover-group>` or see [the configuration file](https://github.com/openshift/release/tree/master/core-services/sync-rover-groups/_config.yaml).
-{{< / alert >}}
+{{% /alert %}}
 
 ### Example
 

content/en/how-tos/adding-a-new-secret-to-ci-gsm.md

@@ -1,21 +1,21 @@
 ---
-title: "Adding a New Secret to CI"
+title: "Adding a New Secret to CI (Coming Soon)"
 description: How to add and manage secrets used by CI jobs.
 ---
 
-{{< alert title="Coming soon" color="info" >}}
-This page describes the new GSM-based secrets workflow, which is not yet in production.
+{{%  alert title="Coming soon" color="info" %}}
+This page describes the new Google Secret Manager-based secrets workflow, which is not yet in production.
 Until the migration is complete, please continue using the [current Vault-based workflow](/how-tos/adding-a-new-secret-to-ci/).
-{{< /alert >}}
+{{% /alert %}}
 
 Jobs execute as `Pod`s; those jobs that need access to sensitive information can have it mounted from
 [Google Secret Manager](https://cloud.google.com/security/products/secret-manager) (GSM). Secret data is managed
 self-service by the owners of the data using the [Secret Manager CLI](/architecture/cli-secret-manager/).
 
-{{< alert title="Security model" color="warning" >}}
+{{% alert title="Security model" color="warning" %}}
 Secret values **cannot be read back** by users. Only the CI infrastructure reads secrets during job execution.
 This is by design to protect sensitive data.
-{{< /alert >}}
+{{% /alert %}}
 
 ## Add a New Secret
 
@@ -27,11 +27,11 @@ If your team already has a collection, skip to [Step 2](#step-2-create-the-secre
 
 1. Go to [Rover groups](https://rover.redhat.com/groups/) and find an existing group for your team, or create a new one.
 
-   {{< alert title="Important" color="warning" >}}
+   {{% alert title="Important" color="warning" %}}
    The Rover group must have **email/calendar capabilities enabled**. This is required for the access control integration
    to work. When creating a new group, check "Enable mail/calendar capabilities." For existing groups, this setting can be
    enabled in the group settings.
-   {{< /alert >}}
+   {{% /alert %}}
 
 2. Submit a PR to [`openshift/release`](https://github.com/openshift/release) adding your Rover group and collection
    to [`core-services/sync-rover-groups/_config.yaml`](https://github.com/openshift/release/blob/master/core-services/sync-rover-groups/_config.yaml):
@@ -43,9 +43,9 @@ If your team already has a collection, skip to [Step 2](#step-2-create-the-secre
          - your-collection-name
    ```
 
-   {{< alert title="Note" color="info" >}}
+   {{% alert title="Note" color="info" %}}
    Secret collection names are globally unique in our system.
-   {{< /alert >}}
+   {{% /alert %}}
 
 3. After the PR is merged, a postsubmit job will provision the collection. This typically takes under a minute.
 
@@ -170,10 +170,10 @@ credentials:
 
 All fields from all groups in the bundle are mounted under the specified path.
 
-{{< alert title="Note" color="info" >}}
+{{% alert title="Note" color="info" %}}
 Changes to bundles require a PR to `openshift/release`. After the PR is merged, it may take 1-2 hours
 for the changes to be propagated to CI jobs.
-{{< /alert >}}
+{{% /alert %}}
 
 ## Naming Conventions