# foundation/0.1.0

This documentation explains how our technology works (or shall be made to work). 

# Process

This section explains how we develop each version of our technology. 

### **Versioning Convention**

Our version numbers follow MAJOR.MINOR.PATCH format. 

For example, version 1.2.3 is 3rd patch of 2nd minor version of 1st major version. 

- Patches fix bugs, but do not add new features.
- Minor versions add new features but not breaking changes.
- Major versions can introduce any changes including breaking changes and deletion of legacy features.

### **Release Cadence**

We target to release 

- major versions in October,
- minor versions in corresponding months (e.g. 0.6.0 in June),
- patches anytime.

We do not release version upgrades in November and December in order to give people time to catch up with big changes in the latest major version. 

### **Version Control**

We use git on GitHub for version control. 

For each version, we develop in 3 branches:

1. foundation/VERSION (e.g. foundation/1.2.3) introduces new general tools with which people can create new experiences. 
2. prominence/VERSION introduces applications that deliver immediate utility to people and demonstrate how people can utilize our technology to create great experiences. 
3. orientation/VERSION brings our codebase in orientation with our documentations, fix bugs, and add tools. 

We create smaller branches to address specific issues (e.g. add features) that we track on Linear. 

### Managing Documents

We use Notion to write and track documents. 

We first write a documentation, and then develop a version to fulfill the documented promises. 

### Managing Commits

We use Linear to manage codebase changes. 

### Example Cycle

Start working on a new version. 

1. Write documentations for the version. Confirm. 
2. Translate target outcomes to specific issues in Linear. 
3. Select an issue. Create a branch. Make code changes. Add issues in Linear when we meet bugs or ideas. 
4. Test code changes. If code changes pass tests, lint code changes, commit, push, review, merge. 
5. Celebrate. Review notes, especially issues we wrote down in Linear, then start writing documentations for the next version. 

Repeat. 

### AI Coding Assistants

Use AI Coding Assistants. 

# Monorepo

### **Tools**

We maintain our codebase as a monorepo using following tools:

- Monorepo Bundler and Build System: Turborepo
- Package Manager: Yarn
- Shell (Frontend): React Native Web with Expo hosted on Vercel.
- Server (Backend): Supabase hosted on Supabase.
    - Database: Postgres in Supabase
    - Server Logic: Deno in Supabase
    - Real-Time: Phoenix Elixir in Supabase

### **Rules**

We follow the following rules:

- Use Typescript wherever possible and strictly enforce types.

# Seelog

Seelog directory contains information on how to understand the codebase. 

### Intuition

Characters place Items in Spaces. 

### Data Models

We track data models in /seelog/src/models. 

- Every data is a Log.
- Character extends Log.
    - Member extends Character.
    - AiCharacter extends Character.
- Item extends Log.
    - DocumentItem extends Item.
    - MediaItem extends Item.
    - InputBoxItem extends Item.
- Space extends Log.
    - HallRoom extends Space.
    - MonitorRoom extends Space.
    - ControlRoom extends Space.
- Energy extends Log.
- Event extends Log.

### Documentations

We keep copies of product documentations and technology documentations as markdown files in /seelog/docs. 

# Server

Server directory contains code for database and server-side logic. 

### Database

We set up schema using sql files in /server/supabase/migrations, and we set up seed data in /server/supabase/seed.sql.  

# Shell

Shell provides the interface for our members to access our technology. 

Code files are managed in abstraction levels. 

- /pages: Containers for elements. A Page usually corresponds to a Space.
- /components: Elements on pages. A Component usually corresponds to an Item, or a way to view or edit an Item.
- /hooks: Commonly called stateful logic.
- /common: Commonly called stateless logic.
- /types
- /styles

# Notes

Find more ways to let people contribute from outside. 

Find more ways to let AI keep growing our product. 

Find more ways to let people guide AI. 

Place compute and storage in server. 

Place caching and staging in shell.