refactor: перенести сборку в проекты

- перенесены каноны и VitePress-конфиги в projects/<slug>

- добавлены корневой и проектные build.ts для сборки артефактов

- добавлены shared-библиотеки сборки в projects/_shared/lib

- обновлены CI, Dockerfile, package.json, gitignore и README

- удалена сборка frontend-агента

projects/template-sync-strategy/canons/concepts/rules.md

@@ -0,0 +1,47 @@
+---
+title: Правила процесса
+description: Набор правил, который удерживает template чистой, а обновления шаблона контролируемыми.
+---
+
+# Правила процесса
+
+Небольшой набор правил удерживает схему чистой.
+
+## Делаем
+
+- `template` обновляем только из `templates/master`.
+- `sync/*` создаём от `origin/master`.
+- `origin/template` вливаем в `sync/*`, а не напрямую в `master`.
+- Конфликты решаем только в `sync/*`.
+- `sync/* -> master` вливаем через PR/MR.
+- Для sync-PR/MR отключаем squash.
+
+## Не делаем
+
+- Не правим `template` руками.
+- Не коммитим изменения приложения в `template`.
+- Не мержим `template -> master` напрямую.
+- Не решаем конфликты в `master`.
+- Не включаем squash для `sync/* -> master`.
+
+## Почему squash нельзя
+
+Squash может уничтожить нормальную связь истории `master` с историей `template`.
+
+Git использует историю, чтобы понимать, какие изменения шаблона уже были доставлены в приложение. Если результат обновления шаблона превратить в один squash-коммит, связь с исходными коммитами шаблона станет хуже или исчезнет.
+
+Для sync-PR/MR допустимы:
+
+```text
+fast-forward merge = хорошо
+merge commit       = допустимо
+squash merge       = нельзя
+```
+
+## Почему template нельзя пачкать
+
+`template` — эталонный слепок оригинального шаблона.
+
+Если в неё попадает локальное решение конфликта или изменение приложения, она перестаёт отвечать на вопрос: “какая версия шаблона сейчас подключена к приложению?”.
+
+После этого ломается главная граница ответственности: шаблон отдельно, приложение отдельно, конфликтная зона отдельно.