Add linters to CI

.gherkin-lintrc

@@ -0,0 +1 @@
+{}

.github/labeler.yml

@@ -11,6 +11,6 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-
+---
 workflow:
-  - ./*
+  - ./*

.github/workflows/labeler.yml

@@ -18,13 +18,12 @@
 # To use this workflow, you will need to set up a .github/labeler.yml
 # file with configuration.  For more information, see:
 # https://github.com/actions/labeler/blob/master/README.md
-
+---
 name: Labeler
-on: [pull_request]
+on: [pull_request] # yamllint disable-line rule:truthy
 
 jobs:
   label:
-
     runs-on: ubuntu-latest
 
     steps:

.github/workflows/lint.yml

@@ -0,0 +1,70 @@
+# Copyright 2020 The Serverless Workflow Specification Authors
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# This workflow will run a set of linters on all files in the repository
+# to ensure consistent formatting and style.  It uses the super-linter
+# action, which is a combination of many linters and formatters.
+#
+# For more information, see:
+# https://github.com/super-linter/super-linter/blob/main/README.md
+---
+name: Lint
+on: # yamllint disable-line rule:truthy
+  push:
+    branches: ["main"]
+    paths:
+      - "**/*.md"
+      - "**/*.yaml"
+  pull_request:
+    branches: ["main"]
+    paths:
+      - "**/*.md"
+      - "**/*.yaml"
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+
+    permissions:
+      contents: read
+      packages: read
+      # To report GitHub Actions status checks
+      statuses: write
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          # super-linter needs the full git history to get the
+          # list of files that changed across commits
+          fetch-depth: 0
+      - uses: super-linter/super-linter@v6.5.1
+        env:
+          # To report GitHub Actions status checks
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+          # relative to $DEFAULT_WORKSPACE=$GITHUB_WORKSPACE
+          LINTER_RULES_PATH: "."
+
+          # check all files (including unmodified) in the repository
+          VALIDATE_ALL_CODEBASE: true
+
+          VALIDATE_MARKDOWN: true
+          MARKDOWN_CONFIG_FILE: .markdownlint.yaml
+
+          VALIDATE_YAML: true
+          YAML_CONFIG_FILE: .yamllint.yaml
+
+          VALIDATE_GHERKIN: true
+          VALIDATE_GITHUB_ACTIONS: true
+          VALIDATE_JSON: true

.github/workflows/schema-check.yaml

@@ -18,20 +18,20 @@
 # To use this workflow, you will need to set up a .github/labeler.yml
 # file with configuration.  For more information, see:
 # https://github.com/actions/labeler/blob/master/README.md
-
+---
 name: Verify Specification Examples
 
-on:
+on: # yamllint disable-line rule:truthy
   push:
-    branches: [ "main" ]
+    branches: ["main"]
     paths:
-      - 'schema/**'
-      - 'examples/**'
+      - "schema/**"
+      - "examples/**"
   pull_request:
-    branches: [ "main" ]
+    branches: ["main"]
     paths:
-      - 'schema/**'
-      - 'examples/**'
+      - "schema/**"
+      - "examples/**"
 
 jobs:
   build:
@@ -44,12 +44,12 @@ jobs:
         node-version: [21.x]
 
     steps:
-    - uses: actions/checkout@v4
-    - name: Use Node.js ${{ matrix.node-version }}
-      uses: actions/setup-node@v4
-      with:
-        node-version: ${{ matrix.node-version }}
-        cache: 'npm'
-        cache-dependency-path: .ci/validation/package-lock.json
-    - run: npm install
-    - run: npm test
+      - uses: actions/checkout@v4
+      - name: Use Node.js ${{ matrix.node-version }}
+        uses: actions/setup-node@v4
+        with:
+          node-version: ${{ matrix.node-version }}
+          cache: "npm"
+          cache-dependency-path: .ci/validation/package-lock.json
+      - run: npm install
+      - run: npm test

.github/workflows/stale.yml

@@ -11,27 +11,40 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-
+---
 name: Mark stale issues and pull requests
 
