---

Ты работаешь только с новым автономным skill-проектом:

/Users/23865613/IdeaProjects/untitled/zadanie2/snl-markdownify-meta

Исходный проект находится здесь:

/Users/23865613/IdeaProjects/untitled/zadanie2/source_project

Исходный проект использовать только как справочник и источник уже реализованной логики.

ЗАПРЕЩЕНО изменять любые файлы в source_project.

Главная задача: исправить snl-markdownify-meta так, чтобы итоговые Markdown-файлы с реальным содержимым META находились непосредственно в иерархии:

projects/SNL/meta

Сейчас проблема состоит в том, что:

1. Полные выгруженные данные находятся в output/*.md.
2. В projects/SNL/meta создано правильное дерево каталогов.
3. Но многие README.md внутри дерева содержат только:
   - название;
   - тип;
   - URL;
   - строку «Источник: output/...».
4. Это не соответствует требованию: итоговая архитектура должна быть полностью сохранена и рассортирована внутри projects/SNL/meta, а не зависеть от файлов output/.

Необходимо исправить именно генератор, а не только вручную переписать текущие README.

Не выполняй git commit и git push.

Не удаляй полезные данные.

Не обращайся к META и не запускай браузер без отдельной необходимости. Сначала используй уже сохранённые данные:

- output/;
- temp_html/;
- существующие README;
- meta_urls.txt;
- BUILD_REPORT.md.

======================================================================
1. СНАЧАЛА ПРОВЕДИ АУДИТ
======================================================================

Перед изменениями проверь:

1. Сколько файлов находится в output/.
2. Какие из них содержат реальные выгруженные данные META.
3. Сколько README.md находится в projects/SNL/meta.
4. Какие README являются полноценными.
5. Какие README являются заглушками и содержат только:
   - заголовок;
   - тип;
   - URL;
   - ссылку на output/.
6. Какой файл output/*.md соответствует каждому README.md.
7. Какие объекты не удалось однозначно сопоставить.

Создай таблицу сопоставления:

| Тип объекта | Название | META ID | META URL | Файл output | Целевой README | Статус |
|---|---|---:|---|---|---|---|

Статусы:

- однозначно сопоставлен;
- сопоставлен по META ID;
- сопоставлен по META URL;
- сопоставлен по точному названию;
- неоднозначно;
- источник не найден.

Сопоставление выполнять в следующем приоритете:

1. META ID;
2. нормализованный META URL;
3. точное название объекта;
4. тип объекта и название;
5. только в крайнем случае — анализ содержимого.

Нельзя сопоставлять объекты только по частичному совпадению имени.

======================================================================
2. ИТОГОВАЯ СТРУКТУРА
======================================================================

Вся итоговая архитектура должна находиться здесь:

projects/SNL/meta

Основная иерархия:

АС → ФП → Модуль → Подмодуль → ТК

Должны поддерживаться три варианта:

1. АС → ФП → ТК
2. АС → ФП → Модуль → ТК
3. АС → ФП → Модуль → Подмодуль → ТК

Пример структуры:

projects/SNL/meta/
└── as/
    └── {AS_NAME}/
        ├── README.md
        ├── attributes/
        │   └── README.md
        └── fp/
            └── {FP_NAME}/
                ├── README.md
                ├── attributes/
                │   └── README.md
                ├── module/
                │   └── {MODULE_NAME}/
                │       ├── README.md
                │       ├── tk/
                │       │   └── {TK_NAME}/
                │       │       └── README.md
                │       └── submodule/
                │           └── {SUBMODULE_NAME}/
                │               ├── README.md
                │               └── tk/
                │                   └── {TK_NAME}/
                │                       └── README.md
                ├── tk/
                │   └── {TK_NAME}/
                │       └── README.md
                ├── integration-flow/
                │   └── {OBJECT_NAME}/
                │       └── README.md
                ├── integration/
                │   └── {OBJECT_NAME}/
                │       └── README.md
                ├── integration-point/
                │   └── {OBJECT_NAME}/
                │       └── README.md
                ├── stand/
                │   └── {STAND_NAME}/
                │       └── README.md
                └── technical-resource/
                    └── {RESOURCE_NAME}/
                        └── README.md

Для уровня АС также должны поддерживаться:

projects/SNL/meta/as/{AS_NAME}/integration-flow/{OBJECT_NAME}/README.md
projects/SNL/meta/as/{AS_NAME}/integration/{OBJECT_NAME}/README.md
projects/SNL/meta/as/{AS_NAME}/integration-point/{OBJECT_NAME}/README.md
projects/SNL/meta/as/{AS_NAME}/stand/{STAND_NAME}/README.md
projects/SNL/meta/as/{AS_NAME}/technical-resource/{RESOURCE_NAME}/README.md

Объект размещается только у подтверждённого родителя.

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

- META ID;
- META URL;
- breadcrumb;
- структурной ссылке;
- данным сохранённого HTML;
- явно указанному родителю в Markdown.

Не придумывать связи.

Если для ТК подтверждён только родитель ФП, он должен находиться здесь:

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/tk/{TK_NAME}/README.md

Не переносить ТК в module/ или submodule/ без подтверждённой связи.

======================================================================
3. СОДЕРЖИМОЕ КАЖДОГО README
======================================================================

Каждый README.md реального объекта должен содержать не ссылку на output, а полные данные объекта.

Минимальная структура README:

# {Название объекта}

**Тип объекта:** ...
**META ID:** ...
**META URL:** ...
**Родитель:** ...
**Источник данных:** ...

## Основная информация

Полное содержимое, извлечённое из соответствующего output/*.md или HTML.

## Карточка

Markdown-таблица с реальными данными, если раздел присутствует.

## Ответственность

Markdown-таблица с реальными данными, если раздел присутствует.

## Дополнительные атрибуты

Markdown-таблица с реальными данными, если раздел присутствует.

## Технические атрибуты

Markdown-таблица с реальными данными, если раздел присутствует.

## Связанные объекты

Список подтверждённых дочерних или родительских объектов.

## Интеграции

Реальные данные об интеграциях, если они относятся к объекту.

## API

Реальные данные API, если они присутствуют.

Не добавлять пустые разделы только ради шаблона.

Если конкретного раздела в исходных данных нет, его можно не создавать.

Нельзя оставлять вместо данных только строку:

**Источник:** output/...

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

======================================================================
4. АТРИБУТЫ АС И ФП
======================================================================

Проверить:

projects/SNL/meta/as/{AS_NAME}/attributes/README.md

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/attributes/README.md

Они должны содержать реальные данные вкладки «Атрибуты»:

- Карточка;
- Ответственность;
- Дополнительные атрибуты;
- Технические атрибуты.

Все данные сохранять в Markdown-таблицах.

Пример:

## Карточка

| Поле | Значение |
|---|---|
| ... | ... |

Запрещено:

- оставлять только количество найденных строк;
- писать только «данные обнаружены»;
- писать только ссылку на output;
- смешивать данные АС и ФП;
- дублировать таблицы при повторном запуске.

Если вкладка присутствовала, но её содержимое не удалось извлечь из сохранённых HTML, честно указать:

«Раздел обнаружен в интерфейсе, но строки таблицы отсутствуют в сохранённом HTML».

Однако сначала обязательно проверить соответствующие output/*.md и temp_html/*.html.

======================================================================
5. МОДУЛИ И ПОДМОДУЛИ
======================================================================

Для каждого модуля и подмодуля:

1. Найти соответствующий output/*.md.
2. Перенести полное содержимое в его README.md.
3. Сохранить:
   - название;
   - META ID;
   - META URL;
   - родителя;
   - описание;
   - таблицы;
   - атрибуты;
   - связанные объекты;
   - исходные данные.
4. Не создавать два каталога для одного META ID или URL.
5. Не переводить и не русифицировать название вручную.

Если существуют каталоги с разными названиями, но одинаковым META ID или URL:

- выбрать одно каноническое название из сохранённого HTML/META;
- объединить полезные данные;
- удалить только доказанный дубль;
- записать действие в BUILD_REPORT.md.

======================================================================
6. ТЕХНИЧЕСКИЕ КОМПОНЕНТЫ
======================================================================

Для каждого из 24 ТК:

1. Найти его полный Markdown-файл в output/.
2. Перенести всё полезное содержимое в соответствующий README.
3. Каждый ТК должен оставаться отдельным каталогом.
4. Не объединять несколько ТК в один файл.
5. Сохранить:
   - название;
   - META ID;
   - META URL;
   - родителя;
   - описание;
   - статус;
   - технологии;
   - владельцев;
   - связи;
   - интеграции;
   - API;
   - прочие таблицы и атрибуты.

Текущее подтверждённое размещение 24 ТК на уровне ФП сохранить, если в данных нет доказанной связи с модулем или подмодулем:

projects/SNL/meta/as/SberGeo/fp/SberGeo.СНЛ/tk/{TK_NAME}/README.md

======================================================================
7. ИНТЕГРАЦИИ
======================================================================

Обработать отдельно три типа:

- integration-flow;
- integration;
- integration-point.

Каждый реальный объект должен иметь отдельный каталог и полноценный README.

Не создавать один общий объект с названием страницы:

- «Интеграционные взаимодействия»;
- «Точки взаимодействия»;
- «Технологические взаимодействия»;
- «Стенды».

Название страницы-раздела не всегда является названием реального объекта.

Для каждого реального интеграционного объекта сохранить:

- название;
- тип;
- META URL;
- META ID;
- родительский уровень: АС или ФП;
- поставщик;
- потребитель;
- ТК поставщика;
- ТК потребителя;
- владелец;
- API;
- описание;
- остальные поля исходной таблицы.

Пять реальных interaction-point должны остаться отдельными каталогами на уровне подтверждённого родителя ФП.

Не создавать их дубли на уровне АС.

Если integration-flow или integration представлены только страницей-разделом, но внутри исходного Markdown есть таблица реальных строк:

- каждая строка должна стать отдельным объектом;
- название брать из колонки «Наименование»;
- данные строки перенести в README.

Если реальных строк нет, не создавать ложный объект. Разрешается оставить индексный README внутри категории с описанием проверенных источников.

======================================================================
8. СТЕНДЫ
======================================================================

Проверить файл:

output/STANDS.md

и соответствующие HTML.

Если обнаружены реальные стенды, например:

- Major-GO;
- DEV;
- ПРОМ;
- Major-Check;

каждый стенд должен иметь отдельный каталог:

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/stand/{STAND_NAME}/README.md

или на уровне другого подтверждённого родителя.

В README стенда перенести все доступные поля из таблицы.

Нельзя оставлять стенды только в output/STANDS.md.

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

======================================================================
9. ТЕХНИЧЕСКИЕ РЕСУРСЫ
======================================================================

Проверить:

output/TECH_RESOURCES.md

и соответствующие HTML.

Нужно различать:

- технические компоненты;
- технические ресурсы.

Нельзя автоматически считать все 24 ТК техническими ресурсами.

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

Если реальные технические ресурсы найдены, создать отдельные каталоги:

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/technical-resource/{RESOURCE_NAME}/README.md

Если данные отсутствуют, не создавать ложные объекты.

======================================================================
10. ИСПРАВИТЬ ГЕНЕРАТОР
======================================================================

Исправить основной генератор, а не только текущие файлы.

Проверить и при необходимости изменить:

scripts/structured_meta_writer.py
scripts/generate_attributes_reports.py
scripts/regenerate_reports.py
scripts/integration_interactions_parser.py
scripts/html_to_markdown.py

Допускается создать вспомогательный скрипт:

scripts/fix_readmes.py

Но итоговая логика обязательно должна быть встроена в штатную генерацию.

После исправления повторный запуск генератора должен сразу создавать полноценные README с реальными данными.

Нельзя оставлять архитектуру, при которой:

1. output/*.md содержит полные данные;
2. projects/SNL/meta содержит только ссылки на output.

Правильная архитектура:

- output/ — технические отчёты и промежуточные результаты;
- projects/SNL/meta — итоговый самодостаточный экспорт архитектуры.

README в projects/SNL/meta должен быть читаем без открытия output/.

======================================================================
11. ИДЕНТИЧНОСТЬ И ДЕДУПЛИКАЦИЯ
======================================================================

Идентичность объекта определять по:

1. META ID;
2. нормализованному META URL.

Название не является основным идентификатором.

Нормализовать URL:

- удалить завершающий `/`;
- не учитывать query-параметры, не относящиеся к объекту;
- сохранить тип объекта и числовой ID.

Один META ID или URL должен соответствовать одному каталогу.

При конфликте имён:

- выбрать название из сохранённого HTML;
- объединить содержимое;
- не терять уникальные таблицы или поля;
- зафиксировать решение в отчёте.

======================================================================
12. СОХРАННОСТЬ ДАННЫХ
======================================================================

Перед перезаписью README:

1. Создать резервную копию только изменяемой целевой структуры, например:

.before-readme-content-fix/

2. Не копировать резервную папку в projects/SNL/meta.
3. Не включать резервную папку в итоговый экспорт.
4. Не удалять output/ до завершения проверки.
5. Не удалять temp_html/.
6. Не менять исходный source_project.

После проверки резервную копию можно оставить вне итогового дерева или удалить только после успешного сравнения.

======================================================================
13. ПРОВЕРКИ
======================================================================

После изменений выполнить:

python -m py_compile run_exporter.py scripts/*.py

Затем штатную генерацию:

python run_exporter.py

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

После первого запуска сохранить:

- список файлов;
- количество файлов;
- SHA256 содержимого всех README.

Затем выполнить второй такой же запуск.

Проверить:

- количество файлов не изменилось;
- пути не изменились;
- содержимое не продублировалось;
- таблицы не повторились;
- заголовки не повторились;
- количество объектов не выросло;
- старые плоские каталоги не появились;
- output не копируется внутрь итоговой структуры как вложенная папка;
- README остаются полноценными.

Идемпотентность должна проверяться не только количеством файлов, но и хешами содержимого.

======================================================================
14. ПРОВЕРКА ПОЛНОТЫ README
======================================================================

Создать автоматическую проверку каждого README.md.

README считается неполным, если:

- содержит менее 5 содержательных строк;
- содержит только заголовок, тип и URL;
- содержит только ссылку на output;
- не содержит реальных полей или таблиц при наличии данных в output;
- содержит слова-заглушки при наличии исходных данных;
- не содержит META ID/URL, хотя они есть в источнике.

Создать отчёт:

BUILD_REPORT.md

Раздел:

## Полнота README

Таблица:

| README | Тип объекта | Источник output | Строк в источнике | Строк в README | Таблиц в источнике | Таблиц в README | Статус |
|---|---|---|---:|---:|---:|---:|---|

Статусы:

- Полный;
- Частично перенесён;
- Источник не найден;
- Требует ручной проверки.

======================================================================
15. ПРОВЕРКА ПО ТИПАМ
======================================================================

В итоговом отчёте вывести:

- количество АС;
- количество ФП;
- количество модулей;
- количество подмодулей;
- количество ТК;
- количество integration-flow;
- количество integration;
- количество integration-point;
- количество стендов;
- количество технических ресурсов;
- количество attributes README;
- количество полноценных README;
- количество неполных README;
- количество объектов без источника;
- количество дублей по META ID;
- количество дублей по META URL.

Также показать дерево:

find projects/SNL/meta -type f | sort

======================================================================
16. BUILD_REPORT
======================================================================

Обновить:

BUILD_REPORT.md

Структура:

# Отчёт сборки skill

## Исходное состояние

## Проблема заглушек README

## Сопоставление output и целевой структуры

## Изменённые скрипты

## Итоговая иерархия

## АС

## ФП

## Модули

## Подмодули

## Технические компоненты

## Атрибуты

## Integration-flow

## Integration

## Integration-point

## Стенды

## Технические ресурсы

## Полнота README

## Дедупликация

## Результат py_compile

## Результат первого запуска

## Результат второго запуска

## Проверка хешей

## Идемпотентность

## Нерешённые случаи

## Итоговый статус

В финале таблица:

| Требование | Статус | Доказательство |
|---|---|---|

======================================================================
17. КРИТЕРИИ ГОТОВНОСТИ
======================================================================

Работа считается завершённой только если:

1. projects/SNL/meta содержит итоговую архитектуру.
2. Каждый реальный объект находится в отдельном каталоге.
3. Каждый README содержит реальные данные объекта.
4. Для чтения README не требуется открывать output/.
5. Атрибуты АС и ФП сохранены таблицами.
6. Модули и подмодули содержат полные данные.
7. Каждый из 24 ТК имеет полноценный README.
8. Интеграционные объекты имеют отдельные каталоги.
9. Стенды перенесены из output, если они являются отдельными объектами.
10. Технические ресурсы перенесены только при наличии подтверждения.
11. Нет дублей по META ID и URL.
12. Нет вымышленных родительских связей.
13. Повторный запуск не меняет количество, пути и содержимое файлов.
14. Генератор создаёт полноценную структуру автоматически.
15. source_project не изменён.
16. git commit и git push не выполнялись.

======================================================================
18. ПОРЯДОК ВЫПОЛНЕНИЯ
======================================================================

Работай в следующем порядке:

1. Проверить текущую директорию.
2. Убедиться, что работа ведётся в snl-markdownify-meta.
3. Проверить, что source_project не изменяется.
4. Провести аудит output и README.
5. Создать таблицу сопоставления.
6. Сделать резервную копию изменяемой структуры.
7. Исправить логику генератора.
8. Создать или применить миграцию существующих README.
9. Проверить атрибуты.
10. Проверить модули и подмодули.
11. Проверить все 24 ТК.
12. Проверить integration-flow, integration и integration-point.
13. Проверить стенды.
14. Проверить технические ресурсы.
15. Запустить py_compile.
16. Выполнить первую генерацию.
17. Выполнить вторую генерацию.
18. Сравнить количество, пути и SHA256.
19. Обновить BUILD_REPORT.md.
20. Показать финальную сводку.

Не останавливайся после создания одного вспомогательного скрипта.

Не считать работу завершённой, пока не проверено фактическое содержимое всех README.

После завершения остановись.

Не выполнять commit и push.