architecture-standards

star 6.8k

Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.

massCodeIO By massCodeIO schedule Updated 5/6/2026

name: architecture-standards description: Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.

Architecture Standards

Overview

Базовый принцип проекта: YAGNI и простота прежде всего. Не усложняй код ради гипотетических сценариев, не строй абстракции без повторяющейся потребности и не размывай границы между renderer, API и main.

Core Rules

  • Соблюдай разделение слоёв:
    • Renderer: только UI, composables, вызовы api.* и ipc.invoke(...).
    • API: маршруты Elysia, DTO, orchestration и доступ к сервисам и данным приложения.
    • Main: системные интеграции, IPC handlers, lifecycle и слой данных приложения.
  • Data flow по умолчанию: Renderer → API / IPC → service / data layer → response.
  • Vue-компоненты называй в PascalCase.
  • TypeScript-файлы называй в camelCase.
  • Composables именуй с префиксом use, а имя файла должно совпадать с экспортируемой функцией.

YAGNI Guardrails

Признаки overengineering:

  • функция страхуется от кейса, которого реально не существует;
  • factory или wrapper используется ровно в одном месте и не скрывает состояние;
  • abstraction-for-abstraction без повторяющейся боли;
  • константы, паттерны и конфигурации придуманы заранее, а не из реальной потребности.

Component Decomposition

  • Если компонент становится больше примерно 300 строк или держит 3+ несвязанных обязанности, дели его.
  • Порядок разбиения:
    1. вынеси константы и статические данные;
    2. вынеси чистые функции в utils, только если это реально переиспользуется;
    3. перемести состояние и эффекты в composable;
    4. разбей шаблон на локальные child components.
  • Не держи в <template> логику сложнее тернарного оператора.

Feature Subdirectories

  • Если часть домена выросла в отдельный subsystem, группируй локальные компоненты, helpers, tests и fixtures в поддиректорию.
  • Внутри поддиректории не повторяй полный родительский префикс в именах файлов.
  • Локальные файлы держи рядом с фичей. Shared-код, который нужен нескольким областям, оставляй выше уровнем.

When to Load Other Skills

  • Vue renderer, auto-imports, composables, shared state: vue-renderer-standards
  • визуальная база, typography, renderer styling decisions: ui-foundations
  • Ui*, Shadcn, cn, cva, notifications: ui-primitives
  • API routes, DTO, IPC, Electron boundaries: electron-api-and-ipc
  • generated API types, utility typing, локальные view-model: api-and-typing
  • code / notes / math / tools, состояние spaces и их синхронизация: spaces-architecture
  • i18n, locale keys, i18n.t(...): i18n
  • docs website, docs sidebar, скриншоты, README-упоминания фич: documentation-workflow
  • scoped lint/test и follow-up commands: development-workflow

Common Mistakes

  • Тянуть DB или filesystem knowledge в renderer.
  • Раздувать один компонент до “оркестратора всего”.
  • Выносить абстракцию до появления второй реальной точки использования.
  • Размазывать одну фичу по плоской структуре файлов, когда ей уже нужен локальный subdirectory.
  • Придумывать локальные typing-паттерны, хотя для них уже пора иметь отдельный skill.
Install via CLI
npx skills add https://github.com/massCodeIO/massCode --skill architecture-standards
Repository Details
star Stars 6,837
call_split Forks 258
navigation Branch main
article Path SKILL.md
More from Creator