docs(rhoso-gitops): restructure pattern docs to JTBD navigation

content/contribute/extending-a-pattern.adoc

@@ -27,7 +27,7 @@ In the example below AMQ Streams (Kafka) is chosen as a product to add to a patt
 
 == Before starting, fork and clone first
 
-. Visit the github page for the pattern that you wish to extend. E.g. https://github.com/hybrid-cloud-patterns/multicloud-gitops[multicloud-gitops]. Select "`Fork`" in the top right corner.
+. Visit the github page for the pattern that you wish to extend. E.g. https://github.com/validatedpatterns/multicloud-gitops[multicloud-gitops]. Select "`Fork`" in the top right corner.
 . On the create a new fork page. You can choose what owner repository you want and the name of the fork. Most times you will fork into your personal repo and leave the name the same. When you have made the appropriate changes press the "Create fork" button.
 . You will need to clone from the new fork onto you laptop/desktop so that you can do the extension work effectively. So on the new fork's main page elect the green "`Code`" button and copy the git repo's ssh address.
 . In an appropriate directory on your laptop (e.g. `~/git`) use `git clone` on the command line using the ssh address copied above. Then create a branch to extend the pattern. For example if you are extending the `multicloud-gitops` pattern and adding kafka, you will need to clone your fork of multicloud-gitops and create a branch to add Kafka:

content/contribute/maintained.adoc

@@ -20,7 +20,7 @@ A pattern categorized under the {maintained} tier implies that the pattern was k
 [id="nominating-a-pattern-for-maintained-tier"]
 == Nominating a pattern for the {maintained} tier
 
-If your pattern qualifies or meets the criteria for {maintained} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
+If your pattern qualifies or meets the criteria for {maintained} tier, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 
 [NOTE]
 ====

content/contribute/pattern-metadata-documentation-sync.adoc

@@ -122,6 +122,6 @@ The workflow validates `repo_url`, flattens the metadata, and opens a pull reque
 
 . Review and merge the resulting pull request in `validatedpatterns/docs`.
 
-Contact mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com] if you need help configuring repository secrets for metadata sync.
+https://groups.google.com/g/validatedpatterns/about[Join the validatedpatterns group] and contact mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com] if you need help configuring repository secrets for metadata sync.
 
 For sync failures, see link:/contribute/pattern-metadata-validation/#metadata-sync-workflow-fails-on-repo-url[Metadata sync workflow fails on repo URL] in Validation and troubleshooting.

content/contribute/support-policies.adoc

@@ -39,7 +39,7 @@ To ensure we can best help you please provide the following information:
 * Any changes that were made prior to the failure
 * Expected Outcome: What you thought should have happened
 
-If you are unsure if your issue is product or pattern related, please reach out to the community using https://groups.google.com/g/validatedpatterns or by emailing validatedpatterns@googlegroups.com 
+If you are unsure if your issue is product or pattern related, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and reach out to the community by posting in the group or emailing mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com]. 
 
 Any pattern-based security issues, such as hard coded secrets, found should be reported to: validated-patterns-team@redhat.com  You can expect a response **within 5 business days**
 

content/contribute/tested.adoc

@@ -20,7 +20,7 @@ The {tested} tier provides you with additional collateral and reassurance that t
 [id="nominating-a-pattern-for-tested-tier"]
 == Nominating a pattern for the {tested} tier
 
-If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
+If your pattern qualifies or meets the criteria for {tested} tier, https://groups.google.com/g/validatedpatterns/about[join the validatedpatterns group] and submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 
 [NOTE]
 ====

content/patterns/rhoso-gitops/_index.adoc

@@ -11,15 +11,17 @@ industries:
   - General
 focus_areas:
   - DevSecOps
-aliases: /rhoso-gitops/
+aliases:
+  - /rhoso-gitops/
+  - /rhoso-gitops/cluster-sizing/
 ci: rhoso-gitops
 ci_sources:
   - base: https://raw.githubusercontent.com/validatedpatterns-sandbox/rhoso-gitops/reporting/
     files:
       - rhoso-gitops-baremetal-4.18-stable-badge.json
 links:
   github: https://github.com/validatedpatterns-sandbox/rhoso-gitops
-  install: getting-started
+  install: deploying-rhoso-gitops-pattern
   bugs: https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues
   feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform
 ---

content/patterns/rhoso-gitops/configuration.adoc

@@ -1,5 +1,5 @@
 ---
-title: Configuration
+title: RHOSO GitOps pattern configuration
 weight: 30
 aliases: /rhoso-gitops/configuration/
 ---

