PMFlow/docs/architecture/PMFLOW_AI_MULTI_AGENT_OPERATING_RUNTIME.md

PMFlow AI Agent OS Runtime

1. Purpose

This document is the target architecture for PMFlow AI after removing the old /ask -> answer center.

PMFlow AI is not a smarter classifier, a fixed answer template, or a single chat bubble. The target is an Agent OS behind a Codex-style thread product: the user sees one continuous thread, each user message creates an internal durable agent run, the runtime binds the workspace, plans the next step, executes read/probe/agent tools, stores observations, verifies the result, recovers when needed, learns from the cycle, and only then composes the customer answer from verified state.

The current implementation has moved past the first Agent OS shell. The user-visible truth source is still pmflow_ai_threads / pmflow_ai_messages; pmflow_agent_runs is the execution truth source for each assistant turn; QARecord remains transcript/history only. The product runtime is now mission-first: each assistant turn creates an OperatingMission, assigns specialist agents, compiles a council-reviewed operating decision, projects product objects, prepares execution/confirmation packets, and writes learning/next-cycle signals before customer projection.

2. Canonical Chain

PMFlow AI
  -> Thread Workspace
  -> User Message
  -> Agent Run Workspace
  -> Operating Mission
  -> Stage / Deliverable / Action Ladder
  -> Mission Workspace
  -> Specialist Agent Registry
  -> Parallel / Sequential Specialist Work Products
  -> Evidence + Artifact Ledger
  -> Agent Council / Critic
  -> Product Object Projection
  -> Action Ladder + Human Review Gate
  -> Execution Bridge Preparation
  -> Outcome Observation
  -> Learning Ledger + Next Cycle Trigger
  -> Customer Payload

Compatibility endpoints may still return chat-shaped payloads, but they must be projections of the PMFlow AI Thread + Agent OS Run model.

3. Non-Goals

• Do not build another prompt router or answer classifier.
• Do not let QARecord, answer_type, answer_shape, route_plan, source_strategy, allowed_executors, task_type or frontend UI state decide the run.
• Do not restore keyword routing, regex routing, looks_like_* helpers, scene enums, or hard-coded business stage lists.
• Do not expose project_object_required_for_world_state, world_state, packet, trace, prompt, function, route_plan, table names, raw field names, model/provider details, or English reasoning to customers.
• Do not show fixed five-step progress. Process display must come from real persisted Agent OS steps.
• Do not expose Run, raw run status, step ids, target refs, verification ids, passed, final_answer, or other execution identifiers in the default PMFlow AI user interface.
• Do not keep the right-bottom chat bubble as the product surface. The product surface is /space/pmflow-ai.

4. Core Runtime Objects

PMFlow AI Thread

pmflow_ai_threads is the user-visible PMFlow AI truth source. One thread contains a continuous conversation and can span many agent runs. The left sidebar lists threads, not runs.

PMFlow AI Message

pmflow_ai_messages stores user and assistant messages in a thread. Assistant messages carry a customer-safe projection:

• final answer text
• collapsible work log
• inline artifacts
• inline action candidates
• inline confirmation requests

It does not expose raw step ids, verification records, provider traces or internal object-gap labels.

Agent Run

pmflow_agent_runs is the execution truth source for one assistant turn.

It stores tenant/user/thread/session, goal, status, final answer, runtime policy, source endpoint and customer-safe payload. Runs are not the primary user-navigation object.

Operating Mission

PMFlowAIOperatingMission upgrades the raw user message from a question into a business operating task. It includes mission_goal, stage, desired_business_outcome, target_objects, required_agents, deliverable_type, action_ladder_level, success_criteria, blocked_boundaries and next_cycle_policy.

Specialist Agent Registry

PMFlowAIOperatingAgentRegistry is the canonical specialist contract surface. Current registered roles are:

• idea_incubation_agent
• market_research_agent
• competitor_agent
• product_strategy_agent
• mvp_scope_agent
• tech_architect_agent
• pm_breakdown_agent
• qa_risk_agent
• growth_agent
• monetization_agent
• learning_agent

