@maincode-ai/matilda-code 0.21.13 → 0.22.0-nightly.20261101.b0ad315a4

package/bundled/mainy/docs/configuration/themes.md

@@ -1,199 +0,0 @@
-# Themes
-
-Matilda Code supports a variety of themes to customize its color scheme and appearance. You can change the theme to suit your preferences via the `/theme` command or `"theme":` configuration setting.
-
-## Available Themes
-
-Matilda Code comes with a selection of pre-defined themes, which you can list using the `/theme` command within the CLI:
-
-- **Dark Themes:**
-  - `ANSI`
-  - `Atom One`
-  - `Ayu`
-  - `Default`
-  - `Dracula`
-  - `GitHub`
-- **Light Themes:**
-  - `ANSI Light`
-  - `Ayu Light`
-  - `Default Light`
-  - `GitHub Light`
-  - `Google Code`
-  - `Xcode`
-
-### Changing Themes
-
-1.  Enter `/theme` into Matilda Code.
-2.  A dialog or selection prompt appears, listing the available themes.
-3.  Using the arrow keys, select a theme. Some interfaces might offer a live preview or highlight as you select.
-4.  Confirm your selection to apply the theme.
-
-**Note:** If a theme is defined in your `settings.json` file (either by name or by a file path), you must remove the `"theme"` setting from the file before you can change the theme using the `/theme` command.
-
-### Theme Persistence
-
-Selected themes are saved in Matilda Code's [configuration](../configuration/settings) so your preference is remembered across sessions.
-
----
-
-## Auto Theme Detection
-
-When the theme is set to `"auto"` (or left unset), Matilda Code automatically detects whether your terminal uses a dark or light background and selects the matching Matilda theme (`Matilda Dark` or `Matilda Light`).
-
-### How to enable
-
-Set the theme to `"auto"` in `settings.json`:
-
-```json
-{
-  "ui": {
-    "theme": "auto"
-  }
-}
-```
-
-Or select **Auto** in the `/theme` dialog. This is the default behavior when no theme is explicitly configured.
-
-### Detection methods
-
-Matilda Code uses multiple detection methods in a fallback chain. At startup (async path), the order is:
-
-| Priority | Method                  | Platform   | How it works                                                                                         |
-| -------- | ----------------------- | ---------- | ---------------------------------------------------------------------------------------------------- |
-| 1        | `COLORFGBG`             | All        | Reads the `COLORFGBG` environment variable (set by terminals like iTerm2, rxvt, Konsole)             |
-| 2        | OSC 11                  | All (TTY)  | Sends an `ESC]11;?` query to the terminal and parses the background color from the response (~200ms) |
-| 3        | macOS system appearance | macOS only | Runs `defaults read -g AppleInterfaceStyle` to check if macOS Dark Mode is active                    |
-| 4        | Default                 | All        | Falls back to dark theme if no method succeeds                                                       |
-
-The first method that returns a result wins. The detected value is cached for the session so subsequent theme resolutions (e.g. reselecting Auto in the `/theme` dialog) stay consistent.
-
-### When to use Auto
-
-- **Most users** — Auto works well if your terminal background matches your OS appearance or if your terminal sets `COLORFGBG` / supports OSC 11.
-- **tmux / screen users** — OSC 11 may not pass through multiplexers. Detection falls back to `COLORFGBG` or macOS system appearance. If neither is available, the default dark theme is used. Set a specific theme if auto-detection gives the wrong result.
-- **SSH sessions** — detection depends on the remote environment. If `COLORFGBG` is not forwarded and the remote terminal doesn't respond to OSC 11, the default dark theme is used.
-
----
-
-## Custom Color Themes
-
-Matilda Code allows you to create your own custom color themes by specifying them in your `settings.json` file. This gives you full control over the color palette used in the CLI.
-
-### How to Define a Custom Theme
-
-Add a `customThemes` block to your user, project, or system `settings.json` file. Each custom theme is defined as an object with a unique name and a set of color keys. For example:
-
-```json
-{
-  "ui": {
-    "customThemes": {
-      "MyCustomTheme": {
-        "name": "MyCustomTheme",
-        "type": "custom",
-        "Background": "#181818",
-        ...
-      }
-    }
-  }
-}
-```
-
-**Color keys:**
-
-- `Background`
-- `Foreground`
-- `LightBlue`
-- `AccentBlue`
-- `AccentPurple`
-- `AccentCyan`
-- `AccentGreen`
-- `AccentYellow`
-- `AccentRed`
-- `Comment`
-- `Gray`
-- `DiffAdded` (optional, for added lines in diffs)
-- `DiffRemoved` (optional, for removed lines in diffs)
-- `DiffModified` (optional, for modified lines in diffs)
-
-**Required Properties:**
-
-- `name` (must match the key in the `customThemes` object and be a string)
-- `type` (must be the string `"custom"`)
-- `Background`
-- `Foreground`
-- `LightBlue`
-- `AccentBlue`
-- `AccentPurple`
-- `AccentCyan`
-- `AccentGreen`
-- `AccentYellow`
-- `AccentRed`
-- `Comment`
-- `Gray`
-
-You can use either hex codes (e.g., `#FF0000`) **or** standard CSS color names (e.g., `coral`, `teal`, `blue`) for any color value. See [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#color_keywords) for a full list of supported names.
-
-You can define multiple custom themes by adding more entries to the `customThemes` object.
-
-### Loading Themes from a File
-
-In addition to defining custom themes in `settings.json`, you can also load a theme directly from a JSON file by specifying the file path in your `settings.json`. This is useful for sharing themes or keeping them separate from your main configuration.
-
-To load a theme from a file, set the `theme` property in your `settings.json` to the path of your theme file:
-
-```json
-{
-  "ui": {
-    "theme": "/path/to/your/theme.json"
-  }
-}
-```
-
-The theme file must be a valid JSON file that follows the same structure as a custom theme defined in `settings.json`.
-
-**Example `my-theme.json`:**
-
-```json
-{
-  "name": "My File Theme",
-  "type": "custom",
-  "Background": "#282A36",
-  "Foreground": "#F8F8F2",
-  "LightBlue": "#82AAFF",
-  "AccentBlue": "#61AFEF",
-  "AccentPurple": "#BD93F9",
-  "AccentCyan": "#8BE9FD",
-  "AccentGreen": "#50FA7B",
-  "AccentYellow": "#F1FA8C",
-  "AccentRed": "#FF5555",
-  "Comment": "#6272A4",
-  "Gray": "#ABB2BF",
-  "DiffAdded": "#A6E3A1",
-  "DiffRemoved": "#F38BA8",
-  "DiffModified": "#89B4FA",
-  "GradientColors": ["#4796E4", "#847ACE", "#C3677F"]
-}
-```
-
-**Security Note:** For your safety, Gemini CLI will only load theme files that are located within your home directory. If you attempt to load a theme from outside your home directory, a warning will be displayed and the theme will not be loaded. This is to prevent loading potentially malicious theme files from untrusted sources.
-
-### Example Custom Theme
-
-<img src="https://gw.alicdn.com/imgextra/i1/O1CN01Em30Hc1jYXAdIgls3_!!6000000004560-2-tps-1009-629.png" alt=" " style="zoom:100%;text-align:center;margin: 0 auto;" />
-
-### Using Your Custom Theme
-
-- Select your custom theme using the `/theme` command in Matilda Code. Your custom theme will appear in the theme selection dialog.
-- Or, set it as the default by adding `"theme": "MyCustomTheme"` to the `ui` object in your `settings.json`.
-- Custom themes can be set at the user, project, or system level, and follow the same [configuration precedence](../configuration/settings) as other settings.
-
-## Themes Preview
-
-|  Dark Theme  |                                                                                Preview                                                                                |  Light Theme  |                                                                                Preview                                                                                |
-| :----------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
-|     ANSI     |     <img src="https://gw.alicdn.com/imgextra/i2/O1CN01ZInJiq1GdSZc9gHsI_!!6000000000645-2-tps-1140-934.png" style="zoom:30%;text-align:center;margin: 0 auto;" />     |  ANSI Light   |     <img src="https://gw.alicdn.com/imgextra/i2/O1CN01IiJQFC1h9E3MXQj6W_!!6000000004234-2-tps-1140-934.png" style="zoom:30%;text-align:center;margin: 0 auto;" />     |
-| Atom OneDark |     <img src="https://gw.alicdn.com/imgextra/i2/O1CN01Zlx1SO1Sw21SkTKV3_!!6000000002310-2-tps-1140-934.png" style="zoom:30%;text-align:center;margin: 0 auto;" />     |   Ayu Light   | <img src="https://gw.alicdn.com/imgextra/i3/O1CN01zEUc1V1jeUJsnCgQb_!!6000000004573-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |
-|     Ayu      | <img src="https://gw.alicdn.com/imgextra/i3/O1CN019upo6v1SmPhmRjzfN_!!6000000002289-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> | Default Light | <img src="https://gw.alicdn.com/imgextra/i4/O1CN01RHjrEs1u7TXq3M6l3_!!6000000005990-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |
-|   Default    |     <img src="https://gw.alicdn.com/imgextra/i4/O1CN016pIeXz1pFC8owmR4Q_!!6000000005330-2-tps-1140-934.png" style="zoom:30%;text-align:center;margin: 0 auto;" />     | GitHub Light  | <img src="https://gw.alicdn.com/imgextra/i4/O1CN01US2b0g1VETCPAVWLA_!!6000000002621-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |
-|   Dracula    |     <img src="https://gw.alicdn.com/imgextra/i4/O1CN016htnWH20c3gd2LpUR_!!6000000006869-2-tps-1140-934.png" style="zoom:30%;text-align:center;margin: 0 auto;" />     |  Google Code  | <img src="https://gw.alicdn.com/imgextra/i1/O1CN01Ng29ab23iQ2BuYKz8_!!6000000007289-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |
-|    GitHub    | <img src="https://gw.alicdn.com/imgextra/i4/O1CN01fFCRda1IQIQ9qDNqv_!!6000000000887-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |     Xcode     | <img src="https://gw.alicdn.com/imgextra/i1/O1CN010E3QAi1Huh5o1E9LN_!!6000000000818-2-tps-1140-934.png" alt=" " style="zoom:30%;text-align:center;margin: 0 auto;" /> |

package/bundled/mainy/docs/configuration/trusted-folders.md

@@ -1,67 +0,0 @@
-# Trusted Folders
-
-The Trusted Folders feature is a security setting that gives you control over which projects can use the full capabilities of the Matilda Code. It asks you to approve a folder before the CLI admits its workspace settings and project hooks.
-
-## Default Policy
-
-Folder trust is **enabled by default** for interactive CLI sessions. An unknown folder uses the existing trust dialog before its workspace settings and project hooks are admitted.
-
-To disable folder trust explicitly, add the following to your user `settings.json` file:
-
-```json
-{
-  "security": {
-    "folderTrust": {
-      "enabled": false
-    }
-  }
-}
-```
-
-## How It Works: The Trust Dialog
-
-Once the feature is enabled, the first time you run the Matilda Code from a folder, a dialog will automatically appear, prompting you to make a choice:
-
-- **Trust folder**: Grants full trust to the current folder (e.g. `my-project`).
-- **Trust parent folder**: Grants trust to the parent directory (e.g. `safe-projects`), which automatically trusts all of its subdirectories as well. This is useful if you keep all your safe projects in one place.
-- **Don't trust**: Marks the folder as untrusted. The CLI will operate in a restricted "safe mode."
-
-Your choice is saved in a central file (`~/.matilda/trustedFolders.json`), so you will only be asked once per folder.
-
-Explicit headless requests, including `-p` and piped input, retain implicit consent for unknown folders. Desktop uses its approved workspace and additional-directory manifest. These runtime decisions do not rewrite saved trust rules, and explicit rejections still apply. Generic ACP requests do not receive blanket consent.
-
-## Why Trust Matters: The Impact of an Untrusted Workspace
-
-When a folder is **untrusted**, the Matilda Code runs in a restricted "safe mode" to protect you. In this mode, the following features are disabled:
-
-1.  **Workspace Settings are Ignored**: The CLI will **not** load the `.matilda/settings.json` file from the project. This prevents the loading of custom tools and other potentially dangerous configurations.
-
-2.  **Project Environment Files Need Trust**: Unknown and rejected folders do not load project `.env` files. User-level environment files remain available.
-
-3.  **Extension Management is Restricted**: You **cannot install, update, or uninstall** extensions.
-
-4.  **Tool Auto-Acceptance is Disabled**: You will always be prompted before any tool is run, even if you have auto-acceptance enabled globally.
-
-5.  **Automatic Memory Loading is Disabled**: The CLI will not automatically load files into context from directories specified in local settings.
-
-Granting trust to a folder unlocks the full functionality of the Matilda Code for that workspace.
-
-Even in trusted folders, project `.env`, `.matilda/.env` and workspace `settings.env` cannot change process bootstrap or policy variables, including `NODE_OPTIONS`, `NODE_PATH`, `BASH_ENV`, `LD_PRELOAD`, `PATH`, storage locations, trust-file locations and Desktop directory consent. Ordinary variables, including gateway `*_BASE_URL` values, remain available. User-level files keep their initial loading behavior.
-
-## Managing Your Trust Settings
-
-If you need to change a decision or see all your settings, you have a couple of options:
-
-- **Change the Current Folder's Trust**: Run the `/permissions` command from within the CLI. This will bring up the same interactive dialog, allowing you to change the trust level for the current folder.
-
-- **View All Trust Rules**: To see a complete list of all your trusted and untrusted folder rules, you can inspect the contents of the `~/.matilda/trustedFolders.json` file in your home directory.
-
-## The Trust Check Process (Advanced)
-
-For advanced users, it's helpful to know the exact order of operations for how trust is determined:
-
-1.  **IDE Trust Signal**: If you are using the [IDE Integration](../ide-integration/ide-integration), the CLI first asks the IDE if the workspace is trusted. The IDE's response takes highest priority.
-
-2.  **Local Trust File**: If the IDE is not connected, the CLI checks the central `~/.matilda/trustedFolders.json` file.
-
-3.  **Runtime Consent**: If no saved decision exists, explicit headless use or Desktop's approved-directory manifest can grant trust for that runtime. Other unknown folders remain unresolved until the interactive choice.

package/bundled/mainy/docs/extension/_meta.ts

@@ -1,9 +0,0 @@
-export default {
-  introduction: 'Introduction',
-  'getting-started-extensions': {
-    display: 'hidden',
-  },
-  'extension-releasing': {
-    display: 'hidden',
-  },
-};

package/bundled/mainy/docs/extension/extension-releasing.md

@@ -1,204 +0,0 @@
-# Extension Releasing
-
-There are three primary ways of releasing extensions to users:
-
-- [Git repository](#releasing-through-a-git-repository)
-- [Github Releases](#releasing-through-github-releases)
-- [npm Registry](#releasing-through-npm-registry)
-
-Git repository releases tend to be the simplest and most flexible approach, while GitHub releases can be more efficient on initial install as they are shipped as single archives instead of requiring a git clone which downloads each file individually. Github releases may also contain platform specific archives if you need to ship platform specific binary files. npm registry releases are ideal for teams that already use npm for package distribution, especially with private registries.
-
-## Releasing through a git repository
-
-This is the most flexible and simple option. All you need to do us create a publicly accessible git repo (such as a public github repository) and then users can install your extension using `matilda extensions install <your-repo-uri>`, or for a GitHub repository they can use the simplified `matilda extensions install <org>/<repo>` format. They can optionally depend on a specific ref (branch/tag/commit) using the `--ref=<some-ref>` argument, this defaults to the default branch.
-
-Whenever commits are pushed to the ref that a user depends on, they will be prompted to update the extension. Note that this also allows for easy rollbacks, the HEAD commit is always treated as the latest version regardless of the actual version in the `matilda-extension.json` file.
-
-### Managing release channels using a git repository
-
-Users can depend on any ref from your git repo, such as a branch or tag, which allows you to manage multiple release channels.
-
-For instance, you can maintain a `stable` branch, which users can install this way `matilda extensions install <your-repo-uri> --ref=stable`. Or, you could make this the default by treating your default branch as your stable release branch, and doing development in a different branch (for instance called `dev`). You can maintain as many branches or tags as you like, providing maximum flexibility for you and your users.
-
-Note that these `ref` arguments can be tags, branches, or even specific commits, which allows users to depend on a specific version of your extension. It is up to you how you want to manage your tags and branches.
-
-### Example releasing flow using a git repo
-
-While there are many options for how you want to manage releases using a git flow, we recommend treating your default branch as your "stable" release branch. This means that the default behavior for `matilda extensions install <your-repo-uri>` is to be on the stable release branch.
-
-Lets say you want to maintain three standard release channels, `stable`, `preview`, and `dev`. You would do all your standard development in the `dev` branch. When you are ready to do a preview release, you merge that branch into your `preview` branch. When you are ready to promote your preview branch to stable, you merge `preview` into your stable branch (which might be your default branch or a different branch).
-
-You can also cherry pick changes from one branch into another using `git cherry-pick`, but do note that this will result in your branches having a slightly divergent history from each other, unless you force push changes to your branches on each release to restore the history to a clean slate (which may not be possible for the default branch depending on your repository settings). If you plan on doing cherry picks, you may want to avoid having your default branch be the stable branch to avoid force-pushing to the default branch which should generally be avoided.
-
-## Releasing through Github releases
-
-Matilda Code extensions can be distributed through [GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases). This provides a faster and more reliable initial installation experience for users, as it avoids the need to clone the repository.
-
-Each release includes at least one archive file, which contains the full contents of the repo at the tag that it was linked to. Releases may also include [pre-built archives](#custom-pre-built-archives) if your extension requires some build step or has platform specific binaries attached to it.
-
-When checking for updates, matilda code will just look for the latest release on github (you must mark it as such when creating the release), unless the user installed a specific release by passing `--ref=<some-release-tag>`. We do not at this time support opting in to pre-release releases or semver.
-
-### Custom pre-built archives
-
-Custom archives must be attached directly to the github release as assets and must be fully self-contained. This means they should include the entire extension, see [archive structure](#archive-structure).
-
-If your extension is platform-independent, you can provide a single generic asset. In this case, there should be only one asset attached to the release.
-
-Custom archives may also be used if you want to develop your extension within a larger repository, you can build an archive which has a different layout from the repo itself (for instance it might just be an archive of a subdirectory containing the extension).
-
-#### Platform specific archives
-
-To ensure Matilda Code can automatically find the correct release asset for each platform, you must follow this naming convention. The CLI will search for assets in the following order:
-
-1.  **Platform and Architecture-Specific:** `{platform}.{arch}.{name}.{extension}`
-2.  **Platform-Specific:** `{platform}.{name}.{extension}`
-3.  **Generic:** If only one asset is provided, it will be used as a generic fallback.
-
-- `{name}`: The name of your extension.
-- `{platform}`: The operating system. Supported values are:
-  - `darwin` (macOS)
-  - `linux`
-  - `win32` (Windows)
-- `{arch}`: The architecture. Supported values are:
-  - `x64`
-  - `arm64`
-- `{extension}`: The file extension of the archive (e.g., `.tar.gz` or `.zip`).
-
-**Examples:**
-
-- `darwin.arm64.my-tool.tar.gz` (specific to Apple Silicon Macs)
-- `darwin.my-tool.tar.gz` (for all Macs)
-- `linux.x64.my-tool.tar.gz`
-- `win32.my-tool.zip`
-
-#### Archive structure
-
-Archives must be fully contained extensions and have all the standard requirements - specifically the `matilda-extension.json` file must be at the root of the archive.
-
-The rest of the layout should look exactly the same as a typical extension, see [extensions.md](extension.md).
-
-#### Example GitHub Actions workflow
-
-Here is an example of a GitHub Actions workflow that builds and releases a Matilda Code extension for multiple platforms:
-
-```yaml
-name: Release Extension
-
-on:
-  push:
-    tags:
-      - 'v*'
-
-jobs:
-  release:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v3
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v3
-        with:
-          node-version: '22'
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Build extension
-        run: npm run build
-
-      - name: Create release assets
-        run: |
-          npm run package -- --platform=darwin --arch=arm64
-          npm run package -- --platform=linux --arch=x64
-          npm run package -- --platform=win32 --arch=x64
-
-      - name: Create GitHub Release
-        uses: softprops/action-gh-release@v1
-        with:
-          files: |
-            release/darwin.arm64.my-tool.tar.gz
-            release/linux.arm64.my-tool.tar.gz
-            release/win32.arm64.my-tool.zip
-```
-
-## Releasing through npm registry
-
-You can publish Matilda Code extensions as scoped npm packages (e.g. `@your-org/my-extension`). This is a good fit when:
-
-- Your team already uses npm for package distribution
-- You need private registry support with existing auth infrastructure
-- You want version resolution and access control handled by npm
-
-### Package requirements
-
-Your npm package must include a `matilda-extension.json` file at the package root. This is the same config file used by all Matilda Code extensions — the npm tarball is simply another delivery mechanism.
-
-A minimal package structure looks like:
-
-```
-my-extension/
-├── package.json
-├── matilda-extension.json
-├── MATILDA.md              # optional context file
-├── commands/             # optional custom commands
-├── skills/               # optional custom skills
-└── agents/               # optional custom subagents
-```
-
-Make sure `matilda-extension.json` is included in your published package (i.e. not excluded by `.npmignore` or the `files` field in `package.json`).
-
-### Publishing
-
-Use standard npm publishing tools:
-
-```bash
-# Publish to the default registry
-npm publish
-
-# Publish to a private/custom registry
-npm publish --registry https://your-registry.com
-```
-
-### Installation
-
-Users install your extension using the scoped package name:
-
-```bash
-# Install latest version
-matilda extensions install @your-org/my-extension
-
-# Install a specific version
-matilda extensions install @your-org/my-extension@1.2.0
-
-# Install from a custom registry
-matilda extensions install @your-org/my-extension --registry https://your-registry.com
-```
-
-### Update behavior
-
-- Extensions installed without a version pin (e.g. `@scope/pkg`) track the `latest` dist-tag.
-- Extensions installed with a dist-tag (e.g. `@scope/pkg@beta`) track that specific tag.
-- Extensions pinned to an exact version (e.g. `@scope/pkg@1.2.0`) are always considered up-to-date and will not prompt for updates.
-
-### Authentication for private registries
-
-Matilda Code reads npm auth credentials automatically:
-
-1. **`NPM_TOKEN` environment variable** — highest priority
-2. **`.npmrc` file** — supports both host-level and path-scoped `_authToken` entries (e.g. `//your-registry.com/:_authToken=TOKEN` or `//pkgs.dev.azure.com/org/_packaging/feed/npm/registry/:_authToken=TOKEN`)
-
-`.npmrc` files are read from the current directory and the user's home directory.
-
-### Managing release channels
-
-You can use npm dist-tags to manage release channels:
-
-```bash
-# Publish a beta release
-npm publish --tag beta
-
-# Users install beta channel
-matilda extensions install @your-org/my-extension@beta
-```
-
-This works similarly to git branch-based release channels but uses npm's native dist-tag mechanism.