Аудит начислений ЖКХ — рабочий документ продукта

1. Что делаем (продукт)

Android-приложение — local-first компанион к ЖКХ для тех, кто не понимает систему. Журнал показаний + аудит начислений + объяснялка над паспортом приборов. Без серверов и аккаунтов.

Формулировка ядра изменена 28.07.2026. Прежняя — «журнал счётчиков + объяснялка + паспорт приборов». Причина: разбор чеков показал, что боль и деньги живут в начислениях, а показания — лишь один из источников данных для их проверки. H5 при этом не менялась: ядро боли по-прежнему непрозрачность.

Модель данных — четыре уровня

Четвёртый уровень обязателен и неочевиден: у одного прибора может быть несколько учётных записей с разными числами. Самоаудит, прибор ГВС 1256973: физически 310, у Горводоканала 310, у Генерации Сибири 341,925, у Квадиса 70,0 (не обновлялось с 01.08.2025). Метод начисления тоже разный: Горводоканал считает по прибору, Генерация Сибири — по нормативу. Поэтому «поставщик» и «метод начисления» не являются полями прибора.

Ядро

• Аудит начислений (новое ядро, 28.07.2026). Пользователь загружает чеки из агрегатора; приложение строит полный список получателей, находит начисления не по прибору, ловит появление новых платных услуг и аномальные суммы. Механика проверки едина для всех услуг: начисление = параметр × ставка. Счётчик даёт параметр прибором, ТКО — числом проживающих, капремонт — площадью. Детали — Разбор_чеков_Платосферы_вердикты.md.

  • Детекция норматива не требует справочника ставок: сумма по услуге неподвижна N месяцев подряд, пока соседние услуги того же адреса меняются → флаг «здесь считают не по твоему прибору». Различитель против фиксированных платежей (содержание жилья, текущий ремонт) — наличие прибора у этой услуги, известное из паспорта.
  • Диффы между чеками (появился получатель, выросла сумма, сменилось название) работают вообще без справочника — самая надёжная и дешёвая часть механики.
  • Приложение не отвечает за пользователя. Периода начисления в чеке нет, поэтому догон за прошлый месяц неотличим от роста начисления. Формулировка — вопрос («это за два периода или изменилась ставка?»), а не утверждение.

• Объяснялка — семь тем, выведенных из данных, а не из предметной области:

  1. Кто мои поставщики, чем РСО отличается от УК (Никита, Данил, самоаудит)
  2. Какие цифры передавать: чёрные vs красные (Кирилл; deep-research: ошибка превращает 13 м³ в 1124 м³)
  3. Какой счётчик горячий и где он стоит (самоаудит: «потрогал счётчик рукой»)
  4. По счётчику или по нормативу мне считают (самоаудит, Маргарита)
  5. До какого числа передавать и что будет при пропуске (все респонденты; заблуждение Витали «санкций нет»)
  6. Не приняли показания / пришёл норматив — что делать (процедура из самоаудита §6)
  7. Поверка: когда, кто вправе, где акт (Оксана, Кирилл)

  Темы 1–5 — короткие ответы контекстными карточками в месте возникновения вопроса. Темы 6–7 — процедуры, живут в разделе, но вход в них контекстный. Дизайн-актив — контекстный вход, а не раздел помощи.

• Справочник — сужённый и датированный (решение 24.07.2026):

  • объём ограничен 4–6 лично верифицированными поставщиками, а не «всеми поставщиками Новосибирска»;
  • каждая запись несёт возраст данных и источник («Проверено 23.07.2026, gensib54.ru») + кнопку «сообщить, что устарело»;
  • принцип наполнения — «форма универсальна, детали локальны»: справочник хранит универсальные процедуры (ПП 354) и честно говорит «позвони и спроси» там, где данные локальны до уровня одной УК. Добытые звонком контакты и шаги записывает сам пользователь → фильтр «чьи данные» проходит.

