hailin
/
rwadurian
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2,436 Commits 1 Branch 10 Tags 175 MiB
Commit Graph

5 Commits

Author SHA1 Message Date
hailin 023d71ac33 feat(authorization): 提高省团队权益初始激活门槛至3000棵 
省团队(AUTH_PROVINCE_COMPANY)初始激活门槛: 500棵 → 3000棵

当前各角色初始激活门槛汇总:
- 社区(COMMUNITY): 100棵（上次已调整: 10→100）
- 市团队(AUTH_CITY_COMPANY): 500棵（上次已调整: 100→500）
- 省团队(AUTH_PROVINCE_COMPANY): 3000棵（本次调整: 500→3000）
- 市区域(CITY_COMPANY): 10000棵（未变）
- 省区域(PROVINCE_COMPANY): 50000棵（未变）

变更说明:
- 仅调整初始激活门槛，月度阶梯考核目标不变
- 已激活用户不受影响（祖父条款），仅对新申请的授权生效
- 数据库已有记录的 initialTargetTreeCount 保持旧值不变
- 需在服务器重新部署 authorization-service 后生效

修改文件:
- assessment-config.vo.ts: 核心门槛配置 500→3000
- authorization-application.service.ts: AUTH_PROVINCE_TARGET 常量及注释同步
- authorization.dto.ts: DTO 注释同步
- authorization.response.ts: ApiProperty 注释同步
- DEVELOPMENT_GUIDE.md: 文档说明同步

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-26 01:44:02 -08:00
hailin eacdfddff8 feat(authorization): 提高社区和市团队权益初始激活门槛 
社区初始激活门槛: 10棵 → 100棵
市团队初始激活门槛: 100棵 → 500棵

变更说明:
- 仅调整初始激活门槛，月度考核目标不变（社区仍为10棵/月，市团队仍为100棵/月）
- 已激活用户不受影响（祖父条款），仅对新申请的授权生效
- 激活逻辑通过 AssessmentConfig 工厂方法动态获取门槛值，无需修改业务代码
- 数据库已有记录的 initialTargetTreeCount 保持旧值不变

修改文件:
- assessment-config.vo.ts: 核心门槛配置
- authorization-application.service.ts: 同步注释
- authorization-role.aggregate.spec.ts: 同步测试断言
- DEVELOPMENT_GUIDE.md: 同步文档描述

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-25 22:55:22 -08:00
hailin 4bf4efb1f4 feat(authorization): add assessment rules for province/city area roles 
- Province area (PROVINCE_COMPANY): 50,000 trees initial target
- City area (CITY_COMPANY): 10,000 trees initial target
- Apply consistent assessment logic: pre-target rewards go to system account, post-target rewards go to company
- Auto-activate benefit when target is reached

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2025-12-11 21:57:00 -08:00
hailin 747e4ae8ef refactor(mpc-system): migrate to party-driven architecture with PartyID-based routing 
- Remove Address field from PartyEndpoint (parties connect to router themselves)
- Update K8s Discovery to only manage PartyID and Role labels
- Add Party registration and SessionEvent protobuf definitions
- Implement PartyRegistry and SessionEventBroadcaster domain logic
- Add RegisterParty and SubscribeSessionEvents gRPC handlers
- Prepare infrastructure for party-driven MPC coordination

This is the first phase of migrating from coordinator-driven to party-driven
architecture following international MPC system design patterns.
 2025-12-05 08:11:28 -08:00
Developer ea03df9059 feat(authorization-service): Implement complete authorization service with DDD architecture 
## Features
- Province/City Company authorization (省代/市代授权)
- Community authorization (社区授权)
- Monthly assessment with ladder targets (月度阶梯考核)
- Team validation for referral chain conflicts (推荐链授权冲突检测)
- First place ranking rewards (区域第一名奖励)

## Architecture
- Domain Layer: Aggregates, Entities, Value Objects, Domain Events, Services
- Application Layer: Commands, Services, Schedulers
- Infrastructure Layer: Prisma ORM, Redis Cache, Kafka Events
- API Layer: Controllers, DTOs, Guards

## Testing
- Unit tests: 33 tests (aggregates, entities, value objects)
- Integration tests: 30 tests (domain services)
- E2E tests: 6 tests (API endpoints)
- Docker test environment with PostgreSQL, Redis, Kafka

## Documentation
- ARCHITECTURE.md: System design and DDD patterns
- API.md: REST API endpoints reference
- DEVELOPMENT.md: Development guide
- TESTING.md: Testing strategies and examples
- DEPLOYMENT.md: Docker/Kubernetes deployment

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
 2025-12-01 06:30:07 -08:00