做完了一部分,备份一下,防止以外删除

specs/001-fiber-middleware-integration/plan.md

@@ -226,13 +226,12 @@ junhong_cmp_fiber/
 3. Fiber middleware execution order and error handling patterns
 4. Fiber keyauth middleware customization for Redis token validation
 5. Fiber limiter middleware configuration options and IP extraction
-6. Redis client selection and connection pool configuration for Go
-7. UUID v4 generation in Go (standard library vs third-party)
+6. Redis connection pool configuration for go-redis/redis/v8 (already decided)
+7. UUID v4 generation using github.com/google/uuid (already in go.mod)
 8. Graceful shutdown patterns for config watchers and HTTP server
 
 **Unknowns to Resolve**:
-- Best Redis client library for Go (go-redis vs redigo)
-- Optimal Viper hot reload implementation (polling vs fsnotify)
+- Optimal Viper hot reload implementation (polling vs fsnotify - recommend fsnotify)
 - How to properly separate Fiber logger middleware output to access.log
 - How to inject custom Zap logger into Fiber recover middleware
 - Request ID propagation through Fiber context
@@ -295,7 +294,12 @@ This phase will generate `tasks.md` with implementation steps ordered by depende
 - Use `github.com/go-redis/redis/v8` for Redis client (widely adopted, good performance)
 - Use `github.com/fsnotify/fsnotify` (Viper's native watcher) for hot reload
 - Use `github.com/google/uuid` (already in go.mod) for UUID v4 generation
-- Separate Zap logger instances for app.log and access.log
+- Separate Zap logger instances for app.log and access.log:
+  - **appLogger**: Initialized with Lumberjack writer pointing to `app.log` with independent rotation settings (max size, max age, max backups, compression). Used for all application-level logging (business logic, errors, middleware events, debug info).
+  - **accessLogger**: Initialized with separate Lumberjack writer pointing to `access.log` with independent rotation settings. Used exclusively for HTTP access logs (request method, path, status, duration, request ID, IP, user agent, user ID).
+  - Both loggers use Zap's structured JSON encoder with consistent field naming.
+  - Logger instances are global variables (package-level) initialized in `pkg/logger/logger.go` via `InitLoggers()` function called from `main.go` at startup.
+  - Each logger has its own Lumberjack configuration to enable different retention policies (e.g., 30 days for app.log, 90 days for access.log).
 - Middleware order: recover → requestid → logger → keyauth → limiter → handler
 
 ### Risk Mitigation: