Pastein: Ты работаешь только в проекте: /Users/23865613/IdeaProjects/untitled/zadanie2/source_project Задача состоит из двух последовательных

Загрузка данных
Ты работаешь только в проекте:

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

Задача состоит из двух последовательных частей:

1. Привести проект adt-markdownify-meta в точное соответствие техническим требованиям задания.
2. Подготовить проект к размещению в общем корпоративном репозитории: удалить персональные, локальные и внутренние служебные формулировки, не затрагивая реализованную функциональность.

Не добавляй требований от себя.

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

======================================================================
ОБЩИЕ ОГРАНИЧЕНИЯ
======================================================================

Обязательно соблюдать:

- названия объектов и каталогов брать из данных META;
- специально переводить или русифицировать названия нельзя;
- один объект META должен существовать только один раз;
- идентичность объектов определять по META ID и URL;
- если META ID и URL отсутствуют, использовать нормализованное реальное имя объекта, подтверждённое исходными данными;
- похожее название само по себе не является подтверждением идентичности или родительской связи;
- не выдумывать объекты, данные и родительские связи;
- не запускать браузер;
- не обращаться к META без отдельного разрешения;
- использовать уже сохранённые temp_html/, output/ и существующие данные;
- не удалять полезные данные без проверки переноса;
- не переписывать проект с нуля;
- вносить только минимальные изменения, необходимые для выполнения требований;
- не выполнять git reset, git clean, git restore или git stash без отдельного разрешения;
- не изменять посторонние файлы IDE;
- не удалять Ralph Loop;
- не выполнять git commit;
- не выполнять git push.

META должна использоваться только в read-only режиме.

======================================================================
1. ПРЕДВАРИТЕЛЬНЫЙ АУДИТ
======================================================================

До изменения файлов выполни аудит проекта.

Покажи:

- корень Git-репозитория;
- текущую ветку;
- git status --short;
- существующую структуру projects/SNL/meta;
- существующие файлы в output/;
- существующие каталоги hierarchy/, modules/, submodules/,
  technical_components/, integration_interactions/,
  interaction_points/, integration_points/, stands/, tech_resources/;
- список файлов, которые предполагается изменить;
- список абсолютных пользовательских путей;
- список персональных и внутренних служебных формулировок.

Не изменяй файлы до завершения первоначального аудита.

======================================================================
2. ПРОВЕРИТЬ УДАЛЕНИЕ ПАПОК C1–C4
======================================================================

Найди, какие именно каталоги проекта соответствовали папкам C1–C4.

Покажи:

- существовали ли они;
- существуют ли сейчас;
- остались ли ссылки на них в коде, конфигурации или документации.

Не удаляй другие каталоги только из-за похожего названия.

Если C1–C4 уже удалены, зафиксируй статус:

Выполнено.

Если точное соответствие C1–C4 невозможно определить по данным проекта,
зафиксируй:

Требует уточнения: исходные названия C1–C4 не определены.

======================================================================
3. ПЕРЕЙТИ В СУЩЕСТВУЮЩУЮ ВЕТКУ
======================================================================

Определи корень Git-репозитория:

git rev-parse --show-toplevel

Покажи текущую ветку:

git branch --show-current

Проверь наличие существующей ветки:

git branch --list features/adt-markdownify-meta

Ветка features/adt-markdownify-meta уже создана.

Не выполнять:

git checkout -b features/adt-markdownify-meta
git switch -c features/adt-markdownify-meta

Нужно только перейти в существующую ветку:

git checkout features/adt-markdownify-meta

или, если поддерживается:

git switch features/adt-markdownify-meta

После перехода показать:

git branch --show-current
git status --short

Если переход невозможен из-за несохранённых изменений:

- не удалять изменения;
- не выполнять reset, clean, restore или stash;
- показать причину;
- остановиться до дальнейшего разрешения.

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

======================================================================
4. ПРОВЕРИТЬ ЦЕЛЕВОЙ КАТАЛОГ
======================================================================

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

projects/SNL/meta

Проверить:

