## Options Analysis: [Decision Topic]

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| B: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| C: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |

**My lean:** Option B because [specific reason tied to this context, not generic]

**Before I proceed:** Which trade-offs are acceptable?

- [ ] Accept [specific con from leaned option]?
- [ ] Comfortable with [specific risk from leaned option]?
- [ ] Or prefer a different option?

## Options Analysis: Database for User Data

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: PostgreSQL | ACID compliance, your team knows SQL, mature tooling, strong for relational data | Rigid schema requires migrations, more upfront design | Medium | Low | No (migration painful) |
| B: MongoDB | Flexible schema, fast iteration, good for evolving data shapes | Eventual consistency trade-offs, less familiar to team, can become messy | Medium | Medium | No (migration painful) |
| C: Start with SQLite | Zero setup, fast for prototyping, easy to migrate later | Not for production scale, single-writer limitation | Low | Low | Yes (designed for migration) |

**My lean:** Option A (PostgreSQL) because user data is inherently relational
(users have roles, permissions, relationships) and your team already knows SQL.
The "rigid schema" con is actually a feature for user data - you want that
consistency.

**Before I proceed:**
- [ ] Accept that schema changes need migrations?
- [ ] Comfortable with more upfront data modelling?
- [ ] Or prefer a different option?

Before I refactor, let me present the options:

## Options Analysis: Auth Code Refactor

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: Extract to auth service | Clean separation, testable, reusable | Bigger change, need to update all callers | High | Medium | Partial |
| B: Clean up in place | Smaller diff, lower risk, quick win | Still coupled, limits future flexibility | Low | Low | Yes |
| C: Incremental over 3 PRs | Reviewable chunks, gradual migration, lower risk per change | Takes longer, temporary inconsistency | Medium | Low | Yes |

**My lean:** Option C because it gives you the benefits of proper extraction
(Option A) with lower risk per change. Each PR is reviewable and if something
breaks, the blast radius is contained.

**Before I proceed:**
- [ ] Accept temporary inconsistency during migration?
- [ ] Comfortable with 3 separate PRs?
- [ ] Or prefer a different approach?

Use whatever your codebase already uses for consistency. If no convention,
either is fine - this isn't a meaningful trade-off.

[Proceeds without options table]

## Options Analysis: JavaScript Date Library

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: date-fns | Tree-shakeable, functional, small bundle | More verbose, import each function | Low | Low | Yes |
| B: Day.js | Moment-like API, tiny (2kb), immutable | Smaller ecosystem than Moment was | Low | Low | Yes |
| C: Luxon | Best timezone support, by Moment team, immutable | Larger bundle (20kb), steeper learning curve | Low | Low | Yes |
| D: Native Intl + Temporal | Zero dependencies, future-proof | Temporal not stable yet, Intl limited for manipulation | Low | Medium | Yes |

**My lean:** Option A (date-fns) for most cases because tree-shaking keeps
bundle small and functional approach is clean. If you're doing heavy timezone
work, Option C (Luxon) instead.

**What's your primary use case?** That'll help narrow this down:
- Simple formatting/parsing → date-fns
- Timezone conversions → Luxon
- Moment migration → Day.js