# foundation/0.2.0 Monorepo - /docs - /docs/current/foundation - /packages - /server - /shell - /apps Env Vars - /next/.env, /expo/.env, /server/.env. For client-side envs, prepend PUBLIC_. Server - Supabase - Microsoft Playwright for web browsing - Monorepo Bundler and Build System: Turborepo - Package Manager: Yarn - Shell (Frontend): React Native Web with Expo hosted on Vercel. - We use Next.js App Router which supports React Server Components. - Server (Backend): Supabase hosted on Supabase. - Database: Postgres in Supabase - Server Logic: Deno in Supabase - Real-Time: Phoenix Elixir in Supabase ```markdown - [Tamagui](https://tamagui.dev) 🪄 - [solito](https://solito.dev) for cross-platform navigation - Expo SDK - Next.js - React Navigation ``` Technical Debts - Migrate from Next Pages Router (`/next/pages`) to Next App Router (`/next/app`). Notes - Make sure version number for packages in apps/{expo|next} and packages/app are the same. ### Changes to docs 1. Moved out operational informations to a separate Operations Guide. This doc more narrowly focuses on technical details. --- # DISSOLVE ALL BELOW. BELOW ARE FROM PAST ITERATION. TODO - /server/_common - functions interacting with database. --- # Changes - Added Testing Stages. - From Data Models, deleted Energy, Events. - In Server, added API Endpoints. --- 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. ### Testing Stages We test new versions in three stages: Developer Device (.dev), Test Server (.test), and Production Server (.pro). ### 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 in .dev environment. If code changes pass tests, lint code changes, commit, push, review, merge. 5. Test version in .test environment. Release to .pro environment. 6. 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. ### 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. ### API Endpoints API Endpoints are in server/functions. - /characters: CRUD characters. - /items: CRUD items. - /spaces: CRUD spaces. - /generate: Call AI to generate contents. - /rank: Call AI to rank contents. ### Common Logic Commonly called functions are in server/functions/_common. # 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.