### 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
3.0 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.
Backend Smoke Test
Read at Step 2. How to start the backend and prove every endpoint registers and responds.
Per-runtime start command
| Runtime | Build | Start host | Default port |
|---|---|---|---|
| Azure Functions (Node v4 / TS) | npm run build |
func start |
7071 |
| Azure Functions (Python v2) | python -m py_compile (or build) |
func start |
7071 |
| Azure Functions (.NET isolated) | dotnet build |
func start (or dotnet run) |
7071 |
| Plain Node API | npm run build |
npm start |
project-defined |
Run the exact command the artifact (.azure/integration-plan.md) documents — it reflects the real project.
Before starting: config & build
- Ensure
.env/local.settings.jsonhas the values the host needs — especially the DB connection string pointing at the local database from Step 1. Use.env.exampleas the template. Never commit secrets. - Build first. Zero errors.
TS2307: Cannot find module '@app/shared'→ the shared package exports/build are broken; fix before starting. - For Functions Node v4: list
dist/and confirm themainglob matches the compiled handler paths. A parentrootDirnests output one level deeper (dist/functions/src/functions/*.js). Fixmainbefore starting or no functions register.
Reading host output (pass/fail)
| Console signal | Meaning | Action |
|---|---|---|
| Each function name listed under "Functions:" | Registered | PASS |
No job functions found. |
Build/main mismatch |
Fix main/build, restart |
ERR_MODULE_NOT_FOUND / broken import |
Bad import or missing dist | Fix import/build, restart |
| Constructor throws on startup | A service (often Enhancement) throws in its constructor | Defer config validation out of the constructor / wrap in try-catch, restart |
Probing endpoints
| Probe | Expected | Verdict |
|---|---|---|
GET /api/health |
200 with status body |
PASS (required) |
GET a list/read endpoint |
200 with array/object, or clean 401/400 |
PASS |
| A write endpoint with missing/invalid body | 400/401 structured error |
PASS (validation working) |
Any endpoint returning 500 |
Schema missing, service crash, unhandled error | FAIL — investigate & fix |
A clean 4xx (missing auth, invalid body) is a PASS — it proves validation and routing work. A 500 is a FAIL: most often a missing table (revisit Step 1) or a service constructor crash.
Use curl/Invoke-RestMethod or the browser tool to hit endpoints. Stop the host when probing is done (unless Step 4 will reuse it).