Brabo API (0.1.0)

Один ключ в обычном режиме; два — во время ротации AUTH_JWT_SECRET.

Несуществующий email, неверный пароль и заблокированная учётная запись возвращают ровно один и тот же ответ 401 — то же тело, тот же статус.

Всегда 204, даже для неизвестного токена — ответ 401 здесь стал бы оракулом валидности токена.

Успех ведёт на WEB_ORIGIN/ с уже установленными cookie сессии; неудача — на WEB_ORIGIN/login?oauth_error=1, без указания причины.

state подписывается HMAC со СВОИМ назначением — никогда не с назначением потока подключения git к проекту (см. ADR 0084).

Предъявленный refresh расходуется. Повторное предъявление уже ротированного токена отзывает ВСЁ семейство и записывает событие безопасности — даже если причиной была двойная отправка клиентом.

Отвечает 202 и для нового адреса, и для уже зарегистрированного — ответ не раскрывает, существует ли учётная запись. Во втором случае ничего не создаётся, а владелец адреса получает уведомление.

Отвечает 202 и для известного, и для неизвестного адреса. Это также путь для тех, кто был импортирован из Keycloak и ещё не задал пароль.

Отзывает ВСЕ сессии пользователя. Не выдаёт токены: тот, кто сбрасывает пароль, отправляется на вход, чтобы компрометация email не означала захват учётной записи за один шаг.

Декларативный индекс gate потока (ADR 0054). Экран берёт отсюда, какие шаги существуют и кто оценивает каждый, вместо того чтобы повторять список в коде — именно так он раньше незаметно устаревал.

Цикл gate, застрявший более чем на 2 ч, паркуется, а не перезапускается сам (ADR 0207). Это жест человека, который его возобновляет.

Публичный, потому что приходит БРАУЗЕР пользователя от провайдера, без сессии api. Это не значит без ограничений: state проверяется HMAC, и без валидного вызов отклоняется. Никогда не отвечает JSON — всегда перенаправляет, потому что сырое тело ошибки при навигации в браузере было бы ужасным опытом.

Основа для заявленного незакрытого вопроса blame (ФАЗА 26b) — интерфейса, аннотирующего редактор построчно, ещё нет. truncated предупреждает, когда файл превысил лимит аннотируемых строк.

Основа для расширенного выпадающего списка (ФАЗА 26b) — сегодня селектор ref является простым текстовым полем. ahead/behind отсчитываются от ветки репозитория ПО УМОЛЧАНИЮ; null, когда провайдер не может это вычислить (честная деградация, а не ошибка). Это НЕ listBranches (который использует bootstrap Gitflow) — это отдельная операция, потому что обогащение стоит лишнего вызова провайдера НА КАЖДУЮ ВЕТКУ.

UTF-8, обрезается на лимите байтов с truncated: true, если он превышен. Путь, выходящий за папку проекта, отклоняется с 400 центральной проверкой из RN-095 — никогда с 404, что приглашало бы к зондированию.

Основа для навигируемого списка (ФАЗА 26b) — сегодня diff доступен только по известному id (например, пришедшему из Одобрений); этот маршрут решает, как дойти до id, не зная его наизусть. truncated предупреждает, когда список превысил лимит на вызов.

Нулевой patch отличает случай, когда провайдер не передал текст (бинарный файл или слишком большой патч), от случая, когда текст вернулся пустым. Слияние двух заставило бы экран говорить, что изменённый бинарный файл не изменился. Поле truncated предупреждает, когда список файлов превысил лимит.

Поиск НЕ является операцией контракта git: он составлен из дерева и содержимого, и поэтому это единственное чтение, стоимость которого растёт с размером репозитория. Его ограничивают три бюджета — пройденные каталоги, открытые файлы и возвращённые совпадения, — а truncated говорит, что он остановился. filesScanned показывает понесённые затраты.

Не рекурсивно, по замыслу контракта: вкладка навигирует по требованию, а запрос всего дерева большого репозитория — именно тот усилитель трафика, который эта фаза запрещает. truncated предупреждает, когда уровень превысил лимит записей.

