docs: Add active project handoff documents

Introduce detailed session handoff documents for Craig's Emacs
configuration project. These provide strategic clarity using the
V2MOM framework and outline current progress, project goals,
recommended actions, and key insights. This addition aims to
streamline handovers and ensure continuity between sessions,
facilitating a systematic approach to addressing identified
challenges and opportunities for improvement.

3 files changed, 669 insertions, 0 deletions

diff --git a/docs/SESSION-HANDOFF-ACTIVE-PROJECT.org b/docs/SESSION-HANDOFF-ACTIVE-PROJECT.org
new file mode 100644
index 00000000..379b11a8
--- /dev/null
+++ b/docs/SESSION-HANDOFF-ACTIVE-PROJECT.org
@@ -0,0 +1,263 @@
+#+TITLE: 🚨 ACTIVE PROJECT - READ THIS FIRST 🚨
+#+AUTHOR: Claude Code Session Notes
+#+DATE: 2025-10-30
+
+* CURRENT PROJECT STATUS
+
+** 🎯 What We're Doing
+Working through a systematic approach to clean up and prioritize Craig's Emacs config work:
+
+1. ✅ *COMPLETE V2MOM* (Vision, Values, Methods, Obstacles, Metrics) - IN PROGRESS
+2. ⏳ *TRIAGE todo.org* - Use V2MOM to ruthlessly cancel ~60% of tasks
+3. ⏳ *EXECUTE TIER 1* - Ship quick wins (network check removal, Corfu, bug fixes)
+4. ⏳ *BUILD OBSERVABILITY* - Create profiling infrastructure (TIER 2)
+5. ⏳ *SYSTEMATIC EXECUTION* - Work through prioritized tasks one by one
+
+** 📍 Where We Are Right Now
+*Session Started:* 2025-10-30
+*Current Step:* V2MOM Methods section (60% complete - Vision + Values done)
+*Time Committed:* ~1 hour sessions, working systematically
+*Status:* PAUSED between sessions - resuming later this evening
+
+** 📄 Key Documents
+
+*** Primary Working Documents
+- *V2MOM:* [[file:emacs-config-v2mom.org][emacs-config-v2mom.org]] - Strategic framework (ACTIVELY EDITING)
+- *Issues Analysis:* [[file:../issues.org][../issues.org]] - Claude's detailed analysis with TIER system and implementations
+- *Current Todos:* [[file:../todo.org][../todo.org]] - Craig's existing task list (~50+ items, needs triage)
+
+*** Reference Documents
+- *Config Root:* [[file:../init.el][../init.el]]
+- *Modules:* [[file:../modules/][../modules/]]
+- *Tests:* [[file:../tests/][../tests/]]
+
+** 🔑 Key Insights About Craig's Work Patterns
+
+*** Strengths
+- Thoughtful and strategic thinker
+- Good research skills (thorough specs, complete code examples)
+- Does ship things (dashboard, dirvish, network check fixes)
+- Recognizes need for V2MOM framework
+- Uses config daily for real work
+
+*** Patterns to Address
+1. *Research > Execution* - Has complete code for Corfu, difftastic, transcription workflow... still TODO
+2. *Priority Inflation* - Too many [#A]/[#B] items, unclear what's actually urgent
+3. *Incomplete Strategy* - V2MOM structure exists but sections are empty
+4. *Hard to Say No* - [#C]/[#D] items should be CANCELLED but remain in list
+5. *Side Projects Compete* - Dupre theme work competes with core config maintenance
+
+*** What Craig Told Us About Himself
+> "I am building tools both because they solve problems, but also because I enjoy building."
+
+This is healthy! But need balance:
+- Fix rough edges FIRST (daily pain points)
+- Build fun stuff SECOND (after maintenance)
+- Cancel distractions ALWAYS (Signal client, minimap, etc.)
+
+** 🎯 Agreed Goals for This Project
+
+*** Immediate (Next 2-3 Sessions)
+1. ✅ Complete V2MOM (IN PROGRESS)
+2. ⏳ Triage todo.org using V2MOM as filter
+3. ⏳ Execute quick wins: network check, Corfu migration, bug fixes
+4. ⏳ Build debug-profiling.el infrastructure
+
+*** Short Term (Next Month)
+5. Profile and optimize org-agenda performance
+6. Ship reveal.js presentation workflow
+7. Establish weekly triage ritual
+
+*** Long Term (Ongoing)
+8. Ship more than research
+9. Maintain < 20 active todos
+10. Measure metrics from V2MOM
+
+** 📋 TIER System from issues.org
+
+*** TIER 1: Do These First (High Impact, Low Effort) - 1 weekend
+- Remove network check (15 min)
+- Fix missing functions (30 min)
+- Corfu migration (2 hours)
+- Mood-line switch (30 min)
+- Bug fixes (1 hour)
+
+*** TIER 2: Build Observability (HIGHEST VALUE) - 1 week
+- Create debug-profiling.el module (3-4 hours)
+- Profile org-agenda-rebuild (1 hour)
+- Add instrumentation and caching (2 hours)
+- Test org-agenda filtering functions (2-3 hours)
+
+*** TIER 3: Quick Wins (After Profiling) - 1-2 hours each
+- Reveal.js presentation workflow (2 hours)
+- Difftastic integration (30 min)
+- Local package development workflow (1 hour)
+
+*** TIER 4: Maybe/Someday (Probably Never)
+- Code-maat reimplementation (HOLD)
+- LaTeX config (HOLD until concrete need)
+- Elfeed dashboard (HOLD - unclear if actually used)
+- DWIM shell integration (HOLD - current solution works)
+- Jumper package (HOLD - already maintaining chime + org-msg)
+
+** 🚫 Items That Should Be CANCELLED
+
+From todo.org, these don't serve the vision:
+- [#D] Signal Client - Not in vision
+- [#D] Awesome-tray / mode-icons - Already have modeline
+- [#C] Minimap - Interesting, not important
+- [#C] Install Magit TODOs - Already works fine
+- [#C] Git Timemachine litters buffers - Minor annoyance
+- Many Dupre theme TODOs - Side project competing with maintenance
+
+## 💡 Key Recommendations for Craig
+
+### Week 1: Strategy + Quick Wins
+1. Complete V2MOM (2-3 hours)
+2. Triage todo.org using V2MOM (1-2 hours)
+3. Execute items you already have code for (2-3 hours)
+
+### Week 2: Observability Infrastructure
+4. Build debug-profiling.el (3-4 hours)
+5. Profile org-agenda (1 hour)
+
+### Week 3: Fix Performance + Ship Presentation
+6. Fix org-agenda based on profiling (2-3 hours)
+7. Ship reveal.js workflow (2 hours)
+
+### Ongoing: Maintenance Discipline
+- Weekly triage ritual (30 min every Sunday)
+- Measure metrics (startup time, agenda time, todo count)
+- Ship > Research
+
+** 🔄 Next Session Pickup Points
+
+When starting next session, Claude should:
+
+1. **Read this document first** to understand context
+2. **Check V2MOM status** - If incomplete, continue there
+3. **Reference issues.org** for detailed technical recommendations
+4. **Reference todo.org** for items to triage
+5. **Ask Craig:** "Where did we leave off? V2MOM? Triage? Execution?"
+
+** 📞 Questions to Ask Craig Next Session
+
+*IMMEDIATE (when resuming):*
+- "Ready to continue V2MOM? We left off at Methods section."
+- "How much time do you have?"
+
+*FOR METHODS SECTION:*
+Show Craig the draft list and ask:
+- "Which methods do you already do consistently?"
+- "Which do you want to do but don't yet?"
+- "Am I missing any important methods?"
+
+*AFTER V2MOM COMPLETE:*
+- "Ready to triage todo.org using the V2MOM?"
+- "Should we execute quick wins or continue systematic triage?"
+
+** 🎯 Success Metrics for This Project
+
+We'll know this is working when:
+- ✅ V2MOM is complete and provides clear strategic direction
+- ✅ todo.org shrinks from ~50 to < 20 active items
+- ✅ Craig ships 3-5 items per week (small but consistent)
+- ✅ Craig has profiling infrastructure to measure performance
+- ✅ Org agenda rebuild time is measured and improving
+- ✅ Weekly triage becomes habit
+
+** 💬 Craig's Words to Remember
+
+> "I think you should adjust issues.org with all your recommendations. They are exciting, eye-opening, and just feel right. Add even your guidance on latex. spot on. thanks for your honesty. I did ask for it and am genuinely grateful for your responses. I'll take action on them."
+
+> "What I need help with is integrating this in with my existing todo.org file... Some of the tasks I've listed should probably just be deleted or better yet, marked CANCELLED."
+
+> "I have about an hour to devote. You could lead me through it, I could do some questions/answer rounds with you to clarify my thinking."
+
+Craig is ready to execute. He asked for honesty and took it well. He recognizes the patterns and wants systematic help.
+
+** 🛠️ Technical Context
+
+*** Current Pain Points
+1. Org agenda is slow (performance bottleneck)
+2. Network check adds 1+ seconds to startup (technical debt)
+3. Missing functions cause errors (cj/log-silently, cj/goto-git-gutter-diff-hunks)
+4. Mail attachments workflow is awkward
+5. No profiling infrastructure to measure performance
+
+*** Items Craig Already Has Code For
+These can be executed immediately - just paste and test:
+- Transcription workflow (complete bash + elisp in todo.org:2-99)
+- Difftastic integration (complete config in todo.org:1211-1223)
+- Corfu migration (complete config in todo.org:1611-1639)
+
+*** Architecture
+- Modular structure: modules/*.el
+- Good test coverage for utilities
+- Modern packages: Vertico/Consult/Embark stack
+- Local package development: chime.el, org-msg
+
+** 📚 Related Reading
+
+If Craig or Claude need more context:
+- [[file:../issues.org::*Second Opinion: Ruthless Prioritization & Reality Checks][Second Opinion section in issues.org]] - Full analysis and recommendations
+- [[file:../issues.org::*TIER 1: Do These First][TIER 1-4 breakdown]] - Prioritized task system
+- [[file:../quality-engineer.org][quality-engineer.org]] - Testing philosophy (if exists)
+
+** 🚀 Current Session Notes
+
+*** 2025-10-30 Session 1 - V2MOM In Progress
+*Time:* ~1 hour
+*Status:* PAUSED - V2MOM 60% complete
+
+*What We Completed:*
+1. ✅ Created docs/ directory structure
+2. ✅ Created SESSION-HANDOFF-ACTIVE-PROJECT.org (this file)
+3. ✅ Created emacs-config-v2mom.org
+4. ✅ Created values-comparison.org (analysis doc)
+5. ✅ Completed Vision (already existed, kept as-is)
+6. ✅ Completed Values section (Intuitive, Fast, Simple)
+   - Intuitive: Muscle memory, mnemonics, which-key timing, "newspaper" code
+   - Fast: Startup < 2s, org-agenda is THE bottleneck, everything else acceptable
+   - Simple: Production software practices, simplicity produces reliability
+
+*What's Next:*
+1. ⏳ *Methods* - IN PROGRESS (have draft list, need Craig's input)
+2. ⏳ *Obstacles* - TODO
+3. ⏳ *Metrics* - TODO
+4. ⏳ *Finalize V2MOM* - Review and commit
+
+*Draft Methods List (Need Craig's Feedback):*
+These were proposed but Craig stopped before reviewing:
+1. Ruthless prioritization (V2MOM guides triage)
+2. Profile before optimizing (build observability first)
+3. Test-driven development (tests enable confident refactoring)
+4. Ship > Research (execute existing specs before exploring new)
+5. Weekly triage ritual (review todos, cancel stale, keep < 20 active)
+6. Measure metrics (track startup, agenda, test coverage, todo count)
+7. Extract packages (when custom code grows: chime, org-msg pattern)
+8. Incremental execution (ship small, test, iterate)
+
+*Questions to Ask Craig When Resuming:*
+- Which methods do you already do consistently?
+- Which do you want to do but don't yet?
+- Am I missing any important methods?
+
+*After Methods/Obstacles/Metrics Complete:*
+Then move to triage todo.org using completed V2MOM as filter.
+
+*Key Files Modified This Session:*
+- [[file:emacs-config-v2mom.org][emacs-config-v2mom.org]] - Main working document (60% complete)
+- [[file:values-comparison.org][values-comparison.org]] - Analysis doc (reference only)
+- [[file:SESSION-HANDOFF-ACTIVE-PROJECT.org][SESSION-HANDOFF-ACTIVE-PROJECT.org]] - This file
+
+*Next Session Starts With:*
+1. Read this handoff document
+2. Read emacs-config-v2mom.org to see what's complete
+3. Ask Craig: "Ready to continue V2MOM with Methods section?"
+4. Show Craig the draft Methods list
+5. Get feedback and complete Methods
+6. Move to Obstacles
+7. Move to Metrics
+8. Finalize V2MOM
+9. Then triage todo.org
diff --git a/docs/emacs-config-v2mom.org b/docs/emacs-config-v2mom.org
new file mode 100644
index 00000000..06664103
--- /dev/null
+++ b/docs/emacs-config-v2mom.org
@@ -0,0 +1,299 @@
+#+TITLE: Emacs Configuration V2MOM
+#+AUTHOR: Craig Jennings
+#+DATE: 2025-10-30
+#+FILETAGS: :strategy:planning:v2mom:
+
+* What is V2MOM?
+
+V2MOM is a strategic framework used to clarify goals and priorities:
+- *Vision:* What do you want to achieve?
+- *Values:* What principles guide decisions?
+- *Methods:* How will you achieve the vision?
+- *Obstacles:* What's in your way?
+- *Metrics:* How will you measure success?
+
+This document provides strategic clarity for prioritizing Emacs configuration work.
+
+* Vision
+
+Your personal ideal Emacs configuration allows you to work at the speed of your own thought. It's stable and never needs edge-case bug fixing. The functionality covers your workflow such that you can work all day in Emacs for any of the following task areas:
+
+- Programming in any language, including emacs-lisp, common-lisp, scheme, golang, and c
+- Reading ebooks, including marginalia handling
+- Listening to music, including playlist management
+- Listening to podcasts, including saving episodes
+- Task organizing and planning
+- Calendaring, including syncing with google calendar
+- Alerting and notifications on tasks and calendar events
+- Timer/stopwatch functionality, including pomodoro presets
+- Audio and desktop recording
+- Memorization drills
+- Email, including email-to-task integration
+- Messaging, i.e., IRC
+- File-management, including extensive integration, and DWM scratchpad integration outside Emacs
+- Shell commands, leveraging vterm and eshell with custom methods, and DWM scratchpad integration outside Emacs
+
+Anytime you make a change in the config, you have unit tests to tell you quickly if the change created unexpected issues. You have a test-runner that integrates with your workflow.
+
+* Values
+
+** Intuitive
+
+*Definition:* Intuition comes from muscle memory, clear mnemonics, and just-in-time discovery that reinforces learning without blocking productivity.
+
+*** Keybindings Build Intuition Through Layers
+1. *Muscle memory first* - C-; on home row becomes automatic habit
+2. *Mnemonics provide "aha!" moments* - C-c **m** for mail creates dopamine hits that cement permanent memory
+3. *Which-key teaches through active recall* - Appears after you try (not before), forcing attempt without wasting time
+
+The timing matters: which-key's delay is calibrated so you're challenged to remember, but not blocked from working.
+
+*** What Breaks Intuition
+- *Physically awkward keybindings* - C-c 1 z C-c f requires hand contortions and offers no mnemonic
+- *Syntax overhead* - Parentheses tracking steals time from real learning (logic bugs, architecture understanding)
+- *Poor architecture* - Common actions (like "save all attachments") shouldn't require architectural archaeology
+
+*** Code Reads "Like a Newspaper"
+- Each use-package declaration is a *story* (topic = package)
+- Configuration settings are *facts* (what it does, how it behaves)
+- Clear variable/method naming (yours + maintainers) makes code read like English
+- Accessible to intermediate elisp readers without deep archaeology
+
+*** Principle
+*Intuition is earned through repeated success, not instant magic.* The config should make success easy to achieve and memorable when it happens.
+
+
+
+** Fast
+
+*Definition:* Fast means staying in flow. Startup and org-agenda must not make me wait. Everything else is already acceptable.
+
+*** Performance Targets
+
+*Startup Time:*
+- Current: ~3.8 seconds (real clock time, not Emacs-reported)
+- Target: ~1 second (aspirational, may not be realistic given package count)
+- Comfortable: ~2 seconds (±)
+
+*Measurement:*
+#+begin_src bash
+time emacs --eval '(save-buffers-kill-emacs)'  # Real startup time
+#+end_src
+
+*Note:* Emacs-reported time is inaccurate. Messages buffer continues populating and Emacs remains unresponsive after "loaded" message appears.
+
+*** Critical Performance Issues (Must Fix)
+
+1. *Emacs startup* - 3.8s is too slow
+   - Network check adds 1+ seconds (DELETE THIS)
+   - Eager loading vs lazy loading
+
+2. *Opening org-agenda for first time* - **THE BOTTLENECK**
+   - "Takes forever and a full work day"
+   - Likely: recursive directory scan, no caching, too many files
+   - Solution: Profile first (build debug-profiling.el), then optimize
+
+*** Must Be Instant (Flow-Critical)
+- Keybinding response
+- Changing projects in projectile (already good ✓)
+- Opening large org files (already good ✓, except malformed files with stray "*"s)
+- Buffer/window operations
+
+*** Can Take 1-2 Seconds (Acceptable)
+- *Mail sync* - Consider putting on timer instead of manual trigger
+- *Calibredb* (PDFs/Epubs) - Known solution: shrink inventory to <1k books or contribute optimizations
+- *Org-noter* opening PDFs/Epubs - Needs reliability + reasonable speed
+- *Looking up org-noter notes* - Should be easy to pull into other documents
+- *Initial file indexing* (projectile, etc.)
+
+*** Disabled Due to Performance (Need Solutions)
+- *Grammar checker* - Installed but turned off because it slows everything down
+  - No task exists to fix this yet
+  - Breaks concentration when writing
+
+- *Bibliography management* - Don't know how to do in Emacs
+  - Worried about broken/slow tools breaking writing flow
+  - Need solution that "just works"
+
+*** Principle
+*Speed is about flow, not milliseconds.* Startup and agenda are flow-breakers. Everything else is fine. Don't optimize what doesn't hurt.
+
+
+
+** Simple
+
+*Definition:* Simple means clear, maintainable code following production software practices. Simplicity is a discipline that produces reliability. Config is production software - treat it as such.
+
+*** What Makes Code Simple
+1. *Clear naming* - Variables and functions say what they do
+2. *Small functions* - Easy to understand, test, and modify
+3. *Good comments* - NOT obvious comments ("cat with post-it note saying 'cat'")
+
+*Good comments:*
+- Navigation markers for long files
+- Explain complex/non-obvious logic
+- Document unobvious impacts of settings
+- Answer "why" not "what"
+
+*Bad comments:*
+#+begin_src emacs-lisp
+;; declare a variable
+(defvar variable 10)
+#+end_src
+
+*** Abstractions and Magic
+- *Abstractions are fine* if they serve a purpose
+- *Macros are irritating* when unnecessary, but acceptable when warranted
+- *Magic is acceptable* if it's reliable and you can build a mental model
+
+*Principle:* "I want to understand every line of what my config does, or at least have a decent mental model of how it probably works. Never use a tool you can't fully trust."
+
+*** Package Count
+Package count itself isn't a concern. Quality and maintainability matter.
+
+*Concerns:*
+- More packages = more potential breakage
+- Need ability to roll back when packages break (localrepo for package snapshots)
+- Maintenance burden is real, but manageable with good practices
+
+*Not concerned about:*
+- Absolute number of packages
+- Startup time impact (if lazy-loaded properly)
+- Cognitive load (if organized well)
+
+*** Config IS Production Software
+
+*Key insight:* "My Emacs config IS production software. I use it more than probably every other application combined. The impact when it's broken can crush my productivity."
+
+This means:
+- *Apply production practices:* Testing, modularity, documentation, version control
+- *Plan for failure:* Rollback capability (localrepo), error handling, graceful degradation
+- *Modular design:* Extract custom code into packages when it grows
+- *Long-term maintenance:* Architecture matters, technical debt has real cost
+
+*** Personal Software Platform
+"I see my config as a personal software project built on the software platform called Emacs. Emacs has taught me a great deal about how to build software platforms well."
+
+*Implications:*
+- Config follows software engineering principles
+- Custom functionality becomes packages (chime, org-msg, potentially jumper)
+- Good architecture enables evolution
+- Quality matters because uptime matters
+
+*** Why Simplicity Matters
+When config breaks, productivity is crushed. The discipline of simplicity produces reliability:
+- Simple code is easier to fix when it breaks
+- Simple architecture enables graceful degradation
+- Simple practices (testing, rollback) provide safety nets
+- Simple means never using tools you can't trust
+
+*** Principle
+*Simple means maintainable production software, not minimal or primitive.* Complexity is acceptable when it serves the vision and can be understood or trusted. **Simplicity is the practice that produces reliability as an outcome.**
+
+
+
+** Summary: Three Core Values
+
+1. *Intuitive* - Muscle memory, mnemonics, just-in-time discovery. Code reads like a newspaper.
+2. *Fast* - Startup and org-agenda must not break flow. Everything else is acceptable.
+3. *Simple* - Clear, maintainable, production-quality code. Simplicity produces reliability.
+
+
+
+* Methods
+
+#+begin_quote
+Working section - HOW will you achieve the vision while honoring the values?
+
+*PAUSED HERE - NEED CRAIG'S INPUT*
+
+Draft methods proposed by Claude (need review):
+1. Ruthless prioritization - V2MOM guides triage, cancel what doesn't serve vision
+2. Profile before optimizing - Build observability (debug-profiling.el), measure first
+3. Test-driven development - Tests give confidence to refactor, catch regressions
+4. Ship > Research - Execute existing specs before exploring new ones
+5. Weekly triage ritual - Review todos, cancel stale items, keep < 20 active
+6. Measure metrics - Track startup time, agenda time, test coverage, todo count
+7. Extract packages - When custom code grows, make it a package (chime, org-msg pattern)
+8. Incremental execution - Ship small, test, iterate. Portions not all-at-once.
+
+*Questions for Craig:*
+- Which of these do you already do consistently?
+- Which do you want to do but don't yet?
+- Am I missing any important methods?
+
+*Fill in below after discussion:*
+#+end_quote
+
+
+
+* Obstacles
+
+#+begin_quote
+Working section - What's preventing you from achieving the vision?
+
+*Questions to answer:*
+- What technical challenges block you?
+- What behavioral patterns get in your way?
+- What external constraints limit you?
+- What trade-offs are hardest to make?
+
+*Fill in below:*
+#+end_quote
+
+
+
+* Metrics
+
+#+begin_quote
+Working section - How will you know you're succeeding?
+
+*Questions to answer:*
+- What numbers will you track?
+- How will you measure performance?
+- How will you measure productivity?
+- What leading indicators show progress?
+
+*Fill in below:*
+#+end_quote
+
+
+
+* How to Use This V2MOM
+
+** For Decision Making
+When considering a new task, package, or feature:
+1. Does it serve the *Vision*?
+2. Does it align with the *Values*?
+3. Is it addressed in the *Methods*?
+4. Does it overcome an *Obstacle*?
+5. Does it improve a *Metric*?
+
+If the answer is "no" to all five → CANCEL the task.
+
+** For Triage
+When reviewing todo.org:
+- Tasks aligned with V2MOM → Keep and prioritize
+- Tasks not aligned with V2MOM → CANCEL
+- Tasks that are interesting but not important → CANCEL
+- Tasks with complete code already → Execute immediately
+
+** For Weekly Review
+Every Sunday (30 minutes):
+1. Review metrics - Are they improving?
+2. Review obstacles - Any new ones? Any resolved?
+3. Review active todos - Still aligned with V2MOM?
+4. Cancel stale/misaligned tasks
+5. Plan next week's focus
+
+* Completion Status
+
+- [X] Vision - Complete (kept from original todo.org)
+- [X] Values - Complete (Intuitive, Fast, Simple)
+- [ ] Methods - IN PROGRESS (have draft, need Craig's input)
+- [ ] Obstacles - TODO
+- [ ] Metrics - TODO
+
+*Last Updated:* 2025-10-30 (Session 1)
+*Next Session:* Continue with Methods section (review draft list with Craig)
+*Estimated Time to Complete:* 20-30 minutes (Methods + Obstacles + Metrics)
diff --git a/docs/values-comparison.org b/docs/values-comparison.org
new file mode 100644
index 00000000..128c6710
--- /dev/null
+++ b/docs/values-comparison.org
@@ -0,0 +1,107 @@
+#+TITLE: Values Comparison - Simple vs Reliability
+#+DATE: 2025-10-30
+
+* What Currently Supports Each Value
+
+| Theme/Practice                        | Simple | Reliability |
+|---------------------------------------+--------+-------------|
+| *Code Quality*                        |        |             |
+| Clear naming                          | ✓      |             |
+| Small functions                       | ✓      |             |
+| Good comments (why not what)          | ✓      |             |
+| Abstractions when warranted           | ✓      |             |
+|---------------------------------------+--------+-------------|
+| *Architecture*                        |        |             |
+| Modular design                        | ✓      |             |
+| Extract custom code into packages     | ✓      |             |
+| Good architecture enables evolution   | ✓      |             |
+| Technical debt has real cost          | ✓      |             |
+|---------------------------------------+--------+-------------|
+| *Production Practices*                |        |             |
+| Testing                               | ✓      | ✓           |
+| Documentation                         | ✓      |             |
+| Version control                       | ✓      |             |
+|---------------------------------------+--------+-------------|
+| *Failure Planning*                    |        |             |
+| Rollback capability (localrepo)       | ✓      | ✓           |
+| Error handling                        | ✓      | ✓           |
+| Graceful degradation                  | ✓      | ✓           |
+|---------------------------------------+--------+-------------|
+| *Trust & Stability*                   |        |             |
+| Never use tools you can't trust       | ✓      | ✓           |
+| Uptime matters                        |        | ✓           |
+| Config breakage crushes productivity  |        | ✓           |
+| More packages = more breakage risk    |        | ✓           |
+| Need confidence to refactor           |        | ✓           |
+|---------------------------------------+--------+-------------|
+
+* Key Quotes Supporting Each
+
+** Simple
+- "Config IS production software - treat it as such"
+- "Clear naming, small functions, good comments"
+- "Apply production practices: Testing, modularity, documentation"
+- "Simple means maintainable production software, not minimal or primitive"
+
+** Reliability/Resilience
+- "Never use a tool you can't fully trust"
+- "The impact when it's broken can crush my productivity"
+- "More packages = more potential breakage. Need ability to roll back"
+- "Plan for failure: Rollback capability, error handling, graceful degradation"
+- "Quality matters because uptime matters"
+
+* Analysis
+
+** If Reliability is part of Simple:
+*Simple means:* Maintainable, trustworthy, production-quality code that fails gracefully
+
+*Pros:*
+- Keeps to 3 values
+- Failure planning is a consequence of good engineering (already in Simple)
+- Less redundancy
+
+*Cons:*
+- "Simple" might not clearly convey the "must not break" urgency
+- Rollback/resilience themes could get lost
+
+** If Reliability is its own value:
+*Simple means:* Clear, maintainable code
+*Reliability means:* Never breaks, fails gracefully, always recoverable
+
+*Pros:*
+- Explicit focus on uptime/stability
+- Clear that this is mission-critical (crushes productivity when broken)
+- Resilience practices (localrepo, testing, error handling) have clear home
+
+*Cons:*
+- 4 values instead of 3
+- Some overlap with Simple
+
+* Decision Framework
+
+Ask yourself:
+
+1. When choosing between two approaches, would "reliability" change your decision differently than "simple"?
+
+   Example: Complex caching solution that's faster but harder to debug
+   - Simple says: "Too complex, harder to maintain"
+   - Reliability says: "If it breaks less often and has rollback, worth the complexity"
+
+2. Does "config can't break" deserve equal weight with Fast and Intuitive?
+
+3. Is the "trust" theme strong enough to be its own value?
+
+* Recommendation
+
+If you had to choose, I'd suggest: **Keep Simple, absorb Reliability into it.**
+
+Why? Most of your reliability practices (testing, rollback, error handling) are already listed under "production software practices" in Simple. The "never use tools you can't trust" is already there too.
+
+**But** - you could rename Simple to "**Reliable**" or "**Solid**" if the stability theme is more important than the simplicity theme.
+
+Alternative value names that might capture both:
+- *Solid* - Stable, maintainable, trustworthy
+- *Resilient* - Fails gracefully, recovers easily, maintainable
+- *Dependable* - Simple enough to trust, robust enough to rely on
+
+What resonates?