@maincode-ai/matilda-code 0.21.13 → 0.22.0

package/bundled/mainy/docs/features/approval-mode.md

@@ -1,388 +0,0 @@
-# Approval Mode
-
-Matilda Code offers five distinct permission modes that allow you to flexibly control how AI interacts with your code and system based on task complexity and risk level.
-
-## Permission Modes Comparison
-
-| Mode                 | File Editing                | Shell Commands              | Best For                                                                                               | Risk Level |
-| -------------------- | --------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------ | ---------- |
-| **Plan**​            | ❌ Read-only analysis only  | ❌ Not executed             | • Code exploration <br>• Planning complex changes <br>• Safe code review                               | Lowest     |
-| **Ask Permissions**​ | ✅ Manual approval required | ✅ Manual approval required | • New/unfamiliar codebases <br>• Critical systems <br>• Team collaboration <br>• Learning and teaching | Low        |
-| **Auto-Edit**​       | ✅ Auto-approved            | ❌ Manual approval required | • Daily development tasks <br>• Refactoring and code improvements <br>• Safe automation                | Medium     |
-| **Auto**​            | ✅ Classifier-evaluated     | ✅ Classifier-evaluated     | • Long autonomous sessions <br>• When Auto-Edit is too cautious but YOLO is too risky                  | Medium     |
-| **YOLO**​            | ✅ Auto-approved            | ✅ Auto-approved            | • Trusted personal projects <br>• Automated scripts/CI/CD <br>• Batch processing tasks                 | Highest    |
-
-> [!NOTE]
->
-> The mode previously named **Default** has been renamed to **Ask Permissions** to better describe its behavior. The underlying configuration value (`tools.approvalMode: "default"`) and the `/approval-mode default` command are unchanged for backward compatibility.
-
-### Quick Reference Guide
-
-- **Start in Plan Mode**: Great for understanding before making changes
-- **Work in Ask Permissions Mode**: The balanced choice for most development work
-- **Switch to Auto-Edit**: When you're making lots of safe code changes
-- **Try Auto Mode**: When you want fewer interruptions but still want safety on shell commands and network calls — an LLM classifier evaluates each call
-- **Use YOLO sparingly**: Only for trusted automation in controlled environments
-
-> [!tip]
->
-> You can quickly cycle through modes during a session using **Shift+Tab** (or **Tab** on Windows). The terminal status bar shows your current mode, so you always know what permissions Matilda Code has.
-
-> The cycle order is: **plan → default → auto-edit → auto → yolo → plan → ...**
-
-## 1. Use Plan Mode for safe code analysis
-
-Plan Mode instructs Matilda Code to create a plan by analyzing the codebase with **read-only** operations, perfect for exploring codebases, planning complex changes, or reviewing code safely.
-
-### When to use Plan Mode
-
-- **Multi-step implementation**: When your feature requires making edits to many files
-- **Code exploration**: When you want to research the codebase thoroughly before changing anything
-- **Interactive development**: When you want to iterate on the direction with Matilda Code
-
-### How to use Plan Mode
-
-**Turn on Plan Mode during a session**
-
-You can switch into Plan Mode during a session using **Shift+Tab** (or **Tab** on Windows) to cycle through permission modes.
-
-If you are in Normal Mode, **Shift+Tab** (or **Tab** on Windows) first switches into `auto-edits` Mode, indicated by `⏵⏵ accept edits on` at the bottom of the terminal. A subsequent **Shift+Tab** (or **Tab** on Windows) will switch into Plan Mode, indicated by `⏸ plan mode`.
-
-**Use the `/plan` command**
-
-The `/plan` command provides a quick shortcut for entering and exiting Plan Mode:
-
-```bash
-/plan                          # Enter plan mode
-/plan refactor the auth module # Enter plan mode and start planning
-/plan exit                     # Exit plan mode, restore previous mode
-```
-
-When you exit Plan Mode with `/plan exit`, your previous approval mode is automatically restored (e.g., if you were in Auto-Edit before entering Plan Mode, you'll return to Auto-Edit).
-
-**Start a new session in Plan Mode**
-
-To start a new session in Plan Mode, use the `/approval-mode` then select `plan`
-
-```bash
-/approval-mode
-```
-
-**Run "headless" queries in Plan Mode**
-
-You can also run a query in Plan Mode directly with `-p` or `prompt`:
-
-```bash
-matilda --prompt "What is machine learning?"
-```
-
-### Example: Planning a complex refactor
-
-```bash
-/plan I need to refactor our authentication system to use OAuth2. Create a detailed migration plan.
-```
-
-Matilda Code enters Plan Mode and analyzes the current implementation to create a comprehensive plan. Refine with follow-ups:
-
-```
-What about backward compatibility?
-How should we handle database migration?
-```
-
-### Configure Plan Mode as default
-
-```json
-// .matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "plan"
-  }
-}
-```
-
-## 2. Use Ask Permissions Mode for Controlled Interaction
-
-Ask Permissions Mode is the standard way to work with Matilda Code. In this mode, you maintain full control over all potentially risky operations - Matilda Code will ask for your approval before making any file changes or executing shell commands.
-
-### When to use Ask Permissions Mode
-
-- **New to a codebase**: When you're exploring an unfamiliar project and want to be extra cautious
-- **Critical systems**: When working on production code, infrastructure, or sensitive data
-- **Learning and teaching**: When you want to understand each step Matilda Code is taking
-- **Team collaboration**: When multiple people are working on the same codebase
-- **Complex operations**: When the changes involve multiple files or complex logic
-
-### How to use Ask Permissions Mode
-
-**Turn on Ask Permissions Mode during a session**
-
-You can switch into Ask Permissions Mode during a session using **Shift+Tab**​ (or **Tab** on Windows) to cycle through permission modes. If you're in any other mode, pressing **Shift+Tab** (or **Tab** on Windows) will eventually cycle back to Ask Permissions Mode, indicated by the absence of any mode indicator at the bottom of the terminal.
-
-**Start a new session in Ask Permissions Mode**
-
-Ask Permissions Mode is the initial mode when you start Matilda Code. If you've changed modes and want to return to Ask Permissions Mode, use:
-
-```
-/approval-mode default
-```
-
-**Run "headless" queries in Ask Permissions Mode**
-
-When running headless commands, Ask Permissions Mode is the default behavior. You can explicitly specify it with:
-
-```
-matilda --prompt "Analyze this code for potential bugs"
-```
-
-### Example: Safely implementing a feature
-
-```
-/approval-mode default
-```
-
-```
-I need to add user profile pictures to our application. The pictures should be stored in an S3 bucket and the URLs saved in the database.
-```
-
-Matilda Code will analyze your codebase and propose a plan. It will then ask for approval before:
-
-1. Creating new files (controllers, models, migrations)
-2. Modifying existing files (adding new columns, updating APIs)
-3. Running any shell commands (database migrations, dependency installation)
-
-You can review each proposed change and approve or reject it individually.
-
-### Configure Ask Permissions Mode as default
-
-```bash
-// .matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "default"
-  }
-}
-```
-
-## 3. Auto Edits Mode
-
-Auto-Edit Mode instructs Matilda Code to automatically approve file edits while requiring manual approval for shell commands, ideal for accelerating development workflows while maintaining system safety.
-
-Auto-approved edit tools include `edit`, `write_file`, and `notebook_edit`.
-
-### When to use Auto-Accept Edits Mode
-
-- **Daily development**: Ideal for most coding tasks
-- **Safe automation**: Allows AI to modify code while preventing accidental execution of dangerous commands
-- **Team collaboration**: Use in shared projects to avoid unintended impacts on others
-
-### How to switch to this mode
-
-```
-# Switch via command
-/approval-mode auto-edit
-
-# Or use keyboard shortcut
-Shift+Tab (or Tab on Windows) # Switch from other modes
-```
-
-### Workflow Example
-
-1. You ask Matilda Code to refactor a function
-2. AI analyzes the code and proposes changes
-3. **Automatically**​ applies all file changes without confirmation
-4. If tests need to be run, it will **request approval**​ to execute `npm test`
-
-## 4. Auto Mode - Classifier-Driven Approval
-
-Auto Mode sits between Auto-Edit and YOLO. An LLM classifier evaluates each
-shell command, network call, and out-of-workspace edit and auto-approves
-the ones it judges safe while blocking risky ones. Most read-only operations
-and in-workspace edits skip the classifier for speed.
-
-See [auto-mode.md](./auto-mode.md) for the full reference (hints
-configuration, troubleshooting, FAQ).
-
-### When to use Auto Mode
-
-- **Long autonomous sessions**: When Ask Permissions Mode interrupts too often but
-  YOLO is too risky.
-- **Trusted projects**: Internal codebases where the agent should keep
-  moving but you still want a guardrail on destructive shell commands and
-  outbound network calls.
-- **Headless / scheduled runs**: Where Auto-Edit isn't enough (the agent
-  needs to run shell commands too) but you want safety on `rm -rf /`,
-  `curl ... | sh`, credential exfiltration, etc.
-
-### How to use Auto Mode
-
-**Turn on Auto Mode during a session**
-
-Press **Shift+Tab** (or **Tab** on Windows) to cycle into Auto Mode. The
-status bar shows the active mode.
-
-**Use the `/approval-mode` command**
-
-```
-/approval-mode auto
-```
-
-The first time you enter Auto Mode, an information message explains how it
-works. The notice does not appear again.
-
-**Start a new session in Auto Mode**
-
-```jsonc
-// .matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "auto",
-  },
-}
-```
-
-### What Auto Mode auto-approves vs blocks
-
-The classifier is biased toward blocking when uncertain. Defaults:
-
-- **Auto-approved**: read-only commands (ls, cat, git status, grep, find),
-  package install in cwd, build/test commands, file edits inside the
-  workspace, local-only operations.
-- **Blocked**: irreversible destruction (rm -rf /, fdisk, mkfs),
-  code-from-external execution (curl | sh, eval of remote content),
-  credential exfiltration, unauthorized persistence (.bashrc edits,
-  crontab), security weakening, force-push to main/master.
-
-You can customize the classifier's judgement via natural-language hints in
-settings.json. See [auto-mode.md](./auto-mode.md#configuring-hints).
-
-### Safety guardrails
-
-- **Hard rules remain in force**: `permissions.deny` rules block actions
-  before the classifier ever runs.
-- **Over-broad allow rules are stripped while in Auto Mode**: e.g.
-  `permissions.allow: ["Bash"]` (allow every shell command) defeats the
-  classifier; entering Auto Mode temporarily disables such rules so the
-  classifier can do its job. The rules are restored when you leave Auto
-  Mode. Settings on disk are never modified.
-- **Fail-closed**: when the classifier API is unreachable, the action is
-  blocked rather than allowed. After two consecutive unavailable calls,
-  the next tool call falls back to manual approval.
-- **Loop guard**: after three consecutive policy blocks, the next call
-  also falls back to manual approval so the agent isn't stuck cycling on
-  a dead-end approach.
-
-### Example
-
-```
-/approval-mode auto
-Refactor the auth module to use OAuth2. Run the full test suite afterwards.
-```
-
-Matilda Code makes the file edits (in-workspace edits skip the classifier),
-runs `npm test` (classifier judges safe), and surfaces a block if it ever
-tries something risky like `rm -rf /Users/me/.aws`. You can review the
-reason inline and decide whether to switch to Ask Permissions Mode for that step.
-
-### Configure Auto Mode as default
-
-```jsonc
-// .matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "auto",
-  },
-  "permissions": {
-    "autoMode": {
-      "hints": {
-        "allow": ["Running pytest, mypy, and ruff on this Python repo"],
-        "deny": ["Any network call to intranet.example.com"],
-      },
-      "environment": ["Open-source monorepo; commits are signed"],
-    },
-  },
-}
-```
-
-## 5. YOLO Mode - Full Automation
-
-YOLO Mode grants Matilda Code the highest permissions, automatically approving all tool calls including file editing and shell commands.
-
-### When to use YOLO Mode
-
-- **Automated scripts**: Running predefined automated tasks
-- **CI/CD pipelines**: Automated execution in controlled environments
-- **Personal projects**: Rapid iteration in fully trusted environments
-- **Batch processing**: Tasks requiring multi-step command chains
-
-> [!warning]
->
-> **Use YOLO Mode with caution**: AI can execute any command with your terminal permissions. Ensure:
->
-> 1. You trust the current codebase
-> 2. You understand all actions AI will perform
-> 3. Important files are backed up or committed to version control
-
-### How to enable YOLO Mode
-
-```
-# Temporarily enable (current session only)
-/approval-mode yolo
-
-# Set as project default
-/approval-mode yolo --project
-
-# Set as user global default
-/approval-mode yolo --user
-```
-
-### Configuration Example
-
-```bash
-// .matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "yolo"
-  }
-}
-```
-
-### Automated Workflow Example
-
-```bash
-# Fully automated refactoring task
-matilda --prompt "Run the test suite, fix all failing tests, then commit changes"
-
-# Without human intervention, AI will:
-# 1. Run test commands (auto-approved)
-# 2. Fix failed test cases (auto-edit files)
-# 3. Execute git commit (auto-approved)
-```
-
-## Mode Switching & Configuration
-
-### Keyboard Shortcut Switching
-
-During a Matilda Code session, use **Shift+Tab**​ (or **Tab** on Windows) to quickly cycle through the five modes:
-
-```
-Plan Mode → Ask Permissions Mode → Auto-Edit Mode → Auto Mode → YOLO Mode → Plan Mode
-```
-
-### Persistent Configuration
-
-```
-// Project-level: ./.matilda/settings.json
-// User-level: ~/.matilda/settings.json
-{
-  "tools": {
-    "approvalMode": "auto-edit"  // or "plan", "default", "auto", "yolo"
-  }
-}
-```
-
-### Mode Usage Recommendations
-
-1. **New to codebase**: Start with **Plan Mode**​ for safe exploration
-2. **Daily development tasks**: Use **Auto-Accept Edits**​ (default mode), efficient and safe
-3. **Automated scripts**: Use **YOLO Mode**​ in controlled environments for full automation
-4. **Complex refactoring**: Use **Plan Mode**​ first for detailed planning, then switch to appropriate mode for execution

package/bundled/mainy/docs/features/arena.md

@@ -1,219 +0,0 @@
-# Agent Arena
-
-> Dispatch multiple AI models simultaneously to execute the same task, compare their solutions side-by-side, and select the best result to apply to your workspace.
-
-> [!warning]
-> Agent Arena is experimental. It has [known limitations](#limitations) around display modes and session management.
-
-Agent Arena lets you pit multiple AI models against each other on the same task. Each model runs as a fully independent agent in its own isolated Git worktree, so file operations never interfere. When all agents finish, you compare results and select a winner to merge back into your main workspace.
-
-Unlike [subagents](/users/features/sub-agents), which delegate focused subtasks within a single session, Arena agents are complete, top-level agent instances — each with its own model, context window, and full tool access.
-
-This page covers:
-
-- [When to use Agent Arena](#when-to-use-agent-arena)
-- [Starting an arena session](#start-an-arena-session)
-- [Interacting with agents](#interact-with-agents), including display modes and navigation
-- [Comparing results and selecting a winner](#compare-results-and-select-a-winner)
-- [Best practices](#best-practices)
-
-## When to use Agent Arena
-
-Agent Arena is most effective when you want to **evaluate or compare** how different models tackle the same problem. The strongest use cases are:
-
-- **Model benchmarking**: Evaluate different models' capabilities on real tasks in your actual codebase, not synthetic benchmarks
-- **Best-of-N selection**: Get multiple independent solutions and pick the best implementation
-- **Exploring approaches**: See how different models reason about and solve the same problem — useful for learning and insight
-- **Risk reduction**: For critical changes, validate that multiple models converge on a similar approach before committing
-
-Agent Arena uses significantly more tokens than a single session (each agent has its own context window and model calls). It works best when the value of comparison justifies the cost. For routine tasks where you trust your default model, a single session is more efficient.
-
-## Start an arena session
-
-Use the `/arena` slash command to launch a session. Specify the models you want to compete and the task:
-
-```
-/arena --models matilda3.5-plus,glm-5,kimi-k2.5 "Refactor the authentication module to use JWT tokens"
-```
-
-If you omit `--models`, an interactive model selection dialog appears, letting you pick from your configured providers.
-
-### What happens when you start
-
-1. **Worktree setup**: Matilda Code creates isolated Git worktrees for each agent at `~/.matilda/arena/<session-id>/worktrees/<model-name>/`. Each worktree mirrors your current working directory state exactly — including staged changes, unstaged changes, and untracked files.
-2. **Agent spawning**: Each agent starts in its own worktree with full tool access and its configured model. Agents are launched sequentially but execute in parallel.
-3. **Execution**: All agents work on the task independently with no shared state or communication. You can monitor their progress and interact with any of them.
-4. **Completion**: When all agents finish (or fail), you enter the result comparison phase.
-
-## Interact with agents
-
-### Display modes
-
-Agent Arena currently supports **in-process mode**, where all agents run asynchronously within the same terminal process. A tab bar at the bottom of the terminal lets you switch between agents.
-
-> [!note]
-> **Split-pane display modes are planned for the future.** We intend to support tmux-based and iTerm2-based split-pane layouts, where each agent gets its own terminal pane for true side-by-side viewing. Currently, only in-process tab switching is available.
-
-### Navigate between agents
-
-In in-process mode, use keyboard shortcuts to switch between agent views:
-
-| Shortcut | Action                            |
-| :------- | :-------------------------------- |
-| `Right`  | Switch to the next agent tab      |
-| `Left`   | Switch to the previous agent tab  |
-| `Up`     | Switch focus to the input box     |
-| `Down`   | Switch focus to the agent tab bar |
-
-The tab bar shows each agent's current status:
-
-| Indicator | Meaning                |
-| :-------- | :--------------------- |
-| `●`       | Running or idle        |
-| `✓`       | Completed successfully |
-| `✗`       | Failed                 |
-| `○`       | Cancelled              |
-
-### Interact with individual agents
-
-When viewing an agent's tab, you can:
-
-- **Send messages** — type in the input area to give the agent additional instructions
-- **Approve tool calls** — if an agent requests tool approval, the confirmation dialog appears in its tab
-- **View full history** — scroll through the agent's complete conversation, including model output, tool calls, and results
-
-Each agent is a full, independent session. Anything you can do with the main agent, you can do with an arena agent.
-
-## Compare results and select a winner
-
-When all agents complete, the Arena enters the result comparison phase. You'll see:
-
-- **Status summary**: Which agents succeeded, failed, or were cancelled
-- **Execution metrics**: Duration, rounds of reasoning, token usage, and tool call counts for each agent
-- **Arena comparison summary**: Files changed in common vs. by one agent only, line-change counts, token efficiency, and a high-level approach summary generated from each agent's diff, metrics, and conversation history
-
-A selection dialog presents the successful agents. Choose one to apply its changes to your main workspace, or discard all results. Press `p` to toggle a quick preview for the highlighted agent, or `d` to toggle that agent's detailed diff before selecting a winner.
-
-### What happens when you select a winner
-
-1. The winning agent's changes are extracted as a diff against the baseline
-2. The diff is applied to your main working directory
-3. All worktrees and temporary branches are cleaned up automatically
-
-If you want to inspect the complete reasoning path before deciding, each agent's full conversation history is still available via the tab bar while the selection dialog is active.
-
-## Configuration
-
-Arena behavior can be customized in [settings.json](/users/configuration/settings):
-
-```json
-{
-  "arena": {
-    "worktreeBaseDir": "~/.matilda/arena",
-    "maxRoundsPerAgent": 50,
-    "timeoutSeconds": 600
-  }
-}
-```
-
-| Setting                   | Description                        | Default            |
-| :------------------------ | :--------------------------------- | :----------------- |
-| `arena.worktreeBaseDir`   | Base directory for arena worktrees | `~/.matilda/arena` |
-| `arena.maxRoundsPerAgent` | Maximum reasoning rounds per agent | `50`               |
-| `arena.timeoutSeconds`    | Timeout for each agent in seconds  | `600`              |
-
-## Best practices
-
-### Choose models that complement each other
-
-Arena is most valuable when you compare models with meaningfully different strengths. For example:
-
-```
-/arena --models matilda3.5-plus,glm-5,kimi-k2.5 "Optimize the database query layer"
-```
-
-Comparing three versions of the same model family yields less insight than comparing across providers.
-
-### Keep tasks self-contained
-
-Arena agents work independently with no communication. Tasks should be fully describable in the prompt without requiring back-and-forth:
-
-**Good**: "Refactor the payment module to use the strategy pattern. Update all tests."
-
-**Less effective**: "Let's discuss how to improve the payment module" — this benefits from conversation, which is better suited to a single session.
-
-### Limit the number of agents
-
-Up to 5 agents can run simultaneously. In practice, 2-3 agents provide the best balance of comparison value to resource cost. More agents means:
-
-- Higher token costs (each agent has its own context window)
-- Longer total execution time
-- More results to compare
-
-Start with 2-3 and scale up only when the comparison value justifies it.
-
-### Use Arena for high-impact decisions
-
-Arena shines when the stakes justify running multiple models:
-
-- Choosing an architecture for a new module
-- Selecting an approach for a complex refactor
-- Validating a critical bug fix from multiple angles
-
-For routine changes like renaming a variable or updating a config file, a single session is faster and cheaper.
-
-## Troubleshooting
-
-### Agents failing to start
-
-- Verify that each model in `--models` is properly configured with valid API credentials
-- Check that your working directory is a Git repository (worktrees require Git)
-- Ensure you have write access to the worktree base directory (`~/.matilda/arena/` by default)
-
-### Worktree creation fails
-
-- Run `git worktree list` to check for stale worktrees from previous sessions
-- Clean up stale worktrees with `git worktree prune`
-- Ensure your Git version supports worktrees (`git --version`, requires Git 2.5+)
-
-### Agent takes too long
-
-- Increase the timeout: set `arena.timeoutSeconds` in settings
-- Reduce task complexity — Arena tasks should be focused and well-defined
-- Lower `arena.maxRoundsPerAgent` if agents are spending too many rounds
-
-### Applying winner fails
-
-- Check for uncommitted changes in your main working directory that might conflict
-- The diff is applied as a patch — merge conflicts are possible if your working directory changed during the session
-
-## Limitations
-
-Agent Arena is experimental. Current limitations:
-
-- **In-process mode only**: Split-pane display via tmux or iTerm2 is not yet available. All agents run within a single terminal window with tab switching.
-- **No diff preview before selection**: You can view each agent's conversation history, but there is no unified diff viewer to compare solutions side-by-side before picking a winner.
-- **No worktree retention**: Worktrees are always cleaned up after selection. There is no option to preserve them for further inspection.
-- **No session resumption**: Arena sessions cannot be resumed after exiting. If you close the terminal mid-session, worktrees remain on disk and must be cleaned up manually via `git worktree prune`.
-- **Maximum 5 agents**: The hard limit of 5 concurrent agents cannot be changed.
-- **Git repository required**: Arena requires a Git repository for worktree isolation. It cannot be used in non-Git directories.
-
-## Comparison with other multi-agent modes
-
-Agent Arena is one of several planned multi-agent modes in Matilda Code. **Agent Team** and **Agent Swarm** are not yet implemented — the table below describes their intended design for reference.
-
-|                   | **Agent Arena**                                        | **Agent Team** (planned)                           | **Agent Swarm** (planned)                                |
-| :---------------- | :----------------------------------------------------- | :------------------------------------------------- | :------------------------------------------------------- |
-| **Goal**          | Competitive: Find the best solution to the _same_ task | Collaborative: Tackle _different_ aspects together | Batch parallel: Dynamically spawn workers for bulk tasks |
-| **Agents**        | Pre-configured models compete independently            | Teammates collaborate with assigned roles          | Workers spawned on-the-fly, destroyed on completion      |
-| **Communication** | No inter-agent communication                           | Direct peer-to-peer messaging                      | One-way: results aggregated by parent                    |
-| **Isolation**     | Full: separate Git worktrees                           | Independent sessions with shared task list         | Lightweight ephemeral context per worker                 |
-| **Output**        | One selected solution applied to workspace             | Synthesized results from multiple perspectives     | Aggregated results from parallel processing              |
-| **Best for**      | Benchmarking, choosing between model approaches        | Research, complex collaboration, cross-layer work  | Batch operations, data processing, map-reduce tasks      |
-
-## Next steps
-
-Explore related approaches for parallel and delegated work:
-
-- **Lightweight delegation**: [Subagents](/users/features/sub-agents) handle focused subtasks within your session — better when you don't need model comparison
-- **Manual parallel sessions**: Run multiple Matilda Code sessions yourself in separate terminals with [Git worktrees](https://git-scm.com/docs/git-worktree) for full manual control