Feature/add mimo provider

[SiYue-ZO]

📝 Description

This PR adds support for Xiaomi MiMo model provider to PicoClaw.

MiMo is Xiaomi's AI assistant model that provides an OpenAI-compatible API. This integration allows users to easily configure and use MiMo models within PicoClaw.

Changes included in this PR:

Backend:

• Add mimo protocol prefix support in factory_provider.go

• Add default API base URL: https://api.xiaomimimo.com/v1
  Frontend:

• Add MiMo label to provider-label.ts

• Add MiMo to PROVIDER_PRIORITY in models-page.tsx for proper sorting

• Add MiMo domain ( xiaomi.com ) to provider-icon.tsx for icon display
  Documentation:

• Update provider tables in both English ( docs/providers.md ) and Chinese ( docs/zh/providers.md ) documentation
  Tests:

• Add unit tests for MiMo provider creation and default API base URL

Usage:

Users can now use MiMo by adding the following configuration:

{
  "model_name": "mimo",
  "model": "mimo/mimo-v2-pro",
  "api_key": "your-mimo-api-key"
}

🗣️ Type of Change

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

Adds Xiaomi MiMo provider support

📚 Technical Context

API Compatibility: MiMo API is compatible with OpenAI API format, making it easy to integrate with the existing HTTPProvider infrastructure.

Authentication: MiMo uses api-key header for authentication (same as standard OpenAI-compatible APIs).

Reference URL: https://platform.xiaomimimo.com/#/docs/quick-start/first-api-call

🧪 Test Environment

• Hardware: PC
• OS: Linux
• Model/Provider: Xiaomi MiMo (mimo-v2-pro)
• Channels: N/A

📋 Checklist

• Code follows the project's style guidelines
• Documentation has been updated

[yinwm]

🔒 Security Issue: Sensitive Files Exposed

This PR includes files that should not be committed to the repository:

Files to Remove

File	Issue
	Contains exposed token ()
	520-line local config file with internal configuration details

Recommended Actions

1. Remove these files from the PR:

   git rm .security.yml onboard
   git commit --amend
   git push -f

2. Add to .gitignore:

   .security.yml
   onboard
   

3. Rotate the exposed token if it is still valid.

---

Note on Core Changes

The actual MiMo provider implementation looks correct - this is purely about the sensitive files that shouldn't be in the repo.

[SiYue-ZO]

sorry, I will fix it

[SiYue-ZO]

I have fix and git commit -m "Add .security.yml and onboard to .gitignore"

[alexhoshina]

I suggest using .git/info/exclude to manage your local Git exclusions. It can replace .gitignore and won't be shared.

[SiYue-ZO]

I suggest using .git/info/exclude to manage your local Git exclusions. It can replace .gitignore and won't be shared.

regarding the .gitignore change, I’d like to clarify my reasoning.

These files are generated locally when running ./build/picoclaw-launcher onboard, and they may contain environment-specific or sensitive information. Since they are recreated automatically during build/runtime, they don’t need to be tracked in the repository.

If we don’t add them to .gitignore, they will keep showing up as untracked files after each build, which increases the risk of accidentally committing them.

Adding them to .gitignore is mainly to prevent accidental commits of sensitive or machine-specific data, and it won’t affect the build or runtime behavior of the project.

🤔

[alexhoshina]

I suggest using .git/info/exclude to manage your local Git exclusions. It can replace .gitignore and won't be shared.

regarding the .gitignore change, I’d like to clarify my reasoning.

These files are generated locally when running ./build/picoclaw-launcher onboard, and they may contain environment-specific or sensitive information. Since they are recreated automatically during build/runtime, they don’t need to be tracked in the repository.

If we don’t add them to .gitignore, they will keep showing up as untracked files after each build, which increases the risk of accidentally committing them.

Adding them to .gitignore is mainly to prevent accidental commits of sensitive or machine-specific data, and it won’t affect the build or runtime behavior of the project.

🤔

你好像是中国开发者，我直接用中文吧。
我明白 .gitignore 修改的理由， 至少目前看来这是我第一次看到有人提交的内容携带onboard产生的文件。所以我认为这个排除配置是不需要进行共享的。
对于不需要共享的排除项我更推荐使用.git/info/exclude，这个文件的作用与 .gitignore 相同，唯一的区别是.git/info/exclude不会被git跟踪，所以不会共享给仓库的其他开发者。
🫡这个事情不会阻塞合并，只是作为一个tips。使用 .gitignore 也可以避免以后有开发者对这些私有文件进行跟踪。

[SiYue-ZO]

I suggest using .git/info/exclude to manage your local Git exclusions. It can replace .gitignore and won't be shared.

regarding the .gitignore change, I’d like to clarify my reasoning.
These files are generated locally when running ./build/picoclaw-launcher onboard, and they may contain environment-specific or sensitive information. Since they are recreated automatically during build/runtime, they don’t need to be tracked in the repository.
If we don’t add them to .gitignore, they will keep showing up as untracked files after each build, which increases the risk of accidentally committing them.
Adding them to .gitignore is mainly to prevent accidental commits of sensitive or machine-specific data, and it won’t affect the build or runtime behavior of the project.
🤔

你好像是中国开发者，我直接用中文吧。 我明白 .gitignore 修改的理由， 至少目前看来这是我第一次看到有人提交的内容携带onboard产生的文件。所以我认为这个排除配置是不需要进行共享的。 对于不需要共享的排除项我更推荐使用.git/info/exclude，这个文件的作用与 .gitignore 相同，唯一的区别是.git/info/exclude不会被git跟踪，所以不会共享给仓库的其他开发者。 🫡这个事情不会阻塞合并，只是作为一个tips。使用**.gitignore**也可以避免以后有开发者对这些私有文件进行跟踪。

好的，我理解了，我的git使用还不熟练，非常感谢你的回复和建议！最初我也很疑惑为什么onboard会生成在项目目录下，我会尝试解决解决这个问题。

[alexhoshina]

在我目前的开发流程中 我更习惯直接使用make install，然后直接使用picoclaw onboard或者启动网关，这样可以避免在仓库下产生相关的配置文件。