Commit 2d701d3

@@ -0,0 +1,34 @@
+# ADR-0001: Consolidate Local Inference Stories
+
+**Date:** 2026-01-29
+**Status:** Accepted
+
+## Context
+
+We have five related user stories (001-005) covering local inference capability:
+
+| Story | Title | Dependencies |
+|-------|-------|--------------|
+| 001 | Local inference spike | None |
+| 002 | Hardware detection | 001 |
+| 003 | Model download | 001, 002 |
+| 004 | Local inference provider | 001, 003 |
+| 005 | Default provider selection | 004 |
+
+Stories 002-005 have strict dependencies and only deliver value together. The spike (001) produces a different deliverable (research document + decision) than the implementation stories.
+
+## Decision
+
+Keep story 001 (spike) separate. Consolidate stories 002-005 into a single implementation story.
+
+## Consequences
+
+**Positive:**
+- Clearer deliverable: one story = one working feature
+- Spike/implementation separation follows established pattern
+- Reduces backlog overhead from 5 stories to 2
+- Easier to understand the end-to-end goal
+
+**Negative:**
+- Larger implementation story may be harder to estimate
+- Less granular progress tracking during development

@@ -0,0 +1,50 @@
+# ADR-0002: Editor Integration via Reline
+
+**Date:** 2026-01-29
+**Status:** Accepted
+
+## Context
+
+Users want the ability to open their `$EDITOR` from the prompt to compose
+long or complex messages. The proposed approach was to implement `CTRL+x CTRL+e`
+keybinding (matching Bash/Zsh behavior).
+
+Research into Ruby's Reline library revealed that this functionality already
+exists for vi mode users.
+
+## Decision
+
+Do not implement custom editor integration. Document the existing Reline
+vi mode functionality instead.
+
+**How it works today (vi mode):**
+1. Configure vi mode in `~/.inputrc`: `set editing-mode vi`
+2. At the elelem prompt, press `ESC` to enter command mode
+3. Press `v` to open `$EDITOR` with current input
+4. Edit, save, quit
+5. Text returns to prompt
+
+Reline's `vi_histedit` function handles:
+- Creating temp file with current input
+- Opening `$EDITOR`
+- Reading result back into the prompt
+- Cleanup
+
+## Consequences
+
+**Positive:**
+- Zero application code required
+- Leverages existing, well-tested functionality
+- Consistent with standard vi behavior
+- Works out of the box for vi mode users
+- Respects user's `~/.inputrc` configuration
+
+**Negative:**
+- Emacs mode users don't get `CTRL+x CTRL+e` (no built-in equivalent)
+- Requires users to know vi mode is available
+- Documentation is the only deliverable
+
+## References
+
+- Reline source: `line_editor.rb` - `vi_histedit` method
+- inputrc location priority: `$INPUTRC` → `~/.inputrc` → `$XDG_CONFIG_HOME/readline/inputrc`

@@ -0,0 +1,93 @@
+# ELELEM-MODE-BUILD(7)
+
+## NAME
+
+elelem-mode-build - implementation with TDD
+
+## SYNOPSIS
+
+```
+/mode build
+```
+
+## DESCRIPTION
+
+Build mode is the primary implementation mode. The agent works through tasks
+from a story using test-driven development: write a failing test, implement
+minimal code to pass, then refactor.
+
+## ROLE
+
+- Work through Tasks in the specified story
+- Check off completed tasks
+- Follow TDD: write failing test, implement, refactor
+
+## TOOLS
+
+All tools are available:
+
+| Tool | Purpose |
+|------|---------|
+| read(path) | Read file contents |
+| write(path, content) | Create or overwrite file |
+| edit(path, old, new) | Replace text in file |
+| execute(command) | Run shell command |
+| eval(ruby) | Execute Ruby code |
+| task(prompt) | Delegate to sub-agent |
+| verify(path) | Check syntax and run tests |
+
+## PROCESS
+
+1. **Focus** - Ask which story to work on if not specified
+2. **Read** - Load the story from .elelem/backlog/
+3. **Test** - Write failing test first
+4. **Implement** - Minimal code to pass
+5. **Verify** - Run tests
+6. **Check** - Mark task complete in story file
+
+## EDITING TECHNIQUES
+
+Multi-line changes:
+
+```
+echo "DIFF" | patch -p1
+```
+
+Single-line changes:
+
+```
+sed -i'' 's/old/new/' file
+```
+
+New files: use the write tool
+
+## SEARCH COMMANDS
+
+```
+rg -n "pattern" .           # text search
+fd -e rb .                  # file discovery
+sg -p 'def $NAME' -l ruby   # structural search
+```
+
+## TASK COMPLETION
+
+When a task is done, edit the story file:
+
+```markdown
+# Tasks
+
+* [x] Create FooService in lib/foo_service.rb  <- mark done
+* [ ] Add #bar method to handle X              <- next task
+```
+
+## GUIDELINES
+
+- Work on what the user asks for
+- One task at a time
+- Minimal diffs
+- No defensive code
+- Verify after every change
+
+## SEE ALSO
+
+elelem-modes(7), elelem-mode-review(7)

@@ -0,0 +1,76 @@
+# ELELEM-MODE-DESIGN(7)
+
+## NAME
+
+elelem-mode-design - research and plan implementation
+
+## SYNOPSIS
+
+```
+/mode design
+```
+
+## DESCRIPTION
+
+Design mode focuses the agent on researching and planning implementation for
+backlog stories. The agent explores the codebase, identifies patterns and
+extension points, then breaks stories into atomic tasks.
+
+## ROLE
+
+- Read stories from `.elelem/backlog/`
+- Explore codebase to understand existing patterns
+- Fill in the Tasks section of each story
+- Identify risks and dependencies
+
+## CONSTRAINTS
+
+**Allowed:**
+- read, glob, grep, task
+- execute (read-only commands)
+- edit (only files in .elelem/backlog/)
+
+**Blocked:**
+- Code changes
+- Test changes
+
+## PROCESS
+
+1. **Review** - Read stories in .elelem/backlog/
+2. **Explore** - Trace code paths, find extension points
+3. **Research** - Consider design options and trade-offs
+4. **Plan** - Break each story into implementation tasks
+5. **Update** - Edit story files to add Tasks
+
+## TASK FORMAT
+
+Tasks should be added to the story's `# Tasks` section:
+
+```markdown
+# Tasks
+
+* [ ] Create FooService in lib/foo_service.rb
+* [ ] Add #bar method to handle X
+* [ ] Write spec in spec/foo_service_spec.rb
+* [ ] Update config/routes.rb to add endpoint
+```
+
+## GUIDELINES
+
+- Tasks should be small, atomic, and independently testable
+- Order tasks by dependency (do X before Y)
+- Reference specific files to modify
+- Note if new files are needed
+- Consider test-first ordering
+
+## TRADE-OFF DIMENSIONS
+
+When designing, consider:
+
+- Simplicity vs Flexibility
+- Performance vs Readability
+- Coupling vs Cohesion
+
+## SEE ALSO
+
+elelem-modes(7), elelem-mode-build(7)

@@ -0,0 +1,74 @@
+# ELELEM-MODES(7)
+
+## NAME
+
+elelem-modes - system prompt modes
+
+## DESCRIPTION
+
+Modes adjust the agent's system prompt and behavior for different phases of
+development. Each mode focuses the agent on a specific task with appropriate
+constraints.
+
+## AVAILABLE MODES
+
+| Mode | Purpose | Constraints |
+|------|---------|-------------|
+| design | Research and plan implementation | Read-only, can edit backlog |
+| build | Execute tasks with TDD | All tools available |
+| review | Verify changes meet criteria | Read-only analysis |
+| verify | Demo feature to Product Owner | End-to-end testing |
+
+## SWITCHING MODES
+
+```
+/mode              # show current mode and list all modes
+/mode design       # switch to design mode
+/mode build        # switch to build mode
+```
+
+## MODE DOCUMENTATION
+
+* [design](design.md) - research and planning
+* [build](build.md) - implementation with TDD
+* [review](review.md) - code review against criteria
+* [verify](verify.md) - end-to-end verification
+
+## CUSTOM MODES
+
+Create custom modes by adding ERB templates to `.elelem/prompts/`:
+
+```
+.elelem/prompts/mymode.erb
+```
+
+The template has access to these variables:
+
+| Variable | Description |
+|----------|-------------|
+| `pwd` | Current working directory |
+| `platform` | Operating system |
+| `date` | Current date |
+| `git_info` | Git branch and status |
+| `repo_map` | Ctags-generated code map |
+| `agents_md` | Contents of AGENTS.md |
+| `elelem_source` | Path to elelem source |
+
+Example custom mode:
+
+```erb
+You are in documentation mode. Write clear, concise docs.
+
+# Role
+- Generate documentation for code
+- Follow the project's doc style
+
+# Environment
+pwd: <%= pwd %>
+date: <%= date %>
+<%= git_info %>
+```
+
+## SEE ALSO
+
+elelem-workflow(7), elelem-plugins(7)