Each contract declares input contract, output artifact, allowed tools, write permissions, autonomy limit, critic checks and customer-safe projection. Selection comes from OperatingMission and project/object scope, not keyword routing.

Product Object Projection

PMFlowAIProductObjectProjection turns specialist outputs into PMFlow business objects before answer projection. Supported object families are IdeaSeed, ResearchNote, OpportunityBrief, ProductHypothesis, MVPOption, RequirementDraft, ChangeSetDraft, TaskDraft, ExecutionPackage, QAPlan, ReleaseSignal, GrowthExperiment and RevenueSignal. These are draft/customer-safe projections until explicit confirmation moves them into the relevant product chain.

Agent Step

pmflow_agent_steps records every planned/executed step:

• operating mission / workspace snapshot
• planner actions
• read/probe tools selected from AGENT_TOOL_CONTRACTS
• external public search
• project operating state reads
• specialist work product generation
• council review and autonomy gate
• product object / execution preparation / learning projection
• critic checks
• answer runtime

Steps are not UI decorations. They are the persisted execution trace customers can inspect in a product-safe form.

Observation

pmflow_agent_observations stores read/probe results as facts, candidates, gaps, and context observations. Tools return observations and artifacts, not final answers.

Artifact

pmflow_agent_artifacts stores product object projections, specialist work products, council summaries, prepared action packets, confirmation requests, research notes and other durable run outputs.

Verification

pmflow_agent_verifications stores step verification, blocked reasons, recovery decisions, role checks and customer-answer safety checks.

Memory

pmflow_agent_memories stores learning and next-cycle signals that can be consumed by future runs. QA transcript is historical conversation; Agent memory is the operational state layer.

5. Implemented Packet Landing

Packet 1: Mission Runtime

Implemented:

• backend/app/schemas/pmflow_ai_operating_runtime.py::PMFlowAIOperatingMission now carries stage, desired_business_outcome, target_objects, deliverable_type, action_ladder_level, blocked_boundaries and next_cycle_policy.
• backend/app/services/pmflow_ai_operating_runtime/mission_service.py uses PROMPT_PMFLOW_AI_OPERATING_MISSION through Prompt Runtime when available, with a conservative mission-first fallback.
• Unbound open opportunities default to research/opportunity missions and project-bound turns default to project operating missions. Both produce specialist assignments and product-object-ready success criteria instead of a plain answer target.

Packet 2: Specialist Agent Registry

Implemented:

• backend/app/services/pmflow_ai_operating_runtime/agent_registry.py replaces the old six-role project-only set with 11 specialist contracts: idea, market research, competitor, product strategy, MVP scope, tech architect, PM breakdown, QA/risk, growth, monetization and learning.
• backend/app/services/pmflow_ai_operating_runtime/specialist_agents.py produces role-specific work products with claims, recommendations, prepared actions, blocked actions, evidence refs and verification.
• Market research is now a recovery-capable specialist, not a normalizer wrapper. External search observations from the inner evidence loop are promoted into external_research_evidence on the operating world state; the market_research_agent consumes source candidates, usable claims and research gaps to decide whether a ResearchNote is ready or whether the next action is read-only research recovery.
• Legacy pmflow_agent_runtime/specialists.py remains only for the old compatibility loop and tests; it is not the /space/pmflow-ai product main controller.

Packet 3: Orchestrator + Council

Implemented:

• backend/app/services/pmflow_ai_operating_runtime/run_service.py is now the default delegate from PMFlowAgentRuntimeService.
• backend/app/services/pmflow_ai_operating_runtime/council.py reviews role outputs, detects blocked role products, risk vetoes, priority competition and evidence boundaries, then compiles one priority order.
• PROMPT_PMFLOW_AI_OPERATING_COUNCIL is registered for prompt operations; deterministic council logic remains the safe baseline and no keyword/scene route is introduced.

