# Wild Central UI Refactor

## Core Insight

Everything flows from the **service**. When a service is registered, Central lights up the components it needs: DNS records, proxy routes, TLS certs, DDNS records. The other pages aren't independent configuration surfaces — they're views into the effects of service registrations.

This creates two clear sections:

- **Services section** — the service-driven system. Everything here exists because services were registered (or because services need it to function). This is what Wild Cloud and Wild Works interact with.
- **Central section** — the device itself. Firewall, VPN, security, DHCP. These exist whether or not any services are registered. This is the appliance config.

## Navigation

```
Services
├── Dashboard        (default landing — health, warnings, at-a-glance status)
├── Cloudflare       (THE setup page — token, zones, tunnel. Prerequisite for everything)
├── Services         (registered services — the primary config surface)
├── DNS              (complete DNS picture — internal + external resolution per service)
└── Certificates     (TLS status per service — what's provisioned, what's missing)

Central
├── Firewall         (nftables rules)
├── VPN              (WireGuard server + peers)
├── CrowdSec         (intrusion detection)
└── DHCP             (IP address assignment + leases)
```

## Page Designs

### Dashboard

The landing page. At-a-glance system health:
- Daemon statuses: dnsmasq ✓, haproxy ✓, wireguard ✓, crowdsec ✓
- Registered services: 9 services (7 public, 2 internal)
- Certificates: 2 valid, 1 missing — ⚠ warning
- DDNS: synced, public IP 216.243.55.15
- Cloudflare: token valid ✓
- Warnings/actions: "wild-cloud.payne.io needs a TLS cert → Provision"

If Cloudflare isn't configured, the dashboard shows a prominent setup prompt directing the user there first.

### Cloudflare

The prerequisite page. Everything public depends on this:
- API token management (set, verify, show accessible zones)
- Tunnel status (cloudflared connection, connected services)
- DDNS provider config (which records to sync, current public IP, last sync)

This is the first page a new user configures. Without the token, public DNS and TLS certs don't work — the UI should make this dependency obvious.

### Services

THE primary interaction surface. Every registered service in one table:

| Domain | Backend | Type | Reach | DNS | TLS | DDNS |
|--------|---------|------|-------|-----|-----|------|
| cloud.payne.io | 192.168.8.240:443 | L4 passthrough | public | ✓ resolves | ✓ passthrough | ✓ A record |
| *.cloud.payne.io | (same) | L4 wildcard | public | ✓ resolves | ✓ passthrough | — |
| central.payne.io | 127.0.0.1:15055 | L7 proxy | internal | ✓ resolves | ✓ 88d left | — (internal) |
| wild-cloud.payne.io | 127.0.0.1:5055 | L7 proxy | internal | ✓ resolves | ⚠ missing | — (internal) |
| payne.io | 192.168.8.240:443 | L4 exact | public | ✓ resolves | ✓ passthrough | ✓ A record |

Each row shows the **complete status** of one service — every effect Central provides for it. The user sees immediately: "wild-cloud.payne.io is missing a TLS cert." Click a row to see details or take action.

Central's own domain (from config) appears in this table too — it's just another service from the user's perspective.

The service detail view shows:
- All the effects (DNS entry, proxy route, TLS cert, DDNS record)
- The registration source (wild-cloud, wild-works, config)
- Actions: provision cert, change reach, deregister

HAProxy raw config, stats, and generate/restart move to a collapsible "Advanced" section at the bottom.

### DNS

The **complete DNS picture** for all services. Not a configuration page — a status view showing how every domain resolves, from both inside and outside the network.

For each service domain:
| Domain | Internal (LAN) | External (Internet) |
|--------|---------------|---------------------|
| cloud.payne.io | 192.168.8.240 (direct to k8s LB) | 216.243.55.15 (via DDNS) |
| central.payne.io | 192.168.8.151 (Central) | — (internal only) |
| internal.cloud.payne.io | 192.168.8.240 (with local=/) | — (never forwarded) |

Plus DNS server infrastructure status:
- dnsmasq: running ✓, listening on 192.168.8.151
- Upstream forwarders: 1.1.1.1, 8.8.8.8
- DDNS sync: last checked 2m ago, public IP 216.243.55.15

This replaces the three overlapping DNS pages (dns, lan-dns, ddns) with one coherent view.

### Certificates

TLS cert status for every service that needs Central to terminate TLS:

| Domain | Status | Expires | Issuer | Action |
|--------|--------|---------|--------|--------|
| central.payne.io | ✓ valid | 88 days | Let's Encrypt | Renew |
| wild-cloud.payne.io | ⚠ missing | — | — | Provision |

Services with TLS passthrough (k8s instances) don't appear here — their backend handles TLS.

"Provision" and "Renew All" buttons. "Add Wildcard" for opt-in wildcard certs.

Requires Cloudflare token — if not configured, shows a prompt directing to Cloudflare page.

### Firewall, VPN, CrowdSec, DHCP

These are Central's own infrastructure config. Not service-driven. Each is its own page under the "Central" sidebar section. No changes needed to their content — just the grouping.

## Key Design Principles

1. **Services are the entrypoint.** Every page in the Services section answers: "what did Central do (or need to do) because of the services registered with it?"

2. **Status over configuration.** DNS and Certificates pages are primarily status views — they show the effects of service registrations. The user configures services, not DNS entries directly.

3. **Dependencies are visible.** Dashboard warns if Cloudflare isn't configured. Certificates page warns if token is missing. Services page shows which effects are green vs red.

4. **Two sections, two concerns.** Services = outward-facing (what Central does for consumers). Central = inward-facing (what the device does for itself).

## Migration

### Pages to delete
- `LanDnsPage.tsx` — duplicate
- `DdnsPage.tsx` — folded into Cloudflare
- `LanDnsComponent.tsx` — duplicate

### Pages to rename
- `CentralPage.tsx` → `DashboardPage.tsx`
- `IngressProxyPage.tsx` → `ServicesPage.tsx`
- `IngressProxyComponent.tsx` → `ServicesComponent.tsx`
- `CentralComponent.tsx` → `DashboardComponent.tsx`

### Pages to rewrite
- `DashboardComponent` — new status dashboard (currently just operator email)
- `ServicesComponent` — new service table with per-service effect status
- `DnsComponent` — unified DNS view (internal + external per service)
- `CloudflareComponent` — add DDNS management and tunnel status

### Sidebar changes
- Two labeled groups: "Services" and "Central"
- "Overview" → "Dashboard"
- "Ingress Proxy" → "Services"
- Remove DNS/LAN DNS/DDNS → replace with single "DNS"
- Add DDNS content to Cloudflare page