# План інновацій з аналізу `sap-adt-mcp`

> Джерело: `~/prj/sap-adt-mcp` (окремий open-source MCP-сервер для SAP ADT, TS, MCP SDK v1.x).
> Мета цього документа — зафіксувати, що з їхніх рішень варто перенести до нашого стеку,
> у який саме компонент/пакет це лягає, який буст дає, і що ми дивимось «для довідки», але собі не робимо.
>
> Це **план-кошик ідей**, а не план імплементації. Рішення «що/де робити» приймаємо окремо по кожному пункту.

## Контекст нашого стеку (важливо для оцінки вартості)

На відміну від `sap-adt-mcp` (моноліт: один процес, один `.sap-profiles.json`, axios усередині),
у нас функціонал розкладений по пакетах:

- **mcp-abap-adt** — MCP-сервер (handlers, server transport, auth broker factory `src/lib/auth/`).
- **mcp-abap-adt-clients** — ADT-клієнти (`AdtClient`, `AdtClientLegacy`, executors, core).
- **пакет-конектор** — нижній шар з'єднання/сесії.
- (+ типи/спільні утиліти).

**Наслідок для авторизації:** будь-яка зміна способу автентифікації зачіпає **3 пакети + конектор**,
а не один файл як у них. Тому auth — найдорожчий і найважливіший блок: оцінюємо окремо й обережно.

---

## A. Авторизація (найвищий пріоритет, найдорожче)

У `sap-adt-mcp` три способи auth у профілі (`.sap-profiles.json`): `basic`, `certificate`, `kerberos`.
Системи — **тільки on-prem ADT** (ICM HTTPS 44300). Cloud/BTP (JWT/OAuth) у них немає — тут ми попереду.

| # | Інновація | Як у них | Що дає нам | Куди лягає | Вартість | Буст |
|---|-----------|----------|------------|------------|----------|------|
| A1 | **Certificate Auth (Windows Cert Store)** | PowerShell+SChannel bridge, пошук серта по SHA-1 thumbprint, без пароля | Закриває корпоративні on-prem системи, де basic заборонений, а вхід — по клієнтському серту | конектор + clients + broker factory + типи профілю | Висока (3 пакети + конектор, Windows-only, spawn PowerShell) | Високий для enterprise on-prem; нульовий для cloud |
| A2 | **Kerberos / SPNEGO SSO** | `kerberos` npm, SPN `HTTP@host`, NTLM-detection + hard-reject | Доменний SSO без зберігання пароля — велика зручність і безпека на on-prem | конектор + clients + broker factory | Висока (нативний модуль компілюється з C++, Windows-домен) | Високий для доменних on-prem; вузька аудиторія |
| A3 | **NTLM-detection guard** | перевірка base64-префікса `TlRMTVNTUAA`, відмова якщо прийшов NTLM замість Kerberos | Захист від тихого фолбеку на слабкий NTLM | конектор | Низька (окрема функція) | Точковий, але дешевий — варто взяти разом з A2 |

**Рекомендація:** спочатку design-spike — описати, як certificate/kerberos лягають на наш broker factory
+ конектор **без ламання** cloud(JWT)/RFC шляхів. Реалізацію A1/A2 — лише після окремого рішення,
бо ціна висока, а аудиторія вузька (доменні Windows on-prem).

---

## B. Інструменти читання / навігації (середня ціна, хороший буст)

| # | Інновація | Що дає нам | Куди лягає | Вартість | Буст |
|---|-----------|------------|------------|----------|------|
| B1 | **`read_signatures`** — лише PUBLIC SECTION класу (методи/типи/константи, без тіл) | 5–20× менший контекст для LLM коли треба лише інтерфейс класу. Прямий burn-rate виграш токенів | handler + clients (парс public section) | Низька–середня | **Високий** — економія токенів на кожному читанні класу |
| B2 | **`list_method_callers`** — where-used на рівні методу | Точніший impact-аналіз перед зміною методу (не весь клас) | handler + clients (method-level usageReferences) | Середня | Середній — корисно для рефакторингу |
| B3 | **`get_cds_dependencies` з SQL-метриками** — дерево залежностей CDS + joins/unions/views count + complexity score (LOW…VERY_HIGH) + DCL/ACL стан | Швидка оцінка складності/безпеки CDS без ручного читання | handler + clients (cds dependency graph parse) | Середня | Середній — нішево для CDS-важких проєктів |
| B4 | **`browse_package` без 500-cap** (до 9999) | Повний лістинг великих пакетів за раз | перевірити, чи в нас є cap; якщо є — підняти | Низька | Низький–середній (залежить чи є в нас обмеження) |

