支柱二 · 能力（它们说 MCP）

上级：key-designs

两个 MCP 平面——不要混为一谈

StandMeet 同时扮演两种 MCP 角色，方向相反：

• 能力平面——StandMeet 作为 MCP host。 我们自己的 visitor-agent 把 MCP 服务器当作自己的工具来使用：内置的 mcp-servers/（stdio 子进程）、owner 挂载的 ext-mcp，以及尚未迁移出去的进程内能力。客户端侧：mcpclient；注册表：capreg。进程本地——没有网络鉴权；沙盒化的 builtin 通过 capsocket 回连宿主。
• 服务句柄——StandMeet 作为 MCP server（as-MCP）。 对外的 /mcp/* 端点（as-mcp-facade），由 Sigv1 守护，供外部 MCP 客户端消费：owner 本人的 AI 会话推送精选语料（thesis 循环），以及他人的 agent 读取 persona。

在这里，不加限定的"MCP"是有歧义的——要说清楚指的是能力平面还是服务句柄。完整的消歧表（这两者再加另外八个容易混淆的概念）：confusables。

agent 的双手，以插件的形式组织在 MCP 标准之上（原样照搬——没有私有协议）。capreg 是注册表：确定性的装配顺序（system-prompt 的哈希依赖于它）、EnableGate，以及暴露公式 exists ∧ owner_enabled ∧ connector_deps_met ∧ role_acl ∧ quota。已经有五个能力搬到了进程之外，作为独立的 Go MCP 服务器（mcp-servers/：ask-visitor、booker、mail-sender、retrieval、summarize），在 compose 启动时通过 stdio 加载，每个都由一份纯数据的 manifest 声明（backend/capabilities/<id>/manifest.yaml，go:embed 进二进制——id 为 ask_visitor、calendar.book、corpus.retrieval、mail.send、summarize_conversation）；沙盒化的 builtin 通过 capsocket（每个能力一个窄的 unix socket）访问宿主数据，其动词自 2026-08-01（5cb8d8464）起在 manifest 里按名字点单（host_ops），由入站收口点 internal/routes/hostdesk 提供。核心之外还有：mcpplugin（manifest + 安装发现，Origin 三层信任：builtin/managed/owner）、mcpclient（http——streamable、回退 HTTP+SSE——/ 进程内 / stdio 三种传输）、as-MCP facade（把 owner 的工具聚合成一个端点，供他人的 agent使用）、ui:// MCP-Apps 卡片，以及 marketplace（基于 GitHub 的技能发现）。

状态（2026-09-07，36789537d）： 机制层是绿的——最后一个占位项监控面板已于 2026-09-04 变成真实数据（e3af33a1c；见 monitor）。剩下的结构性工作是外部化迁移。仍在进程内 MustRegister 的有：job-loop 三件套（jobs / resume / applications——internal/owner/jobs/jobs.go:110-112）、skill runner、ext-mcp、openapi agent-tools 和 resume_read（internal/routes/capload/capreg_register.go:39-50）。me / seo / codes 已经不再是能力——它们的 owner op 搬进了出站 dispatcher（internal/routes/dispatcher），全局 SEO 设置功能也于 2026-09-06 移除（7037a434e；SEO 现在跟着每个微站走）。目标不变：把进程内注册表清到零，同时保住 feature floor。

机制已被取代——everything-is-a-block（eiab），2026-09-13 → 2026-09-18

在上面那次核对之后才落地；意图（外置成 MCP、保住地板）不变，词汇和承载方式变了：

• 五个内建 server 现在是 JS block，不是 Go 了。 ask_visitor / calendar.book / corpus.retrieval / mail.send / summarize_conversation 落在 backend/blocks/*/manifest.yaml + 一个 JS MCP server（不再是 backend/capabilities/ 里的 Go mcp-servers/）。owner 挂的 ext-mcp 仍适用。
• 词汇改名 capabilities/cap* → plugin/block*：capreg → backend/internal/plugin/registry，mcpplugin → plugin.Manifest，store/config/quota → blockstore/blockconfig/blockquota，入站汇聚点 hostdesk → blockdesk，capload → blockload；mcpclient 搬到 backend/internal/infra/。
• capsocket 退役： block 是 JS，在 boot 时暖绑自己的 host socket（见 capsocket，它本身也被取代了）——per-capability 的窄 verb reach-back 形式还在，那个包没了。
• 仍在进程内（准确，只是路径变了）： job-loop 三件套（jobs/resume/applications，仍 MustRegister）+ loader fiber 现在在 internal/routes/blockload/register_mechanisms.go 注册（原 capload/capreg_register.go）。进程内注册表还没到零。

类图（装配侧 vs 消费侧，成员已完整核对）：capabilities-diagram-coverage。

子节点

• capabilities-diagram-coverage —— 本模块的类图（装配侧 vs 消费侧）+ 核对清单。
• mcp-capability-plugins —— manifest、PluginSource、Origin 信任分层、暴露公式。
• skills-progressive-disclosure —— 把技能做成 Agent Skills；三级渐进披露（name → skill_use → skill_run_script）。
• ui-cards —— ui:// MCP-Apps 卡片：sandbox iframe + postMessage 握手；NON_SANDBOX_CARDS 例外情况；拟议中的 manifest renderer 字段。
• capsocket —— 每个沙盒化 builtin 一个窄的 unix socket；爆炸半径 = 几个动词（verb）。
• feature-floor —— 外部化迁移不能丢的那些横切行为（它的验收 spec）。
• capability-owns-quota-config-and-store —— manifest 声明 quota / claim_gate / config·code_config·role_config / visitor_tools / owner_tools / host_ops；capstore（自己的 schema）+ capconfig + capquota（一个计数、两个输出）+ hostdesk 在宿主上不带一个业务词地执行它们；acl: always 那三个；每会话的 Binding 如何装配。

（对外的页面——as-mcp-facade、ui-mcp-parity——放在 service-handle 之下，刻意作为一个独立的节点。）