Measured from the GitHub API by the same workflow that rebuilds every other number here — no third-party stat services, no external cards. Languages are counted by how many repositories use them, not by bytes of code.
Four things I do the same way in every repository, and the artefacts you can check them against.
- Mechanism over memory — anything that matters is a script or a gate, not a habit. A convention nobody enforces is a convention that will be skipped on the day it matters most.
- Public rules over private habit — the workflows, the conventions and the trade-offs are written down and versioned, so they can be read without taking my word for it. Every rule in the shared catalogue gets an answer from this repository — adopted and by what mechanism, rejected and why, or no subject here — in
.rules/bindings.json. - Incidents over folklore — a rule exists because something broke. Each one carries the failure it grew from, and they live together in a public catalogue rather than in my head.
- Measured over hand-written — every number on this page is rebuilt from its source by a daily job. A number nobody measures is a number that rots, and it rots quietly.
- Agent work, signed and traceable — the work here is done in agent sessions, and the history says so: every commit carries who did it and a link to the session that produced it. Over the last 30 days that is 100 of 100 work commits — machine rebuilds excluded, because a scheduled job takes no decisions to sign for. A gate refuses the ones that don't, before the merge rather than after.
One worked example, not the whole argument. On the flagship repository the branch protection is public and machine-readable: 1 required checks on main (read the ruleset yourself), over 13 releases; behind them a test matrix of 3 operating systems × Python 3.14 with no experimental, published by the project itself in its facts file — check either instead of believing this line. The other repositories hold the same shape at their own maturity; this one simply has the most to show.
| CI & merge automation | stronger gates, less manual shepherding |
| Regression coverage | every fixed bug leaves a test behind |
| English documentation | full parity with the Russian docs tree |
| Local web UX | making --serve the primary workflow, not the fallback |
The repositories above are not parallel products competing for attention. They are one sequence, and the order is deliberate. Stepik-Python-Grader — today's flagship — was the first real project, the glossary's cards later moved into it and are exported from there, and every infrastructure repository here grew out of a problem hit while building it. The three infrastructure repositories — steps 1 to 3 below — do the job a project manager would: between me as the client and AI agents as the development team, they hold the pace, the rules and the reusable machinery for everything else. So they are finished first, and the same mistake is not paid for again in every repository.
- Shared pipeline mechanisms — done when every project has moved onto them completely; who already calls the shared steps is measured by their own run, not claimed here. Until then they grow more universal and configurable; afterwards they join the catalogue's cycle: a new rule, a gate built for it, handed out to the family.
- Rule catalogue — every rule carries its incident; it collects new rules and skills from the projects and hands them out to all.
- Development pace control from session telemetry.
- Glossary — finishing the cards, paused until the infrastructure holds.
- The grader. A quiet grader or glossary in the activity above is this order at work, not an abandoned project.
- One infrastructure project on a local server — the catalogue, the mechanisms and pace control as modules of one project, each free to update its own module at any time; developed on a local server alongside git.
- A lighter version without git — asked for by people who do not work through git.
- The main automation project — a modular platform for analytics, reporting and budgeting. It gets its own repository when there is code to show, not before.
- Taxes for the self-employed — preparing and filing the data.
- A project for coaches — exercises, records and the like; for now an idea.
A plan, not a promise with dates: the order can change, and this section changes with it.
Python · pytest · Hypothesis · Ruff · mypy · GitHub Actions · PyPI · Playwright
CLI tooling · local web UI · benchmarking · OS sandboxing · docs architecture · release automation · typed boundaries · property-based testing
Мейнтейнер open-source на Python. Я не рассчитываю на то, что вспомню: всё существенное здесь держат проверки. Перед коммитом бежит один набор, перед слиянием другой, и уговорить их нельзя — сломанное просто не уезжает дальше. Это не строгость к себе, а экономия: помнить два десятка договорённостей дороже, чем один раз их записать так, чтобы за ними следила машина.
Правила у меня не берутся из головы. Каждое выросло из конкретной поломки, и рядом с ним записано, из какой именно — 215 действующих записей в общем каталоге, одном на все репозитории. Каждый отвечает по каждому правилу: принял и чем держит, отклонил и почему, предмета нет — и ответ сверяется гейтом, а не совестью. Правило, за которым не бежит ничего, на витрине видно отдельной долей: если его прятать, картинка всегда выглядит хорошо.
Числа на этой странице я не пишу руками — их пересобирает workflow из тех репозиториев, которые их порождают. Причина простая: число, которое никто не измеряет, устаревает молча, и первым это замечает не автор, а читатель. Когда источник не отвечает, страница показывает вчерашнюю картинку и говорит об этом вслух, вместо того чтобы подставить правдоподобное.
Куда это движется. Репозитории выше — не параллельные продукты, а одна последовательность. Первым был грейдер; карточки глоссария позже переехали в него и экспортируются оттуда, а три инфраструктурных проекта — механизмы конвейера, каталог правил и контроль темпа по телеметрии сессий — родились из проблем, найденных при его разработке. Они делают работу руководителя проектов: держат темп, правила и общие механизмы между мной как заказчиком и ИИ-агентами как командой. Сначала доделывается эта инфраструктура, чтобы не наступать на одни и те же грабли в каждом репозитории: механизмы готовы, когда на них полностью перешли все проекты, и это меряет их собственный прогон, а не слова здесь. Затем глоссарий и грейдер; после них — единый проект инфраструктуры на локальном сервере, облегчённая версия без git, главный проект автоматизации аналитики, отчётности и бюджетирования, налоги для самозанятых и проект для тренеров. Это план, а не обязательство с датами.



