Alex Ant
f0311afaa7
* [598-10][@ant] feat: backend Эпика 7 «Гарантийный возврат» (Stories 7.1-7.4) — завести MarketplaceReturnClaimService с 5 mutations (submretrn/aprretrem/rejretrem/accretrn/rejretrn) и хранилище фото в bucket stol-zakazov:images — Domain: ReturnClaim entity + types (5 статусов pendrev/approvvisit/accepted/rejremote/rejatku с маппингом на ReturnStatus::* контракта), decision_log append-only журнал решений председателя, on_site_inspection-снапшот очного осмотра, ledger_snapshot снапшот compensating-forward пары после accretrn. Photo type хранит bucket_key + sha256 content_hash + mime_type — хеш используется как анкер on-chain (параметр photos[] submretrn). — Repository: create/findById/findByRequestHash/findActiveByOrderId (idempotency check) /listByOrderer/listByDeliveryBraname/applyDecision (append к decision_log + опциональная фиксация on_site_inspection / ledger_snapshot). Partial-unique индекс (coopname, order_id) ограниченный активными статусами — пайщик не может одновременно открыть две заявки на один заказ. — Canonical blockchain port + adapter: 5 новых методов submRetrn/aprRetRem/rejRetRem/accRetrn/rejRetrn — обёртки над marketplace::submretrn/aprretrem/rejretrem/accretrn/rejretrn (контракты уже реализованы в cpp/marketplace/src/p.mkt.return/). accretrn — композитная транзакция через транзит 91: o.mkt.return + o.mkt.return2 (compensating forward к o.mkt.consum, AR9/AR14 L3). — MarketplaceReturnClaimService: submitReturnClaim (Story 7.1: валидация warranty_until>now, reason_text 1-500, photos 1-10, request_hash детерминирован от order_hash+orderer+actual_quantity, фото загружаются в bucket до on-chain submit, on-chain photos[] = sha256-хеши), approveReturnVisit/rejectReturnRemote (Story 7.2 FR31: PENDING_CHAIRMAN_REVIEW → APPROVED_FOR_VISIT/REJECTED_REMOTELY, comment обязателен), acceptReturnAtVisit/rejectReturnAtVisit (Story 7.3-7.4 FR32-FR33: APPROVED_FOR_VISIT → ACCEPTED_AT_VISIT/REJECTED_AT_VISIT, при accept атомарно compensating forward o.mkt.return+o.mkt.return2 восстанавливает w.mkt.member.available заказчика и возвращает имущество на склад КУ, barcode-сверка с Order). getReturnClaimSignablePayload — preview через factory registry_id=800 (ReturnByAssetStatement, переиспользован для членской модели по стандарту p.mkt.return.standard.yaml). — MarketplaceReturnClaimImagesService: @UseBucket('stol-zakazov:images') — конвенция «один сервис на один bucket» из README file-storage. maxBytes 10MB, allowedMime jpeg/png/webp, metadataSchema требует ownerAccount+orderId+claimId. Ключ объекта детерминирован: returns/<claim_id>/<role>/<index>.<ext>; backend хеширует bytes (sha256-hex) — этот же хеш идёт on-chain в submretrn.photos[]. — Resolver + DTO: 5 mutations + 3 queries (marketplaceListMyReturnClaims, marketplaceListReturnClaimsByBraname, marketplaceReturnClaimSignablePayload, marketplaceReturnClaim) + Photo/Decision/Inspection/Ledger ObjectType. GraphQL enum через registerEnumType (MarketplaceReturnClaimStatus / MarketplaceReturnClaimDefectCategory / MarketplaceReturnClaimExpectedResolution). Подписанное заявление приходит как SignedDigitalDocumentInputDTO meta=MarketplaceReturnClaimSignedStatementInputDTO; toDocument() конвертит в Cooperative.Registry.ReturnByAssetStatement.Action для submretrn.statement. — Signed-document DTO: переиспользуем шаблон 800 «Заявление на возврат паевого взноса имуществом» (по стандарту p.mkt.return — структурно совместим с членской моделью; поля request.hash/title/units/unit_cost/total_cost заполняются из Order). request.hash = backend-computed request_hash → двусторонняя сверка backend ↔ on-chain. — Access-matrix: orderer ['create:own', 'read:own'] на ReturnClaim, operator ['read:own-KU', 'decide:remote', 'decide:on-site']. resolver-уровень проверка ownership (orderer_account == member.username, braname == председатель чьего КУ — отложено до core coop_ku.chairman_account, в MVP передаётся параметром). — Регистрация в marketplace-infrastructure.module.ts (TypeORM entity + repository) и marketplace-application.module.ts (FileStorageInfrastructureModule.forFeature + service + resolver). Why: реализация Эпика 7 «Гарантийный возврат имущества» MVP «Стол Заказов» — пайщик подаёт заявление с фото-доказательством, председатель КУ удалённо рассматривает и при необходимости приглашает на очный осмотр, при принятии возврата атомарно через транзит 91 восстанавливаются средства на программном кошельке заказчика и имущество возвращается на склад участка (compensating forward — отдельное событие в журнале, не revert исходного o.mkt.consum). Возврат поставщику и работа с поставщиком по претензиям — Phase 2 (out of MVP). * [598-10][@ant] feat: notifications Эпика 7 — 3 Novu workflow и слушатели per-contract event-bus (submitted/decided/finalized) для гарантийного возврата — @coopenomics/notifications: 3 workflow: marketplace-return-claim-submitted (председателю КУ на новое заявление; email + in-app + push с deep-link на operator-стол), marketplace-return-claim-decided (заказчику на промежуточные решения председателя — invite на очный визит), marketplace-return-claim-finalized (заказчику на финальный исход с восстановленной суммой если accept_at_visit). — controller: 3 события в marketplace-notification.events.ts — MARKETPLACE_RETURN_CLAIM_SUBMITTED_EVENT/DECIDED/FINALIZED + типы payload. Сервис эмитит их после save в PG (INV-12). — marketplace-notification.service.ts: 3 listener (handleReturnClaimSubmitted/Decided/Finalized) тянут subscriber_id/email из AccountDataPort, формируют payload с display-name и deep-link через config.frontend_url, шлют через NovuWorkflowPort. Ошибки доставки logged как warn — основной flow возврата не блокируется. Why: уведомления (push/email/in-app) — обязательный канал коммуникации по UX-DR38; заявление на гарантийный возврат должно дойти до председателя КУ без поляризации UI (председатель не всегда сидит в operator-столе), решение председателя — до заказчика без необходимости вручную проверять статус заявления. * [598-10][@ant] feat: SDK Эпика 7 — Zeus selectors, 5 mutations и 3 queries для гарантийного возврата + перегенерированная schema.gql — Selectors: marketplaceReturnClaimSelector (полный набор полей заявления вместе с photos / decision_log / on_site_inspection / ledger_snapshot), marketplaceReturnClaimResultSelector (claim + tx_hash) и поднаборы (photo / decision-entry / inspection / ledger). Валидаторы MakeAllFieldsRequired гарантируют полное покрытие type. — Mutations: CreateReturnClaim / ApproveReturnVisit / RejectReturnRemote / AcceptReturnAtVisit / RejectReturnAtVisit. Каждая принимает соответствующий Input DTO и возвращает marketplaceReturnClaimResultSelector. — Queries: ListMyReturnClaims (без args), ListReturnClaimsByBraname (data.delivery_braname), ReturnClaimSignablePayload (data.order_id + actual_quantity? — preview registry_id=800 для подписи пайщиком). — schema.gql пересчитана; zeus/const.ts + zeus/index.ts перегенерированы. Все ID-поля заявления через @Field(() => String) (Zeus резолвит scalar ID как unknown без глобального scalar-resolver — поэтому Order и ReturnClaim единообразно используют String). Why: типобезопасный SDK-слой между backend GraphQL и desktop UI; правило «никаких raw GraphQL-строк в desktop» (feedback_graphql_no_raw_strings_desktop) требует прохода через Zeus client. * [598-10][@ant] feat: desktop UI Эпика 7 — orderer и operator страницы возврата на канон-widgets (TakeoverDialog + BarcodeScanner) — OrdererReturnClaims (страница /:coopname/market/returns): список заявлений пайщика разделён на «активные» (PENDING_CHAIRMAN_REVIEW + APPROVED_FOR_VISIT) и «архив» (финальные статусы). Подача нового заявления через SubmitReturnClaimDialog — full-screen TakeoverDialog с q-stepper 3 шага: описание (reason_text + defect_category + actual_quantity?) → фото (q-file 1-10 шт jpeg/png/webp до 10МБ → base64) → подпись заявления (preview registry_id=800 + Classes.Document.signDocument приватным ключом из useGlobalStore). Просмотр через ReturnClaimDetailsDialog — фото-thumbnails со ссылками на signed-URL bucket'а, q-timeline decision_log председателя, снапшот compensating-forward при ACCEPTED_AT_VISIT. — OperatorReturnClaims (страница /:coopname/market-pvz/returns): три ленты — pending (PENDING_CHAIRMAN_REVIEW) с inline-thumbnails фото и кнопкой «Принять решение» → RemoteDecisionDialog, approved (APPROVED_FOR_VISIT) с кнопкой «Очный осмотр» → OnSiteDecisionDialog, archive. RemoteDecisionDialog — q-option-group approve/reject + обязательный комментарий 1-500 симв. OnSiteDecisionDialog — q-stepper: 1) BarcodeScanner сканирует штрих-код имущества для сверки с Order; 2) inspection_result 1-2000 симв; 3) опциональные inspection_photos до 10 шт; 4) accept (compensating forward предупреждение) либо reject (имущество остаётся у заказчика). — API: типобезопасные обёртки в pages/<page>/api/index.ts через destructuring результата `{ [Queries.X.name]: result } = await client.Query(...)`. Типы выведены из Queries/Mutations.X.IOutput без cast'ов. Фото-загрузка через FileReader→base64 в browser, backend кладёт в bucket stol-zakazov:images. — DateTime utility: `formatDateTime(value: unknown)` для GraphQL DateTime scalar — Zeus резолвит как unknown без глобального scalar-resolver, простой helper парсит и форматирует через toLocaleString('ru-RU'). — install.ts: 2 новых маршрута зарегистрированы — workspace 'market' (orderer-стол) → '/:coopname/market/returns' (roles []); workspace 'market-pvz' (operator-стол) → '/:coopname/market-pvz/returns' (roles ['chairman']). Иконки fa-rotate-left / fa-clipboard-check; agreements: agreementsBase. Why: продолжение поведенческой части Эпика 7 — пайщик и председатель кооперативного участка получают функциональные UI для подачи и рассмотрения заявлений на гарантийный возврат, со всеми атрибутами (фото, подпись заявления, барскод-сверка, compensating forward) согласно FR29-FR33. Соблюдён канон дизайн-системы Эпика 10: используются только widgets/Marketplace/* (TakeoverDialog + BarcodeScanner), inline-вёрстка кастомных диалогов запрещена; токены через marketplace-tokens.scss (var(--mp-space-md), mp-role-* классы на корнях страниц). * [598-10][@ant] feat: добавить registry_id=1104 MarketplaceReturnStatement в cooptypes — отделить документ Эпика 7 «Стол заказов» от системы клиринга Marketplace по системе членских взносов ведёт свой контур документов рядом с 1102 «Акт приёма-передачи» и 1103 «ТТН». До этого Эпик 7 ошибочно переиспользовал registry_id=800 ReturnByAssetStatement из старой системы клиринга «по структурному совпадению» — это смешало два процесса в одном signed-document пайплайне. Завожу полноценный собственный документ: заявление пайщика о гарантийном возврате имущества с marketplace-полями (order_id / order_hash / fact_cost / actual_quantity / reason_text / defect_category / braname). Шаблон 800 остаётся как есть на случай будущего клиринга. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * [598-10][@ant] feat: проложить factory-цепочку для registry_id=1104 — Action + Template + регистрация в Registry/index Action 1104.MarketplaceReturnStatement.Factory повторяет паттерн 1102 (getCooperative/getVars/getUser/getRequest/getProgram/getOrganization), но кладёт в Model marketplace-поля (fact_cost / actual_quantity / reason_text / defect_category) и не требует transmitter/decision — заявление подписывает только пайщик. Также: убираю tsconfig.tsbuildinfo из индекса (build-артефакт, не должен жить в git). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * [598-10][@ant] feat: переключить controller + SDK на registry_id=1104 для Эпика 7 — заявление о гарантийном возврате имущества - marketplace-return-statement-document.dto.ts — новый Signed-DTO под Cooperative.Registry.MarketplaceReturnStatement.Action; старый marketplace-return-claim-document.dto.ts (ссылавшийся на 800 ReturnByAssetStatement) удалён. - MarketplaceReturnClaimService.generateStatementDocument теперь строит Action.MarketplaceReturnStatement с marketplace-полями (order_id / order_hash / fact_cost / reason_text / defect_category / braname), а не reuse'ит request{hash,units,unit_cost,total_cost} из старого 800. - getReturnClaimSignablePayload принимает reason_text — превью теперь показывает реальный текст обращения пайщика. - Регенерированы schema.gql + zeus client + SDK zeus (вход MarketplaceReturnStatementSignedInput с marketplace-меткой meta). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * [598-10][@ant] feat: desktop SubmitReturnClaimDialog — превью под registry_id=1104 с пробросом reason_text - API getReturnClaimSignablePayload теперь принимает reason_text и defect_category — превью показывает реальный текст обращения пайщика. - Убрал `result as MarketplaceGeneratedDocumentView` cast (Zeus уже выдаёт нужный тип после регенерации schema/SDK). - Комментарии и подсказки UI обновлены: 1104 MarketplaceReturnStatement вместо устаревшего 800 ReturnByAssetStatement. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * [598-10][@ant] refactor: десктоп-API Эпика 7 на строгие типы из SDK — variables передаём целиком data Канон @coopenomics/sdk: каждый api-метод принимает `data: Mutations.<X>.<Y>.IInput['data']` (или `Queries.<X>.<Y>.IInput['data']`) и передаёт его в variables объектом целиком — `{ variables: { data } }`. Без раскладки полей вручную и без самодельных интерфейсов аргументов. Затронуто: - OrdererReturnClaims/api: getReturnClaimSignablePayload + createReturnClaim - OperatorReturnClaims/api: listReturnClaimsByBraname, approveReturnVisit, rejectReturnRemote, acceptReturnAtVisit, rejectReturnAtVisit - SubmitReturnClaimDialog: defectCategory типизирован как enum Zeus.MarketplaceReturnClaimDefectCategory (раньше падал на string→enum, но был замаскирован ручной раскладкой полей в variables) - OnSiteDecisionDialog: ReturnClaimPhotoUploadInput выведен из IAcceptReturnAtVisitInput - OperatorReturnClaimsPage: listReturnClaimsByBraname({ delivery_braname }) Зачем — ревью PR #397: при ручной раскладке полей в variables.data изменение схемы в SDK не подсвечивает call-site как ошибку TS; регрессии маскируются. Канон даёт строгую сверку при изменении бэкенда. --------- Co-authored-by: coopops <coopos@coopenomics.world> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Цифровой Кооператив
Платформа «Цифровой Кооператив» — комплексное программное обеспечение для управления кооперативными организациями на основе блокчейна EOSIO. Система обеспечивает полный цикл управления кооперативом: от регистрации пайщиков и электронного документооборота до проведения собраний и финансового учёта. Построена на принципах прозрачности, децентрализации и простой электронной подписи.
Проект является частью экосистемы Кооперативная Экономика.
Архитектура
| Компонент | Пакет | Описание |
|---|---|---|
| boot | @coopenomics/boot |
CLI для инициализации и управления блокчейн-инфраструктурой |
| cleos | @coopenomics/cleos |
Утилита командной строки для работы с блокчейн-кошельком |
| contracts | @coopenomics/contracts |
Смарт-контракты EOSIO на C++ |
| controller | @coopenomics/controller |
GraphQL API сервер (NestJS) |
| cooptypes | cooptypes |
Общие типы и интерфейсы блокчейн-контрактов |
| desktop | @coopenomics/desktop |
Рабочий стол кооператива (Vue 3 + Quasar) |
| factory | @coopenomics/factory |
Генератор юридических документов |
| migrator | migrator |
Утилита миграции данных |
| notifications | @coopenomics/notifications |
Библиотека уведомлений на основе Novu |
| parser | @coopenomics/parser |
Индексатор блокчейна через State History Plugin |
| sdk | @coopenomics/sdk |
TypeScript SDK для GraphQL API |
| setup | @coopenomics/setup |
Мастер первоначальной настройки |
Быстрый старт
Предварительные требования
- Node.js >= 20
- pnpm 9
- Docker и Docker Compose
- WeasyPrint (для генерации PDF)
Установка
pnpm install
Конфигурация
pnpm run setup
Интерактивный мастер создаст необходимые .env файлы для всех компонентов.
Запуск инфраструктуры
docker compose up -d
pnpm run reboot
Разработка
Бэкенд (controller + parser)
pnpm run dev:backend
Фронтенд (desktop)
pnpm run dev:desktop
Библиотеки (factory + cooptypes)
pnpm run dev:lib
Все сервисы одновременно
pnpm run dev:all
Примечание: установка пакетов производится только через фильтр:
pnpm add <пакет> --filter <компонент>
Тестирование
# Все тесты
pnpm run test
# Юнит-тесты (cooptypes, parser, notifications)
pnpm run test:unit
# Компонентные тесты (factory)
pnpm run test:component
# Интеграционные тесты (boot + blockchain)
pnpm run test:integration
Сборка
# Библиотеки (cooptypes, factory)
pnpm run build:lib
# Смарт-контракты
pnpm run build:contracts:all
# Desktop (SSR)
pnpm --filter @coopenomics/desktop run build
Лицензия
Продукт Потребительского Кооператива «ВОСХОД» распространяется по лицензии BY-NC-SA 4.0.
Разрешено делиться, копировать и распространять материал, адаптировать и создавать производные произведения при условии указания авторства и сохранения той же лицензии. Коммерческое использование запрещено.