sless/doc/architecture/sonnet-review-of-gpt-analysis.md

Claude Sonnet 4.6: Review of GPT-5.4 Analysis

Дата: 2026-03-10
Автор: Claude Sonnet 4.6
Контекст: Анализ документа agent-handoff-2026-03-10.md, подготовленного GPT-5.4

---

Executive Summary

GPT-5.4 провёл детальный code review и выявил реальные архитектурные проблемы в текущей реализации sless. Анализ качественный, приоритизация разумная, но фокус исключительно на lifecycle/data consistency, при этом полностью упущен security roadmap для production.

Мой вердикт:

• ✅ GPT-5.4 правильно определил проблемы event model (A1, A2)
• ✅ Invocation history gap (A3) — точное попадание
• ✅ Приоритизация задач логична для текущего MVP
• ⚠️ Критичный пробел: безопасность multi-tenant serverless платформы вообще не упомянута
• ⚠️ Не учтён контекст беседы с пользователем про gVisor, LLM validation, runtime isolation

---

Где GPT-5.4 абсолютно прав

1. Event Model Problems (A1, A2) — критично

Проблема:

// trigger_controller.go
func (r *TriggerReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&sllessv1alpha1.Trigger{}).  // ❌ нет watch на Function
        Complete(r)
}

Trigger может зависнуть в waiting если Function не Ready на момент создания. Reconcile не произойдёт автоматически когда Function станет Ready.

Почему это важно: Классическая ошибка в operator patterns. Это не "незавершённая фича" а реальный race condition.

Моё мнение: Приоритет A1/A2 — верный. Это базовая корректность reconciliation loop.

2. Invocation History (A3) — не реализована

GPT-5.4 правильно выявил: таблица invocations есть, SaveInvocation() реализован, но нигде не вызывается.

// invoke.go — должно быть, но нет:
// store.SaveInvocation(ctx, &storage.Invocation{...})

Моё мнение: Согласен. Это не мелкая недоработка — это разрыв между API контрактом и реальностью.

3. Multi-tenancy через namespace в URL (A4) — проблема для production

// router.go
r.HandleFunc("/v1/namespaces/{namespace}/functions", ...)

Пользователь передаёт namespace в URL, но auth не проверяет принадлежность. Один токен = все namespace.

Моё мнение: Верно, но это known limitation для MVP. Важно не забыть при переходе к реальному tenant model.

4. Config inconsistency (B1) — мнимая конфигурируемость

// config.go
FunctionNamespacePrefix string // есть поле

// function_controller.go
targetNS := "sless-fn-" + fn.Namespace  // 🔥 хардкод, игнорирует конфиг

Моё мнение: Полностью согласен. Либо убрать поле либо использовать везде. Сейчас это вводит в заблуждение.

---

Где GPT-5.4 поверхностен или не учёл контекст

1. Security для multi-tenant serverless — критичный пробел

GPT-5.4 вообще не упомянул:

• Container escape protection (gVisor/Kata)
• Network isolation между namespace (NetworkPolicy)
• Code validation перед деплоем
• Resource abuse prevention
• Kernel-level isolation

Проблема: Для публичного managed serverless это не "nice to have" — это базовое требование безопасности.

Контекст из беседы: Пользователь спрашивал: "как быть? всё должно быть безопасно". Обсуждали:

• gVisor — sandbox runtime для защиты от container escape
• NetworkPolicy — изоляция трафика между namespace
• LLM validation — проверка кода на malicious patterns
• Capsule/vCluster — для усиленной изоляции

Мой вывод: GPT-5.4 дал план для "внутреннего инструмента", но не для "облачного продукта".

2. LLM integration для security — не упомянута

Контекст из беседы:

• "LLM скоро запустят в облаке. и он должен себя оправдывать"
• Идея: builder вызывает LLM для проверки кода перед сборкой
• Защита от криптомайнеров, ботнетов, DDoS-агентов

GPT-5.4 вообще не включил это в roadmap, хотя пользователь явно видит это частью системы.

Мой вывод: LLM validation должна быть в плане после исправления lifecycle issues, но до production launch.

3. Go runtime — не упомянут

Контекст из беседы:

• "пока не надо, но надо golang будет"
• Обсуждали двухэтапный Dockerfile (builder → scratch)
• Go даёт ~5-10MB бинарь vs ~100MB Python/Node

GPT-5.4 не включил Go runtime в roadmap, хотя это логичный next step после стабилизации существующих рантаймов.

4. Production deployment model — не рассмотрен

GPT-5.4 правильно отметил что один бинарь (API + operator) "нормален для v1", но не дал vision когда и как разделять.

Что пропущено:

• API становится data plane proxy → bottleneck
• HA для operator manager (leader election есть, но не обсуждается)
• Separate control/data plane для масштабирования

Мой вывод: Для MVP текущая архитектура OK, но GPT-5.4 мог дать более чёткий trigger point для refactor.

---

Где я частично не согласен

1. Timeout enforcement (B2) — не приоритет сейчас

GPT-5.4 включил TimeoutSec в "критичность B", но реально это less critical чем security.

Моё мнение:

• Runtime timeout — nice to have для MVP
• Можно задокументировать как "informational field" и вернуться позже
• Важнее NetworkPolicy + gVisor чем timeout enforcement