**Рекомендація:** **B1 — взяти першим.** Дешево, прямий і вимірюваний виграш по токенах для будь-якого
агентного сценарію. B2/B3 — за запитом.

---

## C. Безпека запису / гардрейли (дешево, добрий ROI)

| # | Інновація | Що дає нам | Куди лягає | Вартість | Буст |
|---|-----------|------------|------------|----------|------|
| C1 | **`read_table` як SQL Console з guard'ами** — whitelist лише SELECT (блок INSERT/UPDATE/DELETE/MODIFY/CALL/CREATE/DROP/ALTER як перший токен) + blacklist sensitive-таблиць (USR02, USR40, PA000x, T000, RFCDES, DEVACCESS, ICF*) | Безпечний ad-hoc SELECT через ADT SQL Console з захистом від витоку credentials/HR/конфіг даних | handler + clients (sqlConsole endpoint) | Середня | Середній — зручно, але треба ретельні guard'и |
| C2 | **`namespace` write-guard як middleware** — відхиляє запис до об'єктів не з дозволеним префіксом ще до lock | Захист від випадкового запису поза Z-простором | server middleware / guards | Низька | Середній — дешевий запобіжник |
| C3 | **per-profile `readonly` + глобальний readonly mode** | Inspection-only режим на рівні профілю/сервера | config + guards | Низька | Середній |
| C4 | **Mandatory transport для write** | Жодного тихого запису без TR | guards (перевірити чи вже є) | Низька | Залежить від поточного стану |

**Рекомендація:** C2/C3/C4 — дешеві запобіжники, варто звірити з тим, що вже маємо, і добрати відсутнє.
C1 — корисний, але guard'и треба робити консервативно (краще blacklist + whitelist разом).

---

## D. UX / onboarding (низький пріоритет для нас)

| # | Інновація | Що дає нам | Вартість | Рішення |
|---|-----------|------------|----------|---------|
| D1 | **`switch_system`** — runtime-перемикання профілю в одній MCP-сесії | Без рестарту сервера між системами | Середня | Розглянути — у нас multi-session модель може робити це інакше |
| D2 | **Setup wizard** (`--setup`) з парсингом `SAPUILandscape.xml` + Windows cert listing | Гарний онбординг для desktop-користувача | Висока | Дивимось як ідею, **собі не робимо** — у нас env/конфіг-driven підхід |
| D3 | **`--standards <file>`** — ін'єкція ABAP coding standards у контекст інструментів | Команда нав'язує naming/error-handling конвенції LLM-у | Низька | **Цікаво — варто розглянути**, дешево й корисно |
| D4 | **Throttle layer** (acquire/release семафор перед ADT-викликом) | Захист від перевантаження ADT паралельними викликами | Низька–середня | Розглянути якщо ловимо rate-limit/race на ADT |

---

## E. «Дивимось як у людей, але собі точно не робимо»

- **Моноліт-архітектура** (`.sap-profiles.json`, axios усередині сервера) — наш розклад по пакетах
  дає перевикористання клієнтів поза MCP; назад до моноліту не йдемо.
- **Setup wizard з парсингом `SAPUILandscape.xml`** (D2) — desktop-онбординг, не наш сценарій.
- **PowerShell-bridge як єдина реалізація cert-auth** — якщо й робити cert-auth (A1), то крос-платформно
  через конектор, а не spawn PowerShell.
- **Прив'язка до Windows** загалом — у них cert/kerberos Windows-only; нам потрібна крос-платформність.

---

## Підсумкова черга (чернетка, обговорюється)

1. **B1 `read_signatures`** — найкращий ROI (токени), низька ціна. Брати першим.
2. **C2/C3/C4** — звірити наявні гардрейли, добрати дешеві запобіжники.
3. **A (auth) design-spike** — спроєктувати certificate/kerberos на broker factory + конектор,
   оцінити реальну ціну по 3 пакетах, **рішення про реалізацію — окремо**.
4. **D3 `--standards`** — дешево, корисно для команд.
5. **C1 `read_table`/SQL Console** — за наявності guard-бюджету.
6. **B2/B3** — за запитом конкретних проєктів.
7. **D1/D4** — розглянути за потребою.

> Наступний крок: по кожному пункту з 1–6 — окреме рішення «робимо / в який пакет / коли»
> + (для auth) окремий технічний spike перед будь-яким кодом.
