[Master-Frank]

Summary

Add OpenDesign as a built-in connector using standard stdio MCP. Users can detect a local installation or import its canonical launch configuration, select the connector in a conversation, confirm a brief, generate/refine a project and obtain preview links or requested source.

• Reuse the stdio loading path for built-in and custom MCP servers. Connections are scoped by user, connector, agent, conversation and launch fingerprint, serialized within a conversation, and closed on idle, reload or shutdown. Discovery uses the official MCP SDK and handles paginated tool lists.

• Remove the separate managed catalog mode, runtime_handler, managed.py, the handler registration protocol and runtime.py. AgentManager owns only stdio connection lifecycle. OpenDesign extends the shared stdio runtime with its brief/task/resource behavior.

• Preserve existing HTTP/gateway handling, tool-name normalization and structured results. Conversation preparation covers dashboard, IM and cron entry points.

• Keep the automatic local detection, advanced JSON import, official logo and catalog order before Notion. Credentials use existing encryption and sharing/access controls.

• Keep octop connector install/get/remove open-design for the companion one-click od mcp install octop integration; this registers MCP configuration, not the OpenDesign application.

• Keep connector-specific preparation, validation, stdio specs, probes and runtime construction in open_design.py. Shared builder/probe/API paths delegate through a small bundled function table; they contain no OpenDesign name checks. This adds no transport mode or lifecycle protocol.

Dependencies / merge readiness

Uses the upstream PyPI dependency octop-harness[all]>=1.0.6 and its lockfile. No Git override or temporary source snapshot is needed. The persistent MCP client is available in this release.

The Harness ManagedMCPClient wraps the standard MCP SDK; it does not define a new transport or protocol. Octop's separate managed registration framework has been removed.

nexu-io/open-design#8724 provides the companion one-click OpenDesign CLI target.

Validation

After merging develop at 3359f5bd on 2026-11-02, with the regular PyPI lockfile:

• Standard make all: Ruff, strict mypy (633 source files), 5371 passed / 33 skipped.
• Dashboard npm run build: TypeScript and production build passed.
• Focused frontend tests: 30 passed across 8 files, covering connector configuration and backend flag helpers.
• Resolved connector probe locale conflicts without product-specific branches; retained both stdio cleanup and upstream model-management test setup.
• Removed the obsolete legacy Harness test fixture in favor of upstream tests. Adopted the upstream Docker architecture test fix (test: match the Docker publish warning after lite image tags #2755), and renamed the backend flag helper to avoid macOS case-insensitive TypeScript resolution conflicts. Production behavior is unchanged by these compatibility fixes.

Local docs/plans/ notes, runtime data and credentials are excluded. Full background task tracking and the design console remain in phase 2 (#2048).

Latest sync: merged develop at dde733b1 (#2755), retaining the upstream Docker assertion unchanged. Focused Docker tests: 7 passed; normal commit checks passed. The full-suite results above are from the preceding sync.

Visual verification

Screenshots captured during the earlier local acceptance of this phase; these show phase 1 rather than the phase 2 console. Existing sharing/access controls from current develop are retained by the conflict resolution.

Built-in catalog: OpenDesign before Notion

Local detection and advanced configuration import

[jubaoliang]

GitHub PR 提交规范

✅ PR 必备清单

1. 📸 提供视觉证明（截图/录屏）

必须贴截图，无论放在 PR 描述中还是评论里——让 reviewer 看到"人"，证明是经过人工检查、用心完成的。

2. 🧪 测试用例完整 & CI 通过

• ✅ 新增功能 → 新增对应测试
• ✅ Bug 修复 → 添加回归测试
• ✅ 所有 CI Workflow 必须通过 → 不要期望 reviewer 去 fix 你的 CI

3. 🔄 与 AI 协作：确认理解一致

• 需求明确后，让 AI 重复一遍需求，确认理解无误
• 代码生成后，主动追问：
  • "这个实现是否满足所有需求点？"
  • "是否有遗漏的场景？"

4. 🎯 代码质量：最小修改 & 追问优化

• 坚守最小修改原则，一个 PR 只解决一个问题
• AI 生成代码后，必问：
  • 是否还有优化空间？
  • 所有异常是否妥善处理？
  • 是否有冗余代码？

---

📋 Quick Checklist（可直接放进 PR 模板）

- [ ] 📸 已提供 UI 截图/功能演示
- [ ] 🧱 测试用例已添加并通过
- [ ] ✅ CI Workflow 全部通过
- [ ] 🤖 已与 AI 对齐需求理解
- [ ] 🎯 遵循最小修改原则，代码结构清晰
- [ ] 📝 已询问并处理代码优化建议

核心原则：PR 是沟通，不是交接。让 reviewer 轻松，就是让自己更快合入。

---

🔍 本 PR 自动检查发现的问题

• ❌ CI Workflow 未通过：当前存在失败的 check，请先修复到全绿
• 📸 本 PR 涉及前端改动，但描述中未提供截图/录屏等视觉证明

以上为 automated 检查提示，请补充后 @ 我重新评审。

[Master-Frank]

GitHub PR 提交规范

✅ PR 必备清单

1. 📸 提供视觉证明（截图/录屏）

必须贴截图，无论放在 PR 描述中还是评论里——让 reviewer 看到"人"，证明是经过人工检查、用心完成的。

2. 🧪 测试用例完整 & CI 通过

• ✅ 新增功能 → 新增对应测试
• ✅ Bug 修复 → 添加回归测试
• ✅ 所有 CI Workflow 必须通过 → 不要期望 reviewer 去 fix 你的 CI

3. 🔄 与 AI 协作：确认理解一致

• 需求明确后，让 AI 重复一遍需求，确认理解无误

• 代码生成后，主动追问：

  • "这个实现是否满足所有需求点？"
  • "是否有遗漏的场景？"

4. 🎯 代码质量：最小修改 & 追问优化

• 坚守最小修改原则，一个 PR 只解决一个问题

• AI 生成代码后，必问：

  • 是否还有优化空间？
  • 所有异常是否妥善处理？
  • 是否有冗余代码？

📋 Quick Checklist（可直接放进 PR 模板）

- [ ] 📸 已提供 UI 截图/功能演示
- [ ] 🧱 测试用例已添加并通过
- [ ] ✅ CI Workflow 全部通过
- [ ] 🤖 已与 AI 对齐需求理解
- [ ] 🎯 遵循最小修改原则，代码结构清晰
- [ ] 📝 已询问并处理代码优化建议

核心原则：PR 是沟通，不是交接。让 reviewer 轻松，就是让自己更快合入。

🔍 本 PR 自动检查发现的问题

• ❌ CI Workflow 未通过：当前存在失败的 check，请先修复到全绿
• 📸 本 PR 涉及前端改动，但描述中未提供截图/录屏等视觉证明

以上为 automated 检查提示，请补充后 @ 我重新评审。

@jubaoliang 已补充