• Паспорт приборов. Не функция, а объект, над которым работают все три функции: журнал в него пишет, аудит читает фактический расход и пишет обратно метод начисления, объяснялка читает место установки, поверку и контакты. Состав — по уровням модели данных выше. Разрядность работает как параметр валидации ввода, а не как текст: приложение не даёт ввести число не той длины. Это боль Кирилла, решённая механически.

• Ожидаемые приборы из чека решение 28.07.2026 приборов в чеке нет, но из услуг выводится, какие приборы должны существовать («Горводоканал берёт за воду → у тебя должен быть счётчик ХВС»). Это не предзаполнение, а предзаполненное ожидание — оно учит и убирает пустой экран после онбординга. Требует таблицы «услуга → бывает ли индивидуальный прибор» (см. открытые вопросы), которая может ошибаться → обязательное «проверь».

• Съём: все счётчики объекта на одном экране, ввод в любом порядке — форма не диктует маршрут по квартире; порядок списка настраивается перетаскиванием один раз (дефолт — порядок добавления). Камера/OCR — гигиена и ускоритель (ML Kit, on-device), с автофонариком; сверка с историей («расход 40 м³ при среднем 4 — перепроверь»).

  • Сохранение — локальное и поштучное, без подтверждения: мы журнал, а не форма. Ввод доступен всегда; ограничение окна — мягкое и на отправке, с возможностью обойти. Обоснование: окна у поставщиков разные, у Квадиса не установлено вовсе, а справочник может ошибаться (риски №5 и №11). Disabled-поле, запрещающее доступное действие, — вред.

• Передача — вспомогательный шаг, не ядро: подготовленные цифры → буфер/диплинк в агрегатор пользователя (Платосфера, Квартплата+); SMS/email — для поставщиков, где канал жив (газ, Горводоканал, частный сектор). Сгруппирована по поставщику, потому что канал у каждого свой; единой кнопки «отправить всё» не существует и быть не может. С агрегаторами за акт передачи не конкурируем — уводим в них.

• Мультиобъектность поддержана моделью данных, но не является позиционированием: боль полностью раскрывается на одном объекте.

Чего в продукте НЕТ (осознанно)

• Оплаты — потребовала бы интеграций с поставщиками/банками и бэкенда. Оплата остаётся в агрегаторе/банке; апп может напоминать «оплатить до 10-го».
• Бэкенда и аккаунтов — все данные локально. «Данные не покидают телефон» — приватность как фича и аргумент в сторе.
• OCR как УТП — камера есть, но это гигиена (OCR коммодитизирован, см. §6).
• Собственной доставки показаний «в один тап» — рельсы агрегаторов. Фильтр «чьи данные»: их рельсы = не наш продукт. Вопрос закрыт, не возвращаемся.
• Автоматического определения поставщиков по адресу отклонено 28.07.2026 — датасета «адрес → РСО/УК» у нас нет; ГИС ЖКХ дырява и не наши данные. Главное: самоаудит показал, что даже вручную собранная карта каналов даёт 1 попадание из 4 и путает организации. Автовыдача — это риск №11, помноженный на масштаб. Вместо неё — разбор чеков самого пользователя.
• Облачного OCR / распознавания на сервере отклонено 28.07.2026 — Яндекс Vision и аналоги требуют отправки платёжного документа с ФИО и адресом на чужие мощности. Ломает local-first, то есть заявленную фичу и аргумент в сторе.
• Композитного скора «ЖКХ здоровье» отклонено 28.07.2026 — шкала склеивала бы полноту наших данных с состоянием чужих финансов; посчитать её нечем (неизвестны число прописанных, площадь, реальные долги), веса пришлось бы выдумать. Прямое нарушение принципа «не выдумывать метрики» и обесценивание честно снятой метрики времени. Замена: счётчик открытых находок с суммой денег («3 вопроса · около 200 ₽/мес») и отдельно названная полнота данных («заполнено 5 из 7 поставщиков»).
• Базы тарифов по стране отклонено 28.07.2026 — единого бесплатного источника нет, ставки утверждаются региональными приказами. Норматив детектируется по константе без ставок; ставки хранятся только для 4–6 верифицированных поставщиков и только чтобы назвать величину переплаты.

