The /sdd-explore command launches an investigation sub-agent that researches your codebase and compares approaches. It’s designed for thinking through problems before committing to a change.
Exploration is read-only by default. No code modifications, no artifacts created unless tied to a named change.
/sdd-explore "state management for user preferences"
Output:
## Exploration: State Management for User Preferences### Current StateUser preferences currently stored in localStorage directly from components.No centralized state management. 5 components read/write preferences independently.### Affected Areas- `src/components/ThemeToggle.tsx` — reads theme preference- `src/components/LanguageSelector.tsx` — reads language preference- `src/components/NotificationSettings.tsx` — reads notification prefs- `src/hooks/useLocalStorage.ts` — shared localStorage hook- `src/types/preferences.ts` — type definitions### Approaches| Approach | Pros | Cons | Complexity ||----------|------|------|------------|| Context API | Native React, no deps, familiar | Verbose, potential re-render issues | Low || Zustand | Minimal boilerplate, great DX | New dependency, learning curve | Low || Redux Toolkit | Team knows it, powerful devtools | Heavy for this use case | Medium || Keep current | No refactor needed | Hard to maintain, prop drilling | Low |### Recommendation**Zustand** - Best balance of simplicity and scalability. The bundle size (1.2kb) is negligible, and the API is intuitive. Context API would work but Zustand's selectors prevent unnecessary re-renders.### Risks- Migration requires touching 5 components simultaneously- localStorage sync logic needs careful testing- Potential race conditions during hydration### Ready for ProposalYes. Recommend proceeding with Zustand approach.
## Exploration: Moving from REST to GraphQL### Current StateREST API with 23 endpoints. Frontend makes 4-7 requests per page load.No caching layer. Some endpoints return over-fetched data.### Affected Areas- `src/api/` — 23 REST endpoint clients- `src/hooks/` — 15 data-fetching hooks- `src/types/api.ts` — request/response types- Backend: `server/routes/` — all route handlers- Backend: `server/middleware/` — auth middleware### Approaches1. **Full Migration to GraphQL** - Pros: Best long-term solution, solves over-fetching, single endpoint - Cons: Complete rewrite, backend + frontend, 3-4 weeks - Effort: High2. **Incremental GraphQL Alongside REST** - Pros: Gradual migration, less risk, test in production - Cons: Maintain two systems, complexity increase - Effort: Medium3. **BFF Pattern with GraphQL** - Pros: Keep REST backend, add GraphQL layer, easier migration - Cons: Extra deployment, potential latency - Effort: Medium4. **Optimize REST (caching + query params)** - Pros: No new tech, fastest to implement - Cons: Doesn't solve over-fetching, bandaid solution - Effort: Low### Recommendation**BFF Pattern** - Add a GraphQL BFF in front of existing REST API. This allows incremental migration without rewriting the backend immediately. Use Apollo Server to wrap REST endpoints, then migrate frontend queries one feature at a time.### Risks- BFF becomes a bottleneck if not properly scaled- Two APIs to maintain during transition period- Team needs GraphQL training- Potential N+1 query issues if not careful with resolvers### Ready for ProposalNo - Need to validate BFF performance with prototype first. Suggest 2-day spike.