@@ -0,0 +1,71 @@
+# ELELEM-MODE-REVIEW(7)
+
+## NAME
+
+elelem-mode-review - code review against criteria
+
+## SYNOPSIS
+
+```
+/mode review
+```
+
+## DESCRIPTION
+
+Review mode focuses the agent on verifying that code changes meet the
+acceptance criteria defined in the story. The agent performs a structured
+code review and reports findings.
+
+## ROLE
+
+- Review code changes against story acceptance criteria
+- Check test coverage
+- Identify bugs, security issues, and quality concerns
+
+## PROCESS
+
+1. **Context** - Read the story from .elelem/backlog/
+2. **Diff** - Run `git diff` to see changes
+3. **Trace** - Read surrounding context
+4. **Verify** - Check each acceptance criterion
+5. **Report** - Summarize findings
+
+## REVIEW CHECKLIST
+
+- [ ] All tasks in story are checked off
+- [ ] Acceptance criteria are satisfied
+- [ ] Tests exist and pass
+- [ ] No logic errors or edge case bugs
+- [ ] No security vulnerabilities
+- [ ] No performance issues
+- [ ] SOLID principles followed
+- [ ] Code is readable and minimal
+
+## OUTPUT FORMAT
+
+```markdown
+## Story: <story file name>
+
+### Acceptance Criteria
+- [x] <criterion> - PASS
+- [ ] <criterion> - FAIL: <reason>
+
+### Issues
+#### [severity] filename:line - title
+<description and suggestion>
+
+Severity: critical | warning | nit
+
+### Verdict
+<approve | request changes | needs discussion>
+```
+
+## GUIDELINES
+
+- Be specific: cite file:line
+- Suggest fixes
+- Distinguish blocking from non-blocking issues
+
+## SEE ALSO
+
+elelem-modes(7), elelem-mode-verify(7)

@@ -0,0 +1,65 @@
+# ELELEM-MODE-VERIFY(7)
+
+## NAME
+
+elelem-mode-verify - end-to-end verification
+
+## SYNOPSIS
+
+```
+/mode verify
+```
+
+## DESCRIPTION
+
+Verify mode focuses the agent on demoing the feature as if presenting to a
+Product Owner. The agent performs end-to-end testing from the user's
+perspective and documents the results.
+
+## ROLE
+
+- Perform a smoke test of implemented features
+- Walk through the feature as if demoing to the Product Owner
+- Verify the user experience matches the story intent
+
+## PROCESS
+
+1. **Setup** - Identify what to demo from .elelem/backlog/
+2. **Execute** - Run the feature end-to-end
+3. **Observe** - Note behavior, output, any issues
+4. **Document** - Add demo notes to story file
+5. **Report** - Summarize for Product Owner
+
+## DEMO CHECKLIST
+
+- [ ] Feature works as described in story
+- [ ] Happy path completes successfully
+- [ ] Error cases are handled gracefully
+- [ ] Output/behavior matches user expectations
+
+## STORY UPDATE
+
+After demo, add to story file:
+
+```markdown
+# Demo Notes
+
+Verified: <date>
+Status: ACCEPTED | NEEDS WORK
+
+Observations:
+- <what was tested>
+- <what worked>
+- <what needs attention>
+```
+
+## GUIDELINES
+
+- Test from user perspective, not developer
+- Try realistic scenarios
+- Note any UX issues
+- Be honest about gaps
+
+## SEE ALSO
+
+elelem-modes(7), elelem-workflow(7)

@@ -2,7 +2,6 @@
 /.yardoc
 /_yardoc/
 /coverage/
-/doc/
 /pkg/
 /spec/reports/
 /tmp/