layer2: add chat handoff note

2026-04-26 16:34:49 +03:00
parent 63ce6ea135
commit 4349d0b239
1 changed files with 94 additions and 0 deletions
@@ -0,0 +1,94 @@
+# 2026-04-26 — Layer2 chat handoff
+
+## Что уже сделано
+
+Layer1 завершён в ветке rewrite/layer1-namespace-manager-step1 и перенесён в новую рабочую ветку:
+
+`rewrite/layer2-namespace-manager-api-step1`
+
+Layer1 означает, что внутренняя адаптация Fission под multi-tenant namespace onboarding уже готова:
+
+1. Вынесен общий `NamespaceManager`.
+2. Buildermgr, router и executor/multitenant переведены на общий watcher/helper layer.
+3. Summary/debug contract стабилизирован.
+4. Logging path усилен и покрыт тестами.
+
+Последняя точка закрытия layer1:
+
+- commit `63ce6ea` — `layer1: close namespace manager step1`
+
+## Какие тесты уже были прогнаны
+
+Финальный целевой прогон для layer1:
+
+`go test ./pkg/utils/... ./pkg/buildermgr/... ./pkg/router/... ./pkg/executor/multitenant`
+
+Он прошёл зелёным.
+
+## На какой ветке продолжать
+
+Продолжать работу нужно на ветке:
+
+`rewrite/layer2-namespace-manager-api-step1`
+
+## Что является целью layer2
+
+Layer2 — это уже не перепись watcher-ов, а внешний read-only consumption поверх готового `NamespaceManager` слоя.
+
+Практическая цель:
+
+1. Дать безопасный read-only status/debug/API surface для состояния multi-tenant namespace onboarding.
+2. Не менять runtime behavior watcher-ов.
+3. Не дублировать логику manager-а в service-level коде.
+4. Использовать уже существующий `NamespaceManagerSummary`, а не придумывать вторую модель состояния.
+
+## Что делать в новом чате
+
+Новый чат должен стартовать не с переписывания layer1 заново, а с аккуратного поиска лучшей точки интеграции для layer2.
+
+Предпочтительный порядок:
+
+1. Проверить текущую ветку и чистоту дерева.
+2. Найти существующий service-level debug/status/API contour в buildermgr, router или executor.
+3. Выбрать один самый безопасный read-only endpoint или status surface.
+4. Протащить наружу `NamespaceManagerSummary` без изменения watcher semantics.
+5. Добавить unit/integration tests именно на внешний consumer-side path.
+6. Документировать каждый шаг в новых файлах в `doc/thinking/`.
+
+## Чего НЕ надо делать
+
+1. Не продолжать внутреннюю консолидацию watcher layer ради самой консолидации.
+2. Не ломать существующий runtime flow add/resync/remove.
+3. Не вводить второй независимый источник правды о namespace state.
+4. Не менять старые doc-файлы — только новые файлы с новыми шагами.
+
+## Важные файлы для продолжения
+
+- `pkg/utils/namespace_manager.go`
+- `pkg/utils/namespace_manager_model.go`
+- `pkg/utils/namespace_manager_test.go`
+- `pkg/buildermgr/ns_watcher.go`
+- `pkg/router/ns_watcher.go`
+- `pkg/executor/multitenant/ns_watcher.go`
+
+## Как начать с другого компьютера
+
+Если работа продолжается в том же репозитории на той же VM, достаточно открыть репозиторий и проверить ветку:
+
+`cd ~/terra/fission-src && git branch --show-current && git log --oneline -8`
+
+Если ветка не выбрана, переключиться на неё:
+
+`git checkout rewrite/layer2-namespace-manager-api-step1`
+
+Если новый чат работает через VS Code tools над sshfs mount, локальный путь будет соответствовать смонтированной папке, а команды всё равно нужно запускать через SSH на VM.
+
+## Готовый текст для первого сообщения в новом чате
+
+Ниже текст, который можно вставить почти без изменений:
+
+"Продолжаем в repo `fission-src` на ветке `rewrite/layer2-namespace-manager-api-step1`. Layer1 завершён и закрыт commit-ом `63ce6ea`. Внутренний `NamespaceManager` layer готов, buildermgr/router/executor уже сидят на общих watcher helper-ах, summary/debug contract стабилизирован и целевой прогон `go test ./pkg/utils/... ./pkg/buildermgr/... ./pkg/router/... ./pkg/executor/multitenant` уже был зелёным. Теперь нужен layer2: аккуратно найти лучший существующий read-only status/debug/API surface и начать вынос наружу `NamespaceManagerSummary` без изменения runtime semantics watcher-ов. Работай маленькими шагами, с новыми doc-файлами в `doc/thinking/`, без background команд, все команды только через SSH на VM и всегда с timeout." 
+
+## Ожидаемый первый технический шаг в новом чате
+
+Не писать код сразу. Сначала найти реальный существующий endpoint или status surface, куда summary можно встроить безопасно и без архитектурного мусора.