docs: add custom fork header to README (multi-tenant by Naeel/ngcloud)

NEXT_CHAT_LAYER2.md

@@ -0,0 +1,79 @@
+# NEXT CHAT: LAYER2 START HERE
+
+Если ты новый агент в новом чате, сначала прочитай этот файл целиком.
+
+## Где работать
+
+Репозиторий: `fission-src`
+
+Ветка:
+
+`rewrite/layer2-namespace-manager-api-step1`
+
+## Что уже готово
+
+Layer1 завершён.
+
+Это значит:
+
+1. Внутренний `NamespaceManager` layer уже реализован.
+2. Buildermgr, router и executor/multitenant уже переведены на общий watcher/helper layer.
+3. Summary/debug contract стабилизирован.
+4. Logging path усилен.
+5. Layer1 закрыт commit-ом:
+
+`63ce6ea`  
+`layer1: close namespace manager step1`
+
+## Что уже было проверено
+
+Целевой прогон для layer1 уже был зелёным:
+
+`go test ./pkg/utils/... ./pkg/buildermgr/... ./pkg/router/... ./pkg/executor/multitenant`
+
+## Что нужно делать теперь
+
+Нужен layer2.
+
+Layer2 = не переписывать watcher-ы заново, а дать внешний read-only status/debug/API surface поверх уже готового `NamespaceManager` слоя.
+
+Цель:
+
+1. Найти лучший существующий read-only endpoint/status/debug surface.
+2. Начать аккуратно выносить наружу `NamespaceManagerSummary`.
+3. Не менять runtime semantics watcher-ов.
+4. Не плодить второй источник правды о namespace state.
+
+## Как работать
+
+1. Работай маленькими шагами.
+2. Перед кодом сначала найди правильную точку интеграции.
+3. Все новые заметки пиши только в новые файлы в `doc/thinking/`.
+4. Не трогай старые doc-файлы.
+5. Не запускай background-команды.
+6. Все команды запускай только через SSH на VM и всегда с timeout.
+
+## Важные файлы
+
+- `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`
+
+## Первый шаг в новом чате
+
+Сначала не писать код.
+
+Сначала:
+
+1. проверить текущую ветку и чистоту дерева;
+2. найти существующий service-level status/debug/API contour;
+3. выбрать один безопасный read-only entrypoint для первого шага layer2.
+
+## Текст первого сообщения нового чата
+
+Можно просто вставить это:
+
+"Прочитай файл NEXT_CHAT_LAYER2.md и продолжай работу строго по нему. Нужен layer2: safe read-only API/status/debug surface поверх NamespaceManager без изменения runtime semantics watcher-ов. Сначала найди правильную точку интеграции, потом делай маленькие шаги с документированием в новых файлах doc/thinking/."

README.md

@@ -1,3 +1,18 @@
+> [!IMPORTANT]
+> ## Это форк Fission с поддержкой мультитенантности (multi-tenant)
+>
+> **Автор доработок:** Naeel / ngcloud  
+> **Базовая версия:** Fission v1.22.0 (официальный)  
+> **Репозиторий:** https://gitea.services.ngcloud.ru/Nail/fission-src
+>
+> ### Что добавлено по сравнению с официальным Fission:
+> - **Динамический multi-tenant:** namespace с меткой `fission.io/managed=true` подхватываются без рестарта Fission
+> - **Автоматический SA provisioning:** при появлении нового namespace автоматически создаются ServiceAccount, Role, RoleBinding для fetcher/builder
+> - **Namespace Manager:** новый компонент в `pkg/utils/` для отслеживания namespace в реальном времени
+> - **Обратная совместимость:** полная, поведение идентично официальному если меток нет
+
+---
+
 <p align="center">
   <img src="https://fission.io/images/logo-gh.svg" width="300" />
   <br>

doc/thinking/2026-04-26-layer2-chat-handoff.md

@@ -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 можно встроить безопасно и без архитектурного мусора.

pkg/executor/client/client.go

@@ -111,7 +111,13 @@ func (c *client) GetServiceForFunction(ctx context.Context, fn *fv1.Function) (s
 func (c *client) UnTapService(ctx context.Context, fnMeta metav1.ObjectMeta, executorType fv1.ExecutorType, serviceURL *url.URL) error {
 	url := c.executorURL + "/v2/unTapService"
 	tapSvc := TapServiceRequest{
-		FnMetadata:     fnMeta,
+		FnMetadata: metav1.ObjectMeta{
+			Name:            fnMeta.Name,
+			Namespace:       fnMeta.Namespace,
+			ResourceVersion: fnMeta.ResourceVersion,
+			Generation:      fnMeta.Generation,
+			UID:             fnMeta.UID,
+		},
 		FnExecutorType: executorType,
 		ServiceURL:     strings.TrimPrefix(serviceURL.String(), "http://"),
 	}
@@ -175,6 +181,7 @@ func (c *client) TapService(fnMeta metav1.ObjectMeta, executorType fv1.ExecutorT
 			Name:            fnMeta.Name,
 			Namespace:       fnMeta.Namespace,
 			ResourceVersion: fnMeta.ResourceVersion,
+			Generation:      fnMeta.Generation,
 			UID:             fnMeta.UID,
 		},
 		FnExecutorType: executorType,

pkg/executor/executortype/poolmgr/gpm.go

@@ -833,6 +833,11 @@ func (gpm *GenericPoolManager) AddNamespace(ctx context.Context, ns string, mgr
 		return fmt.Errorf("AddNamespace %s: register informers: %w", ns, err)
 	}
 
+	// Also update gpm.podLister so IsValid can resolve pods in this namespace.
+	// Without this line gpm.podLister[ns] is nil for dynamically-added user namespaces,
+	// causing a nil-pointer panic in IsValid, which leaves activeRequests permanently stuck at 1.
+	gpm.podLister[ns] = gpmInformer.Core().V1().Pods().Lister()
+
 	// Start the factories — they will begin syncing immediately.
 	finformer.Start(ctx.Done())
 	gpmInformer.Start(ctx.Done())