Initial project scaffold with frontend dashboard and Caddy config

Frontend-first status board with mock data for 16 vendors.
Caddy configured on port 8443 with internal TLS, coexisting
with an existing Caddy instance (admin on 2020, no HTTP redirects).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,77 @@
+# Infrastructure Monitoring Dashboard
+
+## Project Overview
+
+A web-based status feed aggregator for a K-12 school district IT department. Provides a single-pane-of-glass view of vendor service health, replacing the need to manually check multiple status pages during incidents.
+
+## Target Vendors
+
+| Vendor | Type | Status Source |
+|---|---|---|
+| Microsoft 365 | Productivity suite | Service Communications API (Graph API) |
+| SpamTitan | Email security | TBD — likely status page scrape or synthetic check |
+| PowerSchool | Student Information System | TBD — status page scrape |
+| Classlink | SSO / Identity | TBD — status page or API |
+| Apple | Device ecosystem | Apple System Status page (JSON feed) |
+| DRC | Assessment / Testing | TBD — status page scrape |
+| FinalSite | School website CMS | TBD — status page scrape or synthetic check |
+| Google Workspace | Productivity suite | Google Workspace Status Dashboard (JSON feed) |
+| Follett | Library management | TBD — status page scrape or synthetic check |
+| EdInsight | Data analytics (Harris Education Solutions) | TBD — status page or synthetic check |
+| Raptor | Visitor management | TBD — status page scrape |
+| SchoolMessenger | Communication platform | TBD — status page scrape |
+| McGraw Hill | Curriculum / assessment | status.mcgrawhill.com (JS-rendered status page) |
+| Fortinet | Network security | TBD — FortiCloud API or status page |
+| Local Infrastructure | On-prem hardware | Direct monitoring (SNMP, API, or synthetic checks) |
+
+Note: Exchange Online is intentionally excluded — it is a component of M365 Service Health and would be redundant.
+
+New vendors should be added incrementally, not speculatively.
+
+## Hosting
+
+- **Web server**: Caddy
+- **URL**: https://status.nhsd.net:8443 (port 8443 to avoid conflict with existing Caddy instance on this machine)
+- **Access**: Local network only (DNS A record points to the host machine)
+- **TLS**: Caddy internal TLS (self-signed). IT staff only — browser cert warnings are acceptable.
+
+## Architecture
+
+- **Frontend**: HTML/CSS/JS dashboard — lightweight, no heavy framework. Designed to work on a wall-mounted monitor or quick browser check.
+- **Backend**: Node.js service that polls vendor status on a schedule and caches results.
+- **Web server**: Caddy reverse-proxies to the backend API and serves the static frontend.
+- **Services**: NSSM runs both Caddy and the Node backend as Windows services.
+- **Data flow**: Backend polls vendors → caches to local store → frontend fetches from backend API → auto-refreshes on interval.
+
+## Directory Structure
+
+```
+infrastructure-monitoring-dashboard/
+├── CLAUDE.md
+├── .gitignore
+├── bin/
+│   ├── caddy/          # Drop caddy.exe here (git-ignored)
+│   └── nssm/           # Drop nssm.exe here (git-ignored)
+├── config/
+│   └── Caddyfile       # Caddy server configuration
+├── frontend/
+│   ├── index.html
+│   ├── css/
+│   └── js/
+├── backend/
+│   ├── package.json
+│   ├── server.js
+│   └── providers/      # One module per vendor
+└── scripts/            # NSSM service install/uninstall helpers
+```
+
+## Development Approach
+
+Frontend-first with mock data. Build the dashboard UI and layout with realistic fake data, then replace mocks with real vendor integrations one at a time.
+
+## Design Principles
+
+- Keep it simple. This is a status board, not a monitoring platform.
+- Degrade gracefully — if a vendor check fails, show "unknown" rather than crashing.
+- Each vendor integration should be a self-contained module so they can be added/removed independently.
+- Optimize for glanceability — status should be obvious from across the room (color-coded, large indicators).