Repository navigation
fix(flows): correct workflow_builder prompt posture (B27, B28) - #4834
Conversation
B27: the prompt and DIRECTIVE_BUILD_PROPOSE_ONLY described a phantom "review card" whose Accept persists the flow via flows_create. The actual instant-canvas flow is: copilot panel Accept -> local unsaved draft overlay, then the canvas's own Save -> updateFlow/createFlow persists. The agent also echoed the stale wording verbatim while sometimes auto-calling save_workflow itself, contradicting its own message. Rewrite prompt.md and the build directive/doc comments to match the real UI, and stop implying Accept persists anything. B28: add prompt guidance distinguishing a mock-LLM-output placeholder null (sandbox SchemaAwareMockAgentRunner - expected, note and proceed) from a real binding null / dry-run ok:false (a wrong =nodes.* path - a genuine bug that must be fixed). The agent had previously waved off a real dry-run failure as a "known sandbox limitation," which the prompt did not explicitly forbid. Adds a regression assertion that the build directive no longer contains "review card" or "Accept the proposal explicitly".
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe workflow-builder prompts now clarify user-controlled Accept and Save persistence, prohibit implicit saving, strengthen authoring boundaries, and require real handling of failed dry runs. Build-mode regression tests reject legacy persistence wording. ChangesWorkflow Builder Prompt Contract
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05717a012e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| If there is no existing flow to save to, only the user's own **Save** on | ||
| the canvas persists the flow. If a user says "just turn it on for me", | ||
| explain that enabling stays in their hands — you cannot enable a flow. |
There was a problem hiding this comment.
When workflow_builder is reached from main chat or Suggested Workflows without a saved flow_id, the proposal still renders in WorkflowProposalCard, whose user-clicked “Save & enable” path calls flows_create directly, not the canvas Save flow. This new wording tells the agent that only canvas Save can persist in exactly those no-existing-flow cases, so its user-facing guidance can contradict the actual card shown in those contexts.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 46a3571. Verified the claim first: WorkflowProposalCard's "Save & enable" button (app/src/components/chat/WorkflowProposalCard.tsx) calls createFlow → openhuman.flows_create directly, and it's rendered both from main chat (Conversations.tsx) and Suggested Workflows (SuggestedWorkflows.tsx) — both no-existing-flow_id contexts, distinct from the canvas copilot's Accept+Save flow. Reworded the two spots in prompt.md (the invariants section and the authoring-loop step) to describe both persist paths: canvas copilot Accept→Save, and the chat/Suggested-Workflows proposal card's "Save & enable". Kept the B28 dry-run-honesty additions and the "do NOT call save_workflow unless asked" rule intact; cargo test --lib openhuman::flows:: (271 tests) still passes, including the B27 regression test asserting the phantom "review card"/"Accept the proposal explicitly" language stays gone.
coderabbitai
Bot
added
agent
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
B27 over-corrected: it taught the agent that only the canvas's Save persists a flow when there's no existing flow_id. That's true for the canvas copilot, but main chat and Suggested Workflows render the same proposal in WorkflowProposalCard, whose "Save & enable" button calls flows_create directly — no canvas Save step exists in that path. Describe both so the agent's guidance to the user matches whichever surface is actually showing them the proposal. Addresses Codex review comment on PR tinyhumansai#4834 (id 3573085947, src/openhuman/flows/agents/workflow_builder/prompt.md:24).
Summary
workflow_builder's prompt described a phantom "review card" whoseAccept persists a flow via
flows_create— the real instant-canvas flow iscopilot-panel Accept → local unsaved draft, then the canvas's own Save →
updateFlow/createFlowpersists.DIRECTIVE_BUILD_PROPOSE_ONLY)echoed the same stale "Accept the proposal explicitly and the canvas's Save
persists it" wording, which contradicted the agent sometimes auto-calling
save_workflowitself.mock-LLM-output placeholder null (sandbox
SchemaAwareMockAgentRunner—expected, note and proceed) from a real binding null / dry-run
ok:false(a wrong
=nodes.*path — a real bug that must be fixed, never dismissedas a "sandbox limitation").
builder_prompt.rsto match the corrected framing.or frontend code changed.
Problem
The
workflow_builderagent's system prompt (prompt.md) and itsBuild-mode turn directive (builder_prompt.rs) told the agent there is a"review card" with an "Accept" action that persists the flow, and separately
that "the canvas's Save" persists it too — describing two different
persistence paths for what is actually a single two-step UI flow (Accept →
local draft, Save → persist). The agent echoed this stale phrasing verbatim
to users even in turns where it had itself already called
save_workflow,producing contradictory messaging (B27).
Separately, the prompt told the agent to "fix every"
null_resolutionsfinding from
dry_run_workflow, but gave no guidance distinguishing alegitimate mock-LLM-output placeholder (expected in the sandbox — no real
LLM ran) from a real wiring bug (a wrong
=nodes.*binding path). Observedagent behavior dismissed a real dry-run failure as a "known sandbox
limitation... at runtime this works perfectly" and saved anyway — the prompt
did not forbid this pattern (B28).
Solution
B27 —
src/openhuman/flows/agents/workflow_builder/prompt.md:flows_createlanguage; replaced with an accurate statement that only theuser's own canvas Save persists the flow.
panel, applies to canvas draft) → Save (canvas, persists) sequence, and
made explicit that the agent must not call
save_workflowunless asked.src/openhuman/flows/agents/workflow_builder/builder_prompt.rs:DIRECTIVE_BUILD_PROPOSE_ONLYto drop the "I will Accept theproposal explicitly and the canvas's Save persists it" phrasing in favor
of an accurate description ("I will review the proposal in the copilot
panel, accept it onto the canvas draft, and save it myself"). The
Do NOT save_workflowinstruction (critical for Rejecting a seeded flow build leaves the graph persisted #4596) is unchanged.card's Accept" / "explicit Accept + Save" to say "the copilot panel's
Accept + the canvas's Save".
B28 —
src/openhuman/flows/agents/workflow_builder/prompt.md:dry-run
ok: falseas a sandbox limitation.verify-loop section explaining the two classes of null/placeholder values
(mock-LLM-output placeholder vs. real binding null) and explicitly
forbidding "known sandbox limitation" / "at runtime this works perfectly"
as a way to wave off a real finding.
No tool logic or frontend changes —
DryRunWorkflowTool,SaveWorkflowTool,ReviseWorkflowTool,ProposeWorkflowTool,WorkflowCopilotPanel, andFlowCanvasPage's save flow are all correct today; only the agent's promptdescribed them wrong.
Submission Checklist
build_is_propose_only_and_injects_flow_id_as_contextthat the build directive no longer contains"review card"or"Accept the proposal explicitly"; existing positive/negative assertions onDo NOT save_workflowstill pass.Impact
workflow_builderagent's system prompt text and one Rust string constant/doc comments; no RPC, schema, or UI changes.Build/Create/Reviseturn will describe the Accept → draft → Save flow accurately instead of referencing a nonexistent "review card", and will no longer wave off a real dry-run failure as a "sandbox limitation".Related
AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
fix/flows-builder-prompt-postureValidation Run
pnpm --filter openhuman-app format:check— N/A noapp/files changed; rancargo fmt+pnpm format(repo-wide) with no diffs beyond the two intended files.pnpm typecheck— N/A no TypeScript changed; not run.GGML_NATIVE=OFF cargo test --manifest-path Cargo.toml --lib openhuman::flows:: -- --test-threads=1→ 271 passed, 0 failed (single-threaded per knownvalidate_tool_contracts*parallel-only flake).GGML_NATIVE=OFF cargo check --manifest-path Cargo.tomlpassed;cargo fmtapplied (no diffs).app/src-taurifiles changed.Validation Blocked
command:N/Aerror:N/Aimpact:N/ABehavior Changes
workflow_builderagent chat replies describe the real Accept (copilot panel, local draft) → Save (canvas, persists) flow instead of a nonexistent "review card"; the agent no longer dismisses a real dry-runok: falseas a "sandbox limitation".Parity Contract
Do NOT save_workflowpropose-only gate forBuildmode is unchanged (still enforced, still tested per Rejecting a seeded flow build leaves the graph persisted #4596 regression).Duplicate / Superseded PR Handling
Summary by CodeRabbit
ok: falseas real wiring/validation issues, and distinguish placeholder outputs from genuine failures).