──────

### 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
2026-09-20 23:33:55 +02:00
parent f935bbeb8c
commit 635a130f0b
195 changed files with 28309 additions and 957 deletions
@@ -0,0 +1,74 @@
+<!-- azure-cor-disclaimer -->
+> **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.
+
+# Limited Support Warnings
+
+> Emit a standardized warning when the skill detects a feature that is not yet fully supported. The warning format is consistent across all feature categories so the user always knows what to expect.
+
+---
+
+## ⛔ Detection Algorithm — MANDATORY
+
+For every project type, runtime, and emulator declared in the plan's tables, follow this procedure **exactly**:
+
+1. **Check for a matching reference file** — List the files and subdirectories in the category folder (ignoring `_template.md`). If any filename or subdirectory name loosely matches the declared value (ignoring case, spaces, dashes, and underscores), the feature has a reference file.
+2. **Check the status inside the reference file** — Open the matched reference file and look for a status indicator. If the file is marked `🔲 Planned` (in a frontmatter note, status field, or top-level callout), the feature has **limited support** despite having a reference file. You **MUST** emit a warning.
+3. **If a match exists AND the file is not marked Planned** → the feature is fully supported. Proceed normally.
+4. **If no match exists** → the feature has limited support. You **MUST** emit a warning. Do NOT substitute a different, supported feature.
+
+| Category | Category Folder | Path Notes |
+|----------|-----------------|------------|
+| Project type | `references/project-types/` | Some types use subdirectories (e.g., `frontend-spa/frontend-spa.md`). Match against both filenames and subdirectory names. |
+| Runtime | `references/runtimes/` | |
+| Emulator | `references/emulators/` | |
+
+> ⚠️ **Do NOT skip this check.** Every declared feature MUST be verified against the category folder before generating artifacts.
+
+---
+
+## Warning Format
+
+```
+⚠️ LIMITED SUPPORT: {Category} "{value}" is not yet fully supported.
+```
+
+Where:
+- `{Category}` — a short label for the feature area (e.g., `Project type`, `Runtime`, `Emulator`)
+- `{value}` — the specific feature declared in the plan (e.g., `python`, `Container App`, `Cosmos DB`)
+
+---
+
+## ⛔ Emission Protocol — MANDATORY
+
+When a limited-support feature is detected, you **MUST** follow this exact sequence:
+
+### Step 1: Emit in assistant message
+
+Write the canonical warning in your **regular assistant message text**. This is mandatory — the warning must be visible in the chat output, not hidden inside a tool call.
+
+```
+⚠️ LIMITED SUPPORT: Emulator "Durable Task Scheduler" is not yet fully supported.
+```
+
+### Step 2: Confirm with user
+
+For the **first** limited-support feature encountered in the session, call `ask_user` to confirm whether to proceed:
+
+```
+ask_user(
+  question: "⚠️ LIMITED SUPPORT: {Category} \"{value}\" is not yet fully supported. Would you still like me to put forth a best-effort attempt?",
+  choices: [
+    "Yes, proceed with best effort",
+    "No, stop here"
+  ]
+)
+```
+
+If the user agrees, treat that as blanket consent for the rest of the session. Any additional limited-support features discovered later should still be emitted as a warning — but do **not** call `ask_user` again.
+
+> Emit each `⚠️ LIMITED SUPPORT:` warning exactly once per `(Category, value)` pair in assistant messages.
+---
+
+## No Silent Substitution
+
+**Do NOT silently substitute a supported alternative** when a feature has limited support (e.g. switching a Container App to Azure Functions, or Python to Node.js). Always generate for the project type, runtime, and emulators declared in the plan, even when support is limited.