fix(ci): linting issue after new release

this commit fixes the linting issues after a new
vale release changes the rule I guess.

Signed-off-by: Zaki Shaikh <zashaikh@redhat.com>

Author: zakisk

.vale.ini

@@ -33,5 +33,5 @@ RedHat.TermsErrors = NO
 BasedOnStyles = RedHat, PaaC
 
 # Ignore code surrounded by backticks or plus sign, parameters defaults, URLs, Hugo-style shortcode relref.
-TokenIgnores = (\x60[^\n\x60]+\x60), ([^\n]+=[^\n]*), (\+[^\n]+\+), (http[^\n]+\[), (\[[^\n]+\]), \(\{\{<\s*relref\s+\"[^\"]+\"\s*>}}\)
+TokenIgnores = (\x60[^\n\x60]+\x60), ([^\n]+=[^\n]*), (\+[^\n]+\+), (http[^\n]+\[), (\[[^\n]+\]), \(\{\{<\s*relref\s+\"[^\"]+\"\s*>}}\), (\(#[^\)]+\))
 

docs/content/_index.md

@@ -4,12 +4,12 @@ toc: false
 hero_subtitle: "An opinionated CI based on Tekton."
 ---
 
-Pipelines as Code lets you define your CI/CD using
+Pipelines-as-Code lets you define your CI/CD using
 [Tekton](https://tekton.dev) PipelineRuns and Tasks in files stored directly
 alongside your source code. Your pipeline definitions are versioned, reviewed,
 and collaborated on just like your application code — bringing the full power of
 the Git workflow to your CI/CD pipelines. With a single pane of glass from your
-SCM provider (GitHub, GitLab, Bitbucket, or Forgejo), pipeline runs are
+SCM provider (GitHub, GitLab, Bitbucket, or Forgejo), PipelineRuns are
 automatically triggered for Pull Requests and Push events.
 
 {{< cards >}}

docs/content/docs/guides/event-matching/_index.md

@@ -68,7 +68,7 @@ annotations:
 Pipelines-as-Code runs the PipelineRun `pipeline-push-on-1.0-tags` when you push the `1.0` tag to your repository.
 
 {{< callout type="warning" >}}
-GitHub does not send webhook events when more than three tags are pushed simultaneously (e.g., with `git push origin --tags`). To ensure pipeline runs are triggered for all tags, push them in batches of three or fewer. [See GitHub's docs here](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#create).
+GitHub does not send webhook events when more than three tags are pushed simultaneously (e.g., with `git push origin --tags`). To ensure PipelineRuns are triggered for all tags, push them in batches of three or fewer. [See GitHub's docs here](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#create).
 {{< /callout >}}
 
 ## Required annotations and parallel execution

docs/content/docs/guides/llm-analysis/_index.md

@@ -5,7 +5,7 @@ weight: 8
 
 {{< tech_preview >}}
 
-Pipelines-as-Code can analyze your CI/CD pipeline runs using Large Language Models (LLMs). An LLM is an AI service (such as OpenAI or Google Gemini) that reads pipeline logs and failure data, then posts human-readable analysis directly on your pull requests.
+Pipelines-as-Code can analyze your CI/CD PipelineRuns using Large Language Models (LLMs). An LLM is an AI service (such as OpenAI or Google Gemini) that reads pipeline logs and failure data, then posts human-readable analysis directly on your pull requests.
 
 Use this feature when you want automated root-cause analysis of pipeline failures without manually reading through logs.
 

docs/content/docs/guides/repository-crd/comment-settings.md

@@ -47,7 +47,7 @@ GitLab's commit status API to identify which pipelines previously succeeded,
 ensuring only failed pipelines are re-run. If commit statuses were never
 reported (for example, because both status updates failed and only a comment was
 posted), Pipelines-as-Code cannot determine prior results and will fail to
-re-run any pipelines when `/retest` unless you retest individual pipelineruns
+re-run any pipelines when `/retest` unless you retest individual PipelineRuns
 with `/test <pipeline-name>`.
 
 When a status update succeeds, you can see the status in the GitLab UI in the `Pipelines` tab, as