Merge pull request 'docs: README for component/default/sonar-test-nest4' (#14) from documentor-agent-component-default-sonar-test-nest4-doc-d5fbf71aa463 into main

catalog/component/default/sonar-test-nest4/README.md

@@ -1,74 +1,76 @@
 ---
-title: "Sonar Test Nest4"
+title: "sonar-test-nest4"
 generated_by: documentor-agent
-generated_at: "2026-05-14T12:03:00+00:00"
+generated_at: "2026-05-15T15:19:14+00:00"
 human_edited: false
 source_entity: "Component/default/sonar-test-nest4"
 source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4"
 ---
 
-# Sonar Test Nest4
-
-> A stateless microservice built with TypeScript and NestJS, providing API endpoints for item management and Prometheus-based observability.
-
 ## Overview
 
-Sonar Test Nest4 is a stateless microservice scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. It is designed to manage items through a RESTful API and includes built-in observability features such as health checks and Prometheus metrics.
+`sonar-test-nest4` is a stateless microservice built using the `typescript-nestjs` runtime. It was scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. The service provides a RESTful API for managing items, including endpoints for CRUD operations. It is designed to be lightweight, scalable, and observable, with integrated OpenTelemetry instrumentation and Prometheus metrics.
 
-The service is implemented using the `typescript-nestjs` runtime and follows a structured branch model (`dev`, `staging`, `prod`, and `main`) to ensure smooth CI/CD workflows. It is deployed to Azure Kubernetes Service (AKS) via Humanitec, with container images stored in Azure Container Registry (ACR).
-
-This service plays a key role in the broader system by providing item management capabilities and adhering to platform standards for observability, deployment, and runtime configuration.
+This service plays a key role in the demo-apps domain, serving as a foundational component for item management. It is deployed on Azure Kubernetes Service (AKS) via Humanitec, with container images stored in Azure Container Registry (ACR). The CI/CD pipeline is managed through Gitea Actions, ensuring automated builds, tests, and deployments across environments (`dev`, `staging`, `prod`).
 
 ## Repository
 
-| Field | Value |
-|---|---|
-| Source Repo | [Sonar Test Nest4 Repository](https://gitea.kyndemo.live/validate/sonar-test-nest4) |
-| Branch | dev |
-| ArgoCD App | — |
-| Namespace | dev |
+| Field          | Value                                                                                                           |
+|----------------|-----------------------------------------------------------------------------------------------------------------|
+| Source Repo    | [validate/sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4)                               |
+| Branch         | `dev` → `staging` → `prod` (→ `main` SoR)                                                                      |
+| ArgoCD App     | —                                                                                                              |
+| Namespace      | `dev`                                                                                                          |
 
 ## Architecture
 
-Sonar Test Nest4 is built using the `typescript-nestjs` runtime and deployed as a stateless service. Key architectural components include:
+`sonar-test-nest4` follows a stateless architecture, leveraging the `typescript-nestjs` framework. Key components include:
 
-- **Runtime**: TypeScript with NestJS framework.
-- **Container Port**: `3000`.
-- **Health Check Endpoint**: `/health`.
-- **Metrics Endpoint**: `/metrics` (Prometheus format).
-- **Image Repository**: Azure Container Registry (`bstagecjotdevacr`).
+- **Runtime**: `typescript-nestjs`
+- **Container Port**: `3000`
+- **Health Check**: `/health`
+- **Metrics Endpoint**: `/metrics` (Prometheus format)
+- **Image Registry**: Azure Container Registry (`bstagecjotdevacr`)
 
-The CI/CD pipeline is managed through Gitea Actions workflows:
-- `build-push.yml`: Builds and tests the application, then pushes the container image to ACR.
-- `deploy-humanitec.yml`: Deploys the service to AKS via Humanitec using Score files.
+The deployment flow is managed through Gitea Actions CI/CD workflows:
+1. **build-push.yml**: Builds and tests the application, then pushes the container image to ACR.
+2. **deploy-humanitec.yml**: Deploys the service to AKS using Humanitec's API and Score configuration.
 
-Promotions between environments (`dev`, `staging`, `prod`) are triggered through Backstage's CI/CD tab, ensuring controlled and gated deployments.
+Promotions between environments (`dev`, `staging`, `prod`) are triggered via PRs, with CI gates and approval requirements ensuring quality control.
 
 ## Configuration
 
-| Config Key | Value |
-|---|---|
-| runtime | typescript-nestjs |
-| health_path | /health |
-| container_port | 3000 |
+| Config Key       | Value              |
+|------------------|--------------------|
+| `runtime`        | `typescript-nestjs` |
+| `health_path`    | `/health`          |
+| `container_port` | `3000`             |
 
 ## Operations
 
-The service follows a structured branch model for development and deployment:
+### Deployment Steps
+1. Push changes to the `dev` branch for automatic deployment to the development environment.
+2. Open a PR for promotion to `staging` or `prod`. Ensure CI tests pass and obtain one approval before merging.
+3. Use the Backstage CI/CD tab to trigger promotions between environments.
 
-- **dev**: Active development branch; commits trigger automatic builds and deployments to the dev environment.
-- **staging**: Pre-production environment; changes are promoted from `dev` via PR with CI gate and approval.
-- **prod**: Production environment; changes are promoted from `staging` via PR with CI gate and approval.
-- **main**: System of record; receives merges from `prod` after releases.
-
-Deployment workflows are runtime-agnostic and rely on `.platform/config.yaml` for configuration.
+### Runbook Notes
+- Monitor `/health` for service health status.
+- Use `/metrics` for Prometheus-based observability.
+- Refer to `.platform/config.yaml` for runtime-specific configurations.
 
 ## Observability
 
-- [Grafana Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4): OpenTelemetry-based application observability.
-- Prometheus metrics exposed at `/metrics`.
-- Health check endpoint at `/health`.
+- **Grafana Dashboard**: [Opentelemetry Application Observability](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4)
+- **Prometheus Metrics**: Enabled (`/metrics` endpoint).
+- **Chaos Mesh**: Enabled for resilience testing.
+- **K6 Load Testing**: Configured via `k6-test-sonar-test-nest4` in the `dev` namespace.
 
 ## Dependencies
 
-_No declared dependencies._
+- `api:default/sonar-test-nest4-api`
+
+## Links
+
+- [Humanitec Console](https://console.humanitec.dev/orgs/skillful-wild-chicken-2617/projects/domain-demo-apps)
+- [Grafana Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4)
+- [Source Repository](https://gitea.kyndemo.live/validate/sonar-test-nest4)