This chapter is part of the LifeLoveMe Journey. The manuscript also lives under docs/journey/LifeLoveMe_Journey_Book.md in the repository.
One File, One Path, One Vision
Making Development Simple, Efficient, and Productive
Why this chapter exists
LifeLoveMe grew from a focused proof-of-concept into a platform-shaped effort: Ramcharitmanas (RCM) first, with a Universal Collection Framework ahead, multiple apps (Hub, Explorer, Experience Player), documentation, and deploy tiers. Without a few simple rules, complexity becomes navigation cost—for you, for collaborators, and for any assistant that helps edit the tree. This chapter states a compact discipline: one file, one path, one vision.
One file — truth in one place
Every artifact should have a single authoritative home.
- Application and site source live under
web/. That is where HTML, CSS, client scripts, and packaged data for the static app are edited. - Canonical long-form docs that define product direction often live under
docs/(for example vision and architecture). The local web app may mirror shortened or HTML versions underweb/docs/andweb/assets/reference/—but you should know which copy is authoritative when both exist. - Generated or copied deploy output (for example
deploy/web_public/afterprepare_deploy.sh) is an artifact, not a second place to hand-edit. Editing deploy directly creates drift: the next build overwrites your work, or worse, production and source disagree silently.
When you fix a bug or add a paragraph, ask: Which file is the one true file? Commit that. If a mirror must update, update it in the same change or automate it—do not rely on memory.
One path — from edit to preview
One predictable pipeline reduces friction.
A practical path for local work is:
- Change source under
web/(anddocs/when you are editing canonical markdown there). - Run the project’s deploy preparation script so
deploy/web_public/reflects source (team workflow dependent). - Serve and smoke-test locally.
“One path” also means URLs and folders line up mentally: Home → Library → Hub → Explorer → Player/Reference, as described in the Grand Vision. When code, copy, and docs all describe the same spine, onboarding stays cheap.
One vision — decisions ladder up
One vision means the Grand Vision and Universal Collection Framework are the filters for new work: reader-first, search as the heart, collection manifests instead of hard-coded forks where possible, lean deploys, and incremental generalization without breaking RCM.
If a change does not serve clarity, trust, or extensibility—or if it only serves a shortcut in one folder—it probably belongs in a checkpoint or a design note, not in the main line.
Making development simple
Simplicity here is not minimal files; it is minimal ambiguity.
- Prefer obvious names and small README or status notes where the repo cannot speak for itself.
- Keep RCM-specific experiments labeled (backups, dated folders) so they are not mistaken for the shipping app.
- Use validation and test scripts already in the repo rather than one-off manual checks when you can.
Making development efficient
Efficiency comes from batching the right work: touch the authoritative file once, regenerate mirrors if needed, run prepare + tests once before declaring done. For AI-assisted editing, paste or point to the canonical path so suggestions apply to the file that actually ships.
Making development productive
Productivity is shipping without regret: small commits, clear chapter or doc updates when behavior changes, and preserving LineRef-first and search semantics called out elsewhere in the project. The Journey book itself is a tool—when you learn something that would save the next person an hour, add a short chapter or subsection.
A closing habit
Before you close a session, three checks:
- Did I edit the real source file?
- Does the path from this folder to the user’s browser still make sense?
- Does this still match the one vision?
If yes, the system stays simple enough to grow.
Further chapters will be appended to the Journey book in the repository as the work continues.