Не перенаправляет: возвращает URL, чтобы клиент решил, когда отправить браузер. state подписан HMAC, и именно это не даёт подделать callback.

СИНХРОННО: ответ приходит только после выполнения всего bootstrap (постоянные ветки, защиты, шаблоны) — за этим нет ни worker, ни очереди. Это ИДЕМПОТЕНТНО И ВОЗОБНОВЛЯЕМО, поэтому повторный вызов после сбоя продолжает с шага, на котором произошёл сбой. Следите за прогрессом и читайте причину сбоя через GET /projects/:id/git/bootstrap.

Проверяет доступ через getRepo и составляет ПЛАН (dry-run) того, что сделал бы bootstrap, — недостающие ветки, недостающие защиты, файлы. В репозитории НИЧЕГО не выполняется: решите потом через plan/approve или plan/skip. Повторное подключение того же репозитория сходится (план генерируется заново без дублирования строки).

На каком шаге он находится, был ли сбой и где, и сколько было попыток. Пошаговые детали берутся из событий bootstrap.step_* выделенной сессии.

protect_branches завершается сбоем в приватном репозитории на бесплатном тарифе, и мастер предупреждает об этом ЗАРАНЕЕ. Без этого выхода единственной кнопкой было «Попробовать снова», что всегда проваливается по той же причине, — а provision_failed заставляет панель перенаправлять проект обратно на страницу создания, делая его недоступным навсегда. Подтвердить можно только сбой при ЗАЩИТЕ: это последний шаг и единственный, сбой которого оставляет пригодный репозиторий. Блокировка merge продукта (RN-006) не зависит от защиты провайдера и продолжает действовать.

decision: null при наличии плана — это состояние, в котором НИЧЕГО не выполняется: ожидание одобрения или подключения как есть (RN-045).

Одобрение — всё или ничего: одобрение отдельных шагов сломало бы каскад dev←main, qa←dev, rc←qa. Выполняется план, ЗАНОВО ВЫВЕДЕННЫЙ в момент выполнения, — равный показанному или меньше, но никогда не больше.

Записывает решение и не трогает репозиторий. План остаётся сохранённым как доказательство того, что сознательно не было применено, а курсор bootstrap НЕ изменяется — ни один шаг не выполнялся.

Выполняет select 1. Сообщает только, отвечает ли база данных; ни топологии, ни версии. Публичный, потому что вызывающий — kubelet, у которого нет токена.

НАМЕРЕННО НЕ касается базы данных. Если бы касался, медленный Postgres перезапустил бы ВСЕ реплики сразу и превратил деградацию в полный отказ. Pod убирается из балансировщика нагрузки через /health.

Не JSON: это text/plain в формате экспозиции. Публичный по необходимости (сборщик не несёт токена) и ограничен СЕТЬЮ — Ingress продакшена блокирует этот путь на границе, а NetworkPolicy разрешает только пространство имён мониторинга.

Прокси GitHub Releases — platform принимает только linux-x64, linux-arm64, darwin-arm64. Без аутентификации: бинарный файл не секрет. Байты сверяются с checksums.txt той же Release до того, как что-либо будет отдано (ADR 0149, RN-525); маршрут НЕ проверяет подпись манифеста — это целостность, а не происхождение, и подпись проверяет install.sh.

Для установщика в одну строку, который работает там, где почтовый транспорт не настроен: сгенерированный .env не содержит почтовых переменных, MAIL_TRANSPORT падает в log, и обычная регистрация ждёт письма, которое никогда не придёт. Учётная запись рождается подтверждённой, потому что тот, кто запускает установщик, уже доказал нечто БОЛЕЕ СИЛЬНОЕ, чем контроль над почтовым ящиком, — он контролирует машину, .env и демон Docker. Обычная регистрация не затрагивается. Отклоняет с 409, если в установке есть ЛЮБОЙ пользователь: условие касается установки, а не этого email, поэтому восстановление при миграции глушит шаг той же проверкой. Пароль здесь никогда не генерируется и нигде не хранится, кроме как в виде хеша argon2id; личное рабочее пространство (RN-410) рождается в той же транзакции.

