lint issues fix

Author: Milstein

docs/openshift/applications/knative-serving.md

@@ -18,7 +18,7 @@ In this tutorial, you will:
 -   Run different revisions of a service via `blue-green` deployments and `canary`
     release.
 
-## **Prerequisites**:
+## **Prerequisites**
 
 -   Setup the OpenShift CLI (`oc`) Tools locally and configure the OpenShift CLI
     to enable `oc` commands. Refer to [this user guide](../../openshift/logging-in/setup-the-openshift-cli.md).
@@ -28,14 +28,15 @@ In this tutorial, you will:
     client `kn` allows you to create Knative resources from the command line or
     from within Shell scripts. Follow the [official documentation](https://docs.redhat.com/en/documentation/red_hat_openshift_serverless/1.37/html/installing_openshift_serverless/installing-kn)
     to download and install the Knative CLI.
-    
+
     You can verify the Knative CLI installation by running the following command:
 
     ```sh
     kn version
     ```
 
-    For more information regarding the [CLI commands](https://docs.redhat.com/en/documentation/red_hat_openshift_serverless/1.37/html/knative_cli/index) available for Knative Functions, Serving, and Eventing.
+    For more information regarding the [CLI commands](https://docs.redhat.com/en/documentation/red_hat_openshift_serverless/1.37/html/knative_cli/index)
+    available for Knative Functions, Serving, and Eventing.
 
 ## Using Knative Serving
 
@@ -180,7 +181,7 @@ spec:
           ...
           annotations:
             serving.knative.openshift.io/enablePassthrough: 'true'
-            ...        
+            ...  
     ...
     ```
 
@@ -252,7 +253,7 @@ spec:
 EOF
 ```
 
-**3. Verification**
+**3. Verification:**
 
 Applying the application service configuration from the previous step creates a
 route, service, revision, and other resources managed by Knative Serving. You can
@@ -274,7 +275,7 @@ verify these components using the following command:
     ```
 
     **Revisions:**
-    
+
     ```sh
     kn revision list
     ```
@@ -328,7 +329,7 @@ oc exec deployment/curl -it -- curl -ik $EXTERNAL_URL
 **Output:**
 
 ```sh
-HTTP/2 200 
+HTTP/2 200
 content-length: 17
 content-type: text/plain; charset=utf-8
 date: Sat, 13 Dec 2025 21:31:58 GMT
@@ -810,14 +811,14 @@ view:
 
 3. Go to "Actions" -> "Edit Service":
     ![Edit Knative Service](images/knative-service-edit.png)
-    
+
     Then modify the service configuration in the *YAML* editor, and click **Save**.
-    For example, change the `timeoutseconds` from `300` to `301`.   
+    For example, change the `timeoutseconds` from `300` to `301`.  
 
     ![Edit Knative Service YAML](images/knative-service-yaml-edit.png)
 
     This change in the configuration triggers a new revision.
-    
+
     In the **Topology** view, the latest revision is displayed and the **Resources**
     tab for the service now displays the two revisions as shown below:
 
@@ -988,7 +989,7 @@ of real user traffic before a full rollout.
         If you do not plan to roll back to the **first revision**, you can remove
         it instead of setting its traffic to 0%. Non-routable revisions are automatically
         garbage-collected.
-  
+
 11. Visit the **URL of the first revision** to confirm that no traffic is being
     routed to the old version of the application.
 

docs/openshift/applications/understanding-openshift-serverless.md

@@ -67,15 +67,16 @@ and microservices to small, single-purpose functions.
 
 It has **three primary components**:
 
-- [**Serving**](https://knative.dev/docs/serving/): Enables rapid deployment and
-automatic scaling of containers through a request-driven model, serving workloads based on demand.
+-   [**Serving**](https://knative.dev/docs/serving/): Enables rapid deployment and
+    automatic scaling of containers through a request-driven model, serving workloads
+    based on demand.
 
-- [**Eventing**](https://knative.dev/docs/eventing/): Provides the infrastructure
-to consume and produce events that trigger applications. Applications can be
-triggered by internal event sources, cloud services, or Red Hat AMQ streams.
+-   [**Eventing**](https://knative.dev/docs/eventing/): Provides the infrastructure
+    to consume and produce events that trigger applications. Applications can be
+    triggered by internal event sources, cloud services, or Red Hat AMQ streams.
 
-- [**Functions**](https://knative.dev/docs/functions/): Offers a flexible approach
-to building source code into containers.
+-   [**Functions**](https://knative.dev/docs/functions/): Offers a flexible approach
+    to building source code into containers.
 
 ### What is OpenShift Serverless?
 
@@ -117,11 +118,11 @@ With serverless, infrastructure management is handled for you. You simply provid
 a container image and run it on the cluster - everything else is automatically managed.
 
 In Knative, deployment is even simpler: you define a small resource file called
-a **[Knative Service](#knative-serving)**, which specifies the container image to
-run. When applied to the cluster, the Knative Operator automatically creates all
-necessary resources, including the deployment, service, route (if needed), and a
-configuration resource. The configuration resource also manages revisions, making
-it easy to roll back to previous versions when required.
+a **[Knative Service](#knative-functions)**, which specifies the container image
+to run. When applied to the cluster, the Knative Operator automatically creates
+all necessary resources, including the deployment, service, route (if needed),
+and a configuration resource. The configuration resource also manages revisions,
+making it easy to roll back to previous versions when required.
 
 ![Knative Deployment](images/knative_deployment.png)
 
@@ -146,9 +147,11 @@ Knative serverless application components:
 
 The main components of the OpenShift Serverless architecture are:
 
-**Knative Serving**: Enables developers to create cloud-native applications using
-a serverless architecture. It provides Custom Resource Definitions (CRDs) that
-developers can use to deploy serverless containers, manage pod scaling, and more.
+### Knative Serving
+
+Enables developers to create cloud-native applications using a serverless architecture.
+It provides **Custom Resource Definitions (CRDs)** that developers can use to deploy
+serverless containers, manage pod scaling, and more.
 
 Knative Serving is responsible for:
 
@@ -167,14 +170,15 @@ deployment, dynamically scaling with traffic, and supporting traffic-split rollo
 
 **[Watch a video about Knative Serving](https://www.youtube.com/watch?v=oKIHoDzw1RI)**
 
-**Knative Eventing**: Provides the infrastructure for building and deploying
-event-driven applications. It allows developers to define event sources and sinks
-and offers mechanisms to route events to functions, applications, or other event
-sinks.
+### Knative Eventing
+
+Provides the infrastructure for building and deploying *event-driven applications*.
+It allows developers to define event sources and sinks and offers mechanisms to
+route events to functions, applications, or other event sinks.
 
 Knative Eventing is an event-driven platform that uses CloudEvents with a simple
 *HTTP* interface. It enables late-binding of event sources and consumers, allowing
-services to be loosely coupled, independently deployed, and connected without 
+services to be loosely coupled, independently deployed, and connected without
 modifying producers or consumers.  
 
 **Event Mesh:** Supports responsive, scalable, and resilient architectures by