2. Для кого и какие боли

Ядро сегмента — «непонимающие систему» (в интервью — преимущественно 25–33): передают показания, но не понимают, кому, что и почему; не знают, туда ли уходят цифры; не различают поставщиков; узнают о поверке постфактум через переплату. 5 из 9 респондентов. Мультиобъектники как отдельный сегмент закрыты интервью: их оркестрацию уже решили агрегаторы.

Боли:

• Непрозрачность: «передаю двум из четырёх поставщиков, не знаю, правильно ли» (Никита); месяцы неверных показаний из-за непонимания «каких цифр» (Кирилл); «не передаю электричество вообще, не разбираюсь» (Маргарита).
• Не опознал собственный счётчик → норматив (самоаудит, подтверждено поставщиком): строка поставщика в агрегаторе воспринимается как «непонятный счётчик неизвестно где» и игнорируется годами. Итог — ~200 ₽/мес сверх факта, невидимые из интерфейса.
• Не знает, кому вообще платит чеки, 28.07.2026 на одном адресе семь получателей и семь лицевых счетов. Автор проекта после двух дней самоаудита недосчитывал двоих.
• Не знает состояния лицевого счёта чеки за какой период заплачено, есть ли долг, догон это или рост начисления — из документа определить невозможно. Расширение H3.
• Дрейф учётного показания поставщика: цифра поставщика уходит вперёд от физического прибора (341,925 против 310). Пока разрыв не выбран, ни один канал не примет реальное показание.
• Поверка: пропущенный срок → норматив → переплата (Оксана). Акт поверки нужен как документ-ключ при исправлении начислений.
• Надёжность доставки отзывы «показания и деньги приняли, а до поставщика не довели» → норматив/переплата. Агрегатор — чёрный ящик без следа переданного.
• Платная услуга по дефолтной галочке (Кирилл; воспроизведено на авторе — страховка 180 ₽ в мартовском чеке).
• Боли внутри агрегаторов: откат показаний и лимит ввода без объяснений (Данил), форма диктует маршрут по квартире (Александра), отказ без причины (Платосфера «Ошибка. Показания не переданы» против Сбербанка «Нельзя передать меньше 341.925 м³»).

Что НЕ болит (и мы не лечим):

• Связка «передал → сразу оплатил» критична не всем — многие сознательно платят через банк отдельно.
• Оркестрация мультиобъекта (решена агрегаторами); ручной разрыв (фото/бумажка — удобный workaround); пропуски окон передачи показаний (не беспокоят).
• Время цикла. Самозамер: 1 мин 30 с. Экономить нечего — см. §8 риск №3.

3. Конкуренты и отличие

Наше отличие: «слой понимания и контроля над рельсами агрегаторов». Агрегаторы отвечают на «передай и заплати», мы — на «что вообще происходит и всё ли я делаю правильно».

Ключевой фильтр идей: «если ценность продукта живёт в данных, которых у тебя нет, — продукта нет». Наши данные вводит или приносит сам пользователь → фильтр пройден.

Платосфера принадлежит одному из поставщиков чеки, 28.07.2026 правообладатель платёжного сервиса — АО «Новосибирскэнергосбыт», ИНН 5407025576, система «Сфера Энергии». Агрегатор, через который житель платит семи получателям, принадлежит одному из них. Попутно объясняет, почему электроэнергия в нём обслужена лучше остального.

Оговорка о хрупкости ядра (24.07.2026, усилена 28.07.2026). Справочник — ядро ценности и одновременно главный источник риска. Карта каналов оказалась верна для 1 из 4 поставщиков одного адреса, перепутала две разные организации и не знает троих получателей из семи. Отсюда решения §1. Врущая объяснялка хуже отсутствующей.

4. Механика отправки и дизайн-активы

Приложение НЕ отправляет ничего само. Оно готовит отправку и передаёт её в руки пользователя через системные механизмы Android (Intent). Поэтому: нет бэкенда, нет 152-ФЗ (мы не оператор ПДн), нет анонимных писем — поставщик идентифицирует не отправителя, а лицевой счёт в тексте.

