# LifeLoveMe Blueprint and Foundation

## Why This Blueprint Exists

LifeLoveMe is evolving quickly. Many ideas, files, apps, books, poems, records, and experiments are being created. Without a stable structure, valuable work can fade away, become hard to find, or require painful rework.

This blueprint is meant to preserve the foundation.

It is not necessary to build everything at once. But it is important that whatever is built today fits into the larger system.

---

## Core Philosophy

**LifeLoveMe** is organized around three pillars:

```text
Life • Love • Me
```

### Life
How we live better.

Health, wellness, fitness, food, sleep, stress, travel, career, purpose, social relations, and quality of life.

### Love
How we connect deeper.

Relationships, friendship, self-love, love for others, Kama, beauty, music, poetry, devotion, Ramcharitmanas, InnerRamayan, and spiritual transformation.

### Me
Who I am, what I create, what I preserve, and what I share.

Records, progress, Digital Me, family, friends, travels, books, poems, paintings, achievements, finances, plans, creator studio, community, consulting, and legacy.

---

## Design Principles

1. **Data should not be trapped inside HTML.**
   Content should eventually live in JSON, Excel, or a database.

2. **Excel can be the master source where appropriate.**
   Generated JSON should feed the app.

3. **Every file should have a clear home.**
   Source files, generated files, documents, media, and app files should not be mixed randomly.

4. **Use generated indexes for speed and reliability.**
   Apps should use index files such as search indexes, audio maps, and content indexes.

5. **Keep active modules and future modules visibly separate.**
   Users should know what works now and what is part of the roadmap.

6. **Design for private use first, public use later.**
   The same structure should eventually support selected friends, then public users.

7. **Avoid one-off fixes.**
   A solution for books should be reusable for poems, songs, paintings, travel notes, and public uploads.

---

## Folder Structure

Recommended structure:

```text
LifeLoveMe/
  web/
    home/
    life/
    love/
    me/
    about/
    books/
    poems/
    creations/
    docs/
    data/
      content/
    apps/
      rcm-hub/
      experience-player/
  data/
    ramayan/
      rcm/
        source/
        json/
    wellness/
  media/
    rcm/
      audio/
  scripts/
  docs/
  apps/
    spirit/
      inner-ramayan/
        mobile-app/
```

---

## Content Model

Books, poems, paintings, travel notes, songs, research papers, and public uploads should use a common structure.

Suggested fields:

```json
{
  "id": "unique-id",
  "type": "book",
  "title": "Title",
  "subtitle": "Subtitle",
  "creator": "Creator name",
  "category": "Category",
  "pillar": "Life | Love | Me",
  "tags": ["tag1", "tag2"],
  "status": "Concept | Draft | In progress | Published | Coming soon",
  "shortDescription": "One-line description",
  "summary": "Longer description shown when clicked",
  "fileUrl": "",
  "downloadUrl": "",
  "mediaUrl": "",
  "coverImage": "",
  "visibility": "private | selected | public",
  "allowDiscussion": false
}
```

This structure can support:

- books
- poems
- songs
- paintings
- essays
- travel notes
- family stories
- research papers
- app projects
- community uploads

---

## Ramcharitmanas Data Model

The Ramcharitmanas app should rely on stable relationships:

```text
RCM_Lines.LineID
    → exact text sequence

RCM_Lines.Prasang
    → Prasang grouping

RCM_Lines.AIREpisodeNumber
    → direct audio episode lookup

AIr_Episodes.AIREpisodeNumber
    → audio metadata
```

Do not rely primarily on title matching for audio playback.

---

## Documentation Model

Project documents should be saved in:

```text
web/docs/
```

and indexed in:

```text
web/data/content/documents.json
```

The app should have a documentation page so important decisions do not disappear.

Suggested document types:

- journey notes
- blueprint
- data dictionary
- deployment notes
- feedback notes
- roadmap
- technical decisions
- user testing notes

---

## Future Community Layer

When public uploads are enabled, the platform will need:

- user identity
- upload form
- file storage
- database
- moderation
- visibility settings
- tags and categories
- discussion/comment controls
- creator profiles

Until then, the public version should be read-only or selected-feedback only.

---

## Deployment Philosophy

Before public deployment:

1. Clean the folder structure.
2. Remove unnecessary large source files from public web folders.
3. Keep only needed HTML, CSS, JS, JSON, and media.
4. Test locally on Mac.
5. Test on iPhone.
6. Deploy to a staging or private URL.
7. Share with selected friends.
8. Collect feedback.
9. Refine before broader release.

---

## Core Reminder

Foundation and blueprints matter.

A product can grow in stages, but the structure must be strong enough to hold future growth.