Packet 4: Product Object Projection

Implemented:

• PMFlowAIProductObjectProjection projects specialist artifacts into OpportunityBrief, ResearchNote, MVPOption, TaskDraft, GrowthExperiment, RevenueSignal and related object families.
• operating_plan.product_object_projections, command_payload.product_object_projections, operating_run_packet.product_object_projections and agent_os_product_object_projections are all sanitized customer-safe payload fields.
• Product objects are draft/proposed outputs until user confirmation; they do not write Project Memory, commit ChangeSet, create tasks or start execution.
• Open market/opportunity turns must not jump to OpportunityBrief from shallow evidence. If ResearchNote.evidence_state.ready_for_opportunity_brief=false, the projection remains a draft ResearchNote with source plan, gaps and boundaries; the prepared action family is research_recovery, not a project write or execution handoff.

Packet 5: Execution Bridge Deepening

Implemented:

• ExecutionPreparationService now emits execution_bridge_handoff_preparation.v1 inside PMFlowAIExecutionPreparation.handoff_package.
• The handoff package includes execution_capability_graph, prompt_package_contract and result_writeback_contract(protocol_version=execution_result_protocol_v1).
• Execution preparations remain prepared_waiting_confirmation until the user clicks a confirmation action. Confirmed handoffs are executed through POST /space/pmflow-ai/threads/{thread_id}/confirmations/{confirmation_id}/execute, which resolves the persisted action contract server-side and then calls PMFlow OS create_execution_handoff; it does not trust frontend-built prompts or payload-only writes.
• Inline confirmation requests are action contracts, not decorative warning cards. Customer-safe confirmations now carry action_label / action_type / action_payload / can_execute; continue_research starts another read-only PMFlow AI turn with the compiled source plan and re-enters observe/specialist/council, save_candidate writes only to the pre-project saved idea chain, and start_execution_handoff creates a PMFlow OS prompt package for a formal task.
• Execution Bridge result writeback remains outside the backend command runner. External runtimes pull packages and report results through signed PMFlow OS runtime endpoints (/pmflow-os/runtime/execution-packages, /pmflow-os/runtime/execution-results); the next PMFlow AI project re-observation reads execution_progress from the PMFlow OS projection instead of relying on chat transcript.

Packet 6: Learning + Next Cycle

Implemented:

• OperatingCycleService consumes previous operating_learning_ledger capsules and writes outcome observations for pending confirmations, experiments, execution preparations and user preference signals.
• Learning items now capture operating_partner_not_qa, single_priority_order, product_object_first, source-effectiveness policy and risk threshold.
• next_cycle_triggers include user turn, signal, execution result, daily review, weekly strategy review and task update when confirmation state changes.

6. Legacy 5-Step Foundation

Step 1: Agent OS Truth Source

Implemented:

• Durable tables in backend/app/models/pmflow_agent_runtime.py and migration backend/alembic/versions/20260513_add_pmflow_agent_runtime.py.
• Durable PMFlow AI thread/message tables in backend/alembic/versions/20260513_add_pmflow_ai_threads.py.
• backend/app/services/pmflow_agent_runtime/service.py::PMFlowAgentRuntimeService creates the durable run first, delegates product execution to PMFlowAIOperatingRunService, then persists the real operating/process steps, observations, artifacts, verifications and memories.
• GET /space/pmflow-ai/threads, POST /space/pmflow-ai/threads, GET /space/pmflow-ai/threads/{thread_id} and POST /space/pmflow-ai/threads/{thread_id}/messages expose the user-facing PMFlow AI product surface.
• /space/pmflow-ai/runs* remains compatibility/debug surface only. Product UI must not use runs as the primary conversation list.
• POST /space/ai-concierge/ask is compatibility only and enters the same PMFlowAgentRuntimeService.run_space_turn() path.
• Thread payloads return thread_id / messages / assistant_message; each assistant message contains answer, work log, inline artifacts, action candidates and confirmations.

