Книга Восьмая. Цифровая инфраструктура v1.1

Скачать оригинал Word

КНИГА УПРАВЛЕНИЯ

АНБО «ДОМ ТЫСЯЧИ СЕРДЕЦ»

Книга Восьмая

ЦИФРОВАЯ ИНФРАСТРУКТУРА

Архитектура · Данные · Доступы · Админка · Безопасность · Восстановление

Редакция v1.0

пгт Ахтырский · 2026

Сведения об издании

Книга Восьмая описывает цифровую инфраструктуру Дома как управляемую систему: публичный сайт, административный интерфейс, данные, файлы, домены, репозитории, доступы, резервирование, безопасность и порядок развития. Книга превращает технические решения в понятную организационную память и сохраняет возможность переноса системы между платформами.

Параметр	Содержание
Полное название	Книга управления АНБО «Дом тысячи сердец». Книга Восьмая. Цифровая инфраструктура
Версия	v1.0
Дата редакции	23 июля 2026 года
Статус	Рабочая архитектурная редакция. Конкретные настройки, тарифы и возможности внешних платформ сверяются перед внедрением.
Владелец документа	АНБО «Дом тысячи сердец»
Основной хранитель	Президент Организации либо назначенный хранитель цифровой инфраструктуры
Периодичность пересмотра	Ежеквартально по карте инфраструктуры; немедленно после значимого инцидента, миграции или изменения архитектуры
Связанные Книги	Книга Первая. Дом; Книга Вторая. Организация; Книга Четвёртая. Животные; Книга Пятая. Финансы; Книга Девятая. Непрерывность деятельности
Целевая архитектура	Netlify как публичный фасад, сборка, preview и шлюз; PostgreSQL как единый источник истины; Supabase как референсное серверное ядро для базы, авторизации и файлов с обязательной производственной проверкой локализации и правового режима данных.

СТАТУС АРХИТЕКТУРЫ

Книга фиксирует направление и правила. Внешние сервисы развиваются, поэтому перед каждым производственным запуском проверяются актуальная документация, условия размещения данных, стоимость, ограничения и возможность экспорта.

Редакционная группа

Роль	Лицо / орган	Зона ответственности
Смысловой владелец	Совет учредителей	Сохранение целей, контроль критических зависимостей и решений, влияющих на устойчивость Организации.
Исполнительный владелец	Президент Тумилович Софья Маратовна	Утверждение правил доступа, владельцев систем, публичных материалов и производственных запусков.
Хранитель архитектуры	Тумилович Максимилиан Юлианович	Архитектура сайта, данных и админки; документация, сборки, миграции, визуальная и продуктовая логика.
Учредитель и резервный контролёр	Глушкова Юлия Алексеевна	Коллегиальная проверка критических доступов, восстановления, передачи дел и соответствия целям.

Реквизиты Организации

Поле	Значение
Полное наименование	Автономная некоммерческая благотворительная организация помощи бездомным животным «Дом тысячи сердец»
Сокращённое наименование	АНБО «Дом тысячи сердец»
ОГРН	1262300028253
ИНН / КПП	2304088233 / 230401001
Дата государственной регистрации	07.07.2026
Адрес	353300, Краснодарский край, Абинский муниципальный район, Ахтырское городское поселение, пгт Ахтырский, ул. Азарова, д. 59
Президент	Тумилович Софья Маратовна
Сайт	1000heartshome.ru
Почты	president@1000heartshome.ru; partners@1000heartshome.ru; info@1000heartshome.ru; docs@1000heartshome.ru; help@1000heartshome.ru

Журнал редакций

Версия	Дата	Статус	Содержание изменений	Ответственный
v1.0	23.07.2026	Базовая рабочая редакция	Создана полная Книга Восьмая: целевая архитектура, домены, код, среды, данные, админка, контент, Библиотека, роли, файлы, API, безопасность, персональные данные, резервирование, мониторинг, масштабирование и приложения.	АНБО «Дом тысячи сердец»
v1.1	После запуска первой административной версии	Актуализация	Фактические схемы базы, политики доступа, адреса сред, результаты резервного восстановления и инструкция редакторов.	Президент / хранитель архитектуры
v2.0	После появления кабинетов или Точек Дома	Крупная редакция	Пересмотр архитектуры пользователей, географии, медицинских данных, партнёрских доступов и постоянного серверного контура.	Совет учредителей

Архитектурное решение v1.0

Проект сохраняет Netlify как публичный фасад и систему публикации. Данные, авторизация и файлы проектируются как самостоятельный переносимый слой на стандартном PostgreSQL. Supabase используется как референсная реализация серверного ядра, а производственное размещение данных проходит отдельный правовой и технический допуск.

Слой	Решение v1.0	Причина
Публичный сайт	Netlify	Быстрая раздача, preview-сборки, история публикаций и откат.
Админ-интерфейс	admin.1000heartshome.ru на том же фронтенд-стеке	Отделение внутренней работы от художественного публичного интерфейса.
Серверный шлюз	Netlify Functions либо совместимый API-слой	Проверка прав, интеграции, защищённая выдача файлов и сохранение серверных секретов.
Данные	PostgreSQL	Стандартная реляционная модель, связи, миграции, экспорт и переносимость.
Референсное ядро	Supabase Database + Auth + Storage + RLS	Быстрый запуск базы, пользователей, файлов и политик доступа.
Публичная медиатека будущего	S3-совместимое хранилище, при росте возможно Cloudflare R2 или российский аналог	Отделение большого объёма файлов от базы и фронтенда.
Юридический шлюз	Отдельный производственный допуск	Персональные и чувствительные данные размещаются только после проверки требований и выбранной юрисдикции.

ФОРМУЛА НЕЗАВИСИМОСТИ

Дом использует удобные платформы, сохраняя данные, схему, файлы, домены и учётные записи в форме, которую можно перенести.

Карта серии

Книга	Предмет	Связь с цифровой инфраструктурой	Статус
Первая. Дом	Миссия, культура, память	Определяет смысл данных, открытости и Библиотеки Дома.	Создана, v1.1
Вторая. Организация	Органы, решения, документы	Устанавливает полномочия, реестры, уровни доступа и документирование.	Создана, v1.1
Третья. Люди	Роли, безопасность и развитие	Детализирует цифровое включение людей и завершение доступа.	Паспорт серии
Четвёртая. Животные	Приём, медицина, социализация	Формирует профиль животного, связанные записи и карточки сайта.	Создана, v1.0
Пятая. Финансы	Пожертвования, расходы и отчётность	Определяет финансовые данные, доказательства и интеграции.	Создана, v1.0
Шестая. Партнёры	Сотрудничество и проекты	Использует партнёрские кабинеты, документы и ограниченные полки.	Паспорт серии
Седьмая. Имущество	Учёт и эксплуатация	Получает цифровой реестр имущества, запасов и оборудования.	Паспорт серии
Восьмая. Цифровая инфраструктура	Домены, сайт, данные, доступы и безопасность	Текущая Книга.	Настоящая редакция
Девятая. Непрерывность деятельности	Кризисы и восстановление	Задаёт приоритеты восстановления сервисов и данных.	Создана, v1.0
Десятая. Летопись Дома	Хронология и память	Получает устойчивые цифровые записи и архив редакций.	Ведётся постоянно

Как пользоваться Книгой

Книга работает как архитектурная карта, эксплуатационная инструкция и паспорт решений. При создании нового модуля сначала определяется его место в общей модели, затем данные, роли, интерфейс, резервирование и порядок передачи владельцу.

Рабочий маршрут

Контроль

☐ Определить задачу и владельца процесса.

☐ Проверить, существует ли соответствующая сущность данных.

☐ Определить публичный, внутренний или ограниченный уровень.

☐ Назначить роли чтения, изменения, публикации и удаления.

☐ Выбрать место хранения данных и файлов.

☐ Создать миграцию, форму админки и журнал изменений.

☐ Проверить preview-версию до публикации.

☐ Проверить резервное копирование и экспорт.

☐ Обновить реестр систем и связанную Книгу.

ГЛАВНЫЙ ПРИНЦИП

Контент меняется через понятный интерфейс. Код меняется через репозиторий. Доступ выдаётся по роли. Данные остаются переносимыми.

Предисловие. Цифровой Дом как продолжение заботы

Цифровая инфраструктура Дома хранит живую работу: сведения о животных, истории, потребности, документы, фотографии, решения, отчёты и пути участия. Её качество измеряется тем, насколько легко человек может выполнить правильное действие и насколько устойчиво Организация сохраняет результат.

