@rt-tools/agent-kit 0.8.3 → 0.9.0

package/assets/hooks/sql-guard-target.sh

@@ -0,0 +1,134 @@
+#!/usr/bin/env bash
+# Адресат запроса для гарда хранилища: боевая база, одноразовая база проверки или что-то
+# третье — и что на боевой разрешено.
+#
+# Строки `# rt-hook:` здесь нет намеренно: событие и образец вызова объявляет сам гард, а
+# помощник рядом хуком не регистрируется и в одиночку ничего не решает.
+
+# --- прод: запись запрещена в любом виде ------------------------------------------------
+# Признак берётся из профиля: порт туннеля, хост, домен — у каждого дерева свои.
+#
+# Ищем его в АДРЕСЕ, а не в данных: домен приложения живёт и в самих строках — в почте
+# владельца, в канонической ссылке объекта. Пока признак брался по всей команде, вставка
+# строки с таким адресом в локальную базу отклонялась как запись в бой, а опт-аута у этой
+# ветки нет по замыслу — команда становилась неисполнимой.
+# Поэтому текст запроса (то, что стоит после `-c`/`--command`) из проверки вырезается.
+#
+# Запрос из редактора адресата в тексте не называет: база выбирается идентификатором
+# подключения, и по одному SQL отличить прод от локальной копии невозможно. Поэтому
+# подключения опознаются в лицо. Список сверяется вызовом list_database_connections;
+# добавили новое — допишите сюда, иначе оно попадёт в «неизвестные» ниже.
+sql_resolve_target() {
+    is_prod=""
+    PROD_CONNECTIONS="${RT_PROD_CONNECTIONS:-}"
+    LOCAL_CONNECTIONS="${RT_LOCAL_CONNECTIONS:-}"
+
+    conn_known=""
+    if [ -n "$conn" ]; then
+        case " $PROD_CONNECTIONS " in *" $conn "*) is_prod="yes"; conn_known="prod" ;; esac
+        # Опознанное локальное подключение сильнее текстовой догадки: домен приложения живёт в
+        # самих данных — в почте владельца, в канонической ссылке объекта. Пока вывод не
+        # отменялся, обновление такой строки на локальной базе отклонялось как запись в бой, и
+        # обойти это было нечем.
+        case " $LOCAL_CONNECTIONS " in *" $conn "*) conn_known="local"; is_prod="" ;; esac
+    fi
+
+    # Для запроса из редактора адрес в тексте не назван вовсе: там решает опознанное
+    # подключение, а если оно неизвестно — ветка ниже спросит пользователя.
+    is_scratch=""
+    addr_other=""
+    if [ -z "$conn" ] && [ "$context" != "запрос через подключение редактора (обёртка исполнителя)" ]; then
+        while IFS= read -r seg; do
+            [ -z "$seg" ] && continue
+            if [ -n "$PROD_DSN" ] && printf '%s' "$seg" | grep -qE "$PROD_DSN"; then
+                is_prod="yes"
+                addr_other="yes"
+                continue
+            fi
+            # Одноразовая база проверки: петлевой адрес и порт из отведённого под них диапазона.
+            # Диапазон занимают контейнеры, которые поднимают на время одной проверки —
+            # восстановление копии, репетиция миграции на непустой базе — и сносят следом. Данных,
+            # которые стоило бы стеречь, там нет по построению, а вопрос на каждую строку такой
+            # проверки приучает отвечать «да» не читая и обесценивает тот вопрос, который был важен.
+            #
+            # Диапазон узкий и петлевой намеренно: под него не должны попадать ни рабочая база
+            # дерева, ни туннель к бою, ни базы соседних деревьев на этой машине. Какой он здесь,
+            # знает профиль; не назван — исключения нет вовсе, и вопрос задаётся всегда.
+            if [ -n "${RT_SCRATCH_PORT_RE:-}" ] \
+                && printf '%s' "$seg" | grep -qE "$RT_SCRATCH_PORT_RE" \
+                && printf '%s' "$seg" | grep -qE '127\.0\.0\.1|localhost|host\.docker\.internal'; then
+                is_scratch="yes"
+            else
+                # Любой другой адресованный вызов снимает исключение целиком: в цепочке
+                # `psql -p 19434 -f x.sql && psql -c "delete …"` ранний выход убрал бы проверку
+                # со второго звена, а это ровно тот обход, ради которого гард и написан.
+                addr_other="yes"
+            fi
+        done <<EOF
+$(addr_segments)
+EOF
+    fi
+}
+
+# Исключение стоит ПОСЛЕ разбора адреса и ПЕРЕД правилами записи, но строго после того, как
+# признак боевой базы уже выставлен: прод перекрывает исключение при любом совпадении, а не
+# наоборот. Условие тройное — одноразовый адрес найден, боевого нет, и других адресованных
+# вызовов в команде нет вовсе.
+sql_pass_scratch() {
+    if [ -n "$is_scratch" ] && [ -z "$is_prod" ] && [ -z "$addr_other" ]; then
+        exit 0
+    fi
+}
+
+# На боевой базе разрешено только то, что гард опознал как чтение — БЕЛЫМ списком, а не
+# перечислением запретов. Чёрный список здесь принципиально не работает: SQL доезжает до
+# сервера файлом, редиректом, `\copy`, `SELECT … INTO`, и каждая заделанная форма оставляет
+# соседнюю. Поэтому вопрос перевёрнут: не «есть ли здесь запись», а «доказано ли чтение».
+#
+# Чтением считаются три формы, и каждая проверяется в СЕГМЕНТЕ своего вызова:
+#   pg_dump без --clean/--create   — снятие дампа
+#   psql -c "<один SELECT>"        — запрос без второго стейтмента
+#   psql -l / --version / --help   — проверка соединения без запроса
+sql_check_prod() {
+    if [ -n "$is_prod" ] && [ -n "$is_write" ]; then
+        deny "BLOCKED: запись в БОЕВОЕ хранилище (${context}). Адрес ведёт на бой — оттуда данные не восстанавливаются ничем, кроме копии. Схема на бою меняется миграцией через выкатку, данные — через панель владельца. Если правка данных на бою действительно нужна, её делает владелец руками, предварительно сняв копию; гард обойти нельзя."
+    fi
+
+    if [ -n "$is_prod" ]; then
+        unproven=""
+        while IFS= read -r seg; do
+            [ -z "$seg" ] && continue
+            seg_read=""
+            # Аргументы клиента — всё, что стоит ПОСЛЕ его имени. До имени в том же сегменте
+            # свободно живут чужие флаги: `docker compose -f docker-compose.prod.yml … psql`,
+            # и `-f` от compose однажды отменял доказательство чтения.
+            seg_tail="$(printf '%s' "$seg" | perl -0pe 's{^.*?(?<![[:alnum:]_./-])(psql|pg_restore|prisma)(?=\s|$)}{$1}s' 2>/dev/null)"
+            [ -z "$seg_tail" ] && seg_tail="$seg"
+
+            if printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_.-])pg_dump(all)?([^[:alnum:]_.-]|$)'; then
+                case "$seg" in
+                    *--clean*|*--create*) ;;
+                    *) seg_read="yes" ;;
+                esac
+            fi
+
+            # Один SELECT и ничего кроме: второй стейтмент через `;` уже не чтение.
+            if printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_])select([^[:alnum:]_]|$)' \
+                && ! printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_])(delete|update|insert|truncate|drop|alter|grant|revoke|copy)([^[:alnum:]_]|$)|\\copy|into[[:space:]]+[a-z_"]' \
+                && ! printf '%s' "$seg_tail" | grep -qE '(^|[[:space:]])(-f|--file)([[:space:]]|=)'; then
+                seg_read="yes"
+            fi
+
+            printf '%s' "$seg_tail" | grep -qE '(^|[[:space:]])(-l|--list|--version|--help)([[:space:]]|$)' \
+                && seg_read="yes"
+
+            [ -z "$seg_read" ] && unproven="yes"
+        done <<EOF
+$segments
+EOF
+
+        if [ -n "$unproven" ]; then
+            deny "BLOCKED: вызов клиента БД против БОЕВОЙ базы (${context}). На проде разрешено только доказанное чтение — \`pg_dump\` без \`--clean\`, одиночный SELECT через \`-c\`, либо \`-l\`/\`--version\`. Всё остальное отклоняется, даже если гард просто не разобрал команду: содержимое файлов (\`-f\`, \`< dump.sql\`), \`\\copy\` и восстановление дампа ему не видны. Если нужен разбор данных боевой базы — снимай дамп и работай с локальной копией."
+        fi
+    fi
+}

