feat: 集成code-review skill到项目
- 项目级 skill: .claude/skills/code-review/ (398行SKILL.md + 参考文件) - 自动触发: AI修改.py/.cbl/.cpy/.lark后自动review - CLAUDE.md: 定义触发规则、review流程、严重级别 - .code-review.yaml: tier=standard, 高风险模块配置 效果: clone即用, 每次代码变更后自动审查, 防止低质量代码入库 Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
NB-076
@@ -0,0 +1,25 @@
|
||||
# Data Migration — Manual Review Checklist
|
||||
|
||||
## Rollback Plan
|
||||
- [ ] Rollback script tested and ready before migration
|
||||
- [ ] Rollback handles partial migration state
|
||||
- [ ] Rollback is idempotent
|
||||
- [ ] Database backup taken before migration
|
||||
|
||||
## Consistency Verification
|
||||
- [ ] Migration verification query defined (row count, checksum, sample compare)
|
||||
- [ ] Old and new data validated before old table dropped
|
||||
- [ ] Foreign key constraints preserved
|
||||
- [ ] Indexes migrated or recreated
|
||||
|
||||
## Large Table Strategy
|
||||
- [ ] Batch processing with configurable batch size
|
||||
- [ ] Migration doesn't lock table for extended period
|
||||
- [ ] Progress tracking (how many rows processed)
|
||||
- [ ] Rate limiting to avoid DB overload
|
||||
- [ ] Dry-run mode tested before actual migration
|
||||
|
||||
## Idempotency
|
||||
- [ ] Migration script is idempotent (can be re-run safely)
|
||||
- [ ] Uses INSERT ON CONFLICT / INSERT IGNORE / MERGE as appropriate
|
||||
- [ ] Migration tracks what has been processed (checkpoint table)
|
||||
@@ -0,0 +1,23 @@
|
||||
# Distributed Lock — Manual Review Checklist
|
||||
|
||||
## Timeout Strategy
|
||||
- [ ] Lock TTL defined and justified (not arbitrary)
|
||||
- [ ] TTL exceeds maximum expected operation time
|
||||
- [ ] Watchdog/refresh mechanism if operation may exceed TTL
|
||||
- [ ] Lock auto-releases on process crash (not permanent deadlock)
|
||||
|
||||
## Release Mechanism
|
||||
- [ ] Lock released by the same instance that acquired it (ownership check)
|
||||
- [ ] Release is atomic (check-then-release is not atomic — use Lua script or compare-and-delete)
|
||||
- [ ] Lock release in finally/defer block guaranteed to execute
|
||||
|
||||
## Retry Strategy
|
||||
- [ ] Retry with exponential backoff, not infinite retry
|
||||
- [ ] Maximum retry count or timeout defined
|
||||
- [ ] Failed lock acquisition returns clear error (not silent fallback)
|
||||
|
||||
## Granularity & Deadlock
|
||||
- [ ] Lock key granularity appropriate (per-resource, not global)
|
||||
- [ ] Multiple lock acquisition order consistent (prevents deadlock)
|
||||
- [ ] No nested locks on same resource
|
||||
- [ ] Lock contention monitored/metrics available
|
||||
@@ -0,0 +1,21 @@
|
||||
# Inventory Module — Manual Review Checklist
|
||||
|
||||
## Concurrency Safety
|
||||
- [ ] Stock deduction uses atomic operations (optimistic lock, Redis decr, DB atomic update)
|
||||
- [ ] No SELECT + UPDATE gap for stock operations
|
||||
- [ ] Lock granularity: per-SKU, not global lock on inventory table
|
||||
|
||||
## Pre-sale / Reservation
|
||||
- [ ] Pre-sale inventory separated from actual inventory
|
||||
- [ ] Reservation timeout and auto-release mechanism
|
||||
- [ ] Reservation-to-actual-deduction transition is atomic
|
||||
|
||||
## Audit Trail
|
||||
- [ ] Every stock change logged with: SKU, quantity, operation type, order ID, timestamp
|
||||
- [ ] Stock reconciliation queryable from audit log
|
||||
- [ ] No direct DB updates bypassing the service layer
|
||||
|
||||
## Stock Recovery
|
||||
- [ ] Order cancellation triggers stock recovery
|
||||
- [ ] Recovery is idempotent (double-cancel doesn't double-recover)
|
||||
- [ ] Recovery handles edge case: stock recovered after SKU deleted
|
||||
@@ -0,0 +1,23 @@
|
||||
# Order Module — Manual Review Checklist
|
||||
|
||||
## State Machine
|
||||
- [ ] All order states defined and documented
|
||||
- [ ] Valid transitions enforced (no impossible state changes)
|
||||
- [ ] Terminal states properly handled (no further mutations)
|
||||
- [ ] State change audit log exists
|
||||
|
||||
## Concurrent Deduction
|
||||
- [ ] Inventory deduction uses optimistic lock (version number) or pessimistic lock (SELECT FOR UPDATE)
|
||||
- [ ] No race condition between check and deduction (not SELECT → check → UPDATE)
|
||||
- [ ] Oversell prevention verified
|
||||
|
||||
## Timeout Cancellation
|
||||
- [ ] Unpaid order timeout mechanism (scheduled job, delayed queue, or TTL)
|
||||
- [ ] Cancellation releases held inventory
|
||||
- [ ] Cancellation releases held coupons/promotions
|
||||
- [ ] Timeout is configurable, not hardcoded
|
||||
|
||||
## Distributed Transaction
|
||||
- [ ] Cross-service operations (order + inventory + payment) have compensation logic
|
||||
- [ ] Saga pattern or eventual consistency defined
|
||||
- [ ] Failure recovery documented (what happens if order succeeds but payment fails)
|
||||
@@ -0,0 +1,26 @@
|
||||
# Payment Module — Manual Review Checklist
|
||||
|
||||
## Callback Idempotency
|
||||
- [ ] Is payment callback idempotent? (duplicate notification won't double-charge)
|
||||
- [ ] Idempotency key sourced from payment provider's transaction ID
|
||||
- [ ] Idempotency check happens before any state change
|
||||
|
||||
## Amount Precision
|
||||
- [ ] All monetary amounts use integer cents or decimal with fixed precision
|
||||
- [ ] No floating-point arithmetic in payment calculations
|
||||
- [ ] Rounding strategy defined and consistent (round half up vs floor)
|
||||
|
||||
## Reconciliation
|
||||
- [ ] Reconciliation logic matches payment provider's settlement model
|
||||
- [ ] Discrepancy thresholds defined (when to auto-adjust vs flag for manual review)
|
||||
- [ ] Reconciliation runs are idempotent
|
||||
|
||||
## Refund State Machine
|
||||
- [ ] All refund states defined (pending, processing, completed, failed)
|
||||
- [ ] Transition rules enforced (can't refund a refunded payment)
|
||||
- [ ] Partial refund logic correct (remaining refundable amount tracked)
|
||||
|
||||
## Third-Party Timeout
|
||||
- [ ] Payment provider timeout handled (request timed out ≠ payment failed)
|
||||
- [ ] Retry strategy for querying payment status
|
||||
- [ ] Circuit breaker or backoff for provider outages
|
||||
@@ -0,0 +1,28 @@
|
||||
# Permission Module — Manual Review Checklist
|
||||
|
||||
## RBAC Model
|
||||
- [ ] Roles and permissions clearly defined and documented
|
||||
- [ ] No permission inheritance cycles
|
||||
- [ ] Super admin role cannot be accidentally assigned to regular users
|
||||
- [ ] Role changes are logged
|
||||
|
||||
## Authorization Enforcement
|
||||
- [ ] Every protected endpoint checks permissions (not just login state)
|
||||
- [ ] Resource-level permissions: user can only access own data
|
||||
- [ ] Admin endpoints segregated from user endpoints (different middleware chain)
|
||||
|
||||
## Horizontal Escalation
|
||||
- [ ] User A cannot access User B's resources by changing ID in request
|
||||
- [ ] Resource ownership verified on every request (not just at list level)
|
||||
- [ ] Bulk operations check permissions per-item, not just the batch endpoint
|
||||
|
||||
## Vertical Escalation
|
||||
- [ ] Regular users cannot perform admin actions
|
||||
- [ ] Role checks happen server-side (not trusting client-claimed role)
|
||||
- [ ] Privileged operations require re-authentication
|
||||
|
||||
## Token Strategy
|
||||
- [ ] Access token: short-lived (15-60 min)
|
||||
- [ ] Refresh token: long-lived, stored securely (httpOnly cookie)
|
||||
- [ ] Token rotation on refresh (old refresh token invalidated)
|
||||
- [ ] Token revocation mechanism (logout invalidates all user tokens)
|
||||
Reference in New Issue
Block a user