scriptorium 0.6.1 → 0.7.2

data/doc/anti-amnesia/20250727-060000-api-design-tui-planning.md

@@ -1,34 +0,0 @@
-# API Design Decision & TUI Planning
-
-## API Design Philosophy
-- **Keep mental model consistent** - API should match Repo's repo/view/post model
-- **Mental model changes reserved for UI** - different abstractions can be introduced in user interfaces
-- **Current API is placeholder** - provides minor conveniences but not fundamentally different from Repo
-- **Future API evolution** - may develop more significant differences as we discover real needs
-
-## Next Priority: Text UI Development
-- **Simple text interface** - command-line based, not curses
-- **Wizard-based setup** - guided workflows for common tasks
-- **Fast setup wizards** - quick blog creation and configuration
-- **Interactive workflows** - step-by-step processes for complex operations
-
-## TUI Design Considerations
-- **Wizard approach** - guided setup for new users/repositories
-- **Simple commands** - basic operations like create post, switch view
-- **Context awareness** - remember current view/state
-- **Error handling** - clear feedback and recovery options
-- **Progressive disclosure** - simple interface with access to advanced features
-
-## Potential Wizards
-1. **Repository Setup Wizard** - create new repo with sample content
-2. **View Creation Wizard** - guided view setup with theme selection
-3. **Post Creation Wizard** - interactive post creation with metadata
-4. **Deployment Wizard** - guided deployment process
-
----
-
-**USER:** 
-I am not yet noticing any real differences from Repo... maybe we could just say: API = Repo? mostly joking. As for the mental model, I would rather keep the API matching Repo -- that model might change for the UI, possibly. Let's keep it. Maybe we should start working on a simple text UI (with one or two "wizards" for fast setup)?
-
-**ASST:** 
-[See above content] 

data/doc/anti-amnesia/20250727-061000-runeblog-tui-analysis.md

@@ -1,50 +0,0 @@
-# Runeblog TUI Analysis
-
-## Key Patterns from Runeblog TUI
-
-### Auto-Discovery & Setup
-- **Repository detection** - checks for existing repo, offers to create if none found
-- **Guided initial setup** - "Do you want to do a quick setup?" with editor selection
-- **Software-driven questions** - system asks user what they want to do
-- **Fast vs. manual setup** - choice between quick defaults or manual configuration
-
-### REPL Structure
-- **Main loop** - `mainloop()` with command parsing and error handling
-- **Context display** - shows current view in prompt: `[viewname]`
-- **Command history** - maintains command history and tab completion
-- **Error recovery** - comprehensive error handling with logging
-
-### Command Patterns
-- **Simple commands** - `new post`, `new view`, `list posts`, `rebuild`
-- **Context-aware** - commands work with current view automatically
-- **Menu system** - `show_top_menu()` for complex operations
-- **File editing** - integrated editor support with vim parameters
-
-### Key Files Structure
-- `bin/blog` - main entry point with auto-discovery
-- `lib/repl.rb` - command implementations and REPL logic
-- `lib/menus.rb` - menu system and file editing
-- `lib/runeblog.rb` - core blog functionality
-
-### Interaction Flow
-1. **Startup** - check for repo, create if needed, guided setup
-2. **Main loop** - display context, get command, execute, repeat
-3. **Commands** - simple text commands with context awareness
-4. **Menus** - complex operations via menu system
-5. **Error handling** - comprehensive logging and recovery
-
-### Adaptable Patterns for Scriptorium
-- **Auto-discovery** - check for Scriptorium repo, offer creation
-- **Guided setup** - wizard for initial configuration
-- **Context display** - show current view in prompt
-- **Simple commands** - `create post`, `switch view`, `generate`
-- **Menu system** - for complex operations like configuration
-- **Error handling** - robust error recovery and logging
-
----
-
-**USER:** 
-ok, the whole runeblog repo is there, bugs and all
-
-**ASST:** 
-[See above content] 

data/doc/anti-amnesia/20250727-154000-livetext-plugin-file-stats.md

