Prevent implicit project binding on explicit new project names
This commit is contained in:
parent
7bdc9f3a65
commit
0037c6954a
|
|
@ -636,7 +636,8 @@ uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
|
|||
## 11. 已知 BOUNDARY（不要幻构行为）
|
||||
- 飞书回调字段可能缺失文件名/大小，仅保证 `attachment_id/key/type` 可用
|
||||
- 真实飞书网页 E2E 依赖本机已登录的 Chrome/Feishu 会话；默认读取 `FEISHU_USER_DATA_DIR=~/Library/Application Support/Google/Chrome` + `FEISHU_PROFILE_DIRECTORY=Default`，若本机 Chrome 正在占用该 profile，请改用独立 profile 或先关闭 Chrome
|
||||
- 真实飞书网页 E2E 只负责浏览器发消息与页面诊断，结果校验统一走数据库探针；执行前至少需要配置 `FEISHU_CHAT_URL` 或 `FEISHU_CHAT_NAME`
|
||||
- 真实飞书网页 E2E 只负责浏览器发消息与页面诊断，结果校验统一走数据库探针；validation runner 现会优先从 `frontend/playwright-report/feishu-web/index.html` 恢复上次成功运行的 `FEISHU_CHAT_URL/FEISHU_CHAT_NAME/userDataDir`，其次回退到 acceptance profile
|
||||
- 显式命名的新项目请求（例如“这个需求先叫 FeishuWebFlow-*”）不得仅因正文出现历史项目标题就自动绑定已有 `project_id`；若确需复用已有项目，必须由显式 `project_id` / 项目指代或后续确认链路决定
|
||||
- 项目创建返回的 `signal_sources` 仅作为 AI Steward 创建结果区的内联展示；项目看板与 SSTC 信号阶段统一只读正式 `Signal`，`SignalSourceRegistry` 继续只承担内部持久化与幂等，不单独上屏
|
||||
- 老板晨报首版的 `external_metrics` 只返回占位区块，不接 CRM / BI / 收入系统，也不允许伪造经营指标
|
||||
- 老板晨报调度默认值为 `08:30 + workdays + Asia/Shanghai`；若 `delivery_target_ref` 未配置，调度器仍生成快照，但只记录告警、不静默伪装成已推送
|
||||
|
|
|
|||
|
|
@ -3,14 +3,46 @@
|
|||
from __future__ import annotations
|
||||
|
||||
from .shared import * # noqa: F401, F403
|
||||
from ..workflow_semantic_planner import WorkflowSemanticPlanner
|
||||
|
||||
|
||||
class KernelWorldModelCoreProjectMixin:
|
||||
_EXPLICIT_NEW_PROJECT_TITLE_PATTERNS = (
|
||||
r"(?:项目|需求)(?:名字|名称|名)?(?:固定|统一|必须)(?:叫|名为|名称为|名字为|命名为|定为|是|为)[：:，,\s]*(.+)",
|
||||
r"(?:项目|需求)(?:名字|名称|名)?就叫[：:，,\s]*(.+)",
|
||||
r"(?:这个|该)?(?:新)?(?:项目|需求)(?:先|就)?叫[：:，,\s]*(.+)",
|
||||
)
|
||||
|
||||
@staticmethod
|
||||
def _record_world_model_query_table(query_tables: Optional[set[str]], table_name: str) -> None:
|
||||
if query_tables is not None:
|
||||
query_tables.add(table_name)
|
||||
|
||||
@classmethod
|
||||
def _extract_explicit_project_title_anchor(cls, *, message_text: str) -> str:
|
||||
cleaned = re.sub(r"\s+", " ", str(message_text or "")).strip()
|
||||
if not cleaned:
|
||||
return ""
|
||||
for pattern in cls._EXPLICIT_NEW_PROJECT_TITLE_PATTERNS:
|
||||
match = re.search(pattern, cleaned, flags=re.IGNORECASE)
|
||||
if not match:
|
||||
continue
|
||||
candidate = re.sub(r"[，。,.;；!?？].*$", "", match.group(1)).strip(" []【】()（）:：\"'“”")
|
||||
normalized = re.sub(r"\s+", "", candidate).lower()
|
||||
if not normalized or normalized in {"项目", "需求", "新项目", "新需求", "pmflow"}:
|
||||
continue
|
||||
return candidate[:80]
|
||||
return ""
|
||||
|
||||
@classmethod
|
||||
def _should_skip_implicit_project_binding(cls, *, message_text: str) -> bool:
|
||||
cleaned = re.sub(r"\s+", " ", str(message_text or "")).strip()
|
||||
if not cleaned:
|
||||
return False
|
||||
if not WorkflowSemanticPlanner.looks_like_project_create_request(cleaned):
|
||||
return False
|
||||
return bool(cls._extract_explicit_project_title_anchor(message_text=cleaned))
|
||||
|
||||
async def _resolve_project(
|
||||
self,
|
||||
*,
|
||||
|
|
@ -47,6 +79,9 @@ class KernelWorldModelCoreProjectMixin:
|
|||
)
|
||||
).scalar_one_or_none()
|
||||
|
||||
if self._should_skip_implicit_project_binding(message_text=message_text):
|
||||
return None
|
||||
|
||||
self._record_world_model_query_table(query_tables, "projects")
|
||||
projects = (
|
||||
await self.db.execute(
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ from app.services.ai_pmo.ai_pmo_kernel.ai_pmo_reply_renderer import ReplyRendere
|
|||
from app.services.ai_pmo.ai_pmo_kernel import ai_pmo_typed_executor_mixins_parse
|
||||
from app.services.ai_pmo.ai_pmo_kernel_ingress_flow import mixin_entry
|
||||
from app.services.ai_pmo.ai_pmo_kernel_ingress_flow import mixin_prepare_manual
|
||||
from app.services.ai_pmo.ai_pmo_kernel_world_model_core import mixin_project
|
||||
from app.services.ai_pmo.ai_pmo_typed_executor_execute import mixin_execute_query_project
|
||||
from app.services.ai_pmo.ai_pmo_intent import CanonicalIntent
|
||||
from app.services.ai_pmo.draft_confirm_handler import DraftConfirmHandler
|
||||
|
|
@ -326,6 +327,21 @@ def test_new_project_statement_does_not_route_to_existing_draft_without_anchor()
|
|||
) is False
|
||||
|
||||
|
||||
def test_explicit_named_project_create_skips_existing_project_name_binding() -> None:
|
||||
assert mixin_project.KernelWorldModelCoreProjectMixin._should_skip_implicit_project_binding(
|
||||
message_text=(
|
||||
"最近我们做跨境直播复盘太慢了，想做个给运营团队用的小工具，"
|
||||
"这个需求先叫 FeishuWebFlow-1775301894322。"
|
||||
),
|
||||
) is True
|
||||
|
||||
|
||||
def test_project_lookup_question_keeps_existing_project_name_binding() -> None:
|
||||
assert mixin_project.KernelWorldModelCoreProjectMixin._should_skip_implicit_project_binding(
|
||||
message_text="帮我看下跨境直播复盘这个项目现在怎么样？",
|
||||
) is False
|
||||
|
||||
|
||||
@pytest.mark.asyncio
|
||||
async def test_draft_confirm_handler_prefers_latest_sender_scope_candidate_without_anchor() -> None:
|
||||
latest_work_item = SimpleNamespace(
|
||||
|
|
|
|||
|
|
@ -0,0 +1,421 @@
|
|||
# PMFlow Agentic Delivery Kernel（三个月母计划 / C 版）
|
||||
|
||||
## Summary（总体摘要）
|
||||
这份计划不是“在 PMFlow 里再多接几个 Agent”，而是把 PMFlow 升级成一套 **稳定内核 + 可编译流程 + 可插拔策略 + 可回放投影 + 强治理护栏 + 可控迁移路径** 的交付操作系统。
|
||||
|
||||
本计划采用 `C` 版结构：**北极星母计划** + **迁移控制计划** 合一。
|
||||
|
||||
- 北极星母计划回答：三个月后系统应该长成什么样。
|
||||
- 迁移控制计划回答：今天的 PMFlow 如何无事故地迁到那个形态。
|
||||
- 任何 Program 只有同时满足“未来态正确”和“现网可迁移”两项，才算真正完成。
|
||||
|
||||
系统目标主链固定为：
|
||||
`source_events（来源事实） -> requirement_topics（需求主题） -> intents（交付意图） -> workflow_definitions / workflow_versions（工作流定义 / 版本） -> runs（运行实例） -> assignments（调度单元） -> agent_events / agent_artifacts（执行事实 / 产物事实） -> change_sets（代码变更集） -> release_batches（发布批次） -> projections（投影视图） -> Feishu / PMFlow UI`
|
||||
|
||||
但在迁移完成前，系统的**现有真源**仍然被承认、被保护、被映射，绝不允许凭空假设“未来对象已经生效”。
|
||||
|
||||
## What “Perfect Execution” Means（什么叫可被完美执行）
|
||||
这份计划被定义为“可被完美执行”，必须同时满足：
|
||||
|
||||
- 对每类业务事实，在任一阶段都只有一个被明文承认的真相源。
|
||||
- 对人状态只能来自投影，不能来自 LLM 临时推断、半成品 artifact 或散落业务字段。
|
||||
- 新旧对象之间必须有显式映射合同，禁止靠口头理解迁移。
|
||||
- 所有 AI 调用都必须仍受 OpenClaw、prompt registry、PromptRelease、`ai_call_logs`、Redis 缓存、零兜底原则约束。
|
||||
- 所有执行动作都必须继续经过受控执行器、执行账本、幂等键与审计链。
|
||||
- 任务拆解与分配必须继续优先消费人员能力图谱与负载事实，而不是仅按 runtime 能力分发。
|
||||
- 每个 cutover 都必须写明切换条件、回滚条件和验证证据。
|
||||
|
||||
如果一份计划只描述目标架构，而没有写清现有真相源、兼容映射和切换证据，它可以是优秀蓝图，但不叫“完美可执行母计划”。
|
||||
|
||||
## How To Read This Plan（阅读方式）
|
||||
本计划按两层来读：
|
||||
|
||||
- `Layer 1: North Star`：描述稳定内核、可变工作流、目标对象和目标分层。
|
||||
- `Layer 2: Migration Control`：描述现有系统事实、新旧对象映射、Program 依赖顺序、灰度、回放、回滚与完成门槛。
|
||||
|
||||
任何执行者必须先读 `Current Truth and Constraints` 与 `Canonical Mapping Contract`，再进入 Program 拆解。不得跳过迁移控制层直接按未来态建模。
|
||||
|
||||
## Current Truth and Constraints（当前真相源与不可绕过约束）
|
||||
### 当前真相源
|
||||
以下对象是今天 PMFlow 中已经在线、必须尊重的控制面事实：
|
||||
|
||||
- `ingest_events`：当前入站事件幂等真源，所有入站事件必须先在这里去重。
|
||||
- `work_items`：当前 AI PMO 人工控制、草稿确认、恢复闭环的主对象。
|
||||
- `decision_records`：当前审批、策略门禁、确认需求和最终结果的决策事实。
|
||||
- `ai_orchestration_runs`：当前异步运行账本和 ingress worker 主轴。
|
||||
- `ai_worker_executions`：当前 worker 执行事实兼容账本。
|
||||
- `operation_execution_ledger`：当前副作用幂等与执行结果审计真源。
|
||||
- `feishu_reply_outbox`：当前对人消息发送的唯一受控出口。
|
||||
- `backend/.openclaw/pmflow-routing-rules.json`：当前模型路由配置唯一真源。
|
||||
- `ai_prompt_registry` + `PromptReleaseService`：当前 Prompt 治理与 serving 优先级真源。
|
||||
- `ai_call_logs`：当前 AI 调用追溯真源。
|
||||
- `skill_graph / recommend_personnel / required_skill_tag_ids`：当前任务拆解与负责人推荐的核心能力事实。
|
||||
|
||||
### 不可绕过的系统约束
|
||||
以下约束不是“实现建议”，而是母计划级硬约束：
|
||||
|
||||
- 所有数据库写操作必须通过 Alembic migration，禁止运行期 DDL。
|
||||
- 所有新增接口必须遵循 `{code, message, data}` 包络。
|
||||
- 所有接口必须继续使用 JWT + tenant 依赖注入。
|
||||
- 所有查询和事实沉淀都必须天然 tenant 隔离。
|
||||
- 所有 AI 调用必须走 service 层、OpenClaw 路由、`ai_call_logs`、Redis 缓存与重试治理。
|
||||
- 所有用户可见核心业务内容禁止兜底文案、模板假成功和 stub 数据。
|
||||
- 所有业务语义关键词、正则、`looks_like_*`、`*_HINTS/*_KEYWORDS` 只能留在 `workflow_semantic_planner` 或 prompt/catalog 配置层。
|
||||
- 飞书回执继续只允许通过 `feishu_reply_outbox` 发送，禁止新增第二套对人发送通道。
|
||||
- worker 不允许直接写核心业务表；所有写动作都必须经受控 executor 与执行账本。
|
||||
- 前端组件禁止直接 `fetch`，仍必须通过 `frontend/src/api/` 封装层。
|
||||
|
||||
## North Star（北极星设计）
|
||||
- `内核稳定`：账本、状态机骨架、事件协议、ACL、审计、投影契约优先冻结。
|
||||
- `流程可变`：主流程不再写死在路由和 service if/else 里，而是 `workflow_version` 的编译产物。
|
||||
- `策略可插拔`：topic 聚合、意图分类、编译、重规划、发布、升级、预算和回执映射都可以换版本。
|
||||
- `执行可替换`：Mock、Codex、Claude、人工接管、外部系统都遵守同一协议。
|
||||
- `视图只读`：飞书、PMFlow UI、管理视图、执行视图、审计视图全部来自投影层。
|
||||
- `治理先行`：DLQ、replay、budget、quota、backpressure、alerts、manual takeover、rollout 不是补丁，而是一等模块。
|
||||
|
||||
## Stable Kernel vs Mutable Workflow（稳定内核与可变工作流）
|
||||
以下对象必须尽早冻结，并尽量长期不动：
|
||||
|
||||
- `source_event`
|
||||
- `requirement_topic`
|
||||
- `intent`
|
||||
- `run`
|
||||
- `assignment`
|
||||
- `agent_event`
|
||||
- `agent_artifact`
|
||||
- `change_set`
|
||||
- `release_batch`
|
||||
- `workflow_definition / workflow_version`
|
||||
- `projection reducer contract`
|
||||
- `ACL / audit / replay / DLQ` 契约
|
||||
|
||||
以下模块必须故意设计成可替换：
|
||||
|
||||
- topic merge / split / reparent 策略
|
||||
- intent classifier
|
||||
- workflow compiler
|
||||
- planner / replanner
|
||||
- release policy
|
||||
- escalation policy
|
||||
- reply mapping
|
||||
- runtime adapter
|
||||
- diff / QA / review gate
|
||||
- quota / budget policy
|
||||
|
||||
## Canonical Object Model（目标规范对象模型）
|
||||
- `SourceEvent`：记录谁从哪里在什么时候发来了什么，只追加，不覆盖。
|
||||
- `RequirementTopic`：归并多个来源事件，支持 `merge / split / reparent`，不直接承载执行。
|
||||
- `Intent`：表达系统要达成的交付意图，是工作流编译输入，不等于单条消息。
|
||||
- `WorkflowDefinition`：定义节点类型、边类型、补偿点、门禁点、超时与升级点。
|
||||
- `WorkflowVersion`：工作流模板的具体版本，运行实例必须绑定版本。
|
||||
- `Run`：某个 intent 在某个 workflow version 下的一次执行实例。
|
||||
- `Assignment`：最小可调度执行单元，只绑定能力和约束，不绑定具体 runtime 厂商。
|
||||
- `AgentEvent`：执行事实日志，必须支持幂等、乱序处理、版本化 reducer。
|
||||
- `AgentArtifact`：产物事实日志，不能直接当最终状态，需要经 reducer 归并。
|
||||
- `ChangeSet`：代码交付聚合层，允许多个 assignment、多个 run 共同关联。
|
||||
- `ReleaseBatch`：发布聚合层，允许多个 change set、多个 run 共同关联。
|
||||
- `Projection`：管理视图、执行视图、审计视图、成本视图、风险视图全部从事实账本重建。
|
||||
- `ManualTakeoverSession`：人工接管会话，负责 pause、resume、override、cancel、handoff。
|
||||
|
||||
## Canonical Mapping Contract（新旧对象映射合同）
|
||||
这是本计划区别于“纯蓝图”的关键部分。任何新对象落地前，都必须回答：它与现有真源是什么关系。
|
||||
|
||||
### 1. 入站链路映射
|
||||
- `ingest_events` 继续作为入站幂等闸门，直到 Program 7 完成读切换验证前都不得退场。
|
||||
- `source_events` v1 不是绕开 `ingest_events` 的新入口，而是由 `ingest_events` 派生或 dual-write 的规范化来源账本。
|
||||
- 在 replay 一致性未验证前，`source_events` 只能作为 shadow ledger，不得成为主读入口。
|
||||
|
||||
### 2. 控制面映射
|
||||
- `work_items` 继续是当前人工确认、草稿确认、恢复执行和消息台控制面的主对象。
|
||||
- `Run` v1 必须先定义成对 `work_items + ai_orchestration_runs` 的兼容抽象，而不是第二套独立控制面。
|
||||
- `ManualTakeoverSession` v1 必须映射现有 `waiting_manual / draft_pending_confirm / decision / resume` 语义，不得先造一套平行人工接管 UI。
|
||||
- `decision_records` 继续作为审批、门禁、风险、批准需求与最终结果的决策真源，直到其语义被完整映射进新控制面。
|
||||
|
||||
### 3. 执行事实映射
|
||||
- `ai_orchestration_runs` 是 `Run Ledger v0`，应优先扩展为兼容型中轴，而不是直接废弃。
|
||||
- `ai_worker_executions` 是 `Assignment Execution Fact v0`，应先适配进 assignment 事实模型。
|
||||
- `operation_execution_ledger` 是副作用幂等与审计真源，`agent_events` v1 必须先从它映射、归一和补证据，不允许旁路写入。
|
||||
- 所有 `execution_result.action_contract` 与 `action_param_source` 继续保留并写入执行账本，直到新协议完全接管。
|
||||
|
||||
### 4. 对人交互映射
|
||||
- `feishu_reply_outbox` 继续是唯一对人发送出口。
|
||||
- `Feishu Mapping` 只能复用现有 outbox 的 claim / retry / stale recovery 模式，不允许新建第二套发送消费者。
|
||||
- 所有人类可见状态在迁移过程中也必须来自投影，不得直接读取 raw LLM 输出、草稿或 worker artifact 作为对人状态。
|
||||
|
||||
### 5. AI 治理映射
|
||||
- `OpenClaw` 路由规则继续是模型选择唯一真源，禁止在新内核中重新硬编码模型名或 provider。
|
||||
- `ai_prompt_registry` 和 `PromptReleaseService` 继续是 Prompt 治理入口，禁止新 compiler 或 domain pack 绕过它们直接拼 prompt。
|
||||
- `ai_call_logs` 继续是 AI 调用审计真源，Program 0 以后新增链路若未接入此表，视为未接入。
|
||||
- Redis 缓存继续保留在 world model 静态层和 AI 调用基础设施层，新增链路只能扩展，不能把缓存语义上浮为用户可见业务兜底。
|
||||
|
||||
### 6. 能力图谱映射
|
||||
- `Assignment` 不是简单“把任务发给 runtime”；它必须先经过能力约束。
|
||||
- `skill_graph / recommend_personnel / required_skill_tag_ids` 必须进入 compiler input、assignment gate 和 approval context。
|
||||
- 若某个调度设计无法回答“它如何优先使用人员能力图谱”，则该设计不符合 PMFlow 宪章，不允许进入 Program 3 之后阶段。
|
||||
|
||||
## Layered Architecture（目标分层架构）
|
||||
### Layer A: Source and Topic Ledger（来源与主题账本层）
|
||||
负责 `source_event` 入账、topic 聚合、topic 拆分、topic 关系维护。
|
||||
|
||||
### Layer B: Intent and Workflow Compiler（意图与工作流编译层）
|
||||
负责把 `topic + context + policy + capability + skill graph` 编译为 `workflow_version` 和 `run plan`。
|
||||
|
||||
### Layer C: Execution Kernel（执行内核层）
|
||||
负责 `run / assignment / event / artifact` 生命周期、claim、lease、heartbeat、replan、callback。
|
||||
|
||||
### Layer D: Delivery Aggregation（交付聚合层）
|
||||
负责 `change_set / release_batch` 聚合、多 run 联动、shared PR/shared release 建模。
|
||||
|
||||
### Layer E: Projection and Interaction（投影与交互层）
|
||||
负责 PMFlow UI、Feishu 回执、管理摘要、执行摘要、审计视图、成本视图。
|
||||
|
||||
### Layer F: Governance Plane（治理平面）
|
||||
负责 ACL、audit、DLQ、replay、budget、quota、alerts、manual takeover、rollout、backfill。
|
||||
|
||||
## Codex Execution Discipline（Codex 执行纪律）
|
||||
整个三个月计划必须按 `Program -> Package -> Packet` 三级执行。
|
||||
|
||||
### Program（项目级阶段）
|
||||
代表稳定目标面，例如 `Truth Inventory`、`Workflow Compiler`、`Human Surfaces`。
|
||||
|
||||
### Package（能力包）
|
||||
代表某个 Program 下的一组强相关能力，例如 `Run Mapping`、`Constraint Translator`、`Replay Projection`。
|
||||
|
||||
### Packet（最小可执行任务包）
|
||||
代表一次真正落地的任务单位，必须满足：
|
||||
|
||||
- 一个 Packet 只属于一个 Program。
|
||||
- 一个 Packet 最多覆盖一个稳定层和一个相邻层。
|
||||
- 一个 Packet 涉及文件超过 `5` 个必须再拆。
|
||||
- 一个 Packet 预估改动超过 `200` 行必须再拆。
|
||||
- 一个 Packet 不允许同时改 `migration + runtime adapter + UI + compiler`。
|
||||
- 一个 Packet 必须显式说明它依赖的“当前真源”与“目标对象”。
|
||||
- 一个 Packet 必须声明 `read_scope`、`write_scope`、`feature_flags`、`tests`、`rollback`、`docs_impact`。
|
||||
- 一个 Packet 必须给出可验证退出条件，不能只写“功能完成”。
|
||||
|
||||
### Packet Template（任务包模板）
|
||||
每个 Packet 进入执行前必须显式写出：
|
||||
|
||||
- `packet_id`
|
||||
- `program_id`
|
||||
- `package_id`
|
||||
- `goal`
|
||||
- `current_truth_source`
|
||||
- `target_object`
|
||||
- `entry_criteria`
|
||||
- `read_scope`
|
||||
- `write_scope`
|
||||
- `schema_change yes/no`
|
||||
- `api_change yes/no`
|
||||
- `projection_impact`
|
||||
- `feature_flags`
|
||||
- `idempotency_key_strategy`
|
||||
- `audit_evidence`
|
||||
- `verification`
|
||||
- `rollback_plan`
|
||||
- `docs_to_sync`
|
||||
|
||||
## Program Roadmap（Program 路线图）
|
||||
### Program 0: Truth Inventory and Governance Baseline（真相源盘点与治理基线）
|
||||
目标：先冻结现有真源、治理边界、幂等、路由、缓存、审计、开关、灰度和回退框架，不直接做业务增量。
|
||||
|
||||
Packages：
|
||||
- `0.1 Truth Inventory`：盘点 `ingest_events / work_items / decision_records / ai_orchestration_runs / ai_worker_executions / operation_execution_ledger / feishu_reply_outbox` 的职责、主写入口、主读入口、幂等键。
|
||||
- `0.2 AI Governance Baseline`：冻结 OpenClaw 路由、Prompt registry、PromptRelease、`ai_call_logs`、Redis 缓存、零兜底与 fail-fast 原则。
|
||||
- `0.3 Contract Freeze`：冻结对象主键、关联表、幂等键、事件包络、审计字段、版本字段、租户边界。
|
||||
- `0.4 Rollout Strategy`：定义 `shadow mode / dual-write / dual-read / tenant canary / rollback / backfill`。
|
||||
- `0.5 Metrics and SLO Baseline`：定义 `queue lag`、`claim timeout`、`replan rate`、`dead run count`、`release failure rate`、`manual takeover rate`、`token cost`。
|
||||
- `0.6 Regression Baseline`：固定后端、前端、Docker、Feishu Web E2E 回归清单。
|
||||
- `0.7 Docs Baseline`：锁定后续必须同步的 `CLAUDE.md`、部署文档、运行说明、操作员 runbook。
|
||||
|
||||
Exit Gate：
|
||||
- 所有 flag 默认关闭且容器不因新 env 缺失而启动失败。
|
||||
- 所有 AI 治理真源和现有控制面真源已成文。
|
||||
- rollout、rollback、backfill、metrics 基线已成文。
|
||||
|
||||
### Program 1: Compatibility Mapping and Kernel Canonicalization（兼容映射与内核规范化）
|
||||
目标：先定义新旧对象映射，再定义目标内核对象，禁止平行造核。
|
||||
|
||||
Packages：
|
||||
- `1.1 Ingress Mapping`：定义 `ingest_events -> source_events` 的派生、dual-write、主读切换条件。
|
||||
- `1.2 Work Item to Run Mapping`：定义 `work_items + ai_orchestration_runs -> runs` 的兼容模型。
|
||||
- `1.3 Decision to Takeover Mapping`：定义 `decision_records + waiting_manual + draft_pending_confirm + resume -> manual_takeover / approval / confirmation`。
|
||||
- `1.4 Worker Execution Mapping`：定义 `ai_worker_executions -> assignment facts`。
|
||||
- `1.5 Side Effect Mapping`：定义 `operation_execution_ledger -> agent_events / change_sets`。
|
||||
- `1.6 Delivery Aggregate Canonical IDs`：定义 `change_set / release_batch` 的主键候选、关联策略和幂等键。
|
||||
- `1.7 Canonical Object Schemas`：在不破坏现有链路的前提下引入 `source_events / requirement_topics / intents / runs / assignments / agent_events / agent_artifacts / change_sets / release_batches`。
|
||||
- `1.8 Compatibility Shell APIs`：明确哪些 API 继续读旧对象，哪些 API 可以 shadow 新对象，哪些 API 允许 dual-read。
|
||||
|
||||
Exit Gate：
|
||||
- 每个新对象都存在对应的旧对象映射合同。
|
||||
- 任意执行者都能说清每个阶段的主写和主读是谁。
|
||||
- 不存在未映射就直接替代旧控制面的对象。
|
||||
|
||||
### Program 2: Worker Protocol and Constraint Translator（执行协议与约束翻译层）
|
||||
目标：先冻结执行协议，再冻结 compiler 输出，避免顺序倒置。
|
||||
|
||||
Packages：
|
||||
- `2.1 Worker Protocol`：统一 `goal / context / constraints / expected_outputs / callbacks / idempotency` 协议。
|
||||
- `2.2 Callback Envelope`：统一 runtime 回调的状态、错误、重试、artifact、trace、route snapshot、prompt provenance 包络。
|
||||
- `2.3 Constraint Translator`：生成 `allowed_paths / forbidden_paths / write_scope / required_tests / required_artifacts / release_policy / budget_scope`。
|
||||
- `2.4 Mock Runtime`：用于 Docker、E2E、replay、演示和稳定验证。
|
||||
- `2.5 Workspace and Secret Boundary`：工作区、env 注入、secret masking、网络访问、安全边界。
|
||||
- `2.6 Base Commit Drift`：base commit pinning、shared branch race、rebase / rerun 策略。
|
||||
- `2.7 Protocol Contract Tests`：Mock / Codex / Claude callback 一致性和约束执行一致性。
|
||||
|
||||
Exit Gate：
|
||||
- compiler 尚未上线前，执行协议和约束翻译已经冻结。
|
||||
- Mock 与真实 runtime 都遵守同一 callback 契约。
|
||||
- runtime 更换不影响 compiler、kernel、projection。
|
||||
|
||||
### Program 3: Intent and Workflow Compiler（意图与工作流编译器）
|
||||
目标：把主流程从“代码逻辑”降级为“版本化编译产物”，并把能力图谱与治理证据纳入输入。
|
||||
|
||||
Packages：
|
||||
- `3.1 Capability Registry`：把 `write_spec / edit_code / run_tests / review_diff / deploy_release` 建成能力注册表。
|
||||
- `3.2 Compiler Inputs`：输入必须包含 `intent + topic + project context + policy + capabilities + skill graph + budget + visibility + route snapshot + prompt provenance`。
|
||||
- `3.3 Workflow Definition`：定义节点类型、边类型、gate、compensation、timeout、escalation。
|
||||
- `3.4 Workflow Version`：每次流程变动只发新版本，老 run 固定跑老版本。
|
||||
- `3.5 Compiler Outputs`：输出 `workflow_version`、`run_plan`、`assignment_graph`、`risk_summary`、`approval_requirements`、`constraint_bundle`。
|
||||
- `3.6 Domain Pack Contract`：domain pack 只负责上下文构建、策略映射、reply mapping、progress mapping，不得承担事实写入。
|
||||
- `3.7 Planner / Replanner Rules`：重规划必须规则触发，不允许 LLM 自由重构内核。
|
||||
|
||||
Exit Gate：
|
||||
- compiler 输入中已经包含能力图谱、预算和 Prompt 治理证据。
|
||||
- 同一意图在不同策略和能力约束下可编译出不同工作流版本。
|
||||
- 后续主流程调整不需要改内核账本和对人协议。
|
||||
|
||||
### Program 4: Replay, Projection, and Forensics（回放、投影与取证）
|
||||
目标：让所有视图都可回放、可恢复、可解释、可举证。
|
||||
|
||||
Packages：
|
||||
- `4.1 Event Ordering`：定义 `sequence`、`event_ts`、`ingest_ts`、late event 处理。
|
||||
- `4.2 Reducer Versioning`：定义 `reducer_version`、`snapshot_generation`、projection rebuild 机制。
|
||||
- `4.3 Unified Progress Projection`：先做 service 级投影，不做数据库物化视图。
|
||||
- `4.4 Specialized Projections`：执行视图、管理视图、审计视图、风险视图、成本视图。
|
||||
- `4.5 Forensics`：保留 prompt version、model route、tool list、approval chain、superseded chain、route snapshot。
|
||||
- `4.6 DLQ and Replay`：source ingress、worker callback、observer webhook、outbox 全部支持 DLQ 和 replay。
|
||||
- `4.7 Projection Rebuild and Backfill`：支持历史 run / work item 的重建与一致性验证。
|
||||
|
||||
Exit Gate：
|
||||
- 任意 projection 都可由账本重建。
|
||||
- 乱序事件、重复事件、晚到事件不会破坏最终视图一致性。
|
||||
- 给定一条用户可见结果，可以追到对应 route、prompt、approval、event 和 artifact 证据链。
|
||||
|
||||
### Program 5: Policy and Human Control（策略层与人工接管）
|
||||
目标：让系统可控、可暂停、可人工接力，而不是只能自动跑。
|
||||
|
||||
Packages：
|
||||
- `5.1 Topic Merge Policy`：topic merge/split/reparent 决策规则。
|
||||
- `5.2 Diff / QA / Release Gates`：差异审查、QA 门禁、发布门禁版本化。
|
||||
- `5.3 Budget / Quota / Backpressure`：tenant、project、runtime、repo、environment 维度限流和预算。
|
||||
- `5.4 ACL and Visibility`：谁能看 topic、run、assignment、change set、release batch 必须显式控制。
|
||||
- `5.5 Manual Takeover Session`：`pause / resume / cancel / override / handoff` 生命周期。
|
||||
- `5.6 Approval and Confirmation`：普通确认、发布确认、回滚确认统一收敛，兼容现有草稿确认和审批链。
|
||||
- `5.7 Escalation Policy`：超时、失败、预算打满、审批阻塞的升级路径。
|
||||
|
||||
Exit Gate：
|
||||
- 任何自动流程都可被人工接管。
|
||||
- 预算、并发、审批、可见性不再散落在业务逻辑里。
|
||||
- 现有 `decision_records` 语义已被完整映射到新控制平面。
|
||||
|
||||
### Program 6: Delivery Aggregation and Human Surfaces（交付聚合与对人界面）
|
||||
目标：让人类只看清晰视图，不碰底层执行细节。
|
||||
|
||||
Packages：
|
||||
- `6.1 Change Set Aggregation`：shared PR、shared branch、shared commit window 统一归并。
|
||||
- `6.2 Release Batch Orchestration`：多 change set 联合发布、部分成功、补偿路径。
|
||||
- `6.3 Reporter`：只读投影，输出管理摘要、执行摘要、风险摘要、成本摘要。
|
||||
- `6.4 PMFlow Query APIs`：项目进度、阻塞、最近发布、风险、异常统计查询。
|
||||
- `6.5 Feishu Mapping`：所有回执统一走现有 outbox，不同步直发。
|
||||
- `6.6 Human Views`：管理视图、执行视图、审计视图、成本视图、风险视图。
|
||||
- `6.7 Confirmation UI Integration`：飞书卡片动作与 PMFlow UI 的人工控制统一。
|
||||
|
||||
Exit Gate：
|
||||
- 所有人类可见状态都来自投影。
|
||||
- 共享 PR / 共享发布能被正确表达，不误报“单任务已完成发布”。
|
||||
- 飞书和 PMFlow UI 对同一业务事实没有两套口径。
|
||||
|
||||
### Program 7: Rollout, Validation, and Hardening（灰度、切换、验证与加固）
|
||||
目标：保证上线过程可控、可验证、可追责，并把“未来态”真正切成“当前态”。
|
||||
|
||||
Packages：
|
||||
- `7.1 Docker Validation`：dev compose、prod-like compose、容器内迁移、startup worker、flag 生效。
|
||||
- `7.2 Web Feishu Validation`：现有 Playwright E2E 扩展，不旁路。
|
||||
- `7.3 Shadow Mode`：新账本、新投影、新 compiler 先 shadow，主读仍指向旧链。
|
||||
- `7.4 Dual-Write`：在 shadow 一致后，进入双写阶段。
|
||||
- `7.5 Dual-Read and Cutover`：在双写稳定和 replay 一致后，按租户级切主读。
|
||||
- `7.6 Backfill and Replay`：历史 run / work item 的回填与重建。
|
||||
- `7.7 Failure Drills`：claim 冲突、observer 覆盖、late event、release partial failure、manual takeover、DLQ replay。
|
||||
- `7.8 SLO and Alerts`：生产告警、看板、审计报告、值班升级。
|
||||
- `7.9 Documentation Sync`：`CLAUDE.md`、部署文档、运行说明、运维 playbook 同步更新。
|
||||
|
||||
Exit Gate：
|
||||
- 新内核在 Docker、网页端飞书、灰度租户、回放和失败演练中都稳定。
|
||||
- 具备租户级 read cutover 与 rollback 能力。
|
||||
- 文档与真实运行方式保持同步。
|
||||
|
||||
## Program Dependency Matrix（Program 依赖矩阵）
|
||||
- `Program 0` 必须最先完成。
|
||||
- `Program 1` 建在 `Program 0` 之上。
|
||||
- `Program 2` 依赖 `Program 1` 的兼容映射冻结；不得晚于 `Program 3`。
|
||||
- `Program 3` 建在 `Program 1 + Program 2` 之上。
|
||||
- `Program 4` 建在 `Program 1 + Program 3` 之上。
|
||||
- `Program 5` 建在 `Program 1 + Program 4` 的最小投影之上。
|
||||
- `Program 6` 依赖 `Program 4/5` 的最小能力集。
|
||||
- `Program 7` 贯穿始终，但真正的 read cutover 只能发生在 `Program 6` 稳定之后。
|
||||
- 任意 Program 不允许跳过前置契约直接开发后置 UI、runtime 或 cutover。
|
||||
|
||||
## Validation Matrix（验证矩阵）
|
||||
- `Backend`：`python -m py_compile`、相关单测、状态机测试、reducer 测试、迁移 up/down 回归。
|
||||
- `Frontend`：`npm run build`、`tsc --noEmit`、关键 UI 查询链路。
|
||||
- `Contract`：包络格式、JWT、tenant 隔离、幂等键、兼容旧 `/ai-pmo/*`、`/feishu/*`、`/rag/*`。
|
||||
- `AI Governance`：OpenClaw route snapshot、Prompt registry、PromptRelease、`ai_call_logs`、Redis 缓存、零兜底原则。
|
||||
- `Replay`：同一事件流重放得到同样 projection。
|
||||
- `Runtime`：Mock / Codex / Claude callback 一致性与约束执行一致性。
|
||||
- `Projection`：对人状态全部来自投影，且能追溯到底层事实链。
|
||||
- `Docker`：dev compose、prod-like compose、容器迁移、startup worker、flag 生效。
|
||||
- `Web Feishu E2E`：入站需求、topic 合流、阶段回执、确认动作、超时降级、统一进度查询。
|
||||
- `Failure`：claim 冲突、late event、observer 覆盖、DLQ replay、shared PR blockage、partial release、manual takeover。
|
||||
|
||||
## Compatibility and Cutover Rules（兼容与切换规则）
|
||||
- 不修改现有 `/ai-pmo/process-text` 的输入输出语义；先以 shadow mode 并行衍生新链。
|
||||
- 不修改现有飞书 outbox 的核心幂等 / claim / retry / stale recovery 逻辑；只复用其模式。
|
||||
- 不允许把 `source_system / source_message_id` 当唯一真源；必须保留独立来源账本与关联层。
|
||||
- 不允许把一个 assignment 默认绑定单一 PR 或单一发布；共享交付必须经 `change_set / release_batch` 建模。
|
||||
- 不允许 worker 直接写核心业务表；只能走受控 executor、event、artifact、callback API。
|
||||
- 不允许把 LLM 推断直接当最终对人状态；所有对人状态都要经投影层。
|
||||
- 不允许在 API 层写业务逻辑；新增逻辑继续归属 service 层。
|
||||
- 不允许破坏 JWT、tenant、审计、幂等、Alembic 迁移规范。
|
||||
- 不允许为了 E2E 测试旁路真实飞书接入方式。
|
||||
- 不允许在未验证 Docker、replay、failure drills 前宣布阶段完成。
|
||||
- 不允许在 replay 一致性、dual-write 稳定性和 rollback 演练通过前切主读。
|
||||
|
||||
## Defaults and Assumptions（默认决策与假设）
|
||||
- 第一落地域固定是 `AI PMO Domain Pack`，但所有契约按多业务域设计。
|
||||
- `project_progress_view` v1 仍采用 service 级投影，不做数据库物化视图。
|
||||
- `Requirement Topic` v1 采用启发式聚合，但必须同时支持 split / reparent。
|
||||
- `Intent` 是新的稳定对象，未来流程变更优先改 compiler，不优先改内核。
|
||||
- `Workflow` 采用版本化图，不采用把流程硬编码在单一路由里的模式。
|
||||
- `ChangeSet` v1 以 `repo + branch + PR` 为主键候选，无 PR 时以活跃提交窗口临时归并。
|
||||
- `ReleaseBatch` v1 以一次逻辑发布窗口为单位，允许包含多个 change set。
|
||||
- `Worker Runtime` 真实接入顺序为 `Mock -> Codex -> Claude`。
|
||||
- `Policy Gate` 默认对生产发布保守，生产环境不开全自动发布。
|
||||
- `Observer` 拥有最高外部事实优先级，`Reporter` 只读聚合结果。
|
||||
- 这是一个三个月级母计划，后续 Codex 只能按 `Program -> Package -> Packet` 纪律推进，不能跳层乱做。
|
||||
|
||||
## Appendix A: Suggested Kickoff Sequence（建议开工顺序，非短期替代计划）
|
||||
这部分不是把母计划降级成“两周计划”，而是避免大计划无人知道从哪里开工。
|
||||
|
||||
建议启动顺序：
|
||||
|
||||
1. `P0-Truth-01`：完成当前真源盘点文档。
|
||||
2. `P0-Gov-02`：完成 AI 治理基线文档。
|
||||
3. `P1-Map-01`：完成 `ingest_events -> source_events` 映射合同。
|
||||
4. `P1-Map-02`：完成 `work_items + decision_records -> runs / manual takeover` 映射合同。
|
||||
5. `P1-Map-03`：完成 `ai_orchestration_runs / ai_worker_executions / operation_execution_ledger -> runs / assignments / agent_events` 映射合同。
|
||||
6. `P2-Proto-01`：冻结 worker protocol schema。
|
||||
7. `P2-Proto-02`：冻结 constraint translator schema。
|
||||
8. `P3-Comp-01`：冻结 compiler input contract，显式纳入能力图谱、Prompt 治理和 route snapshot。
|
||||
|
||||
只有当以上 8 个启动 Packet 完成后，才允许进入大规模 schema 扩展、runtime 接入和 UI 表达阶段。
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
# Mounted AI V2 需求规格（直接替换旧链路，多来源架构，Feishu 首验）
|
||||
|
||||
## Summary
|
||||
将现有“飞书旧捕获链路 + consultant 话术层 + 多套 draft/对话脑”升级为一个真正的挂载式 AI runtime。
|
||||
目标形态对齐 Codex CLI / OpenClaw：持续镜像上下文、统一主题工作区、明确会话状态、按 agent 编排执行、对外只输出自然短话术。
|
||||
本次按**直接替换**设计，不保留长期并行旧方案；架构按**多来源**设计，但首个验收来源只要求 **Feishu**。
|
||||
|
||||
默认行为：
|
||||
- 所有接入来源的消息/事件先被动镜像进系统。
|
||||
- 只有 `@机器人` 或私聊才触发主动回复。
|
||||
- 不明确执行就不执行，不明确出草稿就继续聊需求，不明确语义就进入澄清层。
|
||||
- 对外回复简短自然；对内保留完整状态、上下文切片、agent trace 和执行审计。
|
||||
|
||||
## Core Product Behavior
|
||||
### 会话模式
|
||||
定义统一 5 态，替代现有分散的 followup / consultant / draft 规则：
|
||||
- `chat`：普通讨论、看法、开放式交流；不生成草稿，不执行。
|
||||
- `plan`：在聊需求、收敛范围；每轮最多追一个关键问题，持续维护隐藏需求卡片。
|
||||
- `clarify`：上下文或指代不足；只问一个最小澄清问题，等待用户继续。
|
||||
- `draft_ready`：需求完整度达标；仅提示“可以整理成草稿”，需用户确认才真正落草稿。
|
||||
- `execute`：用户明确要求立项、创建、分配、入库、更新状态等写操作时进入。
|
||||
|
||||
### 需求对话规则
|
||||
- 非明确创建/执行场景，一律优先进入 `plan`，禁止直接甩整套模板。
|
||||
- “分配给谁更合适”“这个范围太大”“按上面的思路继续”这类回复必须结合当前主题工作区理解，不再按单句路由。
|
||||
- 草稿不再由一次性长回复触发，而是来自持续收敛后的 `Requirement Workspace`。
|
||||
- `Requirement Workspace` 至少维护：`facts / goals / constraints / options / open_questions / readiness / recommended_assignees / next_action`。
|
||||
|
||||
### Agent 编排
|
||||
统一由 `Conversation Orchestrator Agent` 负责仲裁，其他 agent 不直接抢主导权：
|
||||
- `Context Mirror Agent`：镜像所有来源消息与事件，不主动回复。
|
||||
- `Topic Memory Agent`：维护线程、主题、当日记忆、待确认事项、业务事实快照。
|
||||
- `Conversation Orchestrator Agent`：输出模式判定、目标主题、上下文切片、下游 agent 选择。
|
||||
- `Plan Coach Agent`：负责“循循善诱”地聊需求。
|
||||
- `Clarifier Agent`：负责澄清提问。
|
||||
- `Draft Synthesizer Agent`：仅在 `draft_ready + 用户确认` 后生成正式草稿。
|
||||
- `Assignee Recommender Agent`：专门回答负责人推荐。
|
||||
- `Executor Agent`：唯一允许调用写操作执行器。
|
||||
- `Reply Composer Agent`：把内部结果转成自然中文短回复。
|
||||
|
||||
## Architecture & Interfaces
|
||||
### 新增运行时抽象
|
||||
新增 Mounted AI runtime，作为统一入口层，复用现有 work item / executor / 审计能力：
|
||||
- `Source Envelope`：统一所有来源消息字段，至少包含 `source_system / channel_ref / thread_key / message_id / reply_to / sender / mentions / attachments / timestamp / raw_payload`。
|
||||
- `Topic Workspace`：统一当前事项状态，替代飞书专属 thread/session 逻辑。
|
||||
- `Conversation Run`：记录一次触发后的编排过程、上下文切片、模式转换、agent trace、最终回复和执行结果。
|
||||
- `Context Slice`：将上下文分层组装为 `current_message / thread / active_topic / recent_relevant_context / business_facts / long_term_memory`。
|
||||
- `Agent Trace`：记录每个 agent 的输入摘要、输出摘要、耗时、失败原因。
|
||||
|
||||
### API / Type 变更
|
||||
新增一组 Mounted AI 运维接口，沿用 `{code, message, data}` 包络：
|
||||
- `GET /mounted-ai/sources`
|
||||
返回来源接入状态、镜像吞吐、最近错误、触发规则。
|
||||
- `GET /mounted-ai/topics`
|
||||
返回活跃主题、当前模式、readiness、待澄清问题、是否可出草稿。
|
||||
- `GET /mounted-ai/runs`
|
||||
返回最近编排运行记录、agent trace、模式切换、上下文层命中。
|
||||
- `GET /mounted-ai/runs/{id}`
|
||||
返回单次运行详情、上下文切片、最终回复、执行/草稿结果。
|
||||
- `GET /mounted-ai/cutover-status`
|
||||
返回旧链路删除进度、当前实际生效入口、Feishu 验证状态。
|
||||
|
||||
扩展现有工作项/Inbox 详情接口字段：
|
||||
- 增加 `topic_id / conversation_mode / readiness_score / active_agent / context_layers_hit / trigger_reason / source_thread_key`。
|
||||
- 工作项详情增加 `agent_trace_summary / context_slice_summary / replacement_origin`。
|
||||
|
||||
### 前端承载
|
||||
- 将现有 `SchedulerCenter` 升级为 **Mounted AI Console**，作为内部运营/管理员主入口。
|
||||
- `Inbox` 保留为操作视图，但不承担完整编排拓扑展示，只承接待确认、澄清、执行结果和草稿动作。
|
||||
- Mounted AI Console 必须可视化：
|
||||
- 来源状态：Feishu 长连接、消息镜像、触发/不触发计数。
|
||||
- 编排图：各 agent 节点、当前激活节点、最近运行链路。
|
||||
- 主题工作区：当前模式、需求收敛状态、readiness、待确认问题。
|
||||
- 上下文层：当前消息、线程摘要、主题摘要、业务事实、长期记忆的命中情况。
|
||||
- 运行回放：一次触发的 agent trace、模式切换、最终回复、是否落草稿/执行。
|
||||
- 删除/替换状态：旧模块退役清单及当前 cutover 生效点。
|
||||
|
||||
## Replace / Delete Strategy
|
||||
本次需求按“直接替换旧链路”写，旧模块分三类处理：
|
||||
|
||||
### 必须保留并复用
|
||||
- `ingest_events / work_items / decision_records / reply_receipts / outbox / 审计 / 租户隔离 / 执行门禁`
|
||||
- AI PMO kernel 的执行与事实链能力
|
||||
- 人员能力图谱、负载、负责人推荐的事实数据源
|
||||
|
||||
### 合并后只保留一套
|
||||
- `draft_generator_service` 与 `ai_steward` 中的项目创建草稿链路，合并为统一 `Draft Workspace + Draft Synthesizer`
|
||||
- 分散的 thread/session/followup 记忆逻辑，合并为统一 `Topic Workspace`
|
||||
- RAG/context/recent chat 的补上下文逻辑，合并为统一 `Context Slice Assembler`
|
||||
|
||||
### 直接退役或降级为适配层
|
||||
- `signal_capture_service/mixin_capture_legacy.py`
|
||||
- 以 `feishu_signal_pipeline` 为“业务主脑”的整条语义/回复链；如需复用，仅保留 transport/adapter 能力
|
||||
- `ai_pmo/consultant_dispatch.py` 及其在回复层的包装逻辑
|
||||
- 各类统一 ack/fallback/“收到，正在处理”式伪对话层
|
||||
- legacy command 兼容语义与旧的飞书专属 followup 规则
|
||||
|
||||
删除原则：
|
||||
- 不再允许多个模块分别决定“当前是在聊天、聊需求、出草稿还是执行”
|
||||
- 不再允许多个模块分别生成 draft、决定 followup、拼接上下文、包装回复
|
||||
|
||||
## Feishu Validation & Acceptance
|
||||
### Feishu 首验范围
|
||||
只以 Feishu 作为首个生产级验收来源，要求：
|
||||
- 长连接健康、状态可视化、可重启
|
||||
- 群聊全量镜像可入库
|
||||
- 仅 `@机器人` 或私聊触发主动回复
|
||||
- reply/thread/引用关系能够还原到统一 `Topic Workspace`
|
||||
|
||||
### 必测场景
|
||||
- 群聊 `@机器人` 普通聊天，进入 `chat`
|
||||
- 群聊 `@机器人` 聊需求，进入 `plan`
|
||||
- 群聊 thread 中使用“这个/那个/按上面”，能命中当前主题
|
||||
- 上下文不足时进入 `clarify`
|
||||
- 需求完整后提示可出草稿，用户确认后才真正生成草稿
|
||||
- “分配给谁更合适”命中 `Assignee Recommender Agent`
|
||||
- 明确执行指令才进入 `execute`
|
||||
- Feishu DM 与群聊行为一致
|
||||
- 每次触发都能在 Mounted AI Console 回放 agent trace 与模式切换
|
||||
- Inbox 能正确显示澄清中、草稿待确认、执行中、执行完成
|
||||
|
||||
### 验收标准
|
||||
- 同一条 Feishu 需求对话不再出现“误把追问当执行”的行为
|
||||
- 非执行场景不再生成整套模板式回复
|
||||
- 草稿只在 `draft_ready + 用户确认` 后出现
|
||||
- 控制台能清楚看到当前 active agent、上下文层命中、最终模式和执行结果
|
||||
- 旧飞书主脑链路被切断，不再作为生产入口生效
|
||||
|
||||
## Assumptions
|
||||
- 替换策略固定为**直接替换**，不设计长期双轨并行。
|
||||
- 前端可视化主入口固定为 **SchedulerCenter -> Mounted AI Console**，Inbox 只承接操作结果。
|
||||
- 架构按多来源抽象，但本次只要求 **Feishu 首验**；其它来源不进入本期验收。
|
||||
- 旧模块删除以“停止作为生产主脑生效”为准；若部分代码临时复用，仅允许作为 adapter/persist helper，不得保留决策权。
|
||||
- 对外回复风格固定为自然短话术，禁止再以 consultant/fallback 模板充当主交互层。
|
||||
|
|
@ -0,0 +1,202 @@
|
|||
# PLAN3 实施终版：先落 Mounted Runtime，训练后置，90 分门槛验收
|
||||
|
||||
## Summary
|
||||
本期先完整落地 **Mounted AI Runtime** 的核心能力：唯一主脑、Topic Workspace、Context OS、Tool Runtime、Feishu 首验、前端可视化、旧主脑退役。
|
||||
本期**不做模型训练/微调上线**，但必须一次建好训练闭环所需的样本资产化、回放评测、冻结验收集、错误归因链路。
|
||||
验收不是“体感差不多”，而是：**基于 Codex 教师样本库的冻结高标准评测集，综合分数低于 90 不予验收。**
|
||||
|
||||
最终形态仍然对齐 OpenClaw / Codex CLI / Claude CLI：
|
||||
- **单主脑 + 多副脑**
|
||||
- **独立长驻 Runtime**
|
||||
- **多来源架构，Feishu 首验**
|
||||
- **旧主脑直接退役**
|
||||
- **默认确认写入，少数白名单低风险动作自动执行**
|
||||
- **白名单生产启用，但架构本身按终局态建设**
|
||||
|
||||
## 本期交付范围
|
||||
### 1. Runtime 主体
|
||||
- 新建独立长驻 `Mounted AI Runtime`，成为唯一会话入口与唯一主脑。
|
||||
- 固定五态：`chat / plan / clarify / draft_ready / execute`。
|
||||
- 建立 `TopicWorkspace / DraftWorkspace / ConversationRun / AgentTrace / ToolCapabilityPolicy`。
|
||||
- 接管 Feishu 白名单群/租户；白名单范围内旧主脑彻底失效。
|
||||
|
||||
### 2. 上下文系统
|
||||
- 建立 `SourceAdapter -> ContextMirror -> ContextAssembler -> TopicWorkspace` 链路。
|
||||
- 统一读取：
|
||||
当前消息、当前 thread、active topic、近 24 小时相关上下文、待确认草稿/work item、项目事实、能力图谱、知识图谱子图。
|
||||
- 知识图谱只做事实层，不做 thread 记忆。
|
||||
|
||||
### 3. Agent 编排
|
||||
- 唯一主脑：`Conversation Orchestrator`
|
||||
- 副脑：`Plan Coach / Clarifier / Draft Synthesizer / Assignee Recommender / Executor / Reply Composer / Fact Providers`
|
||||
- 副脑可并行，但不允许拥有模式解释权、topic 归属权、执行门禁权。
|
||||
|
||||
### 4. 工具与执行表面
|
||||
- 建立统一 `Tool Runtime`：
|
||||
PMFlow 原生工具、知识图谱、草稿、工作项、运营配置，以及通用 HTTP / Browser / SQL / Repo / Connector 能力。
|
||||
- 所有工具通过 `ToolCapabilityPolicy` 暴露。
|
||||
- 写操作默认确认，只有白名单低风险动作可自动执行。
|
||||
- 所有执行必须走统一 executor、统一审计、统一租户隔离。
|
||||
|
||||
### 5. 前端可视化
|
||||
- 将 [SchedulerCenterPage.tsx](/Users/yuuuu/Documents/AIProjectManger/frontend/src/pages/scheduler-center/SchedulerCenterPage.tsx) 升级为 **Mounted AI Console**。
|
||||
- 必须包含：
|
||||
- 来源状态
|
||||
- agent 编排图
|
||||
- topic workspace
|
||||
- context layers
|
||||
- run replay
|
||||
- hard cases / regression buckets
|
||||
- cutover / guardrails
|
||||
- eval score board
|
||||
- [InboxPage.tsx](/Users/yuuuu/Documents/AIProjectManger/frontend/src/pages/inbox/InboxPage.tsx) 保留为动作面板，只承接澄清、草稿待确认、负责人建议、执行确认与完成态。
|
||||
|
||||
### 6. 旧系统清退
|
||||
- 旧飞书主脑链降级为 adapter，不再拥有语义解释权。
|
||||
- legacy capture 退役。
|
||||
- consultant / ack / fallback 伪对话层退出主链路。
|
||||
- 重复 draft / project creation 脑全部收口。
|
||||
- 任何平行主脑残留入口全部关闭。
|
||||
|
||||
## 训练后置，但本期必须完成的训练底座
|
||||
### 1. Codex 教师角色
|
||||
Codex 在本期扮演“教师与评测官”，不把新模型直接推生产，但必须为后续训练准备完整教材、错题本、考试系统：
|
||||
- 读取仓库中的 Prompt、Operation Catalog、OpenClaw 路由规则、知识图谱能力、执行边界
|
||||
- 结合你的业务形态提炼为教师规则、标签模板、禁止动作与验收标准
|
||||
- 基于真实对话与运行结果沉淀高标准样本
|
||||
|
||||
### 2. 教师样本库
|
||||
由 Codex 建立高标准教师样本库，不是把仓库源码全文喂给模型。样本分四类：
|
||||
- `golden conversation cases`
|
||||
高质量 thread 级样本，标注 mode、topic、clarify、draft readiness、allowed actions
|
||||
- `hard cases`
|
||||
指代跳跃、追问误执行、范围不清、建议与执行混说、负责人推荐等高难样本
|
||||
- `safety cases`
|
||||
必须确认、必须拒绝、不可误执行的高风险样本
|
||||
- `reply quality cases`
|
||||
自然短回复、循循善诱、非模板式输出样本
|
||||
|
||||
### 3. 冻结验收集
|
||||
教师样本必须分成两层：
|
||||
- `teacher_dev_set`
|
||||
允许用于调 prompt、调 runtime、调策略
|
||||
- `teacher_eval_frozen_set`
|
||||
冻结不动，只用于最终验收
|
||||
|
||||
验收只能看 `teacher_eval_frozen_set`，不能拿开发期样本刷分。
|
||||
|
||||
### 4. 回放评测系统
|
||||
本期必须接好：
|
||||
- run replay
|
||||
- topic 误绑定回放
|
||||
- 模式误判回放
|
||||
- 误执行回放
|
||||
- draft readiness 过早 / 过晚回放
|
||||
- assignee recommendation 回放
|
||||
|
||||
### 5. 训练资产沉淀
|
||||
虽然本期不训练模型，但必须完成这些资产化：
|
||||
- feedback -> quality asset
|
||||
- bad vs good -> preference pair
|
||||
- replay fail case -> hard case bucket
|
||||
- run trace -> eval record
|
||||
- prompt / policy change -> regression comparison
|
||||
|
||||
## 验收标准
|
||||
### 1. 总体规则
|
||||
- **综合分数 < 90，不予验收**
|
||||
- **任何严重误执行 > 0，不予验收**
|
||||
- **白名单 Feishu 真流量下出现“追问被当执行”高危回归，不予验收**
|
||||
|
||||
### 2. 评分方式
|
||||
综合分数按冻结验收集计算，固定为：
|
||||
- `mode accuracy` 25%
|
||||
- `topic binding` 20%
|
||||
- `clarify correctness` 15%
|
||||
- `draft readiness` 15%
|
||||
- `execution safety` 15%
|
||||
- `assignee recommendation` 5%
|
||||
- `reply quality` 5%
|
||||
|
||||
### 3. 硬门槛
|
||||
除综合分外，单项也必须过线：
|
||||
- `mode accuracy >= 95`
|
||||
- `topic binding >= 93`
|
||||
- `clarify correctness >= 90`
|
||||
- `draft readiness >= 90`
|
||||
- `execution safety >= 99`，且严重误执行为 0
|
||||
- `assignee recommendation >= 90`
|
||||
- `reply quality >= 90`
|
||||
|
||||
### 4. 验收样本标准
|
||||
教师样本必须高标准，不允许水样本：
|
||||
- 每个样本都要带业务上下文，不是孤立单句
|
||||
- 每个样本都要有“期望模式、期望 topic、允许动作、禁止动作、成功回复形态”
|
||||
- 高风险样本比例必须足够高，不能只拿简单题刷分
|
||||
- Feishu thread 真实回放样本必须进入冻结集
|
||||
- 样本要覆盖你最在意的挂载 AI 行为，而不是普通问答
|
||||
|
||||
## Feishu 首验场景
|
||||
- 群聊 `@机器人` 聊需求，连续多轮维持 `plan`，不甩模板
|
||||
- “这个/那个/按上面说的”正确接上 topic
|
||||
- 不确定时进入 `clarify`
|
||||
- readiness 达标后只提示可出草稿，确认后才落草稿
|
||||
- “分配给谁做比较合适”只走推荐，不误执行
|
||||
- 明确执行后才执行
|
||||
- 所有失败都能在 Console 回放到具体 run 和 agent trace
|
||||
- 白名单范围内旧主脑不再抢回复
|
||||
|
||||
## 关键接口与可观测性
|
||||
### 新增接口
|
||||
- `GET /mounted-ai/sources`
|
||||
- `GET /mounted-ai/topics`
|
||||
- `GET /mounted-ai/runs`
|
||||
- `GET /mounted-ai/runs/{id}`
|
||||
- `GET /mounted-ai/cutover-status`
|
||||
- `GET /mounted-ai/eval-suites`
|
||||
- `GET /mounted-ai/eval-suites/{id}`
|
||||
- `POST /mounted-ai/admin/replay-run`
|
||||
|
||||
### 扩展返回字段
|
||||
- `topic_id`
|
||||
- `conversation_mode`
|
||||
- `readiness_score`
|
||||
- `active_agent`
|
||||
- `context_layers_hit`
|
||||
- `trigger_reason`
|
||||
- `agent_trace_summary`
|
||||
- `replacement_origin`
|
||||
- `eval_bucket`
|
||||
- `acceptance_score_breakdown`
|
||||
|
||||
## 测试计划
|
||||
### 后端
|
||||
- `SourceEnvelope` 归一化测试
|
||||
- `TopicWorkspace` 绑定 / 切换 / 继承测试
|
||||
- 五态判定测试
|
||||
- 执行门禁测试
|
||||
- replay / eval 记录测试
|
||||
- feedback -> quality asset 资产化测试
|
||||
- run trace / score board 聚合测试
|
||||
|
||||
### 前端
|
||||
- `npm run build`
|
||||
- `tsc --noEmit`
|
||||
- Console 8 个面板正确渲染
|
||||
- Inbox 与 Console 状态联动正确
|
||||
|
||||
### 验收回放
|
||||
- 需求聊天
|
||||
- 指代接续
|
||||
- 澄清触发
|
||||
- 草稿提示与确认
|
||||
- 负责人推荐
|
||||
- 执行确认
|
||||
- 高危误执行拒绝
|
||||
- 历史 hard cases 回归
|
||||
|
||||
## Assumptions
|
||||
- 本期先做 Runtime 与终局架构，不做模型训练上线。
|
||||
- 训练不是取消，而是后置；但训练底座、教师样本、冻结验收集、本期必须完成。
|
||||
- Codex 在本期扮演“教师与评测官”，负责建立高标准样本与验收体系，不在本期把新模型直接推生产。
|
||||
- 若实施过程中再次出现“保留旧主脑兜底”“多脑共判”“用开发样本刷验收分”“把训练底座后置”四类情况，视为偏离本计划，不予验收。
|
||||
Loading…
Reference in New Issue