这份文档汇总多轮讨论后的最终共识：产品入口只保留“新包装”和“旧包装升级”；Harness 先收集并确认需求卡片，再生成结构化动态计划；Plan Validator 把关后，由 Functional Workflow 以按需 Skill、真实 Tool、可恢复 Step 完成报告与三张设计图。
动态的不是 Python 源代码，而是 Harness 生成的结构化 Plan。Functional Workflow 是通用执行引擎：按 Plan 的任务、依赖、条件和并行组运行，并用确定性 Gate 保证交付。
统一收集新包装与旧包装升级需求；用户确认后冻结版本。
把需求转成任务、依赖、Skill 提示、Tool 白名单、交付物和验收条件。
先校验 Plan，再用循环、条件与并行正式执行；每个昂贵动作成为可恢复 Step。
报告模块完整、图片真实可读、全部 Gate 通过后才能发布。
对话、补问、读附件、生成需求卡片与结构化 Plan。
解释 Plan，处理依赖、循环、并行、Step、状态和 checkpoint。
包装研究、旧包装诊断、品牌策略、设计方向与报告规范。
搜索、识图、参考检索、生图、校验与资产存储。
| 对比维度 | 被否定的思路 | 已确认的方案 |
|---|---|---|
| 产品场景 | 四个固定场景 | 两个入口，需求自由表达 |
| 规划方式 | Harness 内部 Todo 直接跑 | Harness 产出可保存的 PlanSpec |
| Workflow | 固定 Graph 写死业务步骤 | Functional Workflow 解释动态 Plan |
| Skill | 一个 Skill 等于一个 Agent | 按需加载的指令、资源与脚本包 |
| 完成判断 | Todo 完成或模型声明完成 | Plan Gate、Step Gate、最终 Gate |
| 图片交付 | 占位图或 Agent 自由决定次数 | 固定验收三张真实设计图 |
用户不需要理解 Agent、Skill 或 Workflow；管理员不画流程图。两边通过同一套版本化模型、Skills、执行记录和报告契约连接起来。
页面左侧只有两个入口，具体诉求全部在对话和附件中表达。
页面右侧维护运行配置与版本，不编辑 Functional Workflow 源代码。
Plan 是运行时中间表示；Functional Workflow 是解释器。执行质量首先受 Plan 的覆盖度、任务拆分、依赖、并行和交付物定义影响，但最终质量还依赖 Skills、Tools、执行 Agent 与逐步 Gate。
任务是否覆盖用户真实目标、保留项、改变项和待解决问题。
设计依赖策略，生图依赖设计 Brief；不能提前执行下游。
独立研究可以并行，有先后依赖的任务必须串行。
每个任务都有输入、输出类型、必填字段与验收条件。
Skill 与 Tool 必须来自管理员激活版本和系统白名单。
Harness 从已确认需求卡片生成 PlanSpec。
ID、依赖、类型、并行组、白名单、交付物。
报告模块、三图任务、旧包装诊断等是否可达。
错误以结构化反馈交给 Harness，不合格不执行。
Plan 通过后持久化，恢复时使用完全相同版本。
使用 if/else、for 和 asyncio.gather 表达运行时动态路径。
Agent 调用、搜索、识图和生图使用 @step，保存事件、结果与 checkpoint。
checkpoint 恢复必须绑定原 Plan。需求变化时创建 Plan v2，而不是静默改旧计划。
动态计划决定怎么得到结果，但不能取消结果本身。报告结构和三张真实设计图是系统级强约束，不能由 Planner 或执行 Agent自行删减。
三个生图任务来自设计方向与图片 Brief。Functional Workflow 可用 asyncio.gather 并行执行；任何一张失败只重试失败 Step，不重新运行已经完成的研究与策略任务。
先做技术探针，再搭完整前后端。Harness 与 Functional Workflow 当前都属于实验（Experimental）API，必须锁版本、做适配层并以真实运行证据决定是否继续。
左侧：入口、对话、附件、需求卡片、执行进度、报告。右侧：模型、Skill 版本、系统契约、运行监控。
管理 Harness Session、PlanSpec、Functional Workflow、SSE 事件、Gate、报告和图片资产。
保存需求卡片、Session、Plan 版本、Skill 版本、模型配置、Step 结果、图片和报告。
发现并运行 Agent 与 Workflow，查看 Trace 和事件；不作为生产后台，也不编辑 Workflow。
GPT-5.5 / 5.6 走 OpenAIChatClient 对应的 Responses API。图片服务独立配置并真实调用。
Harness 与 Functional Workflow 包在业务适配层后；升级前重跑完整技术探针和端到端回归。
Responses、Harness、PlanSpec、Validator、动态 Step、并行、checkpoint、DevUI 和真实生图。
需求卡片、Plan Schema、报告 Schema、三图 Gate 与 SQLite 数据对象。
需求收集、计划生成、计划修正、Functional Workflow、Skills 和 Tools。
左右两栏 UI、管理功能、SSE 进度、报告展示与 DevUI。
新包装和旧包装升级各跑一条，提交报告、三图、Trace 与恢复证据。
Agent Harnesses：工具循环、Todo、模式、记忆、Skills、Loop 与可观察性。
Functional Workflow API：普通 async 函数、if/else、for、asyncio.gather、@step、checkpoint、HITL。
Agent Skills：Skill 结构、渐进加载、InlineSkill、ClassSkill 与 SkillsProvider。
Tools Overview：Function Tool、Web Search、MCP 与 Provider 能力矩阵。
DevUI：开发阶段运行、测试、追踪 Agent 与 Workflow 的样例应用。
OpenAI Provider：OpenAIChatClient 使用 Responses API，是新项目推荐的调用接口。
这一版先用于 Review，尚未派发。工作包按“技术探针先行、契约先于实现、运行闭环先于界面、真实验收最后收口”拆分；每包都有目标、交付物、依赖和验收标准。
本机 CC Bridge 已实测健康，任务列表与持久会话可读取。它适合把每个工作包作为后台任务派给 Claude Code，并把长时间执行、会话恢复和飞书通知从当前对话中解耦。
mcp_cc_claude_run异步创建任务，返回 task_id；可指定 cwd、model、session_id 和完成通知。
mcp_cc_claude_status / waitstatus 做轻量存活检查；wait 用 from_seq 增量读取事件，避免反复拉全量日志。
mcp_cc_claude_cancel任务明确卡死、越界或方向错误时终止；取消前先检查工作树是否已有可复用产物。
mcp_cc_claude_sessions列出持久会话。连续实现默认 resume，完全独立任务或新鲜视角验证才新建会话。
mcp_cc_claude_session_memory读取 compact 总结、最新 Todo 和最近对话，快速接管长会话，不手工解析日志文件。
mcp_cc_claude_list / forget查看当前任务全景；确认结果已归档后清理任务内存，不影响磁盘上的 Claude Session。
每次只派一个可独立验收的工作包。WP0 完成并 Review 后才派 WP1；同一包的增量修改继续原 session。
工作包完成后，可以并行派三类只读 CC：战略对齐、行为验收、健壮性与安全。三个会话互不继承原实现上下文。
只有接口契约冻结后，才允许在独立 worktree 并行做互不重叠的前后端任务；最终由单一整合会话合并和联调。
| 节点 | 主任务 | 可并行任务 |
|---|---|---|
| WP0 技术探针 | 一个主 CC 维护最小可运行集成链路。 | 两路只读核验：MAF 官方能力边界、Responses 与图片 Provider 兼容性。 |
| WP3 Plan Validator | 主 CC 实现 Planner 与 Validator。 | 三路只读审查：依赖图、业务完整性、恢复语义。 |
| WP4-WP6 运行闭环 | 同一主 session 连续实现，减少重复摸底。 | 每包结束后独立行为验证；不并行写同一运行核心。 |
| WP7 前端 | 契约冻结后可在独立 worktree 开始界面壳层。 | 视觉验收与接口行为验证分别新开只读会话。 |
| WP8 最终验收 | 一个整合会话汇总报告和证据。 | 并行跑新包装 E2E、旧包装升级 E2E、战略对齐 Review。 |
已从产品入口、动态计划、运行恢复、报告契约、管理端、实验 API 与 CC 编排七个维度重新走完一遍。当前没有阻塞开工的架构矛盾；剩余不确定性都已被收口到 WP0 的 Stop / Go 验证。
| Review 维度 | 结论 | 说明 |
|---|---|---|
| 产品入口 | 通过 | 只保留新包装与旧包装升级；具体需求不再写死成场景。 |
| 计划与执行 | 通过 | Harness 生成冻结的 PlanSpec；Plan Validator 通过后由 Functional Workflow 解释执行。 |
| 恢复语义 | 通过 | 昂贵任务使用 Step 与 checkpoint；恢复绑定原 Plan，需求变化创建 Plan v2。 |
| 最终交付 | 通过 | 新包装九模块、旧包装升级十模块；六方向与前三张真实图片受确定性 Gate 保护。 |
| 管理边界 | 通过 | 管理员管理模型、Skill 版本与运行记录；不编辑 Workflow 拓扑，DevUI 只用于开发调试。 |
| 实验 API 风险 | WP0 条件通过 | Harness 与 Functional Workflow 均为 Experimental；锁版本、适配层和真实探针已经成为开工门槛。 |
| CC 并行安全 | 按隔离规则通过 | 并行只用于独立 worktree 或只读验证；同一工作树保持单写者，连续实现默认 resume。 |