Сайт начинался как художественный Дом-навигация. По мере роста он становится рабочей системой: каталогом животных, Библиотекой, Базой спасения, витриной партнёрств, редакцией новостей и будущим местом личных кабинетов. Такая система нуждается в архитектуре, которая выдерживает изменение контента без постоянной ручной пересборки кода.

Книга закрепляет разделение ответственности. Публичный интерфейс создаёт понятный опыт. Админка позволяет управлять содержанием. База хранит единственную актуальную запись. Серверный слой проверяет права. Репозиторий сохраняет код. Резервные копии сохраняют возможность восстановления. Организационные владельцы сохраняют контроль над всем контуром.

«Цифровая система служит Дому, когда она помогает быстрее заботиться, точнее помнить и спокойнее передавать работу.»

ДОКУМЕНТАЛЬНАЯ ОПОРА

Книга Первая. Дом · Книга Вторая. Организация · Книга Четвёртая. Животные · Книга Девятая. Непрерывность деятельности · стратегия экосистемы v0.9 · брендбук v9.2 · рабочее решение по Netlify, PostgreSQL и административному интерфейсу

1	ГЛАВА 1 Принципы цифровой инфраструктуры Смысл, границы, зрелость и практическая ценность «Инфраструктура ценна ровно настолько, насколько она сохраняет жизнь, память и способность действовать.»

Глава 1. Принципы цифровой инфраструктуры

1.1. Инфраструктура как система заботы

Цифровой контур соединяет людей, процессы и память. Он сокращает время поиска сведений, помогает видеть актуальные потребности, сохраняет историю решений и поддерживает доверие через проверяемые публикации.

КОРОТКАЯ ФОРМУЛА

Цифровая ценность = точные данные + понятное действие + сохранённый результат.

1.2. Семь принципов

Принцип	Практическое выражение
Единый источник истины	Каждый факт имеет основную запись, а интерфейсы показывают её представления.
Разделение слоёв	Интерфейс, данные, файлы, права и интеграции развиваются отдельно.
Переносимость	Схема, данные и файлы можно экспортировать и развернуть в другом контуре.
Минимальные полномочия	Пользователь получает только тот доступ, который нужен его роли.
История изменений	Значимое изменение имеет автора, время, основание и возможность восстановления.
Безопасная публикация	Черновик, preview, проверка и публикация образуют обязательный маршрут.
Живое развитие	Архитектура усложняется после появления реальной потребности.

1.3. Инфраструктурная достаточность

Дом выбирает решение, которое закрывает текущую задачу и сохраняет путь роста. Простая функция остаётся простой. Критические данные получают дополнительную защиту, резервирование и контроль доступа.

1.4. Публичное и внутреннее

Публичный сайт показывает утверждённые материалы. Административный контур хранит черновики, статусы и рабочие связи. Закрытые документы выдаются после проверки права доступа. Секреты и персональные данные остаются вне клиентского кода и публичной сборки.

1.5. Признаки зрелости

Контроль

☐ Система имеет владельца.

☐ Данные имеют модель и словарь.

☐ Доступы выдаются по ролям.

☐ Изменения проходят preview и проверку.

☐ Есть журнал действий.

☐ Резервная копия проверена восстановлением.

☐ Переезд описывается последовательностью действий, а не переписыванием всего проекта.

2	ГЛАВА 2 Целевая архитектура Дома Netlify, переносимое серверное ядро и собственный слой данных «Фасад может быть лёгким, когда фундамент хранит порядок.»

Глава 2. Целевая архитектура Дома

2.1. Публичный фасад

Netlify обслуживает публичный сайт, сборки, preview-версии, откаты и серверные функции. Этот слой отвечает за скорость доставки интерфейса и безопасный выпуск изменений кода.

2.2. Серверное ядро

PostgreSQL хранит структурированные данные. Авторизация, файловое хранилище и политики доступа объединяются вокруг базы. Supabase рассматривается как референсный способ быстро собрать этот контур, сохраняя стандартную основу PostgreSQL.

2.3. Собственный слой данных

Компоненты сайта обращаются к сервисному слою Дома: функциям, запросам и типам данных, описанным в репозитории. Это снижает зависимость интерфейса от особенностей конкретного провайдера и упрощает перенос.

2.4. Архитектурная схема

Участник / слой	Компонент	Функция
Посетитель	Netlify CDN	Публичные страницы и опубликованные данные.
Редактор	admin.1000heartshome.ru	Формы, списки, preview и публикация.
Фронтенд	Слой данных Дома	Единые функции чтения и изменения.
Серверный шлюз	Functions / API	Проверка прав, секреты, интеграции, закрытые файлы.
Серверное ядро	PostgreSQL + Auth + Storage	Данные, пользователи, политики и файлы.
Архив	Резервные копии и экспорт	Восстановление, проверка и перенос.

2.5. Архитектурные ворота

Контроль

☐ Платформа поддерживает экспорт данных.

☐ Файлы можно выгрузить массово.

☐ Схема хранится в миграциях.

☐ Секреты отделены от кода.

☐ Права проверяются сервером и базой.

☐ Производственное размещение данных прошло правовую проверку.

☐ Стоимость и лимиты понятны владельцу Организации.

ДОКУМЕНТАЛЬНАЯ ОПОРА

Рабочее инфраструктурное решение от 23.07.2026 · официальная документация Netlify, Supabase, PostgreSQL и выбранного файлового хранилища

3	ГЛАВА 3 Владение, управление и ответственность Аккаунты Организации, владельцы систем и разделение критических функций «Дом владеет своей цифровой памятью, а люди получают полномочия на определённый срок.»

Глава 3. Владение, управление и ответственность

3.1. Организационное владение

Домены, репозитории, проекты хостинга, база, хранилище, почта и платёжные интеграции создаются на учётные записи, контролируемые Организацией. Личный аккаунт может участвовать как технический пользователь, но не остаётся единственной точкой владения.

3.2. Роли управления

Роль	Ответственность
Владелец системы	Утверждает назначение, уровень критичности, бюджет и правила доступа.
Хранитель архитектуры	Поддерживает схему, репозиторий, миграции и документацию.
Администратор	Управляет пользователями, настройками и восстановлением.
Редактор	Ведёт контент в пределах модуля.
Специалист	Меняет профильные поля, например медицинские сведения.
Наблюдатель	Просматривает рабочие данные без изменения.
Резервный администратор	Принимает управление при недоступности основного.

3.3. Разделение критических функций

Публикация юридического документа, изменение прав, удаление большого массива данных, смена владельца домена и восстановление из резервной копии получают дополнительную проверку. Для наиболее критических действий применяется принцип двух участников.

3.4. Ввод и вывод человека

Доступ начинается с заявки, роли, срока и подтверждения правил. Завершение участия запускает отзыв сессий, ключей, приглашений, прав на репозиторий и внешние сервисы. Служебные материалы остаются в собственности Организации.

3.5. Ежеквартальная сверка

Контроль

☐ Проверены владельцы всех аккаунтов.

☐ Актуальны резервные контакты.

☐ Удалены лишние пользователи.

☐ Проверены права администраторов.

☐ Действует двухфакторная защита.

☐ Обновлён реестр сервисов и стоимости.

☐ Проверен экспорт критических данных.

4	ГЛАВА 4 Домены, DNS и публичные адреса Имена Дома, маршрутизация и безопасные изменения «Домен связывает доверие, память и технический маршрут в одно устойчивое имя.»

Глава 4. Домены, DNS и публичные адреса

4.1. Главный домен

Основным публичным адресом является 1000heartshome.ru. Он принадлежит Организации и направляет пользователей на утверждённую производственную версию сайта. Доступ к регистратору и DNS хранится в защищённом контуре с резервным владельцем.

4.2. Карта поддоменов

Адрес	Назначение
www.1000heartshome.ru	Публичный сайт или перенаправление на основной домен.
admin.1000heartshome.ru	Закрытый Пульт Дома.
api.1000heartshome.ru	Будущий самостоятельный API при появлении постоянного серверного слоя.
docs.1000heartshome.ru	Возможный технический адрес публичной документации или Библиотеки.
status.1000heartshome.ru	Будущая страница состояния сервисов.
preview.*	Временные среды проверки, не индексируемые поиском.

4.3. DNS как критическая система

Каждая запись имеет назначение, владельца, дату изменения и основание. Изменение DNS выполняется по заявке, после проверки текущего состояния и с готовым планом возврата.

4.4. Почта и доверие

Служебные адреса Организации связываются с доменом и используются по назначению: управление, партнёры, документы, общие обращения и помощь. Настройки отправки защищаются записями аутентификации домена и периодически проверяются.

