docs: split contribution guide into individual markdown files

Guides/committing-changes.md

@@ -0,0 +1,48 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Committing Your Changes
+
+When committing changes to your development branch you would be required to submit a commit message to describe the change. Depending on the mechanism that you are using to commit your changes, you may have access to a commit message as well as an extended description of your changes, but it is expected that you should complete at least the commit message.
+
+Tazama aims to comply with the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification for adding human and machine-readable meaning to commit messages (subject to the commit types recommended below).
+
+A commit message must be a short description of the change, prefaced with a commit type:
+
+```
+type: short description
+```
+
+The commit message should also include a scope:
+
+```
+type(scope): short description
+```
+
+If the change is a breaking change, the type should be following by an exclamation:
+
+```
+type!: short description
+```
+
+Recommended commit types for Tazama are based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type), summarized for ease of reference:
+
+ - **build**: Changes that affect the build system or external dependencies
+ - **ci**: Changes to our CI configuration files and scripts
+ - **docs**: Documentation only changes
+ - **feat**: A new feature
+ - **fix**: A bug fix
+ - **perf**: A code change that improves performance
+ - **refactor**: A code change that neither fixes a bug nor adds a feature
+ - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
+ - **test**: Adding missing tests or correcting existing tests
+
+Note: **chore** is not in the recommended list of commit types
+
+Scope keywords are tailored to Tazama's specific requirements. Tazama's source code is spread across a number of repositories and as such even small changes often affect a number of separate repositories simultaneously. This complicates source control a bit, since a number of changes across different repositories may all be related to a single requirement. For the sake of proper governance, the requirement would be logged as an issue in each of the affected repositories to outline the acceptance criteria for the change in *that* repository and also to provide an anchor for the eventual Pull Request to implement the change in that repository. From this perspective, the scope is generally either confined to a single repository that represents a single Tazama processor, or a cluster of repositories representing a number of Tazama processors.
+
+ - If your change is limited to a single repository, the scope should be the name of the repository, e.g. `typology-processor` or `rule-executer`.
+ - If your change impacts multiple repositories, the scope should be `multi-repo`.
+
+## Further reading
+
+- Read the [CONTRIBUTING guide](https://github.com/tazama-lf/.github/blob/main/CONTRIBUTING.md) for more details on the contribution process.

Guides/definition-of-done.md

@@ -0,0 +1,50 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+<a id="top"></a>
+
+# Tazama definition of done
+
+The tasks below must be completed by the code contributor before the Pull Request(PR) is submitted:
+
+**Code Complete** - Source code changes are complete for all items in the acceptance criteria in the issue supporting the story. In Tazama, code is distributed amongst a number of different repositories for specific purposes. Code changes in a single repository should be linked to an issue in that repository. Similar changes that affect a number of different repositories, should be documented as an issue in each of those repositories separately.
+
+**Coding Practices** - source code should conform to [Tazama coding practices](../guides/dev-coding-practices.md) 
+
+**Code Refactoring** - Source code has been refactored to make it comprehensive, maintainable and amenable to change (*unless agreed otherwise as part of refactoring existing legacy code).
+
+**Code Check-in** - Source code is checked in to source code control repository and the PR process is followed.
+
+**Code & Peer reviews** (pull requests) - Code reviews and Peer reviews have been carried out and all improvements implemented and tests completed. Contributor to follow-up and ensure code gets merged in a reasonable time.
+
+**Code Documentation** - Source code has been commented. Complex or compound statements should be explained with a comment, either a comment block (e.g. `/* comment block here */` in TypeScript) or an in-line comment (e.g. `// in-line comment here` in TypeScript). Every function in Tazama must be documented with a preceding [JSDocs docstring](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html).
+
+**Developer Documentation** - The `readme.md` file in every GitHub code repository must contain documentation to explain how the code works, in markdown and in diagrams, either in Mermaid or editable `.svg` or `.png` images. See [guide for draw.io](https://github.com/tazama-lf/docs/blob/main/Guides/drawio-guide.md)
+
+**Licensing comment** Add the following string as a comment ("SPDX-License-Identifier: Apache-2.0") at the top of every file in the organization in GitHub that is capable of including a comment i.e. extensions="ts" "js" "env" "template" "eslintignore" "yaml" "properties" "npmrc" "editorconfig" "dockerignore" "gitignore" "prettierignore" "md" "helmignore" "Makefile" "sh" "npmignore" "plantuml" "yml".
+
+**Unit testing** - Unit test cases have been created in Jest (https://jestjs.io/), executed and are working successfully. Follow [coverage guidelines](https://github.com/tazama-lf/docs/blob/main/Technical/unit-test-coverage.md). 
+
+**Processor performance benchmarking** Ensure that the Newman benchmark results have been presented on the PR as a comment. If you notice any spikes in the benchmark, please report the spike or reevaluate the implemented code.
+
+**Automated Builds** - All code is included in automated builds and any updates to the build scripts have been completed and tested and checked in. Jenkins / CircleCI - Poly vs Mono repo
+
+**GitHub CI/CD** - Ensure that all GitHub workflows have completed successfully during PR checks.
+
+**Logging** - Integration with the Tazama Logger Service. Appropriate logging and log levels implemented 
+- [Logging framework](https://github.com/tazama-lf/docs/blob/5965e608eaf560b650642de734d98b0f2e7168a0/Technical/Logging/Logging-Framework-Architecture.md) - Architecture of logging services
+- [Code Sample](../guides/dev-logger-service.md) - Logger service code template for processors
+
+**All acceptance criteria are met and Testing complete**
+
+ - **Automated testing** - All existing automated tests have been run successfully
+
+ - **Regression testing** – Regression testing has been carried out successfully
+
+### Guide for maintainers  
+
+**Architecture** - All new code conforms to the agreed architecture (*unless agreed otherwise as part of refactoring existing legacy code). 
+<div style="text-align: right"><a href="#top">Top</a></div>
+
+## Further reading
+
+- Read the [CONTRIBUTING guide](https://github.com/tazama-lf/.github/blob/main/CONTRIBUTING.md) for more details on the contribution process.

Guides/dev-coding-practices.md

@@ -0,0 +1,94 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+<a id="top"></a>
+
+# Tazama coding practices <!-- omit from toc -->
+
+## Table of Contents <!-- omit from toc -->
+
+- [1. Linting \& Linting rules](#1-linting--linting-rules)
+  - [Configuration Overview](#configuration-overview)
+  - [Rules Summary](#rules-summary)
+    - [Standard and Plugin Rules](#standard-and-plugin-rules)
+    - [TypeScript Specific Rules](#typescript-specific-rules)
+    - [Stylistic Rules (Custom Plugin)](#stylistic-rules-custom-plugin)
+    - [ESLint Comments Plugin](#eslint-comments-plugin)
+    - [Ignored Files and Directories](#ignored-files-and-directories)
+- [2. Gather asynchronous requests](#2-gather-asynchronous-requests)
+- [3. Further reading](#3-further-reading)
+
+## 1. Linting & Linting rules  
+
+Tazama uses [ESLint](https://eslint.org/) to enforce consistency and specific rules in our use of TypeScript. We implemented the ESLint "[flat config](https://eslint.org/blog/2022/08/new-config-system-part-2/)" in release 2.0.0 of Tazama.
+
+This document details the ESLint configuration for TypeScript files as specified in the `eslint.config.mjs` file. The configuration integrates multiple plugins to enforce style and quality standards.
+
+### Configuration Overview 
+
+- **Files Targeted**: 
+  - Applies to all `.ts` files across the project.
+
+- **Plugins Used**: 
+  - Integrates plugins from `eslint-config-love`, `eslint-plugin-eslint-comments`, `@typescript-eslint/eslint-plugin`, and `@stylistic/eslint-plugin`.
+
+- **Parser**: 
+  - Uses `@typescript-eslint/parser` for parsing TypeScript files.
+
+- **ECMA Version**: 
+  - Configured for ECMAScript 2022 to support modern JavaScript features.
+
+- **Source Type**: 
+  - Files are treated as ECMAScript modules.
+
+### Rules Summary  
+
+#### Standard and Plugin Rules  
+- Inherits rules from `eslint-config-love`.
+- Incorporates recommended rules from `eslint-plugin-eslint-comments`.
+
+#### TypeScript Specific Rules 
+- `@typescript-eslint/restrict-template-expressions`: Errors on unsafe usage in template literals.
+- `@typescript-eslint/no-non-null-assertion`: Disabled.
+- `@typescript-eslint/strict-boolean-expressions`: Disabled to allow any type in conditions.
+- `@typescript-eslint/no-explicit-any`: Errors when the `any` type is used, promoting type safety.
+- `@typescript-eslint/no-floating-promises`: Allows floating promises without handling.
+- `@typescript-eslint/no-var-requires`: Permits using `require` statements in TypeScript.
+- `@typescript-eslint/no-use-before-define`: Disabled to allow hoisting.
+- `@typescript-eslint/prefer-optional-chain`: Does not enforce using optional chaining.
+
+#### Stylistic Rules (Custom Plugin) 
+- `@stylistic/indent`: Enforces 2 spaces for indentation.
+- `@stylistic/semi`: Requires semicolons at the end of statements, warning level.
+- `@stylistic/quotes`: Enforces single quotes for strings.
+- `@stylistic/quote-props`: Requires quotes around object properties when necessary.
+- `@stylistic/arrow-parens`: Requires parentheses around arrow function arguments.
+
+#### ESLint Comments Plugin 
+- `eslint-comments/require-description`: Warns if ESLint directive comments lack a description.
+- `eslint-comments/disable-enable-pair`: Warns to ensure proper use of `eslint-disable` and `eslint-enable` pairs. Sometimes, linting and coding practices collide and a linting override is required to suppress linting alerts over a specific segment of code. While it is possible to override linting for an entire code module, this is not the Tazama way and instead a linting override is expected to only be applied to the specific problematic segment of code via the use of these comment tags above and below the code segment.
+
+#### Ignored Files and Directories 
+- **Ignored Locations**: 
+  - `**/build/**` or `**/lib/**` // tsc output directory (project)
+  - `**/node_modules/**`
+  - `**/docs/**`
+  - `**/__tests__/**`
+  - `**/coverage/**` // jest coverage
+  - `**/jest.config.ts` // jest main config
+  - `**/jest.testEnv.ts` // jest env config
+
+This setup ensures a robust framework for maintaining high code quality and consistency in TypeScript projects, leveraging ESLint's core capabilities and additional style rules from external plugins.
+
+<div style="text-align: right"><a href="#top">Top</a></div>
+
+## 2. Gather asynchronous requests 
+
+When you have multiple asynchronous requests to make, Tazama prefers the requests to operate in parallel using [`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all).
+
+<div style="text-align: right"><a href="#top">Top</a></div>
+
+## 3. Further reading
+
+- Read the [CONTRIBUTING guide](https://github.com/tazama-lf/.github/blob/main/CONTRIBUTING.md) for more details on the contribution process.
+
+<div style="text-align: right"><a href="#top">Top</a></div>

Guides/dev-logger-service.md

@@ -0,0 +1,89 @@
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+<a id="top"></a>
+
+# Logger Service Template
+
+A simple template for the minimum to integrate a logger service
+#### index.ts
+```ts
+import { LoggerService } from '@tazama-lf/frms-coe-lib';
+import type { ProcessorConfig } from '@tazama-lf/frms-coe-lib/lib/config/processor.config';
+import { validateProcessorConfig } from '@tazama-lf/frms-coe-lib/lib/config';
+
+// this line will validate that you've got the mandatory processor ENV variables set, and populate the response with the values:
+let configuration: ProcessorConfig = validateProcessorConfig();
+
+export const loggerService: LoggerService = new LoggerService(configuration);
+
+// By default, the logger will log to Console if NODE_ENV=dev or NODE_ENV=test
+// This will log to the Sidecar which will be deployed with your processor based on the deployment file.
+const msgId = crypto.randomUUID(); 
+const service = 'logger-example';
+
+// trace, debug, log (info), warn, error, fatal
+loggerService.log('sample log', service, msgId);  
+```
+
+### .env
+```
+NODE_ENV=dev
+FUNCTION_NAME=relay-service
+# MAX_CPU requirement as part of standard env validation for processors in tazama
+MAX_CPU=1 
+
+# SIDECAR_HOST requirement for sidecar companion processor (kubernetes)
+# SIDECAR_HOST=0.0.0.0:5000 
+```
+
+### Dockerfile
+```Dockerfile
+ARG BUILD_IMAGE=node:20-bullseye
+ARG RUN_IMAGE=gcr.io/distroless/nodejs20-debian11:nonroot
+
+# Transpile to JS
+FROM ${BUILD_IMAGE} AS builder
+LABEL stage=build
+
+WORKDIR /home/app
+COPY ./src ./src
+COPY ./package*.json ./
+COPY ./tsconfig.json ./
+COPY .npmrc ./
+ARG GH_TOKEN
+
+RUN npm ci --ignore-scripts
+RUN npm run build
+
+# Clean up dev
+FROM ${BUILD_IMAGE} AS dep-resolver
+LABEL stage=pre-prod
+
+COPY package*.json ./
+COPY .npmrc ./
+ARG GH_TOKEN
+RUN npm ci --omit=dev --ignore-scripts
+
+# Runtime
+FROM ${RUN_IMAGE} AS run-env
+USER nonroot
+
+WORKDIR /home/app
+COPY --from=dep-resolver /node_modules ./node_modules
+COPY --from=builder /home/app/build ./build
+COPY package.json ./
+COPY service.yaml ./
+COPY deployment.yaml ./
+
+ENV FUNCTION_NAME=relay-service
+ENV NODE_ENV=production
+ENV SIDECAR_HOST=0.0.0.0:5000
+
+CMD ["build/index.js"]
+```
+<div style="text-align: right"><a href="#top">Top</a></div>
+
+## 3. Further reading
+
+- Read the [CONTRIBUTING guide](https://github.com/tazama-lf/.github/blob/main/CONTRIBUTING.md) for more details on the contribution process.
+<div style="text-align: right"><a href="#top">Top</a></div>