-on:
+on: # yamllint disable-line rule:truthy
   schedule:
     - cron: "0 0 * * *"
 
 jobs:
   stale:
-
     runs-on: ubuntu-latest
 
     steps:
       - uses: actions/stale@v3
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          stale-issue-message: 'This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
-          stale-pr-message: 'This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
-          stale-issue-label: 'Stale Issue'
-          exempt-issue-labels: 'Status: Blocked, Status: In progress, Status: On hold, Status: Awaiting response'
-          stale-pr-label: 'Stale PR'
-          exempt-pr-labels: 'Status: Blocked, Status: In progress, Status: On hold, Status: Awaiting response'
+          stale-issue-message: >
+            This issue has been automatically marked as stale because it has
+            not had recent activity. It will be closed if no further activity
+            occurs. Thank you for your contributions.
+          stale-pr-message: >
+            This pull request has been automatically marked as stale because it
+            has not had recent activity. It will be closed if no further
+            activity occurs. Thank you for your contributions.
+          stale-issue-label: "Stale Issue"
+          exempt-issue-labels: >
+            Status: Blocked,
+            Status: In progress,
+            Status: On hold,
+            Status: Awaiting response
+          stale-pr-label: "Stale PR"
+          exempt-pr-labels: >
+            Status: Blocked,
+            Status: In progress,
+            Status: On hold,
+            Status: Awaiting response
           days-before-stale: 45
           days-before-close: 20

.markdownlint.yaml

@@ -11,13 +11,13 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-
+---
 {
   "default": true,
-  "MD024": { "allow_different_nesting": true },
+  "MD024": { "siblings_only": true },
   "MD029": { "style": "ordered" },
-  "ul-style": false,  # MD004
-  "line-length": false,  # MD013
-  "no-inline-html": false,  # MD033
-  "fenced-code-language": false  # MD040
+  "ul-style": false, # MD004
+  "line-length": false, # MD013
+  "no-inline-html": false, # MD033
+  "fenced-code-language": false, # MD040
 }

.typo-ci.yml

@@ -1,5 +1,4 @@
 ---
-
 # What language dictionaries should it use? Currently Typo CI supports:
 # de
 # en
@@ -22,7 +21,7 @@ excluded_files:
   - ".typo-ci.yml"
   - ".markdownlint.yaml"
   - "Makefile"
-  
+
 # Any typos we should ignore?
 excluded_words:
   - typoci

.vscode/extensions.json

@@ -0,0 +1,3 @@
+{
+  "recommendations": ["davidanson.vscode-markdownlint", "redhat.vscode-yaml"]
+}

.vscode/settings.json

@@ -1,12 +1,22 @@
 {
-    "rewrap.wrappingColumn": 80,
-    "editor.rulers": [80],
-    "markdownlint.config": {
-        "MD004": false,
-        "MD013": false,
-        "MD024": {"allow_different_nesting": true},
-        "MD029": {"style": "ordered"},
-        "MD033": false,
-        "MD040": false,
-    },
+  "rewrap.wrappingColumn": 80,
+  "editor.rulers": [80],
+  "yaml.format.singleQuote": false,
+  "yaml.format.proseWrap": "always",
+  "yaml.format.bracketSpacing": true,
+  "yaml.format.enable": true,
+  "[yaml]": {
+    "editor.defaultFormatter": "redhat.vscode-yaml"
+  },
+  "[markdown]": {
+    "editor.defaultFormatter": "DavidAnson.vscode-markdownlint"
+  },
+  "markdownlint.config": {
+    "MD004": false,
+    "MD013": false,
+    "MD024": { "siblings_only": true },
+    "MD029": { "style": "ordered" },
+    "MD033": false,
+    "MD040": false
+  }
 }

.yamllint.yaml

@@ -0,0 +1,9 @@
+---
+extends: default
+
+rules:
+  comments:
+    min-spaces-from-content: 1
+  braces:
+    min-spaces-inside: 1
+    max-spaces-inside: 1

MAINTAINERS.md

@@ -1,9 +1,10 @@
 # Serverless Workflow Org Maintainers
 
