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
5.5 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.
Azure Debug Plan
AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE
This document is the official, canonical source for classifying a workspace and generating a VS Code debug setup plan. You MUST follow these instructions exactly as written. When in doubt, defer to this document. Do not improvise, infer, or substitute steps.
Global Rules (NO EXCEPTIONS)
- Update plan progressively — Mark steps complete as you go; update Last Updated timestamp on every status change
- ❌ Destructive actions require
ask_user— Always confirm before overwriting, deleting, or modifying existing files - Preserve existing config — Never silently overwrite project configuration files or
docker-compose.yml. Merge or ask first. - Scope — VS Code debug setup only — This instruction set classifies the workspace and generates a plan. Cloud architecture, IaC generation, provisioning, and deployment are handled by the azure-deploy agent through the complete azure-app-onboard pipeline.
Autopilot mode (overrides the approval STOP)
Active when the invoking chat query begins with [AUTOPILOT MODE], or .azure/project-plan.md records executionMode: auto or equivalent. When active, run fully unattended:
- Phase 0–1 still run in full. When generating the plan
.azure/vscode-debug-plan.md, also recordexecutionMode: autoor similar. Follow any specific instructions per the template. - Skip the step that instructs to run
openLocalPlanViewand do NOT wait for approval. Set status straight toApproved, then invokeazure-debug-generateas you normally would, but with the chat arg prefixed with[AUTOPILOT MODE]. - Reuse the project-plan prerequisites. When
.azure/project-plan.mdalready lists Prerequisites, carry them over wholesale instead of re-deriving them — see inventory.md § Step 1 for the detail. - Never call
ask_userfor non-destructive steps. Scan completeness is unchanged — autopilot suppresses the preview and approval gates only.
Workflow
Two phases — Classify → Plan — then STOP.
Do NOT generate any configuration files (docker-compose, launch.json, tasks.json, etc.). All
.azure/artifacts must be created inside the workspace root, not a session-state folder.
Phase 0: Classify
Scan the workspace for service roots. Produce a services[] list.
| Action | Reference |
|---|---|
Check for .azure/project-plan.md — if found, read it for advisory context. |
— |
| Scan all subdirectories; detect project type + runtime per service root | classify.md |
| If 2+ service roots: assign service IDs, deduplicate emulators, plan compound debug config | multi-service.md |
Phase 1: Plan
Scan dependencies, detect configuration, and generate the plan directly. The user reviews and edits the plan markdown before approving.
| # | Action | Reference |
|---|---|---|
| 1 | Detect prerequisites — Check required tools and VS Code extensions | inventory.md § Step 1 |
| 2 | Scan Azure dependencies — For each service, scan bindings (Functions) or SDK packages (other types) to identify Azure service dependencies | inventory.md § Step 2 |
| 3 | Map dependencies to emulators — Map each detected Azure dependency to its local emulator. Deduplicate across services. | inventory.md § Step 2 |
| 4 | Detect container runtime & Compose provider — Scan for an existing docker-compose.yml/compose.yaml and detect the available container runtime per prerequisites.md § Container runtime detection. Record the chosen runtime (Docker, Podman, or Podman (Docker-compatible)) and its Compose command in the plan's Orchestrator table. Prefer the Podman engine when it's ready — native podman compose, or docker compose when the Docker CLI is backed by Podman; fall back to Docker, and default to Docker Compose only when neither is confirmed. |
prerequisites.md |
| 5 | Detect migrations — Scan for migration files, dependencies, and scripts | migrations.md |
| 6 | Inventory API test opportunities — List HTTP endpoints and triggers per service | inventory.md § Step 3 |
| 7 | Write plan — Generate .azure/vscode-debug-plan.md from scan results. Fill all sections completely. |
plan-template.md |
| 8 | Present plan — Show plan to user and ask for approval. Highlight any ❓ prerequisites to double-check. The user can edit the plan directly before approving. On approval, update status to Approved. |
.azure/vscode-debug-plan.md |
❌ STOP HERE — Do NOT proceed to artifact generation. Do NOT generate docker-compose.yml, launch.json, tasks.json, or any other configuration files. Present the plan to the user and wait for approval. After approval, the custom agent wrapper will invoke
azure-debug-generateto handle generation.