# 2026-04-26 — NamespaceManager rewrite, step 1

## Цель шага

Начать bounded rewrite Layer 1 без большого взрыва по коду.
Первый шаг deliberately узкий:

- не менять lifecycle namespace onboarding;
- не трогать watcher-ы executor/router/buildermgr;
- не менять контракты `AddNamespace`;
- убрать первые прямые проходы по общей mutable map `FissionResourceNS`.

## Почему именно так

Сейчас multi-tenant логика уже динамическая, но многие старые code path все еще читают
`DefaultNSResolver().FissionResourceNS` напрямую. Это опасно по двум причинам:

1. map общая и mutable, а dynamic onboarding меняет ее во время работы процесса;
2. часть helper-ов и startup path продолжают жить как будто список namespace-ов immutable.

Полный rewrite в один шаг дал бы слишком большой blast radius. Поэтому сначала вводится
thread-safe snapshot API в namespace layer, а затем существующие потребители переводятся
на него по одному.

## План шага 1

1. Добавить в `pkg/utils/namespace.go` методы snapshot для plain namespaces и namespaces with options.
2. Перевести `pkg/utils/informer.go` на snapshot API.
3. Перевести startup factory path в `pkg/executor/executor.go` на snapshot API.
4. Добавить unit tests для snapshot behavior.
5. Прогнать `go test ./pkg/utils/... ./pkg/executor/...`.

## Ожидаемый эффект

- меньше прямых чтений общей map;
- появление базового API, через который дальше можно выносить единый NamespaceManager;
- нулевое изменение внешнего поведения на этом шаге.

## Что НЕ делаем на этом шаге

- не исправляем watcher lifecycle;
- не добавляем remove/delete semantics;
- не трогаем router race и buildermgr dedup bug;
- не меняем RBAC.