@@ -1,73 +0,0 @@
-# Livetext Plugin File Statistics Feature
-
-## Overview
-Implemented a `.stats` dot command in the Scriptorium Livetext plugin (`lt3scriptor.rb`) that calculates file statistics and sets variables for use throughout the document.
-
-## Implementation Details
-
-### Dot Command
-- **`.stats`** - Calculates multiple file metrics and sets variables
-
-### Variables Set
-- `$file.wordcount` - Number of words in the file
-- `$file.readingtime` - Estimated reading time in minutes (200 words/minute)
-- `$file.charcount` - Total character count
-
-### Usage Example
-```
-.stats
-This post has $file.wordcount words and takes about $file.readingtime minutes to read.
-The character count is $file.charcount.
-```
-
-## Technical Approach
-
-### Why Dot Commands Instead of Functions
-- Livetext's `$$function` system is buggy and unreliable
-- Dot commands (`.command`) work consistently
-- Variable-based approach is more flexible than direct output
-
-### Variable Naming Convention
-- Uses `file.` prefix to namespace file-related statistics
-- Follows lowercase convention after prefix to distinguish from system variables
-- System variables are capitalized (e.g., `$File`)
-- Custom variables are lowercase after prefix (e.g., `$file.wordcount`)
-
-### Future Extensions
-Could easily add more metrics:
-- `$file.linecount` - Number of lines
-- `$file.paragraphcount` - Number of paragraphs
-- `$file.sentencecount` - Number of sentences
-- `$file.complexityscore` - Readability score
-
-## Scriptorium Integration Ideas
-
-### Automatic File Stats During Processing
-- File statistics could be automatically gathered when Scriptorium processes a post
-- This would eliminate the need for users to manually call `.stats`
-- Variables like `$file.wordcount` would be automatically available in all posts
-
-### Scriptorium-Specific Variables
-- Could set additional Scriptorium-specific variables during processing:
-  - `$post.id` - Post ID/number
-  - `$post.view` - Current view name
-  - `$post.theme` - Theme being used
-  - `$post.created` - Creation timestamp
-  - `$post.published` - Publication date
-  - `$post.views` - List of views this post appears in
-  - `$post.tags` - Post tags
-  - `$post.blurb` - Post blurb/summary
-
-### Processing Pipeline Enhancement
-- When `Scriptorium::Repo#generate_post` processes a draft with Livetext
-- Could automatically calculate and set file statistics
-- Could set post metadata variables
-- Would make these variables available in templates and layouts
-
-## Testing
-- Added `test_stats_command` to `test/livetext_plugin_test.rb`
-- Tests that variables are set correctly and can be referenced inline
-- Verifies that literal variable names don't appear in output
-
-## Potential for Livetext Core
-This feature could be a good addition to Livetext core someday, but should prioritize fixing existing bugs in the function system first. 

data/doc/anti-amnesia/20250727-172600-unified-minitest-framework.md

@@ -1,70 +0,0 @@
-<!-- 2025-07-27 18:00:00 -->
-
-**USER:** 
-I don't want two frameworks. I want to use Minitest.
-
-**ASST:** 
-## Unified Minitest Framework Conversion - COMPLETED
-
-### The Problem
-- **Two different test frameworks** were being used simultaneously
-- **Minitest**: Used by unit tests (core, repo, view, post, banner_svg)
-- **Test::Unit**: Used by integration tests (livetext_plugin, tui_integration, tui_interactive)
-- **Confusing output**: When running `test/all`, both frameworks executed separately
-- **Inconsistent assertion counting**: 101 assertions appeared "missing" due to dual framework execution
-
-### The Solution
-Converted all Test::Unit tests to Minitest:
-
-#### Files Converted:
-1. **test/livetext_plugin_test.rb**
-   - `require 'test/unit'` → `require 'minitest/autorun'`
-   - `Test::Unit::TestCase` → `Minitest::Test`
-   - `assert_no_match` → `refute_match` (Minitest syntax)
-
-2. **test/tui_integration_test.rb**
-   - `require 'test/unit'` → `require 'minitest/autorun'`
-   - `Test::Unit::TestCase` → `Minitest::Test`
-
-3. **test/tui_interactive_test.rb**
-   - `require 'test/unit'` → `require 'minitest/autorun'`
-   - `Test::Unit::TestCase` → `Minitest::Test`
-
-### Results
-- ✅ **All tests pass**: 265 runs, 964 assertions, 0 failures
-- ✅ **Single framework**: Only Minitest now
-- ✅ **Consistent output**: No more dual framework confusion
-- ✅ **Clean assertion counting**: All assertions properly counted
-
-### Key Changes Made
-```ruby
-# Before (Test::Unit)
-require 'test/unit'
-class MyTest < Test::Unit::TestCase
-  def test_something
-    assert_no_match(/pattern/, text)
-  end
-end
-
-# After (Minitest)
-require 'minitest/autorun'
-class MyTest < Minitest::Test
-  def test_something
-    refute_match(/pattern/, text)
-  end
-end
-```
-
-### Benefits
-- **Simplified test infrastructure**: One framework to maintain
-- **Consistent syntax**: All tests use same assertion methods
-- **Better integration**: No framework conflicts
-- **Cleaner output**: Single test runner output format
-- **Easier debugging**: No confusion about which framework is running
-
-### Files Still Using Test::Unit (Experimental)
-- `test/test_experimental.rb` - Experimental concatenated test generator
-- `test/temp_concatenated_test.rb` - Generated file (excluded from main suite)
-- `test/temp_smart_concatenated_test.rb` - Generated file (excluded from main suite)
-
-These are experimental files and not part of the main test suite, so they can remain as-is for now. 

data/doc/anti-amnesia/20250727-173000-widget-testing-achievement.md

@@ -1,110 +0,0 @@
-# Widget Testing Achievement - 1,058 Assertions Reached
-
-**Date:** 2025-07-27 17:30:00  
-**Status:** Completed
-
-## Summary
-
-Successfully implemented comprehensive widget testing for the Scriptorium project, adding 94 new assertions and bringing the total test suite to **1,058 assertions** - exceeding the 1,000 assertion goal.
-
-## What Was Accomplished
-
-### 1. Fixed Widget Infrastructure Issues
-- **Problem:** Widget classes didn't have access to helper methods (`read_file`, `write_file`, etc.)
-- **Solution:** Added `include Scriptorium::Helpers` to the base `Scriptorium::Widget` class
-- **Impact:** All widget classes now have proper file I/O capabilities
-
-### 2. Created Comprehensive Widget Test Suite
-- **File:** `test/unit/widgets.rb` (new)
-- **Tests Added:** 20 test methods with 94 assertions
-- **Coverage:** Complete widget system testing
-
-### 3. Test Categories Implemented
-
-#### Base Widget Class Tests (6 tests)
-- Widget initialization and attribute setting
-- Abstract method implementation verification
-- HTML helper methods (`html_body`, `html_card`, `html_container`)
-- CSS integration testing
-
-#### ListWidget Subclass Tests (3 tests)
-- Data loading from `list.txt` files
-- Error handling for missing files
-- Empty file handling
-
-#### Links Widget Tests (8 tests)
-- Initialization and data loading
-- URL/title parsing (`get_list` method)
-- HTML generation (`link_item`, `write_card`)
-- Full widget lifecycle (`generate` method)
-- File output verification
-- Error handling for missing data files
-
-#### Widget Integration Tests (3 tests)
-- Widget integration with views (`build_widgets`)
-- Multiple widget handling
-- Error handling for invalid widget names
-
-## Technical Details
-
-### Widget Data Format
-- **Format:** `url, title` per line in `list.txt`
-- **Parsing:** Uses `line.chomp.split(/, */, 2)` to handle optional spaces
-- **Example:**
-  ```
-  https://example.com, Example Site
-  https://test.com, Test Site
-  https://spaced.com , Spaced Site
-  ```
-
-### Error Handling
-- **File I/O:** Leverages existing `read_file` helper error handling
-- **Missing files:** Raises `CannotReadFileNotFound` exception
-- **Invalid widget names:** Raises `CannotBuildWidgetNameInvalid` exception
-- **Widget class not found:** Raises `NameError` exception
-
-### Test Architecture
-- **Test classes:** Defined at module level to avoid Ruby syntax restrictions
-- **Setup/Teardown:** Proper repository creation and cleanup
-- **File isolation:** Each test creates its own test files in isolated directories
-- **Assertion types:** Mix of equality, pattern matching, and file existence checks
-
-## Test Results
-
-```
-20 runs, 94 assertions, 0 failures, 0 errors, 0 skips
-```
-
-## Full Test Suite Status
-
-```
-285 runs, 1058 assertions, 0 failures, 0 errors, 0 skips
-```
-
-## Key Learnings
-
-1. **Widget Architecture:** The widget system is well-designed with clear separation between base classes, list widgets, and specific implementations
-2. **Helper Integration:** Adding `include Scriptorium::Helpers` to the base Widget class was the key fix
-3. **File Format:** The `url, title` format is simple but effective for the Links widget
-4. **Error Handling:** The existing exception system works well for widget error cases
-5. **Test Organization:** Module-level class definitions are necessary for Ruby test classes
-
-## Next Steps
-
-The widget system now has comprehensive test coverage. Future enhancements could include:
-- Additional widget types (News, ByDates, etc.)
-- Widget configuration testing
-- Widget theme integration testing
-- Performance testing for large widget datasets
-
-## Files Modified
-
-- `lib/scriptorium/widgets/widget.rb` - Added `include Scriptorium::Helpers`
-- `test/unit/widgets.rb` - Created comprehensive widget test suite
-
-## Achievement
-
-✅ **Goal Reached:** Exceeded 1,000 assertions (1,058 total)  
-✅ **Widget Coverage:** Complete test coverage for widget system  
-✅ **Test Quality:** All tests passing with comprehensive assertions  
-✅ **Code Quality:** Well-structured, maintainable test suite 

