# Story 2.6: Database Seeding

## Metadata
- **Story ID**: 2.6
- **Title**: Database Seeding
- **Epic**: 2 - Core Services (Authentication & Authorization)
- **Status**: Pending
- **Priority**: Medium
- **Estimated Time**: 4-6 hours
- **Dependencies**: 2.1, 2.2, 2.3, 2.4

## Goal
Provide database seeding functionality for all services to create initial admin user, default roles, and core permissions. Each service seeds its own database schema.

## Description
This story implements seeding for all core services. Each service has its own seed script that populates its database schema with initial data. The seeding uses service clients where cross-service data is needed (e.g., creating admin user in Identity Service, then assigning admin role via Authz Service).

## Deliverables

### 1. Identity Service Seeding (`services/identity/internal/seed/seed.go`)
- Create default admin user (if doesn't exist)
- Idempotent operations
- Uses Identity Service's own database connection

### 2. Authz Service Seeding (`services/authz/internal/seed/seed.go`)
- Create default roles (admin, user, guest)
- Create core permissions
- Assign core permissions to roles
- Uses Authz Service's own database connection

### 3. Seed Command (`cmd/seed/main.go`)
- Command-line interface for seeding all services
- Service-specific seed functions
- Configuration via environment variables
- Dry-run mode
- Verbose logging
- Uses service clients for cross-service operations (e.g., assign admin role to admin user)

### 4. Service-Specific Seed Functions
- Each service can seed its own schema independently
- Seed functions are idempotent (safe to run multiple times)
- Seed functions use service clients when needed

### 5. Integration
- Optional: Auto-seed on first startup in development
- Manual seeding in production
- Can be run per-service or all services at once

## Acceptance Criteria
- [x] Identity Service seed creates admin user successfully
- [x] Authz Service seed creates default roles with proper permissions
- [x] Seeding is idempotent (can run multiple times safely)
- [x] Seed command can be run via CLI
- [x] Seed command uses service clients for cross-service operations
- [x] Each service seeds its own database schema
- [x] Admin user can login and manage system after seeding

## Related ADRs
- [ADR-0029: Microservices Architecture](../../adr/0029-microservices-architecture.md)
- [ADR-0030: Service Communication Strategy](../../adr/0030-service-communication-strategy.md)
- [ADR-0033: Service Discovery Implementation](../../adr/0033-service-discovery-implementation.md)

## Implementation Notes
- Seeding is typically done once per environment
- Can be run as a separate command or as part of deployment
- Uses service clients for cross-service operations (e.g., IdentityServiceClient, AuthzServiceClient)
- Each service manages its own seed data
- Seed command coordinates seeding across services

## Testing
```bash
# Test seeding
go run cmd/seed/main.go

# Test idempotency
go run cmd/seed/main.go
go run cmd/seed/main.go  # Should be safe to run again

# Test service-specific seeding
go run cmd/seed/main.go --service=identity
go run cmd/seed/main.go --service=authz
```

## Files to Create/Modify
- `services/identity/internal/seed/seed.go` - Identity Service seed functions
- `services/authz/internal/seed/seed.go` - Authz Service seed functions
- `cmd/seed/main.go` - Seed command (coordinates all services)
- `Makefile` - Add seed command