Plan Mode Architecture¶
PlanMode turns an experimental report or natural-language scientific request into a reviewable, Python-native molexp workspace. It authors and validates a workspace; it does not execute experiments.
PlanMode is implemented as a molexp.workflow.Workflow. The agent
layer owns the prompts, model policy, review gate, and handoff contract.
The workflow layer owns workflow/task abstractions and generic
WorkflowContract validation. The workspace layer owns generic storage
primitives such as subsystem directories and atomic writes.
Flow¶
flowchart TD
A["Experiment Report / User Request"] --> B["IngestReport"]
B --> C["DraftReportDigest"]
C --> D["DraftImplementationPlan"]
D --> E["CompileWorkflowIR"]
E --> F["CompileTaskIR"]
F --> CN["DraftCapabilityNeeds"]
CN --> CD["DiscoverCapabilities"]
CD --> G["GenerateWorkflowSkeleton"]
F --> H["GenerateTaskTests"]
CD --> H
G --> I["GenerateTaskImplementations"]
CD --> I
H --> I
I --> J["ValidateWorkspace"]
J --> K["HumanReview"]
K --> X["FinalHandoffCheck"]
X --> L["PlanMode Result"]
L --> M["RunMode"]
Planning Nodes¶
The current PlanMode workflow uses these 13 node names:
IngestReportDraftReportDigestDraftImplementationPlanCompileWorkflowIRCompileTaskIRDraftCapabilityNeedsDiscoverCapabilitiesGenerateWorkflowSkeletonGenerateTaskTestsGenerateTaskImplementationsValidateWorkspaceHumanReviewFinalHandoffCheck
The two capability nodes (Phase 4-5 of agent-pydanticai-rectification)
sit between IR compilation and the codegen fan-out so each codegen
node can refuse unevidenced Molcrafts API references. See
agent.md for the full gate
contract.
Code, tests, and documentation should use these names for the current pipeline.
Artifacts¶
PlanMode materializes a plan workspace under the agent-owned subsystem store:
The workspace contains:
report/original.mdreport/digest.mdplan/implementation_plan.mdir/workflow.yamlir/tasks/*.yamlcapability/needs.yamlcapability/evidence.yamlcapability/missing.mdsrc/experiment/workflow.pysrc/experiment/tasks/*.pytests/test_*.pymanifest.yamlvalidation_report.mdvalidation_report.yaml
Generated experiment code is Python-native and uses
molexp.workflow.WorkflowBuilder. The generated workflow module exposes
create_workflow, which returns the molexp.workflow.Workflow object
that RunMode will load.
Validation¶
Validation has two levels:
ValidateWorkspacechecks materialized files, task IR files, generated source, RunMode-style entrypoint importability, and delegates generic workflow contract rules tomolexp.workflow.validate_workflow_contract.FinalHandoffCheckrepeats the RunMode-facing import and contract validation after human review so final edits cannot bypass handoff checks.
Syntax compilation is only a preliminary check. A workspace is runnable only if RunMode can import the generated entrypoint and the loaded workflow passes generic contract validation.
Review And Readiness¶
Human approval and runnable readiness are separate:
Default auto-approval may approve the design direction, but failed
machine validation cannot produce ready_for_run. The manifest records
both the approval result and the final machine-readable status under the
plan_mode block.
Current status values are:
draftvalidatedvalidation_failedready_for_reviewapprovedapproved_with_overrideready_for_runpending_review
Handoff¶
PlanMode ends with a PlanRunHandoff. The manifest includes the
entrypoint metadata RunMode needs:
plan_mode:
status: ready_for_run
validation_passed: true
ready_for_run: true
handoff:
source_root: src
module: experiment.workflow
symbol: create_workflow
override: false
RunMode owns dispatch, monitoring, resume, logging, backend execution, failure tracking, and artifact collection. It should not have to rediscover basic PlanMode generation errors.