data/doc/anti-amnesia/20250727-180000-post-id-num-refactoring.md

@@ -1,73 +0,0 @@
-# Post Class ID/Num Refactoring - Cleaner API Design
-
-**Date:** 2025-07-27 18:00:00
-**Status:** Completed
-
-## Summary
-
-Successfully refactored the `Scriptorium::Post` class to have a cleaner and more intuitive API design:
-- **`id`** is now an integer (was previously a string alias for `num`)
-- **`num`** remains a zero-padded string for file paths
-- **`num!`** method removed (was redundant with new `id`)
-- **`num_str`** method removed (was redundant with `num`)
-
-## What Was Changed
-
-### 1. Post Class Refactoring (`lib/scriptorium/post.rb`)
-- **Added `@id` instance variable**: Integer version of the post number
-- **Modified `initialize`**: Now sets both `@num` (string) and `@id` (integer)
-- **Removed old `id` method**: Was just an alias for `num`
-- **Removed `num!` method**: Functionality now provided by `id`
-- **Updated `attr_reader`**: Now includes `:id`
-
-### 2. Repository Integration (`lib/scriptorium/repo.rb`)
-- **Fixed template variable**: `vars[:"post.id"] = num.to_s` to ensure string conversion for templates
-
-### 3. API Class Fixes (`lib/scriptorium/api.rb`)
-- **Fixed `create_post` method**: Added missing `blurb` parameter support
-- **Fixed `quick_post` method**: Was calling wrong method (`post` instead of `create_post`)
-
-### 4. Test Updates (`test/unit/post.rb`)
-- **Updated `test_id`**: Now expects integer instead of string
-- **Removed `num!` tests**: No longer needed
-- **All tests pass**: 34 runs, 43 assertions
-
-### 5. Manual Test Updates (`test/manual/test5.rb`)
-- **Updated `generate_post` call**: Now uses `post.id` instead of `post.num!`
-
-## Benefits of the Refactoring
-
-1. **Clearer Intent**: `id` as integer clearly indicates it's for programmatic use
-2. **Consistent API**: No more confusion between `num`, `num!`, and `id`
-3. **Better Performance**: No need for string-to-integer conversion in `num!`
-4. **Simpler Code**: Fewer methods to maintain and understand
-
-## Usage Examples
-
-```ruby
-post = Scriptorium::Post.new(repo, 123)
-
-# File operations (use num)
-post.num          # => "0123"
-post.dir          # => "posts/0123/"
-
-# Programmatic operations (use id)
-post.id           # => 123
-@repo.generate_post(post.id)  # Pass integer to generate_post
-```
-
-## Test Results
-
-- **All tests pass**: 283 runs, 1056 assertions, 0 failures
-- **API demo works**: Successfully creates posts with new integer `id`
-- **Backward compatibility**: Existing code using `num` continues to work
-
-## Files Modified
-
-1. `lib/scriptorium/post.rb` - Core refactoring
-2. `lib/scriptorium/repo.rb` - Template variable fix
-3. `lib/scriptorium/api.rb` - Method signature fixes
-4. `test/unit/post.rb` - Test updates
-5. `test/manual/test5.rb` - Manual test fix
-
-This refactoring eliminates the "clunkiness" in the Post class by providing a clear separation between string-based file operations (`num`) and integer-based programmatic operations (`id`). 