- каталог существует;
- все целевые Markdown-файлы архитектуры находятся внутри него;
- генератор сохраняет архитектуру именно туда;
- повторный запуск не создаёт итоговую архитектуру в output/,
  hierarchy/, modules/ или других альтернативных структурах.

output/ может содержать технические отчёты.

temp_html/ может содержать сохранённые HTML-страницы.

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

projects/SNL/meta

======================================================================
5. ПРОВЕРИТЬ ИЕРАРХИЮ КАТАЛОГОВ
======================================================================

Требуемая иерархия:

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

Поддерживаемые варианты:

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

Шаблоны каталогов:

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

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

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

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/module/{MODULE_NAME}/submodule/{SUBMODULE_NAME}/README.md

Размещение ТК:

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

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

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

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/module/{MODULE_NAME}/submodule/{SUBMODULE_NAME}/tk/{TK_NAME}/README.md

Правила размещения:

- ТК размещается только у подтверждённого родителя;
- родитель подтверждается только по META URL, META ID, breadcrumb
  или структурной ссылке в сохранённом HTML;
- похожее название не является подтверждением;
- нельзя переносить ТК внутрь модуля или подмодуля без доказательства;
- нельзя создавать одну и ту же ТК на нескольких уровнях.

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

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

Не переносить их внутрь модулей или подмодулей без подтверждённой связи.

Для отсутствующих в исходных данных связей использовать статус:

Не применимо: связь отсутствует в данных META.

======================================================================
6. ПРОВЕРИТЬ README АРХИТЕКТУРНЫХ ОБЪЕКТОВ
======================================================================

Для каждого реального объекта проверить отдельный README.md:

- АС;
- ФП;
- модуль;
- подмодуль;
- ТК.

README.md не должен быть пустым.

Минимальное содержание:

- название;
- тип объекта;
- META URL;
- META ID, если найден;
- подтверждённый родитель;
- основные выгруженные данные.

Требования:

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

======================================================================
7. ВЫГРУЗИТЬ ВКЛАДКУ «АТРИБУТЫ»
======================================================================

Проверить выгрузку разделов:

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

Для АС:

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

Для ФП, если вкладка присутствует:

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

Проверить:

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

Формат:

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

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

======================================================================
8. ИНТЕГРАЦИИ УРОВНЯ АС
======================================================================

Требуемые пути:

projects/SNL/meta/as/{AS_NAME}/integration-flow/{NAME}/README.md

projects/SNL/meta/as/{AS_NAME}/integration/{NAME}/README.md

projects/SNL/meta/as/{AS_NAME}/integration-point/{NAME}/README.md

Каждый реальный объект должен находиться в собственном каталоге `{NAME}`.

Нельзя создавать ложные объекты:

- unknown;
- Интеграционные взаимодействия;
- Технологические взаимодействия;
- Точки взаимодействия;
- Стенды;
- другие названия страниц или разделов;
- пустые имена;
- каталоги, созданные только из заголовка страницы.

Если на уровне АС реальные объекты конкретного типа не найдены:

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

======================================================================
9. ИНТЕГРАЦИИ УРОВНЯ ФП
======================================================================

Требуемые пути:

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/integration-flow/{NAME}/README.md

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

projects/SNL/meta/as/{AS_NAME}/fp/{FP_NAME}/integration-point/{NAME}/README.md

Каждая реальная интеграционная сущность должна иметь отдельный каталог.

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

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

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

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

Идентичность интеграционных объектов определять в таком порядке:

1. META ID;
2. META URL;
3. нормализованное реальное имя — только при отсутствии ID и URL.

Пустой URL не должен приводить к объединению всех объектов в один.

======================================================================
10. ПРОВЕРИТЬ ДАННЫЕ ИЗ СТАРОЙ СТРУКТУРЫ
======================================================================

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

Особенно проверить:

- hierarchy/;
- modules/;
- submodules/;
- technical_components/;
- данные страницы «Интеграционные взаимодействия»;
- данные, связанные с ius-request-approval;
- integration_interactions/;
- interaction_points/;
- integration_points/;
- stands/;
- tech_resources/.

Для каждого уникального файла определить:

