Work goes in as a ticket. It comes out as a merge request.
Задача входит тикетом. Выходит merge request'ом.
Rubka reads the requirement, finds the service it touches, writes the change in your repository's own style, builds it, runs the service against its tests — and opens a merge request with the evidence attached. A person approves every stage.
Рубка разбирает требования, находит нужный сервис, пишет изменение в стиле вашего репозитория, собирает его, поднимает сервис и гоняет автотесты — и открывает MR, к которому приложены доказательства. Каждую стадию утверждает человек.
Every run is visible end to endПрогон видно целиком
Each stage leaves a document you can read, challenge and send back. Nothing moves on until a person agrees to it.
Каждая стадия оставляет документ, который можно прочитать, оспорить и вернуть на доработку. Ничего не уходит дальше, пока человек не согласился.
What it doesЧто делает
Not an assistant that suggests — a worker that finishes the job: a branch, a commit, a merge request, a ticket, a report.
Не ассистент, который советует, — исполнитель, который доводит работу до артефакта: ветки, коммита, MR, тикета, отчёта.
Carries a task end to endВедёт задачу целикомpipelineпайплайн
From requirements to an open MR with tests — with stages, artefacts and the decisions behind them.
От разбора требований до открытого MR с тестами — со стадиями, артефактами и историей принятых решений.
Triages failing testsРазбирает паденияtriageтриаж
Tells a product defect from a broken test and from an environment problem — and brings the evidence, not a guess.
Отличает дефект продукта от дефекта теста и от проблемы стенда — и приносит доказательство, а не догадку.
Takes the night shiftДежурит по ночамroutinesрутины
Overnight triage of the test and load runs: the team arrives to a report instead of a red board.
Ночной разбор автотестов и нагрузочных прогонов: утром у команды готовый отчёт, а не красная доска.
Knows your architectureЗнает архитектуруmapкарта
Services, contracts and dependencies are extracted from the code itself and kept current — unlike a wiki.
Сервисы, контракты и зависимости извлекаются из самого кода и обновляются — в отличие от вики, которая устаревает.
The platform around the workПлатформа вокруг работы
An agent that writes code is half of it. The other half is what makes it usable by a company: who may do what, whose context it works in, which model runs it, and where the result lands.
Агент, который пишет код, — это половина. Вторая половина — то, что делает его пригодным для компании: кто что может, в чьём контексте он работает, на какой модели и куда приходит результат.
Roles and accessРолевая модельrolesроли
Administrator, manager, engineer and a read-only demo seat. Accounts are issued, not self-registered; the product's own source stays admin-only and every attempt to reach it is logged.
Администратор, менеджер, инженер и демо-доступ «только смотреть». Учётки заводит администратор, самостоятельной регистрации нет; исходники самой платформы видны только администраторам, попытки доступа фиксируются.
Teams on one shared contextКоманды в едином контекстеprojectsпроекты
A person belongs to one or several projects and sees their own work; the map of the estate — repositories, services, contracts, dependencies — stays shared and current for everyone.
Пользователь привязан к своим проектам и видит свою работу; карта среды — репозитории, сервисы, контракты, зависимости — общая и поддерживается автоматически для всех.
Model choice and switchingВыбор и смена моделиmodelsмодели
Pick the model per user, per run or per stage: the strongest one writes code, a cheaper one reads tickets. The admin keeps a pool of accounts and switches the active one without stopping work in flight — and the same merge request can be reviewed by a model from a different vendor, so no model marks its own homework.
Модель выбирается на уровне пользователя, прогона или отдельной стадии: сильная пишет код, быстрая разбирает тикет. Администратор держит пул учёток и переключает активную, не останавливая идущие прогоны, — а тот же merge request можно прогнать через модель другого вендора, чтобы модель не проверяла сама себя.
Messengers and emailМессенджеры и почтаnotificationsуведомления
Telegram works both ways: a stage waiting for a decision arrives with Approve / Re-run / Comment buttons. Reports go to email and to the team channel in the corporate messenger.
Telegram работает в обе стороны: стадия, ждущая решения, приходит с кнопками «Утвердить / Перезапустить / Комментарий». Отчёты уходят на почту и в канал корпоративного мессенджера.
One integration circuitЕдиный контур интеграцийintegrationsинтеграции
Issue tracker, GitLab, CI, test management, monitoring and logs, secret storage. Each person acts under their own tokens, so the tracker and GitLab show a human, not a shared robot.
Трекер задач, GitLab, CI, тест-менеджмент, мониторинг и логи, хранилище секретов. Каждый работает под своими токенами — в трекере и GitLab виден живой человек, а не общий робот.
Secrets stay secretsУправление секретамиsecretsсекреты
Personal integration tokens are stored encrypted; runtime credentials are pulled from the corporate vault for the duration of a run and destroyed afterwards.
Персональные токены интеграций хранятся зашифрованными; доступы для запуска берутся из корпоративного хранилища на время прогона и уничтожаются после.
Everything is on the recordЖурнал действийauditаудит
Who started it, who approved it, who sent it back, what was published to the tracker, which access changed — an append-only journal an administrator can read.
Кто запустил, кто утвердил, кто вернул на доработку, что опубликовано в трекер, какие доступы менялись — журнал только на дозапись, доступный администратору.
Scheduler and unattended workПланировщик и автономная работаscheduleрасписание
A run can be scheduled for a given time, and recurring routines run on cron with no one at the keyboard — the result lands in email and the messenger.
Прогон ставится на конкретное время, регулярные сценарии идут по расписанию без человека — результат приходит на почту и в мессенджер.
Inside your perimeterВ вашем периметреon-premна своих мощностях
Deployed on the customer's own machines — code and data never leave. Parallel runs are isolated from each other and their resources are capped.
Ставится на мощности заказчика — код и данные не покидают периметр. Параллельные прогоны изолированы друг от друга, ресурсы ограничены.
You stay in controlКонтроль остаётся у команды
Automation with no room for self-deception: green is never claimed for red.
Автоматизация без права на самообман: система не выдаёт красное за зелёное.
A gate on every stageГейт на каждой стадии
Send a document back with comments — the next stage does not start until this one is accepted.
Документ можно вернуть с замечаниями — следующая стадия не начнётся, пока предыдущая не принята.
No test is fixed by weakening itТест не «чинится» ослаблением
A failure gets explained. If the environment is down, it says so instead of "all good".
Падение разбирается по существу. Если стенд недоступен — так и написано, а не «всё хорошо».
A separate instance per clientОтдельный контур на клиента
Own server, own database: code and data never mix with anyone else's.
Свой сервер и своя база: код и данные не смешиваются с чужими.
Every MR has its runК каждому MR есть прогон
Stages, artefacts, logs and reviewer notes are kept — you can see where a change came from.
Стадии, артефакты, логи и правки ревьюера сохраняются — видно, откуда взялось изменение.
Get in touchСвязаться
Rubka runs on a live production estate and grows with it. If you want to see what it does on your own tasks — write to us.
Рубка работает на реальном продуктовом контуре и развивается вместе с ним. Если хотите посмотреть, как это выглядит на ваших задачах — напишите.