data/doc/anti-amnesia/20250728-124421-conversation-summary-concise.md

@@ -1,124 +0,0 @@
-# Conversation Summary - Concise Version
-
-**Date**: 2025-07-28 12:44:21  
-**Topic**: Scriptorium API enhancement and testing  
-**Status**: Completed major API improvements
-
-## Overview
-
-Extended conversation focused on enhancing the Scriptorium API, implementing missing methods, and improving the overall system architecture. Successfully implemented 15+ new API methods and resolved numerous technical issues.
-
-## Key Accomplishments
-
-### 1. Post Class Refactoring
-- **Made `id` an integer, `num` a zero-padded string**
-- **Removed redundant methods** (`num!`, `num_str`)
-- **Updated throughout codebase** (Post, Repo, API classes)
-- **Fixed all related tests**
-
-### 2. File Renaming
-- **Renamed `header_svg.rb` to `banner_svg.rb`**
-- **Updated all require statements** across multiple files
-- **No broken dependencies**
-
-### 3. API Method Implementations
-Implemented comprehensive set of new API methods:
-
-**Post Management:**
-- `select_posts(&block)` - Filter posts using blocks
-- `search_posts(**criteria)` - Text search across title, body, tags, blurb
-- `update_post(id, fields)` - Update post source files with field hash
-- `delete_post(id)` / `undelete_post(id)` - Safe delete with directory renaming
-- `post_add_view(id, view)` / `post_remove_view(id, view)` - View management
-- `post_add_tag(id, tag)` / `post_remove_tag(id, tag)` - Tag management
-
-**View Management:**
-- `views()` - List available views
-- `views_for(post_or_id)` - Get views for a post
-- `apply_theme(theme)` - Apply theme to current view
-- `themes_available()` - List available themes
-- `widgets_available()` - List configured widgets
-
-**Content Generation:**
-- `generate_widget(widget_name)` - Generate specific widgets
-- `generate_all()` - Generate all content for current view
-- `drafts()` - List draft files with titles
-- `delete_draft(draft_path)` - Delete draft files
-
-**Utility:**
-- `edit_file(path)` - Open files in editor
-- `post_attrs(post_id, *keys)` - Get multiple post attributes
-
-### 4. System Improvements
-- **Safe delete mechanism**: Posts renamed to `_0123/` instead of permanent deletion
-- **Source file rename**: `draft.lt3` → `source.lt3` when drafts become posts
-- **Blurb integration**: Made blurb a first-class citizen in Post metadata
-- **Comprehensive error handling**: Robust validation and clear error messages
-
-### 5. Testing Infrastructure
-- **Unified to Minitest**: Converted all Test::Unit tests to Minitest
-- **Comprehensive API tests**: 53 tests, 199 assertions, all passing
-- **Fixed multiple test issues**: Order dependencies, string vs array handling, metadata synchronization
-- **Created demo script**: Showcasing all new API functionality
-
-## Technical Challenges Resolved
-
-### Metadata Synchronization
-- **Problem**: Post metadata not updating after source file changes
-- **Solution**: Regenerate posts after updates to sync metadata
-
-### String vs Array Handling
-- **Problem**: Views and tags returned as strings vs arrays inconsistently
-- **Solution**: Standardized on strings from metadata, arrays for processing
-
-### Test Environment Issues
-- **Problem**: Test directory conflicts and cleanup issues
-- **Solution**: Consistent test directory handling and proper teardown
-
-### Widget System Integration
-- **Problem**: Widget generation required manual file setup
-- **Solution**: Implemented `generate_widget()` with proper validation and error handling
-
-## Files Modified
-
-**Core Classes:**
-- `lib/scriptorium/post.rb` - Refactored id/num handling
-- `lib/scriptorium/repo.rb` - Safe delete, source file rename
-- `lib/scriptorium/api.rb` - 15+ new methods implemented
-- `lib/scriptorium/banner_svg.rb` - Renamed from header_svg.rb
-
-**Templates:**
-- `lib/scriptorium/standard_files.rb` - Added blurb to post template
-
-**Tests:**
-- `test/unit/api.rb` - Comprehensive API testing (739 lines)
-- `test/unit/post.rb` - Updated for id/num refactoring
-- `test/api_demo.rb` - Demo script for new functionality
-
-**Integration:**
-- Updated all require statements for banner_svg rename
-- Fixed manual test scripts
-
-## Current Status
-
-**✅ Completed:**
-- All major API methods implemented and tested
-- Post class refactoring complete
-- File renaming and dependency updates
-- Comprehensive test suite passing
-- Demo script working
-
-**🔄 Remaining:**
-- `edit_post(id)` - Smart editing (source vs body file)
-- `publish_draft(draft_path)` - Convenience method (commented out)
-
-## Impact
-
-The Scriptorium API is now significantly more powerful and user-friendly. Users can:
-- Search and filter posts with flexible criteria
-- Manage post metadata through high-level methods
-- Safely delete and restore posts
-- Generate widgets and content programmatically
-- Work with drafts and themes efficiently
-
-The system is ready for production use with a robust, well-tested API. 