Ветки доставки: A — email (открываем почтовый клиент с заполненным письмом) · B — SMS (открываем «Сообщения» с номером и текстом) · C — буфер (кладём цифры в буфер, юзер вставляет в свой ЛК/агрегатор) · D — чат-боты (диплинк с предзаполненным текстом).

Приоритет: C → B/A → D. Полной автоматизации не будет и не надо: тихая пакетная отправка запрещена Android, финальный тап всегда за юзером. «Очередь отправки» как конвейер из 6 каналов — в архив: 0/9 пользователей SMS/email/ботов.

Подтверждено самоаудитом: на реальном адресе по веткам A/B/D доступен 1 поставщик из 4, по ветке C — все четыре.

Дизайн-активы

1. «Форма не диктует маршрут» — свободный порядок ввода + настраиваемый список против навязанной последовательности «по услугам» (Александра; подтверждено отзывами).

2. Прогрессивное раскрытие доменной сложности — объяснить структуру ЖКХ без превращения приложения в лонгрид (запрос Данила). Форма — контекстные карточки, а не раздел помощи.

3. «Личная квитанция переданного» — датированный след «что и когда я сдал» как доказательство при споре. Строго в рамках «чьи данные»: логируем отправленное, не подтверждаем доставку.

4. Предупреждение до отправки переопределено 28.07.2026 — инлайн под полем ввода: показание меньше учётного, аномальный расход, окно закрыто. Не «объяснить отказ», а не допустить его: собственного экрана отказа у нас быть не может, отказ происходит в чужом приложении.

5. Разбор чужого отказа 28.07.2026 — отдельный вход «не приняли показания?»: что мог написать чужой сервис и что это значит. Отсюда вход в процедуру исправления (акт поверки → акт контрольных показаний → заявление). Второй вход в ту же процедуру — из результата аудита. Обоснование — пара скриншотов Платосфера/Сбербанк.

6. «Единый день передачи» — пересечение окон всех поставщиков адреса одной датой. У автора: НЭС 23–26 ∩ Горводоканал до 25 ∩ Генерация Сибири 15–25 = 23–25. Краевой случай: пересечение может быть пустым — тогда фича вырождается в «минимальное число походов», и это проектируется явно.

7. Аудит начислений по чекам новый, 28.07.2026, главный актив — онбординг просит три чека, принимает один (уточнено 28.07.2026: прежние «6–12 месяцев» — избыточное требование к старту). Порог смысла: 1 чек — получатели, ЛС и суммы; 2 — диффы; 3 — детекция норматива (ниже трёх константа неотличима от совпадения); 4–6 — удвоения и догоны; 12 — годовая сумма против долга. Состав получателей меняется от месяца к месяцу, поэтому после разбора обязательна оговорка о неполноте. Дальнейшая загрузка — необязательное поддержание, предлагается в момент оплаты.

8. «Расхождения по одному прибору» новый, 28.07.2026 — четыре числа одного прибора в одном месте: физическое, и по каждому поставщику отдельно, с датой последнего обновления. Ни один агрегатор этого не показывает, потому что каждый показывает свою колонку. Герой экрана паспорта; заодно бесплатная проверка H7.

9. Три слоя достоверности в карточке поставщика новый, 28.07.2026 — каждая строка показывает своё происхождение: из твоего чека (название, ЛС, услуги, суммы — факт), из справочника (канал, окно, формат, телефоны — с датой проверки), неизвестно (окно Квадиса, локальные процедуры — «позвони и запиши»). Различение на уровне строк, не дисклеймером внизу. Интерфейсная митигация риска №11 и предмет проверки в Блоке Б. Выросло из провала собственного ресёрча, а не из абстрактной прозрачности.

Технические ограничения парсера чеков для этапа 2 PDF содержит текстовый слой, OCR не нужен. Разбор идёт по координатам текстовых блоков, а не по порядку в потоке — порядок строк в извлечённом тексте не совпадает с визуальным. Самотест: сумма услуговых строк обязана сходиться с полем «Итог»; не сошлась — разбор считается неудавшимся и уходит в ручной ввод. Разметка Квартплаты+ своя и не проверена (см. открытые вопросы).

