# NEXT CHAT: OPEN THIS REPO

Если ты новый агент в новом чате, сначала прочитай этот файл целиком.

## Какой репозиторий открывать

Открывать нужно **этот** репозиторий:

`fission`

Текущая рабочая ветка здесь:

`refactor/project-structure`

## Важно

Layer2 API делать нужно **здесь**, а не в `fission-src`.

`fission-src` был нужен для layer1 и внутренней адаптации Fission под multi-tenant namespace onboarding.
Но API-код и console-side интеграция для следующего этапа находятся в **этом** репозитории.

## Что уже известно из layer1

Во внешнем репозитории `fission-src` слой layer1 уже доведён до рабочего состояния:

1. Есть общий `NamespaceManager`.
2. Buildermgr/router/executor уже сидят на общих watcher helper-ах.
3. Summary/debug contract стабилизирован.
4. Целевой тестовый прогон для layer1 был зелёным.

Это контекст, на который layer2 может опираться. Но реализацию API и console-side surface нужно продолжать в **этом** repo.

## Состояние этого репозитория

Рабочее дерево **грязное**. Здесь уже есть пользовательские изменения. Их нельзя откатывать или перетирать без необходимости.

На момент создания этого файла были изменены/добавлены такие пути:

- `console/cmd/server/main.go`
- `console/deploy/console.yaml`
- `console/internal/api/handlers.go`
- `console/internal/api/package.go`
- `console/internal/api/server.go`
- `console/internal/fission/namespace.go`
- `console/internal/cloud/`
- `deploy/rbac/executor-multi-ns.yaml`
- `test_layer1.sh`
- `test_multitenant_ns.sh`

## Что требуется от нового чата

Нужно продолжать **layer2 API** именно в этом repo.

То есть:

1. Понять текущую console/API архитектуру в этом репозитории.
2. Найти правильную точку интеграции для multi-tenant namespace status/debug/API surface.
3. Аккуратно связать это с уже готовым layer1 смыслом, но не ломать существующую структуру.
4. Не трогать unrelated user changes.

## Как работать

1. Сначала прочитать текущие API-файлы в `console/internal/api/`.
2. Отдельно посмотреть текущую интеграцию с Fission в `console/internal/fission/`.
3. Не писать код сразу, пока не станет ясна текущая server/API wiring схема.
4. Работать маленькими шагами.
5. Новые заметки писать только в новые файлы в `doc/` или `doc/thinking/`, не переписывая старые.
6. Все команды запускать только через SSH на VM и всегда с timeout.
7. Не использовать background-команды.

## Первый шаг нового агента

Сначала нужно не писать новый endpoint, а сделать короткую разведку:

1. прочитать `console/internal/api/server.go`
2. прочитать `console/internal/api/handlers.go`
3. прочитать `console/internal/fission/namespace.go`
4. посмотреть, как сейчас console API разговаривает с Fission и где логичнее всего показать multi-tenant namespace state

## Текст первого сообщения в новом чате

Можно просто вставить это:

"Прочитай файл NEXT_CHAT_LAYER2_API.md и продолжай работу строго по нему. Layer2 API делать нужно в текущем repo fission, не в fission-src. Сначала разберись в console/internal/api и console/internal/fission, затем выбери правильную точку интеграции для multi-tenant namespace status/debug/API surface. Не трогай посторонние пользовательские изменения, не запускай background-команды, все команды только через SSH на VM и с timeout."