支持导入并管理 Pi / Codex 等 Runtime 原生扩展，而非仅依赖 Ghost 市场

**提交人**: jermy
**客户端版本**: 0.1.33

---

## 使用场景

Cindy 已经承载原生 Pi 与 Codex Runtime，但用户在进入 Cindy 后无法自然复用各 Runtime 已有的扩展生态。当前扩展入口主要是 Cindy Ghost 市场和本地 `.cindy` 文件导入；市场规模有限，而 Pi Package、Codex Plugin、Claude Code Plugin、Runtime 原生 Skills 与 MCP Server 都是不同生态，不能也不应该被强制转换成 Ghost。

实际案例：用户已通过官方 `pi install npm:nowledge-mem-pi` 安装 Nowledge Mem Pi Package。独立 Pi 能加载该 package 的 extension，获得 Session Start Context、completed turn、compaction、clean-exit Thread Sync 等原生生命周期能力；Cindy 的 managed Pi Runtime 不能继承该 package，只能退化为 Skills + CLI。详见 #1967。

## 诉求

提供第一方的 Runtime Extensions 管理中心，让 Cindy 成为各 Agent Runtime 的统一会话、权限和 UI 层，同时保留原生扩展的安装、运行与生命周期，不把它们转换或重写成 Ghost。

建议在设置中按 Runtime 分类：

```text
扩展
├─ Cindy Ghost
├─ Pi Runtime
├─ Codex Runtime
├─ Claude Code Runtime
└─ MCP Servers
```

每类扩展都应显示来源、版本、更新状态、权限、Hook/MCP/Skill 能力、冲突状态与启用范围。

## 建议方案

### Pi Runtime

- 自动发现用户 `~/.pi/agent/settings.json` 中已安装的 Pi Packages，或支持通过官方 package source（例如 `npm:nowledge-mem-pi`）安装。
- 允许用户明确选择“在 Cindy Pi 中启用”。
- 将 package source 以 Pi 官方支持的形式合并到 Cindy managed Pi Agent Home，保留 package 的原生 extensions、skills、prompts、themes 与生命周期行为。
- 不复制、转换或自行重写第三方 package；Cindy 仅负责来源校验、权限确认、配置投影和升级状态展示。

### Codex / Claude Code Runtime

- 支持发现与导入用户已安装或已连接 marketplace 的原生 Plugin / MCP / Skill 配置。
- 导入前展示 Hook、网络域名、凭证、文件访问等权限与潜在冲突。
- 使用各 Runtime 自己的原生安装、更新与生命周期机制，不把插件转换成 Ghost。

### MCP

- 一个 Custom MCP Server 应能勾选目标 Runtime，例如 Pi、Codex、Claude Code。
- 目标 Runtime 的支持状态需要可见；不能像当前 Pi 的 `remoteServers: 0` 一样静默缺失。

## 为什么这比扩充 Ghost 市场更重要

Ghost 市场可以继续发展，但不应成为唯一生态入口。Pi、Codex、Claude Code 与 MCP 已有成熟扩展格式和生命周期模型；Cindy 的价值应是统一管理与安全授权，而不是重新建立一个封闭市场，迫使用户失去已有 Runtime 的原生能力。

## 期望结果

用户能够在 Cindy 中一键发现、导入、授权、启用和更新自己已经在 Pi / Codex / Claude Code 使用的官方扩展；扩展仍由对应 Runtime 原样运行，Session Start、Stop Hook、Thread Capture、MCP、Skills 等能力在 Cindy 内保持与独立 Runtime 一致。
---
**OS**: darwin arm64 (25.5.0)
**界面语言**: zh-CN

Start by reading the existing Cindy Ghost market and local .cindy import entry points, then compare them with the managed Pi Runtime and the behavior described in #1967. Define the extension-management scope and runtime boundaries before implementation; done means the supported runtime categories, permissions, lifecycle behavior, and conflict states are specified and testable.

Written by the indexing model from the issue text.