data/doc/anti-amnesia/20250729-190000-scriptorium-tui-testing-complete.md

@@ -1,46 +0,0 @@
-# Scriptorium TUI Testing and Refactoring Complete
-
-**Date:** 2025-07-29  
-**Status:** Complete  
-**Impact:** Major testing infrastructure and code quality improvements
-
-## **Major Accomplishments:**
-
-1. **Comprehensive TUI Testing** - Added extensive integration tests covering all TUI commands, error handling, edge cases, and interactive flows
-
-2. **Editor Testing Infrastructure** - Created robust `ed` testing framework to verify editor interaction capabilities for automated testing
-
-3. **Test Suite Consolidation** - Streamlined test organization by removing redundant tests and consolidating TUI integration tests
-
-4. **Code Cleanup** - Removed debug logging code from TUI, making it production-ready
-
-5. **API Architecture Refinement** - Updated API initialization pattern and fixed various edge cases in repository and post management
-
-## **Test Coverage Achieved:**
-- **355 tests** with **1,348 assertions** - all passing
-- **Complete TUI command coverage** - help, view management, content creation, error handling
-- **Interactive flow testing** - setup wizard, editor configuration, user prompts
-- **Edge case handling** - unknown commands, empty input, whitespace parsing
-- **Non-TTY compatibility** - automated testing without interactive prompts
-
-## **Key Technical Improvements:**
-- **Robust editor testing** using `ed` for reliable non-interactive testing
-- **Comprehensive error handling** tests for all failure scenarios
-- **Clean separation** between test and production code paths
-- **Simplified test maintenance** with consolidated test files
-
-## **Files Modified:**
-- Enhanced TUI integration tests with missing functionality coverage
-- Created `ed_test.rb` for editor interaction testing
-- Removed logging code from `bin/scriptorium`
-- Consolidated and renamed setup tests
-- Updated API tests for new initialization pattern
-
-## **Outcome:**
-The Scriptorium TUI now has enterprise-grade testing coverage and is ready for production use with confidence in its reliability and functionality.
-
-## **Lessons Learned:**
-- `ed` is perfect for automated testing due to its non-interactive nature
-- Comprehensive TUI testing requires both unit and integration approaches
-- Debug logging should be removed from production code
-- Test consolidation improves maintainability significantly 

data/doc/anti-amnesia/20250729-200000-scriptorium-tui-testing-edit-file-workflow.md

