misterfrukt3/oborudsh

Purpose and entry points

Оборудыш is a Telegram Mini App for reserving filming equipment and room 626 at Media BMSTU. The browser client starts at prototype/index.html; its Telegram-facing backend and bot process are combined in bot/main.py. The system is deployed as one production service and one SQLite-backed instance.

Mini App client

The static Mini App provides catalog browsing, reservation flow, navigation, screens, and visual presentation:

• prototype/index.html

• prototype/style.css

• prototype/catalog.js

• prototype/texts.js

It runs inside Telegram Web Apps and calls backend HTTP endpoints. The catalog is also shipped client-side, making the UI catalog a deliberate boundary from server-side availability and reservation enforcement.

API, bot, and authentication boundary

bot/main.py hosts aiohttp API routes and an aiogram 3 Telegram bot in the same Python runtime. It validates Telegram Mini App identity, serves application bootstrap/state, accepts booking-related actions, and handles bot commands such as migration. Telegram is the identity and notification channel; browser requests must cross the Telegram init-data authorization boundary before accessing user-specific data.

Reservation and availability domain

The backend owns booking state, equipment availability, room scheduling, request lifecycle, and conflict prevention. Its central orchestration is in:

• bot/main.py

• bot/equipment.json

• bot/catalog.js

Equipment metadata is maintained as structured catalog data; bot/update_catalog_from_csv.py is the controlled import path for catalog updates. Client and server catalog representations must remain aligned, while the backend remains authoritative for occupied dates and accepted requests.

Persistence and operational jobs

SQLite persistence is embedded in the backend process, storing users, registration-derived fields, reservations, and local accrual data. A scheduler in bot/main.py handles time-based workflow actions, such as reservation lifecycle transitions and notifications. The architecture is intentionally single-instance: production must not run a second bot or database.

External integrations

Telegram Bot API and Mini App runtime are core external dependencies. Google Sheets is optional: registration may be populated from a restricted люди sheet, and accruals can be synchronized while retaining local persistence when Sheets is disabled. Server-sent events from bot/main.py provide real-time client updates where applicable.

Supporting operational interfaces

User-facing Telegram copy is centralized in bot/texts.py. Migration from a legacy button bot is a one-way administrative workflow: it reads the old database directly without changing the new database. Runtime dependencies and environment contract are defined in:

• bot/requirements.txt

• bot/.env.example

• DEPLOY.md