-* [Antonio Mendoza Pérez](https://github.com/antmendoza)
-* [Charles d'Avernas](https://github.com/cdavernas)
-* [Ricardo Zanini](https://github.com/ricardozanini)
-* [Tihomir Surdilovic](https://github.com/tsurdilo)
+- [Antonio Mendoza Pérez](https://github.com/antmendoza)
+- [Charles d'Avernas](https://github.com/cdavernas)
+- [Ricardo Zanini](https://github.com/ricardozanini)
+- [Tihomir Surdilovic](https://github.com/tsurdilo)
 
 # Maintainers Mailing list
-[cncf-serverlessws-maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io)
+
+[cncf-serverlessws-maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io)

code-of-conduct.md

@@ -7,5 +7,6 @@ We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/mai
     If your project isn't prepared to handle reports, remove the project email address and just have
     reporters send to conduct@cncf.io.
 -->
+
 Please contact the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io)
 in order to report violations of the Code of Conduct.

community/README.md

@@ -1,7 +1,7 @@
-# Community  
+# Community
 
 Here you can find information about our:
 
 - [Contributors](contributors.md): People and companies contributing to the
   Serverless workflow specification and ecosystem
-- [Presentations](https://serverlessworkflow.io/): Community presentations about the project (see the 'Resources' section)
+- [Presentations](https://serverlessworkflow.io/): Community presentations about the project (see the 'Resources' section)

community/contributors.md

@@ -1,85 +1,102 @@
 # Community Contributors
 
-This list acknowledges community contributors to the Serverless Workflow 
-project. 
+This list acknowledges community contributors to the Serverless Workflow
+project.
 
-We welcome everyone to join our community and contribute. 
+We welcome everyone to join our community and contribute.
 For more information on how, please reference the ['how to contribute'](../contributing.md) doc.
 
-We try to add every contributor here, but if for some reason we missed 
-adding your name, feel free to add it via pull request to this document or let 
+We try to add every contributor here, but if for some reason we missed
+adding your name, feel free to add it via pull request to this document or let
 us know in chat or team meeting.
 
-* **Independent**
-  * Louis Fourie
-  * Achilleas Tzenetopoulos
-  * Richard Gibson
-  * Lucas Stocksmeier
-
-* **Accenture**
-  * Mona Borham
+- **Independent**
+  - Louis Fourie
+  - Achilleas Tzenetopoulos
+  - Richard Gibson
+  - Lucas Stocksmeier
+- **Accenture**
 
-* **Camunda**
-  * Mauricio Salatino
-  * Falko Menge
+  - Mona Borham
 
-* **Chargebee**
-  * Manickavasagam Sundaram
+- **Camunda**
 
-* **Fujitsu**
-  * Naohiro Tamura
+  - Mauricio Salatino
+  - Falko Menge
 
-* **Google**
-  * Evan Anderson
-  * Rachael Myers
+- **Chargebee**
 
-* **Huawei**
-  * Cathy Hong Zhang
-  * Farhad Sunavala
+  - Manickavasagam Sundaram
 
-* **IBM**
-  * Doug Davis
+- **Fujitsu**
 
-* **Microsoft**
-  * Josh Lane
-  * Chris Gillum
+  - Naohiro Tamura
 
-* **Neuroglia**
-  * Charles d'Avernas
-  * Jean-Baptiste Bianchi
+- **Google**
 
-* **Nokia**
-  * Manuel Stein
-  * Istemi Ekin Akkus
+  - Evan Anderson
+  - Rachael Myers
 
-* **OpenEnterprise**
-  * Maciek Swiderski
+- **Huawei**
 
-* **Oracle**
-  * Varun Madan
+  - Cathy Hong Zhang
+  - Farhad Sunavala
 
-* **Oracle Cloud Infrastructure**
-  * Kay Singh
-  * Jorgen Johnson
+- **IBM**
 
-* **Red Hat**
-  * Ruben Romero Montes
-  * Ricardo Zanini 
-  * Lucas Caparelli
-  * Paul Morie
+  - Doug Davis
 
-* **SecureDocs, Inc**
-  * Stephen Crosby
+- **Microsoft**
 
-* **Serverless**
-  * Brian Neisler
+  - Josh Lane
+  - Chris Gillum
 
-* **Sophos**
-  * Matt Nicholls
+- **Neuroglia**
 
-* **Temporal Technologies**
-  * Antonio Mendoza Pérez
-  * Tihomir Surdilovic
+  - Charles d'Avernas
+  - Jean-Baptiste Bianchi
 
-* **WSO2**
-  * Chathura Ekanayake
+- **Nokia**
+
+  - Manuel Stein
+  - Istemi Ekin Akkus
+
+- **OpenEnterprise**
+
+  - Maciek Swiderski
+
+- **Oracle**
+
+  - Varun Madan
+
+- **Oracle Cloud Infrastructure**
+
+  - Kay Singh
+  - Jorgen Johnson
+
+- **Red Hat**
+
+  - Ruben Romero Montes
+  - Ricardo Zanini
+  - Lucas Caparelli
+  - Paul Morie
+
+- **SecureDocs, Inc**
+
+  - Stephen Crosby
+
+- **Serverless**
+
+  - Brian Neisler
+
+- **Sophos**
+
+  - Matt Nicholls
+
+- **Temporal Technologies**
+
+  - Antonio Mendoza Pérez
+  - Tihomir Surdilovic
+
+- **WSO2**
+  - Chathura Ekanayake

contributing.md

@@ -57,26 +57,26 @@ first comment in the issue to include `Assigned to: @person`
 
 ## Versioning
 
-The versioning strategy for the Serverless Workflow DSL is structured to accommodate different types of changes introduced through pull requests (PRs). 
+The versioning strategy for the Serverless Workflow DSL is structured to accommodate different types of changes introduced through pull requests (PRs).
 
-If a PR is labeled with `change: documentation`, indicating modifications related to improving or clarifying documentation, it does not trigger a version change. 
+If a PR is labeled with `change: documentation`, indicating modifications related to improving or clarifying documentation, it does not trigger a version change.
 
-Conversely, if the PR addresses a fix, labeled as `change: fix`, it results in an increase in the patch version (0.0.x). 
-A fix typically refers to corrections made to resolve bugs or errors in the DSL specification or its implementations, ensuring smoother functionality and reliability. 
+Conversely, if the PR addresses a fix, labeled as `change: fix`, it results in an increase in the patch version (0.0.x).
+A fix typically refers to corrections made to resolve bugs or errors in the DSL specification or its implementations, ensuring smoother functionality and reliability.
 
-Similarly, when a PR introduces a new feature, labeled as `change: feature`, it prompts an increase in the minor version (0.x.0). 
-A feature denotes the addition of significant capabilities, enhancements, or functionalities that extend the DSL's capabilities or improve its usability. 
+Similarly, when a PR introduces a new feature, labeled as `change: feature`, it prompts an increase in the minor version (0.x.0).
+A feature denotes the addition of significant capabilities, enhancements, or functionalities that extend the DSL's capabilities or improve its usability.
 
-Lastly, if the PR is marked as `change: breaking`, indicating alterations that are incompatible with previous versions, it leads to an increase in the major version (x.0.0). A breaking change signifies modifications that necessitate adjustments in existing workflows or implementations, potentially impacting backward compatibility. 
+Lastly, if the PR is marked as `change: breaking`, indicating alterations that are incompatible with previous versions, it leads to an increase in the major version (x.0.0). A breaking change signifies modifications that necessitate adjustments in existing workflows or implementations, potentially impacting backward compatibility.
 
 This versioning strategy ensures clarity and transparency in tracking changes and communicating their impact on users and implementations.
 
-| Label | Version Change |  Description  |
-|:-- |:---:|:---|
-| `change: documentation` | - | Modifications related to documentation improvements or clarifications. |
-| `change: fix` | `0.0.x` | Corrections made to resolve bugs or errors in the DSL specification or its implementations. |
-| `change: feature` | `0.x.0` | Addition of significant capabilities, enhancements, or functionalities that extend the DSL's capabilities or improve its usability. |
-| `change: breaking` | `x.0.0` | Alterations that are incompatible with previous versions, necessitating adjustments in existing workflows or implementations. |
+| Label                   | Version Change | Description                                                                                                                         |
+| :---------------------- | :------------: | :---------------------------------------------------------------------------------------------------------------------------------- |
+| `change: documentation` |       -        | Modifications related to documentation improvements or clarifications.                                                              |
+| `change: fix`           |    `0.0.x`     | Corrections made to resolve bugs or errors in the DSL specification or its implementations.                                         |
+| `change: feature`       |    `0.x.0`     | Addition of significant capabilities, enhancements, or functionalities that extend the DSL's capabilities or improve its usability. |
+| `change: breaking`      |    `x.0.0`     | Alterations that are incompatible with previous versions, necessitating adjustments in existing workflows or implementations.       |
 
 In addition to versioning changes denoted by labels in pull requests, pre-release versions will be suffixed with either `alphaX`, `betaX`, or `rcX` where `X` represents the pre-release version number (ex: `1.0.0-alpha1`). These pre-release versions are designated to indicate different stages of development and testing before the final release.
 
@@ -103,8 +103,7 @@ Documents in this repository will adhere to the following rules:
 Markdown files should be appropriately formatted before a pull request is sent out.
 In this repository, we follow the
 [markdownlint rules](https://github.com/DavidAnson/markdownlint#rules--aliases)
-with some customizations. See [markdownlint](.markdownlint.yaml) or
-[settings](.vscode/settings.json) for details.
+with some customizations. See [markdownlint](.markdownlint.yaml) for details.
 
 We highly encourage using line breaks in markdown files at `80` characters
 wide. Some tools can do it for you effectively. Please submit the proposal
@@ -115,18 +114,59 @@ If you are using Visual Studio Code,
 you can also use the `fixAll` command of the
 [vscode markdownlint extension](https://github.com/DavidAnson/vscode-markdownlint).
 
-To otherwise check for style violations, use:
+To otherwise check for style violations, use one of the following commands:
 
 ```bash
-# Ruby and gem are required for mdl
-gem install mdl
-mdl -c .mdlrc .
+npm install -g markdownlint-cli
+markdownlint **/*.md
+```
+
+```bash
+brew install markdownlint-cli
+markdownlint **/*.md
 ```
 
 To fix style violations, follow the
 [instruction](https://github.com/DavidAnson/markdownlint#optionsresultversion)
 with the Node version of markdownlint.
 
+### YAML style
+
+YAML files should be appropriately formatted before a pull request is sent out.
+In this repository, we follow the
+[yamllint rules](https://github.com/adrienverge/yamllint/blob/master/docs/rules.rst).
+See [yamllint](.yamllint.yaml) for details.
+
+We highly encourage using line breaks in markdown files at `80` characters
+wide. Some tools can do it for you effectively. Please submit the proposal
+to include your editor settings required to enable this behavior so the
+out-of-the-box settings for this repository will be consistent.
+
+If you are using Visual Studio Code,
+you can also use the formatter of the
+[vscode YAML Language Support extension](https://github.com/redhat-developer/vscode-yaml).
+
+To install yamllint follow the [instructions outlined here](https://github.com/adrienverge/yamllint/blob/master/docs/quickstart.rst#installing-yamllint).
+
+### Gherkin style
+
+Gherkin files should be appropriately formatted before a pull request is sent out.
+In this repository, we follow the
+[gherkin-lint rules](https://github.com/gherkin-lint/gherkin-lint?tab=readme-ov-file#available-rules).
+See [gherkin-lint](.gherkin-lintrc) for details.
+
+We highly encourage using line breaks in markdown files at `80` characters
+wide. Some tools can do it for you effectively. Please submit the proposal
+to include your editor settings required to enable this behavior so the
+out-of-the-box settings for this repository will be consistent.
+
+To install gherkin-lint run:
+
+```bash
+npm install -g gherkin-lint
+gherkin-lint **/*.feature
+```
+
 ### Typos
 
 In addition, please make sure to clean up typos before you submit the change.

ctk/README.md

@@ -4,30 +4,30 @@
 
 - [Introduction](#introduction)
 - [Using the CTK](#using-the-ctk)
-  + [Conformance testing](#conformance-testing)
-  + [Behavior Driven Development](#behavior-driven-development-bdd)
+  - [Conformance testing](#conformance-testing)
+  - [Behavior Driven Development](#behavior-driven-development-bdd)
 - [Writing Features and Scenarios](#writing-features-and-scenarios)
-    + [Feature File Structure](#feature-file-structure)
-    + [Steps](#steps)
-      - [Arrange](#arrange)
-        + [Define workflow](#define-workflow)
-        + [Set workflow input](#set-workflow-input)
-      - [Act](#act)
-        + [Execute Workflow](#execute-workflow)
-      - [Assert](#assert)
-        - [Workflow has been cancelled](#workflow-has-been-cancelled)
-        - [Workflow ran to completion](#workflow-ran-to-completion)
-        - [Workflow has faulted](#workflow-has-faulted)
-        - [Workflow output should have properties](#workflow-output-should-have-properties)
-        - [Workflow output should have property with value](#workflow-output-should-have-property-with-value)
-        - [Workflow output should have property with item count](#workflow-output-should-have-property-with-item-count)
-        - [Task ran first](#task-ran-first)
-        - [Task ran last](#task-ran-last)
-        - [Task ran before](#task-ran-before)
-        - [Task ran after](#task-ran-after)
-        - [Task has been cancelled](#task-has-been-cancelled)
-        - [Task ran to completion](#task-ran-to-completion)
-        - [Task has faulted](#task-has-faulted)
+  - [Feature File Structure](#feature-file-structure)
+  - [Steps](#steps)
+    - [Arrange](#arrange)
+      - [Define workflow](#define-workflow)
+      - [Set workflow input](#set-workflow-input)
+    - [Act](#act)
+      - [Execute Workflow](#execute-workflow)
+    - [Assert](#assert)
+      - [Workflow has been cancelled](#workflow-has-been-cancelled)
+      - [Workflow ran to completion](#workflow-ran-to-completion)
+      - [Workflow has faulted](#workflow-has-faulted)
+      - [Workflow output should have properties](#workflow-output-should-have-properties)
+      - [Workflow output should have property with value](#workflow-output-should-have-property-with-value)
+      - [Workflow output should have property with item count](#workflow-output-should-have-property-with-item-count)
+      - [Task ran first](#task-ran-first)
+      - [Task ran last](#task-ran-last)
+      - [Task ran before](#task-ran-before)
+      - [Task ran after](#task-ran-after)
+      - [Task has been cancelled](#task-has-been-cancelled)
+      - [Task ran to completion](#task-ran-to-completion)
+      - [Task has faulted](#task-has-faulted)
 
 ## Introduction
 
@@ -44,15 +44,18 @@ The Serverless Workflow CTK serves two primary purposes: conformance testing and
 Conformance testing is the process of verifying that an implementation adheres to a given specification. By running the CTK, developers can ensure that their implementations of the Serverless Workflow DSL behave as expected and meet the defined standards. This is crucial for maintaining interoperability and consistency across different implementations of the Serverless Workflow specification.
 
 1. **Clone the Repository**: Start by cloning the Serverless Workflow CTK repository to your local machine.
-   
+
 ```sh
 git clone https://github.com/serverlessworkflow/specification.git
 ```
 
+<!-- markdownlint-disable-next-line ol-prefix -->
 2. **Install Dependencies**: Ensure that you have all the necessary dependencies installed. This typically involves setting up a testing framework that can execute Gherkin tests.
 
-3. **Run the Tests**: Execute the Gherkin features using your preferred test runner. 
+<!-- markdownlint-disable-next-line ol-prefix -->
+3. **Run the Tests**: Execute the Gherkin features using your preferred test runner.
 
+<!-- markdownlint-disable-next-line ol-prefix -->
 4. **Review Results**: After running the tests, review the results to ensure that your implementation passes all the scenarios. Any failures indicate deviations from the Serverless Workflow specification.
 
 ### Behavior-Driven Development (BDD)
@@ -98,17 +101,17 @@ Feature: <Feature Name>
 
 ### Steps
 
-For clarity, we've categorized the Gherkin steps used in the Serverless Workflow CTK into three main groups: Arrange, Act, and Assert. 
+For clarity, we've categorized the Gherkin steps used in the Serverless Workflow CTK into three main groups: Arrange, Act, and Assert.
 
-These divisions help clarify the purpose of each step and streamline scenario comprehension. 
+These divisions help clarify the purpose of each step and streamline scenario comprehension.
 
 The Arrange section sets up the initial state or context, the Act section describes the action, and the Assert section verifies the outcome. This structure enhances readability, aiding stakeholders in understanding the scenario flow and step intent.
 
 #### Arrange
 
-Sets up the initial conditions for the test scenario. 
+Sets up the initial conditions for the test scenario.
 
-It includes steps to define the workflow, set the input data for the workflow, and prepare any necessary resources or configurations required for executing the workflow. 
+It includes steps to define the workflow, set the input data for the workflow, and prepare any necessary resources or configurations required for executing the workflow.
 
 The arrange section of the test ensures that the environment is properly configured before the workflow execution begins.
 
@@ -150,9 +153,9 @@ When the workflow is executed
 
 #### Assert
 
-Contains assertions that verify the outcome of the workflow execution. 
+Contains assertions that verify the outcome of the workflow execution.
 
-It includes steps to check various conditions such as whether the workflow was canceled, completed successfully, or encountered any faults or errors during execution. 
+It includes steps to check various conditions such as whether the workflow was canceled, completed successfully, or encountered any faults or errors during execution.
 
 The assert section ensures that the workflow behaves as expected and meets the specified criteria for correctness and reliability.
 
@@ -223,7 +226,6 @@ And the workflow output should have a '<PROPERTY_PATH>' property with value:
 And the workflow output should have a '<PROPERTY_PATH>' property containing <ITEMS_COUNT> items
 ```
 
-
 ##### Task ran first
 
 Asserts that a specific task within the workflow executed first during workflow execution. It ensures the correct sequence of task execution based on the provided workflow definition.
@@ -296,4 +298,4 @@ And <TASK_NAME> should fault with error:
 """yaml
 <EXPECTED_ERROR>
 """
-```
+```

examples/accumulate-room-readings.yaml

@@ -1,3 +1,4 @@
+---
 document:
   dsl: 1.0.0-alpha1
   namespace: examples
@@ -43,4 +44,4 @@ do:
       operationId: produceReport
 timeout:
   after:
-    hours: 1
+    hours: 1

examples/bearer-auth-uri-format.yaml

@@ -1,3 +1,4 @@
+---
 document:
   dsl: 1.0.0-alpha1
   namespace: examples

examples/bearer-auth.yaml

@@ -1,3 +1,4 @@
+---
 document:
   dsl: 1.0.0-alpha1
   namespace: examples

examples/switch-then-string.yaml

@@ -1,8 +1,9 @@
+---
 document:
-  dsl: '1.0.0-alpha1'
+  dsl: "1.0.0-alpha1"
   namespace: test
   name: sample-workflow
-  version: '0.1.0'
+  version: "0.1.0"
 do:
   processOrder:
     switch:
@@ -45,4 +46,4 @@ do:
             log: warn
         notifyAdmin:
           set:
-            message: something's wrong
+            message: something's wrong

owners.md

@@ -1,9 +1,11 @@
 # See the GOVERNANCE.md document for the definition of the roles and responsibilities
+
 maintainers:
-  - antmendoza
-  - cdavernas
-  - ricardozanini
-  - tsurdilo
-reviewers:
-  - JBBianchi
-  - manick02
+
+- antmendoza
+- cdavernas
+- ricardozanini
+- tsurdilo
+  reviewers:
+- JBBianchi
+- manick02