Section 01
1. Purpose
This document defines how LifeHub is organized as a navigable system.
Section 02
2. Architectural Principle
LifeHub should be organized from broadest context to greatest detail.
Section 03
2A. Repository Boundary
The repository root is the technical container for LifeHub, not the operational workspace root.
Section 04
3. Primary Domain Structure
At the highest meaningful navigation level, LifeHub is divided into five core domains:
1. Overview
The top-level ecosystem view.
- show the broad condition of the whole system
- surface major alerts
- summarize health, equity, progress, and status
2. Business
The business domain.
- contain all business entities and business-related systems
- provide a business-level dashboard
- allow drill-down into individual ventures, entities, and business modules
3. Personal
The personal domain.
- contain personal finance, personal assets, liabilities, records, and life-management structures
- allow visibility into personal condition without blending it carelessly with business systems
4. Projects
The project domain.
- contain initiatives that are cross-domain, experimental, developmental, ambiguous, or not fully reducible to business or personal categories
- support tracking, planning, synthesis, and execution of initiatives in progress
5. Goals
The goals domain.
- contain overarching aims and directional objectives
- show progress toward those aims
- connect activity in the other domains to larger outcomes
Section 05
4. Navigation Levels
LifeHub should generally be navigated through the following levels.
Level 1 — Main Menu / System Entry
The main starting point.
- present the major domains
- provide top-level orientation
- surface urgent notices where relevant
Level 2 — Domain Dashboards
The first major layer inside each domain.
- summarize the state of the selected domain
- show alerts, status, key metrics, and important navigation options
- make the domain understandable before entering detail
Level 3 — Subdomain / Entity Views
The next drill-down layer.
- separate a domain into meaningful sections, entities, or categories
- provide visibility into the major components of that domain
- Business → Boothly / Style Studio / Mongu Meal / other entities
Level 4 — Operational Views
The layer where day-to-day management becomes more visible.
- show actionable operational detail
- expose status, tasks, reporting, schedules, requests, notices, and health indicators
- help the user understand what is happening and what needs response
Level 5 — Records, Logs, Forms, and Actions
The deepest regular working layer.
- show underlying records
- allow entry, editing, review, and confirmation of detailed information
- support actual operational actions
Section 06
5. Relationship Between Levels
Each level should act as a contextual wrapper for the one below it.
Section 07
6. Business Domain Architecture
The Business domain should generally follow this structure:
Business Domain
- overall business dashboard
- top-level business metrics
- business alerts and notices
Business Entities
Each business should be treated as a drill-down unit with its own view.
- Boothly
- Style Studio
- Mongu Meal
Entity Dashboard Layer
Each entity dashboard may contain:
- health/status
- reporting status
- key metrics
Entity Detail Layer
Deeper views may expose:
- daily reports
- account-level details
- inventory/resource data
Section 08
7. Personal Domain Architecture
The Personal domain should generally follow this structure:
Personal Domain
- personal dashboard
- equity and debt overview
- urgent notices
Major Personal Categories
Possible categories include:
- accounts
- liquid funds
- assets
Personal Detail Views
Each category may drill into:
- individual accounts
- assets by type
- debts and obligations
Section 09
8. Projects Domain Architecture
The Projects domain should generally follow this structure:
Projects Domain
- active projects overview
- project health/status
- upcoming deadlines
Individual Project Views
Each project may include:
- summary
- current stage
- next actions
Project Detail Layer
Possible detail areas:
- synthesis files
- working models
- generated assets
Section 10
9. Goals Domain Architecture
The Goals domain should generally follow this structure:
Goals Domain
- overview of major aims
- progress visibility
- strategic direction
Goal Categories or Tracks
Goals may be grouped by:
- domain
- timeframe
- strategic area
Goal Detail Views
Each goal may include:
- definition
- current status
- milestones
Section 11
10. Overview Domain Architecture
The Overview domain is the highest system-level summary layer.
Section 12
11. Cross-Domain Design Patterns
Even though domains differ, the system should use shared patterns where appropriate.
Section 13
12. Information Boundaries
LifeHub should preserve clean boundaries between:
Section 14
13. Expansion Rules
As LifeHub grows:
Section 15
13A. Implementation Boundary
Implementation work should preserve the same structural boundaries as the rest of LifeHub.
Section 16
14. Architectural Summary
LifeHub should be structured as a drill-down system with five major domains and multiple navigation levels.