1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
* Claude Code Session Notes
This file contains important information for Claude to remember between sessions.
** User Information
*** Calendar Location
Craig's calendar is available at: =/home/cjennings/sync/org/gcal.org=
Use this to:
- Check meeting times and schedules
- Verify when events occurred
- See what's upcoming
*** Todo List Location
Craig's todo list is at: =/home/cjennings/code/wttrin/todo.org=
*IMPORTANT*: When Craig refers to "my todo list" or "task list", he means this file.
- Use the Edit tool to update tasks in this file
- Do NOT confuse this with Claude Code's TodoWrite tool (which is for tracking Claude's internal task progress)
- This is an org-mode file with TODO/DOING/DONE states
*** Quality Engineering Guidelines
Craig's quality engineering and testing practices are documented at:
=/home/cjennings/.emacs.d/ai-prompts/quality-engineer.org=
*Key principles for wttrin testing project:*
- Follow ERT (Emacs Lisp Regression Testing) framework
- Separate interactive UI from logic (Interactive vs Non-Interactive Pattern)
- Internal functions prefixed with =--= contain pure logic
- Interactive wrappers handle user prompts
- Test the internal functions with direct parameters
- Test file organization:
- Unit tests: =test-wttrin-<methodname>.el= (one file per method)
- Integration tests: =test-integration-<area-or-workflow>.el=
- Test utilities: =testutil-<category>.el=
- Test naming: =test-<module>-<function>-<category>-<scenario>-<expected-result>=
- Categories: normal, boundary, error
- NEVER hardcode dates in tests - use dynamic timestamp generation
- DON'T MOCK WHAT YOU'RE TESTING - only mock external dependencies
- Each test must be independent and deterministic
*Current testing project:*
- Adding comprehensive ERT tests to wttrin package
- Multi-session project - track progress in session notes
- Refactor functions to be testable (separate UI from logic)
- Goal: Full test coverage for all core functionality
*Session 1 Progress (2025-11-03):*
- Created comprehensive testing plan in =docs/testing-plan.org=
- Refactored wttrin.el to separate UI from logic
- Extracted =wttrin--build-url= (pure function for URL building)
- Fixed multiple bugs in =wttrin-fetch-raw-string=:
- Removed incorrect callback parameter to url-retrieve-synchronously
- Added nil buffer check for network failures
- Strip HTTP headers before decoding
- Kill buffer after use to prevent leaks
- URL encoding now handled properly
- Fixed double concatenation bug in =wttrin--get-cached-or-fetch=
- Fixed nil handling in =wttrin-additional-url-params=
- Created test infrastructure:
- =tests/testutil-wttrin.el= with test utilities and helpers
- 4 unit test files with 33 comprehensive tests
- Test Results: *33 tests, 33 passing, 0 failures*
*Files with test coverage:*
1. =wttrin-additional-url-params= - 7 tests (normal, boundary, error cases)
2. =wttrin--make-cache-key= - 9 tests (includes Unicode, special chars)
3. =wttrin--build-url= - 10 tests (URL encoding, parameters)
4. =wttrin--cleanup-cache-if-needed= - 7 tests (cache eviction logic)
*Next session priorities:*
1. Write tests for =wttrin--get-cached-or-fetch= (cache workflow)
2. Extract parsing logic from =wttrin-query= and test it
3. Write integration tests for fetch → parse → display workflow
4. Test error handling paths
5. Consider adding tests for interactive functions (if needed)
*** Working Style
- Craig uses Emacs as primary tool
** Session Protocols / Vocabulary
*** "Add to our vocabulary"
When Craig says "let's add this to our vocabulary" or a similar phrase, you should execute this sequence:
1. Add a row at this level to the parent org heading named "Session Protocols / Vocabulary"
2. Ask Craig for any similar names he might use.
3. If he already hasn't provided this information or it isn't clear, ask him for the steps you should take when you see this phrase. Make sure the phrase under discussion is clear.
4. Write the definition in steps just like any of the other org-headers and their content in this list.
5. Then remember the instructions, because he's likely to ask you to do that vocabulary word.
*** "Let's wrap it up" / "That's a wrap" - End of Session Routine
When Craig says "let's wrap it up" or "that's a wrap", execute this sequence:
1. *Update notes*: Add anything important to remember for next session to this file (CLAUDE-NOTES.org)
- Session summary if significant work was done
- Critical reminders for tomorrow
- Any new conventions or preferences learned
2. *Git commit and push*: Commit all changes in the repository and push to remote
- Use descriptive commit message
- Ensure working tree is clean
- Confirm push succeeded
3. *Final exchange*: Brief valediction/good wishes before Craig closes laptop
- Keep it warm but concise
- Acknowledge the day's work if appropriate
- "Good night" / "Talk tomorrow" / similar
This ensures clean handoff between sessions and nothing gets lost.
** File Naming Conventions
*** Update todo.org Links When Renaming Files
Many documents in this project are linked in =todo.org= using org-mode =file:= links.
*When renaming ANY file*, always search =todo.org= for references to that file and update all links to the new filename.
Example workflow:
1. Rename file (e.g., add =TOOLARGE-= prefix)
2. Search =todo.org= for old filename
3. Update all =file:= links to new filename
This prevents broken links and maintains the integrity of the project documentation.
** File Format Preferences
*** ALWAYS Use Org-Mode Format
The user uses Emacs as their primary tool. *ALWAYS* create new documentation files in =.org= format, not =.md= (markdown).
*Rationale*:
- Org-mode files are well-supported in Emacs
- Can be easily exported to any other format (HTML, PDF, Markdown, etc.)
- Better integration with user's workflow
*Exception*: Only use .md if specifically requested or if the file is intended for GitHub/web display where markdown is expected.
|
