refactor(server-runtime): split modules

2026-05-05 02:30:45 +08:00
parent 40284514d4
commit 8a88d233f2
8 changed files with 1695 additions and 710 deletions
@@ -145,6 +145,10 @@ Concise but detailed reference for contributors working across the `moeru-ai/air
 ## Naming & Comments

 - File names: kebab-case.
+- Prefer names that rely on the module boundary for context instead of repeating package, product, protocol, or transport prefixes inside every symbol. A well-named module should let exported functions use short action-first names; repeat the larger context only when the symbol crosses a boundary where that context is no longer obvious.
+- Name functions after the domain operation they perform, not after the implementation layer that happens to contain them. This keeps call sites readable after refactors and avoids names becoming stale when code moves between files.
+- Avoid names that encode multiple layers of ownership into one symbol. If a name needs several qualifiers to be understandable, reconsider the module boundary or introduce a clearer local concept.
+- Use nouns for resolved domain concepts and verbs for transformations or side effects. When a function derives a policy/configuration from an event or request, name the domain result explicitly so callers understand what decision is being made.
 - Avoid classes unless extending runtime/browser APIs; FP + DI is easier to test/mock.
 - Add clear, concise comments for utils, math, OS-interaction, algorithm, shared, and architectural functions that explain what the function does.
 - When using a workaround, add a `// NOTICE:` comment explaining why, the root cause, and any source context. If validated via `node_modules` inspection or external sources (e.g., GitHub), include relevant line references and links in code-formatted text.