Sven laptop
635a130f0b
Build and Push Docker Images / detect-changes (push) Successful in 11s
Build and Push Docker Images / build-auth-api (push) Successful in 1m0s
Build and Push Docker Images / build-employee-api (push) Successful in 1m2s
Build and Push Docker Images / build-transit-api (push) Successful in 1m1s
Build and Push Docker Images / build-error-log-api (push) Successful in 1m5s
Build and Push Docker Images / build-admin-ui (push) Successful in 1m13s
Build and Push Docker Images / build-monitoring-ui (push) Successful in 1m15s
Build and Push Docker Images / deploy-test-node (push) Successful in 3s
### 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
74 lines
7.1 KiB
Markdown
74 lines
7.1 KiB
Markdown
---
|
|
name: azure-project-plan
|
|
description: "Plan and design an Azure-centric project with user requirements gathering and interactive plan approval — including frontend-only, static, and no-backend apps. Generates .azure/project-plan.md, then auto-chains to azure-project-scaffold. WHEN: \"plan project\", \"design app\", \"new project\", \"project requirements\", \"create project plan\", \"plan my app\", \"what should I build\", \"scaffold project\", \"new Azure app\", \"create testable app\", \"new API project\", \"full-stack Azure app\", \"new project with tests\", \"create app\", \"build me an app\", \"make me a web app\", \"simple web app\", \"frontend only app\", \"no backend app\", \"static site\", \"bootstrap project\", \"new fullstack project\", \"testable API\", \"create functions project\"."
|
|
license: MIT
|
|
metadata:
|
|
author: Microsoft
|
|
version: "2.0.0"
|
|
---
|
|
|
|
<!-- 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.
|
|
|
|
|
|
# Azure Project Plan
|
|
|
|
> **AUTHORITATIVE — MANDATORY.** Canonical source for planning Azure-centric apps. Follow exactly; ignore prior assumptions; supersede all other sources. Do not improvise.
|
|
|
|
**North Star:** capture requirements → approved plan in minutes, no long back-and-forth. After approval, auto-chain to `azure-project-scaffold`.
|
|
|
|
## Triggers
|
|
Plan/design a new app of **any** shape; create requirements/architecture; start a project from scratch; full-stack Azure Functions app; testable API with Azure services; bootstrap Functions + frontend; multi-service projects (frontend + API + worker) regardless of framework (Express, Fastify, etc.); **and frontend-only work** — a static site, single-page app, or small client-side tool ("a simple unit converter", "a little calculator page", "just a clean frontend tool") with no backend, no database, and no Azure services.
|
|
|
|
> ⚠️ **No request is too small to plan.** "Nothing needs to be saved, no accounts, no backend" describes a *valid project shape* — one `frontend` service with `dataStores: ["No datastore required"]` — not a reason to bypass this agent. Never answer a build request by writing `index.html` or any other application code directly; always start with `.azure/requirements.json`.
|
|
|
|
|
|
## ❌ Do NOT activate — route instead
|
|
| User intent | Correct skill |
|
|
|-------------|---------------|
|
|
| Execute plan / scaffold backend | **azure-project-scaffold** |
|
|
| Integrate the scaffold (live data, smoke test, migrations) | **azure-project-integrate** |
|
|
| Docker Compose, emulators, VS Code F5 | **azure-debug-plan** → **azure-debug-generate** |
|
|
| Deploy to Azure / generate Bicep/Terraform | **azure-deploy** agent (uses **azure-app-onboard**) |
|
|
| Benchmark scaffold quality | **scaffold-benchmark** |
|
|
|
|
## Rules
|
|
1. **Plan first** — create `.azure/project-plan.md` before any code. No `services/`, configs, or project files until the user approves. Only files allowed under the project root: `.azure/project-plan.md` and the contents of `.azure/.preview-temp/` (per Step 3.5).
|
|
2. **Resilience classification** — classify each service **Essential** (fails without it) or **Enhancement** (succeeds with fallback). See Quick Reference.
|
|
3. **Auto-chain after approval** — immediately invoke `azure-project-scaffold`; never ask the user to invoke it manually. **Generate a presentation-quality frontend HTML/CSS preview** during planning per Step 3.5 (the scaffold agent consumes it as a visual spec but builds the real app with the chosen framework).
|
|
4. **Interactive UI** — all user input comes through the requirements and plan webviews; never ask in plain chat and never call `vscode_askQuestions`. Batch open questions into the webview rather than the transcript.
|
|
|
|
## Autopilot is selected on the plan page (this agent always runs guided)
|
|
This agent **always** runs guided: it generates `.azure/project-plan.md` with `Status: Planning`, opens the plan preview, and stops for the user's approval. It does **not** detect, decide, or record autopilot, and never skips the preview or approval gate.
|
|
Autopilot is chosen by the **user** via the **Autopilot toggle on the plan webview**, after the plan is shown. When they approve with it on, the extension records `**Execution Mode**: auto` in `.azure/project-plan.md`, enables global auto-approve, and hands off to the scaffold agent with the `[AUTOPILOT MODE]` marker; every downstream skill then inherits autopilot from the plan file and runs unattended to the end.
|
|
|
|
There is nothing autopilot-specific for you to do here — just write a correct, complete plan and always emit both the `### Run` and `### Debug` prerequisite sub-tables (§ 5). Never call `vscode_askQuestions` in chat — the only stop is the plan webview approval.
|
|
|
|
|
|
## Two-phase instructions — read the file for the current phase
|
|
|
|
This agent runs in two phases with **separate instruction files**. Read only the file for the phase you are in — do **not** load both at once. This keeps each phase focused and fast.
|
|
|
|
| Phase | When | Read & follow | Produces |
|
|
|-------|------|---------------|----------|
|
|
| **A — Requirements** | Fresh invocation — no `.azure/requirements.json` yet, or the user is starting a new project | [`requirements.md`](requirements.md) | `.azure/requirements.json` → requirements webview |
|
|
| **B — Plan** | Re-entry after the user submits the requirements form (query begins *"Requirements submitted at .azure/requirements.json…"*), or `.azure/requirements.json` is already fully answered | [`plan.md`](plan.md) | `.azure/project-plan.md` + `.azure/.preview-temp/` |
|
|
|
|
- **Phase A** — Step 1 (Detect Workspace) + Step 2 (Gather Requirements).
|
|
- **Phase B** — Step 3 (Generate Plan) + Step 3.5 (Frontend Preview) + Planning Quick Reference.
|
|
- The end-to-end order is unchanged: **DETECT → GATHER → GENERATE PLAN → GENERATE PREVIEW → approval → AUTO-CHAIN scaffold.** Only the instructions are split by phase; each phase file is self-contained for its phase.
|
|
|
|
## Workflow (mandatory order)
|
|
DETECT (Step 1) → GATHER (Step 2) → GENERATE `.azure/project-plan.md` (Step 3) → GENERATE FRONTEND PREVIEW (Step 3.5, if applicable) → approval → AUTO-CHAIN scaffold after approval. Only files allowed: `.azure/project-plan.md` and the contents of `.azure/.preview-temp/` — no `services/`, configs, or production code. Detect + gather are inlined in [`requirements.md`](requirements.md); plan generation, the preview, and all architectural context are inlined in [`plan.md`](plan.md). Planning needs ZERO external file reads except `references/html-preview.md` for Step 3.5.
|
|
|
|
## Outputs
|
|
|
|
| Artifact | Location |
|
|
|----------|----------|
|
|
| **Requirements** | `.azure/requirements.json` (statuses → `confirmed` after the webview submit) |
|
|
| **Project Plan** | `.azure/project-plan.md` (Status: Approved) |
|
|
|
|
## Next
|
|
|
|
> **Automatic**: after the plan is approved, the flow immediately invokes **azure-project-scaffold** (auto-chain). No user action required.
|