This is the public control surface for your Hermes ecosystem: dashboard access, deployment entry points, operating references, and the structure for future modules like calendar, agents, logs, and settings.
Use Hermes as the umbrella product. Each page should feel like a section of one platform, not a random collection of tools.
Main operator view for Hermes activity, status, and direct control. Keep the legacy route live while we test subpath migration.
Release staging, static site deployment, and delivery verification. For now this remains on its own route while the Hermes shell becomes the umbrella.
A time-and-priority layer for execution planning, weekly structure, deadlines, and rhythm management across career, projects, and life admin.
Explain the operating structure: executive layer, specialists, duties, and which parts of the system are independent versus coordinated.
Central place for lower-priority output, event history, and machine receipts without contaminating the main command surface.
Open placeholder →Configuration surface for models, gateways, profiles, channels, permissions, and operating preferences.
Open placeholder →The earlier command-center briefing remains preserved as a reference artifact rather than the primary Hermes homepage.
Open archive →The structure stays simple: one canonical domain, selected modules beneath it, and separate subdomains only where infrastructure or app behavior truly demands it.
hermes.minjayjo.com becomes the brand and product layer. This is where a user should first land.
Some tools stay on subdomains until proven stable under subpaths. That is an engineering decision, not a branding failure.
As each service proves it can behave under a route prefix, we consolidate it under the Hermes umbrella.
These are the kinds of page-level intents each module should support as the system matures.
Hermes operating principle: 1. One visible executive surface 2. Clean route map 3. Separate infrastructure only when justified 4. Preserve working links during migration 5. Expand with pages, not unnecessary domains
The landing page is the shell. The next real leverage comes from moving selected tools behind first-class Hermes routes and giving each page actual functionality.
Dashboard and deploy remain available on their current subdomains so operations stay uninterrupted.
Calendar, agents, logs, and settings can now grow as clean native pages under the Hermes site.
Once we verify service compatibility, we move dashboard and deploy to route-based hosting without breaking the live system.