Реестр ОПИСЫВАЕТ, а не исполняет: ни один gate не становится обязательным из-за него, и изменение поля здесь не меняет никакого поведения. Каждый gate говорит, где находится доказательство его прохождения (evidencia), потому что не каждое доказательство есть в журнале событий.

Если для того же name уже существует версия с ТЕМ ЖЕ хешем, новая версия не создаётся — возвращается существующая (попадание идемпотентности не меняет HTTP-статус: всегда 201, для простоты — тело идентично тому, что было бы создано).

Конкретная version ищется по равенству; если опущена, ищется самая свежая версия active. 404, если шаблон (или запрошенная версия) не существует.

Для установщика в одну строку, сразу после создания первой учётной записи: локальному агенту нужны учётные данные, а единственные существовавшие были привязаны к ПРОЕКТУ — в установке, где проектов ещё нет. Пара генерируется НА МАШИНЕ, и сюда приходит только публичная половина; запишите возвращённый id в приватный JWK как kid (RN-475) — это единственная связь между файлом на диске и публичной половиной на сервере. userId в теле НЕТ НАМЕРЕННО: владелец — ЕДИНСТВЕННЫЙ пользователь установки, определяемый api, поэтому владение сервисным токеном никогда не означает выбор, чьи учётные данные выпустить. Регистрация ЗАМЕНЯЕТ: активные машинные ключи владельца отзываются в той же транзакции, так что переустановленная машина работает, а тысяча машинных ключей существовать не может. Ключи проекта (ADR 0118) никогда не затрагиваются.

Никогда не падает из-за одного провайдера: каждый отвечает за себя в отчёте, с причиной пропуска и источником сбоя, если он был. Провайдер, который не ответил, ПРОПУСКАЕТСЯ, а не помечается недоступным.

ТО ЖЕ дерево эпик → история → задача, что и во вкладке Backlog, через тот же сценарий использования (три чтения на проект, никогда N+1). Именно с ним PO видит эпик без историй и историю без задач, вместо того чтобы заново создавать уже существующее (RN-164).

Все artifact.business_rule из сессий проекта — не только текущей сессии, что было потолком контекста kickoff у PO, — с полным description и тем, какие истории уже ссылаются на каждое правило. uncoveredCount — это незакрытое: правило, которое не покрывает ни одна история (RN-164). Проект совсем без правил отвечает 200 с пустым списком: «ни одного правила ещё не собрано» — не ошибка.

Вызывается только engine, когда Engine.Actions.TerminalExecutor решил, что команда должна выполняться внутри настоящего контейнера (execution_mode: container с ЗАРЕГИСТРИРОВАННОЙ строкой running). Проксирует в ContainerBrokerPort.exec (ADR 0130/0134) — последняя из пяти операций broker, получившая реального вызывающего. sucesso: false в ответе — никогда не выброшенная ошибка — это НОРМАЛЬНАЯ форма для отказавшего или недоступного broker: контейнер мог умереть или быть удалён извне между зарегистрированной строкой running и этим вызовом (RN-486, зарегистрированное и наблюдаемое никогда не сливаются), и это сбой команды, а не ошибка транспорта.

Идентичность проекта, режим выполнения и текущее решение Архитектора об образе. Broker перепроверяет всё это, прежде чем что-либо передать демону, — читать отсюда не то же самое, что доверять, и отказ называет поле. АБСОЛЮТНЫЙ путь не возвращается: источник bind разрешается демоном относительно файловой системы ХОСТА, и путь изнутри контейнера api молча смонтировал бы пустую папку. Передаётся localizacao (RN-503) — какой из двух корней broker использовать плюс относительный сегмент, который этот корень не покрывает.

Возвращает чистый origin (без встроенных учётных данных) и, для удалённого провайдера, токен ВЛАДЕЛЬЦА рабочего пространства (RN-058), расшифрованный на лету. Потребитель внедряет токен при каждом вызове и НИКОГДА не записывает его в файл — .git/config находится внутри папки, где RN-075 даёт dev agent автоматически одобренный доступ на чтение.