Required behavior:

• 你是谁 creates a run with capability observation and does not read project world state.
• 现在有哪些项目 creates a space observation.
• 这个项目怎么推进 reads project world state only when a strong project anchor exists.
• QARecord is transcript/history, not the thread or run truth source.

Step 2: Evidence Observe-Plan-Act-Critic Loop

Implemented through backend/app/services/pmflow_ai_agent_runtime/agent_run_service.py. This loop is now an evidence/answer adapter inside the operating runtime, not the Space PMFlow AI mission owner.

The loop runs:

understand_goal -> GoalFrame -> workspace snapshot -> LLM step planner -> selected read/probe tool -> observation ledger -> universal evidence normalizer -> claim/boundary/action ledger -> state critic -> recover/continue/stop -> answer runtime

Rules:

• The planner chooses from typed AGENT_TOOL_CONTRACTS; it must not use keyword routers, fixed executor enums or old answer contracts.
• The state critic treats the GoalFrame as the acceptance test. A step can pass only if normalized claims/boundaries/gaps move the run toward that goal.
• If a user asks for market/current public information, the planner can select external_search; the evidence normalizer must turn public material into usable claims or source-quality boundaries before the answer runtime can use it.
• External research recovery is part of the main loop, not a UI retry. When source detail fetch fails, source quality is blocked, or no claim enters the ledger, the runtime must first read untried ranked sources from the same observation; only when no candidate remains may it re-search from the GoalFrame evidence gaps. A failed first URL must not abort the whole source batch.
• The pre-research loop must close before downstream objects advance: search -> read -> normalize -> critic -> recover -> re-read -> re-normalize -> ResearchNote. LLM normalizer output is not allowed to suppress deterministic source extraction; if the LLM only returns noisy/gap diagnostics but the customer-safe source text contains gated facts, the deterministic extraction wins and the diagnostics are retained as gaps. Chinese numeric/time evidence such as 2025年, %, 亿/万元 must count as substantive signal after quality gates.
• Source quality is enforced at fragment level, not page level. A fetched page may contain navigation, ads, login copy or other shell text, but only clean fragments with substantive business signals may enter the Claim Ledger. Page shells, short title-only fragments, HTML entity noise, link-dense text, markdown/table composites and generic source-candidate statements remain blocked from claims. A year alone does not qualify as a ResearchNote claim; it must be paired with adoption, budget, attendance, revenue, growth, risk, forecast or another customer-useful signal. Candidate sources can remain visible as research candidates, but final answers and ResearchNote readiness consume only gated claims.
• Search provider synthesized answer text is not source evidence. If a provider returns multiple URL candidates and one generated summary, the generated summary must not be copied into every source snippet. external_public_evidence observations are source candidates only; they can create source plans and boundaries, but cannot create ResearchNote claims until inspect_source_detail reads source text and the normalizer extracts clean source-bound facts.
• Critic veto is a hard control gate. When the critic says ready_to_answer=false and a retry/read would change state, the answer runtime must not override it because there are partial directional claims. The runtime must either continue recovery with the next read/research action or return a blocked/recover customer answer built from Boundary/Attempt Ledger, not a market conclusion.
• Interpretation branches are evidence hypotheses, not keyword routes. Normalized external claims may carry interpretation_branch_id when their fragment overlaps the GoalFrame branch profile; the critic uses that to answer a supported branch with explicit boundaries instead of repeating the same failed query or pretending that unrelated branch evidence answers the whole goal.
• Branch coverage gaps are evidence boundaries, not automatic vetoes, for directional_answer / partial_answer goals. If a reasonable interpretation branch has gated claims, PMFlow AI should answer that branch with a clear assumption and keep the uncovered branch as a remaining gap. Strict/official/fail-closed policies still block when required.
• ResearchNote.ready_for_opportunity_brief=false only blocks downstream OpportunityBrief / CompetitorMap / Execution preparation. It must not erase useful gated claims. The final answer may give a bounded initial read from those claims while saying why it cannot yet upgrade to an opportunity brief or execution action.
• Process display must expose true total count separately from the visible preview. The collapsed work log can show 12/真实总数; expanding must use backend-provided customer-safe steps instead of frontend-fixed step templates.
• Specialist agents may not advance later-stage object shells when the previous stage is not ready. For open market/opportunity research, ResearchNote must reach the minimum source/claim threshold before CompetitorMap, OpportunityBrief, execution handoff or growth/revenue objects become prepared actions.
• Project operating state is read only when a strong project anchor exists.

