feat(v3.12.0): media pipeline, AI image generation, capability probe, companion v2.9.0
Three-month batch sync from internal repo (~80 commits) covering Tracks F.5a, F.7e, F.8, F.17, F.18, F.X. WordPress media pipeline - Pillow-based optimization, AI image generation (OpenAI / Stability / Replicate / Google Nano Banana / OpenRouter), chunked + resumable uploads, bulk delete/reassign, idempotent retries. Capability discovery (F.7e) - Per-site credential probe + adapters for WordPress / WooCommerce / Gitea, tier-fit unions granted ∪ roles, capability badge UI with HTMX partial re-check, install hint in every companion-unreachable error. Companion plugin overhaul - Renamed wordpress-plugin/airano-mcp-seo-bridge → wordpress-plugin/airano-mcp-bridge. - Eight new endpoints: /capabilities, /bulk-meta, /export, /cache-purge, /transient-flush, /site-health, /audit-hook, /upload-and-attach. - wp.org Plugin Check pass: i18n, WP_Filesystem, scheme allowlist on audit-hook URL. Other - Gitea ergonomics (F.17): batch files, tree, search, compare, releases, fork. - Opportunistic bcrypt upgrade for legacy SHA-256 admin keys (F.8). - n8n refactor: structured errors, capability probe, missing tools backfilled. - Idempotency-Key dedup for AI media upload retries; WP client fast-fails on unreachable sites. Docs - README + CLAUDE.md drop the fixed "633 tools" claim. The total grows with each release; per-plugin approximations + dashboard-surfaced counts replace it. - Tools/Tests badges removed in favour of "Plugins: 10". Deployment - PyPI mirror chain, optional BUILD_HTTP_PROXY, Alpine→Yandex apk mirror, Debian-slim Plan-B Dockerfile, mirror.gcr.io variant. CI - Black + Ruff clean on Python 3.12; pytest tests/ green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -57,7 +57,7 @@ Your personal MCP endpoint:
|
||||
https://mcp.example.com/u/{your-user-id}/{alias}/mcp
|
||||
```
|
||||
|
||||
**WordPress users:** Install the [Airano MCP SEO Bridge](https://wordpress.org/plugins/airano-mcp-seo-bridge/) plugin for SEO tools, and create an [Application Password](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/) (Users → Profile) for authentication.
|
||||
**WordPress users:** Install the [Airano MCP SEO Bridge](https://wordpress.org/plugins/airano-mcp-bridge/) plugin for SEO tools, and create an [Application Password](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/) (Users → Profile) for authentication.
|
||||
|
||||
> If you prefer self-hosting, continue with the options below.
|
||||
|
||||
|
||||
97
docs/media-error-codes.md
Normal file
97
docs/media-error-codes.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# Media Upload Error Codes (F.5a.6.2)
|
||||
|
||||
All media-upload tools return structured JSON errors shaped as:
|
||||
|
||||
```json
|
||||
{
|
||||
"error_code": "TOO_LARGE",
|
||||
"message": "File is 12345678 bytes; limit is 10485760 bytes ...",
|
||||
"details": { "size": 12345678, "max": 10485760 }
|
||||
}
|
||||
```
|
||||
|
||||
The `error_code` values below are **stable**: renaming or removing one is
|
||||
a breaking change. The source of truth is
|
||||
[`core/media_error_codes.py`](../core/media_error_codes.py) (the set
|
||||
`MEDIA_ERROR_CODES`) and the stability test in
|
||||
[`tests/plugins/wordpress/test_media_error_taxonomy.py`](../tests/plugins/wordpress/test_media_error_taxonomy.py).
|
||||
|
||||
## Input / validation
|
||||
|
||||
| Code | When it fires |
|
||||
| ----------------- | ------------------------------------------------------------------------------------- |
|
||||
| `BAD_BASE64` | The supplied base64 payload (full upload or single chunk) fails to decode. |
|
||||
| `BAD_MODE` | `mode` argument to attach tools is not `append` or `replace`. |
|
||||
| `BAD_ROLE` | `role` argument to attach tools is not `main` or `gallery`. |
|
||||
| `BAD_SIZE` | Chunked `total_bytes` is `<= 0`. |
|
||||
| `BAD_SOURCE` | Attach-upload helper given a `source` other than `base64` / `url`. |
|
||||
| `EMPTY_FILE` | Decoded payload is zero bytes. |
|
||||
| `MEDIA_NOT_FOUND` | A supplied `media_id` does not exist in the WP media library. |
|
||||
| `MIME_REJECTED` | Sniffed MIME is not in the allow-list (`ALLOWED_MIMES`). |
|
||||
| `MISSING_FIELD` | A required field is missing (e.g. `data` for base64, `url` for URL sideload). |
|
||||
| `SSRF` | URL resolves to private/loopback/link-local/metadata IP or is on the host blocklist. |
|
||||
| `TOO_LARGE` | Payload exceeds `WP_MEDIA_MAX_MB` / streamed download exceeds the byte cap. |
|
||||
| `URL_FETCH_FAILED`| Remote URL returned `>= 400` while downloading. |
|
||||
|
||||
## WordPress REST upstream
|
||||
|
||||
| Code | When it fires |
|
||||
| ----------------- | ------------------------------------------------------------------------------------- |
|
||||
| `WP_413` | WordPress rejected the upload with HTTP 413 (server `upload_max_filesize` too low). |
|
||||
| `WP_AUTH` | WordPress rejected auth (401/403). Application Password likely invalid/expired. |
|
||||
| `WP_BAD_RESPONSE` | Upload accepted but WP returned a non-JSON body. |
|
||||
| `WP_CREDENTIALS_MISSING` | (WC sites only) Tool needs a WP Application Password to hit `/wp/v2/media`. WC Consumer Key + Secret do not authenticate the WP core REST. Add `wp_username` + `wp_app_password` in Connection Settings → advanced. |
|
||||
| `WP_<status>` | Any other non-2xx status from WP — e.g. `WP_400`, `WP_500`. Dynamic. |
|
||||
|
||||
## Companion plugin `upload-chunk` route (F.5a.7)
|
||||
|
||||
These only fire when MCPHub chose the companion `/airano-mcp/v1/upload-chunk` route
|
||||
(because the probe advertises the helper and the payload exceeds `upload_max_filesize`).
|
||||
A companion failure is **non-fatal**: MCPHub falls back to the standard `/wp/v2/media`
|
||||
route on any error here, so these codes usually surface in logs, not to end users.
|
||||
|
||||
| Code | When it fires |
|
||||
| ------------------------ | --------------------------------------------------------------------- |
|
||||
| `COMPANION_BAD_RESPONSE` | Companion route returned 2xx but the body was not parseable JSON. |
|
||||
| `COMPANION_<status>` | Any non-2xx status from the companion route — e.g. `COMPANION_500`. |
|
||||
|
||||
## Chunked upload session
|
||||
|
||||
| Code | When it fires |
|
||||
| ------------------- | ---------------------------------------------------------------------------- |
|
||||
| `BAD_STATE` | Session exists but is not in `open` state (already finalized/aborted). |
|
||||
| `CHECKSUM_MISMATCH` | Assembled sha256 does not match value supplied at `start`. |
|
||||
| `CHUNK_CHECKSUM` | Per-chunk sha256 does not match the value supplied with the chunk. |
|
||||
| `CHUNK_ORDER` | Chunk index does not match `next_chunk`. |
|
||||
| `CHUNK_OVERFLOW` | Appending this chunk would exceed declared `total_bytes`. |
|
||||
| `EXPIRED` | Session's TTL has elapsed. |
|
||||
| `INCOMPLETE` | Finalize called before all declared bytes arrived. |
|
||||
| `NO_SESSION` | `session_id` is unknown. |
|
||||
| `QUOTA_EXCEEDED` | User already has `MCPHUB_UPLOAD_MAX_CONCURRENT` open sessions. |
|
||||
| `SESSION_TOO_LARGE` | Declared `total_bytes` exceeds the hard session cap (default 500 MB). |
|
||||
|
||||
## AI generation providers
|
||||
|
||||
| Code | When it fires |
|
||||
| ----------------------- | ---------------------------------------------------------------------- |
|
||||
| `GENERATION_FAILED` | Generic provider failure not covered by a more specific code. |
|
||||
| `NO_PROVIDER_KEY` | No per-user key stored and no env fallback for the selected provider. |
|
||||
| `PROVIDER_AUTH` | Provider rejected the supplied API key. |
|
||||
| `PROVIDER_BAD_REQUEST` | Provider returned 4xx — prompt or size was invalid. |
|
||||
| `PROVIDER_BAD_RESPONSE` | Provider returned a 2xx with an unexpected shape. |
|
||||
| `PROVIDER_QUOTA` | Provider returned 429 / quota error. |
|
||||
| `PROVIDER_TIMEOUT` | Provider timed out. |
|
||||
| `PROVIDER_UNAVAILABLE` | Provider returned 5xx / circuit open. |
|
||||
| `PROVIDER_UNKNOWN` | `provider` argument is not one of the registered providers. |
|
||||
|
||||
## Rate / policy
|
||||
|
||||
| Code | When it fires |
|
||||
| -------------------- | --------------------------------------------------------------------- |
|
||||
| `TOOL_RATE_LIMITED` | Per-tool, per-user cap exceeded (see `core/tool_rate_limiter.py`). |
|
||||
|
||||
## Catchall
|
||||
|
||||
| Code | When it fires |
|
||||
| ---------- | ---------------------------------------------------------------------------------- |
|
||||
| `INTERNAL` | Unexpected exception reached the top of a tool handler. Details in `message`. |
|
||||
@@ -1,90 +0,0 @@
|
||||
# F.16 — Gitea Plugin Review, Test & Public Release
|
||||
|
||||
> Session prompt. Copy and paste into a new Claude Code conversation.
|
||||
|
||||
---
|
||||
|
||||
## Prompt:
|
||||
|
||||
```
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. پروژه mcphub-internal روی branch Phase-1 است.
|
||||
فایلهای مرجع:
|
||||
- docs/plans/2026-03-25-v4-development-cycle.md
|
||||
- CLAUDE.md
|
||||
- CHANGELOG.md
|
||||
|
||||
## وضعیت فعلی
|
||||
- نسخه: v3.5.0
|
||||
- 565 ابزار در 9 پلاگین (4 پلاگین عمومی: WordPress, WooCommerce, Supabase, OpenPanel)
|
||||
- FastMCP: `>=3.0.0,<4.0.0`
|
||||
- CI سبز
|
||||
- F.15 تکمیل شده — FastMCP 3.x upgrade + legacy cleanup
|
||||
|
||||
## هدف: فاز F.16 — Gitea Plugin Review, Test & Public Enablement
|
||||
|
||||
مشابه F.10 (OpenPanel) — بررسی، تست و فعالسازی عمومی پلاگین Gitea.
|
||||
|
||||
### بخش 1: بررسی و تحلیل
|
||||
1. **ساختار پلاگین**: `plugins/gitea/` شامل 56 ابزار در 5 هندلر:
|
||||
- `handlers/repositories.py` — 16 tools (CRUD repos, branches, tags, files)
|
||||
- `handlers/issues.py` — 12 tools (issues, comments, labels, milestones)
|
||||
- `handlers/pull_requests.py` — 15 tools (PRs, reviews, merge, diff)
|
||||
- `handlers/users.py` — 8 tools (users, orgs, teams)
|
||||
- `handlers/webhooks.py` — 5 tools (CRUD webhooks, test)
|
||||
2. **مشکلات شناساییشده**:
|
||||
- `update_webhook` در client.py هست ولی به عنوان tool expose نشده
|
||||
- هیچ تست اختصاصیای ندارد (0 تست!)
|
||||
- فعلاً admin-only هست (نه در ENABLED_PLUGINS)
|
||||
3. **تست واقعی**: سایت Gitea از MCPHub MCP endpoint:
|
||||
- از ابزارهای Supabase MCP (`mcp.example.com`) استفاده کنید تا سایت Gitea موجود را پیدا کنید
|
||||
- یا یک Gitea instance جدید از طریق داشبورد اضافه کنید
|
||||
- هر دسته tool را با API واقعی تست کنید
|
||||
|
||||
### بخش 2: تست نوشتن
|
||||
مشابه `tests/test_openpanel_plugin.py` (الگو — 767 خط, 62 تست):
|
||||
1. `tests/test_gitea_plugin.py` بنویسید:
|
||||
- Client initialization + health check
|
||||
- Tool spec validation (نامها، پارامترها، type ها)
|
||||
- Handler delegation (mock client)
|
||||
- Error handling
|
||||
- Pagination
|
||||
2. هدف: حداقل 80 تست (56 tool + edge cases)
|
||||
|
||||
### بخش 3: رفع مشکلات
|
||||
1. `update_webhook` را به عنوان tool expose کنید
|
||||
2. هر tool که در تست واقعی مشکل دارد را fix کنید
|
||||
3. توضیحات service page برای Gitea بنویسید
|
||||
4. health check endpoint را بررسی کنید
|
||||
|
||||
### بخش 4: فعالسازی عمومی
|
||||
1. `core/plugin_visibility.py`: اضافه کردن `gitea` به `DEFAULT_PUBLIC_PLUGINS`
|
||||
2. `env.example`: آپدیت ENABLED_PLUGINS default
|
||||
3. `glama.json`: آپدیت description اگر لازمه
|
||||
|
||||
### بخش 5: Release
|
||||
1. Version bump: `3.5.0` → `3.6.0`
|
||||
2. CHANGELOG update
|
||||
3. Lint: `uvx --python 3.12 black .` && `uvx ruff check --fix .`
|
||||
4. Commit + push Phase-1
|
||||
5. Sync: `python3.11 scripts/community-build/sync.py --output ../mcphub/`
|
||||
6. بعد از sync حتماً `uvx --python 3.12 black .` در public repo هم بزنید!
|
||||
7. Commit + push public repo
|
||||
|
||||
### مراحل پیشنهادی
|
||||
1. **تحلیل**: خواندن کامل هر handler + client + schemas
|
||||
2. **تست واقعی**: اتصال به Gitea instance و تست ابزارها
|
||||
3. **پلن اجرایی**: ارائه پلن و تایید قبل از شروع
|
||||
4. **تست نوشتن**: test_gitea_plugin.py
|
||||
5. **رفع مشکلات**: fix هر tool مشکلدار
|
||||
6. **فعالسازی**: ENABLED_PLUGINS update
|
||||
7. **Release**: v3.6.0
|
||||
|
||||
### نکات فنی
|
||||
- Private repo: /config/workspace/mcphub-internal (branch Phase-1)
|
||||
- Public repo: /config/workspace/mcphub (branch main)
|
||||
- Lint: `uvx --python 3.12 black .` && `uvx ruff check --fix .`
|
||||
- Sync: `python3.11 scripts/community-build/sync.py --output ../mcphub/`
|
||||
- ایمیل git عمومی: hi.airano@gmail.com
|
||||
- **مهم**: اول پلن بده، بدون تایید شروع نکن
|
||||
- **الگوی مرجع**: F.10 (OpenPanel) — بخش "Phase F.10" در plan و `tests/test_openpanel_plugin.py`
|
||||
```
|
||||
@@ -1,95 +0,0 @@
|
||||
# Next Session — F.17 Coolify MCP Plugin (MVP)
|
||||
|
||||
> Session prompt. Copy and paste into a new Claude Code conversation.
|
||||
|
||||
---
|
||||
|
||||
## Prompt:
|
||||
|
||||
```
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## فایلهای مرجع
|
||||
- docs/plans/2026-04-02-coolify-mcp-plugin-design.md (mcphub-internal) ← طرح کامل پلاگین
|
||||
- docs/plans/2026-03-25-v4-development-cycle.md (mcphub-internal, branch Phase-1) ← فاز F.17
|
||||
- CLAUDE.md (mcphub-internal)
|
||||
- plugins/gitea/ (mcphub-internal) ← الگوی مرجع (آخرین پلاگین ساختهشده)
|
||||
- plugins/base.py (mcphub-internal) ← BasePlugin interface
|
||||
|
||||
## وضعیت فعلی
|
||||
- MCPHub: v3.6.0 — 566 ابزار، 5 پلاگین عمومی
|
||||
- FastMCP: >=3.0.0,<4.0.0
|
||||
- CI سبز
|
||||
- طرح Coolify: نوشته شده — ~68 ابزار در 6 handler
|
||||
|
||||
## ریپازیتوری
|
||||
- MCPHub (internal): `/config/workspace/mcphub-internal` (branch Phase-1)
|
||||
|
||||
## هدف session: F.17 Phase 1 — Coolify MVP
|
||||
|
||||
### پیشنیاز اول: Coolify API Token
|
||||
- [ ] در داشبورد Coolify، بخش Keys & Tokens، یک API token بساز
|
||||
- [ ] تست اتصال: `curl -s https://COOLIFY_URL/api/v1/version -H "Authorization: Bearer TOKEN"`
|
||||
- [ ] اگر URL و TOKEN مشخص نبود، از کاربر بپرس
|
||||
|
||||
### مرحله ۱: ساختار اولیه پلاگین
|
||||
- [ ] `plugins/coolify/__init__.py` (خالی)
|
||||
- [ ] `plugins/coolify/client.py` — CoolifyClient با Bearer Token auth
|
||||
- الگو از `plugins/gitea/client.py` بگیر
|
||||
- متدها: `request()`, `get()`, `post()`, `patch()`, `delete()`
|
||||
- Error handling + retry مشابه Gitea client
|
||||
- [ ] `plugins/coolify/plugin.py` — CoolifyPlugin(BasePlugin)
|
||||
- الگو از `plugins/gitea/plugin.py` بگیر
|
||||
- `get_tool_specifications()` باید ابزارهای handler ها رو جمع کنه
|
||||
- [ ] `plugins/coolify/handlers/__init__.py`
|
||||
- [ ] `plugins/coolify/schemas/__init__.py`
|
||||
- [ ] `plugins/coolify/schemas/common.py` — مدلهای مشترک (UUID, pagination)
|
||||
|
||||
### مرحله ۲: Handler — Applications (18 ابزار)
|
||||
- [ ] `plugins/coolify/handlers/applications.py`
|
||||
- [ ] ابزارها (از طرح):
|
||||
- list_applications, get_application
|
||||
- create_application_public, create_application_dockerfile, create_application_docker_image, create_application_compose
|
||||
- update_application, delete_application
|
||||
- start_application, stop_application, restart_application
|
||||
- get_application_logs
|
||||
- list_application_envs, create_application_env, update_application_env, update_application_envs_bulk, delete_application_env
|
||||
- [ ] schemas/application.py — Pydantic models
|
||||
|
||||
### مرحله ۳: Handler — Deployments (5 ابزار)
|
||||
- [ ] `plugins/coolify/handlers/deployments.py`
|
||||
- [ ] ابزارها: list_deployments, get_deployment, cancel_deployment, deploy, list_app_deployments
|
||||
|
||||
### مرحله ۴: Handler — Servers (8 ابزار)
|
||||
- [ ] `plugins/coolify/handlers/servers.py`
|
||||
- [ ] ابزارها: list_servers, get_server, create_server, update_server, delete_server, get_server_resources, get_server_domains, validate_server
|
||||
- [ ] schemas/server.py
|
||||
|
||||
### مرحله ۵: ثبت پلاگین و تنظیمات
|
||||
- [ ] در `plugins/__init__.py` اضافه کن: `from plugins.coolify.plugin import CoolifyPlugin` + `registry.register("coolify", CoolifyPlugin)`
|
||||
- [ ] در `env.example` اضافه کن: `COOLIFY_URL`, `COOLIFY_TOKEN`
|
||||
- [ ] پلاگین فعلا admin-only باشد (به ENABLED_PLUGINS اضافه نشود)
|
||||
|
||||
### مرحله ۶: تست
|
||||
- [ ] `tests/test_coolify.py` — Unit tests با mocked HTTP
|
||||
- الگو از `tests/test_gitea*.py` بگیر
|
||||
- حداقل: test_list_applications, test_get_application, test_deploy, test_list_servers
|
||||
- [ ] `pytest tests/test_coolify.py -v`
|
||||
- [ ] اگر API Token موجود بود: integration test با Coolify واقعی
|
||||
|
||||
### مرحله ۷: تست نهایی و commit
|
||||
- [ ] `uvx --python 3.12 black .`
|
||||
- [ ] `uvx ruff check --fix .`
|
||||
- [ ] `pytest` (همه تستها سبز)
|
||||
- [ ] Commit: `feat(F.17): add Coolify MCP plugin — Phase 1 MVP (~31 tools)`
|
||||
- [ ] Push to Phase-1
|
||||
|
||||
## قوانین
|
||||
- اول پلن بده، بدون تایید شروع نکن
|
||||
- از Gitea plugin به عنوان الگوی اصلی استفاده کن (آخرین و تمیزترین پلاگین)
|
||||
- هر مرحله commit شود
|
||||
- tool specifications باید دقیقا مطابق فرمت BasePlugin باشند (name, method_name, description, schema, scope)
|
||||
- scope ها: read, write, admin — مطابق جدول در طرح
|
||||
- حافظه آپدیت شود بعد از اتمام
|
||||
- ایمیل git داخلی: mcphub.dev@gmail.com
|
||||
```
|
||||
@@ -1,77 +0,0 @@
|
||||
# Next Session — Coolify MCP Plugin Testing & Next Steps
|
||||
|
||||
> Session prompt. Copy and paste into a new Claude Code conversation.
|
||||
|
||||
---
|
||||
|
||||
## Prompt:
|
||||
|
||||
```
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## هدف: تست پلاگین Coolify MCP و مراحل بعدی
|
||||
|
||||
### پیشنیاز
|
||||
- MCPHub redeploy شده و سایت Coolify اضافه شده
|
||||
- MCP endpoint `mcphub-coolify` در `.claude.json` تنظیم شده
|
||||
- پلاگین 30 ابزار دارد (17 application + 5 deployment + 8 server)
|
||||
|
||||
### مرحله ۱: تأیید اتصال MCP
|
||||
- [ ] لیست ابزارهای coolify را از MCP بگیر (باید 30 ابزار باشد)
|
||||
- [ ] اگر ابزار coolify در لیست نبود، `.claude.json` و `settings.json` را بررسی کن
|
||||
|
||||
### مرحله ۲: تست ابزارهای read
|
||||
- [ ] `coolify_list_servers` — لیست سرورها
|
||||
- [ ] `coolify_list_applications` — لیست اپلیکیشنها
|
||||
- [ ] `coolify_list_deployments` — لیست دیپلویمنتهای در حال اجرا
|
||||
- [ ] `coolify_get_server_resources(uuid=SERVER_UUID)` — منابع سرور
|
||||
- [ ] `coolify_get_server_domains(uuid=SERVER_UUID)` — دامنههای سرور
|
||||
- [ ] یک اپلیکیشن انتخاب کن و:
|
||||
- [ ] `coolify_get_application(uuid=APP_UUID)` — جزئیات
|
||||
- [ ] `coolify_get_application_logs(uuid=APP_UUID, lines=50)` — لاگها
|
||||
- [ ] `coolify_list_application_envs(uuid=APP_UUID)` — متغیرهای محیطی
|
||||
- [ ] `coolify_list_app_deployments(uuid=APP_UUID)` — تاریخچه دیپلوی
|
||||
|
||||
### مرحله ۳: تست ابزارهای write (با احتیاط)
|
||||
- [ ] از کاربر بپرس آیا مجاز است یک env var تست ایجاد/حذف کند
|
||||
- [ ] اگر بله:
|
||||
- [ ] `coolify_create_application_env(uuid=APP_UUID, key="TEST_VAR", value="test123")`
|
||||
- [ ] `coolify_delete_application_env(uuid=APP_UUID, env_uuid=...)`
|
||||
|
||||
### مرحله ۴: گزارش نتایج
|
||||
- [ ] خلاصه نتایج تست (چند ابزار کار کرد، مشکلات)
|
||||
- [ ] مقایسه با ابزارهای Gitea و Supabase MCP (کیفیت پاسخها)
|
||||
|
||||
### مرحله ۵: اگر تست موفق بود — Sync به نسخه عمومی
|
||||
- [ ] `python3.11 scripts/community-build/sync.py --output ../mcphub/`
|
||||
- [ ] `cd /config/workspace/mcphub && uvx --python 3.12 black . && uvx ruff check --fix .`
|
||||
- [ ] تستها: `python3.11 -m pytest tests/ -q`
|
||||
- [ ] Commit و push نسخه عمومی
|
||||
|
||||
### مرحله ۶: آپدیتها
|
||||
- [ ] mcp-skills/skills/coolify/SKILL.md — از planned به active تغییر کرده (بررسی شود)
|
||||
- [ ] حافظه آپدیت شود
|
||||
|
||||
## پیشنهاد مراحل بعدی (بعد از تست)
|
||||
|
||||
### فوری
|
||||
1. **F.17 Phase 2**: اضافه کردن databases (16 ابزار) + services (13 ابزار) → ~59 ابزار کل
|
||||
2. **F.17 Phase 3**: projects (8 ابزار) → ~67 ابزار کل — تکمیل طرح اصلی
|
||||
|
||||
### میانمدت
|
||||
3. **Coolify Workflow Skill**: مهارت اختصاصی برای عملیات متداول (deploy all, backup all, health check all)
|
||||
4. **Integration Test**: تست خودکار با Coolify واقعی (pytest mark integration)
|
||||
5. **F.14a**: ثبت MCPHub در Smithery + Official MCP Registry
|
||||
|
||||
### بلندمدت
|
||||
6. **Blog Post**: نوشتن مقاله درباره "Self-hosted MCP Hub with Coolify Integration"
|
||||
7. **F.5a**: Base64 media upload برای WordPress
|
||||
8. **F.6**: Claude Code skills بومی
|
||||
|
||||
## قوانین
|
||||
- اول ابزارهای read تست شوند، بعد write
|
||||
- قبل از هر عملیات write از کاربر تأیید بگیر
|
||||
- نتایج تست دقیق گزارش شود (UUID ها، خطاها، زمان پاسخ)
|
||||
- حافظه آپدیت شود بعد از اتمام
|
||||
- ایمیل git داخلی: mcphub.dev@gmail.com
|
||||
```
|
||||
@@ -1,115 +0,0 @@
|
||||
# Next Session — F.17 Phase 3: Projects + Phase 2: Databases & Services
|
||||
|
||||
> Session prompt. Copy and paste into a new Claude Code conversation.
|
||||
|
||||
---
|
||||
|
||||
## Prompt:
|
||||
|
||||
```
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## فایلهای مرجع
|
||||
- docs/plans/2026-04-02-coolify-mcp-plugin-design.md (mcphub-internal) ← طرح کامل پلاگین
|
||||
- docs/plans/2026-03-25-v4-development-cycle.md (mcphub-internal) ← Phase F.17 آپدیت شده
|
||||
- plugins/coolify/ (mcphub-internal) ← پلاگین Phase 1 (الگوی اصلی)
|
||||
- plugins/gitea/ (mcphub-internal) ← الگوی مرجع معماری
|
||||
- CLAUDE.md (mcphub-internal)
|
||||
|
||||
## وضعیت فعلی
|
||||
- MCPHub: v3.7.0 — 596 ابزار، 10 پلاگین
|
||||
- Coolify Phase 1: ✅ 30 ابزار (17 app + 5 deploy + 8 server) — deployed, tested, synced
|
||||
- MCP endpoint فعال: mcphub-coolify در Claude Code (30 ابزار لود شده)
|
||||
- CI سبز، 718 تست (internal), 686 تست (public)
|
||||
|
||||
## ریپازیتوری
|
||||
- MCPHub (internal): `/config/workspace/mcphub-internal` (branch Phase-1)
|
||||
|
||||
## هدف session: F.17 Phase 3 + Phase 2
|
||||
|
||||
### بخش اول: Phase 3 — Projects & Environments (8 ابزار)
|
||||
> اولویت بالا — بدون project_uuid ساخت app/db/service بلاک است
|
||||
|
||||
#### مرحله ۱: Projects Handler
|
||||
- [ ] `plugins/coolify/handlers/projects.py`
|
||||
- [ ] ابزارها:
|
||||
- list_projects (GET /projects) — read
|
||||
- get_project (GET /projects/{uuid}) — read
|
||||
- create_project (POST /projects) — write
|
||||
- update_project (PATCH /projects/{uuid}) — write
|
||||
- delete_project (DELETE /projects/{uuid}) — admin
|
||||
- list_environments (GET /projects/{uuid}/environments) — read
|
||||
- get_environment (GET /projects/{uuid}/environments/{name}) — read
|
||||
- create_environment (POST /projects/{uuid}/environments) — write
|
||||
- [ ] متدهای client در `client.py` اضافه شود
|
||||
- [ ] در `handlers/__init__.py` ایمپورت projects اضافه شود
|
||||
- [ ] در `plugin.py` — specs و __getattr__ آپدیت شود
|
||||
|
||||
#### مرحله ۲: تست و دیپلوی Phase 3
|
||||
- [ ] `tests/test_coolify_projects.py` — Unit tests با mocked HTTP
|
||||
- [ ] `pytest tests/test_coolify*.py -v`
|
||||
- [ ] Commit: `feat(F.17): add projects handler — Phase 3 (8 tools)`
|
||||
- [ ] Push و درخواست redeploy
|
||||
- [ ] تست live: list_projects → پیدا کردن project_uuid
|
||||
- [ ] تست ساخت container: create_application_docker_image با project_uuid واقعی → دیپلوی nginx → تأیید → حذف
|
||||
|
||||
### بخش دوم: Phase 2 — Databases (16 ابزار)
|
||||
- [ ] `plugins/coolify/handlers/databases.py`
|
||||
- [ ] ابزارها:
|
||||
- list_databases, get_database — read
|
||||
- update_database — write
|
||||
- delete_database — admin
|
||||
- start_database, stop_database, restart_database — write
|
||||
- create_postgresql, create_mysql, create_mariadb — write
|
||||
- create_mongodb, create_redis, create_clickhouse — write
|
||||
- get_database_backups — read
|
||||
- create_database_backup — write
|
||||
- list_backup_executions — read
|
||||
- [ ] متدهای client اضافه شود
|
||||
- [ ] تست: `tests/test_coolify_databases.py`
|
||||
|
||||
### بخش سوم: Phase 2 — Services (13 ابزار)
|
||||
- [ ] `plugins/coolify/handlers/services.py`
|
||||
- [ ] ابزارها:
|
||||
- list_services, get_service — read
|
||||
- create_service — write
|
||||
- update_service — write
|
||||
- delete_service — admin
|
||||
- start_service, stop_service, restart_service — write
|
||||
- list_service_envs — read
|
||||
- create_service_env — write
|
||||
- update_service_env — write
|
||||
- update_service_envs_bulk — write
|
||||
- delete_service_env — write
|
||||
- [ ] متدهای client اضافه شود
|
||||
- [ ] تست: `tests/test_coolify_services.py`
|
||||
|
||||
### بخش چهارم: ثبت و تست نهایی
|
||||
- [ ] handlers/__init__.py آپدیت (projects, databases, services)
|
||||
- [ ] plugin.py آپدیت (specs + __getattr__)
|
||||
- [ ] server.py — نیازی به تغییر ندارد (coolify قبلا ثبت شده)
|
||||
- [ ] `uvx --python 3.12 black .`
|
||||
- [ ] `uvx ruff check --fix .`
|
||||
- [ ] `pytest` (همه تستها سبز)
|
||||
- [ ] Commit: `feat(F.17): add databases + services handlers — Phase 2 (29 tools)`
|
||||
- [ ] Push و درخواست redeploy
|
||||
- [ ] تست live: list_databases, list_services
|
||||
- [ ] آپدیت ورژن به v3.8.0 (اگر تأیید شد)
|
||||
|
||||
### بخش پنجم: Sync و داکیومنت
|
||||
- [ ] Sync به نسخه عمومی: `python3.11 scripts/community-build/sync.py --output ../mcphub/`
|
||||
- [ ] black + ruff + pytest در نسخه عمومی
|
||||
- [ ] README آپدیت (تعداد ابزار، جدول Coolify)
|
||||
- [ ] Commit و push نسخه عمومی
|
||||
- [ ] mcp-skills/skills/coolify/SKILL.md آپدیت (67 ابزار)
|
||||
- [ ] حافظه آپدیت شود
|
||||
- [ ] پلن آپدیت شود (Phase 2+3 complete)
|
||||
|
||||
## نکات مهم
|
||||
- server.py نیازی به تغییر ندارد — coolify قبلا register شده و generate_tools خودکار specs جدید رو میخونه
|
||||
- site_api.py نیازی به تغییر ندارد — credential fields و display name قبلا اضافه شده
|
||||
- الگوی handler: از applications.py کپی کن (آخرین و تمیزترین)
|
||||
- هر بخش (Phase 3, databases, services) جداگانه commit شود
|
||||
- قبل از هر عملیات write در تست live از کاربر تأیید بگیر
|
||||
- ایمیل git داخلی: mcphub.dev@gmail.com
|
||||
```
|
||||
@@ -1,136 +0,0 @@
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## فایلهای مرجع
|
||||
- docs/plans/2026-03-25-v4-development-cycle.md (mcphub-internal) ← Phase F.7 طراحی کامل
|
||||
- core/tool_generator.py (mcphub-internal) ← تولید ابزار فعلی
|
||||
- core/tool_registry.py (mcphub-internal) ← رجیستری ابزار
|
||||
- core/user_endpoints.py (mcphub-internal) ← فیلتر ابزار در endpoint کاربر
|
||||
- core/user_keys.py (mcphub-internal) ← سیستم API key کاربر
|
||||
- core/database.py (mcphub-internal) ← دیتابیس و مایگریشن
|
||||
- core/plugin_visibility.py (mcphub-internal) ← فیلتر پلاگین فعلی
|
||||
- core/dashboard/routes.py (mcphub-internal) ← روتهای داشبورد
|
||||
- server.py (mcphub-internal) ← middleware و scope enforcement
|
||||
- CLAUDE.md (mcphub-internal)
|
||||
|
||||
## وضعیت فعلی
|
||||
- MCPHub: v3.8.0 — 633 ابزار، 10 پلاگین، 67 ابزار Coolify
|
||||
- تستها: 766 (internal), 734 (public)
|
||||
- CI سبز
|
||||
- Scope فعلی: read/write/admin (سه سطح ساده)
|
||||
- فیلتر فعلی: فقط plugin-level (ENABLED_PLUGINS) — بدون per-tool toggle
|
||||
|
||||
## ریپازیتوری
|
||||
- MCPHub (internal): `/config/workspace/mcphub-internal` (branch Phase-1)
|
||||
|
||||
## هدف session: F.7 — Smart Tool Visibility & Scope-Based Access Control
|
||||
|
||||
### مشکلاتی که حل میشوند
|
||||
1. همه ابزارهای یک پلاگین فعال به همه کاربران نشان داده میشوند — کنترل per-tool نداریم
|
||||
2. وقتی کاربر API key با scope خاص (مثلا read) میسازد، باز هم همه ابزارها در tools/list نمایش داده میشوند
|
||||
3. ابزارهای وردپرس که نیاز به افزونههای کمکی دارند (SEO Bridge, WP-CLI) بدون بررسی prerequisite نشان داده میشوند
|
||||
4. کاربران نمیتوانند ابزارهایی که نیاز ندارند را غیرفعال کنند
|
||||
|
||||
### مدل scope پیشنهادی (گسترشیافته)
|
||||
فعلی: `read`, `write`, `admin`
|
||||
جدید:
|
||||
- `deploy` — عملیات lifecycle (start/stop/restart/deploy) + read
|
||||
- `read:sensitive` — read + لاگ، env var، بکاپ، connection string
|
||||
|
||||
**نگاشت scope → دستهبندی ابزار:**
|
||||
| Scope | ابزارها |
|
||||
|-------|---------|
|
||||
| `read` | list_*, get_* (بدون sensitive) |
|
||||
| `read:sensitive` | read + *_logs, *_envs, *_backups |
|
||||
| `deploy` | read + start_*, stop_*, restart_*, deploy |
|
||||
| `write` | deploy + create_*, update_*, delete_*_env |
|
||||
| `admin` | write + delete_* (منابع)، create_server |
|
||||
|
||||
### بخش اول: Core — ساختار داده و مدیریت دسترسی (بدون UI)
|
||||
|
||||
#### مرحله ۱: دیتابیس
|
||||
- [ ] جدول `user_tool_toggles` در `core/database.py`
|
||||
```sql
|
||||
CREATE TABLE user_tool_toggles (
|
||||
id TEXT PRIMARY KEY, user_id TEXT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
|
||||
tool_name TEXT NOT NULL, enabled INTEGER NOT NULL DEFAULT 1,
|
||||
reason TEXT, updated_at TEXT NOT NULL, UNIQUE(user_id, tool_name)
|
||||
);
|
||||
```
|
||||
- [ ] جدول `scope_presets` — پریستهای scope سیستمی + سفارشی
|
||||
- [ ] Migration اجرا شود
|
||||
|
||||
#### مرحله ۲: ماژول tool_access.py
|
||||
- [ ] `core/tool_access.py` — کلاس `ToolAccessManager`
|
||||
- [ ] `get_visible_tools(user_id, scopes, plugin_type)` → لیست فیلتر شده
|
||||
- [ ] `apply_scope_filter(tools, scopes)` → فقط ابزارهای مجاز بر اساس scope
|
||||
- [ ] `apply_user_toggles(tools, user_id)` → اعمال toggleهای کاربر
|
||||
- [ ] `toggle_tool(user_id, tool_name, enabled)` → ذخیره تنظیم
|
||||
- [ ] `bulk_toggle_by_scope(user_id, scope_name)` → فعال/غیرفعال دستهجمعی
|
||||
|
||||
#### مرحله ۳: Tool metadata enhancement
|
||||
- [ ] اضافه کردن `sensitivity` و `category` به tool specs در handlerها:
|
||||
- `sensitivity`: "normal" | "sensitive" (لاگ، env، بکاپ)
|
||||
- `category`: "read" | "lifecycle" | "crud" | "env" | "backup" | "system"
|
||||
- [ ] شروع از Coolify (آخرین و تمیزترین) سپس سایر پلاگینها
|
||||
- [ ] ToolDefinition در tool_registry.py آپدیت شود
|
||||
|
||||
#### مرحله ۴: فیلتر در user_endpoints.py
|
||||
- [ ] `_get_tools_for_plugin()` از ToolAccessManager استفاده کند
|
||||
- [ ] Pipeline فیلتر:
|
||||
1. plugin_visibility (موجود)
|
||||
2. scope-to-tool mapping (جدید)
|
||||
3. user toggles (جدید)
|
||||
- [ ] Scope enforcement در middleware آپدیت شود (server.py)
|
||||
|
||||
#### مرحله ۵: تست
|
||||
- [ ] `tests/test_tool_access.py` — unit tests
|
||||
- [ ] تستهای scope mapping: key با scope "read" → فقط ابزارهای read
|
||||
- [ ] تستهای toggle: کاربر disable کرده → ابزار در tools/list نیست
|
||||
- [ ] تستهای integration: API key scope → فیلتر واقعی
|
||||
|
||||
### بخش دوم: API — روتهای مدیریت toggle
|
||||
|
||||
- [ ] `GET /api/user/tools` — لیست ابزارها با وضعیت toggle
|
||||
- [ ] `PATCH /api/user/tools/{tool_name}` — تغییر toggle
|
||||
- [ ] `POST /api/user/tools/bulk-toggle` — toggle دستهجمعی بر اساس scope
|
||||
- [ ] `GET /api/user/scope-presets` — لیست presetها
|
||||
- [ ] تست: روتها کار کنند
|
||||
|
||||
### بخش سوم: Prerequisites (وردپرس/ووکامرس)
|
||||
|
||||
- [ ] `check_prerequisites(tools, site_config)` در tool_access.py
|
||||
- [ ] تشخیص SEO Bridge: `wp-json/airano-mcp-seo-bridge/v1/status`
|
||||
- [ ] تشخیص WP-CLI: بررسی `container` field در credentials
|
||||
- [ ] تشخیص WooCommerce: `wp-json/wc/v3/system_status`
|
||||
- [ ] ابزارهای وابسته علامتگذاری شوند (نه حذف — فقط annotation)
|
||||
|
||||
### بخش چهارم: UI — صفحه مدیریت ابزار
|
||||
|
||||
- [ ] `core/templates/dashboard/tool-preferences.html`
|
||||
- [ ] لیست ابزارها گروهبندی شده بر اساس category
|
||||
- [ ] Toggle switch برای هر ابزار
|
||||
- [ ] Badge برای prerequisite (نصب نشده / نیاز به Docker)
|
||||
- [ ] Dropdown برای اعمال scope preset
|
||||
- [ ] در صفحه Connect: پیشنمایش ابزارها هنگام ساخت API key
|
||||
|
||||
### بخش پنجم: ثبت و تست نهایی
|
||||
|
||||
- [ ] `uvx --python 3.12 black .`
|
||||
- [ ] `uvx ruff check --fix .`
|
||||
- [ ] `pytest` — همه تستها سبز
|
||||
- [ ] Commit: `feat(F.7): add smart tool visibility and scope-based access control`
|
||||
- [ ] Push و درخواست redeploy
|
||||
- [ ] تست live: ساخت API key با scope "read" → بررسی tools/list
|
||||
- [ ] Sync به نسخه عمومی
|
||||
- [ ] آپدیت ورژن به v3.9.0 (اگر تأیید شد)
|
||||
- [ ] حافظه آپدیت شود
|
||||
- [ ] پلن آپدیت شود (F.7 complete)
|
||||
|
||||
## نکات مهم
|
||||
- فیلتر scope باید backward-compatible باشد — keyهای موجود بدون تغییر کار کنند
|
||||
- Default: همه ابزارها فعال — فقط explicit disable ذخیره شود
|
||||
- `user_tool_toggles` فقط overrideها رو ذخیره میکنه، نه همه ابزارها
|
||||
- Prerequisite check باید non-blocking باشه — ابزار حذف نشه، فقط annotate بشه
|
||||
- server.py نیازی به تغییر زیاد ندارد — فقط middleware scope check آپدیت شود
|
||||
- ایمیل git داخلی: mcphub.dev@gmail.com
|
||||
- بخش اول و دوم اولویت اصلی هستند — بخش سوم و چهارم اگر وقت شد
|
||||
@@ -1,98 +0,0 @@
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## فایلهای مرجع
|
||||
- docs/plans/2026-04-04-f7b-site-scoped-tool-access.md ← پلن کامل F.7b
|
||||
- core/tool_access.py ← ToolAccessManager (سایتمحور — session 1)
|
||||
- core/dashboard/routes.py ← روتهای API site tools (بخش F.7b)
|
||||
- core/templates/dashboard/sites/edit.html ← صفحه edit سایت (بدون بخش tools)
|
||||
- core/templates/dashboard/connect.html ← صفحه connect فعلی (config snippets + keys)
|
||||
- core/templates/dashboard/api-keys/list.html ← صفحه admin کلیدها (UI بهتر)
|
||||
- core/dashboard/routes.py::dashboard_connect_page / dashboard_api_keys_list
|
||||
- CLAUDE.md (mcphub-internal)
|
||||
|
||||
## وضعیت فعلی
|
||||
- MCPHub: v3.8.0 + F.7b session 1 (commit روی Phase-1)
|
||||
- Tests: 813 passed، CI سبز
|
||||
- Backend F.7b کامل است: per-site tool_scope + site_tool_toggles + 4 روت جدید تحت `/api/sites/{site_id}/...` + `/api/scope-presets`
|
||||
- فقط UI باقی مانده — هدف این session
|
||||
|
||||
## ریپازیتوری
|
||||
- MCPHub (internal): `/config/workspace/mcphub-internal` (branch Phase-1)
|
||||
|
||||
## هدف session: F.7b — UI + page merge
|
||||
|
||||
### ۱. بخش "Tool Access" در صفحه edit سایت
|
||||
فایل: `core/templates/dashboard/sites/edit.html`
|
||||
|
||||
- [ ] اضافه کردن یک کارت جدید "Tool Access" بعد از فرم credentials
|
||||
- [ ] Dropdown برای `tool_scope` (values: read / read:sensitive / deploy / write / admin / custom)
|
||||
- PATCH روی `/api/sites/{site_id}/tool-scope` با body `{scope: "..."}`
|
||||
- توضیح کوتاه کنار هر گزینه: "Read (X tools)" — شمارش زنده از `/api/sites/{site_id}/tools`
|
||||
- [ ] Collapsible "Advanced — per-tool overrides":
|
||||
- گرید/لیست گروهبندی شده بر اساس `category` (read / read_sensitive / lifecycle / crud / env / backup / system)
|
||||
- Toggle switch برای هر ابزار → PATCH `/api/sites/{site_id}/tools/{tool_name}` با `{enabled: bool}`
|
||||
- Badge قرمز برای `sensitivity=sensitive`
|
||||
- نام کوتاه از `name`، tooltip با `description`
|
||||
- [ ] استفاده از HTMX (در پروژه موجود است) برای updates بدون full reload
|
||||
- [ ] CSRF token از cookie `dashboard_csrf` به header `X-CSRF-Token`
|
||||
|
||||
### ۲. انتقال config snippets از connect به صفحه سایت
|
||||
فایل: `core/templates/dashboard/sites/view.html` (یا ایجاد اگر وجود ندارد)
|
||||
|
||||
- [ ] هر سایت در `/dashboard/sites/{id}` نمایش دهد:
|
||||
- URL MCP مخصوص آن سایت: `{PUBLIC_URL}/u/{user_id}/{alias}/mcp`
|
||||
- Tabs یا accordion با snippets برای Claude Desktop / Cursor / Zed / کلاینتهای دیگر
|
||||
- استفاده از `core/config_snippets.py::get_supported_clients` (موجود)
|
||||
- [ ] از صفحه `/dashboard/sites` (list) دکمه "Connect" به این صفحه لینک بزند
|
||||
|
||||
### ۳. ادغام `/dashboard/connect` و `/dashboard/api-keys` → `/dashboard/keys` (گزینه A)
|
||||
UI مبنا: `core/templates/dashboard/api-keys/list.html` (قشنگتر و کاملتر است طبق تأیید کاربر)
|
||||
|
||||
- [ ] ساخت handler `dashboard_keys_unified(request)` که بر اساس session type branch میزند:
|
||||
- OAuth user → نمایش `user_api_keys` برای آن کاربر
|
||||
- Admin/master → نمایش کامل `api_keys` (همان view فعلی)
|
||||
- [ ] template جدید `core/templates/dashboard/keys/list.html` با ادغام design از `api-keys/list.html`
|
||||
- User view: سادهتر، scope selector در create dialog، لیست کلیدهای خود کاربر
|
||||
- Admin view: فیلترهای کامل (project, status, search, pagination) — بدون تغییر
|
||||
- [ ] **Scope selector در create-key dialog** — این بخش حیاتی است:
|
||||
- Radio/select: read / read:sensitive / deploy / write / admin
|
||||
- Helper text: "Per-site tool filters are set in Site Settings"
|
||||
- POST به `/api/keys` (همان endpoint فعلی) با `scopes: "<selected>"`
|
||||
- [ ] Redirect های قدیمی:
|
||||
- `/dashboard/connect` → `/dashboard/keys` (301)
|
||||
- `/dashboard/api-keys` → `/dashboard/keys` (301)
|
||||
- [ ] حذف handler های قدیمی `dashboard_connect_page` و `dashboard_api_keys_list` و یا تبدیل به thin wrapper redirect
|
||||
- [ ] منوی navigation sidebar را update کن — فقط یک entry "API Keys"
|
||||
|
||||
### ۴. گزینه B (ادغام عمیق DB) — deferred
|
||||
در پلن session 1 ذکر شده اما اجرا نمیکنیم مگر کاربر صراحتاً درخواست کند. کامنت در code اضافه کنید به `api_create_key` که "dual-table model is intentional — see F.7b plan".
|
||||
|
||||
### ۵. تست
|
||||
- [ ] `tests/test_dashboard_keys_unified.py` — تست منوی unified، scope selector، 301 redirect از URL های قدیمی
|
||||
- [ ] `tests/test_sites_tool_access_ui.py` — smoke test که edit page با tool_scope=read درست render شود (میتوان با TestClient چک کرد که template بدون 500 میآید)
|
||||
- [ ] بهروزرسانی `tests/test_dashboard.py::test_dashboard_connect_page` → به `/dashboard/keys` منتقل شود یا به پذیرش redirect
|
||||
- [ ] pytest کامل سبز
|
||||
|
||||
### ۶. ورژن، sync، commit
|
||||
- [ ] `uvx --python 3.12 black . && uvx --python 3.12 ruff check --fix .`
|
||||
- [ ] bump version به `v3.9.0` در pyproject.toml + `__version__` در server.py (اگر وجود دارد)
|
||||
- [ ] Commit: `feat(F.7b): tool access UI + unified keys page (v3.9.0)`
|
||||
- [ ] Push به Phase-1
|
||||
- [ ] `python3.11 scripts/community-build/sync.py --output ../mcphub/` سپس در repo عمومی `black` + `ruff`
|
||||
- [ ] Commit عمومی با ایمیل `hi.airano@gmail.com` و push
|
||||
- [ ] درخواست deploy از کاربر
|
||||
|
||||
### ۷. تست live پس از deploy
|
||||
- [ ] ورود به `/dashboard/sites/{id}/edit` → بخش Tool Access → تغییر scope به `read` → save
|
||||
- [ ] بدون ساخت کلید جدید، MCP client (همان کلید admin موجود) روی آن alias → `tools/list` باید فقط ابزارهای read را نشان دهد
|
||||
- [ ] تغییر به `custom` → Advanced → disable یک ابزار خاص (مثلاً `coolify_delete_server`) → تست
|
||||
- [ ] ساخت کلید جدید از صفحه unified با scope=`read` → بررسی در لیست
|
||||
|
||||
## نکات مهم
|
||||
- **Backward compatibility:** سایتهای موجود `tool_scope='admin'` دارند (default migration v7) → هیچ تغییر رفتاری روی سایتهای قدیمی
|
||||
- **فیلترها:** key scope و site scope **intersect** میشوند. admin key + site=read → فقط read. write key + site=deploy → فقط read + lifecycle.
|
||||
- **CSRF:** middleware روی `/api/sites/*` فعال است. UI باید header `X-CSRF-Token` از cookie `dashboard_csrf` بفرستد. HTMX این را با `hx-headers` هندل میکند.
|
||||
- **CSS:** پروژه Tailwind دارد. از همان کلاسهای موجود در `api-keys/list.html` استفاده کن برای consistency.
|
||||
- **i18n:** پروژه EN/FA است. متنهای جدید را به `core/i18n.py` اضافه کن.
|
||||
- **ایمیل git داخلی:** mcphub.dev@gmail.com | ایمیل عمومی: hi.airano@gmail.com
|
||||
- **نباید:** توابع F.7 v1 (با `user_` prefix) را بازگردانی کنی. همه سایتمحور است.
|
||||
@@ -1,93 +0,0 @@
|
||||
# Next Session — Registry + MCP Skills + Infrastructure
|
||||
|
||||
> Session prompt. Copy and paste into a new Claude Code conversation.
|
||||
|
||||
---
|
||||
|
||||
## Prompt:
|
||||
|
||||
```
|
||||
از مهارت project-ops برای آشنایی با محیط استفاده کن. حافظه و فایلهای مرجع را بررسی کن.
|
||||
|
||||
## فایلهای مرجع
|
||||
- docs/plans/2026-03-25-v4-development-cycle.md (mcphub-internal, branch Phase-1)
|
||||
- CLAUDE.md (mcphub-internal)
|
||||
- CHANGELOG.md (mcphub-internal)
|
||||
|
||||
## وضعیت فعلی
|
||||
- MCPHub: v3.6.0 — 567 ابزار، 5 پلاگین عمومی (WordPress, WooCommerce, Supabase, OpenPanel, Gitea)
|
||||
- FastMCP: >=3.0.0,<4.0.0
|
||||
- CI سبز
|
||||
|
||||
## MCP Endpoints فعال
|
||||
- mcphub-supabase: 70 ابزار Supabase (DB, auth, storage)
|
||||
- mcphub-gitea: 58 ابزار Gitea (repos, issues, PRs, webhooks)
|
||||
|
||||
## ریپازیتوریها
|
||||
### GitHub (airano-ir)
|
||||
- mcphub (public) → /config/workspace/mcphub
|
||||
- mcphub (private, Phase-1) → /config/workspace/mcphub-internal
|
||||
- mcp-skills (private, خالی) → /config/workspace/mcp-skills
|
||||
- skillhub-internal → /config/workspace/skillhub-internal
|
||||
- skillhub (public) → /config/workspace/skillhub
|
||||
|
||||
### Gitea (atlatl @ gitea.example.com)
|
||||
- polymarket (private) → /config/workspace/polymarket
|
||||
- polymarket-skill (private) → /config/workspace/polymarket-skill
|
||||
- project-ops (private) → مهارت در /config/.claude/skills/project-ops/
|
||||
|
||||
## اهداف این session (به ترتیب اولویت)
|
||||
|
||||
### 1. Registry Submissions (F.14a)
|
||||
وضعیت فعلی:
|
||||
- Glama: ثبت شده (Score: A)، glama.json اضافه شده
|
||||
- awesome-mcp-servers: PR #2147 باز — badge SVG + tool count اصلاح شده، منتظر merge
|
||||
- Smithery.ai: ثبت نشده → از smithery.ai/new ثبت کن (نیاز به public HTTPS URL: mcp.example.com)
|
||||
- Official MCP Registry: ثبت نشده → بررسی `mcp-publisher` CLI
|
||||
کارها:
|
||||
- [ ] وضعیت PR #2147 چک شود — اگر feedback جدید دارد رفع شود
|
||||
- [ ] ثبت در Smithery.ai
|
||||
- [ ] بررسی Official MCP Registry submission process
|
||||
|
||||
### 2. MCP Skills — اولین مهارتها (github:airano-ir/mcp-skills)
|
||||
ریپازیتوری خالی ساخته شده. ساختار:
|
||||
```
|
||||
mcp-skills/skills/
|
||||
├── wordpress/ ← اولین مهارت
|
||||
├── supabase/
|
||||
├── gitea/
|
||||
├── woocommerce/
|
||||
├── openpanel/
|
||||
└── coolify/ ← آینده
|
||||
```
|
||||
کارها:
|
||||
- [ ] از SkillHub بهترین مهارتهای مرتبط را جستجو کن: `npx skillhub search "wordpress mcp" --sort aiScore`
|
||||
- [ ] اگر مهارت با کیفیت بالا (aiScore > 70) پیدا نشد، با skill-creator مهارت جدید بساز
|
||||
- [ ] اولین مهارت: WordPress content workflow (استفاده از MCP endpoint مستقیم)
|
||||
- [ ] هر مهارت باید SKILL.md + اسکریپتهای عملی داشته باشد
|
||||
- [ ] بعد از تست، commit و push به github:airano-ir/mcp-skills
|
||||
|
||||
### 3. Project-Ops Sync با Gitea
|
||||
- [ ] محتوای `/config/.claude/skills/project-ops/SKILL.md` را به `gitea:atlatl/project-ops` push کن
|
||||
- [ ] مطمئن شو backup در Gitea up-to-date است
|
||||
|
||||
### 4. Blog Workspace Setup
|
||||
- [ ] WordPress MCP endpoint اضافه کن از داشبورد mcp.example.com (blog.example.com)
|
||||
- [ ] یک پست تست با MCP WordPress tools بنویس
|
||||
- [ ] اگر API مشکلی داشت، در mcphub-internal fix کن
|
||||
|
||||
### 5. بررسی Coolify MCP (F.17)
|
||||
- [ ] API documentation کولیفای را بررسی کن
|
||||
- [ ] بررسی آیا Coolify API در دسترس است از این محیط
|
||||
- [ ] یک طرح اولیه از tools مورد نیاز بنویس
|
||||
- [ ] نتیجه را در docs/plans/ ذخیره کن
|
||||
|
||||
## قوانین
|
||||
- اول پلن بده، بدون تایید شروع نکن
|
||||
- هر مرحله commit شود
|
||||
- حافظه و project-ops در صورت نیاز آپدیت شود
|
||||
- از SkillHub برای پیدا کردن بهترین مهارتها استفاده کن (aiScore بالاترین)
|
||||
- اگر مهارتی بررسی نشده، با auto-review بررسی کن
|
||||
- ایمیل git عمومی: hi.airano@gmail.com
|
||||
- ایمیل git داخلی: mcphub.dev@gmail.com
|
||||
```
|
||||
Reference in New Issue
Block a user