diff --git a/assets/templates/design_doc.md b/assets/templates/design_doc.md
index 5dc6021..b551411 100644
--- a/assets/templates/design_doc.md
+++ b/assets/templates/design_doc.md
@@ -1,9 +1,513 @@
-# Design — <FR id / Title>
+<!--META
+{
+  "kind": "design_document",
+  "tokens": ["FeatureId", "CreatedDate", "Title"]
+}
+-->
 
-## Context & Goals
-## Non-Goals & Constraints
-## Options Considered
-## Decision & Rationale
-## Architecture Diagram(s)
-## Risks & Mitigations
-## Acceptance Criteria (measurable)
\ No newline at end of file
+# Design Document: {Title}
+
+**Feature ID:** {FeatureId}
+**Status:** Draft
+**Created:** {CreatedDate}
+**Last Updated:** {CreatedDate}
+**Authors:** [To be filled by AI from discussion participants]
+**Reviewers:** [To be filled from discussion]
+
+---
+
+## Executive Summary
+
+[1-2 paragraph overview of the feature and this design's approach. What problem does this solve? What's the proposed solution at a high level?]
+
+---
+
+## 1. Context & Problem Statement
+
+### Background
+
+[What is the current state? What pain points or opportunities led to this feature request?]
+
+### Business Goals
+
+- [Goal 1: e.g., Reduce user onboarding time by 50%]
+- [Goal 2: e.g., Support 10,000 concurrent users]
+- [Goal 3: e.g., Enable third-party integrations]
+
+### Success Metrics
+
+| Metric | Target | Measurement Method |
+|--------|--------|-------------------|
+| [e.g., Page load time] | [< 2s] | [Performance testing] |
+| [e.g., User satisfaction] | [> 4.5/5] | [Post-feature survey] |
+
+---
+
+## 2. Requirements
+
+### Functional Requirements
+
+**Must Have (MVP):**
+- [ ] [FR-1: User can create account with email/password]
+- [ ] [FR-2: User can reset password via email]
+- [ ] [FR-3: User can log in with Google OAuth]
+
+**Should Have (Nice to Have):**
+- [ ] [FR-4: Remember me functionality]
+- [ ] [FR-5: Two-factor authentication]
+
+**Won't Have (Out of Scope):**
+- [FR-6: Social login with Facebook/Twitter (deferred to v2)]
+- [FR-7: Biometric authentication (platform limitations)]
+
+### Non-Functional Requirements
+
+**Performance:**
+- Response time: < 200ms for API calls
+- Throughput: Support 1,000 requests/second
+- Database queries: < 50ms p95
+
+**Security:**
+- Password hashing: bcrypt with salt
+- Token expiration: 1 hour for access, 7 days for refresh
+- Rate limiting: 10 failed login attempts = 15min lockout
+
+**Scalability:**
+- Horizontal scaling: Support 10+ app instances
+- Database: Read replicas for query performance
+- Caching: Redis for session storage
+
+**Reliability:**
+- Uptime: 99.9% SLA
+- Data durability: Daily backups with 30-day retention
+- Graceful degradation: Fallback to email-only if OAuth fails
+
+---
+
+## 3. Options Considered
+
+### Option 1: [Name, e.g., "In-house Authentication System"]
+
+**Approach:**
+[Description of this option]
+
+**Pros:**
+- ✅ [Pro 1]
+- ✅ [Pro 2]
+
+**Cons:**
+- ❌ [Con 1]
+- ❌ [Con 2]
+
+**Cost/Complexity:**
+- Development: [X person-weeks]
+- Maintenance: [Y hours/month]
+- Infrastructure: [Z $/month]
+
+**Risk Assessment:**
+- [Risk 1: Security vulnerabilities - HIGH]
+- [Risk 2: Development timeline - MEDIUM]
+
+---
+
+### Option 2: [Name, e.g., "Third-Party Auth Service (Auth0)"]
+
+**Approach:**
+[Description]
+
+**Pros:**
+- ✅ [Pro 1]
+- ✅ [Pro 2]
+
+**Cons:**
+- ❌ [Con 1]
+- ❌ [Con 2]
+
+**Cost/Complexity:**
+- Development: [X person-weeks]
+- Maintenance: [Y hours/month]
+- Infrastructure: [Z $/month]
+
+**Risk Assessment:**
+- [Risk 1]
+- [Risk 2]
+
+---
+
+### Option 3: [Name, if applicable]
+
+[Repeat structure from Option 1/2]
+
+---
+
+## 4. Decision & Rationale
+
+### Selected Approach: [Option Name]
+
+**Primary Reasons:**
+1. [Reason 1: Aligns with technical stack]
+2. [Reason 2: Lowest total cost of ownership]
+3. [Reason 3: Fastest time to market]
+
+**Trade-offs Accepted:**
+- [Trade-off 1: Higher infrastructure costs vs. lower dev time]
+- [Trade-off 2: Vendor lock-in vs. managed service reliability]
+
+**Alternatives Rejected:**
+- **Option X** rejected because: [reason]
+- **Option Y** rejected because: [reason]
+
+**Key Assumptions:**
+- [Assumption 1: User growth will remain under 100K for next 12 months]
+- [Assumption 2: OAuth providers maintain 99.9% uptime]
+
+**When to Revisit:**
+- If user base exceeds 500K (cost model changes)
+- If OAuth vendor has >2 major outages in 6 months
+- After 1 year in production (reevaluate build vs. buy)
+
+---
+
+## 5. Architecture
+
+### System Architecture Diagram
+
+```
+[Insert diagram here - can be ASCII art, PlantUML, or image link]
+
+Example:
+┌─────────────┐      ┌──────────────┐      ┌─────────────┐
+│   Browser   │─────▶│  API Gateway │─────▶│   Auth      │
+│             │◀─────│              │◀─────│   Service   │
+└─────────────┘      └──────────────┘      └─────────────┘
+                             │                      │
+                             │                      ▼
+                             │              ┌──────────────┐
+                             │              │   User DB    │
+                             │              │  (Postgres)  │
+                             │              └──────────────┘
+                             ▼
+                     ┌──────────────┐
+                     │  Session     │
+                     │  Store       │
+                     │  (Redis)     │
+                     └──────────────┘
+```
+
+### Component Breakdown
+
+**Component 1: [Name, e.g., "Authentication Service"]**
+- **Responsibility:** Handle user login, registration, token issuance
+- **Technology:** Node.js (Express), PassportJS
+- **Interfaces:**
+  - REST API: `/auth/login`, `/auth/register`, `/auth/refresh`
+  - Events: `user.logged_in`, `user.registered`
+- **Dependencies:** User DB, Session Store, Email Service
+
+**Component 2: [Name]**
+[Repeat structure]
+
+### Data Models
+
+**User Table:**
+```sql
+CREATE TABLE users (
+  id            UUID PRIMARY KEY,
+  email         VARCHAR(255) UNIQUE NOT NULL,
+  password_hash VARCHAR(255),
+  oauth_provider VARCHAR(50),
+  oauth_id      VARCHAR(255),
+  created_at    TIMESTAMP DEFAULT NOW(),
+  updated_at    TIMESTAMP DEFAULT NOW(),
+  INDEX idx_email (email),
+  UNIQUE idx_oauth (oauth_provider, oauth_id)
+);
+```
+
+**Session Table:**
+```sql
+CREATE TABLE sessions (
+  id              UUID PRIMARY KEY,
+  user_id         UUID REFERENCES users(id),
+  access_token    VARCHAR(500) NOT NULL,
+  refresh_token   VARCHAR(500),
+  expires_at      TIMESTAMP NOT NULL,
+  created_at      TIMESTAMP DEFAULT NOW()
+);
+```
+
+### API Contracts
+
+**POST /auth/register**
+```json
+Request:
+{
+  "email": "user@example.com",
+  "password": "SecurePass123!",
+  "name": "John Doe"
+}
+
+Response (201 Created):
+{
+  "user_id": "uuid",
+  "access_token": "jwt",
+  "refresh_token": "jwt",
+  "expires_in": 3600
+}
+
+Errors:
+400 - Invalid email format
+409 - Email already registered
+422 - Password too weak
+```
+
+**POST /auth/login**
+[Similar structure]
+
+---
+
+## 6. Implementation Plan
+
+### Phases
+
+**Phase 1: Core Authentication (Week 1-2)**
+- [ ] Set up database schema
+- [ ] Implement email/password registration
+- [ ] Implement login endpoint
+- [ ] Add password hashing (bcrypt)
+- [ ] Write unit tests
+
+**Phase 2: OAuth Integration (Week 3)**
+- [ ] Integrate Google OAuth
+- [ ] Add OAuth callback handling
+- [ ] Link OAuth accounts to existing users
+- [ ] Test OAuth flow
+
+**Phase 3: Security Hardening (Week 4)**
+- [ ] Add rate limiting
+- [ ] Implement token refresh
+- [ ] Add password reset flow
+- [ ] Security audit
+
+**Phase 4: Testing & Deployment (Week 5)**
+- [ ] End-to-end testing
+- [ ] Load testing
+- [ ] Documentation
+- [ ] Production deployment
+
+### Dependencies
+
+- **External:**
+  - Google OAuth credentials (waiting on: Platform team)
+  - Email service API key (waiting on: DevOps)
+
+- **Internal:**
+  - User profile service (blocks: User settings feature)
+  - Session management (required by: All authenticated endpoints)
+
+### Resource Requirements
+
+- **Development:** 1 backend engineer (full-time, 5 weeks)
+- **Design:** 0.5 designer (mockups, 1 week)
+- **QA:** 0.5 QA engineer (testing, 1 week)
+- **Infrastructure:** $200/month (database + Redis)
+
+---
+
+## 7. Risks & Mitigations
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| OAuth provider downtime | Medium | High | Fallback to email auth; cache OAuth tokens |
+| Password breach | Low | Critical | Bcrypt + salt; enforce strong passwords; rate limit |
+| Database bottleneck | Medium | High | Add read replicas; implement caching |
+| Token theft | Medium | High | Short expiration; secure httpOnly cookies |
+
+### Security Considerations
+
+**Threat Model:**
+- **Threat 1: Brute force attacks** → Mitigation: Rate limiting, CAPTCHA after 3 failures
+- **Threat 2: SQL injection** → Mitigation: Parameterized queries, ORM usage
+- **Threat 3: XSS in user data** → Mitigation: Input validation, output encoding
+
+**Compliance:**
+- GDPR: User data deletion within 30 days of request
+- CCPA: User data export API endpoint
+- SOC 2: Audit logging for all auth events
+
+---
+
+## 8. Testing Strategy
+
+### Unit Tests
+- Password hashing/validation
+- Token generation/validation
+- Input validation logic
+- Coverage target: 90%
+
+### Integration Tests
+- Registration flow (email + OAuth)
+- Login flow (email + OAuth)
+- Token refresh flow
+- Password reset flow
+
+### End-to-End Tests
+- New user signup journey
+- Returning user login journey
+- OAuth account linking
+- Session expiration handling
+
+### Performance Tests
+- Concurrent logins: 1,000 users/second
+- Database query performance: < 50ms p95
+- API response time: < 200ms p95
+
+---
+
+## 9. Monitoring & Observability
+
+### Metrics to Track
+
+**Business Metrics:**
+- Daily active users (DAU)
+- Registration conversion rate
+- OAuth vs. email signup ratio
+
+**Technical Metrics:**
+- API response time (p50, p95, p99)
+- Error rate by endpoint
+- Database connection pool utilization
+- Cache hit rate
+
+### Alerts
+
+- Error rate > 5% for 5 minutes → Page on-call engineer
+- Response time p95 > 500ms → Slack warning
+- Failed login attempts > 100/min → Slack + investigate
+
+### Dashboards
+
+- Real-time: Login success/failure rates, active sessions
+- Daily: User growth, OAuth provider breakdown
+- Weekly: Performance trends, error analysis
+
+---
+
+## 10. Documentation & Training
+
+### User-Facing Documentation
+- [ ] Registration guide
+- [ ] Password reset guide
+- [ ] OAuth connection guide
+- [ ] Security best practices
+
+### Developer Documentation
+- [ ] API reference (OpenAPI spec)
+- [ ] Local development setup
+- [ ] Testing guide
+- [ ] Deployment runbook
+
+### Training Materials
+- [ ] Team demo of authentication flow
+- [ ] Security review session
+- [ ] Runbook walkthrough for on-call engineers
+
+---
+
+## 11. Rollout Plan
+
+### Feature Flags
+
+```yaml
+feature_flags:
+  auth_email_registration: true
+  auth_google_oauth: false  # Enable after testing
+  auth_password_reset: false  # Enable in phase 2
+```
+
+### Rollout Stages
+
+1. **Internal Alpha (Week 1)**
+   - Deploy to staging
+   - Team testing (10 users)
+   - Fix critical bugs
+
+2. **Beta (Week 2)**
+   - Deploy to 10% of production traffic
+   - Monitor error rates
+   - Collect user feedback
+
+3. **General Availability (Week 3)**
+   - Ramp to 50%, then 100%
+   - Enable OAuth
+   - Sunset old authentication system (Week 4)
+
+### Rollback Plan
+
+- **Trigger:** Error rate > 10% or critical security issue
+- **Procedure:**
+  1. Disable feature flag
+  2. Route traffic to old system
+  3. Incident post-mortem within 24 hours
+- **RTO:** 5 minutes (time to disable flag)
+- **RPO:** 0 (no data loss)
+
+---
+
+## 12. Future Enhancements
+
+### Deferred to v2
+- Two-factor authentication (SMS, TOTP)
+- Social login (Facebook, Twitter, GitHub)
+- Biometric authentication
+- SSO for enterprise customers
+
+### Technical Debt Accepted
+- [Debt 1: Monolithic auth service - plan to split into microservices after 100K users]
+- [Debt 2: In-memory session cache - migrate to distributed cache under high load]
+
+---
+
+## 13. Acceptance Criteria
+
+This design is considered complete and ready for implementation when:
+
+- [x] All stakeholders have reviewed and approved
+- [ ] Security team has completed threat model review
+- [ ] At least 2 technical reviewers have signed off
+- [ ] All "Must Have" functional requirements are addressed
+- [ ] Performance targets are achievable (validated by load test plan)
+- [ ] Rollback plan is documented and tested
+- [ ] Cost estimate approved by finance
+
+---
+
+## 14. Appendices
+
+### Appendix A: Research & References
+
+- [Link to competitive analysis]
+- [Link to user research findings]
+- [Link to technology evaluation matrix]
+
+### Appendix B: Meeting Notes
+
+**Design Review 1 (YYYY-MM-DD):**
+- Attendees: [Names]
+- Decisions: [Key decisions]
+- Action items: [Follow-ups]
+
+### Appendix C: Change Log
+
+| Date | Author | Change |
+|------|--------|--------|
+| {CreatedDate} | AI_Claude | Initial draft from feature discussion |
+| | | |
+
+---
+
+**Document Status:** 🟡 Draft - Awaiting Review
+**Next Review Date:** [YYYY-MM-DD]
+**Related Documents:**
+- Feature Discussion: `../discussions/design.discussion.md`
+- Implementation Plan: `../implementation/plan.md` (created after approval)