- старый путь;
- META URL;
- META ID;
- тип страницы;
- существует ли эквивалент в as/;
- полностью ли перенесены данные;
- можно ли безопасно удалить старый файл.

Не удалять файл, если его данные ещё не представлены в целевой структуре.

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

output/UNMIGRATED_META_DATA.md

Формат:

| Старый путь | META URL | META ID | Тип данных | Целевой путь | Статус переноса |
|---|---|---:|---|---|---|

Допустимые статусы:

- Перенесено полностью;
- Перенесено частично;
- Не перенесено;
- Дубликат по META ID;
- Дубликат по META URL;
- Требует уточнения;
- Данные отсутствуют.

Удалять старые каталоги разрешается только после подтверждения, что:

- данные перенесены;
- целевые README.md существуют;
- файлы не содержат уникальной информации;
- генератор не восстановит старые каталоги повторно.

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

Проверить сохранённые HTML и Markdown-данные на наличие:

- стендов;
- технических ресурсов.

Если реальные данные найдены:

- сохранить их в projects/SNL/meta;
- разместить у подтверждённого родителя;
- создать отдельный README.md для каждого реального объекта;
- сохранить META URL и META ID, если доступны.

Если реальные данные не найдены:

- не создавать вымышленные объекты;
- не создавать ложные пустые дочерние каталоги;
- не ставить статус «Закрыто»;
- перечислить проверенные источники;
- использовать статус «Не применимо» или «Не закрыто» в зависимости
  от наличия исходной страницы.

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

Проверить:

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

Генератор должен:

- формировать только целевую архитектурную структуру;
- использовать реальные сохранённые данные;
- не создавать дубли;
- не создавать ложные интеграционные объекты;
- сохранять таблицы атрибутов;
- размещать ТК только у подтверждённого родителя;
- разделять integration-flow, integration и integration-point;
- разделять уровень АС и уровень ФП;
- не создавать один объект одновременно на уровнях АС и ФП;
- не восстанавливать удалённые старые каталоги;
- быть идемпотентным;
- записывать архитектуру в projects/SNL/meta;
- записывать технические отчёты в output/.

Разрешены минимальные исправления алгоритмов, необходимые для выполнения
этих требований.

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

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

.before-requirements-fix

Резервные копии не должны попадать в итоговую архитектуру или отчёты.

======================================================================
13. ПРОВЕРКИ ФУНКЦИОНАЛЬНОСТИ
======================================================================

Выполнить:

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

Затем:

python scripts/regenerate_reports.py

После завершения выполнить повторно:

python scripts/regenerate_reports.py

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

- количество объектов не растёт;
- количество файлов не растёт без причины;
- README.md не дублируются;
- таблицы не дублируются;
- интеграционные точки не появляются одновременно на уровнях АС и ФП;
- структура остаётся одинаковой;
- старые каталоги не восстанавливаются;
- данные не теряются;
- результат второго запуска совпадает с первым по составу объектов.

Показать:

find projects/SNL/meta/as -type f | sort

Показать статистику:

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

======================================================================
14. ОБНОВИТЬ TASK_COVERAGE
======================================================================

Обновить:

output/TASK_COVERAGE.md

Проверять только реальные технические требования:

1. Папки C1–C4 удалены.
2. Архитектура сохранена в projects/SNL/meta.
3. Активна существующая ветка features/adt-markdownify-meta.
4. Создана иерархия АС → ФП → Модуль → Подмодуль → ТК.
5. Поддерживается путь АС → ФП → ТК.
6. Поддерживается путь АС → ФП → Модуль → ТК при наличии связи.
7. Поддерживается путь АС → ФП → Модуль → Подмодуль → ТК при наличии связи.
8. Для реальных объектов созданы README.md.
9. Выгружена вкладка «Атрибуты».
10. Атрибуты сохранены в табличном формате.
11. Integration-flow для АС структурирован.
12. Integration для АС структурирован.
13. Integration-point для АС структурирован.
14. Integration-flow для ФП структурирован.
15. Integration для ФП структурирован.
16. Integration-point для ФП структурирован.
17. Нет ложных объектов и дублей.
18. Повторная генерация идемпотентна.
19. Полезные данные старой структуры перенесены или учтены в отчёте.
20. В отслеживаемых файлах нет персональных абсолютных путей.
21. В проекте нет внутренних персональных формулировок.