Current checkpoint:

• The front research loop is contractually closed as search -> read source detail -> normalize -> critic -> recover -> re-read or re-search -> re-normalize -> ResearchNote threshold.
• Single external query plans remain bounded (result_limit <= 5), but the agent run budget allows multiple read/recovery turns. More evidence comes from the loop, not from raising one provider call to an unbounded result count.
• If the LLM normalizer returns an empty response, the deterministic fallback can still extract customer-safe, goal-relevant claims from already-read source text. It does not promote raw source candidates, navigation pages, emails, phone numbers or generic source labels into the claim ledger.
• Source and claim quality are now separate gates. agent_evidence_quality.py blocks page shell, navigation, ad/contact fragments, HTML entities, link-dense text, source-candidate statements, generic source wrappers and raw page fragments before they can become ResearchNote evidence. The normalizer, critic, answer runtime and operating-world-state merge must all use this shared gate; no layer may rebuild its own looser claim filter.
• Critic veto is enforced through gated claims rather than raw claim count. If every observed claim is invalid, the runtime must recover with another read/search when state can change, or stop as a blocked evidence state. It must not answer from a non-empty but invalid claim_ledger.
• Final answer projection must consume only gated terminal claims/ResearchNote facts. Raw source fragments, source candidates and deliverable section text that fails the shared claim gate cannot be merged back into the operating answer or customer canvas.
• Customer process display returns both a visible slice and the full customer-safe process list: work_log, work_log_full, and work_log_meta(total_step_count, visible_step_count, hidden_step_count, truncated). The frontend displays 12/19 style counts and expands to all customer-safe steps instead of silently hiding later recovery/re-read steps.
• Recovery is no longer optional when the critic says another read would change state. If no more untried URLs remain, the runtime builds a recovery search from the user goal, GoalFrame evidence requirements and critic gaps; if tool budget is exhausted, the stop reason is explicit research_recovery_budget_exhausted.
• The specialist registry no longer truncates open research to a fixed front-stage whitelist. Requested specialists remain assigned, but downstream roles block their own prepared actions until the ResearchNote threshold is met.
• Customer thread payloads preserve the final operating answer and machine action contracts (action_type, action_payload) separately from display text, so the UI does not replace the answer with a safety fallback or drop executable confirmation metadata.

Still intentionally not started in this checkpoint:

• Confirmed execution handoff result polling/writeback beyond existing PMFlow OS runtime endpoints.
• Autonomous project writes, ChangeSet commits, task creation or Project Memory updates from open research.
• Growth/revenue/QA downstream object preparation before the ResearchNote threshold is satisfied.
• The run has iteration, tool-call and repeated-action budgets to prevent dead loops.

Step 3: Runtime Tools / Agent Steps

Implemented as typed agent tools in backend/app/services/pmflow_ai_agent_runtime/agent_tool_registry.py.

Current product tools include:

• inspect_space_collections
• inspect_project_operating_state
• resolve_customer_object
• inspect_object_detail
• inspect_saved_ideas
• inspect_pending_confirmations
• external_search
• inspect_pmflow_capability_boundary

The old fixed durable loop in pmflow_agent_runtime/loop.py is no longer the /space/pmflow-ai main controller. It remains a legacy compatibility asset until all old tests/debug consumers are removed. PMFlowAIOperatingRunService is now the mission-first product controller and may override the evidence adapter’s plain answer with council-reviewed operating output.

