Nimbus Docs

Appearance

Задачи для Junior-разработчика (безопасные для ядра расчётов) ​

Документ содержит 5–7 конкретных задач, которые:

  • не затрагивают ядро расчётов (ПП 354, Ledger, балансы, движок начислений);
  • приносят пользу проекту (справочники, UI, выгрузки, улучшение UX);
  • подходят для разработчика с опытом использования AI (Cursor и др.) при условии соблюдения онбординга.

Перед началом любой задачи обязательно прочитать онбординг (раздел 2 — жёсткие архитектурные правила).

Задача 1. CRUD для справочника «Типы помещений» (RoomKind / назначение помещений) ​

Суть: Доработать или реализовать полный CRUD в админке для справочника типов помещений (например RoomKind, RoomPurpose — в зависимости от текущей модели в core-service). Справочник используется при создании/редактировании помещений (Room).

Где смотреть:

  • Backend: services/core-service/internal/handlers/, internal/models/ (room_kind.go, room_purpose.go и т.п.).
  • Frontend: frontend/src/crud-dashboard/ — по аналогии с другими справочниками (organizations, house dictionaries).

Ограничения: Только CRUD по справочнику. Не менять связи Room ↔ House, не трогать логику начислений.

Польза: УК может самостоятельно вести типы помещений без правки БД/сидов.

Задача 2. CRUD для справочника «Отделы и должности» организации ​

Суть: Реализовать или доработать UI (список, создание, редактирование, удаление) для отделов и должностей организации. API в core-service уже может быть частично реализован (registerDepartments в routes, handlers/departments.go).

Где смотреть:

  • Backend: services/core-service/internal/handlers/departments.go, модели department, position.
  • Frontend: frontend/src/crud-dashboard/data/departments.ts, компоненты по аналогии с organizations/houses.

Ограничения: Не менять структуру организаций и роли пользователей (RBAC). Только справочник отделов/должностей.

Польза: Удобное управление структурой организации в одном месте.

Задача 3. Выгрузка списка лицевых счетов в Excel ​

Суть: На странице списка лицевых счетов (PersonalAccountList) добавить кнопку «Скачать Excel». По нажатию — запрос к API (GET с параметрами фильтрации, как в списке), формирование на backend файла .xlsx со столбцами: номер ЛС, адрес, собственник, дата открытия/закрытия, статус (и т.д. по текущей модели). Отдача файла через Content-Disposition: attachment.

Где смотреть:

  • Backend: новый endpoint в services/core-service/internal/handlers/personal_accounts.go (или отдельный handler export). Библиотека: например excelize для Go.
  • Frontend: frontend/src/crud-dashboard/components/personal-account/PersonalAccountList.tsx — кнопка, вызов API, скачивание по ссылке или через fetch + blob.

Ограничения: Только чтение существующих данных. Не менять расчёт, балансы, начисления. Экспорт только тех полей, которые уже есть в модели ЛС.

Польза: УК может выгружать реестр ЛС для отчётов и сверок.

Задача 4. Выгрузка списка услуг дома (тарифы/нормативы) в Excel ​

Суть: В карточке дома (HouseShow) или в списке услуг дома добавить кнопку «Выгрузить в Excel»: выгрузка списка услуг дома с тарифами и нормативами на выбранный период (если применимо) в формате .xlsx.

Где смотреть:

  • Backend: services/core-service/internal/handlers/houses.go, house_services — данные уже доступны через API. Новый endpoint вида GET /api/organizations/:orgId/houses/:houseId/services/export?format=xlsx.
  • Frontend: frontend/src/crud-dashboard/components/house/HouseShow.tsx, вкладка услуг — кнопка экспорта.

Ограничения: Только чтение. Не менять тарифы, нормативы и правила расчёта (ПП 354). Экспорт = снимок данных на момент запроса.

Польза: Удобная передача тарифов в бухгалтерию или контролирующие органы.

Задача 5. Компонент «Фильтр по периоду» (месяц/год) для переиспользования ​

Суть: Вынести в общий UI-компонент выбор периода (месяц + год) в виде двух селектов или DatePicker’ов (только месяц/год). Использовать его на страницах отчётов, начислений, платежей (где уже есть или планируется фильтр по периоду).

Где смотреть:

  • Frontend: frontend/src/crud-dashboard/ или frontend/src/dashboard/ — создать компонент, например PeriodFilter.tsx в components/ или shared/. Подключить в существующих страницах (расчёты, отчёты).

Ограничения: Только UI. Не менять API и логику расчётов. Компонент должен быть «тупым» (управляемый извне через props: value, onChange).

Польза: Единообразный выбор периода по приложению, меньше дублирования кода.

Задача 6. Страница «Отчёты»: каркас и список типов отчётов ​

Суть: Реализовать страницу «Отчёты» (Reports), на которой отображается список доступных типов отчётов (например: «Начисления за период», «Задолженность по ЛС», «Платежи за период») в виде карточек или меню. По клику — переход на отдельную страницу/модальное окно с параметрами (период, дом, организация) и кнопкой «Сформировать» / «Скачать». Само формирование отчёта может быть заглушкой (например, показывать сообщение «В разработке» или возвращать тестовый Excel), если бэкенд отчётов ещё не готов.

Где смотреть:

  • Frontend: frontend/src/dashboard/pages/ReportsPage.tsx (если есть заглушка — заменить на каркас с пунктами меню и навигацией).
  • Роутинг: добавить подстраницы или query-параметры для выбора типа отчёта.

Ограничения: Не реализовывать расчёт отчётов на backend (это ядро). Допустимо: заглушки, моки, позже — вызов уже готовых API экспорта.

Польза: Пользователь видит структуру раздела отчётности; позже сюда подключаются реальные отчёты.

Задача 7. Улучшение форм: валидация и сообщения об ошибках (на примере одной сущности) ​

Суть: Выбрать одну форму (например создание/редактирование лицевого счёта или собственника) и улучшить UX:

  • Валидация полей на фронте (обязательные поля, формат ИНН/номера, даты).
  • Понятные сообщения об ошибках под полями и в тосте.
  • Блокировка кнопки «Сохранить» при невалидной форме или показ списка ошибок.

Где смотреть:

  • Frontend: frontend/src/crud-dashboard/components/personal-account/PersonalAccountForm.tsx, OwnerForm.tsx или аналог.
  • Использовать существующие паттерны валидации в проекте (например в data/personal-accounts.ts — validate).

Ограничения: Не менять API контракты и бизнес-правила (например правила открытия/закрытия ЛС). Только улучшение отображения ошибок и валидации на клиенте.

Польза: Меньше некорректных данных и понятнее обратная связь пользователю.

Как выбирать и выполнять задачи ​

  1. Согласовать с тимлидом/CTO приоритет (можно начать с 1, 2 или 5, 7 — они не зависят от готовности billing).
  2. Перед правками перечитать онбординг, особенно раздел 2. Не вносить изменений в:
    • формулы и коды ПП 354 в core-service;
    • логику расчёта в billing-service;
    • обновление балансов через UPDATE (только проводки/Ledger, когда они появятся).
  3. При использовании AI проверять сгенерированный код на соответствие правилам выше и стилю проекта (Go: handlers, models; React: существующие паттерны в crud-dashboard).
  4. После реализации — убедиться, что не сломаны существующие сценарии (список ЛС, создание дома, отображение услуг и т.д.).

Дорожная карта по этапам описана в roadmap_3m.md. Задачи из этого файла можно выполнять параллельно этапам MVP и интеграций.