package/assets/hooks/sql-guard-write.sh

@@ -0,0 +1,212 @@
+#!/usr/bin/env bash
+# Запись для гарда хранилища: что считается записью, что из неё заведомо разрушительно, куда
+# идут миграции и по чему запрос адресует строки.
+#
+# Строки `# rt-hook:` здесь нет намеренно: событие и образец вызова объявляет сам гард, а
+# помощник рядом хуком не регистрируется и в одиночку ничего не решает.
+
+# Глаголы ищутся в сегментах ВЫЗОВА, а не по всей строке: иначе слово из шаблона поиска в
+# соседнем звене цепочки объявляло записью читающую команду.
+sql_detect_write() {
+    is_write=""
+    write_scope="$segments"
+    # `copy … from` и `select … into` — запись, не называющая ни одного привычного глагола.
+    printf '%s' "$write_scope" | grep -qE '(^|[^[:alnum:]_])(delete|update|insert|truncate|drop|alter|create|grant|revoke|copy)([^[:alnum:]_]|$)|\\copy|into[[:space:]]+[a-z_"]' \
+        && is_write="yes"
+    # Конвейер из источника в клиент — та же доставка файла, только без флага: содержимое
+    # `cat fix.sql | psql …` гарду не видно, значит это запись по определению.
+    while IFS= read -r seg; do
+        [ -z "$seg" ] && continue
+        printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_.-])(cat|head|tail|gzcat|zcat|gunzip|echo|printf|curl|wget)([[:space:]]|$)' \
+            && is_write="yes" && break
+    done <<PIPE_EOF
+$(client_segments)
+PIPE_EOF
+
+    # Команды prisma меняют базу, не называя ни одного SQL-глагола: `migrate reset` пересоздаёт
+    # её целиком, `db push` подгоняет схему под модель, `db execute` льёт произвольный файл.
+    printf '%s' "$write_scope" | grep -qE 'prisma[[:space:]]+(migrate[[:space:]]+(reset|deploy|dev)|db[[:space:]]+(push|execute))' \
+        && is_write="yes"
+
+    # Глагол в командной строке — не единственный способ довезти SQL до сервера. Файл (`-f`,
+    # `--file`, `< dump.sql`) и `pg_restore` не называют ни одного, поэтому раньше проходили
+    # мимо всех трёх уровней: доставка файла в клиент на боевой базе завершалась нулём
+    # без единого вопроса, а `pg_restore` не мог сработать в принципе, хотя `--clean` сносит
+    # содержимое. Содержимое файла гарду недоступно — значит это запись по определению.
+    printf '%s' "$flat" | grep -qE '(^|[^[:alnum:]_.-])pg_restore([^[:alnum:]_.-]|$)' \
+        && is_write="yes"
+    # У `pg_dump` тот же `-f` означает файл ВЫВОДА: это чтение, и записью его считать нельзя —
+    # иначе штатное снятие дампа с боевой базы отклонялось, хотя текст отказа сам его советует.
+    #
+    # Исключение действует ПОСЕГМЕНТНО. Пока оно проверялось по всей команде, одного упоминания
+    # `pg_dump` где угодно в цепочке хватало, чтобы `-f` перестал считаться записью во всех
+    # остальных вызовах: `pg_dump … > /dev/null && psql -d app -f /tmp/x.sql` проходил молча.
+    while IFS= read -r seg; do
+        [ -z "$seg" ] && continue
+        # Граница слова обязательна: `-f /tmp/pg_dump-restore.sql` — это заливка дампа, а не
+        # его снятие, и подстрочное совпадение снимало с неё обе защиты разом.
+        if printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_.-])pg_dump(all)?([^[:alnum:]_.-]|$)'; then
+            continue
+        fi
+        # Хвост сегмента после имени клиента: `-f` у `docker compose` (боевой compose-файл
+        # называется нестандартно, без флага не поднимается) стоит ДО `psql` и к запросу
+        # отношения не имеет.
+        seg_tail="$(printf '%s' "$seg" | perl -0pe 's{^.*?(?<![[:alnum:]_./-])(psql|pg_restore|prisma)(?=\s|$)}{$1}s' 2>/dev/null)"
+        [ -z "$seg_tail" ] && seg_tail="$seg"
+        if printf '%s' "$seg_tail" | grep -qE '(^|[[:space:]])(-f|--file)([[:space:]]|=)|<[[:space:]]*[^[:space:]|<]+\.(sql|dump)'; then
+            is_write="yes"
+            break
+        fi
+    done <<EOF
+$segments
+EOF
+}
+
+# --- заведомо разрушительное ------------------------------------------------------------
+verdict() {
+    if [ -n "$soft" ]; then
+        ask "Запрос помечен маркером destructive-ok, но остаётся разрушительным: $1 Подтверди выполнение, если это осознанно."
+    fi
+    deny "BLOCKED: $1 Адресуй строки по первичному ключу — \`WHERE id IN ('…','…')\`: так затрагивается ровно столько строк, сколько перечислено, и промах виден до выполнения. Удаление по маске (email LIKE '%test%') однажды унесло вместе с тестовыми записями демонстрационные брони владельца. Если адресация по id действительно не подходит — сначала выполни SELECT с тем же условием, покажи пользователю, что попадает под удаление, и помечай запрос маркером destructive-ok с объяснением."
+}
+
+sql_check_destructive() {
+    soft=""
+    case "$flat" in
+        *destructive-ok*) soft="yes" ;;
+    esac
+
+    if printf '%s' "$flat" | grep -qE '(^|[^[:alnum:]_])(truncate|drop[[:space:]]+(table|database|schema|column|index)|alter[[:space:]]+table)([^[:alnum:]_]|$)'; then
+        verdict "запрос меняет саму схему или очищает таблицу целиком (${context})."
+    fi
+
+    if printf '%s' "$flat" | grep -qE 'prisma[[:space:]]+(migrate[[:space:]]+reset|db[[:space:]]+push)'; then
+        verdict "\`prisma migrate reset\` / \`db push\` пересоздаёт базу и теряет её содержимое (${context})."
+    fi
+
+    # `pg_restore --clean` перед загрузкой удаляет существующие объекты — то же очищение
+    # таблиц, только чужими руками. Без `--clean` это обычная догрузка, она идёт общим путём.
+    if printf '%s' "$flat" | grep -q 'pg_restore' && printf '%s' "$flat" | grep -qE '(^|[[:space:]])(--clean|-c|--create)([[:space:]]|=|$)'; then
+        verdict "\`pg_restore --clean\` удаляет объекты базы перед загрузкой дампа (${context})."
+    fi
+}
+
+# Штатное применение миграций разрушительным не считается. Раньше здесь стоял безусловный
+# `ask` со словами «убедись, что DATABASE_URL указывает на локальную базу» — гард
+# перекладывал на человека ровно ту работу, которую умеет сделать сам. На локальной базе
+# миграции гоняются постоянно, и вопрос на каждую не добавляет безопасности: гард, который
+# спрашивает по десятому разу, перестают читать вместе с тем единственным вопросом, который
+# был важен.
+#
+# Поэтому адрес РАЗРЕШАЕТСЯ, а не угадывается: сначала inline-префикс самой команды, затем
+# переменная окружения, затем `.env` рабочего каталога.
+unquote() {
+    sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' -e 's/^"//' -e 's/"$//' -e "s/^'//" -e "s/'$//"
+}
+
+resolve_database_url() {
+    # Искать по `$flat` нельзя: он приведён к нижнему регистру, и `DATABASE_URL=` в нём
+    # не встречается никогда — правило молча брало бы адрес из `.env`, игнорируя явно
+    # указанный в команде. Разбирается исходная строка, а `$flat` остаётся запасным
+    # вариантом с регистронезависимым поиском.
+    inline="$(printf '%s' "${cmd:-}" | grep -oE '[Dd][Aa][Tt][Aa][Bb][Aa][Ss][Ee]_[Uu][Rr][Ll]=[^[:space:]]+' | tail -n1)"
+    [ -z "$inline" ] && inline="$(printf '%s' "$flat" | grep -oiE 'database_url=[^[:space:]]+' | tail -n1)"
+    if [ -n "$inline" ]; then
+        printf '%s' "${inline#*=}" | unquote
+        return
+    fi
+    if [ -n "${DATABASE_URL:-}" ]; then
+        printf '%s' "$DATABASE_URL" | unquote
+        return
+    fi
+    # Подъём по дереву, а не только рабочий каталог: агент работает в git worktree под
+    # `.claude/worktrees/<ветка>/`, где своего `.env` нет, а у основного чекаута — есть,
+    # и он лежит ровно выше по пути. Без подъёма гард не разрешил бы адрес ни разу
+    # именно там, где миграции и гоняются.
+    dir="$hook_cwd"
+    depth=0
+    while [ -n "$dir" ] && [ "$dir" != '/' ] && [ "$depth" -lt 8 ]; do
+        for env_file in "$dir/.env" "$dir/.env.local"; do
+            [ -f "$env_file" ] || continue
+            value="$(grep -m1 -E '^[[:space:]]*DATABASE_URL=' "$env_file" 2>/dev/null | sed -e 's/^[[:space:]]*DATABASE_URL=//' | unquote)"
+            if [ -n "$value" ]; then
+                printf '%s' "$value"
+                return
+            fi
+        done
+        dir="$(dirname "$dir")"
+        depth=$((depth + 1))
+    done
+}
+
+sql_check_migrations() {
+    if printf '%s' "$flat" | grep -qE 'prisma[[:space:]]+migrate[[:space:]]+(deploy|dev)'; then
+        migrate_target="$(resolve_database_url)"
+        # Боевой адрес проверяется ДО разбора по видам: туннель к бою тоже висит на петлевом
+        # адресе, только на своём порту, и общее правило «петлевой значит локальный» пропустило бы
+        # миграцию на бой.
+        if [ -n "$PROD_DSN" ] && printf '%s' "$migrate_target" | grep -qE "$PROD_DSN"; then
+            deny "BLOCKED: применение миграций к БОЕВОЙ базе (${context}). Адрес базы ведёт на бой. Схема на бою меняется выкаткой: она сама зовёт применение миграций одноразовым контейнером до старта приложения. Руками этого делать нельзя — гард обойти нельзя."
+        fi
+        case "$migrate_target" in
+            *@localhost:*|*@127.0.0.1:*|*@postgres:*|*@host.docker.internal:*)
+                # Локальная база — штатная работа. Разбор завершается здесь, иначе ниже
+                # сработает общее правило про запись в базу и вопрос всё равно будет задан:
+                # `migrate deploy` помечен записью выше по тексту.
+                #
+                # Но выйти можно, только если запись в команде ОДНА — сама миграция. В цепочке
+                # `prisma migrate deploy && psql -c "delete …"` ранний выход снял бы проверку со
+                # второго звена, а это ровно тот обход, ради которого гард и написан.
+                other_write=""
+                printf '%s' "$write_scope" \
+                    | grep -qE '(^|[^[:alnum:]_])(delete|update|insert|truncate|drop|alter|create|grant|revoke|copy)([^[:alnum:]_]|$)|\\copy|into[[:space:]]+[a-z_"]' \
+                    && other_write="yes"
+                while IFS= read -r seg; do
+                    [ -z "$seg" ] && continue
+                    printf '%s' "$seg" | grep -qE '(^|[^[:alnum:]_.-])(cat|head|tail|gzcat|zcat|gunzip|echo|printf|curl|wget)([[:space:]]|$)' \
+                        && other_write="yes" && break
+                done <<MIGRATE_PIPE_EOF
+$(client_segments)
+MIGRATE_PIPE_EOF
+                [ -z "$other_write" ] && exit 0
+                ;;
+            '')
+                ask "Применение миграций к базе (${context}), но адрес разрешить не удалось: DATABASE_URL нет ни в команде, ни в окружении, ни в \`.env\` рабочего каталога. Проверь, куда пойдёт миграция, и подтверди."
+                ;;
+            *)
+                ask "Применение миграций по адресу, НЕИЗВЕСТНОМУ ГАРДУ (${context}). Гард знает локальные адреса и боевые; этот — ни то, ни другое. Убедись, что это не прод, и подтверди."
+                ;;
+        esac
+    fi
+}
+
+# --- delete/update: смотрим на адресацию ------------------------------------------------
+sql_check_addressing() {
+    if printf '%s' "$flat" | grep -qE '(^|[^[:alnum:]_])(delete[[:space:]]+from|update)([^[:alnum:]_]|$)'; then
+        if ! printf '%s' "$flat" | grep -q 'where'; then
+            verdict "DELETE/UPDATE без WHERE затрагивает всю таблицу (${context})."
+        fi
+
+        # Адресация ищется ТОЛЬКО в хвосте после последнего `where`. Пока смотрели на весь
+        # запрос, присваивание в SET засчитывалось за адресацию: `UPDATE bookings SET
+        # "propertyId" = 'p1' WHERE source = 'site'` выглядел адресным, хотя задевал все прямые
+        # заявки объекта — ровно то, от чего гард и защищает.
+        # Регистр здесь сохраняется, в отличие от `flat`: колонки Prisma пишутся в camelCase, и
+        # приведённый к нижнему регистру `bookingid` уже не отличить от слова `paid`.
+        where_tail="$(printf '%s' "$sql" | tr '\n\t' '  ' | sed -E 's/.*[Ww][Hh][Ee][Rr][Ee]/where/')"
+
+        # Имя колонки требуется целиком: `id`, `booking_id`, `"bookingId"`. Прежний шаблон
+        # `[a-z_]*id` принимал за идентификатор `paid` и `valid`.
+        if ! printf '%s' "$where_tail" | grep -qE '(^|[^[:alnum:]_"])"?(id|[A-Za-z_]+_id|[a-zA-Z]+Id)"?[[:space:]]*(=|[Ii][Nn][[:space:]]*\()'; then
+            verdict "DELETE/UPDATE адресует строки не по идентификатору (${context}) — условие может совпасть шире, чем задумано."
+        fi
+
+        # Гард видит имя колонки, но не схему: `propertyId` и `session_id` — внешние ключи, и
+        # запрос по ним адресный только на вид. `DELETE … WHERE "propertyId" = 'p1'` сносит все
+        # брони объекта. Отличить это от первичного ключа без схемы нельзя, поэтому решение
+        # остаётся за пользователем — но предупреждение должно быть прямым, а не общим.
+        if ! printf '%s' "$where_tail" | grep -qE '(^|[^[:alnum:]_"])"?id"?[[:space:]]*(=|[Ii][Nn][[:space:]]*\()'; then
+            ask "Условие адресует строки по ВНЕШНЕМУ ключу, а не по первичному (${context}): $(printf '%s' "$where_tail" | head -c 200). Под него попадут ВСЕ строки, связанные с этой сущностью, — например \`WHERE \"propertyId\" = …\` заденет все брони объекта, включая демонстрационные. Если нужны конкретные строки, сперва выбери их SELECT-ом и перечисли в \`WHERE id IN (…)\`."
+        fi
+    fi
+}