Rules:

• 你是谁 does not enter specialist/council/autonomy.
• 帮我看看市场上有没有什么新的好项目 must not be answered from PMFlow capability or space project list alone; it needs external/public observations and opportunity candidates or an explicit evidence boundary.
• 这个项目怎么推进 enters the project operating read path when a project is bound.
• Specialist/opportunity outputs enter observations, artifacts and deliverables, not direct answer overrides.
• project_object_required_for_world_state is an internal verification detail only and must never appear in the customer answer.

Step 4: Terminal Answer State + Natural Answer Runtime

Implemented in backend/app/services/pmflow_ai_agent_runtime/agent_answer_runtime.py.

The answer layer consumes the final workspace, latest observation and critic result. It builds:

• terminal claims
• customer-safe boundaries
• attempts
• remaining gaps
• next possible actions
• deliverable packet

Then PROMPT_PMFLOW_AI_AGENT_ANSWER_COMPOSER writes the natural answer. If the LLM answer leaks internal terms or misses the lead claim/boundary, the generic repair path rebuilds the answer from terminal state.

Customer-visible forbidden terms include:

project_object_required_for_world_state
mission
world_state
packet
trace
prompt
function
route_plan
当前对象（空对象）
Claim Ledger
Boundary Ledger
TurnState
英文内部推理
固定“判断依据/证据边界/下一步”三段式

The critic repairs or blocks answers that leak internal runtime terms, echo process plans as final answers, return empty text, or fall back to fixed templates.

Step 5: PMFlow AI Workspace

Implemented:

• The right-bottom chat bubble is removed from frontend/src/features/personal-space/PersonalSpacePage.tsx.
• The first Space sidebar item is PMFlow AI in frontend/src/features/personal-space/components/SpaceChrome.tsx.
• Main route: /space/pmflow-ai.
• Legacy route /space/agent-command-center redirects to /space/pmflow-ai.
• frontend/src/features/personal-space/components/PMFlowAIWorkspace.tsx is the Codex-style workspace:
  • left thread list
  • middle continuous transcript
  • bottom composer
  • per-assistant-message collapsible work log
  • inline artifacts, action candidates and confirmation requests
  • new thread, continue current thread, refresh
  • no local answer fallback; failed sends clear the composer and show an explicit non-committed error instead of replaying the submitted text as if it entered the durable chain
• Frontend API wrappers live in frontend/src/api/aiSteward.ts:
  • createPMFlowAIThread
  • sendPMFlowAIThreadMessage
  • streamPMFlowAIThreadMessage
  • listPMFlowAIThreads
  • getPMFlowAIThread

Frontend must only display backend customer-safe work_log / artifacts / actions / confirmations. It must not render raw agent_os_steps, agent_os_verifications, step ids, target refs or English status labels in the default user experience.

7. Current API Contract

POST /space/pmflow-ai/threads

Creates a PMFlow AI thread and sends the first user message. The backend creates an internal Agent Run for that assistant turn.

Input shape follows the existing Space ask body:

• question
• surface_context
• asked_via
• thinking_mode
• action_mode

Return payload includes:

• thread_id
• title
• messages[]
• assistant_message

Assistant messages include:

• content
• run_id
• work_log[] with customer-safe Chinese labels/summaries
• artifacts[]
• actions[]
• confirmations[]

POST /space/pmflow-ai/threads/{thread_id}/messages

Continues the same PMFlow AI thread. The next user message creates a new internal Agent Run attached to the same thread. It must append to the transcript, not create a new user-visible run row.

POST /space/pmflow-ai/threads/stream

Creates a PMFlow AI thread through the same durable Agent OS path, then streams customer-safe progress and the final thread projection. The stream endpoint must pass event_sink through PMFlowAgentRuntimeService -> PMFlowAIOperatingRunService -> PMFlowAIAgentRunService; a signature mismatch or swallowed event sink is a main-chain failure, because it prevents real runtime steps from reaching both the UI and audit trail.

