path: root/todo.org

#+TITLE: Emacs Config V2MOM and Tasks
#+AUTHOR: Craig Jennings
#+DATE: 2025-10-31
#+FILETAGS: :v2mom:active:

* Instructions

This inbox contains ONLY tasks that serve the V2MOM vision. Before adding any task here, ask:
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 → DON'T ADD IT.

V2MOM is located at: [[file:docs/emacs-config-v2mom.org][emacs-config-v2mom.org]]
Research/ideas that don't serve vision: [[file:docs/someday-maybe.org][someday-maybe.org]]

* Method 1: Make Using Emacs Frictionless [10/18]

** TODO [#A] Fix Google Calendar password prompts every 15 minutes

IRRITANT: gcal-sync triggers password prompts approximately every 15 minutes,
interrupting workflow and breaking focus. This defeats the purpose of having
passphrase caching configured.

**Current Setup:**
- GPG agent configured with 400-day cache (gpg-agent.conf):
  - default-cache-ttl 34560000
  - max-cache-ttl 34560000
  - allow-loopback-pinentry enabled
- Plstore caching enabled (auth-config.el:54):
  - plstore-cache-passphrase-for-symmetric-encryption t
  - plstore-encrypt-to nil (symmetric encryption)
- Auth-source cache: 24 hours (auth-config.el:31)
- Auto-sync interval: 30 minutes (org-gcal-config.el:50)

**Problem:**
Despite proper GPG agent caching, oauth2-auto.plist prompts for passphrase
every ~15 minutes during gcal-sync operations. This suggests:
1. plstore may not be using GPG agent cache properly for symmetric encryption
2. oauth2-auto token refresh might be bypassing cache
3. EPinentry mode may need explicit configuration (currently commented out)

**Goal:**
Passphrase should be entered ONCE per Emacs session, then cached until Emacs
closes. No interruptions during normal work.

**Investigation Paths:**
1. Check if oauth2-auto respects plstore passphrase caching
2. Investigate plstore symmetric encryption cache behavior with GPG agent
3. Test enabling epa-pinentry-mode 'loopback (auth-config.el:42)
4. Check oauth2-auto token refresh cycle vs password prompt timing
5. Consider oauth2-auto configuration options for token persistence
6. Review org-gcal or oauth2-auto issues for similar problems

**Files:**
- modules/auth-config.el (plstore and GPG configuration)
- modules/org-gcal-config.el (org-gcal and oauth2-auto setup)
- ~/.gnupg/gpg-agent.conf (GPG agent cache settings)
- oauth2-auto.plist (encrypted OAuth tokens - prompts every access?)

**Related:**
This violates the "Frictionless" value - interruptions every 15 minutes during
calendar sync breaks concentration and workflow momentum.

** TODO [#B] Fix org-noter (reading/annotation workflow currently "so painful")

High priority - daily pain point.

** TODO [#B] Fix mail attachment workflow (currently awkward)

Daily workflow improvement.

** TODO [#B] Toggle org-appear on/off

When org links have long paths and point is on them, they expand and make text difficult to read
(especially in org-tables). Need ability to toggle org-appear: on for editing links, off for reading.
Moved from inbox 2025-11-07.

** TODO [#B] Optimize org-agenda performance using built-in profiler

THE BOTTLENECK. Currently 30+ seconds, target < 5 seconds.
Use M-x profiler-start before Method 3 debug-profiling.el is built.

** TODO [#B] Optimize org-capture target building performance

15-20 seconds every time capturing a task (12+ times/day).
Major daily bottleneck - minutes lost waiting, plus context switching cost.

** TODO Frequently used org-mode keybindings under C-; o

Add quick access keybindings for common org commands (org-table, org-reveal, etc.) under C-; o.
Makes org-mode operations more frictionless.
Moved from inbox 2025-11-07.

** TODO [#D] Fix EMMS keybinding inconsistency with other buffers

EMMS keybindings conflict with standard buffer keybindings, causing mistypes.
Results in accidental destructive actions (clearing buffers), requires undo + context switch.
Violates Intuitive value - muscle memory should help, not hurt.

** DONE [#A] Remove network check from startup (saves 1+ seconds)
CLOSED: [2025-10-31 Fri]

✅ Deleted blocking ping check. Startup improved from 6.2s to 5.4s.
Now uses package priorities: .localrepo (200) > online repos (25).

** DONE [#A] Fix cj/goto-git-gutter-diff-hunks (missing function causing errors)
CLOSED: [2025-11-03 Sun]

✅ Implemented missing function in modules/vc-config.el
- Added `cj/goto-git-gutter-diff-hunks` function (lines 118-124)
- Uses consult-line to search for diff markers (^[+\-])
- Enables interactive jumping to any changed line via C-; v d
- Function properly documented with docstring
- No linting issues, compiles cleanly

Quick win completed - 5 minutes actual time.

** DONE [#A] Fix chime-check throw with no catch block
CLOSED: [2025-11-01 Fri]

Error: "(no-catch --cl-block-chime-check-- nil)"
Chime was throwing to a catch block that doesn't exist.
Location: chime package - chime-check() function at line 1540
Fix: Changed defun to cl-defun to provide implicit catch block for cl-return-from.

Fixed in ~/code/chime.el/chime.el:1540

Added regression test: test-integration-startup-early-return-on-validation-failure
Created Makefile with test targets (unit, integration, all, by-file, by-name)
Updated README.org with Development/Testing section

All integration tests pass (5/5) ✅

** DONE [#A] Implement cj/diff-buffer-with-file (compare buffer with saved version)
CLOSED: [2025-10-31 Fri]

Bound to C-; b D. Weekly need satisfied.

** DONE [#A] Add comprehensive test coverage for video-audio-recording module
CLOSED: [2025-11-03 Sun]

✅ Created comprehensive test suite following quality-engineer.org standards:
- 9 test files (8 unit + 1 integration)
- 83 test cases with 100% pass rate
- Test categories: Normal, Boundary, Error cases
- 6 test fixtures for reproducible testing
- Mocking strategy using cl-letf
- Integration test validates complete parse→group→friendly-names workflow
- Tests document bugs in legacy detect functions
- Critical validation: Bluetooth MAC normalization across component boundaries

✅ Refactored code for testability:
- Extracted `cj/recording--parse-pactl-output` internal parser
- Separated I/O from business logic

✅ Fixed all linting warnings (checkdoc):
- 6 spacing/grammar issues resolved
- `make lint` now passes cleanly

✅ All changes committed and pushed to all remotes (origin + github)

Commits:
- 0a69c58: test: Add comprehensive test suite for video-audio-recording module
- b086539: style: Fix checkdoc warnings in video-audio-recording.el

*** TODO [#C] Add device testing command cj/recording-test-devices
Records 3 seconds of audio.
Plays it back.
Confirms devices work before real recording.

*** TODO [#C] Add recording status display (optional via flag, default off)
Show "Recording: 00:05:23" in modeline or echo area.
Timer showing duration.
File size updating.

*** TODO [#C] Add recording presets
Screencast (video + audio, high quality).
Podcast (audio only, voice optimized).
Meeting (balanced, lower filesize).
Quick note (audio, low quality, small file).

*** TODO [#C] Build recording history buffer
*Recordings* buffer showing history.
Duration, file size, location.
Quick actions: play, delete, rename, move.

*** TODO [#C] Add post-processing hooks
Auto-compress after recording.
Move to cloud sync directory.
Generate transcript (once transcription workflow exists).

** DONE [#A] Delay in modeline lines and columns update
CLOSED: [2025-11-08 Fri]

✅ Fixed modeline position lag by replacing expensive function calls with cached values.

**Problem:**
- Line/column numbers lagged behind cursor movement
- Used `line-number-at-pos` which counts from buffer start on every update
- Performance degraded in large files

**Solution:**
- Replaced with built-in format specifiers `%l` and `%c` (modeline-config.el:81)
- These use cached values maintained by line-number-mode and column-number-mode
- Explicitly enabled line-number-mode in ui-config.el:53
- Zero performance overhead - cached values update instantly

**Result:**
- Modeline position now updates instantly with cursor movement
- No lag, even in large files
- Maintains same "L:line C:col" format

** DONE [#B] Fix go-ts-mode-map keybinding error (void-variable)
CLOSED: [2025-11-03 Sun]

Error: "Debugger entered--Lisp error: (void-variable go-ts-mode-map)"
Location: modules/prog-go.el - trying to bind keys before mode loads.

✅ Already fixed in commit 196b289 (Nov 2, 2025)
- Moved keybinding from `:bind (:map go-ts-mode-map ...)` to hook function
- Keybinding now set in `cj/go-mode-keybindings` called via `:hook`
- Function executes after mode loads, ensuring keymap exists
- Today's cleanup: Removed unused forward declarations (lines 34-35)

Fix was: Wrap keybinding in hook function instead of :bind clause.
Result: No more void-variable error, keybinding works correctly.

** DONE [#B] Fix video/audio recording module (use constantly, just broke)
CLOSED: [2025-11-03 Sun]

Main issue: No way to select audio devices when multiple are available.
Plugging in external audio interface broke recording - only captured input, not output.

✅ COMPLETED - Module now has robust device detection and selection.

*** DONE [#A] Add diagnostic command cj/recording-list-devices
CLOSED: [2025-11-03 Sun]

✅ Created `cj/recording-list-devices` command (C-; r d)
Shows ALL available PulseAudio/PipeWire sources with drivers and states.
Displays current configuration.
Helps debug why auto-detection fails.

*** DONE [#A] Add device selection UI
CLOSED: [2025-11-03 Sun]

✅ Created TWO selection workflows:
1. `cj/recording-select-devices` (C-; r s) - Full manual control
   - Select mic and system audio separately
   - Interactive completion with device states
2. `cj/recording-quick-setup-for-calls` (C-; r c) - Quick call setup
   - Smart device pairing (groups mic + monitor by hardware)
   - One selection for both mic and system audio
   - Handles Bluetooth MAC normalization

Devices cached in variables for future recordings.
Can switch devices without restarting Emacs.

*** DONE [#B] Improve error messages
CLOSED: [2025-11-03 Sun]

✅ Error messages now include:
- Guidance to run `cj/recording-select-devices`
- Clear indication when auto-detection fails
- User-friendly prompts for manual selection

*** DONE [#B] Make device detection more flexible
CLOSED: [2025-11-03 Sun]

✅ Implemented multi-level fallback system:
1. Auto-detect using pactl output parsing
2. Prompt user to select manually if auto-detect fails
3. Error with helpful guidance if user declines

✅ Smart device grouping in `cj/recording-group-devices-by-hardware`:
- Handles USB, PCI (built-in), and Bluetooth devices
- Normalizes Bluetooth MAC addresses (colons ↔ underscores)
- Assigns friendly names (e.g., "Built-in Laptop Audio", "Bluetooth Headset")
- Filters incomplete devices (must have both mic and monitor)

✅ Supports both PulseAudio and PipeWire (both use pactl).

*** TODO [#B] Validate recording startup
Check process status after starting.
Parse ffmpeg output for errors.
Show actual ffmpeg command for debugging.

** DONE [#C] Fix grammar checker performance (currently disabled)
CLOSED: [2025-11-04 Mon]

✅ **Installed and configured LanguageTool for comprehensive grammar checking**

Replaced disabled grammar checker with on-demand LanguageTool integration:
- Installed LanguageTool 6.6-2 from Arch repos (222MB)
- Created wrapper script: scripts/languagetool-flycheck (Python 3)
- Integrated with flycheck for on-demand checking via C-; ?
- Removed proselint (redundant - LanguageTool catches more)
- No performance impact: only runs when explicitly invoked
- Installation instructions added to modules/flycheck-config.el commentary

LanguageTool catches:
- Real grammar errors (subject-verb agreement, tense, etc.)
- Missing punctuation (commas, periods)
- Common mistakes (could of → could have)
- Style issues (redundant phrases, wordiness)

Workflow: Open org/text/markdown file → press C-; ? → see errors in *Flycheck errors* buffer

** DONE cj/flyspell-then-abbrev loses keybinding in scratch org-mode buffer
CLOSED: [2025-11-08 Fri]

✅ Fixed keybinding issue in org-mode buffers.

**Problem:**
1. Autoload cookies were just comments and never executed
2. Org-mode was overriding C-' with org-cycle-agenda-files

**Solution:**
- Set keybindings directly when module loads (lines 239-240)
- Explicitly override org-mode's C-' after org loads (lines 244-245)
- Both C-' and C-c f now work correctly in all buffers including org-mode

File modified: modules/flyspell-and-abbrev.el:235-251

* Method 2: Stop Problems Before They Appear [3/5]

** TODO [#B] Migrate from Company to Corfu
:PROPERTIES:
:COMPLETE_CONFIG: [[file:docs/someday-maybe.org::1611][todo.org:1611-1639]]
:END:

Complete config already exists in someday-maybe.org. Just needs to be executed.

** DONE [#C] Switch to mood-line (actually: built custom modeline)
CLOSED: [2025-11-03 Sun]

✅ **Built custom modeline (better than mood-line)**

Went beyond mood-line and created a fully custom modeline using only built-in
Emacs functionality to avoid native-compilation issues. Features:

**Architecture:**
- Named segment system using defvar-local (easy to reorder)
- Emacs 30 built-in right-alignment (mode-line-format-right-align)
- All segments marked as risky-local-variable for proper evaluation

**Interactive Features:**
- Color-coded buffer names (green=writeable, red=read-only, gold=overwrite)
- VC branch with git symbol () and state-based coloring
- Mouse click handlers: buffer name (prev/next), branch (vc-diff), mode (describe-mode)
- Help-echo tooltips on all segments
- String truncation for narrow windows (< 100 chars wide)
- Active-window-only display for branch and misc-info (less clutter)

**Layout:**
- Left: Major mode, buffer name, position (L:# C:#)
- Right: Git branch, chime notifications

**Bug Fixes:**
- Disabled async native compilation (prevented "Selecting deleted buffer" errors)
- Fixed difftastic loading (:demand → :defer)
- Abstracted buffer status colors to user-constants.el

Inspired by Prot's modeline design. See commit c0c4b17.

** DONE [#C] Remove deprecated tree-sitter package (rely on treesit-auto)
CLOSED: [2025-11-03 Sun]

✅ Removed deprecated tree-sitter package from modules/prog-general.el
- Deleted `(use-package tree-sitter)` on line 97
- Now relies solely on Emacs 29+ built-in treesit with treesit-auto
- treesit-auto continues to manage tree-sitter grammars automatically
- No functionality lost, cleaner dependency tree

** DONE [#C] Add org-appear (show emphasis markers only when point is on them)
CLOSED: [2025-11-03 Sun]

✅ Added org-appear package to modules/org-config.el
- Shows emphasis markers (* / _) only when cursor is on them
- Also shows link markup and sub/superscripts when editing
- Changed org-fontify-emphasized-text from nil to t (line 75)
- Updated comment on line 71 to reference org-appear
- Cleaner editing experience while maintaining visual clarity

** TODO [#C] Integrate prescient with Corfu (smart sorting)

Already using prescient with vertico. Extend to Corfu after migration.

* Method 3: Make *Fixing* Emacs Frictionless [1/5]

** TODO [#B] Build debug-profiling.el module

Reusable profiling infrastructure for any future performance work.

** TODO [#C] Build localrepo out (package snapshot system)

Repeatable installs and safe rollbacks.

*** TODO [#C] Document localrepo limitations (treesitter grammars not included)

.localrepo only contains packages from package.el archives.
Treesitter grammars are downloaded separately by treesit-auto on first use.
For true offline reproducibility, need to cache treesitter grammars separately.

** TODO [#C] Integrate Buttercup (behavior-driven integration tests)

Complex workflow testing capability.

** DONE [#C] Integrate difftastic (structural diffs)
CLOSED: [2025-11-03 Sun]

✅ Completed difftastic integration:
1. **Upgraded cj/diff-buffer-with-file to use ediff** (modules/custom-buffer-file.el)
   - Replaced basic unified diff with ediff-current-file
   - Now uses same ediff config (horizontal split, j/k navigation)
   - Keybinding C-; b D now launches interactive ediff

2. **Added difftastic for git diffs** (modules/vc-config.el)
   - Installed binary: difftastic 0.64.0
   - Added difftastic.el package integrated with magit
   - Keybindings in magit-diff: D for dwim, S for show
   - Provides structural, language-aware diffs for git changes

Result: Better diffs everywhere - ediff for interactive buffer comparison,
difftastic for understanding git changes.

** TODO [#C] Remove orphaned dwim-shell-security tests and unused production code

Why: 12 tests in test-dwim-shell-security.el fail because the functions they test
are inside a use-package :config block (dwim-shell-config.el:101-108) that only
loads when the dwim-shell-command package is available. During batch testing,
the package isn't loaded, so functions are never defined (void-function errors).

These are PDF password protection and ZIP encryption functions that likely have
never been used in practice - they're placeholder code from initial setup.

What to delete:
1. Test file: tests/test-dwim-shell-security.el (12 failing tests)
2. Production functions in modules/dwim-shell-config.el (lines ~302-347):
   - cj/dwim-shell-commands-pdf-password-protect (lines 302-324)
   - cj/dwim-shell-commands-pdf-password-unprotect (lines 326-347)
   - cj/dwim-shell-commands-create-encrypted-zip (search for it)
   - cj/dwim-shell-commands-remove-zip-encryption (search for it)

After deletion: Run "make test-all" to confirm 18 failures → 6 failures
(only benchmark performance tests remain, which are environment-dependent).

Aligns with: Reducing test failures from 18 to 6, cleaning up unused code.

* Method 4: Contribute to the Emacs Ecosystem [0/4]

** TODO [#C] Set up package-lint for elisp linting (chime, org-msg, wttrin)

Catch packaging issues automatically.

** TODO [#C] Set up melpazoid CI for MELPA submissions

Validates packages meet MELPA standards.

** TODO [#C] Set up elisp-check GitHub Action

Zero-config CI for Emacs packages.

** TODO [#C] Integrate undercover.el for test coverage

Measure and track test coverage over time.

* Method 5: Be Kind To Your Future Self [0/2]

** TODO [#C] Add transcription workflow
:PROPERTIES:
:COMPLETE_CONFIG: [[file:docs/someday-maybe.org::2][todo.org:2-99]]
:END:

Complete code already exists in someday-maybe.org. Need today and recurring.

** TODO [#C] Implement org-reveal presentation workflow

Create reveal.js slides from org-mode.

* Method 6: Develop Disciplined Engineering Practices [0/3]
** TODO [#A] First weekly triage by Sunday (establish habit)
SCHEDULED: <2025-11-03 Sun>

Review this inbox, cancel stale items, keep < 20 active. Track in calendar.

** TODO [#B] Track current metrics baseline

- [ ] Measure current startup time (time emacs --eval '(save-buffers-kill-emacs)')
- [ ] Count current active todos
- [ ] Set up tracking document for weekly metrics

** TODO [#C] Set up monthly research:shipped ratio tracking

Can't research next thing until current thing is implemented.

* Emacs Config Resolved
* Emacs Config Inbox

** TODO [#B] Fix tests or remove code for 12 dwim-shell-security test failures

All 12 tests in test-dwim-shell-security.el fail because the production functions
they test are inside a use-package :config block that only loads when dwim-shell-command
package is available. During batch testing, functions are never defined (void-function errors).

**Current Failures:**
1. test-dwim-archive-temp-file-cleanup-on-error-error
2. test-dwim-archive-very-long-password-boundary
3. test-dwim-create-encrypted-zip-no-password-in-command-normal
4. test-dwim-create-encrypted-zip-uses-7z-normal
5. test-dwim-multiple-temp-file-cleanup-error
6. test-dwim-pdf-password-empty-password-boundary
7. test-dwim-pdf-password-protect-creates-temp-file-normal
8. test-dwim-pdf-password-protect-no-password-in-command-normal
9. test-dwim-pdf-password-special-characters-boundary
10. test-dwim-pdf-password-temp-file-cleanup-on-error-error
11. test-dwim-pdf-password-unprotect-creates-temp-file-normal
12. test-dwim-remove-zip-encryption-uses-7z-normal

**Problem:**
These are PDF password protection and ZIP encryption functions that likely have
never been used in practice - placeholder code from initial dwim-shell setup.

**Related TODO:**
There's already a TODO for this at line 432: "Remove orphaned dwim-shell-security
tests and unused production code". This task is to execute that TODO.

**What to Delete:**
1. **Test file**: tests/test-dwim-shell-security.el (entire file, 12 tests)
2. **Production functions** in modules/dwim-shell-config.el:
   - cj/dwim-shell-commands-pdf-password-protect (lines ~302-324)
   - cj/dwim-shell-commands-pdf-password-unprotect (lines ~326-347)
   - cj/dwim-shell-commands-create-encrypted-zip (search for it)
   - cj/dwim-shell-commands-remove-zip-encryption (search for it)

**Investigation First:**
1. Search git history: Have these functions ever been called?
2. Check if any keybindings reference them
3. Confirm they're not used in any other modules
4. Document why we're removing (unused, untested in practice)

**After Deletion:**
- Run `make test` to confirm: 18 failures → 2 failures
- Only 2 benchmark tests remain (separate TODO above)
- Cleaner codebase, no orphaned tests

**Related Files:**
- tests/test-dwim-shell-security.el (DELETE)
- modules/dwim-shell-config.el (remove 4 functions)
- Test output showing void-function errors

**Related Docs:**
- Original TODO at line 432 in this file
- V2MOM Method 2: Stop Problems Before They Appear (remove unused code)
- Test run output: 18 total failures (12 dwim + 2 benchmark + 4 other checks)

**Success Criteria:**
- test-dwim-shell-security.el deleted
- 4 unused functions removed from dwim-shell-config.el
- `make test` shows 2 failures (only benchmarks remain)
- No broken functionality (functions were never used)
- Git commit documents why removal is safe

**Note:**
This is the largest source of test failures. Completing this + benchmark fix
achieves clean test suite (0 unexpected failures).

** TODO [#B] Review and fix 2 lorem-optimum benchmark tests

Two benchmark tests are failing because they take MINUTES instead of seconds.
These tests have been DISABLED with :tags '(:slow) until lorem-optimum is optimized.

**CURRENT STATE (2025-11-09):**
✓ Tests disabled with :tags '(:slow) to prevent blocking test suite
✓ Docstrings updated to explain why disabled
✓ Tests will be skipped in normal test runs

**Current Failures:**
From test run output:
1. `benchmark-learn-10k-words` - Expected < 500ms, **actually takes MINUTES** (>100x slower)
2. `benchmark-tokenize-10k-words` - Expected < 50ms, **actually takes MINUTES** (>1000x slower)

**Root Cause:**
The lorem-optimum implementation is severely underperforming. Unit tests should never
take minutes to run. This needs major performance optimization work.

**Problem:**
- Tests use absolute time thresholds (< 500ms, < 50ms)
- Thresholds were likely set on a different machine/environment
- Batch mode testing may be slower than interactive Emacs
- System load affects results (makes tests flaky)

**Investigation:**
1. Review test file: tests/test-lorem-optimum-benchmark.el
2. Check actual performance numbers on this system
3. Understand what these benchmarks are measuring:
   - Learning 10k words (building Markov chain?)
   - Tokenizing 10k words (parsing text?)
4. Determine if these are critical performance indicators or just smoke tests

**Possible Solutions:**
A. **Adjust thresholds** to realistic values for this environment
   - Run tests multiple times to get consistent baseline
   - Set threshold to 2x baseline for headroom
   - Document why these thresholds were chosen

B. **Use relative benchmarks** instead of absolute times
   - Compare against a reference implementation
   - Measure ratio instead of absolute milliseconds
   - More portable across machines

C. **Mark as optional performance tests**
   - Add :tags to exclude from normal test runs
   - Run only when explicitly testing performance
   - Don't block on CI/batch test runs

D. **Remove absolute timing assertions**
   - Keep benchmarks for manual profiling
   - Just report times without pass/fail
   - Add to a performance monitoring system instead

**Recommended Approach:**
✓ **DONE**: Option C implemented - tests marked with :tags '(:slow) to skip in normal runs
- Still TODO: Optimize lorem-optimum performance (see related task below)
- Consider Option D: Convert to reporting-only benchmarks after optimization

**Next Steps:**
1. Profile lorem-optimum to find bottlenecks (see related task at line 1542+)
2. Optimize performance to get tests under 5 seconds
3. Re-enable tests once optimized
4. Consider if absolute time thresholds make sense or switch to relative benchmarks

**Related Files:**
- tests/test-lorem-optimum-benchmark.el (tests now disabled with :tags '(:slow))
- modules/lorem-optimum.el (needs performance profiling and optimization)
- Related task: "Optimize size of liber-primus.txt for lorem-optimum" at line 1542

**Related Docs:**
- ai-prompts/quality-engineer.org (testing philosophy)
- Performance principle: No unit test should take minutes
- Test output: Was 14 total failures, now down to 12 (dwim-shell only)

**Success Criteria:**
- ✓ Tests disabled to unblock test suite (DONE 2025-11-09)
- TODO: lorem-optimum optimized to run 10k word tests in < 5 seconds
- TODO: Re-enable tests once performance acceptable
- TODO: `make test` passes without benchmark failures
- Benchmark tests clearly marked as optional/manual-only
- Test file documents performance expectations and how to run benchmarks
- No flaky tests (timing assertions work consistently)

**Note:**
These are the only non-dwim-shell failures in the test suite. Fixing these
gets us to just 12 orphaned dwim-shell tests (which have their own TODO).

** TODO [#B] Consider implementing cron download of Google Calendar to replace org-gcal

Replace problematic org-gcal OAuth workflow with simpler cron-based calendar download.
This could eliminate the password prompt issues and provide a more reliable sync solution.

**Current Problem:**
From TODO at line 22-66:
- org-gcal prompts for password every ~15 minutes
- OAuth token refresh bypasses cache
- plstore symmetric encryption cache issues
- Interrupts workflow constantly
- Makes calendar sync painful instead of seamless

**Proposed Solution:**
Instead of OAuth-based sync (org-gcal), use Google Calendar's public iCalendar URLs:
1. Download .ics file via cron (every 15-30 minutes)
2. Parse .ics file into org-mode format
3. Update org-agenda files automatically
4. No OAuth, no passwords, no interruptions

**Benefits:**
- ✓ No password prompts (public calendar URL or one-time API key)
- ✓ No OAuth token refresh issues
- ✓ Runs in background (cron), never interrupts work
- ✓ Simpler architecture (download → parse → update)
- ✓ Can work offline (reads last downloaded .ics)
- ✓ More reliable (fewer moving parts)
- ✓ No plstore symmetric encryption issues

**Drawbacks:**
- ✗ Read-only (can't create/update events from Emacs)
- ✗ Need to manually get calendar iCal URL
- ✗ Requires cron setup (one-time configuration)
- ✗ May have sync delay (up to cron interval)

**Investigation:**

1. **Get Google Calendar iCal URL:**
   - Open Google Calendar settings
   - Find "Integrate calendar" section
   - Copy secret iCal address (https://calendar.google.com/calendar/ical/...)
   - Store in auth-source (encrypted)

2. **Test iCal download:**
   ```bash
   curl -o calendar.ics "https://calendar.google.com/calendar/ical/.../basic.ics"
   ```
   - Verify it downloads
   - Check .ics format
   - Confirm events are present

3. **Research iCal parsing:**
   - Does Emacs have built-in iCal parser? (icalendar.el)
   - Check icalendar-import-file function
   - Test parsing downloaded .ics file
   - Verify it creates org entries

4. **Design cron workflow:**
   ```bash
   # Every 15 minutes
   */15 * * * * curl -s "$(cat ~/.calendar-url)" -o ~/calendars/gcal.ics
   ```
   - Downloads silently in background
   - Emacs watches file for changes (file-notify)
   - Auto-reimport when changed

**Possible Implementations:**

A. **Full replacement (recommended):**
   - Remove org-gcal entirely
   - Use cron + icalendar.el
   - Read-only calendar view in org-agenda
   - Create events directly in Google Calendar web UI

B. **Hybrid approach:**
   - Keep org-gcal for writing events
   - Use cron download for reading events
   - Disable org-gcal auto-sync (no password prompts)
   - Manually trigger org-gcal only when creating events

C. **Enhanced cron:**
   - Cron downloads .ics
   - Emacs function parses and updates org files
   - Add file-notify watcher for auto-update
   - Optional: Convert two-way with CalDAV later

**Implementation Sketch:**
```elisp
(defun cj/calendar-import-gcal ()
  "Import Google Calendar from downloaded .ics file."
  (interactive)
  (let ((ics-file "~/calendars/gcal.ics")
        (org-file "~/org/calendar.org"))
    (when (file-exists-p ics-file)
      (icalendar-import-file ics-file org-file)
      (message "Imported calendar from %s" ics-file))))

;; Auto-import when .ics file changes
(file-notify-add-watch
 "~/calendars/gcal.ics"
 '(change)
 (lambda (event) (cj/calendar-import-gcal)))
```

**Related Files:**
- modules/org-gcal-config.el (current problematic implementation)
- Emacs built-in: icalendar.el (iCal parsing)
- System: crontab -e (download schedule)
- ~/.authinfo.gpg (store calendar URL securely)

**Related Docs:**
- Current problem: TODO line 22-66 (password prompts every 15 min)
- icalendar.el manual: C-h f icalendar-import-file
- Google Calendar iCal format documentation
- V2MOM Method 1: Frictionless (no interruptions!)

**Success Criteria:**
- Calendar events appear in org-agenda
- No password prompts during work
- Updates automatically in background (cron)
- Can work offline with last sync
- Setup is one-time configuration
- Simpler than current org-gcal setup

**Testing Plan:**
1. Get iCal URL from Google Calendar
2. Test download: `curl URL -o test.ics`
3. Test import: `M-x icalendar-import-file`
4. Verify org entries created correctly
5. Set up cron job
6. Wait for auto-update
7. Confirm events in org-agenda
8. Disable org-gcal auto-sync
9. Monitor for 1 week (no password prompts?)

**Decision Point:**
This is a significant architectural change. Need to:
1. Test proof-of-concept first (manual download + import)
2. Evaluate if read-only is acceptable
3. Compare to fixing OAuth password prompts
4. Consider hybrid approach if two-way sync needed

**Note:**
Priority [#B] because this could eliminate the #1 daily irritant (password prompts
every 15 minutes). If proof-of-concept works, this is higher value than fixing
OAuth issues. Simpler architecture = fewer problems.

** TODO [#C] Verify format-buffer hands off to shfmt in shell scripts

Need to verify that the format-buffer command correctly delegates to shfmt when
formatting shell scripts. May not be configured or may use wrong formatter.

**Problem:**
- Unknown if format-buffer works in shell-script-mode
- May not be using shfmt (should use shfmt for shell scripts)
- May be using a different formatter (or no formatter)
- Need to verify configuration and test manually

**Investigation:**
1. Find format-buffer implementation:
   - Search for defun format-buffer in modules/
   - Check if it's in prog-general.el or separate module
   - Review how it selects formatters per mode
2. Check shfmt configuration:
   - Is shfmt installed? `which shfmt`
   - Is shfmt configured for shell-script-mode?
   - What are the shfmt command-line arguments?
3. Test manually:
   - Create test shell script with bad formatting
   - Run format-buffer command
   - Verify it uses shfmt (not something else)
   - Check formatted output is correct

**Expected Behavior:**
1. In shell-script-mode buffer
2. Run format-buffer (or whatever the command is)
3. Should invoke shfmt to format the buffer
4. Output should be properly formatted shell code
5. Should preserve shebang and script functionality

**Possible Issues:**

A. **shfmt not installed**
   - Check: `pacman -Q shfmt` or `which shfmt`
   - Install if missing: `sudo pacman -S shfmt`

B. **format-buffer not configured for shell**
   - May only work for elisp/python/etc.
   - Need to add shell-script-mode configuration
   - Need to specify shfmt command

C. **Wrong formatter used**
   - May be using bashfmt, beautysh, or other tool
   - Should specifically use shfmt (preferred)

D. **format-buffer doesn't exist**
   - May be using different command name
   - Check for format-all, apheleia, or custom function

**Manual Test:**
Create test file:
```bash
#!/bin/bash
# Poorly formatted script
if [ -f "test.txt" ];then
echo "found"
else
    echo "not found"
fi
for i in 1 2 3;do echo $i;done
```

Expected after shfmt:
```bash
#!/bin/bash
# Poorly formatted script
if [ -f "test.txt" ]; then
        echo "found"
else
        echo "not found"
fi
for i in 1 2 3; do
        echo $i
done
```

**Related Commands to Check:**
- format-buffer
- format-all-buffer
- apheleia-format-buffer
- Custom cj/format-buffer

**Related Files:**
- modules/prog-general.el (likely location of format-buffer)
- modules/prog-shell.el (shell-specific config)
- Check for apheleia or format-all package config

**Related Docs:**
- shfmt documentation: https://github.com/mvdan/sh
- format-all or apheleia package docs (whichever is used)
- V2MOM Method 1: Frictionless (formatting should just work)

**Success Criteria:**
- format-buffer (or equivalent) command exists
- Works in shell-script-mode buffers
- Uses shfmt as the formatter
- Produces correctly formatted shell code
- Doesn't break script functionality
- Documented what command to use and how it works

**If It Doesn't Work:**
1. Install shfmt: `sudo pacman -S shfmt`
2. Configure formatter (apheleia or format-all):
   ```elisp
   ;; Example configuration
   (add-to-list 'apheleia-formatters
                '(shfmt . ("shfmt" "-i" "2" "-ci")))
   (add-to-list 'apheleia-mode-alist
                '(shell-script-mode . shfmt))
   ```
3. Test again
4. Document in prog-shell.el

**Note:**
Priority [#C] because formatting is nice-to-have. Can format manually with shfmt
if needed. Low priority but good for maintaining code quality in shell scripts.

** TODO [#B] Write tests for cj/make-script-executable

The `cj/make-script-executable` function automatically makes shell scripts executable
when they have a shebang, but it has no test coverage. This is a critical function
that modifies file permissions and needs comprehensive testing.

**Function Location:**
modules/prog-shell.el:158-167

**Current Implementation:**
```elisp
(defun cj/make-script-executable ()
  "Make the current file executable if it has a shebang."
  (when (and buffer-file-name
             (not (file-executable-p buffer-file-name))
             (save-excursion
               (goto-char (point-min))
               (looking-at "^#!")))
    (set-file-modes buffer-file-name
                   (logior (file-modes buffer-file-name) #o111))
    (message "Made %s executable" (file-name-nondirectory buffer-file-name))))
```

**Why Testing Is Critical:**
1. **File system side effects** - modifies actual file permissions
2. **Security implications** - making files executable is a security operation
3. **Cross-platform** - file permissions work differently on different systems
4. **Hooked function** - runs automatically on after-save-hook (high frequency)
5. **Potential for bugs** - conditions must be exactly right to avoid false positives

**Test Categories:**

**Normal Cases:**
1. File with shebang `#!/bin/bash` should become executable
2. File with shebang `#!/usr/bin/env python3` should become executable
3. File already executable should not change permissions (idempotent)
4. Should work with various shebangs (sh, bash, zsh, python, ruby, perl, node)
5. Message should indicate file was made executable

**Boundary Cases:**
1. Shebang with spaces: `#! /bin/bash` (space after #!)
2. Shebang with extra content: `#!/bin/bash -e`
3. Shebang not at start of file (should NOT make executable)
4. Empty file (no shebang) - should not make executable
5. Non-script file (.txt, .md) with shebang - should still work (user intent)
6. File permissions already include execute for some users (should add for all)
7. Symlinks - should follow symlink and set permission on target
8. File name with special characters (spaces, quotes, etc.)

**Error Cases:**
1. Buffer not visiting a file (buffer-file-name nil) - should do nothing
2. Read-only file system - should handle error gracefully
3. No permission to chmod file - should handle error gracefully
4. File deleted after buffer opened but before save - should handle gracefully
5. Very large file with shebang at start - should not read entire file
6. Binary file that happens to start with #! - should still work (edge case)

**Test Structure:**
Create test file: `tests/test-prog-shell-make-script-executable.el`

Following quality-engineer.org patterns:
- One test file per method (unit test)
- Use temp files for file system operations
- Clean up in teardown
- Mock/stub file-executable-p for some tests
- Test actual file permission changes in others
- Verify message output
- Test interaction with after-save-hook

**Implementation Considerations:**
1. **Temp file creation** - Use make-temp-file for test files
2. **Permission verification** - Check actual file-modes after operation
3. **Cross-platform** - Test on Linux (primary), note Windows differences
4. **Cleanup** - Ensure temp files deleted even on test failure
5. **Isolation** - Each test creates its own temp file
6. **No side effects** - Tests don't modify real config files

**Example Test:**
```elisp
(ert-deftest test-prog-shell-make-script-executable-normal-bash-shebang ()
  "Test that file with bash shebang becomes executable.

Normal case: File with #!/bin/bash at start should get +x permission."
  (let ((test-file (make-temp-file "test-script-" nil ".sh")))
    (unwind-protect
        (progn
          ;; Write shebang to file
          (with-temp-file test-file
            (insert "#!/bin/bash\necho hello\n"))
          ;; Remove execute permission
          (set-file-modes test-file #o644)
          (should-not (file-executable-p test-file))
          ;; Open file and trigger function
          (with-current-buffer (find-file-noselect test-file)
            (cj/make-script-executable)
            (kill-buffer))
          ;; Verify file is now executable
          (should (file-executable-p test-file)))
      (delete-file test-file))))
```

**Related Files:**
- modules/prog-shell.el:158-167 (function to test)
- tests/test-prog-shell-make-script-executable.el (NEW - create this)
- ai-prompts/quality-engineer.org (testing guidance)

**Related Docs:**
- quality-engineer.org: File system testing best practices
- Recent test examples: test-custom-buffer-file-*.el (file operations)
- Emacs manual: File permissions and file-modes function

**Success Criteria:**
- Comprehensive test file covering all normal/boundary/error cases
- All tests pass on Linux
- Tests properly clean up temp files
- Tests verify actual file permission changes
- Tests verify message output
- No false positives (making non-script files executable)
- No false negatives (missing files that should be executable)
- Tests document expected behavior (serve as specification)

**Estimated Tests:**
- 6-8 normal cases (different shebangs)
- 8-10 boundary cases (edge conditions)
- 5-6 error cases (failure handling)
- Total: ~20-25 tests

**Note:**
Priority [#B] because this function runs on every save in shell-script-mode and
modifying file permissions incorrectly could cause security issues or workflow
problems. Needs testing before any refactoring or changes.

** TODO [#C] Implement or manually test difftastic magit integration

Difftastic was integrated for git diffs but needs verification that it actually works
with magit as intended. The integration may need configuration or the keybindings
may not work as expected.

**Current State:**
From DONE task at line 413-429:
- Difftastic 0.64.0 installed
- difftastic.el package added
- Integrated with magit
- Keybindings in magit-diff: D for dwim, S for show
- Provides structural, language-aware diffs for git changes

**Problem:**
- Unknown if difftastic actually displays in magit
- Haven't verified keybindings work (D, S in magit-diff)
- May need additional configuration for magit integration
- Could conflict with existing magit diff commands
- Unclear if side-by-side view works in Emacs buffer

**Investigation:**
1. Review current difftastic configuration:
   - Check modules/vc-config.el for difftastic setup
   - Verify difftastic.el package is actually loaded
   - Check if :demand or :defer affects loading
2. Test manually in magit:
   - Open magit-status on .emacs.d
   - Make a test change to any .el file
   - Navigate to diff section
   - Try keybindings: D (dwim), S (show)
   - Verify difftastic output appears
3. Compare with regular diff:
   - Does regular magit diff still work?
   - Can you toggle between regular diff and difftastic?
   - Which is better for elisp files?

**Possible Issues:**

A. **Package not loading**
   - :defer prevents loading until first use
   - No autoload cookies
   - Missing require statement

B. **Keybindings conflict**
   - D or S already bound in magit-diff
   - Need to check magit-diff-mode-map
   - May need different keys

C. **Display issues**
   - ANSI colors not rendering
   - Side-by-side too wide for window
   - Output not in readable format

D. **Integration not configured**
   - difftastic.el needs explicit magit integration setup
   - Missing hooks or advice
   - Needs transient menu configuration

**Expected Behavior:**
1. In magit-diff buffer, press D or S
2. Difftastic should show structural diff with:
   - Syntax-aware comparison
   - Language-specific formatting
   - Side-by-side or unified view
   - ANSI colors (if terminal supports)
3. Should be obviously different from regular git diff
4. Should be more readable for code changes

**Testing Checklist:**
- [ ] Verify difftastic binary works: `difft --version`
- [ ] Check difftastic.el is installed: `M-x package-list-packages`
- [ ] Review vc-config.el for difftastic setup
- [ ] Open magit-status on emacs.d
- [ ] Stage a change, view diff
- [ ] Try keybinding D in diff view
- [ ] Try keybinding S in diff view
- [ ] Verify output is difftastic (not regular diff)
- [ ] Test with different file types (.el, .org, .md)
- [ ] Check if colors render correctly

**If It Doesn't Work:**
1. **Check package installation**
   ```elisp
   (require 'difftastic)  ; Does this error?
   (difftastic-mode 1)    ; Try enabling manually
   ```
2. **Review difftastic.el documentation**
   - How should it integrate with magit?
   - What configuration is needed?
   - Are there examples?
3. **Check for errors**
   - Look in *Messages* buffer
   - Check *Warnings* buffer
   - Run with debug-on-error

**If It Works:**
Document in vc-config.el:
- Keybindings that work
- When to use difftastic vs regular diff
- Any performance considerations
- Examples of good use cases

**Related Files:**
- modules/vc-config.el (difftastic configuration)
- Binary: /usr/bin/difft (verify exists)
- Package: difftastic.el (from package archives)
- Test repo: .emacs.d (make test changes here)

**Related Docs:**
- DONE task line 413: "Integrate difftastic (structural diffs)"
- difftastic.el package documentation
- difftastic project: https://github.com/Wilfred/difftastic
- V2MOM Method 3: Make Fixing Emacs Frictionless (better diff tools)

**Success Criteria:**
- Difftastic keybindings work in magit-diff (D and/or S)
- Output clearly shows structural diff (different from regular diff)
- Works for elisp, org, and markdown files
- Performance is acceptable (not noticeably slow)
- Documented in vc-config.el how to use
- Can toggle between difftastic and regular diff

**Note:**
Priority [#C] because it's a nice-to-have improvement. Regular magit diffs work fine,
but difftastic could make code review easier with structural awareness. Low priority
since core functionality (diffing) already works without it.

** TODO [#B] Figure out a way to clear "all ERT tests" when switching projects

When switching between projects (e.g., from emacs.d to chime.el), previously loaded
ERT tests from the old project remain in memory. This causes confusion and can lead
to running tests from the wrong project.

**Problem:**
- ERT tests are globally registered in Emacs session
- Switching projects (projectile/project.el) doesn't clear old tests
- `M-x ert RET t RET` runs ALL loaded tests from ALL projects
- No built-in way to unload tests from a specific project
- Can accidentally run emacs.d tests when working on chime.el (or vice versa)

**Current Workaround:**
- Restart Emacs when switching projects (loses session state)
- Manually track which project's tests are loaded (error-prone)
- Hope you don't accidentally run wrong tests (unreliable)

**Investigation:**
1. How ERT stores tests:
   - Tests stored in global `obarray` with special properties
   - Each test is a symbol with ert-test property
   - No built-in concept of "project" or "namespace"
2. Existing solutions to check:
   - Does projectile have test isolation?
   - Any ERT extensions for project-scoped tests?
   - Can we tag tests by project?
3. Review test file loading patterns:
   - How do we currently load tests? (batch vs interactive)
   - Are tests autoloaded or explicitly loaded?
   - Can we track which files define which tests?

**Possible Solutions:**

A. **Project-aware test selector**
   - Create `cj/ert-run-project-tests` command
   - Use project-root to filter tests by file location
   - Only run tests defined in current project's test/ directory
   - Leaves other tests in memory but doesn't run them

B. **Clear tests on project switch**
   - Hook into project-switch-commands or projectile-after-switch-project-hook
   - Undefine all ERT tests before switching
   - Reload only new project's tests
   - Clean slate for each project

C. **Tag-based test filtering**
   - Add :tags '(project-name) to all tests
   - Filter by tag when running tests
   - Requires modifying all test definitions
   - More maintainable across projects

D. **Separate test namespaces**
   - Use different prefixes per project (cj/ vs chime-)
   - Run tests by prefix pattern
   - Already partially done (good!)
   - Could be enhanced with smarter filtering

E. **Project-local test runner**
   - Create wrapper around `ert` command
   - Automatically detects project root
   - Clears tests not in current project
   - Provides project-scoped test results

**Preferred Approach:**
Combination of B + D:
1. Create `cj/ert-clear-tests` function to undefine all tests
2. Hook into project switching to auto-clear
3. Use test name prefixes to selectively clear/run
4. Add `cj/ert-run-current-project-tests` command

**Implementation Sketch:**
```elisp
(defun cj/ert-clear-tests (&optional prefix)
  "Clear all ERT tests, optionally matching PREFIX."
  (interactive)
  (let ((count 0))
    (mapatoms
     (lambda (sym)
       (when (and (ert-test-boundp sym)
                  (or (null prefix)
                      (string-prefix-p prefix (symbol-name sym))))
         (setf (get sym 'ert--test) nil)
         (cl-incf count)))
     obarray)
    (message "Cleared %d ERT tests" count)))

(defun cj/ert-run-current-project-tests ()
  "Clear all tests and run only current project's tests."
  (interactive)
  (cj/ert-clear-tests)
  ;; Load current project's test files
  ;; Run tests with appropriate selector
  ...)
```

**Related Files:**
- Emacs built-in: ert.el (study test storage mechanism)
- modules/test-runner.el (if it exists - check current test infrastructure)
- init.el or project config (where to add hooks)
- .dir-locals.el (project-specific test configuration?)

**Related Docs:**
- ERT manual: Test selectors and running tests
- Projectile/project.el documentation on hooks
- Current test workflow: Makefile test targets
- V2MOM Method 3: Make Fixing Emacs Frictionless (better test workflow)

**Success Criteria:**
- Can switch from emacs.d project to chime.el project
- Old tests are cleared (don't show up in completion)
- Only current project's tests run with `M-x ert RET t RET`
- Clear feedback about which tests were cleared/loaded
- Works with both interactive and batch test runs
- Integrated with existing test infrastructure (Makefile)

**Testing:**
1. Load emacs.d tests (make test or load test files)
2. Verify emacs.d tests are registered (M-x ert shows them)
3. Switch to chime.el project
4. Verify emacs.d tests cleared, chime tests loaded
5. Run tests - only chime tests execute
6. Switch back - only emacs.d tests execute

**Note:**
This is a workflow pain point when maintaining multiple Emacs Lisp projects.
Priority [#B] because it affects daily development across projects and can cause
subtle bugs (running wrong tests, confusion about failures).

** TODO [#B] Fix broken transcription-config not working for Jabra - no audience recorded

Transcription workflow is failing when using Jabra headset. The recording captures
no audio (silent/empty file) or doesn't detect the Jabra device properly.

see: /home/cjennings/sync/recordings/2025-11-09-12-42-02.txt

Question: can we run validation that audio will be heard from both user and audience as a separate diagnostics test? 

**Problem:**
- Transcription records from wrong audio device (not Jabra headset)
- Results in silent recording with no audience audio to transcribe
- May be related to same device selection issues fixed in video-audio-recording
- Transcription likely hardcodes device selection or uses outdated detection

**Investigation:**
1. Review modules/transcription-config.el
   - Check how audio device is selected
   - Look for hardcoded device names/indices
   - Compare to working video-audio-recording device detection
2. Test current transcription workflow:
   - What command initiates transcription?
   - Does it prompt for device selection?
   - What error messages (if any)?
3. Check if related to recent Jabra device changes:
   - External audio interface addition
   - Multiple audio devices now available
   - Need dynamic device selection like recording module

**Likely Causes:**
- Hardcoded audio device (e.g., always uses default or device index 0)
- No device selection UI (unlike video-audio-recording which has C-; r s)
- ffmpeg command uses wrong input source
- PulseAudio/PipeWire device name changed when Jabra was added
- Missing device auto-detection or manual override

**Related Working Code:**
Look at video-audio-recording.el for patterns:
- `cj/recording-list-devices` (diagnostic command)
- `cj/recording-select-devices` (manual device selection)
- `cj/recording-quick-setup-for-calls` (smart device pairing)
- Device detection via pactl parsing
- Cached device selection in variables

**Possible Solutions:**
A. **Add device selection to transcription workflow**
   - Prompt for audio device before recording
   - Cache selection for session
   - Similar to recording module's approach

B. **Reuse recording module's device detection**
   - Share device selection code between modules
   - Extract common device detection to system-lib or audio-lib
   - Single source of truth for audio devices

C. **Make transcription workflow interactive**
   - Show available devices
   - Let user confirm before recording
   - Display actual ffmpeg command for debugging

**Related Files:**
- modules/transcription-config.el (broken transcription)
- modules/video-audio-recording.el (working device selection)
- Test with Jabra headset connected

**Related Docs:**
- Recent fix: video-audio-recording device selection (DONE task)
- V2MOM Method 5: Be Kind To Your Future Self (transcription workflow)
- SOMEDAY-MAYBE.org likely has transcription config notes

**Success Criteria:**
- Transcription records audio from Jabra headset successfully
- User can select audio device (or auto-detection works)
- Clear error messages if device selection fails
- Recording contains actual audio (not silent)
- Transcription produces text from recorded audio

**Testing:**
1. Connect Jabra headset
2. Run transcription command
3. Speak into Jabra microphone
4. Verify recording captures Jabra audio
5. Verify transcription produces text

**Note:**
This blocks the transcription workflow entirely with Jabra. High priority [#B]
because transcription is a stated goal (Method 5) but currently unusable.

** TODO [#C] Identify any current methods in need of refactoring

Review all modules to identify functions that violate single-responsibility principle,
have poor separation of concerns, or could benefit from refactoring for testability
and maintainability.

**Goal:**
Create a comprehensive list of refactoring opportunities across the entire config.
This supports V2MOM Method 2 (Stop Problems Before They Appear) by identifying
code quality issues before they cause bugs.

**Criteria for Refactoring Candidates:**
1. **Long functions** (>50 lines) that do multiple things
2. **Mixed concerns** (UI + business logic, I/O + computation)
3. **Hard to test** (requires extensive mocking, side effects everywhere)
4. **Duplicated logic** (same pattern in multiple places)
5. **Poor naming** (unclear what function does)
6. **Hidden dependencies** (relies on global state, implicit context)
7. **Interactive functions with business logic** (should split into internal + wrapper)
8. **Functions that can't be called programmatically** (too much user interaction)

**Review Process:**
1. **Scan all modules** in alphabetical order
   - For each module, list functions that meet refactoring criteria
   - Note specific issues (too long, mixed concerns, etc.)
   - Estimate refactoring complexity (trivial, moderate, complex)

2. **Check recent refactoring patterns** for examples:
   - modules/custom-buffer-file.el (internal + interactive wrapper pattern)
   - modules/video-audio-recording.el (extracted parser for testing)
   - modules/system-lib.el (consolidated utilities)

3. **Document findings** in a refactoring checklist:
   - Module name
   - Function name
   - Current issues
   - Proposed refactoring
   - Benefits (testability, reusability, clarity)
   - Dependencies (what else needs to change)

4. **Prioritize refactorings:**
   - High: Functions used frequently or causing bugs
   - Medium: Functions that are hard to test or understand
   - Low: Functions that work but could be cleaner

**Areas Likely to Need Refactoring:**
- Old modules not touched in recent quality pass
- Modules with no tests (indicates possible design issues)
- Modules with many interactive functions (may hide testable logic)
- Configuration modules with complex setup logic
- Modules that grew organically (org-config, mail-config, etc.)

**Output:**
Create a refactoring.org file or section listing:
```
*** Module: custom-example.el
**** REFACTOR cj/example-function [Priority: High]
Issues:
- 80 lines long (should be < 50)
- Mixes UI prompting with business logic
- Hard to test (requires user input)

Proposed Solution:
- Extract cj/--example-internal (takes params, returns result)
- Keep cj/example-function as thin interactive wrapper
- Add tests for cj/--example-internal

Benefits:
- Testable without mocking user input
- Reusable from other code
- Clearer separation of concerns

Estimated Effort: 2 hours
```

**Related Files:**
- All modules/* files (review candidates)
- ai-prompts/quality-engineer.org (refactoring guidance)
- Recent refactoring examples for patterns

**Related Docs:**
- quality-engineer.org section on "Interactive vs Non-Interactive Function Pattern"
- Recent refactoring work (custom-buffer-file, video-audio-recording)
- V2MOM Method 2: Stop Problems Before They Appear

**Success Criteria:**
- Comprehensive list of refactoring candidates across all modules
- Each candidate has clear issue description and proposed solution
- Prioritized by impact and effort
- Can be tackled incrementally (smallest to largest)
- Becomes backlog for future refactoring sprints

**Note:**
This is a one-time audit to identify technical debt. Once complete, it feeds
future [#B] and [#C] refactoring tasks. Not meant to do all refactoring at once,
just catalog opportunities.

** TODO [#B] Review all config and pull library functions into system-lib file

Extract reusable utility functions scattered across modules into system-lib.el
for better code organization and reusability.

**Goal:**
Create a centralized system utilities library where generic functions that check
system state, detect programs, or provide low-level system operations can live.
This makes them:
- Easily discoverable
- Reusable across modules
- Testable in isolation
- Following single-responsibility principle

**Current State:**
- system-lib.el exists with `cj/executable-exists-p` function
- Already required at top of init.el (System Configuration section)
- Has comprehensive test coverage (test-system-lib-executable-exists-p.el)

**Task:**
1. Search entire config for candidate functions:
   - System queries (program detection, path checking, environment vars)
   - File system utilities (beyond buffer-file operations)
   - Process utilities
   - Platform detection helpers
2. Review each module for extraction candidates:
   - host-environment.el (already has some, may have more)
   - system-utils.el (may contain generic utilities)
   - Any module with functions that don't depend on mode-specific context
3. Move appropriate functions to system-lib.el:
   - Update function documentation
   - Add require statements where functions are used
   - Maintain backward compatibility (old locations can call new ones)
4. Add comprehensive test coverage for all moved functions
5. Document the purpose/scope of system-lib.el in its Commentary section

**Criteria for inclusion in system-lib.el:**
- ✓ Pure utility functions (no side effects)
- ✓ System-level queries (executable detection, path operations)
- ✓ Platform-agnostic where possible
- ✓ No dependencies on mode-specific functionality
- ✗ NOT buffer/file operations (those stay in custom-buffer-file.el)
- ✗ NOT user-facing commands (those stay in their domain modules)

**Related Files:**
- modules/system-lib.el (target file)
- modules/host-environment.el (likely source)
- modules/system-utils.el (likely source)
- modules/config-utilities.el (check for candidates)
- tests/test-system-lib-*.el (add tests for moved functions)

**Related Docs:**
- Recent refactoring: Created system-lib.el with cj/executable-exists-p
- Testing guidance: ai-prompts/quality-engineer.org
- V2MOM Method 2: Stop Problems Before They Appear (better organization)

**Success Criteria:**
- All generic system utilities consolidated in system-lib.el
- Each function has comprehensive test coverage
- No functionality broken (all tests pass)
- Documentation explains purpose and scope of system-lib.el
- Other modules properly require system-lib where needed

** TODO [#B] Optimize size of liber-primus.txt for lorem-optimum and investigate launch notices

The liber-primus.txt file may be too large for optimal lorem-optimum performance,
causing slow random text generation or excessive memory usage. Additionally, there
are notices appearing in the *Messages* buffer during Emacs launch that need investigation.

**Primary Problem:**
- liber-primus.txt might be too large for efficient text generation
- lorem-optimum may be slow when selecting random text from large corpus
- File size could be causing memory or performance issues
- Impact on startup time or buffer creation unknown

**Secondary Problem:**
- *Messages* buffer shows notices during Emacs launch
- May be related to lorem-optimum, liber-primus, or unrelated issues
- Need to identify source and severity of notices

**Investigation:**

1. **Check current file size:**
   ```bash
   ls -lh liber-primus.txt
   wc -l liber-primus.txt
   wc -w liber-primus.txt
   ```

2. **Review lorem-optimum configuration:**
   - Find lorem-optimum module: `grep -r "lorem-optimum" modules/`
   - Check how liber-primus.txt is loaded
   - Look for performance issues in implementation
   - Check if entire file is loaded into memory

3. **Test performance with current file:**
   ```elisp
   (benchmark-run 100
     (lorem-ipsum-insert-paragraphs 1))
   ```
   - Measure baseline performance
   - Note memory usage

4. **Investigate Messages buffer notices:**
   - Launch Emacs with `emacs --debug-init`
   - Check *Messages* buffer immediately after startup
   - Search for lorem, liber-primus, or warning keywords
   - Note timestamps and context

5. **Identify notices source:**
   - Could be from lorem-optimum loading
   - Could be file permissions warnings
   - Could be encoding issues
   - Could be unrelated initialization messages

**Possible Solutions:**

1. **Reduce file size** (if too large):
   - Keep most meaningful/interesting sections
   - Remove repetitive content
   - Target size: 50-100KB (fast loading, sufficient variety)
   - Preserve character of cryptic/cipher text

2. **Optimize lorem-optimum loading** (if implementation issue):
   - Lazy load: don't read file until first use
   - Sample lines: don't load entire file
   - Cache in memory: read once, reuse
   - Stream reading: read chunks as needed

3. **Fix launch notices** (if errors/warnings):
   - Fix source of warnings
   - Silence benign notices
   - Add proper error handling
   - Document expected behavior

**Testing:**
1. Note baseline: file size, performance, messages
2. Apply optimization (file size or code)
3. Measure improvement:
   - File size reduced?
   - Performance improved?
   - Messages cleaned up?
4. Verify text generation still works
5. Check variety/quality of generated text

**Related Files:**
- liber-primus.txt (the text corpus file)
- modules/lorem-optimum.el or similar (lorem generation module)
- init.el (loading sequence, Messages source)
- tests/test-lorem-optimum-*.el (performance/benchmark tests)

**Related Docs:**
- DONE task at line 68-96: "Review lorem-optimum benchmark tests and fix"
- Failed benchmark tests may be related to this issue
- V2MOM Method 1: Frictionless (fast text generation)
- V2MOM Method 2: Stop Problems Before They Appear (clean Messages)

**Success Criteria:**
- liber-primus.txt optimized to reasonable size (<100KB ideal)
- lorem-optimum generates text quickly (<100ms for paragraph)
- No unnecessary notices in *Messages* during launch
- Text generation still produces varied, interesting output
- Benchmark tests pass (after fixing per separate TODO)
- Documented optimal file size and loading strategy

**Benchmark Target:**
- Text generation: <100ms for 1 paragraph
- File loading: <50ms at startup (if not lazy loaded)
- Memory usage: Reasonable for file size
- No degradation from current working state

**Note:**
Priority [#B] because performance impacts daily workflow (lorem text generation
used frequently for testing) and clean *Messages* buffer is important for catching
real issues during startup. This ties into fixing the 2 failed benchmark tests
(separate TODO at line 68-96).

** TODO [#B] Move cj/log-silently to system-lib

The `cj/log-silently` function is a generic utility for logging messages without
displaying them in the echo area. It should be moved to system-lib.el for better
organization and reusability across modules.

**Current Problem:**
- cj/log-silently is likely defined in a specific module
- It's a generic logging utility that could be used by any module
- Not easily discoverable for reuse
- Doesn't follow the system-lib pattern we're establishing

**What is cj/log-silently?**
This function logs messages to the *Messages* buffer without interrupting the user
by displaying them in the echo area (minibuffer). Useful for debugging and tracing
code execution without breaking user flow.

**Task:**
1. **Find current location:**
   ```bash
   grep -rn "defun cj/log-silently" modules/
   ```

2. **Review implementation:**
   - Check if it has dependencies on mode-specific functionality
   - Verify it's truly generic (should be)
   - Check for any callers that need updating

3. **Move to system-lib.el:**
   - Cut from current location
   - Paste into system-lib.el
   - Add appropriate commentary/docstring
   - Ensure proper section organization

4. **Update callers:**
   - Find all uses: `grep -rn "cj/log-silently" modules/`
   - Add `(require 'system-lib)` to any module that uses it
   - Verify no circular dependencies

5. **Write tests:**
   Create `tests/test-system-lib-log-silently.el` with coverage for:
   - Normal cases: logging simple messages
   - Boundary cases: empty strings, very long messages, special characters
   - Error cases: nil input, non-string input
   - Verify output: check *Messages* buffer contains logged text
   - Verify silence: ensure nothing appears in echo area

**Expected Signature:**
```elisp
(defun cj/log-silently (format-string &rest args)
  "Log a message to *Messages* buffer without displaying in echo area.
FORMAT-STRING and ARGS work like `message' but output is not shown to user."
  (let ((inhibit-message t))
    (apply #'message format-string args)))
```

**Related Files:**
- modules/system-lib.el (destination)
- Current module where cj/log-silently lives (TBD - find it)
- All modules that call cj/log-silently (update requires)
- tests/test-system-lib-log-silently.el (NEW - create this)

**Related Docs:**
- System-lib refactoring initiative (previous TODO)
- quality-engineer.org (testing guidance)
- Recent refactoring: moved cj/executable-exists-p to system-lib
- V2MOM Method 2: Stop Problems Before They Appear (better organization)

**Success Criteria:**
- cj/log-silently moved to system-lib.el
- All callers updated with proper requires
- Comprehensive test coverage (normal/boundary/error cases)
- All existing tests still pass (no regressions)
- Function works identically to before
- Well-documented in system-lib.el

**Testing:**
1. Run all tests before move (baseline)
2. Move function and update requires
3. Run all tests after move (verify no breakage)
4. Run new cj/log-silently tests (verify behavior)
5. Test in real usage (logging works, messages not shown)

**Note:**
Priority [#B] because this is part of the larger system-lib consolidation effort
(separate TODO). Logging utilities are commonly used, so centralizing them improves
discoverability and encourages consistent logging patterns across the codebase.

** TODO [#B] Select one method for dirvish to open files with default MIME handler detached from Emacs

Consolidate duplicate file-opening methods into a single, working implementation that
dirvish can use to open files with their default system MIME handler, detached from
the Emacs process so closing Emacs doesn't kill the opened application.

**Problem:**
- Multiple duplicate methods exist for opening files externally
- Unclear which method actually works correctly
- Likely scattered across dired-config.el, dirvish-config.el, or file utilities
- Need one canonical implementation that:
  - Opens file with system default application (xdg-open on Linux)
  - Detaches from Emacs process (doesn't block, doesn't die with Emacs)
  - Can be called by dirvish keybindings
  - Works reliably across file types

**Investigation:**

1. **Find all duplicate methods:**
   ```bash
   grep -rn "xdg-open\|open-externally\|system-open\|mime-open" modules/
   grep -rn "start-process.*xdg-open" modules/
   grep -rn "defun.*open.*external" modules/
   ```

2. **Check dirvish configuration:**
   - Review modules/dirvish-config.el
   - Look for keybindings that open files externally
   - Check what function is currently bound (if any)
   - Note any custom file-opening logic

3. **Check dired configuration:**
   - Review modules/dired-config.el
   - Look for external open functions
   - May have duplicate or conflicting implementations

4. **Test each method found:**
   - Does it open the file?
   - Does it detach properly (start-process vs call-process)?
   - Does it work with all file types?
   - Does closing Emacs kill the opened app?

**Requirements for Chosen Method:**

```elisp
(defun cj/open-file-externally (file)
  "Open FILE with system default application, detached from Emacs.
FILE is opened using xdg-open (or equivalent) in a detached process
that survives Emacs session ending."
  (interactive "fFile to open: ")
  (start-process "xdg-open" nil "xdg-open" (expand-file-name file)))
```

Key characteristics:
- Uses `start-process` (not `call-process`) for true detachment
- First arg: process name (not important, can be "xdg-open")
- Second arg: nil (no buffer, fully detached)
- Third+ args: command and file path
- Should expand file path to absolute path
- Should work from dirvish context

**Integration with Dirvish:**

```elisp
;; In dirvish-config.el
(define-key dirvish-mode-map (kbd "C-c o") #'cj/open-file-externally)
;; or similar keybinding
```

**Cleanup Tasks:**
1. Identify the one best working method (or write it)
2. Remove all duplicate implementations
3. Update dirvish-config.el to use the chosen method
4. Remove old keybindings to deleted methods
5. Test with various file types (PDF, image, video, etc.)
6. Document the keybinding in dirvish-config.el

**Testing:**

Test with different file types:
- [ ] PDF file (should open in PDF viewer)
- [ ] Image (should open in image viewer)
- [ ] Video (should open in video player)
- [ ] Text file (should open in text editor or ask)
- [ ] Directory (should open in file manager or error gracefully)

Test process detachment:
- [ ] Open a file externally
- [ ] Verify application opens
- [ ] Close Emacs (C-x C-c)
- [ ] Verify opened application still running
- [ ] Verify no zombie processes

**Related Files:**
- modules/dirvish-config.el (primary integration point)
- modules/dired-config.el (may have duplicates)
- modules/file-operations.el (if exists - may have duplicates)
- Any custom file utility modules

**Related Docs:**
- Emacs manual: start-process vs call-process (detachment)
- xdg-open documentation (Linux MIME handler)
- dirvish keybinding documentation
- V2MOM Method 1: Frictionless (seamless file opening)

**Success Criteria:**
- Single canonical function for external file opening
- All duplicates removed
- Integrated with dirvish keybinding
- Opens files with correct default application
- Process properly detached (survives Emacs exit)
- Works across all common file types
- Documented in dirvish-config.el

**Possible Locations of Duplicates:**
- dired-config.el: May have old dired external open
- dirvish-config.el: May have incomplete implementation
- custom-buffer-file.el: Unlikely but check
- system-lib.el: Could belong here if generic enough
- init.el: May have old ad-hoc implementation

**Decision: Where Should Final Function Live?**
- If dirvish-specific: keep in dirvish-config.el
- If also used by dired: put in dired-config.el, require from dirvish
- If generic file utility: put in system-lib.el or new file-lib.el
- Recommend: system-lib.el (generic system interaction)

**Note:**
Priority [#B] because duplicate code creates maintenance burden and having a
reliable external file opener improves workflow. This is a common operation
(opening PDFs, images, etc. from dirvish) that should just work without thinking.

** TODO [#B] Remove ANSI color codes from Makefile test output

The Makefile uses ANSI escape codes for colorization, but they clutter the output
and make it harder to read in CI/batch mode. Replace with simple text markers.

**Problem:**
- Makefile uses variables like `COLOR_GREEN`, `COLOR_RED`, `COLOR_BLUE`
- These insert ANSI escape codes like `\033[0;32m` into output
- Makes output harder to read, especially in logs or when piped
- Color codes don't work well in all terminals
- Unnecessary complexity

**Proposed Solution:**
Replace color codes with simple text markers:
- `✓` (checkmark) for success - KEEP THIS
- `✗` (x mark) for failure - KEEP THIS
- `[i]` for informational messages
- Remove color entirely, rely on symbols alone

**Examples:**
Current:
```
\033[0;32m✓ All unit tests passed\033[0m
\033[0;31m✗ 18 unit test file(s) failed\033[0m
\033[0;34mRunning unit tests...\033[0m
```

Proposed:
```
✓ All unit tests passed
✗ 18 unit test file(s) failed
[i] Running unit tests...
```

**Implementation:**
1. Find all `COLOR_*` variables in Makefile
2. Replace colored text with plain text + symbols
3. Remove color variable definitions
4. Test that output is still clear and readable

**Related Files:**
- Makefile (all COLOR_ variables and usage)

**Success Criteria:**
- No ANSI escape codes in Makefile
- Output still clear and readable
- Uses text symbols (✓, ✗, [i]) appropriately
- Simpler, cleaner Makefile
- Test output works in any terminal/CI environment

**Note:**
Priority [#B] because it improves readability and maintainability. Not urgent,
but makes the codebase cleaner and more portable.