content/patterns/rhoso-gitops/getting-started.adoc → content/patterns/rhoso-gitops/deploying-rhoso-gitops-pattern.adoc

@@ -1,7 +1,9 @@
 ---
-title: Getting started
-weight: 10
-aliases: /rhoso-gitops/getting-started/
+title: Deploying the RHOSO GitOps pattern
+weight: 20
+aliases:
+  - /rhoso-gitops/deploying-rhoso-gitops-pattern/
+  - /rhoso-gitops/getting-started/
 ---
 
 :toc:

content/patterns/rhoso-gitops/secret-management.adoc

@@ -1,6 +1,6 @@
 ---
-title: Secret management
-weight: 25
+title: Secret management for the RHOSO GitOps pattern
+weight: 10
 aliases: /rhoso-gitops/secret-management/
 ---
 
@@ -15,10 +15,10 @@ include::modules/comm-attributes.adoc[]
 The {rhoso-gitops-pattern} requires secrets for OpenStack service passwords, SSH
 key pairs, bare-metal controller credentials, and container registry
 authentication. You can provide these secrets in two ways depending on whether a
-secure storage backend is available. The two approaches can also be combined: for
-example, store shared credentials (registry, subscription) in the backend while
-injecting service-specific passwords as `bootstrap_secrets`, or use
-`onMissingValue: generate` to let the backend generate passwords at deployment
+secure storage backend is available. The two approaches can also be combined, for
+example, by storing shared credentials (registry, subscription) in the backend while
+injecting service-specific passwords as `bootstrap_secrets`, or by using
+`onMissingValue: generate` to have the backend generate passwords at deployment
 time.
 
 For the canonical list of required secrets, see
@@ -33,14 +33,10 @@ Review the following approaches before you deploy the pattern.
 [id="rhoso-secrets-vault-eso"]
 === Secure storage backend and {eso-op}
 
-image::rhoso-gitops/rhoso-gitops-secrets-vault-eso.png[Secure storage backend and {eso-op} secrets flow]
+For production deployments, store secrets in a secure storage backend such as {hashicorp-vault}, AWS Secrets Manager, or any link:https://external-secrets.io/latest/provider/aws-secrets-manager/[provider supported by the {eso-op}]. `ExternalSecret` resources project these secrets into the `openstack` namespace through a `SecretStore`.
 