POST /space/pmflow-ai/threads/{thread_id}/messages/stream

Continues the same PMFlow AI thread with SSE. Allowed events are run.started, step.started, step.completed, answer.started, answer.delta, answer.completed, thread.completed and error. thread.completed is the only success marker for committing the visible thread detail. If the stream errors before completion, the frontend must not persist a fake message or restore the composer as though the send succeeded.

GET /space/pmflow-ai/threads

Lists PMFlow AI threads for the current tenant/user.

GET /space/pmflow-ai/threads/{thread_id}

Returns one thread and its continuous message transcript.

/space/pmflow-ai/runs*

Compatibility/debug surface for internal Agent Run inspection. The product UI must not use it for primary conversation navigation.

POST /space/ai-concierge/ask

Compatibility endpoint. It must call the same Agent OS runtime and return the same customer-safe Agent OS payload projection. It must not restore old /ask route planning as the main control path.

8. Acceptance Cases

1. 你是谁

   • Answer identity, ability and boundary.
   • Do not read project world state.
   • Do not run specialist/council/autonomy.
   • Do not leak internal terms.

2. 现在有哪些项目

   • Read current Space state.
   • Return real visible projects or an empty state.
   • Do not require a project object.
   • Do not run council.

3. 这个项目怎么推进

   • With a strong object anchor, read project world state.
   • Run project operating specialists/council/autonomy as needed.
   • Return judgement, priority actions, confirmation boundary and evidence boundary naturally.

4. 帮我全面推进当前空间

   • Organize a multi-agent run.
   • Select cross-project candidates from visible/authorized state.
   • Produce a run plan and continue until waiting confirmation, blocked boundary or completion.

5. Tool failure

   • Persist the failing step and verification finding.
   • Generate a recovery step when retry can change state.
   • Do not turn raw errors into customer answers.

6. User confirmation

   • Execute only after confirmation.
   • Re-observe and verify after action.
   • Update run status and memories.

7. Replay qa_records.id=1713

   • Final answer must be the identity answer.
   • Project world-state gap must not override the main answer.

9. Files

Backend:

• backend/app/models/pmflow_agent_runtime.py
• backend/app/schemas/pmflow_agent_runtime.py
• backend/app/schemas/pmflow_ai_operating_runtime.py
• backend/app/services/pmflow_agent_runtime/service.py
• backend/app/services/pmflow_ai_operating_runtime/run_service.py
• backend/app/services/pmflow_ai_operating_runtime/mission_service.py
• backend/app/services/pmflow_ai_operating_runtime/agent_registry.py
• backend/app/services/pmflow_ai_operating_runtime/specialist_agents.py
• backend/app/services/pmflow_ai_operating_runtime/council.py
• backend/app/services/pmflow_ai_operating_runtime/autonomy.py
• backend/app/services/pmflow_ai_operating_runtime/cycle.py
• backend/app/services/pmflow_agent_runtime/loop.py
• backend/app/services/pmflow_agent_runtime/answer.py
• backend/app/services/pmflow_agent_runtime/specialists.py
• backend/app/api/space_api/__init__.py
• backend/app/api/rag_ask_contract.py
• backend/tests/test_pmflow_ai_agent_runtime_step1.py

Frontend:

• frontend/src/api/aiSteward.ts
• frontend/src/features/personal-space/components/PMFlowAIWorkspace.tsx
• frontend/src/features/personal-space/components/SpaceChrome.tsx
• frontend/src/features/personal-space/PersonalSpacePage.tsx
• frontend/src/router/index.tsx
• frontend/src/features/personal-space/PersonalSpacePage.test.tsx

Legacy/demoted:

