add alias ~platform and ~material

docs/devnotes.md

@@ -49,3 +49,38 @@ Use physical directions to avoid trouble, like "margin-top, margin-bottom".
 For isolating control of the UI effect, we already setup css variables `--safe-area-inset-*`. In components, you should use the variables unless you have reasons to use `env()`.
 
 Using `--safe-area-inset-*`, you can control the global value in settings (under dev mode).
+
+## Module Isolation
+
+> Write the code that can be easily removed.
+
+To limit the code impact, we organize the code based on **"topic modules"** (modules in short). Each module focus on a specific topic described by the name. Like the "accounts" contains the code about the accounts, "masto" contains the code about the masto (a library used to access mastodon) helpers.
+
+> Sidenote: This also helps easing "the landing problem". If you need something about accounts, no longer "common/accounts" and "hooks/accounts" and "helpers/accounts" and "components/accounts". Someone says this is clean - is it even if you need to jump between 6 directories for how one simple feature works?
+> And you no longer needs to think about "where to place this file (between six directories, usually)".  People often optimize their code structure too early - just like how they treat the runtime performance.
+> The worse is, it's very hard to solve this problem later, because you had sent your code to different places.
+
+There are **two special modules** in this project:
+
+One is the *platform*. This module provides foundation of this app: deals with the host platform (like SizedTextarea - auto resized textarea), provides custom platform feature (like StackedRouter - provides mobile-native navigation experience).
+
+The another is the *material*. This module provides Material styling toolkit, the stylesheets, MUI Theme, constants and components.
+
+They (and only them) can be accessed by special aliases: `~{module name}`, like the `~platform`.
+
+We discourage cross referencings between two topics. Reuse is not better than duplication. Cross referencing is still possible if required.
+
+When a tool, a file or a component is required every-elsewhere, **promoting** is required to reduce the cross referencing. Thanksfully, it's usually automated process for moving files.
+
+But, sometimes you need a redesigned (sometimes better) tool for the generic usage. Follow the idea:
+
+- Move slowly or crash. Only make the change if it's required.
+- Try to make the original part depends on your new tool, and keep the original for awhile.
+- Mark deprecated only if you think the original won't worth an existence. Reasons:
+  - Migrate to the new code only needs minor change.
+  - The original code has critical problems, like performance or compatibility.
+- Make notes. Communication is important, even with the future you.
+  - *Why* this move is decided?
+  - *What* this new tool does?
+  - *How* this tool works?
+- Clean up code regularly. Don't keep the unused code forever.