Допустимые статусы:

- Закрыто;
- Частично;
- Не закрыто;
- Не применимо: связь отсутствует в данных META;
- Требует уточнения.

Не ставить «Закрыто», если:

- существует только заглушка;
- исходные данные отсутствуют;
- объект не подтверждён META ID или URL;
- данные ещё находятся только в старой структуре;
- повторная генерация восстанавливает старые каталоги.

======================================================================
15. ОЧИСТИТЬ ПРОЕКТ ДЛЯ ОБЩЕГО РЕПОЗИТОРИЯ
======================================================================

Этот этап выполнять только после завершения функциональных исправлений.

На этом этапе запрещено менять:

- алгоритмы парсинга;
- иерархию projects/SNL/meta;
- размещение ТК;
- определение родительских связей;
- генерацию атрибутов;
- интеграционные объекты;
- реальные данные;
- Ralph Loop.

Разрешены:

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

----------------------------------------------------------------------
15.1. НАЙТИ ПЕРСОНАЛЬНЫЕ И ВНУТРЕННИЕ УПОМИНАНИЯ
----------------------------------------------------------------------

Выполни поиск по всему проекту, включая скрытые каталоги:

- наставник
- наставника
- наставнику
- mentor
- mentoring
- mentor requirements
- требования наставника
- фидбек наставника
- по словам наставника
- как потребовал наставник
- MENTOR_REQUIREMENTS_REPORT
- mentor_feedback
- mentor-feedback
- куратор
- стажировка
- моё задание
- мне сказали
- пользователь попросил
- готово для наставника
- ожидаю дальнейших указаний
- остановился и жду подтверждения
- наш проект
- мы решили

Проверить:

- Python-код;
- комментарии;
- docstring;
- README.md;
- SKILL.md;
- MAIN_GOAL.md;
- AGENTS.md;
- конфигурационные файлы;
- scripts/;
- docs/;
- output/;
- projects/SNL/meta/;
- .gigacode/;
- шаблоны отчётов;
- генерируемые строки и заголовки.

Сначала показать список найденных файлов и строк.

----------------------------------------------------------------------
15.2. ЗАМЕНИТЬ ФОРМУЛИРОВКИ НА НЕЙТРАЛЬНЫЕ
----------------------------------------------------------------------

Использовать нейтральные формулировки:

- «требования наставника» → «требования задания»
- «фидбек наставника» → «результаты проверки»
- «проверка требований наставника» → «проверка требований»
- «готовность наставнику» → «готовность результата»
- «что требует наставник» → «что требуется по заданию»
- «по указанию наставника» → «согласно требованиям»
- «согласовать с наставником» → «требует уточнения»
- «для демонстрации наставнику» → «для итоговой проверки»
- «ожидаю дальнейших указаний» → «проверка завершена»
- «остановился и жду подтверждения» → «требует уточнения»
- «по твоим словам» → удалить или заменить доказательством из данных
- «мы решили» → «принятое техническое решение»
- «наш проект» → «проект»
- «выполняем совет наставника» → «выполняются требования задания»

Не использовать в новых текстах:

- наставник;
- mentor;
- куратор;
- стажировка;
- моё задание;
- мне сказали;
- пользователь попросил.

Технические требования нельзя удалять. Они должны называться:

- требования задания;
- требования экспорта;
- критерии готовности;
- критерии проверки.

----------------------------------------------------------------------
15.3. ПЕРЕИМЕНОВАТЬ ОТЧЁТ
----------------------------------------------------------------------

Если существует:

output/MENTOR_REQUIREMENTS_REPORT.md

переименовать в:

output/REQUIREMENTS_REPORT.md

Обновить ссылки в:

- Python-скриптах;
- README.md;
- SKILL.md;
- MAIN_GOAL.md;
- AGENTS.md;
- TASK_COVERAGE.md;
- остальных отчётах;
- генераторах отчётов.