Ввод файла — share target как основной путь решение 28.07.2026 приложение регистрируется приёмником PDF, пользователь жмёт «Поделиться» в агрегаторе или в почте. Ноль файлового менеджмента, работает с любым источником, стоит одной строки в манифесте. Файловый пикер с мультивыбором — фолбэк. Самый устойчивый источник чеков — почта: Платосфера шлёт чек на e-mail при каждой оплате, и эта инструкция не устареет вместе с чужим интерфейсом.

5. Технический стек и ограничения

Бюджет: Claude Pro + Figma Starter (Free), $0 сверху.

Жёсткие ограничения: без бэкенда и серверов; без платных API; всё локально; справочник обновляется с релизами приложения и обязан показывать дату проверки.

6. Рынок и UX передачи показаний в РФ (выжимка deep-research #1)

Полный текст — Пользовательский_опыт_передачи_показаний.md. Здесь только то, что влияет на решения:

• OCR коммодитизирован (Сбер, «Электронный дом», Госуслуги.Дом) → строить УТП на камере нельзя.
• Проблема сужается сверху умными счётчиками: электро ~12% базы, полный переход к ~2038; вода и тепло почти не автоматизированы.
• Массовая путаница «какие цифры»: захват красной цифры превращает 13 м³ в 1124 м³ — обоснование разрядности как параметра валидации.
• Передача и оплата разнесены по времени и каналам; отказ от оплаты — приемлемая модель, но лишает «липкости» (осознанный трейд-офф).
• Аудитория велика: Госуслуги.Дом 20+ млн установок; в одной Москве ~6,5 млн человек ежемесячно передают показания.
• Отзывы смещены в негатив, удовлетворённость выше, чем кажется — это не голубой океан, и не надо.
• Самый острый сегмент — мультиобъектники → опровергнуто интервью.

7. Карта каналов Новосибирска (рабочая версия)

Первоисточник — Карта_каналов_передачи_показаний.md (deep-research #2). Таблица ниже — рабочая версия с правками самоаудита 23–24.07.2026 и чеков 28.07.2026; при расхождении верна она.

Доверие к карте пересмотрено трижды. Deep-research #2 обещал покрытие полуавтоматикой ~3 из 4 якорных ресурсов — живая проверка дала 1 из 4. Карта перепутала СГК (sibgenco.ru, федеральный холдинг) и ООО «Генерация Сибири» (gensib54.ru, ИНН 5405436860, локальная РСО) — разные организации с разными каналами и телефонами. И карта неполна: троих получателей платежей по адресу автора в ней нет вовсе.

Инсайты:

• Три несовместимых синтаксиса (пробел / запятые / решётка) + разные окна + пять каналов = никто не держит это в голове. Сам факт, что понадобился deep research, — доказательство боли.
• Ни SMS-first, ни email-first. По реальному адресу живой SMS-канал остался один. Ветка C — не ограничение, а рынок.
• Услуги без приборов не бесканальны, а беспараметренны: передавать нечего, но параметр начисления есть, он лежит в чужой базе, не показывается и может быть неверным.
• Пересечение окон по адресу автора: 23–25 (без Квадиса, окно которого не установлено).

8. Оставшиеся риски

9. Продуктовые принципы

Рабочие принципы сотрудничества — в project-instructions.md. Здесь только то, что касается самого продукта:

• Фильтр «чьи данные»: ценность на данных, которых у нас нет, = нет продукта.
• Не конкурировать с бесплатными продуктами государства и банков в их зоне (съём/OCR, оплата).
• Справочник не притворяется всезнающим: лучше «не проверено» и «позвони и спроси», чем уверенная неверная цифра.
• Приложение спрашивает там, где не может знать. Период начисления, догон против роста, число проживающих — вопрос пользователю, а не утверждение от имени системы.
• Данные не покидают телефон. Любое решение, требующее сервера, проверяется на конфликт с этим до обсуждения деталей.