• backend/app/services/pmflow_ai_agent_runtime/agent_run_service.py::PMFlowAIAgentRunService is now the evidence/answer adapter inside the operating runtime, not the Space user-side mission owner.
• backend/app/services/pmflow_agent_runtime/loop.py、answer.py、specialists.py are legacy compatibility assets and must not regain product main-control status.
• frontend/src/features/personal-space/components/SpaceAIConcierge.tsx has been deleted from the Space product surface; shared surface-context construction now lives in frontend/src/features/personal-space/components/spaceSurfaceContext.ts.
• /space/ai-concierge/ask is compatibility, not the terminal product path.

10. Next Deepening Work

The Packet 1-6 landing establishes the operating-agent architecture. The current hardening status is:

• Open market/research missions now stay on the front-stage operating chain until ResearchNote evidence is usable: Idea Incubation, Market Research and Product Strategy. Growth, monetization, learning writeback and execution handoff must not appear as executable customer cards before the research threshold is met.
• Inner Agent OS observations are promoted from agent_os_observations, agent_run_packet.observations and agent_workspace.observations into the Operating World State before specialists/council run. Operating answers must not report 0 sources / 0 claims when the delegated read loop has actually observed sources.
• Candidate-source claims no longer count as substantive claims for recovery blocking. If the critic says retry can change state, the run must re-observe by reading untried sources or issuing a recovery search instead of stopping at no_state_delta_recovery_blocked.
• Recovery search is only allowed inside the external research read chain. A generic space/project read with insufficient state must return to the normal planner, not be forced into public search.
• Recovery search must diversify from the GoalFrame interpretation branches and critic gaps, while excluding attempted source URLs. An off-branch claim cannot block recovery for a higher-priority uncovered branch.
• If the critic says the state is not ready and another read/retry can change the state, terminal state is waiting_for_evidence. Product object projection must not consume claim ledger rows from that terminal state.
• ResearchNote projection must only use gated claims from an answerable or partially-answerable terminal state. Page shells, candidate-source fragments and off-branch claims are not enough to become a market judgement.
• Source relevance and claim relevance are hard gates before ResearchNote readiness. A fetched source can mention the right broad topic and still be rejected if the extracted fragment does not align with GoalFrame evidence requirements or if it is only a raw page/event/investment fragment.
• Critic readiness must check the ResearchNote threshold, not only claim count. External research needs independent source support and enough evidence-requirement coverage before ready_to_answer=true; otherwise the only valid result is recover or blocked.
• Answer quality is fail-closed for external research. If the final draft still contains raw source noise, repeated page fragments, unsupported external claims, internal terms or other severe findings after revision/repair, the runtime rebuilds a blocked terminal answer instead of returning the bad draft.
• Packet AZ locks the customer-visible truth source for external research: the gated ResearchNote or blocked recovery deliverable is the only text source for answer, reply_text, answer_canvas.direct_answer, stored message payloads and frontend rendering. API projection may sanitize protected implementation terms, but it must not replace an Agent Runtime answer with a separate canvas/action fallback. If the state is blocked, the blocked recovery deliverable is shown as the answer; if it is answerable, only gated ResearchNote facts may feed the answer.
• Operating answer text must be the same text used by answer_canvas.direct_answer, so the UI cannot show the old inner answer while the message body shows the operating answer.
• Confirmation requests must preserve action_type / action_label / action_payload / can_execute_after_confirmation, otherwise the frontend shows non-executable process cards.

To approach Codex-level behavior in the project-operating domain, deepen these modules in order rather than rebuilding the architecture again:

• Let specialist agents use richer typed tools and controlled parallelism, without restoring keyword or enum branching.
• Expand tool coverage for project memory, task graph, change review, release/growth, capacity and external evidence as typed observations/work products.
• Expand project-bound execution handoff coverage with formal task/repo fixtures and runtime credential smoke tests.
• Add golden cases for confirmed research recovery re-observe/re-council, saved idea promotion and execution result writeback learning.
• Add UI affordances for completed confirmation actions and blocked execution-preparation gaps.
• Persist learning memory beyond QA session capsules when run volume requires dedicated memory projection tables.