Enable Ava to switch between different project contexts (e.g., omnirepo vs ~/fund) with separate AGENTS.md files and infrastructure.
User requirement:
/switch-project fund should switch to ~/fund directory- Each project has its own AGENTS.md and infrastructure
- Need to handle multiple project contexts simultaneously
Current constraints:
- systemd service sets a fixed working directory
- system prompt instructs Ava to work in omnirepo worktree
- unclear how to reconcile multiple working directories with service setup
Design questions to resolve:
1. Should this maintain per-project context state (active project, last-used files, etc.)?
2. How should file paths be resolved when switching projects? (absolute vs relative)
3. Should each project have its own:
- task database?
- memory/recall context?
- chat history?
- subagent spawning namespace?
4. Implementation approach:
- Option A: maintain project state in memory, prefix all file operations with project root
- Option B: dynamically update system prompt with current project context
- Option C: spawn project-specific subagents that operate in their own working directory
- Option D: refactor to support multiple simultaneous project contexts
5. Should there be a default project, or does Ava need explicit project context for all operations?
6. How should /switch-project interact with systemd service constraints?
Acceptance criteria:
- User can switch between omnirepo and ~/fund (and potentially other projects)
- File operations respect the current project context
- AGENTS.md is read from the correct project directory
- Clear UX for which project is currently active
Design constraint: project switching should work by swapping the filesystem context section of Ava's system prompt, not by implicit path prepending. Each project has a registry entry with root path, description, and key files. When user switches projects, we reconstruct that prompt section with the new project's context. Ava already uses absolute paths, so no changes needed to file tool calls. Memories and tasks remain global per user across all projects.