-This is the recommended approach for production deployments. You store secrets
-in a secure storage backend (for example {hashicorp-vault}, AWS Secrets Manager,
-or any
-link:https://external-secrets.io/latest/provider/aws-secrets-manager/[provider supported by the {eso-op}]).
-`ExternalSecret` resources project these secrets into the `openstack` namespace
-through a `SecretStore`.
+.Secret flow from secure storage method
+image::rhoso-gitops/rhoso-gitops-secrets-vault-eso.png["Secure storage backend and {eso-op} secrets flow"]
 
 The framework does not install the storage backend or the {eso-op}
 automatically. You must include the {eso-op} through the `operator-dependencies`
@@ -65,7 +61,8 @@ This approach uses the following configuration:
 [id="rhoso-secrets-direct-injection"]
 === Direct injection without an external store
 
-image::rhoso-gitops/rhoso-gitops-secrets-direct.png[Direct injection secrets flow]
+.Secret flow for direct injection method
+image::rhoso-gitops/rhoso-gitops-secrets-direct.png["Direct injection secrets flow"]
 
 Use this approach when you do not have a secure storage backend. All secrets are
 defined as `bootstrap_secrets` in the `values-secret.yaml` file. The framework
@@ -92,7 +89,7 @@ contains placeholder entries for each secret.
 | `vault-approle-secret-id`
 | `id`
 | Authentication credential for the {eso-op} `SecretStore` to connect to the
-  secure storage backend. Required only with the backend + {eso-op} approach.
+  secure storage backend. Required only with the backend and {eso-op} approach.
 
 | `osp-secret`
 | Multiple service and database password fields
@@ -203,7 +200,7 @@ bootstrap_secrets:
         path: ~/vault-approle-secret-id
         onMissingValue: error
 
-secrets: []
+secrets: []     # additional secrets loaded into the back end
 ----
 
 . Install the pattern:
@@ -213,7 +210,7 @@ secrets: []
 $ ./pattern.sh make install
 ----
 
-. Verify that the `ExternalSecret` resources are synchronized:
+. Verify that the `ExternalSecret` resources synchronized:
 +
 [source,terminal]
 ----

content/patterns/rhoso-gitops/troubleshooting.adoc

@@ -1,5 +1,5 @@
 ---
-title: Troubleshooting
+title: Troubleshooting the RHOSO GitOps pattern
 weight: 40
 aliases: /rhoso-gitops/troubleshooting/
 ---
@@ -12,9 +12,13 @@ include::modules/comm-attributes.adoc[]
 [id="troubleshooting-rhoso-gitops"]
 = Troubleshooting the {rhoso-gitops-pattern}
 
-Validate the {rhoso-gitops-pattern} deployment, inspect Argo CD application and
-pod status, and review known issues. Use these procedures when child applications
-fail to sync, pods are unhealthy, or you need to confirm a successful deployment.
+Validate the {rhoso-gitops-pattern} deployment and inspect Argo CD application and
+pod status. Use these procedures when child applications fail to sync, pods are
+unhealthy, or you need to confirm a successful deployment.
+
+For known issues that can affect deployment, see
+link:../#rhoso-gitops-known-issues[Known issues] in
+link:../[About the {rhoso-gitops-pattern}].
 
 [id="rhoso-gitops-validate-pattern"]
 == Validating the pattern
@@ -45,23 +49,23 @@ $ ./pattern.sh make argo-healthcheck
 [id="rhoso-gitops-check-argocd"]
 == Checking Argo CD application status
 
-All Argo CD applications run in the `vp-gitops` namespace:
+Confirm the health of the Argo CD applications.
 
-. List applications in `vp-gitops`:
+. Confirm that all Argo CD applications run in the `vp-gitops` namespace:
 +
 [source,terminal]
 ----
 $ oc get applications -n vp-gitops
 ----
 
-. Inspect a child application that is out of sync or unhealthy:
+. Inspect any child application that is out of sync or unhealthy:
 +
 [source,terminal,subs="+quotes"]
 ----
 $ oc describe application __<application_name>__ -n vp-gitops
 ----
 
-Use the Argo CD UI in the `vp-gitops` namespace to review application status,
+. Use the Argo CD UI in the `vp-gitops` namespace to review application status,
 resource health, and diff details for upstream overlays.
 
 [id="rhoso-gitops-check-pods"]
@@ -82,22 +86,5 @@ Review logs for a specific pod:
 $ oc logs -n __<namespace>__ __<pod_name>__
 ----
 
-[id="rhoso-gitops-known-issues"]
-== Known issues
-
-The following known issues can affect pattern deployment:
-
-* *`openstack-secrets` disabled*: The default pattern leaves
-  `openstack-secrets` disabled because no Git path exists.
-  Enable it only after you configure secret wiring. See
-  link:../secret-management/[Secret management for the {rhoso-gitops-pattern}].
-* *Upstream sync failures*: Confirm that `targetRevision` and paths in
-  `overrides/values-rhoso-gitops.yaml` match a tag or branch that exists in
-  link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops].
-* *Operator install delays*: Infrastructure Operators in `operator-dependencies`
-  subscribe from the cluster catalog; allow time for OLM to resolve
-  `ClusterServiceVersions` (CSVs). Other applications retry automatically
-  until their dependencies are satisfied.
-
 For community support, open an issue in the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].

modules/contributing.adoc

@@ -8,15 +8,15 @@
 
 There are a few different ways you can contribute to Validated Patterns documentation:
 
-* Email the Validated Patterns team at mailto:hybrid-cloud-patterns@googlegroups.com[hybrid-cloud-patterns@googlegroups.com].
+*  https://groups.google.com/g/validatedpatterns/about[Join the validatedpatterns group] and email the Validated Patterns team at mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
 * Create a link:https://github.com/validatedpatterns/docs/issues[GitHub] or link:https://issues.redhat.com/projects/MBP/issues[Jira issue] .
 //to-do: Add link to the contribution workflow when we have a proper one. You might need to create a new file
 * Submit a pull request (PR). To create a PR, create a local clone of your own fork of the link:https://github.com/validatedpatterns/docs[Validated Patterns docs repository], make your changes, and submit a PR. This option is best if you have substantial changes.
 //to-do:For more details on creating a PR see <topic_link_to_contribution_workflow>.
 
 == Contribution workflow
 
-When you submit a PR, the https://github.com/orgs/hybrid-cloud-patterns/teams/docs[Validated Patterns Docs team] reviews the PR and arranges further reviews by Quality Engineering (QE), subject matter experts (SMEs), and others, as required. If the PR requires changes, updates, or corrections, the reviewers add comments in the PR. The documentation team merges the PR after you have implemented all feedback, and you have squashed all commits.
+When you submit a PR, the https://github.com/orgs/validatedpatterns/teams/docs[Validated Patterns Docs team] reviews the PR and arranges further reviews by Quality Engineering (QE), subject matter experts (SMEs), and others, as required. If the PR requires changes, updates, or corrections, the reviewers add comments in the PR. The documentation team merges the PR after you have implemented all feedback, and you have squashed all commits.
 
 
 == Repository organization

