diff --git a/AGENTS.md b/AGENTS.md
index 235a664..0f9b09c 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -83,6 +83,13 @@ UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименован
 
 Карточка задачи должна разделять постановку, план этапов и фактическую реализацию.
 
+Каноническая структура карточки:
+- заголовок карточки
+- основное описание карточки
+- при необходимости текстовый блок `Текущая архитектура`
+- для каждого этапа: текстовый блок этапа, затем чекер этапа
+- после реализации этапа: текстовый блок `Реализация этапа N`
+
 Заголовок карточки:
 - передает основную суть задачи
 - должен быть коротким, читаемым в списке и без служебного шума
@@ -93,20 +100,39 @@ UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименован
 - не превращается в журнал работ и не дублирует чекеры
 - остается читаемым входом в задачу после нескольких итераций
 
-Подэлементы-чекеры:
-- создаются через `Добавить подэлемент` как отдельный чекер на каждый смысловой этап
-- заголовок чекера должен называться как этап, например `Этап 1. Backend enforcement лимитов`
+Текстовый блок `Текущая архитектура`:
+- создается через `Добавить подэлемент`, если задача опирается на уже существующее поведение
+- фиксирует, что уже реализовано, что частично реализовано, а чего в системе еще нет
+- отделяет существующий baseline от будущего плана, чтобы не планировать повторную реализацию уже готовых частей
+- не должен содержать рабочие чекеры или журнал выполнения
+
+Текстовый блок этапа:
+- создается через `Добавить подэлемент` перед чекером соответствующего этапа
+- заголовок должен называться как этап, например `Этап 1. Backend enforcement лимитов`
+- тело блока описывает цель этапа, текущий статус, границы scope, зависимости и важные ограничения
+- если этап пока только планируется, в теле явно указывается `Статус: не реализовано`, `Статус: частично реализовано` или `Статус: backlog`
+- длинные архитектурные пояснения живут здесь, а не внутри пунктов чекера
+
+Чекер этапа:
+- создается через `Добавить подэлемент` сразу после текстового блока этапа
+- заголовок чекера должен называться `Чекер этапа N. <название этапа>`
 - пункты внутри чекера должны быть короткими проверяемыми действиями по этапу
 - пункт закрывается только после реализации и проверки, а не по намерению
 - чекеры используются как рабочий план, а не как место для длинных объяснений
 
 Текстовые блоки фактической реализации:
-- создаются через `Добавить подэлемент` под соответствующим чекером этапа
+- создаются через `Добавить подэлемент` под соответствующим чекером этапа только после фактической реализации
 - заголовок текстового блока должен явно связывать его с этапом, например `Реализация этапа 1`
 - блок фиксирует, что реально сделано, какие файлы/модули затронуты, какие проверки прошли и какие ограничения остались
 - важные нюансы для дальнейшего масштабирования записываются именно сюда, а не теряются в чате
 - после каждого осмысленного этапа соответствующий текстовый блок обновляется
 
+Декомпозиция задач:
+- одна продуктовая или архитектурная тема должна жить в одной карточке, если этапы не имеют самостоятельного независимого scope
+- не создавать пачку top-level карточек для этапов одной большой задачи; этапы ведутся текстовыми блоками и чекерами внутри основной карточки
+- отдельная top-level карточка допустима только когда задача имеет отдельный результат, владельца, проверку и может выполняться независимо от родительского контекста
+- если несколько старых карточек описывают один контекст, их нужно объединить в одну актуальную карточку и удалить или закрыть дубли
+
 Статус карточки:
 - `В работе` ставится только когда задача реально взята в исполнение
 - `Готово` ставится после проверки результата и закрытия рабочих чекеров