2. Test coverage (B4) — правильно отмечено, но слишком общо

GPT-5.4: "Тестов ядра почти нет".

Моё мнение:

• Да, это проблема
• Но конкретные приоритеты тестов должны быть:
  1. Event model (Trigger/FunctionJob watch на Function)
  2. Cleanup finalizers
  3. Invocation history recording
• Не надо гнаться за coverage %, надо покрыть critical paths

---

Production Security Roadmap (пропущен GPT-5.4)

Это должно быть в handoff, но отсутствует.

Immediate (до первых external users)

1. gVisor RuntimeClass

   spec:
     runtimeClassName: gvisor
   

   • Защита от container escape
   • ~10-20% performance overhead
   • Установка на ноды + RuntimeClass в k8s

2. NetworkPolicy per namespace

   kind: NetworkPolicy
   spec:
     podSelector: {}
     policyTypes: ["Ingress", "Egress"]
     ingress: []  # Deny all by default
   

   • Запретить трафик между sless-fn-* namespace
   • Разрешить только к external services + internal DNS

3. ResourceQuota per tenant

   apiVersion: v1
   kind: ResourceQuota
   spec:
     hard:
       requests.cpu: "10"
       requests.memory: 20Gi
       pods: "50"
   

Near-term (параллельно с lifecycle fixes)

4. Static code analysis в builder

   • Python: bandit before Docker build
   • Node.js: npm audit
   • Блокировка деплоя при critical issues

5. Image scanning

   • Trivy/Grype после kaniko build
   • Reject образа если critical CVE

Medium-term (перед production launch)

6. LLM validation hook

   • API call к облачному LLM перед сборкой
   • Детект криптомайнеров, port scanners, DDoS agents
   • Premium feature или throttled для free tier

7. True tenant isolation

   • Identity из JWT → namespace mapping
   • User не может передать namespace в URL
   • RBAC per tenant

---

Рекомендуемый порядок работ (мой взгляд vs GPT-5.4)

GPT-5.4 предложил:

1. Event model (Trigger/FunctionJob watch)
2. Invocation history
3. Timeout/validation sync
4. Config consistency
5. Tests

Я рекомендую:

1. ✅ Event model — согласен, приоритет #1
2. ✅ Invocation history — согласен, приоритет #2
3. ⚠️ Добавить: gVisor + NetworkPolicy (до external users)
4. ✅ Config consistency
5. ✅ Tests (но фокус на critical paths)
6. ⚠️ Добавить: Static analysis в builder
7. Timeout enforcement (lower priority)
8. ⚠️ Добавить: LLM validation (перед production)

---

Практические дополнения для следующего агента

Что делать с GPT-5.4 handoff

Использовать как base, но:

1. После этапа 2 (invocation history) → добавить security hardening
2. Перед production launch → полный security audit + LLM integration
3. Go runtime → после стабилизации Python/Node (не urgent)

Конкретные файлы для security work (пропущены GPT-5.4)

gVisor:

• controllers/function_controller.go — добавить RuntimeClassName: "gvisor" в PodSpec
• Установка на ноды (вне кода)

NetworkPolicy:

• deployments/k8s/network-policy.yaml — создать template
• controllers/function_controller.go — создавать NetworkPolicy per namespace

Code validation:

• internal/builder/builder.go — добавить pre-build validation hook
• internal/validator/ (новый) — интеграция с bandit/npm audit

LLM validation:

• internal/validator/llm.go — API client к облачному LLM
• internal/api/handler/upload.go — вызов перед S3 upload

---

Файлы которые следующий агент должен создать/изучить

GPT-5.4 не упомянул, но критичны:

1. doc/security/multi-tenancy-model.md — дизайн tenant isolation
2. doc/security/runtime-isolation.md — gVisor/Kata decision + implementation
3. deployments/k8s/network-policy-template.yaml — NetworkPolicy per tenant
4. deployments/k8s/resource-quota-template.yaml — ResourceQuota per tenant
5. internal/validator/ — новый пакет для code validation
6. doc/decisions/gvisor-vs-kata.md — почему gVisor for MVP

---

Окончательный вердикт

GPT-5.4 провёл отличный технический аудит кода, но смотрел через призму "внутреннего инструмента", а не "managed cloud service".

Сильные стороны анализа:

• ✅ Детальный разбор lifecycle problems
• ✅ Конкретные файлы и строки кода
• ✅ Приоритизация по критичности
• ✅ Практичный план для MVP stabilization

Пробелы:

• ❌ Security roadmap отсутствует
• ❌ Не учтён контекст беседы (gVisor, LLM, Go runtime)
• ❌ Production deployment model не рассмотрен
• ❌ Tenant isolation strategy не обсуждается

Рекомендация: Использовать GPT-5.4 handoff как техническую базу, дополнить моими замечаниями по security, затем скомбинировать в единый production roadmap.

Для следующего агента:

1. Читать GPT-5.4 документ для lifecycle issues
2. Читать этот документ для security roadmap
3. Начинать с lifecycle (приоритет GPT-5.4)
4. После стабилизации — security hardening (мой приоритет)
5. Перед production launch — полный аудит (желательно Claude Opus 4.6)

---

Действия для этой сессии

Следующий шаг: обновить doc/progress.md, зафиксировать оба анализа (GPT-5.4 + мой), чтобы следующий агент видел полную картину.