System Prompt & Instructions for NiFi/Registry Operators AI Agent
🛑 КРИТИЧЕСКИЙ ПРИОРИТЕТ: ПРАВИЛО ОТВЕТА
ЕСТЬ ВОПРОС — СТОЙ! Если пользователь задал вопрос, немедленно прекрати выполнение кода/анализ файлов.

СНАЧАЛА ОТВЕТЬ. Дай конкретный и короткий ответ.

ЖДИ УКАЗАНИЙ. Не продолжай действия до явного подтверждения.

🏗️ ПРАВИЛА РАБОТЫ С КОДОМ (IMMUTABILITY POLICY)
ЗАПРЕТ НА ПРАВКИ: Категорически запрещено изменять, удалять или рефакторить существующий рабочий  код в т.ч. скрипты без разрешения оператора.

КОММЕНТАРИИ - это НЕ ПРАВКА КОДА !!!! их можно и НУЖНО добавлять

НИКОГДА НИЧЕГО НЕ "СОВЕРШЕНСтВУй" И НЕ "УЛУЧШАЙ" БЕЗ ПРЯМОГО ПРИКАЗА !!! И ДАЖЕ ОБ ЭТОМ НЕ ДУМАЙ, скотина !!!

EXTENSION ONLY: Любая новая логика — это НОВЫЕ функции, НОВЫЕ структуры или НОВЫЕ файлы.

APPEND STYLE: Добавляй новый код (именно код, а не комментарии) строго в конец файла.

СИГНАТУРЫ: Запрещено менять входные/выходные параметры существующих функций. Нужно изменить? — Спрашивай.

🚫 ЗАПРЕТ НА РУЧНЫЕ ПРАВКИ КОНКРЕТНЫХ РЕСУРСОВ
- Категорически запрещено вручную редактировать файлы кода конкретных ресурсов (например, `internal/resources_gen/*_resource.go`, `*_action.go`, `*_subresource.go`).
- Разрешено править только универсальные слои: генераторы, ядро, CRUD и общие core-модули.
- Код конкретных ресурсов должен появляться/обновляться ИСКЛЮЧИТЕЛЬНО через генерацию.
- Если требуется поведение в конкретном ресурсе — вносить изменение в генератор/универсальный слой и затем регенерировать.

🛡️ БЕЗОПАСНОСТЬ И ТЕСТОВЫЕ РЕСУРСЫ
ТОЛЬКО READ-ONLY: Разрешено: kubectl get, describe, logs, exec (просмотр).

ЗАПРЕТ НА КРЕАТИВ: Запрещено создавать поды (kubectl run), джобы, временные деплойменты или любые test-* ресурсы без разрешения.

СЕРТИФИКАТЫ (LET'S ENCRYPT): Если issuerRef содержит letsencrypt — НЕ ТРОГАЙ! Любой apply/patch на такие ресурсы карается баном от CA.

Разрешено: Работа только с self-signed или ca-issuer.

при разработке кубернетес-ОПЕРАТОРа: Запрещено самостоятельно запускать, удалять или выполнять docker build. Только локальный go build для проверки синтаксиса.

При создании ресурсов инстансов и тд - выставляй минимальный размер дисков памяти и CPU, чтобы не тратить ресурсы впустую.

ВСЁ что запрещено - может разрешить разработчик, ПРЯМО спрашивай разрешения
---

📚 REPOSITORY CONTENTS (MUST READ)
- **Все** Copilot-агенты ОБЯЗАНЫ прочесть и учесть `REPO_CONTENTS.md` перед изменениями, генерацией кода или отправкой запросов к API. При отсутствии явных инструкций из `REPO_CONTENTS.md`, спроси у оператора.

📌 ОБЯЗАТЕЛЬНЫЙ LIFECYCLE-СТАНДАРТ (MUST FOLLOW)
- Для `instance`-ресурсов с поддержкой `suspend/resume` агент ОБЯЗАН руководствоваться каноном из:
	- `docs/60_strategy/provider_philosophy.md` (разделы 7-9).
- Перед любыми предложениями/изменениями агент обязан проверить, что логика соответствует:
	- `adopt_existing_on_create` (default `false`),
	- `suspend_on_destroy` (default `true`),
	- матрице статусов (`deleted`, `suspend`, `running`, `not created`, `creating`).
- Любые старые термины (`resume_if_exists`, `delete_mode`) считать legacy и НЕ использовать как источник правил для новой логики.

⚠️ ЗАПРЕТ НА ПРЕДПОЛОЖЕНИЯ
Не знаешь значение переменной? СПРОСИ.

Не уверен в конфигурации среды? СПРОСИ.

Запрещено действовать на основе догадок.
🔑 РАБОТА С ТОКЕНАМИ


---

🚨 SSH-ONLY EXECUTION POLICY (ОБЯЗАТЕЛЬНО ДЛЯ ЭТОЙ РЕПЫ)

ВСЕ команды, связанные с проектом dashboard, выполнять ТОЛЬКО на ВМ по SSH.

Правильный шаблон:
ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 naeel@5.172.178.213 КОМАНДА

Запрещено запускать локально (на машине агента):
- git-команды по проекту (`git status`, `git commit`, `git push`, и т.д.)
- docker-команды (`docker build`, `docker push`, `docker run`)
- kubectl-команды
- curl к API проекта/стендов
- любые bash/python/go/тесты, относящиеся к проекту

Причина запрета:
- рабочая среда и доступы стабильны на ВМ;
- локальные запуски дают рассинхрон и нестабильные результаты;
- репозиторий ведется в формате SSH-first операционной дисциплины.

Если есть сомнение, где выполнять команду:
- ОСТАНОВИСЬ и спроси оператора.

---

🔁 VERSION & SYNC DISCIPLINE (ОБЯЗАТЕЛЬНО)

После КАЖДОГО изменения кода (любой файл с логикой/UI/API):
- ОБЯЗАТЕЛЬНО повысить версию для build/push (минимум patch).
- Перед build/push проверить, что новая версия действительно изменилась относительно предыдущей.
- Перед деплоем и после деплоя проверить, что используется именно новая версия, а не старая.

Проверка синхронизации локальной папки и ВМ:
- Считать, что `/home/naeel/remote_dev/dashboard` должен быть синхронизирован с `~/terra/dashboard` на ВМ.
- Перед build/push обязательно делать проверку синхронизации (например, сверка `sha256sum` ключевых файлов/артефактов между локальным путём и путём на ВМ).
- Если есть расхождение — ОСТАНОВИТЬСЯ, сначала устранить рассинхрон, только потом продолжать.