46 KiB
46 KiB
ARCHITECTURE INVENTORY
1. 目的
- 本文档承接 PMFlow 的架构库存与关键入口索引。
CLAUDE.md保留当前架构说明、运行边界和参考模式。- 本文档记录当前模块分布、重要子包、关键脚本与前端页面分组,后续架构变更统一在此同步。
2. 同步规则
- 任何影响目录结构、主入口、模块归属、前后端页面/API 分组、脚本布局的架构变更,都必须同步更新:
CLAUDE.mddocs/architecture/ARCHITECTURE_INVENTORY.md
- API/Schema 契约变更仍需同步:
docs/architecture/API_CONTRACTS.md- 对应前端
types/api封装
- 路由/函数名/运行时流向变更仍需同步:
docs/architecture/DATAFLOW.mdbackend/.control_plane/pmflow-routing-rules.json
3. 顶层库存
docs/PMFLOW_PRODUCT_BLUEPRINT.md:PMFlow 产品蓝图真源;锁定“对话驱动的 AI 产品执行操作系统”、solo-first, team-ready、项目真相层、ChangeSet 待确认、Execution Bridge 与人机混编团队方向docs/PMFLOW_PRODUCT_DELIVERY_STANDARD.md:PMFlow 产品推进执行标准;记录当前进度、Phase A-F 推进顺序、单次任务范围、Codex 并行推进协议、进度台账和新线程接续规则docs/PMFLOW_UI_CONTRACT.md:PMFlow UI 契约真源;锁定 Logo、浅色白底 +#2463EB、移动端固定底部导航、四类视觉语法、核心功能 canonical 契约和当前前端一致性审计docs/INBOX_INLINE_OPS_3_PHASE_CHECKLIST.md:消息台内联操作执行清单docs/architecture/MASTER_CONTRACT.md:跨栈主契约docs/architecture/CODE_REFERENCE_INDEX.md:新增代码参考入口与高频代码索引docs/architecture/PMFLOW_OS_PRODUCT_CONTRACT.md:PMFlow OS 产品合同真源;锁定前端ProjectTruthState / ChangeSet / Evidence / Approval / ExecutionContext与后端truth_nodes / tasks / semantic_facts / ai_project_control / dev_sync的复用边界;Phase C1 已实现 review 表和审查 API,Phase C2 backend/frontend 已实现 atomic commitdocs/architecture/RUNTIME_GUARDRAILS.md:运行边界、守门规则与已知运行假设docs/architecture/API_CONTRACTS.md:接口/Schema 契约docs/architecture/DATAFLOW.md:主链与数据流说明docs/architecture/TASK_BRIEF_TEMPLATE.md:并行安全任务包模板;用于声明 Packet 的base_ref / read_scope / write_scope / forbidden_paths / shared_files / verification / docs_to_syncdocs/superpowers/plans/:实现计划docs/superpowers/specs/:需求/方案规格docs/task_briefs/:任务包产物与验收截图
4. 后端库存
4.1 API 路由分组
backend/app/api/ai_steward_api/backend/app/api/ai_pmo_api/backend/app/api/feishu_api/backend/app/api/rag_api/backend/app/api/sstc_api/backend/app/api/pmflow_launch_api/backend/app/api/pmflow_os_api/backend/app/api/signals_api/backend/app/api/signal_sources_api/backend/app/api/semantic_facts_api/backend/app/api/skill_tags_api/backend/app/api/ai_logs_api/
4.2 AI PMO 与语义主链
backend/app/services/ai_pmo/ai_pmo_kernel/backend/app/services/ai_pmo/ai_pmo_kernel_ingress_flow/backend/app/services/ai_pmo/project_operating_context_builder.pybackend/app/services/ai_pmo/ai_pmo_typed_executor_execute/backend/app/services/ai_pmo/ai_pmo_typed_executor_discovery/backend/app/services/ai_pmo/semantic_context/backend/app/services/ai_pmo/workflow_semantic_planner/backend/app/services/ai_pmo/draft_confirm_handler.py
4.3 问答、模型与生成
backend/app/services/adaptive_rag_service/backend/app/services/adaptive_rag_service/internal_query_context.pybackend/app/services/adaptive_rag_service/mixin_project_fit_brief.pybackend/app/services/adaptive_rag_service/mixin_query_route_gateway.pybackend/app/services/adaptive_rag_service/mixin_query_route_governance.pybackend/app/schemas/project_operating_context.pybackend/app/services/external_query_service/backend/app/services/semantic_fact_service/backend/app/services/semantic_fact_service/hooks.pybackend/app/services/llm_service/backend/app/services/ai_steward_service/backend/app/services/feedback_center/backend/app/services/task_brief_service.pybackend/app/config/ai_prompts.pybackend/app/config/ai_prompts_catalog/backend/app/config/ai_prompt_registry.pybackend/app/services/model/model_routing/service.pybackend/app/services/model/model_config.py
4.4 集成、信号与运行时
backend/app/services/integrations/feishu_integration_service/backend/app/services/integrations/feishu_outbox/service.pybackend/app/services/integrations/feishu_signal_pipeline/backend/app/services/signal/signal_capture_service/backend/app/services/signal/signal_source_orchestration/backend/app/services/signal/signal_source_repair/backend/app/services/signal/signal_planner/backend/app/services/signal/draft_generator_service.pybackend/app/core/startup/backend/app/utils/thread_context.pybackend/app/utils/timezone.pybackend/app/utils/audited_write.pybackend/alembic/versions/backend/app/main.py现已把模型连通性探测、飞书长连接、World Model 预热、调度器与后台队列消费收口为显式环境开关;开发环境可直接通过STARTUP_*/FEISHU_LONG_CONNECTION_ENABLED关闭重型副作用,避免热重载每次都付全量启动成本。backend/app/api/router.py现改为按模块路径动态注册路由;默认保持full,并支持通过API_ROUTE_PROFILE与API_OPTIONAL_ROUTE_GROUPS在开发场景下裁掉重型 optional route group,减少 eager import 开销。
4.5 Mounted Runtime / 训练相关
backend/app/models/reply_iteration.pybackend/app/models/training_pipeline.pybackend/app/models/mounted_ai_runtime.pybackend/app/models/query_route_memory.pybackend/app/models/semantic_fact.pybackend/app/models/semantic_fact_extraction_run.pybackend/app/models/pmflow_launch.pybackend/app/models/pmflow_change_review.pybackend/app/api/ai_steward_api/routes_reply_iteration.pybackend/app/api/ai_steward_api/routes_training_pipeline.pybackend/app/api/ai_steward_api/routes_mounted_ai.py
4.6 结构归并结果
backend/app/services/根目录已目录化收敛,新增服务优先进入对应子包。- API canonical 入口优先使用
*_api/子包,不再优先引用顶层兼容壳。 - 运行时业务动作归因优先走“对象/上下文绑定 ->
SemanticContextPacket->SemanticDecision-> gatekeeper”。 - non-plan
query.answer现已在AdaptiveRAG内增加Query Route Gateway:只消费上游单次结构化query_profile/source_policy/effective_source_policy与显式 hint,结合ProjectOperatingContext归一化产出route_mode / decision_origin / reply_contract / probe_snapshot(contract audit) / execution_recipe,不再在运行时执行 internal/external probe 或 route memory 强拍板,再进入检索与回答主链。 - query semantics 上游真源也已继续收口:
PROMPT_RAG_QUERY_SEMANTICS+mixin_core_intent.py现在只把query_profile(needs_private_context, needs_freshness, confidence)与BusinessSemanticFrame写回运行时,subject_focus / query_profile.referenced_objects已从 production backend 移除,不再参与 route snapshot、session scope continuity 或任何 read-side 分流。 WorkflowSemanticPlanner冷启动 bundle 现已补上四挡interaction_boundary合同:decision_schema.py定义InteractionBoundaryPacket / AnswerControlDecision / SelfReviewResult,planner 会把显式status / recommendation / draft / execute边界与识别出的workflow_plans合成answer_control,并把requested_level / forbidden_levels / effective_level / blocked_workflows落进 bundle diagnostics。对“只给建议/先别出草稿”这类 recommendation-only 问法,planner 允许识别到底层signal_source_flow,但最终会按 boundary 把 bundle 降回query_flow,避免误滑到draft_pending_confirm;旧的无 boundary bundle 仍走兼容透传,不会压坏既有写链路。AdaptiveRAG与 AI PMO 主链里几个最容易回流硬语义的入口也已继续收口:project progress fast answer 只按结构化interaction_level / goal_kind / resource_role / expected_answer_shape决定是否绕开 fast path;casual chat 直答只消费message_intent=casual_chat的结构化结果;typed executor 对project_lookup直答只认结构化message_intent=project_lookup(_question) + query_semantics,不再被项目列表/项目清单/项目#123这类词面带偏;signal 数量和“先分析再入库”这类分析模式也只读requested_count / analysis_mode / operation_intent_contract,不再从自然语言里额外解析“3个信号/先分析后入库”。- internal config 这条 read-side 也继续结构化了:
AdaptiveRAGTargetResolutionMixin不再把泛化resource_role=config自动映射成config:system,必须依赖显式object_binding区分config:model_routing与config:mcp_template_center;对应的 deep guard 直答也拆成模型路由和 MCP 配置两个子口径。 - 项目化影响判断不再必须依赖外部实时抓取才能保住“直接影响”那一行:
AdaptiveRAGFastAnswerProjectMainMixin现在会根据goal_kind=impact_judgment / expected_answer_shape=impact_chain保留结构化external_impact渲染,避免 WMS/税控/评论流这类高频影响问法退回普通项目周报。 AdaptiveRAG的 follow-up clarification 现在也继续往结构化真源收:mixin_followup_anchor.py不再在 runtime 用“第几条/标签名/最近回复 match_text”去消费pending_clarification;query_route_selection / followup_anchor_selection都先经过统一结构化澄清解析,再把选中的source_policy_hint / query_semantics_overrides / selected_qa_id透回mixin_answer_mainline.py。这样用户说“内部那个 / 第二条”后,主链会带着明确的 route override 或 anchor QA id 继续,不会再把原问题拿回去后靠最近回复词面重猜。- internal
Operation Contract / Target Resolver已按 business-frame-first 收口:mixin_target_resolution.py现在只消费goal_kind / target_scope / resource_role / project_binding / object_binding / expected_answer_shape来判定project / task / signal / config / feature / doc / user绑定,不再让subject_focus / referenced_objects这类 coarse 字段单独拍板内部对象类型。 - internal object/domain clarify 继续往下一层时,当前由
backend/app/services/adaptive_rag_service/internal_domain_catalog.py提供 catalog 真源;catalog 已覆盖project / task / signal / config / feature / doc / user这批 internal domain。mixin_target_resolution.py会在只确认大域(如resource_role=config或resource_role=doc)但尚未唯一落到子对象时生成candidate_summary,mixin_answer_payload.py/mixin_answer_precheck.py/mixin_followup_anchor.py再把它转成internal_target_selectionpending clarification,并在 follow-up 后回填query_semantics_overrides继续主链。 AdaptiveRAGread-side 那批旧 compatibility consumer 也已一起收口:shared_utils.py统一提供BusinessSemanticFrame -> structured entity/project binding归一化,mixin_deterministic_query_core.py、mixin_fast_answer_project_main.py、mixin_fast_answer_semantic_p1.py、mixin_deterministic_query_count.py、mixin_deterministic_query_list.py、mixin_retrieval_router_db.py、mixin_deep_guard_answer.py、mixin_answer_mainline.py、mixin_manifest_feature_p2.py现在只看这层结构化结果决定project / task / signal / config / feature / doc / user的快答、检索、deep guard 与 internal query plan,不再读取subject_focus / referenced_objects做二次业务分流。ProjectOperatingContext当前由project_operating_context_builder.py统一组装:最小范围固定为“当前项目 + 当前仓库摘要 + 页面/线程锚点”;world model 建完后会回填resolved_project_id / repo_scope,再供Query Route Gateway、mixin_project_fit_brief.py与 answer payload 消费。analysis_packet现作为单独的 analysis layer 增量接到问答主链:analysis_packets.py定义project_fit_analysis / external_impact_analysis / internal_explain_analysis / followup_explain_analysis这组 typed packet,analysis_packet_builder.py只消费ProjectOperatingContext / ExecutionRecipe / fit_brief / external_recommendation / InternalContextPacket / clarification等 runtime truth 组包,不从回答正文反推。当前 richer packet 会把current_subject / candidate_position / rejected_position / reason_chain这类对象级分析字段显式落盘,避免 presenter 再用泛句补戏;共享 richer project snapshot 由analysis_project_snapshot_loader.py统一补tasks/signals + description/summary + analysis_object_refs,供 AdaptiveRAG payload 和 Feishu presenter 复用。最新 snapshot loader 已 fail-closed:没有真实结构锚点时,不再从 task/signal 标题描述推fit_candidate_* / fit_rejected_* / primary_*关系,也不再生成task_signal_scores / signal_task_links这类 token-overlap 产物;builder 主路径只消费显式 object ref、精确文本绑定和唯一候选这三类非语义结构证据。analysis_packet_builder.py里原来那层“工程任务/信号源占位/展示层”词面 second-guess 已继续收掉:generic fallback、direct-match generic 分支和 internal explain target fallback 现在都不再靠_looks_like_engineering_task / _looks_like_signal_placeholder / _task_presentation_hint / token-overlap / partial-name match去反驳上游对象关系;没有显式 ref 时只能诚实降级,最多允许“唯一候选”这种纯结构兜底。- internal
query.answer的下一阶段基线已经确认:Query Route Gateway之后不再直接靠快答分支拍板,而是统一进入Operation Contract -> Target Resolver -> Query DSL Plan -> InternalContextPacket -> 白名单受控执行器 -> semantic facts 优先 -> verifier主链;InternalContextPacket由backend/app/services/adaptive_rag_service/internal_query_context.py定义,并作为 internal executor / verifier / runtime summary 的运行时单一真源;相关设计规格见docs/superpowers/specs/2026-04-15-internal-query-dsl-plan-design.md与docs/superpowers/specs/2026-04-15-semantic-facts-read-model-design.md。 - internal 主链现已补上 packet 预检:
mixin_answer_mainline.py在组完InternalContextPacket后,会先拦截missing packet / missing operation contract / target clarify / missing query plan contract这类上下文不完整场景,再决定是否进入 deterministic fast path、internal model-config fast path、GLM semantic fast path 或 retrieval;query_semantics对operation_contract / target_resolution / query_plan的镜像也已收口到单点兼容写回。 - external
query.answer已完成 second-pass 收口:Query Route Gateway之后统一进入backend/app/services/external_query_service/,按ProjectFitBrief -> External Query Planner -> External Query Gateway -> External Provider Registry -> MCP adapter 优先 -> bounded fallback live search -> external answer verifier -> ExternalContextPacket -> ExternalAnswerPresenter执行;planner 会显式消费fit_brief_summary / project_scope_hint / recommendation_goal / project_object_anchors / signal_source_objectives,其中 formal object anchors 优先来自ProjectFitBrief.signal_source_anchors,项目任务目标锚点来自ProjectFitBrief.signal_source_objectives,不再拿 feature capability 名称或固定类别模板直接冒充 formal project object;payload 会拆出fit_brief / external_recommendation,AdaptiveRAG external probe、freshness fetch 与 external route retrieval 已接到这条链上,并对 external sources 执行 fail-closed 过滤。当前 planner 还补了 recommendation query seed guard:命中“推荐外部信号源”问法时,会优先把当前项目任务目标和 formal anchor 驱动的 query 排到search_queries前面,避免 structured planner 用industry best practices / external data sources这类泛化词覆盖掉更贴当前项目的 seed query;同时interaction_level=recommendation会从统一语义规划层经answer_control/source_policy_hint透传到ExternalQueryPlan,recommendation 分支不再由 presenter 本地 cue list 单独拍板。presenter.py使用独立 external-only prompt 家族,并强制区分verifier_blocked / no_relevant_results / retrieval_failed / indirect_only,不再回流industry_trend/external_trendscene prompt;对 recommendation ask,presenter 现在会先生成SignalSourceRecommendationPacket(candidates + caveat),再渲染成业务中文的1/2/3候选建议,确保输出真的贴当前项目对象,而不是只靠自由文本兜一句“先看上游输入”。同时仍保留 overclaim guard:当结构化候选或文本里出现百分比、已确认、无需验证等高确定性措辞时,会 fail-closed 回退到 customer-safe candidate 文案。相关设计规格见docs/superpowers/specs/2026-04-15-external-query-gateway-design.md。 - non-plan recommendation -> signal-source write 当前已补齐结构 carry-over:external recommendation 不再只返回文本,
SignalSourceRecommendationPacket里的 candidate set 绑定会经reply_anchor_qa_context + action_contract一路沉到signal_source.onboard执行结果,并在 follow-up把推荐的写进系统 / 确认入库时由mixin_followup_project_signal_resume.py重建回operation_intent_contract(candidate_set_binding/candidate_refs/project_binding)。signal_source.onboard直写链会在 signal 已 materialize 且项目关联成功后把业务结果视为succeeded,同时仅通过post_process_status / signal_source_workflow.status暴露后续 onboarding/manual 状态;ai_pmo_reply_renderer.py也会把批量 signal source 直写回执渲染成自然业务中文,而不是 requirement draft 或 pending-manual 漂移文案。 - QA session detail 持久化现已补齐
routing_snapshot.response_payload:mixin_core_intent.py在写QARecord时会把project_operating_context / execution_recipe / fit_brief / external_recommendation / analysis_packet / handoff_mode / can_enter_plan / recommended_next_step一并归档,mixin_qa_session_list_ops_p1.py再将其投影给 AI Steward 历史回放,避免即时回答与 session detail 出现两套合同。 - Feishu QA 呈现现与共享 analysis packet 对齐:
mixin_receive_routing.py会先基于project_operating_context读取当前项目实体快照,再调用analysis_packet_builder.py生成共享analysis_packet,之后才进入“受控改写 -> blocked-entity 校验 -> deterministic fallback”的渠道 presenter。运行时会同时校验 fixed opener、标签摘要、内部 packet 术语(如analysis_packet / missing_mapping / next_step / focus_objects / reason_chain)以及未入选实体泄漏;若任一条件不满足,则 fail-closed 回退到 packet-based deterministic 文本。同时保留draft_pending_confirm / requirement_plan_followup / pending_manual优先走 action card,避免把飞书回归修成单纯文案 bypass。最新qa_direct还新增了一层中文化 presentation policy:内部现状问题若原始 answer 泄出Project database / signal_total / 当前盘面 / 建议动作 / External Freshness Guard这类英文或内部术语,会优先回退成共享 packet 文本,并最多只追加一行中文来源说明;外部信号源 recommendation ask 若已有推荐正文,则优先直出推荐正文,再补同样的中文来源说明;对 sparse project-fit 这类 packet,deterministic fallback 也会转成人话解释,不再原样暴露 packet 缺口字段。 - Feishu
project.create预填与 QA fallback 现继续去 lexical 化:project create 相关字段不再由_extract_project_scope / _extract_project_intent_fields / _is_contextual_project_request / heuristic_*之类 helper 从用户原话里扣词,而统一消费_extract_project_prefill()的结构化suggested_name / suggested_description / suggested_scope;QA fallback 也不再用_pick_feishu_entity_by_keywords按“摘要/拉取/推送”等关键词挑实体,改成只按共享 packet/select entity 的结构顺序兜底。 analysis_packet_builder.py的 sparse project-fit fallback 也往结构化真源继续收:当前如果preferred/rejected对象缺失,会直接按“结构对象缺失”降级,不再靠“解释层/当前主链”这类占位词表决定 sparse fallback 分支。- unified handoff 当前补有最小 rollback guard:
shared_utils.py提供 env flag 解析,mixin_query_route_gateway.py/mixin_answer_retrieval.py/mixin_answer_payload.py分别支持独立关闭execution_recipe增强、fit_brief + external_recommendation构建、以及默认offer_after_answer呈现,不需要回退 ingress/context 真源。 analysis_packet当前也带独立 rollout guard:PMFLOW_ENABLE_ANALYSIS_PACKET_FAMILY=0时,AdaptiveRAG payload / session replay / Feishu presenter 会回退到旧 handoff truth + 旧 presenter,避免影响project_operating_context / execution_recipe / fit_brief / external_recommendation真源。query.answer的客户可见回答展示也已确认独立基线:运行时证据必须拆成customer_safe与admin_debug双视图,客户侧统一消费中文化display_label,禁止直接暴露raw_source_label、机器来源或内部术语;external answer presenter 的 prompt 输入也必须保持 external-only,仅允许消费经 verifier 通过的外部证据摘要与计划摘要;相关设计规格见docs/superpowers/specs/2026-04-15-answer-presentation-policy-design.md。- 下一阶段的全量业务结构化基线已确认:在
InteractionBoundaryPacket / AnswerControlDecision之上继续引入BusinessSemanticFrame、AnswerShapeContract、RecommendationCandidateSet、ClarificationDelta / CorrectionDelta与OperationIntentContract,把 recommendation、clarification/correction、casual chat、non-planmode direct signal-source write 统一收口到同一语义真源;并以 58 条广覆盖业务语义矩阵作为完整回归基线、以docs/superpowers/specs/2026-04-20-business-golden20-refresh.md里的 20 条当前项目池黄金案例作为日常 P0/P1 spot check 集。 semantic_fact_service已升级为统一基线:semantic_facts / semantic_fact_extraction_runs读模型、ORM 提交钩子自动收集对象变更并 upsertingest_events(channel=semantic_fact_extract)、统一 worker 抽取/失活,以及 internal query 的 facts-first 主路径。- semantic facts 自动抽取覆盖
project / task / signal / document / user / requirement(charter) / release / review八类业务对象;manual retry 与 backfill 走同一队列、同一 worker,不再开旁路。 - MCP 模板接入中心已接入
backend/app/api/mcp_api/+backend/app/services/mcp_config/:租户内统一保存 MCP 模板 catalog、server 配置 bundle、命令预览、validate 结果、runtime probe 与pending_local_apply / user_confirmed / not_required状态;backend_direct模板既支持远程streamable_http(如microsoft_learn),也支持后端内建backend_adapterruntime(如duckduckgo),本地stdio模板只输出 Local Bridge/兼容 host 接入说明,服务端不直写客户机器~/.codex/config.toml。 query_route_memories作为独立路由记忆表,承接QARecord的 route audit、feedback 回灌和离线评估样本,不复用原 answer-quality 资产表。query_route_memories现已补 manager-only 只读治理入口:backend/app/api/rag_api/routes_route_governance.py+mixin_query_route_governance.py负责/rag/query-route-governance/summary|items|items/{id},统一暴露reply_contract / probe_snapshot / query_profile / feedback_outcome审计快照,但 v1 不做在线自动调路由。backend/tests/test_runtime_structured_semantics_contract.py与backend/tests/test_feishu_pipeline_queue_contract.py共同守门 runtime 结构化语义收口,锁定飞书入口、signal capture、reply/runtime routing 不得回流旧词法拍板 helper。backend/tests/test_external_query_planner.py现已补进 external fallback 回归,锁定 planner fallback 只能产出 generic external plan,不得再根据weather/news/public_model/...之类对象映射在运行时硬分 query_kind。
5. 前端库存
5.1 页面分组
frontend/src/pages/inbox/frontend/src/pages/ai-steward/frontend/src/pages/scheduler-center/frontend/src/pages/project-board/frontend/src/pages/projects/frontend/src/pages/users/frontend/src/pages/recipes/frontend/src/pages/feishu-config/frontend/src/pages/ai-config/frontend/src/pages/model-routing-config/frontend/src/pages/ai-config/mcp-config/frontend/src/pages/query-route-governance/frontend/src/pages/task-brief-center/frontend/src/pages/task-brief-runs/frontend/src/pages/task-brief-template/frontend/src/pages/charter-detail/frontend/src/pages/contract-sync-board/frontend/src/pages/dashboard/frontend/src/pages/knowledge-graph-context-board/frontend/src/pages/semantic-facts-board/frontend/src/pages/login/frontend/src/components/login/frontend/src/features/pmflow-os/pages/frontend/src/features/pmflow-os/components/frontend/src/features/account-settings/frontend/src/features/personal-space/components/frontend/src/pages/skill-tasks/frontend/src/pages/skills/frontend/src/pages/user-profile/frontend/src/pages/user-skills/frontend/src/pages/workload-detail/frontend/src/pages/workloads/
5.2 API 与共享模块
frontend/src/api/aiPmo.tsfrontend/src/api/aiSteward.tsfrontend/src/components/marketing/frontend/src/components/login/frontend/src/components/layout/LazyBoundary.tsxfrontend/src/components/ai-steward/frontend/src/components/ai-steward/QAConversationStatusBar.tsxfrontend/src/components/ai-steward/QAResponseMetaCard.tsxfrontend/src/components/ai-steward/QAResponseMetaCard.test.tsx- AI Steward 问答浮窗现分三层显性化:
FloatingQAChat.tsx负责即时回答/历史回放归一化,QAConversationStatusBar.tsx展示对象/来源/仓库/执行通道/plan handoff,QAResponseMetaCard.tsx展示fit_brief / external_recommendation / recommended_next_step,对应前端回归由FloatingQAChat.test.tsx与QAResponseMetaCard.test.tsx锁定。 - 登录页与营销页仍共享
frontend/src/components/marketing/的部分视觉基线;公开登录页现改由frontend/src/components/login/目录承载,其中LoginExperience.tsx负责登录壳层、LoginWorkflowVisual.tsx负责左侧场景、loginScene.ts/loginMath.ts拆出展示配置与路径几何、login.css负责登录页专属样式边界,frontend/src/pages/login/LoginPage.tsx继续负责真实鉴权、错误态和 redirect 提示;未登录访问/会经frontend/src/router/index.tsx直接重定向到/login,无显式redirect的成功登录现在默认进入/command-center。 - 前端主包治理已切到“同步首屏最小集 + route/page-section lazy”模式:
frontend/src/router/index.tsx保留LoginPage / Layout这组同步入口,其余后台重页面通过React.lazy + Suspense懒加载;统一 fallback 在frontend/src/components/layout/LazyBoundary.tsx。P0 公共壳冻结后,大模块 route 归属为:/space归 Space lane,/project-launch是启动层入口,/pmflow-os与/command-center / /change-review / /execution-bridge / /release-growth归 Main Flow lane,/me归 Account Settings lane,/settings当前仅为 reserved route、尚未实现,新增必须由 Shell / Integration owner 串行处理。frontend/src/features/personal-space/作为空间层入口,通过/space提供可直接打开的本地预览入口,承载继续推进、待我确认、AI 正在推进、暂存想法、草案箱与新建项目入口。frontend/src/features/project-launch/作为首次进入页 / 新项目启动台产品域,通过/project-launch提供可直接打开的入口;Phase B 后默认调用真实pmflow-launchdraft/confirm API,创建成功态主动作跳转后端返回的/pmflow-os?projectId=<id>,只有显式?demo=1或?dataSource=demo才启用本地 mock 状态机。frontend/src/features/account-settings/作为 Account Settings 产品域,通过/me提供个人资料、默认语言、AI 回答深度、证据展示偏好、待确认/执行回写/发布门禁/失败提醒通知偏好和账户操作入口;该域通过frontend/src/api/accountSettings.ts建立前端合同,有 token 时优先调用已挂入backend/app/api/router.py的backend/app/api/account_settings_api/GET /account-settings/me/PUT /account-settings/me同步当前账号偏好,后端不可用时明确回落本机暂存,不修改 OAuth/JWT/auth core。frontend/src/features/pmflow-os/作为新产品域,通过PMFlowOsProvider在应用根部挂载共享 truth store,并提供CommandCenter / ChangeReview / WorkGraph / ExecutionBridge / ReleaseGrowth / TeamLayer / ProjectMemory / Account主入口;当前 PMFlow OS 页面已切到专属轻壳,桌面端默认隐藏旧 TopBar,并由frontend/src/features/pmflow-os/components/PMFlowOsFrame.tsx统一承接“左侧稳定导航 + 顶部上下文条 + 中央视图 + 右侧 AI 副驾”的全局骨架,同时承接项目内个人空间 / 当前项目名面包屑和项目切换器;账号退出登录由frontend/src/features/pmflow-os/components/AccountControls.tsx统一承接桌面头像下拉、退出确认与移动端 bottom sheet,frontend/src/features/pmflow-os/pages/AccountPage.tsx提供/me入口并委托 Account Settings 域渲染设置页;正式应用壳移动端底部导航统一由frontend/src/features/pmflow-os/components/MobileBottomNav.tsx承接,固定为空间 / 指挥台 / 待确认 / 动态 / 我的,其中动态当前仍是/command-center占位。/command-center额外提供免登录产品预览壳,/pmflow-os是真实项目上下文 alias。主视觉按#2463EB + 白色的 Linear-like 高密度原型展开。UsersPage把创建/删除/重置/导入/批量分配对话框拆为按需 chunk,UserSkillsPage与WorkloadDetailPage的图表也分别拆到了frontend/src/pages/user-skills/components/UserSkillsRadarPanel.tsx与frontend/src/pages/workload-detail/components/WorkloadTrendChart.tsx。 frontend/src/features/personal-space/PersonalSpacePage.tsx是空间首页视图层,frontend/src/api/space.ts是空间工作面只读聚合 API:从projectssummary、PMFlow OStruth-state与execution-summary生成继续推进、待确认、发布关注、执行中 / AI 正在推进、暂存想法、草案箱、最近项目摘要;Space P3 的releaseAttention优先消费truth-state.releases中由 release validation run 投影出的 release 状态与检查项,把“发布验证阻塞 / 发布验证待确认”显示到/space,没有发布验证投影时才回落到execution-summary.releaseGate的发布候选或发布门禁阻塞;发布验证缺失时显示明确空态,不虚构验证结果。项目主动作进入/pmflow-os?projectId=<id>,待确认项进入/change-review?projectId=<id>&changeSetId=<id>,发布关注项进入/release-growth?projectId=<id>,执行中项进入/execution-bridge?projectId=<id>;暂存想法后端只读聚合尚未接入时只显示 empty/warning,不使用 mock 数据冒充真实内容;移动端为空间首页独立 App 布局,不直接压缩桌面卡片,并保留最近项目区块;frontend/src/pages/PersonalSpacePage.tsx是薄入口。该域只表达个人空间和主流程导航,不做团队空间强切换、企业组织管理、Project Memory 写入、ChangeSet 状态写入、ProgressEvent 写入、ReleaseValidationRun 写入或发布执行。frontend/src/features/project-launch/types.ts、mockData.ts、useProjectLaunchState.ts是新项目启动台状态层;默认真实模式通过frontend/src/api/pmflowLaunch.ts生成草案并确认创建真实项目,API 失败进入明确失败态,不静默 fallback 成 mock 成功;mockData.ts仅在显式?demo=1或?dataSource=demo下作为演示状态机使用。components/LaunchShell.tsx负责桌面/移动分流,桌面端复用frontend/src/features/personal-space/components/SpaceChrome.tsx的空间左侧栏和顶部条,LaunchCanvases.tsx和MobileLaunchLayout.tsx承接高保真图中的意图输入、AI 工作、人类确认、草案修改、生成失败、创建成功过渡与移动端 bottom sheet 交互。frontend/src/features/account-settings/AccountSettingsPanel.tsx是/me设置页实现:桌面端为个人资料摘要 + 分区设置面板,移动端为分组列表 +MobileBottomSheet编辑;当前覆盖个人资料、默认语言、AI 回答深度、证据展示偏好、待确认、执行回写、发布门禁和失败提醒通知偏好,并在通知偏好区展示页面内提醒消费说明。frontend/src/api/accountSettings.ts是前端合同层;有 token 时优先调用backend/app/api/account_settings_api/,失败时回落浏览器本机暂存;P2 新增shouldShowAccountNotification与getAccountNotificationConsumption,将四类通知偏好映射为本地 UI 的待确认、Execution Bridge、Release/Growth 和失败提醒显示/静默状态;P3 新增getReleaseGateNotificationPreference(settings, event),把 Release/Growth 的release_gate_* / release_validation_*事件映射到releaseGate偏好,把failed_event映射到failureAlert偏好,并返回inAppEnabled / desktopPreference / emailDigestPreference供后续 Main Flow 页面消费。该合同不代表邮件、桌面推送或系统通知中心已接入。backend/app/schemas/account_settings.py定义账号偏好合同,backend/app/services/account_settings_service.py当前复用既有integrations表按tenant_id + user_id保存account_settings_preferences配置包,backend/app/api/router.py已挂载该 API;未改用户表、OAuth/JWT/auth core 或 PMFlow OS truth store。frontend/src/features/pmflow-os/store.tsx当前是 PMFlow OS 共享 truth store:?projectId=<id>时通过 React Query 调用frontend/src/api/pmflowOs.ts读取真实GET /pmflow-os/projects/{project_id}/truth-state与GET /pmflow-os/projects/{project_id}/execution-summary,真实模式下项目内 message、proposed_itemsextraction、ChangeItemaccept/edit/defer、ChangeSet commit、Execution Handoff create/consume、execution progress writeback、release validation run create 与 release feedback ingest 均调用/pmflow-os后端并 refetch;只有显式?demo=1或?dataSource=demo时才启用本地 mock 演示状态机。真实读取/动作失败会进入错误/空态,不静默 fallback 成 mock 成功。frontend/src/features/pmflow-os/store.tsx仍保留演示用项目内 AI 结构化闭环状态机:command_idle / ai_extracting / extraction_ready / review_open / writeback_success。frontend/src/features/pmflow-os/pages/StructuredExtractionPage.tsx是本轮结构化提取页,ChangeReviewPage.tsx是决策与待确认中心,MemoryWritebackResultPage.tsx是项目记忆写入结果页,WorkGraphPage.tsx是项目工作台关系总览与对象投影视图,ExecutionBridgePage.tsx是执行桥上下文包、交接按钮、运行端领取确认、PR/测试与回写状态页;ReleaseGrowthPage.tsx真实模式读取execution-summary.releaseGate、latestValidationRun与releaseSignals,从 branch、commit、PR、test、failed evidence 展示可发布 / 阻塞 / 需要人工确认 / 缺少证据判断、阻塞原因、下一步动作、发布验证记录和发布后 feedback/revenue/recommendation 信号,缺少发布后信号时显示 empty/warning,不执行发布命令、不展示 mock 发布结果;同时读取 Account notification preference helper,用releaseGate偏好控制发布门禁强调提醒,用failureAlert偏好控制失败强调提醒,偏好关闭时只静默提醒表达强度,不隐藏 release evidence、阻塞原因、审计状态、validation run 或 releaseSignals;静态发布/增长原型只保留在显式 demo 模式。A3 已接入后端 truth-state,C1 已接入真实 message/extraction/review 状态机,C2 已接入真实 ChangeSet commit,Phase D 已接入真实 execution-summary/dev-sync,D.2 已接入POST /execution-handoffs创建 PromptPackage + handoff_created progress event,P1 已接入POST /execution-handoffs/{prompt_package_id}/consume创建 handoff_consumed progress event 并把 execution status 投影为 coding,Release Growth P1 已接入 execution evidence gate,Release Validation P1 已接入POST /release-validation-runs创建ReleaseValidationRun快照,Release Feedback P1 已接入POST /release-feedback-ingests写入FeedbackIngest并生成IterationRecommendation;当前仍不调用真实 AI 提取,不把 mock 当真实失败 fallback。ProjectMemoryPage.tsx在真实模式下展示后端truth_nodes + semantic_facts的projectMemory投影,accepted/edited ChangeItem 只有 commit 成功后才进入 Project Memory。frontend/src/features/pmflow-os/components/ProjectStructuredLoop.tsx提供StatusLabel / EvidenceSnippet / ObjectChangeCard / ProjectConversationPanel / StructuredExtractionPanel / ProjectAICopilotPanel等闭环组件,并复用契约化InlineNotice表达“未确认不得写入”的局部提示。- PMFlow OS 后端入口位于
backend/app/api/pmflow_os_api/,projection service 位于backend/app/services/pmflow_os_projection_service.py,Change Review / commit 服务位于backend/app/services/pmflow_change_review_service.py,Pydantic 合同位于backend/app/schemas/pmflow_os.py;当前聚合truth_nodes / tasks / semantic_facts / ai_project_control / dev_sync,Thread / Message来自pmflow_threads / pmflow_thread_messages,ChangeSet / ChangeItem / Approval / EvidenceLink来自backend/app/models/pmflow_change_review.py对应真实表。C1 已实现 message、proposed_itemsextraction、ChangeSet detail、ChangeItemaccept/edit/defer;C2 backend/frontend 已实现POST /pmflow-os/change-sets/{change_set_id}/commit与真实模式前端接入,默认 atomic,将Requirement / Decision / Risk写入truth_nodes,将Task写入truth_nodes(node_type='task') + tasks,高风险项强制 approval gate;D.2 已实现POST /pmflow-os/projects/{project_id}/execution-handoffs,校验 task/repo project 边界,生成/复用PromptPackage(package_kind='execution_handoff')并写ProgressEvent(event_type='handoff_created')起点;P1 已实现POST /pmflow-os/projects/{project_id}/execution-handoffs/{prompt_package_id}/consume,校验 execution handoff package 后更新PromptPackage.package_payload.latest_handoff.handoff_state=consumed并写ProgressEvent(event_type='handoff_consumed', derived_task_status='coding');Release Growth P1 在ExecutionSummaryProjection.releaseGate中从ProgressEvent推导发布门禁状态,失败事件 fail-closed 阻塞发布,无证据返回 empty/warning;Release Validation P1 新增POST /pmflow-os/projects/{project_id}/release-validation-runs,复用现有ReleaseValidationRun模型固化当前releaseGate快照、人工决策、证据、阻塞原因和下一步动作,并在releaseGate.latestValidationRun返回最新记录;Release Feedback P1 新增POST /pmflow-os/projects/{project_id}/release-feedback-ingests,复用现有FeedbackIngest / IterationRecommendation,在ExecutionSummaryProjection.releaseSignals中返回真实发布后 feedback、revenue event 和 iteration recommendation 读模型;这些步骤都不直接执行本机命令、真实发布命令、外部支付或真实推送;ModelDecision / MetricSignal在 C2 V1 仍 fail-closed。 - PMFlow Launch 后端 Phase B 创建链位于
backend/app/api/pmflow_launch_api/、backend/app/services/pmflow_launch_service.py、backend/app/schemas/pmflow_launch.py与backend/app/models/pmflow_launch.py;POST /pmflow-launch/drafts只写pmflow_launch_drafts,POST /pmflow-launch/drafts/{draft_id}/confirm在同一事务内写projects / user_projects / pmflow_threads / pmflow_thread_messages / truth_nodes / tasks / semantic_facts seed / operation_logs,并把launch_draft_id / thread_id / thread_message_id写入正式对象 metadata。 frontend/src/features/pmflow-os/components/ChangeReviewGroup.tsx、WorkbenchPanel.tsx、ExecutionBridgeCards.tsx、PMFlowOsFrame.tsx、AccountControls.tsx、FeedbackPrimitives.tsx是高保真原型新增的行为组件层:分别承载变更 diff 审查块、工作台对象卡组、执行桥上下文/日志卡片、全局上下文条与 AI 副驾、账号菜单/退出登录确认交互,以及PageBanner / InlineNotice / HumanDecisionBar / ConfirmDialog / MobileBottomSheet这组提示、提醒、确认与移动端 bottom sheet 基础组件,避免再把这些业务片段内联塞回pages/。frontend/vite.config.ts现补了固定 vendor chunk 分组(framework / state-query / ui-radix / icons / charts / markdown)与业务 chunk 分组(ai-steward / sstc / governance),目标是让登录页与基础导航不再背 AI Steward、SSTC、治理页和图表代码。- 旧登录残留
frontend/src/components/ui/sign-in.tsx与frontend/src/components/ui/demo.tsx已删除,frontend/src/components/login/成为唯一登录实现真源。 - 前端开发链路已按职责拆分:
docker-compose.dev.yml下的 Vite 热更新开发前端固定占用5174,静态生产预览前端默认改为5175;frontend/scripts/dev-entrypoint.sh避免每次容器启动都执行npm ci,frontend/scripts/login-live-check.mjs与package.json中的verify:login-fast / verify:login-responsive / verify:login-full、capture:login:matrix作为登录页快回路验证入口,截图产物统一落到frontend/output/login/。 frontend/src/api/taskBriefs.tsfrontend/src/api/modelRouting.tsfrontend/src/api/mcp.tsfrontend/src/api/knowledgeGraph.tsfrontend/src/api/semanticFacts.tsfrontend/src/api/queryRouteGovernance.tsfrontend/src/api/mountedAi.tsfrontend/src/api/feedbackCenter.tsfrontend/src/api/sstc.tsfrontend/src/components/inbox/frontend/src/components/sstc/frontend/src/pages/scheduler-center/components/frontend/src/pages/ai-steward/components/frontend/src/lib/
5.3 前端结构边界
- 页面级编排逻辑优先收敛到
pages/*/子目录。 - API 调用统一走
frontend/src/api/,不在页面或组件内直接fetch。 frontend/src/components/sstc/继续作为 SSTC 共享组件目录维护。- AI Steward 浮窗的“当前对象/来源模式/证据状态”必须直接消费
/rag/ask与 QA session API 的显式 contract 字段,禁止在前端靠回答正文反推 internal/external 或 plan 状态。 - 网页问答显式锚点 v1 只能消费稳定强锚点:项目页路径中的
project_id与 URL query 中已显式存在的project_id/source_chat_id;前端禁止自行猜测source_chat_id。 AI Config -> Governance Tools现新增/ai-config/mcp-config、/ai-config/query-route-governance与/ai-config/semantic-facts-board入口;三类治理页都只对BOSS/ADMIN开放。MCP 页负责模板化配置、后端直连/Local Bridge 状态展示、runtime probe、命令预览与本机确认;route/context 页负责 mismatch、clarify-heavy 与 negative feedback 样本排查;semantic facts 页负责 KPI、队列、对象表与详情抽屉。- PMFlow OS 原型页是前端独立产品域,不复用
AI Steward/Project Board的旧信息架构;新页面只允许消费frontend/src/features/pmflow-os/store.tsx的共享状态和行为组件,避免把原型再拖回 SSTC/治理后台语义。个人空间首页、新项目启动台和 Account Settings 同样是独立产品域:Space 只能通过frontend/src/api/space.ts做项目摘要、PMFlow OStruth-state / execution-summary的只读聚合并跳回主流程;Project Launch 默认走真实 draft/confirm 创建链,只有显式 demo 参数才使用本地状态机;Account Settings 只管理个人资料、偏好和通知,不改 OAuth/JWT/auth core、PMFlow OS truth store、Project Memory、ChangeSet 或 Execution Bridge 写回。
6. 工具与运行库存
backend/scripts/repair_requirement_plan_history.pyscripts/start_model_probe.shscripts/model_probe.pyscripts/gen_task_brief.shscripts/check_contract_sync.shfrontend/playwright.config.tsfrontend/vitest.setup.tsfrontend/e2e/feishu-project-full-flow.spec.tsfrontend/scripts/dev-entrypoint.shfrontend/scripts/login-live-check.mjs- 前端到后端访问链路已收敛为同源
/api:开发环境由 Vite proxy 转发,生产环境由 nginx/api反代;临时外网访问脚本与浏览器侧绝对 API base 配置已移除。
7. 维护建议
- 想看“现在怎么跑、边界怎么定”:先看
AGENTS.md,再看CLAUDE.md - 想看“模块都搬到哪里了、目录怎么分组”:看本文档
- 想看“接口/数据流契约”:看
docs/architecture/API_CONTRACTS.md与docs/architecture/DATAFLOW.md