Sven laptop
635a130f0b
### Summary of Changes
1. Documentation Consolidation:
• Relocated the docs/ folder and all repository .md files (README.md, DEPLOYMENT.md, DOCKER_README.md,
DOMAINS_README.md, GETTING_STARTED.md, CI_CD_PORTAINER_GUIDE.md, ADMIN_DEPLOYMENT_SUMMARY.md,
SECURITY_PRIVATE_FILES.md, handoff.md, azure-project-plan.md, plus service-specific READMEs) into .
• Updated document links in README.md.
2. AI Agent Project Map:
• Created PROJECT_MAP.md in the project root containing complete architecture diagrams, service specs, ports, DB
schemas, environment variables, and developer workflows.
• Added PROJECT_MAP.md to .gitignore.
3. Monitoring UI & Infrastructure Integration:
• Added monitoring_ui service to docker-compose.yml (port 5175).
• Configured Gitea workflow docker-build.yml for monitoring_ui builds.
• Added CORS middleware headers in index.js.
• Added nginx.conf copy step in Dockerfile.
──────
### Recommended Commit Message
docs: consolidate project documentation into monitoring_ui and add agent project map
- Move all markdown documentation files and docs/ folder into monitoring_ui/docs/
- Update documentation hub index (monitoring_ui/docs/README.md) with relative paths
- Generate comprehensive AI agent reference map (PROJECT_MAP.md) in repository root
- Add PROJECT_MAP.md and monitoring_ui build output/env overrides to .gitignore
- Integrate monitoring_ui service into docker-compose.yml and Gitea CI workflow
- Configure CORS handling in employee_api for monitoring dashboard access
──────
### Alternative Short Commit Message
refactor(docs): move docs to monitoring_ui and create AI agent PROJECT_MAP.md
6.1 KiB
Important: This skill provides guidance and recommended instructions to assist the AI system. Outputs are not guaranteed to be complete, correct, secure, or applicable to every scenario. Results should be reviewed and validated by a human before being applied. The AI model may choose not to follow all instructions exactly, and additional verification may be required.
Component-to-Azure mapping and existing infrastructure detection. Part of the deployability check.
Step 1: Component Mapping Feasibility
Determine if each detected component maps to a known Azure service.
| Component Type | Mappable Azure Services |
|---|---|
| SPA / Static Site | Static Web Apps, Blob + CDN |
| Existing Azure Functions project | Azure Functions |
| SSR Web App | Container Apps, App Service |
| REST / GraphQL API | Container Apps, App Service, Functions |
| Background Worker | Container Apps, Functions |
| Scheduled Task | Functions (Timer Trigger) |
| Event Processor | Functions, Container Apps |
| CLI Tool | Not directly deployable — flag |
| Outcome | Verdict |
|---|---|
| All components map to Azure services | ✅ PASS |
| Some components need clarification | ⚠️ WARN |
| Unknown component type, can't map | ⚠️ WARN — ask user for context |
| Component is fundamentally incompatible | ❌ FAIL |
Preserve Existing Compute Models
The table above describes what can host newly designed components. It does not permit replatforming an existing component whose framework already selects a compute model.
host.jsonplus an Azure Functions SDK or worker signal identifies an Azure Functions project. Map it to Azure Functions even when all of its triggers are HTTP triggers.- Keep separate service roots as separate components. A SPA root and a Functions root produce a frontend component and a backend component.
- Static Web Apps may host the frontend, but an existing Functions root must not become an SWA-managed API.
Do not move or copy its source under an SWA API directory and do not change its runtime or authentication
provider to
azureStaticWebApps. - A detached Static Web App plus Function App with explicit CORS is the default. Linking the separately
deployed Function App as an SWA backend requires explicit user approval and must be recorded in
context.json.overrides[].
Step 2: Existing Infrastructure Check
Check if the repo already has Azure infrastructure or deployment config.
| Found | Implication |
|---|---|
azure.yaml |
AZD project — may only need update |
infra/*.bicep |
Bicep IaC exists |
infra/*.tf or *.tf |
Terraform IaC exists — classify provider (see below) |
Dockerfile |
Containerization ready |
.github/workflows/ |
CI/CD configured |
azure-pipelines.yml |
Azure DevOps CI/CD |
docker-compose.yml |
Multi-container setup — parse for service dependencies |
| None of the above | Greenfield — full prep needed |
Record what exists; this feeds into recipe selection during azure-prepare.
Terraform Provider Classification
When .tf files are detected, read versions.tf, provider.tf, or main.tf to identify required_providers. Classify and write to context.json.detectedInfraProvider.terraform:
required_providers contains |
Classification | Scaffold behavior |
|---|---|---|
hashicorp/azurerm only |
"azure" |
Halt — existing Azure IaC |
hashicorp/google or hashicorp/google-beta (no azurerm) |
"gcp" |
Generate Azure TF alongside |
hashicorp/aws (no azurerm) |
"aws" |
Generate Azure TF alongside |
Multiple cloud providers including azurerm |
"multi" |
Halt — Azure IaC already present |
Multiple cloud providers without azurerm |
"multi" |
Generate Azure TF alongside |
| No provider block found or only non-cloud providers | "unknown" |
Halt — ask user to clarify |
Also check for azure.yaml coexistence: if BOTH azure.yaml AND non-Azure .tf exist → azure.yaml takes priority → route to azure-deploy, not AppOnboard scaffold.
Compose Service Dependency Extraction
When docker-compose.yml or compose.yml is found, parse services: for infrastructure dependencies. Map known images to detectedServices[] entries (DetectedService in session-schemas.ts):
| Image pattern | type |
Version source |
|---|---|---|
postgres:* |
postgresql |
Image tag (e.g., postgres:16 → "16") |
redis:* / redis/redis-stack:* |
redis |
Image tag |
*kafka* (bitnami, confluent, etc.) |
kafka |
Image tag |
elasticsearch:* / opensearchproject/* |
elasticsearch |
Image tag |
mariadb:* |
mariadb |
Image tag |
mongo:* |
mongodb |
Image tag |
rabbitmq:* |
rabbitmq |
Image tag |
minio/* |
minio |
Image tag |
mysql:* |
mysql |
Image tag |
Set source: "compose" on each. If no tag or latest, omit version. Skip the app's own service entries (services with build: context pointing to the repo).
Compose Hostname Detection
After extracting compose services, grep app source code and config files for compose service names used as hostnames. Compose DNS names (e.g., postgres, redis, api) resolve inside Docker networks but NOT on Azure PaaS.
Detection: For each extracted service name, search app config files (.env, config.*, application.*, settings.*) and source code for patterns like host=<service_name>, <service_name>:<port>, ://<service_name>:, or <service_name>. used as a hostname. Common examples: host=postgres, redis://redis:6379, PGHOST=db.
Verdict: ⚠️ WARN — id: W-COMPOSE-HOSTNAME. "App references Docker Compose service name {name} as a hostname. On Azure, use the managed service endpoint (set via environment variable) instead." Include in postDeployRecommendations[]: { "title": "Replace compose hostnames with Azure endpoints", "reason": "Compose DNS names don't resolve on Azure PaaS", "effort": "low", "services": ["{mapped Azure service}"] }.