hailin
30a2f739cb
fix(contribution): Dockerfile添加预种Prisma Client生成和migration
...
- builder和runner阶段均添加 prisma generate --schema=prisma/pre-planting/schema.prisma
- start.sh添加预种migration部署步骤
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-26 20:33:04 -08:00
hailin
acf55b26a7
feat(pricing): 预种每份价格从 3171 调整为 3566 绿积分
...
分配规则:按 reward-service RIGHT_AMOUNTS(15831 整棵树)各项 /5 取整,
余额全归总部社区(HQ_BASE_FEE)。5 份合成一棵树 = 17830。
10 类分配金额变更:
- COST_FEE: 576 (不变, floor(2880/5))
- OPERATION_FEE: 420 (不变, floor(2100/5))
- HQ_BASE_FEE: 29.4 → 427 (3566 - 3139, 吸收全部余额)
- RWAD_POOL: 1152 (不变, floor(5760/5))
- SHARE_RIGHT: 720 (不变, floor(3600/5))
- PROVINCE_AREA: 21.6 → 21 (floor(108/5))
- PROVINCE_TEAM: 28.8 → 28 (floor(144/5))
- CITY_AREA: 50.4 → 50 (floor(252/5))
- CITY_TEAM: 57.6 → 57 (floor(288/5))
- COMMUNITY: 115.2 → 115 (floor(576/5))
- 合计: 3171 → 3566 ✓
涉及服务:planting-service, admin-service, contribution-service
涉及前端:admin-web, mobile-app (Flutter)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-26 08:02:17 -08:00
hailin
a11e4d0261
fix(pre-planting): 修复 5 个预种模块 Bug + 补全 3 服务 migration
...
Bug #1 (HIGH): allocateFunds 从 Prisma 事务内移到事务外
- pre-planting-reward.service.ts: distributeRewards 拆为
prepareAndPersistRewards(事务内持久化)+ executeAllocations(事务后转账)
- pre-planting-application.service.ts: 事务后调用 executeAllocations
Bug #2 (HIGH): signContract 后触发 hasPlanted
- 签约事务成功后发布 PlantingOrderPaid 到 planting-events topic
- wallet-service 消费后执行 markUserAsPlanted + settleUserPendingRewards
- event-publisher.service.ts: 新增 publishRawToPlantingEvents 方法
Bug #3 (MEDIUM): PENDING 推荐奖励改为全部 SETTLED
- 与现有认种行为对齐,推荐奖励立即发放
Bug #4 (HIGH): 补全 3 个服务的数据库迁移文件
- planting-service: 4 张预种表(orders/positions/merges/reward_entries)
- admin-service: 1 张配置表(pre_planting_configs)+ 默认数据
- contribution-service: 4 张 CDC 追踪表(synced_orders/positions/freeze_states/processed_cdc_events)
Bug #5 (LOW): 合并循环 if→while,支持一次购买多份触发多次合并
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-23 18:09:14 -08:00
hailin
b3a3652f21
feat(transfer): 树转让功能全量实现(纯新增,零侵入)
...
实现已认种果树所有权在用户间转让的完整功能。采用方案一:
独立 transfer-service 微服务 + Saga 编排器模式。
=== 架构设计 ===
- Saga 编排器 8 步正向流程:卖方确认 → 冻结资金 → 锁定树 →
变更所有权 → 调整算力 → 更新统计 → 结算资金 → 完成
- 补偿回滚:任一步骤失败自动反向补偿(解冻资金 → 解锁树)
- 13 种状态:PENDING → SELLER_CONFIRMED → PAYMENT_FROZEN →
TREES_LOCKED → OWNERSHIP_TRANSFERRED → CONTRIBUTION_ADJUSTED →
STATS_UPDATED → PAYMENT_SETTLED → COMPLETED / CANCELLED /
FAILED / ROLLING_BACK / ROLLED_BACK
=== Phase 1-2: transfer-service(独立微服务) ===
新建文件:
- Prisma Schema:transfer_orders + transfer_status_logs + outbox_events
- Domain:TransferOrder 聚合根 + TransferFeeService(5% 手续费)
- Application:TransferApplicationService + SagaOrchestratorService
- Infrastructure:Kafka 事件消费/生产 + Outbox Pattern
- API:TransferController(用户端)+ AdminTransferController(管理端)
- External Clients:wallet/planting/identity-service HTTP 客户端
- Docker + 环境配置
=== Phase 3: 现有微服务扩展(纯追加) ===
planting-service:
- Prisma schema 追加 transferLockId 可空字段
- InternalTransferController:锁定/解锁/执行 3 个新端点
- Kafka handlers:transfer-lock/execute/rollback 事件处理
- main.ts 追加 Kafka consumer group 配置
referral-service:
- PlantingTransferredHandler:处理转让后团队统计更新
- TeamStatisticsAggregate 追加 handleTransfer() 方法
- TeamStatisticsRepository 追加 adjustForTransfer() 方法
- ProvinceCityDistribution 追加 transferTrees() 方法
contribution-service:
- TransferOwnershipHandler:处理所有权变更事件
- TransferAdjustmentService:算力调整(879 行核心逻辑)
- Prisma schema 追加 transferOrderId 可空字段
- ContributionAccount 追加 applyTransferAdjustment() 方法
=== Phase 4A: wallet-service(3 个新内部端点) ===
新建文件:
- FreezeForTransferDto / UnfreezeForTransferDto / SettleTransferDto
- FreezeForTransferCommand / UnfreezeForTransferCommand / SettleTransferPaymentCommand
- InternalTransferWalletController(POST freeze/unfreeze/settle-transfer)
修改文件:
- wallet-application.service.ts 追加 3 组方法(+437 行):
freezeForTransfer / unfreezeForTransfer / settleTransferPayment
(乐观锁 + 3 次重试 + Prisma $transaction + 幂等检查)
- 结算操作:单事务内更新 3 个钱包(买方扣减 + 卖方入账 + 手续费归集)
=== Phase 4B: admin-web(转让管理页面) ===
新建文件:
- transferService.ts:API 调用服务 + 完整类型定义
- useTransfers.ts:React Query hooks(list/detail/stats/forceCancel)
- /transfers/page.tsx:列表页(统计卡片 + 搜索筛选 + 分页 + 13 种状态 badge)
- /transfers/[transferOrderNo]/page.tsx:详情页(Saga 时间线 + 状态日志 + 强制取消)
- transfers.module.scss:完整样式
修改文件:
- endpoints.ts 追加 TRANSFERS 端点配置
- Sidebar.tsx 追加「转让管理」菜单项
- hooks/index.ts 追加 useTransfers 导出
=== Phase 4C: mobile-app(转让 UI) ===
新建文件:
- transfer_service.dart:Flutter API 服务 + Model(TransferOrder/Detail/StatusLog)
- transfer_list_page.dart:转让记录列表(全部/转出/转入 Tab + 下拉刷新)
- transfer_detail_page.dart:转让详情(Saga 时间线 + 确认/取消操作)
- transfer_initiate_page.dart:发起转让表单(手续费自动计算)
修改文件:
- injection_container.dart 追加 transferServiceProvider
- route_paths.dart + route_names.dart 追加 3 个路由
- app_router.dart 追加 3 个 GoRoute
- profile_page.dart 追加「发起转让」+「转让记录」按钮行
=== 基础设施 ===
- docker-compose.yml 追加 transfer-service 容器配置
- deploy.sh 追加 transfer-service 部署
- init-databases.sh 追加 transfer_db 数据库初始化
=== 纯新增原则 ===
所有变更均为追加式修改,不修改任何现有业务逻辑:
- 新增 nullable 字段(不影响现有数据)
- 新增 enum 值(不影响现有枚举使用)
- 新增 providers/controllers(不影响现有依赖注入)
- 新增页面/路由(不影响现有页面行为)
回滚方式:删除 transfer-service 目录 + 移除各服务中带 [2026-02-19] 标记的代码
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-19 03:44:02 -08:00
hailin
e1cd8ed7f2
feat(pre-planting): 3171 预种计划 2.0 算力集成(contribution-service CDC 模块)
...
Phase 5:将预种数据集成到 contribution-service 2.0 算力体系。
=== 新增文件(11 个) ===
- prisma/pre-planting/schema.prisma:独立 Prisma schema(4 张追踪表)
- PrePlantingPrismaService + Module:独立 PrismaClient
- PrePlantingCdcConsumerService:独立 CDC 消费者(consumer group: contribution-pre-planting-cdc)
- PrePlantingOrderSyncedHandler:订单 CDC handler + synced_adoptions marker 插入
- PrePlantingPositionSyncedHandler:持仓 CDC handler
- PrePlantingCdcDispatcher:CDC 事件分发器
- PrePlantingContributionService:1/5 算力计算(复用领域计算器)
- PrePlantingFreezeScheduler:每日冻结/解冻调度(凌晨 5 点)
- PrePlantingCdcModule:模块注册
- constants.ts:10B 偏移量、冻结期限等常量
=== 隔离保证 ===
- 独立 Kafka consumer group(contribution-pre-planting-cdc)
- 独立 CDC topics(cdc.pre-planting.public.*)
- 独立 Prisma schema + generated client
- sourceAdoptionId 使用 10,000,000,000 偏移避免 ID 冲突
- synced_adoptions marker: contributionDistributed=true + treeCount=0
- 不更新 NetworkAdoptionProgress(预种不推高全网算力系数)
- 现有代码文件零修改(仅 app.module.ts 加 1 行 import)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-18 05:25:14 -08:00
hailin
4817d92507
feat(adoption-injection): 认种自动 fUSDT 注入做市商钱包 + CDC outbox 修复
...
## contribution-service 改动
### 1. CDC Outbox 实时发布修复
- adoption-synced.handler: handleCreate/handleUpdate 在同步数据后立即写入
AdoptionSynced outbox 事件,确保 mining-admin-service 实时接收认种同步
- referral-synced.handler: 同理,写入 ReferralSynced outbox 事件
- 之前只有手动调用 /admin/adoptions/publish-all 才会创建 outbox 事件
### 2. 认种 fUSDT 注入事件
- 新增 AdoptionFusdtInjectionRequestedEvent 事件类
- 当认种状态变为 MINING_ENABLED 时触发
- 写入 outbox,topic: contribution.adoptionfusdtinjectionrequested
- payload 含: adoptionId, accountSequence, treeCount, adoptionDate, amount
- 转账金额 = treeCount × 5760 fUSDT
## mining-blockchain-service 改动
### 3. fUSDT 注入钱包 MPC 签名支持
- mpc-signing.client: 新增 FUSDT_INJECTION_WALLET_USERNAME/ADDRESS 配置
isFusdtInjectionConfigured(), signMessageAsFusdtInjection() 等方法
- erc20-transfer.service: IMpcSigningClient 接口增加注入钱包方法
新增 transferFusdtAsInjectionWallet() 转账方法(含余额检查、MPC签名、广播)
### 4. 认种注入 Kafka 消费者
- adoption-injection-consumer.service: 订阅 cdc.contribution.outbox
过滤 AdoptionFusdtInjectionRequested 事件,解析 Debezium 扁平化消息格式
- adoption-injection.handler: 处理注入事件
- 幂等性检查(已确认的跳过)
- 写入 adoption_injection_records 分类账(PROCESSING 状态)
- 从注入钱包转 fUSDT 到做市商钱包
- 成功: markConfirmed (txHash, blockNumber, gasUsed)
- 失败: markFailed (errorMessage),支持重试
- 发布 confirmed/failed Kafka 事件
### 5. 分类账持久化
- Prisma schema: 新增 AdoptionInjectionRecord 模型 (adoption_injection_records 表)
字段: adoption_id, account_sequence, tree_count, adoption_date, from/to_address,
amount, chain_type, tx_hash, block_number, gas_used, memo, status, error_message
索引: uk_adoption_id (唯一), idx_injection_account, idx_injection_status 等
- migration: 20250203000000_add_adoption_injection_records
- Repository 接口 + 实现: save, findByAdoptionId, markConfirmed, markFailed
### 6. 启动余额检查
- main.ts: 启动时异步查询注入钱包 fUSDT 余额,余额为 0 时输出警告日志
新增注入钱包配置验证
## 部署前需添加环境变量 (.env)
FUSDT_INJECTION_WALLET_USERNAME=wallet-bff20b69
FUSDT_INJECTION_WALLET_ADDRESS=0x7BDB89dA47F16869c90446C41e70A00dDc432DBB
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-03 05:25:56 -08:00
hailin
7180e2ac27
fix(contribution): 算力记录按层级升序排列 L1→L2→...→L15
...
用户期望 L1 在前 L15 在后,将 levelDepth/bonusTier 排序从 DESC 改为 ASC
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 20:14:31 -08:00
hailin
17f8a61bcf
feat(contribution-service): 贡献值明细按 L/T 降序排序
...
- 同伴下贡献值 (TEAM_LEVEL): 按 levelDepth DESC 排序 (L3, L2, L1)
- 同伴上贡献值 (TEAM_BONUS): 按 bonusTier DESC 排序 (T3, T2, T1)
- 全部/本人: 按 levelDepth DESC, bonusTier DESC, createdAt DESC
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 14:20:03 -08:00
hailin
b1607666a0
fix(contribution): LEVEL_OVERFLOW 回收任务,修复已解锁层级的溢出记录无法被回收的 bug
...
当下级认种时上级 unlocked_level_depth 不足,层级奖励进入 LEVEL_OVERFLOW(PENDING)。
上级后续解锁到足够层级后,现有 backfill 因条件 expectedLevel > currentLevel 为 false
而跳过,导致 PENDING 记录永远无法被回收。新增独立调度任务每10分钟扫描并回收。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 10:12:48 -08:00
hailin
817b7d3a9f
fix(contribution): 算力分配时序保证 + bonus补发stale-read修复
...
4处改动确保部署清库重新同步后100%可靠:
1. contribution.scheduler.ts - CDC就绪门控
注入CDCConsumerService,processUnprocessedAdoptions/publishRecentlyUpdatedAccounts/
processContributionBackfill三个调度方法开头加isCdcReady()检查,
确保用户+推荐+认种三阶段CDC同步全部完成后才开始处理。
2. contribution-calculation.service.ts - 推荐数据防护
calculateForAdoption()中,userReferral为null时warn并return,
不标记distributed,调度器下次重试。覆盖continuous mode下
认种事件先于推荐事件到达的竞态场景。
3. bonus-claim.service.ts - bonus补发stale-read修复
processBackfillForAccount()中,level事务的updateAccountUnlockStatus
通过incrementDirectReferralAdoptedCount()同时修改unlockedLevelDepth
和unlockedBonusTiers,导致bonus分支条件永远为false。
修复:保存originalDirectReferralAdoptedCount和originalUnlockedBonusTiers,
bonus分支使用原始值判断和传参。
4. config.controller.ts - mining-admin同步检查增强
isSynced新增allAdoptionsProcessed条件(unprocessedAdoptions===0),
确保所有认种分配+补发完成后才允许激活挖矿。
修复data变量作用域问题(原在if块内声明,外部引用会报错)。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-30 05:54:02 -08:00
hailin
cec98e9d3e
feat(contribution): 添加定时任务补发未完全解锁的贡献值
...
每10分钟扫描已认种但解锁状态不完整的账户,检查其直推用户认种情况,
若满足新的解锁条件则自动补发层级贡献值和奖励档位。
- 添加 findAccountsWithIncompleteUnlock 查询方法
- 添加 findPendingLevelByAccountSequence 和 claimLevelRecords 方法
- 实现 processBackfillForAccount 和 claimLevelContributions 补发逻辑
- 添加 processContributionBackfill 定时任务(每10分钟执行)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-28 06:25:57 -08:00
hailin
37d3300b17
fix(contribution-service): CDC planting_orders 阶段按 order_id 排序处理
...
## 问题背景
用户 D25122700018 的层级已解锁(unlocked_level_depth=5),但缺少 TEAM_LEVEL 算力记录。
其下级用户 D25122700019 的团队算力被错误地分配给了 D25122700015(level 2)而非 D25122700018(level 1)。
## 根本原因分析
1. 源系统数据顺序正确:
- D25122700018: order_id=55, created_at=2026-01-09 11:57:01 (先认种)
- D25122700019: order_id=57, created_at=2026-01-09 12:00:38 (后认种)
2. Kafka 消息顺序错误:
- D25122700019: offset=732, synced_at=10:15:32 (先处理)
- D25122700018: offset=798, synced_at=10:15:41 (后处理)
3. 原因:Debezium snapshot 按 PostgreSQL 物理存储顺序(heap order)读取数据,
而非按主键顺序。即使 topic 只有 1 个分区,消息顺序仍然错误。
4. 后果:当处理 D25122700019 的认种时,D25122700018 的 unlocked_level_depth 还是 0,
导致 D25122700019 的 TEAM_LEVEL 算力跳过 level 1 直接分配给 level 2。
## 解决方案
对 planting_orders 阶段实现"收集-排序-处理"模式:
1. 先收集所有消息到内存数组(不立即处理)
2. 按 order_id(源系统主键)升序排序
3. 再按排序后的顺序逐条处理
这确保上游用户的认种记录先于下游用户处理,避免算力分配错误。
## 受影响用户案例
- 上游用户: D25122700018 (order_id=55)
- 下游用户: D25122700019 (order_id=57, 58, 59)
- 错误分配: D25122700019 的 TEAM_LEVEL 给了 D25122700015 而非 D25122700018
## 回滚方法
如需回滚此修改,将 consumePhaseToEnd 方法中的判断条件改为 false:
```typescript
const needsSorting = false; // 原: phase.tableName === 'planting_orders'
```
或直接 revert 此 commit。
## 风险评估
- 业务逻辑完全不变,只改变处理顺序
- user_accounts 和 referral_relationships 阶段保持原有逻辑
- 内存开销可控(10000 条记录约 5MB)
- 排序开销可忽略(O(n log n))
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-23 03:41:14 -08:00
hailin
390cc3131d
fix(contribution): 修复T2/T3补发记录缺少treeCount和baseContribution
...
补发奖励时从SyncedAdoption查询原始认种数据,
确保补发记录包含正确的棵数和基础贡献值。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 19:38:18 -08:00
hailin
f7dbe2f62b
refactor(contribution): 合并所有迁移到 0001_init
...
- 将 0002_add_soft_delete 的 deleted_at 字段合并到 0001_init
- 删除 0002_add_soft_delete_to_system_contribution_records 目录
- 现在只保留一个初始化迁移文件
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 04:31:52 -08:00
hailin
21c6c25f7c
refactor(contribution): 合并 source_type 迁移到 0001_init
...
将 0003_add_source_type 迁移合并到 0001_init/migration.sql
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 04:28:14 -08:00
hailin
e7260be219
feat(contribution): 添加系统账户算力来源类型字段
...
- 添加 sourceType 字段区分算力来源类型:
- FIXED_RATE: 固定比例分配(OPERATION 12%、PROVINCE 1%、CITY 2%)
- LEVEL_OVERFLOW: 层级溢出归总部(上线未解锁该级别)
- LEVEL_NO_ANCESTOR: 无上线归总部(该级无上线)
- BONUS_TIER_1/2/3: 团队奖励未解锁归总部
- 添加 levelDepth 字段记录层级深度(1-15级)
- 更新前端表格显示来源类型列
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 04:23:50 -08:00
hailin
eeaa43e044
feat(contribution): 系统账户明细记录改为软删除
...
- 在 SystemContributionRecord 模型添加 deleted_at 字段
- 修改 deleteContributionRecordsByAdoption 方法为软删除(设置 deleted_at)
- 修改 findContributionRecords 方法过滤已删除记录(deletedAt: null)
- 添加数据库迁移文件
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 03:09:41 -08:00
hailin
e0eb734196
fix(contribution): 用户领取奖励时从 HEADQUARTERS 减少算力并删除明细
...
- 添加 subtractContribution 方法减少系统账户算力
- 添加 deleteContributionRecordsByAdoption 方法删除明细记录
- 在 BonusClaimService 中领取奖励时同步更新 HEADQUARTERS
2026-01-21 02:56:58 -08:00
hailin
974b45554d
feat(contribution): 为 HEADQUARTERS 未分配算力创建明细记录
...
- 每笔未分配算力都创建 HEADQUARTERS 的明细记录
- 发布 SystemContributionRecordCreatedEvent 事件同步到 mining-admin-service
- 明细记录包含来源用户ID (sourceAccountSequence)
2026-01-21 02:20:36 -08:00
hailin
27a045e082
fix(contribution): 在算力明细事件中添加 regionCode 字段
...
修改 SystemContributionRecordCreatedEvent 事件,将 systemAccountType
拆分为 accountType 和 regionCode 两个独立字段,以便 mining-admin-service
正确同步按省市细分的算力明细记录
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 01:25:46 -08:00
hailin
96da7518bf
fix(system-accounts): 修复省市系统账户自动创建的数据流问题
...
1. contribution-service: 修复 CITY 类型账户的 provinceCode 映射
- 之前 CITY 的 provinceCode 被错误设为 cityCode
- 现在正确传递 provinceCode 用于创建省份
2. mining-wallet-service: 修复系统账户创建事件的 topic
- 之前发布到 mining-wallet.system-account.created
- 现在发布到 cdc.mining-wallet.outbox 供 mining-admin-service 同步
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-21 00:28:48 -08:00
hailin
40ac037c03
fix(contribution): 修复系统账户查询中 nullable regionCode 的 TypeScript 类型错误
...
## 问题
- Prisma 生成的类型不允许在 unique where 条件中传递 null
- addContribution 方法被传入多余参数
- findByType 返回数组被当作单个对象使用
## 修复
- findByTypeAndRegion: 使用 findFirst 替代 findUnique
- ensureSystemAccountsExist: 使用 findFirst + create 替代 upsert
- addContribution: 使用 findFirst + create/update 替代 upsert
- 修正 HEADQUARTERS 账户同步事件调用参数
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 21:37:44 -08:00
hailin
9062346650
refactor(system-accounts): 移除 baseType 字段,使用 accountType+regionCode 复合唯一键
...
## 主要变更
### 数据模型简化
- 移除冗余的 baseType 字段,accountType 已包含类型信息
- 使用 accountType (OPERATION/PROVINCE/CITY/HEADQUARTERS) + regionCode (省市代码) 作为复合唯一键
- 所有查询改用 accountType+regionCode,100% 弃用数据库自增 ID
### contribution-service
- SystemAccount 表移除 baseType,改用 accountType+regionCode 唯一约束
- 修改算力分配逻辑,省市账户使用对应 regionCode
- 事件发布增加 regionCode 字段
### mining-service
- SystemMiningAccount 表使用 accountType+regionCode 唯一约束
- API 改为 /system-accounts/:accountType/records?regionCode=xxx 格式
- 挖矿分配逻辑支持按省市细分
### mining-admin-service
- SyncedSystemContribution 表使用 accountType+regionCode 唯一约束
- CDC 同步处理器适配新格式
- API 统一使用 accountType+regionCode 查询
## API 示例
- 运营账户: GET /admin/system-accounts/OPERATION/records
- 广东省: GET /admin/system-accounts/PROVINCE/records?regionCode=440000
- 广州市: GET /admin/system-accounts/CITY/records?regionCode=440100
- 总部: GET /admin/system-accounts/HEADQUARTERS/records
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 21:29:01 -08:00
hailin
81b2e7a4c2
refactor(migrations): 合并各服务的 migration 文件为单个 0001_init
...
将各服务的多个 migration 文件合并到单一的初始化 migration 中:
- contribution-service: 3→1 (含 region 支持)
- mining-service: 4→1 (含 second 分配和 region 支持)
- mining-admin-service: 4→1 (含 region 和算力明细同步)
- auth-service: 2→1 (含 CDC 幂等)
- trading-service: 9→1 (含销毁系统/做市商/C2C)
- mining-wallet-service: 2→1 (含 SHARE_POOL 拆分)
所有迁移统一使用 TEXT 类型(非 VARCHAR)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 20:34:56 -08:00
hailin
9c816266ac
fix(schema): 统一使用 TEXT 类型替代 VARCHAR
...
问题:
- 之前 schema 和 migration 中使用了 VARCHAR(n) 限制字段长度
- Prisma 的 String 类型默认映射到 PostgreSQL TEXT
- VARCHAR 和 TEXT 在 PostgreSQL 中性能相同,VARCHAR 限制反而增加风险
修复:
1. contribution-service:
- schema: 移除 accountType/baseType/regionCode/name 的 @db.VarChar
- migration: VARCHAR -> TEXT
2. mining-service:
- schema: 移除 accountType/baseType/regionCode/name 的 @db.VarChar
- migration: VARCHAR -> TEXT
3. mining-admin-service:
- migration: VARCHAR -> TEXT (schema 已使用 TEXT)
原则:Prisma String 直接使用,不加 @db.VarChar()
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 20:24:01 -08:00
hailin
5f2f223f7b
fix(contribution): 修复 SystemAccountSyncedEvent 缺少 baseType/regionCode 参数
...
问题:
- admin.controller.ts 中 republishSystemAccounts 端点调用 SystemAccountSyncedEvent 时
只传递了 4 个参数,但构造函数需要 6 个参数
- 缺少 baseType(基础类型)和 regionCode(区域代码)参数
修复:
- 添加 account.baseType 和 account.regionCode 参数
- 与 contribution-calculation.service.ts 中的调用保持一致
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 20:12:49 -08:00
hailin
09b0bc077e
feat(system-accounts): 实现系统账户按省市细分算力和挖矿分配
...
## 核心功能
### 1. 算力按省市细分分配
- accountType 从枚举改为组合键字符串:PROVINCE_440000, CITY_440100
- 新增 baseType (基础类型) 和 regionCode (区域代码) 字段
- 认种时根据 selectedProvince/selectedCity 分配到具体省市账户
- 无省市信息时归入汇总账户
### 2. 系统账户参与挖矿
- 运营、省、市账户按各自 totalContribution 参与挖矿
- 总部账户(HEADQUARTERS)不直接参与,接收待解锁算力收益
- 待解锁算力 100% 参与挖矿,收益归总部
### 3. 算力来源明细追溯
- 新增 SystemContributionRecord 记录每笔算力来源
- 新增 SystemContributionRecordCreatedEvent 事件同步明细
- 前端新增"算力来源"标签页展示明细
## 修改的服务
### contribution-service
- schema: SystemAccount 新增 baseType, regionCode
- contribution-calculator: 按省市生成组合键
- system-account.repository: 支持动态创建省市账户
- 新增 SystemContributionRecordCreatedEvent 事件
### mining-service
- schema: SystemMiningAccount 从枚举改为字符串
- network-sync: 处理带 baseType/regionCode 的同步事件
- mining-distribution: 系统账户和待解锁算力参与挖矿
### mining-admin-service
- schema: 新增 SyncedSystemContributionRecord 表
- cdc-sync: 处理 SystemContributionRecordCreated 事件
- system-accounts.service: 新增算力来源明细和统计 API
### mining-admin-web
- 新增 ContributionRecordsTable 组件
- 系统账户详情页新增"算力来源"标签页
- 显示来源认种ID、用户、分配比例、金额
## 数据库迁移
- contribution-service: 20250120000001_add_region_to_system_accounts
- mining-service: 20250120000001_add_region_to_system_mining_accounts
- mining-admin-service: 20250120000001, 20250120000002
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 19:55:14 -08:00
hailin
1d5e3ebff2
fix(contribution): 使用 upsert 替代 update 避免记录不存在错误
...
将 addContribution 方法改为 upsert,当系统账户不存在时自动创建,
存在时增加算力余额。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 08:43:37 -08:00
hailin
5ec310124d
fix(contribution): 确保 HEADQUARTERS 账户存在后再更新算力
...
修复 Record to update not found 错误,在调用 addContribution 前
先调用 ensureSystemAccountsExist 确保系统账户记录已创建。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 08:42:02 -08:00
hailin
d844228711
fix(contribution): 将未分配算力汇总到总部账户(HEADQUARTERS)
...
之前 HEADQUARTERS 账户在算力分配时被遗漏,未获得未分配算力的汇总。
现在在保存未分配算力时,同时更新 HEADQUARTERS 账户的 contributionBalance,
并发布同步事件用于 mining-admin-service 同步。
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 08:26:53 -08:00
hailin
1c787a22a3
fix(mining): 修复 mining-service 订阅错误的 Kafka topic
...
问题:mining-service 订阅的是 cdc.contribution.outbox (Debezium CDC topic),
但 contribution-service 使用 Outbox Pattern 直接发送到 contribution.{eventType} topic。
修复:
- mining-service 订阅正确的 topic 列表
- 修复消息解析逻辑支持 Outbox Pattern 消息格式
- contribution-service 添加 GET /admin/unallocated-contributions 端点(调试用)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-20 03:03:17 -08:00
hailin
e8f3c34723
fix(contribution): 认种记录总贡献值显示用户实际有效算力
...
后端:
- get-planting-ledger.query.ts: 添加effectiveContribution字段
- 从contributionAccount获取用户实际的个人算力(personalContribution)
前端:
- planting_record.dart: PlantingSummary添加effectiveContribution字段
- planting_record_model.dart: 解析effectiveContribution字段
- planting_records_page.dart: 总贡献值显示effectiveContribution而非totalAmount
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-17 08:29:14 -08:00
hailin
0ebb0ad076
fix(contribution): use Symbol token for SYNCED_DATA_REPOSITORY injection
...
The GetTeamTreeQuery was importing SYNCED_DATA_REPOSITORY as a Symbol from
the domain interface, but InfrastructureModule defined its own string token.
This caused NestJS dependency resolution to fail.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 09:33:21 -08:00
hailin
4ec6c9f48b
feat(contribution/mining-app): add team tree API using contribution-service 2.0
...
Add team info and direct referrals endpoints to contribution-service,
using SyncedReferral data synced via CDC. Update mining-app to use the
new v2 contribution API instead of legacy referral-service.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 09:17:18 -08:00
hailin
f22c3efb11
fix: use correct property name 'type' for unallocated contribution
...
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 05:40:40 -08:00
hailin
0241930011
feat(contribution/mining): sync unallocated contributions to mining-service
...
- Add UnallocatedContributionSyncedEvent in contribution-service
- Add event handler in mining-service's contribution-event.handler.ts
- Add handleUnallocatedContributionSynced in network-sync.service.ts
- Add admin endpoint to publish all unallocated contributions
- Sync pending/unallocated contributions to PendingContributionMining table
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 05:29:28 -08:00
hailin
130bf57842
fix(contribution): 处理认种时发布系统账户同步事件
...
- 在保存系统账户算力后,发布 SystemAccountSyncedEvent
- 使 mining-service 能够同步运营/省/市公司的算力
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 05:24:04 -08:00
hailin
962e7874c8
fix(contribution): 修复全网理论算力未同步问题
...
- 在 calculateForAdoption 中调用 updateNetworkProgress 更新 NetworkAdoptionProgress 表
- 之前 publishNetworkProgressEvent 读取的 totalTreeCount 始终为 0,因为表未被更新
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 04:55:30 -08:00
hailin
bb75ff19a4
feat(contribution): 认种处理后自动发布全网进度事件
...
- 每次认种分配完成后发布 NetworkProgressUpdatedEvent
- mining-service 通过 Kafka 实时接收全网理论算力更新
- 定时同步改为每5分钟一次,作为兜底方案
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 04:46:12 -08:00
hailin
de5416aee6
feat(mining): 实现系统账户和待解锁算力参与挖矿
...
重大变更:
- 挖矿分母从用户有效算力改为全网理论算力(networkTotalContribution)
- 系统账户(运营12%/省1%/市2%)参与挖矿,有独立的挖矿记录
- 待解锁算力参与挖矿,收益归总部账户,记录包含完整来源信息
新增功能:
- mining-service: 系统挖矿账户表、待解锁算力表及相关挖矿记录表
- mining-service: NetworkSyncService 同步全网数据
- mining-service: /admin/sync-network 和 /admin/system-accounts 端点
- contribution-service: /admin/system-accounts 和发布系统账户事件端点
- mining-admin-service: 状态检查返回全网理论算力信息
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 03:39:56 -08:00
hailin
b5fca7bb04
fix(mining-admin): 修复算力同步状态检查的 API 路径
...
- contribution-service: 给 /contribution/stats 接口添加 @Public() 装饰器
- mining-admin-service: 修正 API 路径从 api/v1 改为 api/v2
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-16 03:09:05 -08:00
hailin
01bd638dbb
fix(contribution-service): add parent .env path for shared config
...
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 07:00:02 -08:00
hailin
cfbf1b21f3
feat(dashboard): add detailed contribution breakdown by category
...
Backend (contribution-service):
- Add getDetailedContributionStats() to repository
- Add getUnallocatedByLevelTier/BonusTier() to repository
- Extend stats API with level/bonus breakdown by tier
- Add getTotalTrees() to synced-data repository
Backend (mining-admin-service):
- Add detailed contribution stats calculation
- Calculate theoretical vs actual values per category
- Return level/bonus breakdown with unlocked/pending amounts
Frontend (mining-admin-web):
- Add ContributionBreakdown component showing:
- Personal (70%), Operation (12%), Province (1%), City (2%)
- Level contribution (7.5%) by tier: 1-5, 6-10, 11-15
- Bonus contribution (7.5%) by tier: T1, T2, T3
- Update DashboardStats type definition
- Integrate breakdown component into dashboard page
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 01:43:37 -08:00
hailin
1f15daa6c5
fix(planting-records): filter only MINING_ENABLED records and fix UI overflow
...
- Backend: Add status filter to getPlantingLedger and getPlantingSummary
- Frontend: Change Row to Wrap for info items to prevent width overflow
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 00:12:07 -08:00
hailin
b310fde426
feat(mining-admin): show pending contribution in dashboard
...
- Add networkPendingContribution and networkBonusPendingContribution to API
- Display combined pending contribution (teamLevel + teamBonus) in stats card
- Replace 'total contribution' with 'pending contribution' in price overview
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 23:46:05 -08:00
hailin
81a58edaca
fix(contribution-service): calculate totalContribution correctly in CDC event
...
Previously, totalContribution was incorrectly set to effectiveContribution.
Now correctly calculated as: personal + teamLevel + teamBonus
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 23:40:50 -08:00
hailin
141db46356
fix(contribution-service): use real contributionPerTree from rate service
...
Previously, adoptions were synced with hardcoded contributionPerTree=1,
resulting in contribution values like 0.7 instead of the expected 15831.9.
Now the handler fetches the actual contribution rate from ContributionRateService
based on the adoption date, storing values like:
- Personal (70%): 22617 × 70% = 15831.9
- Team Level (0.5%): 22617 × 0.5% = 113.085
- Team Bonus (2.5%): 22617 × 2.5% = 565.425
Note: Historical data may need migration to apply the correct multiplier.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 18:01:30 -08:00
hailin
f2692a50ed
fix(contribution-service): fix toRecordDto using wrong property name
...
- Changed `record.finalContribution` to `record.amount` for getting final contribution value
- Added optional chaining to prevent undefined errors
- Added default values for safety
The ContributionRecordAggregate uses `amount` property, not `finalContribution`.
This was causing "Cannot read properties of undefined (reading 'value')" errors.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 08:43:14 -08:00
hailin
0bbb52284c
fix(contribution): avoid nested transaction timeout in BonusClaimService
...
Use unitOfWork.isInTransaction() to detect if already in a transaction
context (called from ContributionCalculationService). If so, reuse the
existing transaction instead of opening a new one, preventing Prisma
interactive transaction timeout errors.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 01:02:08 -08:00
hailin
2a79c83715
feat(contribution): implement TEAM_BONUS backfill when unlock conditions met
...
When a user's direct referral count reaches 2 or 4, the system now automatically
backfills previously pending TEAM_BONUS (T2/T3) contributions that were allocated
to headquarters while waiting for unlock conditions.
- Add BonusClaimService for handling bonus backfill logic
- Add findPendingBonusByAccountSequence and claimBonusRecords to repository
- Integrate bonus claim into updateReferrerUnlockStatus flow
- Add BonusClaimed event consumer in mining-wallet-service
- Generate ledger records for backfilled contributions
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 23:58:54 -08:00