Stoic Citadel — Надійне виконання на Python/MT5
Особиста інженерна розробка для інтеграції з брокером: обробка ордерів, збереження стану й перевірки ризику. Кейс показує роботу з відмовами без обіцянок торгового прибутку.
Переглянути матеріалиХронологія
2026
Роль
Розробник
R&D
Тип проєкту
Paper
Режим виконання
SQLite
Журнал ордерів
Інженерний результат
Ордер → постійний журнал → відновлення
Чесний вплив
Обмежений paper-пілот із явними станами ордерів, перевірками ризику й правилами відновлення, постійним журналом та незалежним моніторингом.
Матеріали проєкту
Що зроблено й що можна переглянути
- Обсяг роботи
- Нативна архітектура виконання Python/MT5, постійний журнал ордерів, перевірки ризику й незалежний watchdog.
- Що перевірено
- Опис архітектури спирається на репозиторій і межі локальних регресійних перевірок безпеки. Схема ілюструє інженерну реалізацію.
- Межі доказів
- Нове приймання у брокера для кейсу не виконувалося. Межа пілоту — paper-режим та вимкнені входи. Торгова перевага, повний контрольований цикл ордера й готовність до production не заявляються.
Інженерний кейс · особистий R&D
Нативний MT5: виконання та відновлення
Поточна архітектура для контрольованого paper-пілота. У центрі — життєвий цикл ордера й обробка збоїв; схема пояснює реалізовані компоненти.
Нативний шлях виконання
Paper-режим · входи вимкненіСтратегія
Сигнал за закритими свічками стає версіонованим наміром з обмеженим строком дії.
Безпека й ризик
Стоп-лос, свіжість котирувань, ліміти обсягу та збережені зупинки обмежують допуск.
Виконавець із прив’язкою до рахунку
Один власник життєвого циклу перевіряє ідентичність рахунку й звіряє відповіді брокера.
MetaTrader 5
Захищений міст утворює межу брокера. У paper-режимі ордери не надсилаються.
Журнал ордерів SQLite
Збережені наміри й контрольні точки допомагають звірці після перезапуску. Невідомий результат не спричиняє сліпого повторного надсилання.
Незалежний контролер
Окремий процес перевіряє відкриті позиції та heartbeat; захисне закриття прив’язане до конкретного тикета.
Ілюстрація архітектури. На цій сторінці немає підключення до брокера чи керування торгівлею.
проблема
Підтвердження брокера може загубитися, а процес — перезапуститися з відкритою позицією. Відновлення не має наосліп надсилати той самий ордер повторно.
Виклик
Зберегти одного власника життєвого циклу ордера, перевіряти допуск перед записом у брокера та звіряти невизначені результати.
Рішення
Я звузив нативний MT5-пілот до виконавця з прив’язкою до акаунта, автентифікованого мосту, обов’язкового журналу SQLite й незалежного watchdog. Redis зберігає стан ризику та heartbeat.
Технічні особливості
Один власник життєвого циклу нативного MT5-ордера; попереднє Freqtrade/ML-дослідження відокремлене.
Обов’язковий SQLite-журнал і звірка з брокером після перезапуску або втрати відповіді.
Перевірки стоп-лосу, свіжості котирувань, обмежень обсягу та ідентичності рахунку до запису брокеру.
Незалежний контролер і захисне закриття конкретного тикета позиції.
Локальні регресії для відмов, невідомих результатів, збережених зупинок і меж відновлення.
Типово paper-режим і вимкнені входи; негативне walk-forward-дослідження збережене без обіцянки прибутку.
Архітектура системи
Python · AsyncIO (native pilot lifecycle)
MetaTrader 5 · account-bound HTTP bridge
FastAPI · authenticated broker boundary
SQLite (mandatory order journal and restart reconciliation)
Redis (risk state and heartbeat)
Independent equity watchdog
Pytest · Hypothesis (local safety regressions)
Docker (persistent local Redis)
Основні технології
Пов'язані проєкти
Потрібна Python-система зі зрозумілою обробкою відмов?
Я розробляю API-інтеграції та бекенди з явними станами, корисними журналами й правилами відновлення. Починаємо з однієї обмеженої інтеграції та погоджуємо, як її перевірити.