4.5. Контроль домена

Контроль

☐ Автопродление включено.

☐ Контакт владельца актуален.

☐ Доступ имеет резервный администратор.

☐ Коды восстановления хранятся отдельно.

☐ DNS экспортирован или задокументирован.

☐ Сертификат HTTPS действует.

☐ Изменения домена фиксируются в журнале.

5	ГЛАВА 5 Репозитории, код и история изменений Git, ветки, ревью, документация и воспроизводимость «Код становится памятью, когда каждое изменение можно понять, проверить и повторить.»

Глава 5. Репозитории, код и история изменений

5.1. Основной репозиторий

Исходный код хранится в закрытом Git-репозитории Организации. Репозиторий содержит приложение, конфигурацию, миграции базы, схемы данных, тесты, инструкции запуска и документацию архитектурных решений.

5.2. Модель веток

Ветка	Назначение
main	Производственная линия. Каждое состояние готово к публикации или откату.
develop / integration	Объединение крупных изменений перед выпуском, если оно действительно нужно.
feature/*	Отдельная функция или модуль.
fix/*	Исправление дефекта.
content-schema/*	Изменение модели контента и миграций.
hotfix/*	Срочное производственное исправление с коротким маршрутом проверки.

5.3. Коммит и запрос на изменение

Коммит описывает одно понятное изменение. Запрос на слияние показывает цель, затронутые модули, миграции, способ проверки, снимки интерфейса и риски. Preview-версия позволяет увидеть результат до выпуска.

5.4. Архитектурные решения

Крупное решение получает короткую запись ADR: контекст, выбранный вариант, альтернативы, последствия и дата пересмотра. Это сохраняет причины, которые код сам по себе объяснить не умеет.

5.5. Готовность репозитория

Контроль

☐ README позволяет запустить проект.

☐ Зависимости зафиксированы.

☐ Миграции применяются последовательно.

☐ Секреты отсутствуют в истории Git.

☐ Лицензии ассетов и шрифтов учтены.

☐ Сборка проходит автоматически.

☐ Владение репозиторием принадлежит Организации.

6	ГЛАВА 6 Среды, публикация и откат Разработка, preview, производство и безопасный выпуск «Новая версия сначала доказывает готовность, затем получает право стать Домом для посетителей.»

Глава 6. Среды, публикация и откат

6.1. Четыре состояния

Среда	Назначение
Локальная среда	Разработка и проверка на компьютере. Использует тестовые данные.
Preview	Автоматическая версия конкретного изменения для визуальной и функциональной проверки.
Staging	Стабильная предрелизная среда при появлении сложных интеграций.
Production	Публичная утверждённая система с реальными данными и доменом.

6.2. Разделение данных

Тестовые среды не получают производственные персональные данные и секреты. Для preview используются обезличенные наборы, отдельные ветки базы или безопасные фикстуры.

6.3. Маршрут выпуска

Изменение проходит автоматическую сборку, проверку типов, тесты, preview, визуальный просмотр и подтверждение владельца модуля. Миграция базы и публикация интерфейса выполняются как согласованный выпуск.

6.4. Откат

Каждый выпуск имеет известную предыдущую версию. При дефекте интерфейс откатывается на проверенный deploy, а изменения базы возвращаются предусмотренной миграцией либо исправляются новой безопасной миграцией.

6.5. Чек выпуска

Контроль

☐ Preview открыт на компьютере и телефоне.

☐ Проверены День и Ночь.

☐ Проверены формы и права.

☐ Миграция протестирована на копии данных.

☐ Секреты настроены в среде.

☐ Есть план отката.

☐ После выпуска проверены ключевые маршруты.

7	ГЛАВА 7 Данные и PostgreSQL Схема, миграции, качество и жизненный цикл записи «База хранит не страницы сайта, а устойчивые факты и связи Дома.»

Глава 7. Данные и PostgreSQL

7.1. PostgreSQL как основа

Реляционная база подходит Дому, потому что сущности связаны: животное имеет фотографии, истории, медицинские сведения, потребности и статусы; документ имеет версии, доступы и связи; партнёр участвует в проектах. Стандарт PostgreSQL сохраняет возможность переноса.

7.2. Схема в миграциях

Каждое изменение таблиц, индексов, ограничений и политик хранится как версионируемая миграция. Новую базу можно развернуть из последовательности миграций и проверенного набора начальных данных.

7.3. Качество данных

Качество	Механизм
Уникальность	Служебные идентификаторы и адреса записей не дублируются.
Обязательность	Критические поля требуют заполнения.
Связность	Ссылки ведут на существующие сущности.
Справочники	Статусы и категории выбираются из управляемых наборов.
Временные метки	Создание, изменение и публикация фиксируются автоматически.
Авторство	Изменение связывается с пользователем или системной операцией.

7.4. Мягкое удаление и архив

Крестик в интерфейсе переводит запись в архив, когда сохранение истории имеет ценность. Физическое удаление применяется по утверждённому правилу, после проверки связей, сроков хранения и резервной копии.

7.5. Минимальная готовность

Контроль

☐ У каждой таблицы есть назначение.

☐ Поля описаны в словаре.

☐ Индексы поддерживают основные запросы.

☐ Политики доступа включены.

☐ Миграции хранятся в Git.

☐ Экспорт протестирован.

☐ Резервное восстановление проверено.

8	ГЛАВА 8 Модель сущностей и единый источник истины Животные, публикации, нужды, документы, товары и связи «Один факт хранится один раз и появляется там, где он нужен.»

Глава 8. Модель сущностей и единый источник истины

8.1. Основные сущности

Сущность	Что хранит
Животное	Профиль, состояние, характер, статус, локализация, публикация.
Медиа	Фотография, видео, документ, обложка, производные версии.
Публикация	История, новость, памятка, отчёт, анонс.
Потребность	Позиция блока «Что нужно сейчас», категория, срочность и статус.
Документ	Материал Библиотеки, версия, полка, уровень доступа.
Товар	Продукт Лаборатории, партнёрская подборка или внешний товар.
Пользователь	Учётная запись, роль, статус и срок доступа.
Партнёр / проект	Организация, контактный контур, проект и связанные материалы.

8.2. Представления вместо копий

«Животное дня» хранит ссылку на профиль и отдельную подпись для периода показа. История связывается с животным, а карточка животного показывает эту историю автоматически. Библиотечная полка показывает документы по уровню и статусу.

8.3. Статусы как процесс

Статус выражает реальное состояние и управляет интерфейсом. Черновик доступен редакторам. Материал на проверке ожидает подтверждения. Опубликованная версия видна посетителям. Архив сохраняет историю. Ограниченный материал требует роли.

8.4. Справочники

Вид животного, пол, возрастная группа, статус пристройства, категория нужды, тип публикации, полка, доступ и тип товара хранятся в справочниках. Их изменение проходит проверку влияния на фильтры и отчёты.

8.5. Проверка модели

Контроль

☐ Факт не дублируется в нескольких таблицах без причины.

☐ Связь имеет понятное направление.

☐ Статус управляет реальным процессом.

☐ Архив не смешивается с опубликованными данными.

☐ Поле имеет владельца и источник.

☐ Публичное представление отделено от внутренней записи.

9	ГЛАВА 9 Пульт Дома: административный интерфейс Редакционная работа без правки кода «Управление контентом становится обычной работой, а не маленьким ритуалом развертывания.»

Глава 9. Пульт Дома: административный интерфейс

9.1. Назначение

Пульт Дома позволяет добавлять, обновлять, проверять, публиковать и архивировать данные через формы и списки. Изменение содержания не требует изменения кода и полной пересборки интерфейса.

9.2. Принципы интерфейса

Принцип	Проявление
Ясная роль	Пользователь видит только доступные модули и действия.
Сохранение черновика	Работа не теряется и не публикуется случайно.
Проверка	Критические поля и ошибки показаны до публикации.
История	Можно увидеть автора, время и предыдущее значение.
Безопасное удаление	Запись архивируется и восстанавливается.
Массовые действия	Экспорт, фильтры и изменение статусов доступны там, где это безопасно.
Мобильная пригодность	Срочную потребность или статус можно обновить с телефона.

9.3. Навигация Пульта

Главная панель показывает задачи проверки, неопубликованные изменения, срочные потребности, материалы с истёкшей актуальностью, ошибки интеграций и состояние резервного копирования. Модули следуют предметным областям Дома.

9.4. Редакторские гарантии

Форма объясняет смысл поля, формат и место отображения. Предпросмотр показывает результат в дневной и ночной версии. Публикация требует подтверждения, если меняются реквизиты, юридический документ или закрытый уровень.

9.5. Готовность модуля

Контроль

☐ Есть список и поиск.

☐ Есть создание и редактирование.

☐ Есть черновик и публикация.

☐ Есть архив и восстановление.

☐ Есть история изменений.

☐ Есть права по ролям.

☐ Есть экспорт.

☐ Есть мобильная проверка.

10	ГЛАВА 10 Контентные модули Потребности, животные, публикации, товары и редакционный ритм «Каждый раздел получает собственную форму, сохраняя общую грамматику данных.»

Глава 10. Контентные модули

10.1. Что нужно сейчас

Модуль хранит название позиции, категорию, количество или сумму, срочность, комментарий, порядок, видимость и статус. Закрытая потребность может временно показываться как результат помощи, затем переходить в архив.

10.2. Каталог животных

Профиль включает служебный ID, вид, пол, возраст, размер, статусы, характер, совместимость, здоровье, стерилизацию, вакцинацию, особенности ухода, тексты, языковые версии, медиагалерею, кураторство и готовность к международному маршруту.

10.3. Животное дня

Редактор выбирает профиль, период, отдельную подпись и режим показа. Автоматическая ротация может работать по утверждённому набору животных. Все основные сведения продолжают поступать из каталога.

10.4. Истории и новости

Публикация имеет заголовок, анонс, основной текст, обложку, галерею, рубрику, связанные сущности, дату, SEO-поля, статус, закрепление и время отложенной публикации.

10.5. Товары и Лаборатория

Тип	Данные и статус
Собственный продукт	Концепция, прототип, статус, характеристики, изображения, производство.
Партнёрский товар	Поставщик, условия, ссылка, раскрытие партнёрского характера.
Сценарная подборка	Связь с Базой спасения, животным или видом ухода.
Внешняя площадка	Ozon, Wildberries или официальный ресурс партнёра.
Публикация	Черновик, тестирование, доступно, временно скрыто, архив.

10.6. Редакционная проверка

Контроль

☐ Текст соответствует фактам.

☐ Статус и дата актуальны.

☐ Фотографии имеют права и подписи.

☐ Связанные животные выбраны верно.

☐ Закрытые сведения отсутствуют в публичном поле.

☐ Предпросмотр проверен в двух темах.

☐ После публикации открыта реальная страница.

11	ГЛАВА 11 Библиотека Дома и защищённые полки Версии, доступ, выдача файлов и связь с культурным разделом «Библиотека показывает масштаб знания и бережно различает открытость и доверенный доступ.»

Глава 11. Библиотека Дома и защищённые полки

11.1. Карточка материала

Материал хранит название, тип, полку, версию, дату редакции, автора или владельца, статус, аннотацию, обложку, файл, уровень доступа, предыдущие редакции и связи.

11.2. Уровни доступа

Уровень	Пример содержания
Публичный	Открытая полка, документы прозрачности, публичные Книги и памятки.
Партнёрский	Стандарты сотрудничества, рабочие материалы проектов и документы партнёра.
Добровольческий	Инструкции, обучение и рабочие памятки.
Внутренний	Процессы команды, реестры и непубличные рабочие версии.
Совет / Президент	Управленческие материалы с наиболее ограниченным доступом.

11.3. Видимые закрытые полки

Публичный интерфейс может показывать решётку, название полки и безопасные корешки материалов. Файл физически отсутствует в публичной сборке. Нажатие ведёт к входу, приглашению или описанию порядка получения доступа.

11.4. Выдача файла

Сервер проверяет пользователя, роль, статус документа и право на конкретный материал. После проверки создаётся временная ссылка либо файл передаётся через защищённый маршрут. Событие записывается в журнал.

11.5. Версии и архив

Новая редакция не заменяет историческую бесследно. Публичная карточка ведёт на действующую версию, а архив хранит дату, статус, основание и связь с предыдущей редакцией.

11.6. Связь с «Под крышей»

Библиотека хранит карточку источника, права, аннотацию и связи. «Под крышей» раскрывает культурный смысл через художественный опыт. Два раздела соединяются взаимными ссылками, сохраняя самостоятельные роли.

12	ГЛАВА 12 Пользователи, роли и политики доступа Auth, RLS, приглашения и завершение полномочий «Доступ следует за ответственностью и прекращается вместе с ней.»

Глава 12. Пользователи, роли и политики доступа

12.1. Аутентификация и авторизация

Аутентификация подтверждает пользователя. Авторизация определяет доступное действие. Серверный слой и база проверяют полномочия независимо от того, какие элементы показаны в интерфейсе.

12.2. Базовые роли

Роль	Граница
Администратор	Настройки, пользователи, роли, восстановление и все модули.
Редактор	Животные, потребности, истории, новости и товары.
Специалист	Определённые профильные поля и записи.
Библиотекарь	Документы, версии, полки и публикация Библиотеки.
Партнёр	Только материалы и проекты, связанные с его доступом.
Доброволец	Рабочие инструкции и назначенные задачи.
Наблюдатель	Чтение разрешённых рабочих данных без изменения.

12.3. Row Level Security

Политики уровня строк связывают запись с её доступом, организацией, проектом, владельцем или статусом. Публичный пользователь получает только опубликованные записи. Редактор меняет разрешённые сущности. Партнёр видит материалы своего проекта.

12.4. Приглашения и сессии

Аккаунты создаются по приглашению. Срок доступа, роль и владелец указываются заранее. Администратор видит активные сессии, может отозвать доступ и потребовать повторный вход. Для критических ролей используется второй фактор.

12.5. Проверка политики

Контроль

☐ RLS включена для доступных приложению таблиц.

☐ Публичная роль получает только опубликованные поля.

☐ Сервисный ключ отсутствует в браузере.

☐ Партнёрский доступ проверен отдельным тестовым аккаунтом.

☐ Удалённый пользователь теряет доступ сразу.

☐ Администраторские действия журналируются.

☐ Политика описана человеческим языком.

13	ГЛАВА 13 Файлы, изображения и медиатека Оригиналы, производные версии, метаданные и права «Файл становится частью памяти после того, как получает имя, происхождение, связь и правила доступа.»

Глава 13. Файлы, изображения и медиатека

13.1. Объектное хранение

Фотографии, видео, PDF, обложки и архивы хранятся отдельно от строк базы. База содержит идентификатор объекта, путь, тип, размер, контрольную сумму, доступ, автора, права и связи.

13.2. Оригинал и производные

Оригинал сохраняется неизменным. Для сайта создаются оптимизированные версии: обложка, карточка, полноэкранное изображение, WebP или AVIF. Производная версия всегда знает свой оригинал и параметры обработки.

13.3. Имена и пути

Путь	Назначение
animals/{animal-id}/originals	Оригинальные материалы животного.
animals/{animal-id}/web	Оптимизированные версии сайта.
library/{document-id}/{version}	Файлы редакций Библиотеки.
posts/{post-id}	Обложки и галереи публикации.
products/{product-id}	Материалы товара и прототипа.
private/{scope}	Закрытые объекты с серверной выдачей.

13.4. Права и происхождение

Каждый внешний материал получает источник, автора, основание использования и ограничения. Материалы животных проверяются на допустимость публикации, персональные сведения и безопасность точной локации.

13.5. Медиагигиена

Контроль

☐ Оригинал сохранён.

☐ Поворот и цвет проверены.

☐ Размер оптимизирован.

☐ Альтернативный текст заполнен.

☐ Источник и права указаны.

☐ Точная локация и метаданные удалены при необходимости.

☐ Закрытый файл находится вне публичного контейнера.

14	ГЛАВА 14 API, функции и интеграции Шлюзы, контракты, секреты и внешние сервисы «Интеграция остаётся надёжной, когда её границы и отказ понятны заранее.»

Глава 14. API, функции и интеграции

14.1. API Дома

API предоставляет устойчивые маршруты чтения и изменения. Каждый маршрут имеет назначение, метод, входные данные, результат, роль, ограничения и журналирование. Версия контракта меняется управляемо.

14.2. Серверные функции

Функции выполняют операции, которые требуют секрета или доверенной проверки: отправка почты, создание временной ссылки, обработка платежного уведомления, формирование экспорта, проверка роли и взаимодействие с внешним сервисом.

14.3. Интеграционный каталог

Интеграция	Функция
Электронная почта	Приглашения, уведомления, служебные сообщения.
Платежи	Пожертвования, статусы, чеки и сверка.
Социальные сети	Публикация и ссылки без передачи избыточных данных.
Карты и география	Примерная локация и будущие Точки Дома.
Аналитика	Обезличенные события и воронки.
Хранилище	Медиа, закрытые документы и временные ссылки.
Резервирование	Экспорт базы и файлов во второй контур.

14.4. Идемпотентность и повторы

Операция, которую внешний сервис может отправить повторно, имеет уникальный идентификатор и безопасно распознаёт дубликат. Ошибка записывается, повтор запускается управляемо, а критический сбой получает уведомление.

14.5. Паспорт интеграции

Контроль

☐ Есть владелец.

☐ Известны передаваемые данные.

☐ Секрет хранится в среде.

☐ Права минимальны.

☐ Есть тестовая среда.

☐ Описан отказ и повтор.

☐ Есть способ отключения и удаления данных.

15	ГЛАВА 15 Безопасность, секреты и устройства Практическая защита без театра сложности «Безопасность начинается с владения, минимальных прав и способности быстро восстановить контроль.»

Глава 15. Безопасность, секреты и устройства

15.1. Модель угроз

Дом учитывает потерю телефона, компрометацию почты, утечку токена, ошибочную публикацию, вредоносный файл, массовое удаление и захват домена. Защита строится вокруг наиболее вероятных и наиболее тяжёлых последствий.

15.2. Секреты

Пароли, ключи API, сервисные токены и коды восстановления хранятся в менеджере секретов или защищённом организационном хранилище. Они не появляются в коде, документах общего доступа, скриншотах и чатах.

15.3. Устройства

Устройство с административным доступом защищается блокировкой, обновлениями, шифрованием, отдельным профилем браузера и возможностью удалённого завершения сессий. Потеря устройства запускает готовый чек-лист.

15.4. Защита публикации

Пользовательский ввод очищается и проверяется. Загрузка ограничивает тип и размер файла. Юридические документы и реквизиты получают дополнительное подтверждение. Публичные страницы не раскрывают внутренние идентификаторы, секретные пути и точные адреса животных.

15.5. Минимум безопасности

Контроль

☐ Второй фактор включён у администраторов.

☐ У каждого человека отдельная учётная запись.

☐ Сервисные ключи не доступны браузеру.

☐ Секреты ротируются после инцидента и смены владельца.

☐ Права пересматриваются ежеквартально.

☐ Журналы сохраняют критические действия.

☐ Восстановление аккаунтов проверено.

16	ГЛАВА 16 Персональные данные и производственный допуск Правовые границы, локализация и минимизация данных «Техническая возможность получает право на запуск после проверки законности и необходимости.»

Глава 16. Персональные данные и производственный допуск

16.1. Отдельный контур решения

Публичный контент, данные животных и технические метаданные отличаются от персональных данных пользователей, благотворителей, партнёров, сотрудников и заявителей. Перед сбором персональных данных определяется основание, цель, состав, срок хранения, доступ и место размещения.

16.2. Производственный шлюз

До запуска аккаунтов, заявок, кабинетов и форм с персональными данными Организация проводит правовую проверку: статус оператора, уведомления, локализация первичной базы, трансграничная передача, согласия, политика, договоры с обработчиками и меры защиты.

16.3. Архитектурное следствие

Референсная связка Netlify и Supabase может использоваться для разработки, публичного контента и обезличенных данных. Производственный контур персональных данных выбирается после проверки юрисдикции и при необходимости переносится на российский PostgreSQL, авторизацию и объектное хранилище без изменения предметной модели.

16.4. Минимизация

Форма собирает только данные, необходимые конкретному процессу. Точная локация животных, медицинские документы людей, паспортные сведения, телефоны и внутренние контакты получают ограничение, сроки и отдельные основания.

16.5. Допуск к запуску

Контроль

☐ Определены цели обработки.

☐ Состав полей минимален.

☐ Опубликована актуальная политика.

☐ Получены необходимые согласия.

☐ Определено место первичного хранения.

☐ Оформлены отношения с обработчиками.

☐ Настроены сроки удаления и права субъектов.

☐ Проведена проверка доступа и инцидентного маршрута.

ДОКУМЕНТАЛЬНАЯ ОПОРА

Действующее законодательство РФ о персональных данных · официальный портал Роскомнадзора · внутренние документы Организации

17	ГЛАВА 17 Резервирование и восстановление Копии, контрольные точки и доказанная способность вернуть систему «Резервная копия существует после успешного восстановления, всё остальное является надеждой в формате файла.»

Глава 17. Резервирование и восстановление

17.1. Объекты резервирования

Объект	Резерв
PostgreSQL	Полная копия, инкрементальные механизмы провайдера и независимый периодический экспорт.
Объектное хранилище	Копия оригиналов и закрытых документов во второй контур.
Git	Удалённый репозиторий и дополнительный архив критических релизов.
Домены и DNS	Экспорт записей, контактов и инструкции восстановления.
Секреты	Защищённый резерв кодов и процедура ротации.
Документация	Книга, реестр систем, схемы и инструкции запуска.

17.2. Правило 3–2–1

Критические данные имеют три копии, размещаются как минимум на двух типах или независимых системах хранения, одна копия находится вне основного производственного контура. Конкретная реализация выбирается соразмерно объёму и риску.

17.3. Цели восстановления

Для каждого сервиса задаются допустимая потеря данных и допустимое время простоя. Каталог и публичный сайт могут иметь один режим, а закрытые документы, медицинские назначения и доступы — более строгий.

17.4. Учение восстановления

Квартальное учение выбирает один сценарий: восстановить таблицу, поднять тестовую базу из экспорта, вернуть удалённый файл, откатить deploy или передать домен резервному администратору. Результат фиксируется временем и замечаниями.

17.5. Готовность

Контроль

☐ Копия создаётся автоматически.

☐ Сбой копирования заметен.

☐ Экспорт хранится независимо.

☐ Ключ расшифрования доступен резервному владельцу.

☐ Инструкция восстановления актуальна.

☐ Последний тест завершился успешно.

☐ Срок хранения соответствует ценности данных.

18	ГЛАВА 18 Мониторинг, журналы и инциденты Наблюдаемость, поддержка и раннее обнаружение «Система сообщает о проблеме раньше, чем посетитель успевает написать об исчезнувшем коте.»

Глава 18. Мониторинг, журналы и инциденты

18.1. Что наблюдать

Область	Сигнал
Доступность сайта	Главная, каталог, Библиотека и ключевые API.
Ошибки приложения	Сбой загрузки, публикации, входа и выдачи файла.
База	Подключения, медленные запросы, объём и неуспешные миграции.
Хранилище	Ошибки загрузки, объём и доступность объектов.
Безопасность	Необычные входы, массовые действия, отказ политики.
Резервирование	Успех копий и дата последнего восстановления.
Расходы	Приближение к лимитам и резкий рост потребления.

18.2. Журнал действий

Критические изменения фиксируют пользователя, время, сущность, действие, прежнее и новое состояние, источник запроса и результат. Журнал защищён от обычного редактирования.

18.3. Классы инцидентов

Инцидент может затрагивать доступность, целостность данных, конфиденциальность, финансы, публикацию или владение аккаунтом. Класс определяет срочность, руководителя, обязательные действия и круг уведомления.

18.4. Поддержка редакторов

Пульт содержит понятные сообщения об ошибках и идентификатор события для технической проверки. Редактор знает, как сохранить черновик, повторить действие и передать сведения без пересылки секретов.

18.5. Первый доклад

Контроль

☐ Что произошло.

☐ Когда обнаружено.

☐ Какие функции затронуты.

☐ Есть ли риск для данных или денег.

☐ Что уже сделано.

☐ Кто руководит.

☐ Когда следующая проверка.

19	ГЛАВА 19 Масштабирование и переносимость Рост от одного Дома к сети без пленения платформой «Масштабирование начинается с ясной модели, а не с покупки сервера внушительного размера.»

Глава 19. Масштабирование и переносимость

19.1. Три этапа

Этап	Нагрузка и функции
Первый	Десятки и сотни животных, потребности, публикации, Библиотека, несколько редакторов.
Второй	Тысячи материалов, кабинеты, заявки, несколько языков, партнёрские доступы и регулярные пожертвования.
Третий	Точки Дома, команды, локальные каталоги, склад, медицинский учёт и интеграционная шина.

19.2. Признаки постоянного API

Постоянный серверный слой становится оправданным при длительных фоновых задачах, интенсивных интеграциях, собственной очереди заданий, WebSocket-сервисах, тяжёлой обработке медиа или требованиях к специальному размещению. Публичный фронтенд при этом может остаться на Netlify.

19.3. План переноса

Перенос включает экспорт PostgreSQL, перенос файлов, развёртывание миграций, настройку секретов, проверку политик, переключение адреса API и DNS. Контракт данных и интерфейс продолжают работать с новым серверным контуром.

19.4. Финансовая масштабируемость

Стоимость наблюдается по слоям: сборки и трафик, база, хранилище, функции, почта, аналитика и резерв. Рост расхода связывается с реальной метрикой и заранее установленным порогом пересмотра.

19.5. Готовность к переезду

Контроль

☐ Есть актуальный pg_dump или эквивалентный экспорт.

☐ Файлы имеют реестр и контрольные суммы.

☐ Миграции развертывают чистую базу.

☐ Секреты перечислены без раскрытия значений.

☐ API скрывает детали провайдера.

☐ DNS находится под контролем Организации.

☐ Перенос проверен на тестовом контуре.

20	ГЛАВА 20 Эксплуатация, развитие и живая Книга Ритм обслуживания, дорожная карта и передача знаний «Инфраструктура остаётся живой, когда её регулярно проверяют, упрощают и передают.»

Глава 20. Эксплуатация, развитие и живая Книга

20.1. Еженедельный ритм

Проверяются ошибки публикации, заявки редакторов, просроченные материалы, состояние домена, уведомления платформ и критические обновления. Небольшие замечания превращаются в задачи, а не растворяются в чатах.

20.2. Ежемесячное обслуживание

Контур	Действие
Контент	Архив потребностей, актуальность животных, публикаций и Библиотеки.
Доступы	Новые пользователи, завершённые роли и необычные входы.
Данные	Качество, дубликаты, объём и ошибки связей.
Файлы	Неиспользуемые производные, объём и закрытые объекты.
Резерв	Успех копий и выборочный тест.
Стоимость	Расходы и прогноз.
Документация	Изменения архитектуры и инструкций.

20.3. Дорожная карта

Первый приоритет — отделить контент от HTML и создать модели данных. Затем появляется Пульт Дома для потребностей, животных, публикаций и Библиотеки. После этого развиваются роли, закрытые полки, кабинеты, интеграции и сеть Точек.

20.4. Критерий новой функции

Новая функция получает место в архитектуре после ответа на вопросы: какую задачу она решает, кто владелец, какие данные создаёт, кто видит результат, как восстанавливается, сколько стоит и как отключается.

20.5. Обновление Книги

Каждая значимая миграция, новый сервис, изменение владельца, инцидент или успешное восстановление обновляет реестры и при необходимости текст Книги. Исторические редакции сохраняются.

20.6. Итоговый контроль

Контроль

☐ Архитектура соответствует реальной системе.

☐ Владельцы и доступы актуальны.

☐ Схема базы и миграции совпадают.

☐ Резерв восстановлен в тесте.

☐ Стоимость понятна.

☐ Персональные данные прошли производственный допуск.

☐ Следующий этап дорожной карты утверждён.

КОРОТКАЯ ФОРМУЛА

Живая инфраструктура = эксплуатация + память + проверка + улучшение.

Приложения

Приложение 1. Схема целевой архитектуры

Рабочая схема фиксирует границы публичного интерфейса, административного контура, серверных операций, данных и резервов.

Слой	Компоненты	Контроль
Публичный	Netlify CDN, сайт, опубликованные представления	Код, preview, выпуск, откат
Административный	admin.1000heartshome.ru	Вход, роли, черновики, публикация
Сервисный	Functions / API Дома	Секреты, проверки, интеграции
Данные	PostgreSQL	Миграции, RLS, экспорт
Файлы	Объектное хранилище	Метаданные, доступ, временные ссылки
Непрерывность	Git, резерв базы и файлов	Восстановление и перенос

ПРАВИЛО ПРИМЕНЕНИЯ

Схема обновляется после фактического запуска каждого слоя.

Приложение 2. Матрица ответственности платформ

Функция	Netlify	PostgreSQL / Supabase	Организация
Публичный интерфейс	Раздача и сборка	Предоставляет данные	Утверждает содержание
Preview	Создаёт среду	Тестовая ветка или набор	Проверяет
Авторизация	Показывает интерфейс входа	Проверяет пользователя и политики	Выдаёт роль
Закрытый файл	Вызывает серверную функцию	Хранит объект и право	Определяет доступ
Резерв	Хранит deploy и кодовую связь	Копия базы и файлов	Хранит независимый экспорт

ПРАВИЛО ПРИМЕНЕНИЯ

Ответственность сервиса не заменяет организационного владельца.

Приложение 3. Паспорт цифрового сервиса

Поле	Заполнение
Название сервиса
Назначение
Владелец Организации
Технический администратор
Резервный администратор
Адрес входа
Организационная почта
Тариф и стоимость
Категории данных
Юрисдикция и место хранения
Способ экспорта
Резервирование
Дата последней проверки
План отключения

Приложение 4. Реестр доменов и поддоменов

Домен / поддомен	Регистратор / DNS	Назначение	Владелец	Срок / автопродление
1000heartshome.ru		Публичный сайт
www.1000heartshome.ru		Перенаправление
admin.1000heartshome.ru		Пульт Дома
api.1000heartshome.ru		Будущий API
status.1000heartshome.ru		Будущий статус

ПРАВИЛО ПРИМЕНЕНИЯ

Реестр хранится без паролей и секретных кодов.

Приложение 5. Заявка на изменение DNS

Поле	Заполнение
Дата и инициатор
Запись до изменения
Запись после изменения
Цель
Связанный релиз
Оценка риска
План проверки
План возврата
Исполнитель
Подтверждение результата

Приложение 6. Паспорт репозитория

Поле	Заполнение
Название
Адрес
Владелец
Основная ветка
Среда сборки
Команда запуска
Команда тестов
Путь миграций
Путь документации
Секреты среды
Резервная копия
Последний проверенный релиз

Приложение 7. Модель веток и изменений

Тип	Шаблон	Кто создаёт	Условие слияния
Функция	feature/*	Разработчик / хранитель	Preview, тесты, проверка владельца
Исправление	fix/*	Разработчик	Воспроизведение и проверка
Схема данных	content-schema/*	Хранитель архитектуры	Миграция и тест экспорта
Срочное	hotfix/*	Уполномоченный администратор	Короткая проверка и последующий разбор

ПРАВИЛО ПРИМЕНЕНИЯ

Каждое изменение связывается с задачей или архитектурным решением.

Приложение 8. Чек-лист выпуска

Контроль

☐ Сборка прошла.

☐ Тесты прошли.

☐ Preview проверен.

☐ Мобильная версия проверена.

☐ День и Ночь проверены.

☐ Права проверены тестовыми ролями.

☐ Миграция протестирована.

☐ Резерв создан.

☐ План отката готов.

☐ После выпуска выполнена дымовая проверка.

Приложение 9. Чек-лист отката

Контроль

☐ Остановить новые опасные операции.

☐ Зафиксировать время и версию.

☐ Оценить состояние базы.

☐ Откатить интерфейс на проверенный deploy.

☐ Применить безопасную стратегию для данных.

☐ Проверить ключевые маршруты.

☐ Сообщить владельцу процесса.

☐ Сохранить журнал и выводы.

Приложение 10. Реестр переменных окружения

Имя	Среда	Назначение	Секретность	Владелец	Ротация

ПРАВИЛО ПРИМЕНЕНИЯ

Значения секретов в реестре не указываются; хранится только назначение и владелец.

Приложение 11. Карточка выдачи секрета

Поле	Заполнение
Сервис
Тип секрета
Получатель
Основание
Минимальные права
Дата выдачи
Срок / ротация
Место хранения
Способ отзыва
Дата отзыва

Приложение 12. Матрица ролей Пульта Дома

Модуль	Администратор	Редактор	Специалист	Библиотекарь	Наблюдатель
Животные	CRUD	CRUD	Профильные поля	R	R
Потребности	CRUD	CRUD	R	R	R
Публикации	CRUD	CRUD	Комментарий	R	R
Библиотека	CRUD	Черновики	R	CRUD	R
Пользователи	CRUD	—	—	—	—
Настройки	CRUD	—	—	—	R

ПРАВИЛО ПРИМЕНЕНИЯ

CRUD уточняется политиками на уровне строк и отдельных действий.

Приложение 13. Заявка на доступ

Поле	Заполнение
ФИО / служебное имя
Контакт
Роль
Модули
Основание
Дата начала
Срок
Владелец согласования
Требуется второй фактор
Дата выдачи
Дата пересмотра

Приложение 14. Ежеквартальная проверка доступа

Контроль

☐ Сверены активные пользователи.

☐ Уволенные и завершившие участие удалены.

☐ Права соответствуют текущим ролям.

☐ Администраторов минимальное число.

☐ Второй фактор включён.

☐ Сервисные ключи имеют владельцев.

☐ Сессии и приглашения проверены.

☐ Результат зафиксирован.

Приложение 15. Паспорт политики RLS

Поле	Заполнение
Таблица / объект
Операция
Роль
Условие доступа
Проверяемые поля
Исключения
Тестовые сценарии
Автор
Дата
Результат последней проверки

Приложение 16. Реестр сущностей данных

Сущность	Владелец	Источник	Публичность	Срок хранения	Связанные модули
Животное			Частично		Каталог, истории, кураторство
Потребность			Публичная после публикации		Что нужно сейчас
Документ			По уровню		Библиотека
Публикация			Публичная после публикации		Новости и истории
Медиа			По объекту		Все модули
Пользователь			Закрытая		Админка и кабинеты

Приложение 17. Словарь данных профиля животного

Поле	Тип	Обязательность	Публичность	Источник
animal_id	UUID / строка	Да	Служебное	Реестр животных
name	Текст	Да	Да	Карточка
species	Справочник	Да	Да	Осмотр
status	Справочник	Да	Да / частично	Ответственный
health_summary	Текст	По ситуации	Публичная редакция	Медицинская история
location_public	Текст	Да	Примерная	Ответственный
adoption_ready	Логический	Да	Да	Маршрут животного
updated_at	Дата-время	Автоматически	Да	Система

ПРАВИЛО ПРИМЕНЕНИЯ

Полный медицинский контур описывается Книгой Четвёртой и отдельными политиками доступа.

Приложение 18. Словарь данных «Что нужно сейчас»

Поле	Назначение	Пример
title	Короткое название	Пелёнки 60×90
category	Одна из трёх утверждённых категорий	Уход
quantity_or_amount	Количество или сумма	10 упаковок
urgency	Обычная / важная / срочная	Важная
comment	Пояснение	Для спинальников
sort_order	Порядок показа	20
status	Черновик / активно / закрыто / архив	Активно
closed_thanks	Показывать результат помощи	Да

Приложение 19. Словарь данных публикации

Поле	Назначение
title	Заголовок
slug	Устойчивый адрес
excerpt	Краткий анонс
body	Основной текст
cover_media_id	Обложка
category_id	Рубрика
related_animals	Связанные животные
status	Черновик / проверка / опубликовано / архив
publish_at	Дата публикации
seo_title / seo_description	Поисковое представление

Приложение 20. Словарь данных документа Библиотеки

Поле	Назначение
document_id	Устойчивый ID
title	Название
shelf	Полка
document_type	Книга, положение, отчёт, памятка
version	Редакция
status	Рабочий, утверждённый, архивный
access_level	Публичный, партнёрский, добровольческий, внутренний, Совет
file_id	Файл
previous_version_id	Предыдущая редакция
owner	Владелец
published_at	Дата публикации

Приложение 21. Словарь данных медиа

Поле	Назначение
media_id	Устойчивый ID
storage_path	Путь объекта
original_media_id	Связь с оригиналом
mime_type	Тип файла
size_bytes	Размер
checksum	Контрольная сумма
access_level	Уровень доступа
rights_basis	Источник и права
alt_text	Альтернативный текст
created_by / created_at	Автор загрузки и время

Приложение 22. Правила именования файлов

Категория	Шаблон	Пример
Животное	{animal-id}_{date}_{kind}_{seq}.{ext}	A-0042_20260723_portrait_01.webp
Документ	{code}_{title}_{version}_{date}.{ext}	BOOK-08_digital-infrastructure_v1.0_20260723.pdf
Публикация	{post-id}_{kind}_{seq}.{ext}	P-0124_cover_01.webp
Товар	{product-id}_{view}_{seq}.{ext}	LAB-003_front_01.webp

ПРАВИЛО ПРИМЕНЕНИЯ

Публичное имя может быть красивым; внутренний файл сохраняет устойчивый технический идентификатор.

Приложение 23. Шаблон импорта данных

Колонка	Требование	Ошибка импорта
external_id	Уникальный идентификатор	Дубликат
name / title	Непустое значение	Пусто
status	Значение справочника	Неизвестный статус
related_id	Существующая связь	Ссылка отсутствует
published	true / false	Неверный тип
updated_at	ISO дата-время	Неверный формат

ПРАВИЛО ПРИМЕНЕНИЯ

Импорт сначала выполняется в preview или тестовую таблицу и формирует отчёт ошибок.

Приложение 24. Состав экспортного пакета

Элемент	Формат	Назначение
Схема	SQL миграции	Развёртывание структуры
Данные	SQL dump / CSV по сущностям	Перенос и проверка
Файлы	Объекты + манифест	Восстановление медиатеки
Пользователи	Разрешённый экспорт без секретов	Миграция аккаунтов по правовой модели
Конфигурация	Список параметров без значений секретов	Повторная настройка
Документация	README, ADR, реестры	Передача дел

Приложение 25. Паспорт модуля Пульта Дома

Поле	Заполнение
Название модуля
Владелец процесса
Сущности
Основные поля
Роли
Статусы
Список и фильтры
Форма создания
Проверки
Preview
Публикация
Архив
История изменений
Экспорт
Метрики

Приложение 26. Маршрут публикации контента

Этап	Ответственный	Результат
Черновик	Редактор	Заполненные поля и материалы
Проверка фактов	Владелец содержания	Подтверждённые сведения
Проверка доступа	Редактор / администратор	Корректная публичность
Preview	Редактор / дизайнер	Проверенный вид
Публикация	Уполномоченный	Действующая версия
Контроль	Редактор	Проверенная реальная страница
Архив / обновление	Владелец	Актуальное состояние

Приложение 27. Матрица редакционных статусов

Статус	Виден публично	Можно редактировать	Следующее действие
Черновик	Нет	Да	Завершить
На проверке	Нет	Ограниченно	Подтвердить или вернуть
Запланировано	После даты	Ограниченно	Дождаться публикации
Опубликовано	Да	Через новую редакцию	Контроль / обновление
Скрыто	Нет	Да	Вернуть или архивировать
Архив	Нет	Только восстановление	Хранить

Приложение 28. Реестр API-маршрутов

Метод и путь	Назначение	Роль	Вход	Результат
GET /api/animals	Публичный каталог	public	Фильтры	Опубликованные профили
POST /api/admin/animals	Создание профиля	editor	Данные формы	ID и статус
PATCH /api/admin/needs/:id	Изменение потребности	editor	Поля	Обновлённая запись
POST /api/library/:id/access	Выдача файла	authorized	Документ	Временная ссылка
POST /api/webhooks/payment	Событие платежа	service	Подпись и payload	Статус обработки

Приложение 29. Паспорт серверной функции

Поле	Заполнение
Название
Триггер / маршрут
Назначение
Вход
Выход
Роль
Секреты
Идемпотентность
Повторы
Тайм-аут
Журналирование
Метрика
План отказа

Приложение 30. Паспорт интеграции

Поле	Заполнение
Сервис
Назначение
Владелец
Передаваемые данные
Правовое основание
Секреты
Тестовый режим
Лимиты
Обработка ошибки
Резервный маршрут
Отключение
Удаление данных

Приложение 31. Карта почты и уведомлений

Событие	Канал	Получатель	Срочность
Новый пользователь	Email	Пользователь и администратор	Обычная
Смена роли	Email + журнал	Пользователь и владелец	Важная
Ошибка публикации	Пульт + email	Редактор / администратор	Важная
Сбой резервной копии	Email / мессенджер	Администратор и резервный	Срочная
Необычный вход	Email	Пользователь и администратор	Срочная
Просроченный документ	Пульт	Библиотекарь	Обычная

Приложение 32. План резервного копирования

Объект	Частота	Хранение	Владелец	Последний тест
База данных
Закрытые файлы
Публичная медиатека
Репозиторий
DNS и домены
Документация

Приложение 33. Протокол теста восстановления

Поле	Заполнение
Дата
Сценарий
Источник копии
Целевая среда
Начало
Окончание
Потеря данных
Ошибки
Проверенные функции
Результат
Корректирующие действия
Ответственный

Приложение 34. Карточка цифрового инцидента

Поле	Заполнение
ID и дата
Обнаружил
Класс
Затронутые сервисы
Риск для данных
Риск для пользователей
Руководитель
Первичные действия
Решения
Восстановление
Уведомления
Причина
Корректирующие меры

Приложение 35. Потеря устройства

Контроль

☐ Завершить активные сессии.

☐ Заблокировать устройство и SIM при необходимости.

☐ Сменить пароль основной почты.

☐ Отозвать токены и ключи.

☐ Проверить журналы входов.

☐ Сообщить владельцу инфраструктуры.

☐ Восстановить доступ на доверенном устройстве.

☐ Зафиксировать инцидент и выводы.

Приложение 36. Компрометация аккаунта

Контроль

☐ Сохранить доказательства и время.

☐ Завершить сессии.

☐ Сменить пароль и второй фактор.

☐ Отозвать ключи и приглашения.

☐ Проверить изменения прав, данных и DNS.

☐ Восстановить корректное состояние.

☐ Проверить связанные аккаунты.

☐ Уведомить владельца и при необходимости затронутых лиц.

☐ Провести разбор.

Приложение 37. Шлюз персональных данных

Контроль

☐ Определена категория субъектов.

☐ Определена цель.

☐ Поля минимальны.

☐ Определено место хранения.

☐ Проверена локализация.

☐ Проверена трансграничная передача.

☐ Оформлены согласия и политика.

☐ Назначены сроки хранения.

☐ Настроены права и журнал.

☐ Подготовлен маршрут запроса субъекта.

☐ Проведён правовой допуск.

Приложение 38. Проверка готовности к миграции

Контроль

☐ Свежий экспорт базы читается.

☐ Миграции разворачивают схему.

☐ Файлы выгружены с манифестом.

☐ Контрольные суммы совпадают.

☐ Секреты перечислены и могут быть перевыпущены.

☐ DNS доступен Организации.

☐ Код запускается вне текущей платформы.

☐ Тестовая миграция завершена.

☐ План переключения и возврата готов.

Приложение 39. Ежеквартальный обзор инфраструктуры

Контур	Вопрос	Результат / задача
Владение	Все сервисы принадлежат Организации?
Доступы	Есть ли лишние роли?
Данные	Качество и объём в норме?
Безопасность	Есть ли новые риски и обновления?
Резерв	Последний тест успешен?
Стоимость	Есть ли приближение к лимитам?
Архитектура	Появилась ли реальная причина усложнить слой?
Документация	Книга и реестры актуальны?

Приложение 40. Дорожная карта цифрового Дома

Этап	Результат	Критерий завершения
A. Контентный фундамент	Модели животных, потребностей, публикаций, документов и медиа	Контент отделён от HTML, данные импортируются и экспортируются
B. Пульт Дома MVP	Редактирование основных модулей	Редактор работает без кода и видит preview
C. Роли и Библиотека	Auth, RLS, закрытые полки	Тестовые роли проходят сценарии доступа
D. Кабинеты и интеграции	Партнёры, кураторы, заявки и уведомления	Есть производственный допуск данных
E. Сеть Точек	Мультиорганизационная модель и локальные контуры	Точка работает по общему стандарту и сохраняет автономность

ПРАВИЛО ПРИМЕНЕНИЯ

Приоритет определяется реальной нагрузкой и пользой, а не привлекательностью новой технологии.

Заключение. Цифровой Дом остаётся нашим

Книга Восьмая закрепляет цифровую инфраструктуру как часть организационной памяти и ежедневной заботы. Она позволяет людям менять содержание через понятный Пульт, хранит связи в стандартной базе, защищает закрытые материалы, поддерживает публикацию и сохраняет путь к восстановлению и переносу.

Выбранная архитектура использует сильные стороны Netlify для публичного фасада и выпуска изменений, а серверное ядро строит вокруг PostgreSQL. Supabase помогает быстро реализовать базу, авторизацию, файлы и политики, сохраняя при этом обязательный производственный шлюз для персональных данных и возможность перейти на другой PostgreSQL-контур.

Главная устойчивость находится в правилах владения: домены, репозитории, база, хранилища и учётные записи принадлежат Организации; схема хранится в миграциях; данные и файлы экспортируются; доступы имеют срок и владельца; резерв проверяется восстановлением; решения остаются понятными следующему человеку.

«Дом владеет своей памятью, понимает свою систему и умеет продолжить работу после любого технического переезда.»

СТАТУС РЕДАКЦИИ

Рабочая редакция v1.0 подлежит уточнению после создания первой схемы PostgreSQL и MVP Пульта Дома. Конкретные платформенные настройки проверяются по актуальной официальной документации перед внедрением.

Источники и технические ориентиры

Перечень используется для проверки возможностей платформ на дату внедрения. Внешняя документация обновляется, поэтому ссылка подтверждает направление проверки, а не заменяет архитектурное решение Организации.

Источник	Назначение
Netlify Docs: Deploy overview, Deploy Previews, Functions overview	Публикация, preview, откат и серверные функции.
Supabase Docs: Database overview, Auth, Row Level Security, Storage access control	PostgreSQL, пользователи, политики доступа и файлы.
PostgreSQL Documentation	Стандарт базы, экспорт, роли, резервирование и перенос.
Decap CMS Documentation	Git-backed модель контента и границы её применения.
Портал персональных данных Роскомнадзора	Проверка требований к оператору, локализации и обработке персональных данных.
Книги управления и проектные документы Дома	Организационные полномочия, память, Библиотека, животные, финансы и непрерывность.

Сведения об издании

Журнал редакций

Архитектурное решение v1.0

Карта серии

Как пользоваться Книгой

ОГЛАВЛЕНИЕ

Предисловие. Цифровой Дом как продолжение заботы

Глава 1. Принципы цифровой инфраструктуры

Глава 2. Целевая архитектура Дома

Глава 3. Владение, управление и ответственность

Глава 4. Домены, DNS и публичные адреса

Глава 5. Репозитории, код и история изменений

Глава 6. Среды, публикация и откат

Глава 7. Данные и PostgreSQL

Глава 8. Модель сущностей и единый источник истины

Глава 9. Пульт Дома: административный интерфейс

Глава 10. Контентные модули

Глава 11. Библиотека Дома и защищённые полки

Глава 12. Пользователи, роли и политики доступа

Глава 13. Файлы, изображения и медиатека

Глава 14. API, функции и интеграции

Глава 15. Безопасность, секреты и устройства

Глава 16. Персональные данные и производственный допуск

Глава 17. Резервирование и восстановление

Глава 18. Мониторинг, журналы и инциденты

Глава 19. Масштабирование и переносимость

Глава 20. Эксплуатация, развитие и живая Книга

Приложения

Приложение 1. Схема целевой архитектуры

Приложение 2. Матрица ответственности платформ

Приложение 3. Паспорт цифрового сервиса

Приложение 4. Реестр доменов и поддоменов

Приложение 5. Заявка на изменение DNS

Приложение 6. Паспорт репозитория

Приложение 7. Модель веток и изменений

Приложение 8. Чек-лист выпуска

Приложение 9. Чек-лист отката

Приложение 10. Реестр переменных окружения

Приложение 11. Карточка выдачи секрета

Приложение 12. Матрица ролей Пульта Дома

Приложение 13. Заявка на доступ

Приложение 14. Ежеквартальная проверка доступа

Приложение 15. Паспорт политики RLS

Приложение 16. Реестр сущностей данных

Приложение 17. Словарь данных профиля животного

Приложение 18. Словарь данных «Что нужно сейчас»

Приложение 19. Словарь данных публикации

Приложение 20. Словарь данных документа Библиотеки

Приложение 21. Словарь данных медиа

Приложение 22. Правила именования файлов

Приложение 23. Шаблон импорта данных

Приложение 24. Состав экспортного пакета

Приложение 25. Паспорт модуля Пульта Дома

Приложение 26. Маршрут публикации контента

Приложение 27. Матрица редакционных статусов

Приложение 28. Реестр API-маршрутов

Приложение 29. Паспорт серверной функции

Приложение 30. Паспорт интеграции

Приложение 31. Карта почты и уведомлений

Приложение 32. План резервного копирования

Приложение 33. Протокол теста восстановления

Приложение 34. Карточка цифрового инцидента

Приложение 35. Потеря устройства

Приложение 36. Компрометация аккаунта

Приложение 37. Шлюз персональных данных

Приложение 38. Проверка готовности к миграции

Приложение 39. Ежеквартальный обзор инфраструктуры

Приложение 40. Дорожная карта цифрового Дома

Заключение. Цифровой Дом остаётся нашим

Источники и технические ориентиры