Заголовок файла:

# Проверка требований

Не оставлять файл:

output/MENTOR_REQUIREMENTS_REPORT.md

Если отчёт создаётся программно, изменить имя и заголовок в генераторе,
а не только переименовать существующий Markdown-файл.

----------------------------------------------------------------------
15.4. УБРАТЬ ЛОКАЛЬНЫЕ И ПЕРСОНАЛЬНЫЕ ДАННЫЕ
----------------------------------------------------------------------

Проверить текстовые файлы на наличие:

/Users/23865613/
/Users/23865613/IdeaProjects/untitled/zadanie2
/Users/23865613/snl-ai-spec

В документации, отчётах, примерах и комментариях заменить абсолютные пути
относительными:

- корень проекта;
- .gigacode/skills/adt-markdownify-meta;
- projects/SNL/meta;
- output/;
- temp_html/.

Также удалить из отслеживаемых файлов:

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

Не удалять технические настройки SberBrowser, если они необходимы
для запуска проекта.

Локальный конфигурационный файл может содержать локальный путь только если:

- он исключён через .gitignore;
- это явно зафиксировано в отчёте;
- в отслеживаемых файлах этого пути нет.

======================================================================
16. ФИНАЛЬНЫЕ ПРОВЕРКИ ПОСЛЕ ОЧИСТКИ
======================================================================

Выполнить:

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

Если изменялся генератор отчётов:

python scripts/regenerate_reports.py

После этого проверить отсутствие персональных формулировок:

grep -RniE \
'наставник|наставника|наставнику|mentor|mentoring|MENTOR_REQUIREMENTS_REPORT|фидбек наставника|требования наставника|куратор|стажировка|моё задание|мне сказали|пользователь попросил' \
. \
--exclude-dir=.git \
--exclude-dir=.venv \
--exclude-dir=__pycache__ \
--exclude-dir=.local-backup

Ожидаемый результат: совпадений нет.

Проверить абсолютные пути:

grep -RniE \
'/Users/23865613|IdeaProjects/untitled/zadanie2|/Users/23865613/snl-ai-spec' \
. \
--exclude-dir=.git \
--exclude-dir=.venv \
--exclude-dir=__pycache__ \
--exclude-dir=.local-backup

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

Проверить Git-состояние:

git branch --show-current
git status --short
git diff --stat
git diff --name-status

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

======================================================================
17. ФИНАЛЬНЫЙ ОТЧЁТ
======================================================================

Создать:

output/REQUIREMENTS_REPORT.md

Структура:

# Проверка требований

## Папки C1–C4

## Целевой каталог projects/SNL/meta

## Активная Git-ветка

## Иерархия

## Размещение ТК

## README архитектурных объектов

## Атрибуты

## Интеграции уровня АС

## Интеграции уровня ФП

## Неперенесённые данные

## Стенды

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

## Удалённые дубли

## Удалённые ложные объекты

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

## Результат первой регенерации

## Результат повторной регенерации

## Проверка идемпотентности

## Очистка внутренних формулировок

## Проверка абсолютных путей

## Изменённые файлы

## Итоговая таблица соответствия

Итоговая таблица:

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

В финале явно указать:

- какие файлы изменены;
- какие файлы переименованы;
- какие файлы удалены;
- какие резервные копии созданы;
- какая ветка активна;
- сколько объектов каждого типа создано;
- сколько объектов каждого типа найдено на уровнях АС и ФП;
- какие требования полностью выполнены;
- какие выполнены частично;
- какие не закрыты;
- какие не применимы из-за отсутствия связей в META;
- какие данные ещё остаются вне as/;
- остались ли ложные объекты;
- остались ли дубли;
- остались ли персональные формулировки;
- остались ли абсолютные пользовательские пути;
- требуется ли повторный браузерный прогон;
- требуется ли ручная проверка.

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

Не выполнять git commit.
Не выполнять git push.
Не запускать браузер.
Не обращаться к META.
Больше возможностей при регистрации:
