Rename project to OrbitalWard

Add optional TLS certificate expiry checks for website monitors and update product, package, environment, Docker, and documentation naming.

docs/alerting-design.md

@@ -26,4 +26,4 @@ Initial channels:
 - Zoom Team Chat incoming webhook
 - Generic webhook
 
-Alert messages should be human-readable and include asset, check, status, duration, timestamps, and a link back to InfraPulse.
+Alert messages should be human-readable and include asset, check, status, duration, timestamps, and a link back to OrbitalWard.

docs/architecture.md

@@ -1,6 +1,6 @@
 # Architecture
 
-InfraPulse is a monorepo with four main areas:
+OrbitalWard is a monorepo with four main areas:
 
 - `backend`: FastAPI service exposing REST endpoints and owning database access.
 - `worker`: Background scheduler and collectors for checks and alert evaluation.

docs/discovery-design.md

@@ -1,6 +1,6 @@
 # Discovery Design
 
-Guided discovery is a core InfraPulse workflow.
+Guided discovery is a core OrbitalWard workflow.
 
 ```text
 Add target
@@ -16,7 +16,7 @@ Create monitors and optional alert rules
 
 ## Monitor vs Alert Separation
 
-InfraPulse must allow monitoring without alerting. Every discovered item should eventually support separate choices:
+OrbitalWard must allow monitoring without alerting. Every discovered item should eventually support separate choices:
 
 - Collect metric
 - Graph metric

docs/plugin-design.md

@@ -1,11 +1,11 @@
 # Plugin Design
 
-Plugins will let InfraPulse add collectors and discovery logic without hard-coding every integration into the core API.
+Plugins will let OrbitalWard add collectors and discovery logic without hard-coding every integration into the core API.
 
 Target shape:
 
 ```python
-class InfraPulsePlugin:
+class OrbitalWardPlugin:
     name: str
     display_name: str
 

docs/progress.md

@@ -1,10 +1,10 @@
-# InfraPulse Progress
+# OrbitalWard Progress
 
-Last updated: 2026-05-22
+Last updated: 2026-05-23
 
 ## Current State
 
-InfraPulse has a working Docker Compose development stack with PostgreSQL, Redis, FastAPI backend, Python worker, and React/Vite frontend.
+OrbitalWard has a working Docker Compose development stack with PostgreSQL, Redis, FastAPI backend, Python worker, and React/Vite frontend.
 
 Implemented foundation:
 
@@ -18,6 +18,7 @@ Implemented website-monitor slice:
 
 - Create, edit, delete website monitors from the UI.
 - HTTP status and expected-text checks.
+- Optional TLS certificate expiry checks for HTTPS monitors.
 - Monitor status and recent incident visibility on dashboard.
 - Basic alert rules created with website monitors.
 - Incidents can be acknowledged and silenced from the UI.
@@ -27,7 +28,7 @@ Implemented notification slice:
 
 - Create, edit, test, and delete notification channels from the UI.
 - Generic webhook, Mattermost, and Zoom Team Chat channel types.
-- Webhook URLs encrypted at rest using `INFRAPULSE_SECRET_KEY`.
+- Webhook URLs encrypted at rest using `ORBITALWARD_SECRET_KEY`.
 - Saved webhook URLs are not returned to the UI.
 - Configurable post username per notification channel.
 - Worker sends incident open and recovery notifications.
@@ -42,7 +43,6 @@ Implemented notification slice:
 - Alert rule editing UI is not implemented.
 - Notification routing/policies are not implemented; all enabled webhook channels receive incident notifications.
 - Email/SMTP notifications are not implemented yet.
-- TLS certificate expiry checks are not implemented yet.
 - Ping and TCP checks are not implemented yet.
 - Graphing exists only as placeholders; metric visualization is not implemented.
 - Worker scheduling is simple polling, not a Redis queue yet.
@@ -51,16 +51,15 @@ Implemented notification slice:
 
 ## Recommended Next Work
 
-1. Add TLS certificate expiry monitor support.
-2. Add ping and TCP port monitors.
-3. Add alert rule editing UI and richer alert conditions.
-4. Add notification policy/routing controls.
-5. Add email/SMTP notification channel.
-6. Add audit event writes for auth, monitor, credential, notification, and incident actions.
-7. Build credential vault UI with masked secret handling.
-8. Add user administration UI.
-9. Add graphs for website response time and monitor status history.
-10. Add backend and worker tests for the website-monitor and notification flows.
+1. Add ping and TCP port monitors.
+2. Add alert rule editing UI and richer alert conditions.
+3. Add notification policy/routing controls.
+4. Add email/SMTP notification channel.
+5. Add audit event writes for auth, monitor, credential, notification, and incident actions.
+6. Build credential vault UI with masked secret handling.
+7. Add user administration UI.
+8. Add graphs for website response time and monitor status history.
+9. Add backend and worker tests for the website-monitor and notification flows.
 
 ## Operational Notes
 
@@ -75,4 +74,4 @@ Default local login comes from `.env`:
 - `INITIAL_ADMIN_EMAIL=admin@example.com`
 - `INITIAL_ADMIN_PASSWORD=change-me`
 
-Change these values before using InfraPulse outside local development.
+Change these values before using OrbitalWard outside local development.

docs/security.md

@@ -1,6 +1,6 @@
 # Security
 
-InfraPulse must be secure from the beginning because it will store infrastructure credentials.
+OrbitalWard must be secure from the beginning because it will store infrastructure credentials.
 
 ## Authentication
 
@@ -19,7 +19,7 @@ Credential records are modeled separately from monitors and assets. Secret field
 
 Rules:
 
-- Use `INFRAPULSE_SECRET_KEY` from the environment.
+- Use `ORBITALWARD_SECRET_KEY` from the environment.
 - Never log secrets.
 - Mask saved secrets in the UI.
 - Audit credential create, update, and delete events.

docs/vision.md

@@ -1,12 +1,12 @@
-# InfraPulse Vision
+# OrbitalWard Vision
 
-InfraPulse is a secure, self-hosted monitoring platform for homelabs, small businesses, and internal IT teams.
+OrbitalWard is a secure, self-hosted monitoring platform for homelabs, small businesses, and internal IT teams.
 
 The v0.1 product should feel like a polished appliance, not a pile of raw monitoring configuration. Users should be guided through adding targets, testing connections, discovering useful items, choosing what to monitor, and separately choosing what should alert.
 
 ## Design Philosophy
 
-InfraPulse exposes intent, not implementation details.
+OrbitalWard exposes intent, not implementation details.
 
 Raw SNMP OIDs, probe internals, and collector details belong behind friendly profiles and advanced tools. The normal UI should say things like "Port 5 outbound traffic", "Graph this port", and "Alert if port goes down".