用途
Bootstrap CAP Server 用于把用户已有的因果图、因果运行时或内部因果 API 转换为 CAP 兼容服务器。典型触发场景包括：用户希望暴露 GET /.well-known/cap.json 与 POST /cap；用户想要一个全新的 CAP 服务器脚手架，或想把现有服务包装在 CAP 之后；用户不确定运行时是否能诚实地支持结构性、观测性或干预性动词；能力卡应当从已挂载接口派生，而不是手工维护。
不适用场景：主要任务是认证、网关、租户、限流或其他产品边界工作；主要任务是发明厂商扩展而非诚实暴露 CAP 核心动词；用户尚无图、运行时或因果 API，需要先从头构建因果机制；请求依赖声称 Level 3 或反事实支持。
主要能力
- 对运行时形态进行分类，优先暴露最小且诚实的公共接口。
- 从已挂载动词派生能力卡，而非手工维护能力声明。
- 默认只使用 CAP 核心动词，不引入厂商扩展。
- 默认只做 CAP 层脚手架，不把认证、网关、租户、限流或产品访问控制纳入主引导流程。
- 从 Level 1 起步，除非用户图与运行时明确支持 Level 2；从不声称 Level 3。
- 在生成文件前，主动总结计划中的公共 CAP 接口与能力卡影响。
- 提供全新可运行脚手架：
scripts/bootstrap_cap_server.py配合assets/templates/level1-fastapi或assets/templates/level2-fastapi。
使用方式
工作流以 references/workflow.md 作为唯一活跃的引导循环。辅助参考按需使用：references/user-graph-shapes.md 用于运行时分类；references/conformance-matrix.md 用于诚实的 CAP 接口与级别选择；references/python-sdk-patterns.md 用于已发布 SDK 导入、注册表接线与能力披露；references/implementation-patterns.md 用于适配器与项目布局模式。
生成项目文档时默认使用 uv sync --extra dev，本地工作流使用 uv run ...。不要生成从本地 python-sdk/ 检出导入的代码。
交互契约：脚手架之前，需明确项目父目录、文件夹名与是否 git init；尽可能推断运行时来源，或用平实语言询问用户是从本地文件、Python 代码还是已运行服务开始；询问预测或干预今天是否已经可用，若不可用，用平实语言询问是暂时省略还是先搭占位符；在生成文件前复述计划挂载的动词、一致性级别、能力披露形态与当前的非声明。默认将所需信息收集问题合并为一条分组消息，不要逐条拖沓询问。
输出期望：产出代码而非仅建议。对于非平凡请求，优先包含项目树、主服务器模块、运行时适配器接口、由已挂载动词派生的能力卡构建器、测试、安装与运行命令、一两个示例请求。
适用场景
- 已有因果图或因果运行时，需要以 CAP 协议对外暴露。
- 需要为现有服务套上 CAP 外壳。
- 需要生成全新的 CAP 服务器脚手架。
- 需要根据运行时实际能力诚实地选择 CAP 级别与动词接口。
限制
- 不处理认证、网关、租户、限流等产品边界工作。
- 不发明厂商扩展。
- 不声称 Level 3 或反事实支持。
- 用户尚无图、运行时或因果 API 时，需先构建因果机制。
- 默认不把
context.graph_ref当作多图设计需求，而是视为可选的 CAP 请求上下文字段。 - 具体收费、价格、平台支持等信息暂未提供。