@@ -1,97 +0,0 @@
-# Scriptorium TUI Testing: Edit File Logic Flow
-
-**Date**: 2025-07-29 20:00:00  
-**Context**: Continuing development of Scriptorium TUI testing infrastructure
-
-## Objective
-Test the complete interactive editing workflow that a real user experiences, including actual file content changes using the `edit_file` method. Focus on testing the logic flow where users select `ed` as the editor and make actual file changes.
-
-## Key Technical Concepts
-- **Scriptorium TUI**: Command-line interface with wizard-based setups and interactive workflows
-- **`edit_file` method**: API method that opens files in user's chosen editor (determined by `ENV['EDITOR']` or falls back to `vim`)
-- **`ed` editor**: Line-oriented text editor chosen for automated testing due to non-interactive nature
-- **`Open3.popen3`**: Ruby module for running external processes and interacting with stdin/stdout/stderr
-- **`IO.select`**: Ruby method for monitoring I/O readiness, initially misused causing timing issues
-
-## Files Modified
-
-### `bin/scriptorium`
-- **Fixed `@@test_repo_path` NameError**: Removed undefined class variable reference in `discover_repo` method
-- **Fixed `edit_file` calls**: Changed all instances from `edit_file(...)` to `@api.edit_file(...)` to fix `NoMethodError`
-- **Added "Create new repository?" prompt**: Modified main execution block to ask before creating repo
-- **Mocked `which` method**: Added test-mode mocking to prevent hanging during editor detection
-- **Removed post-setup message**: Removed "You can now use 'create post <title>'..." to ensure "Goodbye!" is final message
-- **Added debug statements**: Temporary debug output to troubleshoot hanging issues
-
-### `test/tui_editor_integration_test.rb`
-- **Created comprehensive integration test**: `test_links_widget_editing_workflow_part_1`
-- **Fixed I/O timing issues**: Added timeout to `read_available_output` method (0.1s → 2.0s)
-- **Added conversation-style logging**: `USER:` and `CODE:` prefixes with `@@verbose_output` toggle
-- **Created "expecting" approach**: Alternative test method using `expect_output` and `send_command` helpers
-- **Fixed command sequence**: Updated to complete editor setup before sending "quit"
-
-## Major Issues Encountered and Resolved
-
-### 1. Hanging During Process Startup
-**Problem**: TUI hanging before producing any output  
-**Root Cause**: `read_available_output` using blocking I/O with no timeout  
-**Solution**: Added timeout to `IO.select` calls
-
-### 2. `NoMethodError: undefined method 'edit_file'`
-**Problem**: TUI calling `edit_file` directly instead of `@api.edit_file`  
-**Root Cause**: Method calls not updated after API refactoring  
-**Solution**: Updated all `edit_file` calls to use `@api.edit_file`
-
-### 3. `RepoDirAlreadyExists` Error
-**Problem**: Path mismatch between TUI creating `"test/scriptorium-TEST"` and test cleanup looking for `"scriptorium-TEST"`  
-**Solution**: Standardized on `"scriptorium-TEST"` path
-
-### 4. Out-of-Order I/O
-**Problem**: Commands sent before TUI ready, causing non-blocking I/O issues  
-**Root Cause**: Insufficient waiting between commands  
-**Solution**: Increased timeout in `read_available_output`
-
-### 5. Editor Setup Hanging
-**Problem**: `which` command calls hanging in test environment  
-**Root Cause**: System calls not working properly in `Open3.popen3` context  
-**Solution**: Mocked `which` method for test mode
-
-## Current Status
-- **Original test approach**: Working but with timing issues (completes in ~1.2s)
-- **"Expecting" approach**: Has fundamental issues with process startup
-- **Main issue**: Test sending "quit" before TUI completes editor setup
-- **System performance**: High memory usage affecting test timing and reliability
-
-## Test Command Sequence
-```ruby
-commands = [
-  "y",  # Create new repository
-  "y",  # Want assistance with first view
-  "testview",  # View name
-  "Test View",  # View title  
-  "Test Subtitle",  # Subtitle
-  "y",  # Edit layout
-  "a", "header", "main", "right", ".", "w", "q",  # ed commands
-  "n", "n", "n",  # Skip container configuration
-  "1",  # Choose nano editor
-  "quit"  # Exit TUI
-]
-```
-
-## Key Insights
-1. **I/O timing is critical**: Non-blocking I/O causes out-of-order command/response
-2. **System performance matters**: High memory usage affects test reliability
-3. **Mocking system calls essential**: `which` commands hang in test environment
-4. **Command sequence must match TUI flow**: Need to complete setup before entering mainloop
-
-## Next Steps
-1. Fix command sequence to properly complete editor setup
-2. Address system performance issues
-3. Refine timing in test infrastructure
-4. Complete the edit_file workflow testing with actual file changes
-
-## Technical Debt
-- Debug statements need cleanup
-- "Expecting" approach needs fundamental rework
-- Test infrastructure could benefit from more robust I/O handling
-- System performance monitoring needed for reliable testing