modules/emerging-disease-detection/metadata-emerging-disease-detection.adoc

@@ -0,0 +1,21 @@
+// This file has been generated automatically from the pattern-metadata.yaml file
+// Do not edit manually!
+:metadata_version: 1.0
+:name: emerging-disease-detection
+:description: This pattern deploys a sepsis early warning system driven by clinical AI at the edge
+:pattern_version: 1.0
+:display_name: Emerging Disease Detection
+:repo_url: https://github.com/validatedpatterns/emerging-disease-detection
+:docs_repo_url: https://github.com/validatedpatterns/docs
+:issues_url: https://github.com/validatedpatterns/emerging-disease-detection/issues
+:docs_url: https://validatedpatterns.io/patterns/emerging-disease-detection/
+:ci_url: https://validatedpatterns.io/ci/?pattern=emerging-disease-detection
+:tier: sandbox
+:owners: dminnear-rh
+:requirements_hub_compute_platform_aws_replicas: 3
+:requirements_hub_compute_platform_aws_type: m5.2xlarge
+:requirements_hub_controlPlane_platform_aws_replicas: 3
+:requirements_hub_controlPlane_platform_aws_type: m5.xlarge
+:extra_features_hypershift_support: true
+:extra_features_spoke_support: false
+:external_requirements: 

modules/rhoso-gitops/rhoso-gitops-about.adoc

@@ -5,11 +5,9 @@
 = About the {rhoso-gitops-pattern}
 
 Deploying {rh-rhoso} spans Operators, networking, and control-plane and data-plane resources.
-Teams that rely on imperative scripts or manual cluster changes face
-slow rollouts, configuration drift, and weak audit trails when you upgrade or
-reproduce the stack.
+Teams that rely on imperative scripts or manual cluster changes can therefore face slow rollouts, configuration drift, and weak audit trails when they try to upgrade or reproduce the stack.
 
-The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public
+The {rhoso-gitops-pattern} addresses these issues by driving {rh-rhoso-short} from public
 Git through Argo CD. Manifests stay declarative and version-controlled, and
 Argo CD reconciles the cluster to match what the repository declares.
 
@@ -38,8 +36,8 @@ The {rhoso-gitops-pattern} uses the following Red Hat products:
 == Cluster scope
 
 {solution-name-upstream} distinguishes between the *initial cluster* (where you
-install the pattern) and *managed clusters* (additional {rh-ocp} clusters or
-hosts managed from that hub, for example through {rh-rhacm}).
+install the pattern) and additional *managed clusters* that are managed by the
+initial cluster, for example, through {rh-rhacm}.
 
 The {rhoso-gitops-pattern} is *single-cluster only*. It does not include
 multi-cluster support, spoke provisioning, or hub-to-spoke {gitops-shortname}
@@ -64,8 +62,7 @@ fan-out.
 |===
 
 Sizing guidance under `requirements.hub` in the pattern repository applies to
-the single target cluster. Managed-cluster requirements (for example eventual
-consistency across spokes) do not apply to this pattern.
+the single target cluster. Requirements that apply only to managed clusters are not relevant for this pattern.
 
 [id="rhoso-gitops-support"]
 == Support
@@ -74,3 +71,24 @@ This is a *sandbox tier* pattern. The community provides support on a
 best-effort basis. For details, see the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/SUPPORT.md[support policy]
 in the pattern repository.
+
+[id="rhoso-gitops-known-issues"]
+== Known issues
+
+The following known issues can affect pattern deployment:
+
+* *`openstack-secrets` disabled*: The default pattern intentionally leaves `openstack-secrets` disabled. Enable `openstack-secrets` only after you have configured secrets in a secure location outside your repository. See
+  link:secret-management[Secret management for the {rhoso-gitops-pattern}] for details.
+* *Upstream sync failures*: Confirm that `targetRevision` and paths in
+  `overrides/values-rhoso-gitops.yaml` match a tag or branch that exists in
+  link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops].
+* *Operator install delays*: Infrastructure Operators in `operator-dependencies`
+  subscribe from the cluster catalog; allow time for the Operator Lifecycle Manager to resolve
+  `ClusterServiceVersions` (CSVs). Other applications retry automatically
+  until their dependencies are satisfied.
+
+For deployment validation and troubleshooting procedures, see
+link:troubleshooting[Troubleshooting the {rhoso-gitops-pattern}].
+
+For community support, open an issue in the
+link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].