feat(dashboard): workflow optional steps — authoring, full-modal parity, stepwise seam - #1703
Merged
Conversation
…ep to stepwise workflow The stepwise-coding IR had no workflow-step seam node, so a per-task enabledWorkflowSteps entry (e.g. browser verification) would never execute. Add the seam node on the success path (steps -> workflow-step -> review, once post-foreach) and declare browser-verification as an optional step, matching the coding workflow. Covers the dead-toggle gap with resolver and engine execution-divergence tests.
Thread an optionalSteps param through flowToIr (counts as a v2 signal, re-attached like fields/settings, omitted entirely when empty for byte identity) and add an optionalStepsOf reader mirroring fieldsOf/settingsOf. Without this, saving a workflow through the node editor silently dropped its optional-step declaration.
New WorkflowOptionalStepsPanel (sibling to Fields/Settings) lets authors add/remove optional steps and set each one's defaultOn, with unknown ids shown as muted removable rows. Wire optionalSteps state through both load paths (incl. the fragment path, which also dropped settings), every flowToIr/serializeGraph call site, and the save handler deps — fixing a stale-closure that dropped defaultOn edits on save. Extract the shared phaseBadge helper. Mobile gets an Optional steps tab too.
Add WorkflowOptionalStepsDropdown — a controlled, portal-rendered multi-select (listbox a11y, keyboard nav, committed 'Steps: N selected' label matrix, render-nothing empty state) shared by the quick-add card and (next) the full modal. Swap InlineCreateCard's inline chip toggles for it; the fetch/seed/submit wiring is unchanged. Remove the now-unused chip CSS.
Contributor
|
Warning Review limit reached
More reviews will be available in 5 minutes and 2 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
📝 WalkthroughWalkthroughAdds optional workflow steps end-to-end: the stepwise-coding built-in IR gains a ChangesWorkflow Optional Steps
Sequence DiagramssequenceDiagram
rect rgba(100, 149, 237, 0.5)
Note over NewTaskModal,fetchWorkflowOptionalSteps: Task creation optional-step selection
end
participant NewTaskModal
participant TaskForm
participant fetchWorkflowOptionalSteps
participant WorkflowOptionalStepsDropdown
NewTaskModal->>TaskForm: enabledWorkflowSteps, onEnabledWorkflowStepsChange
TaskForm->>fetchWorkflowOptionalSteps: fetch(workflowId, projectId)
fetchWorkflowOptionalSteps-->>TaskForm: ResolvedWorkflowOptionalStep[]
TaskForm->>TaskForm: seed enabledIds from defaultOn
TaskForm->>WorkflowOptionalStepsDropdown: steps, enabledIds, onToggle
WorkflowOptionalStepsDropdown-->>TaskForm: onToggle(templateId)
TaskForm-->>NewTaskModal: onEnabledWorkflowStepsChange(ids)
NewTaskModal->>NewTaskModal: create payload includes enabledWorkflowSteps
sequenceDiagram
rect rgba(144, 238, 144, 0.5)
Note over WorkflowNodeEditor,WorkflowOptionalStepsPanel: Node editor authoring
end
participant WorkflowNodeEditor
participant optionalStepsOf
participant WorkflowOptionalStepsPanel
participant flowToIr
WorkflowNodeEditor->>optionalStepsOf: optionalStepsOf(activeWorkflow)
optionalStepsOf-->>WorkflowNodeEditor: WorkflowOptionalStep[]
WorkflowNodeEditor->>WorkflowOptionalStepsPanel: optionalSteps, onChange, readOnly
WorkflowOptionalStepsPanel-->>WorkflowNodeEditor: onChange(updatedSteps)
WorkflowNodeEditor->>flowToIr: flowToIr(..., optionalSteps)
flowToIr-->>WorkflowNodeEditor: WorkflowIrV2 with optionalSteps
WorkflowNodeEditor->>WorkflowNodeEditor: updateWorkflow(ir)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Ready to review this PR? Stage has broken it down into 9 individual chapters for you: 
Chapters generated by Stage for commit 7c8eba3 on Jun 21, 2026 10:14am UTC. |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (6)
packages/core/src/builtin-stepwise-coding-workflow-ir.ts (1)
126-131: ⚡ Quick winAdd an FNXC-formatted requirement trace comment for the new seam/optional-step behavior.
This is a major behavior seam change (
steps → workflow-step → reviewplus optional-step declaration) and should carry oneFNXC:<Area> yyyy-MM-dd-hh:mm:trace comment near the introduced logic for requirement/date traceability.As per coding guidelines,
**/*.{ts,tsx,js,jsx}changes should include FNXC-formatted requirement/date comments; based on learnings, use theFNXC:<Area> yyyy-MM-dd-hh:mm:convention (without requiring a literalFNXC_LOGtoken).Also applies to: 162-172, 192-194
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/core/src/builtin-stepwise-coding-workflow-ir.ts` around lines 126 - 131, Add FNXC-formatted requirement trace comments for requirement and date traceability near the major behavior seam changes in this file. Specifically, add comments with the format FNXC:<Area> yyyy-MM-dd-hh:mm: near the workflow-step node definition (the prompt kind node with id "workflow-step"), and near any optional-step declarations (such as browser-verification step). These trace comments should be placed as inline comments just before or after the logic that introduces this new workflow-step seam behavior to maintain compliance with the TypeScript file coding guidelines for requirement traceability.Sources: Coding guidelines, Learnings
packages/dashboard/app/components/workflow-flow-mapping.ts (1)
458-463: ⚡ Quick winAdd an FNXC-formatted comment for the optionalSteps v2-signal/round-trip contract.
The new v2 signaling + key-omission behavior is contract-level logic; adding a nearby
FNXC:<Area> yyyy-MM-dd-hh:mm:comment would keep requirement provenance explicit.As per coding guidelines, important TS behavior decisions should be captured with FNXC-formatted requirement/date comments; based on learnings, follow the
FNXC:<Area> yyyy-MM-dd-hh:mm:convention.Also applies to: 564-569, 981-989
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/dashboard/app/components/workflow-flow-mapping.ts` around lines 458 - 463, Add FNXC-formatted comments to document the contract-level logic related to v2 signaling and key-omission behavior. Specifically, add a comment in the format FNXC:<Area> yyyy-MM-dd-hh:mm: near the v2 variable assignment (around the hasOptionalSteps check) to capture the requirement that optionalSteps contributes to v2-signal detection and impacts round-trip serialization. Apply the same FNXC comment pattern to the other related v2-signal logic locations mentioned (at lines 564-569 and 981-989) to maintain consistent documentation of this contract-level behavior throughout the workflow-flow-mapping.ts file.Sources: Coding guidelines, Learnings
packages/dashboard/app/components/WorkflowOptionalStepsDropdown.tsx (1)
1-18: ⚡ Quick winAdd an FNXC-formatted provenance comment for this new dropdown.
Please include a brief
FNXC:<Area-of-product> yyyy-MM-dd-hh:mm:comment that captures the requirement/decision behind this shared optional-steps control.As per coding guidelines
**/*.{ts,tsx,js,jsx}requires FNXC-formatted requirement/change comments, and based on learnings this should use theFNXC:<Area-of-product> yyyy-MM-dd-hh:mm:convention.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/dashboard/app/components/WorkflowOptionalStepsDropdown.tsx` around lines 1 - 18, The WorkflowOptionalStepsDropdown component is missing the required FNXC-formatted provenance comment. Add a brief FNXC comment following the convention FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: that documents the requirement or decision behind this shared optional-steps control. This comment should be placed after the existing JSDoc block and before the component implementation to comply with coding guidelines for all TypeScript/TSX files.Sources: Coding guidelines, Learnings
packages/dashboard/app/components/WorkflowOptionalStepsPanel.tsx (1)
1-13: ⚡ Quick winAdd an FNXC-formatted provenance comment for this panel.
Please add a concise
FNXC:<Area-of-product> yyyy-MM-dd-hh:mm:comment documenting the requirement/decision for this optional-steps authoring surface.As per coding guidelines
**/*.{ts,tsx,js,jsx}requires FNXC-formatted requirement/change comments, and based on learnings this should followFNXC:<Area-of-product> yyyy-MM-dd-hh:mm:.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/dashboard/app/components/WorkflowOptionalStepsPanel.tsx` around lines 1 - 13, The WorkflowOptionalStepsPanel.tsx file is missing the required FNXC-formatted provenance comment. Add a new line at the beginning of the JSDoc block (before the existing documentation comment) that follows the format FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: where Area-of-product should be a descriptive label for the workflow editor functionality and the timestamp should reflect when this requirement/decision was made. This comment documents the rationale for the optional-steps authoring surface and is required for all TypeScript and TypeScript React files per coding guidelines.Sources: Coding guidelines, Learnings
packages/dashboard/app/components/workflow-phase-badge.tsx (1)
1-5: ⚡ Quick winAdd an FNXC-formatted provenance comment for this helper.
Please add a short
FNXC:<Area-of-product> yyyy-MM-dd-hh:mm:comment capturing the requirement/decision that introduced this shared badge extraction.As per coding guidelines
**/*.{ts,tsx,js,jsx}requires FNXC-formatted requirement/change comments, and based on learnings this should use theFNXC:<Area-of-product> yyyy-MM-dd-hh:mm:convention (not a literalFNXC_LOGtoken).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/dashboard/app/components/workflow-phase-badge.tsx` around lines 1 - 5, The workflow-phase-badge.tsx file is missing an FNXC-formatted provenance comment as required by the coding guidelines for TypeScript/JavaScript files. Add a short FNXC-formatted comment using the convention FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: that captures the requirement or decision that introduced this shared badge extraction. This comment should be placed near the existing JSDoc comment at the top of the file and should follow the FNXC format convention (not a literal FNXC_LOG token).Sources: Coding guidelines, Learnings
packages/dashboard/app/components/TaskForm.tsx (1)
298-304: ⚡ Quick winUse FNXC-format for this new requirement comment block.
The new optional-steps behavior notes are requirement-driven and should use the repo’s FNXC comment convention.
As per coding guidelines,
**/*.{ts,tsx,js,jsx}should use comments inFNXC:<Area-of-product> yyyy-MM-dd-hh:mm:format for requirement/UX/technical-decision traces. Based on learnings, this means using FNXC heading format rather than adding a literalFNXC_LOGtoken.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/dashboard/app/components/TaskForm.tsx` around lines 298 - 304, The comment block preceding the effectiveOptionalWorkflowId variable declaration does not follow the FNXC format convention required for requirement-driven comments in TypeScript files. Replace the existing comment that describes the optional workflow steps behavior with a properly formatted FNXC comment using the format FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: followed by the requirement details, ensuring the comment captures the null selection and undefined behavior documentation in the standardized FNXC format.Sources: Coding guidelines, Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/dashboard/app/components/InlineCreateCard.tsx`:
- Around line 1083-1091: Add a FNXC-formatted requirement comment to document
the design decision for the user-facing selection path introduced by the
WorkflowOptionalStepsDropdown component. Insert an FNXC comment with the format
FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: followed by the rationale for enabling
users to toggle optional workflow steps through this dropdown. This comment
should be placed directly above or inline with the WorkflowOptionalStepsDropdown
component to document the product requirement and decision behind this UX
interaction.
In `@packages/dashboard/app/components/NewTaskModal.tsx`:
- Around line 64-66: The enabledWorkflowSteps state is now user-editable but the
hasDirtyState tracking does not include it in its comparison logic. Update the
hasDirtyState calculation to also compare the current enabledWorkflowSteps
against its initial value, ensuring that any changes to optional workflow steps
are properly detected as dirty state and trigger the discard confirmation prompt
when users attempt to close the modal.
In `@packages/dashboard/app/components/TaskForm.tsx`:
- Around line 307-310: The early return when effectiveOptionalWorkflowId is
falsy does not reset the optionalStepsLoading state, which can leave the loading
UI stuck even after switching to "No workflow". Add a call to set
optionalStepsLoading to false in the conditional block around line 307-310
before the early return statement. Apply the same fix to the similar code block
mentioned at lines 325-327 to ensure the loading state is cleared in all cases
where the workflow selection changes or is cleared.
In `@packages/dashboard/app/components/WorkflowNodeEditor.tsx`:
- Around line 2501-2505: The WorkflowOptionalStepsPanel component accepts a
pluginTemplates prop that allows it to merge and display plugin-contributed step
templates, but both instances of this component (one in the desktop layout
around line 2501-2505 and one in the mobile layout around line 2811-2815) are
missing this prop. Add the pluginTemplates prop to both
WorkflowOptionalStepsPanel component instances and pass the appropriate plugin
templates data so that the "Add optional step" picker can display
plugin-contributed step templates.
In `@packages/dashboard/app/components/WorkflowOptionalStepsDropdown.tsx`:
- Around line 163-166: The listbox element with role="listbox" in
WorkflowOptionalStepsDropdown.tsx is missing the aria-multiselectable="true"
attribute. Add this attribute to the same element that has aria-label and
aria-labelledby to properly expose the multi-select semantics to assistive
technologies, ensuring they interpret this as a multi-select control rather than
a single-select one.
---
Nitpick comments:
In `@packages/core/src/builtin-stepwise-coding-workflow-ir.ts`:
- Around line 126-131: Add FNXC-formatted requirement trace comments for
requirement and date traceability near the major behavior seam changes in this
file. Specifically, add comments with the format FNXC:<Area> yyyy-MM-dd-hh:mm:
near the workflow-step node definition (the prompt kind node with id
"workflow-step"), and near any optional-step declarations (such as
browser-verification step). These trace comments should be placed as inline
comments just before or after the logic that introduces this new workflow-step
seam behavior to maintain compliance with the TypeScript file coding guidelines
for requirement traceability.
In `@packages/dashboard/app/components/TaskForm.tsx`:
- Around line 298-304: The comment block preceding the
effectiveOptionalWorkflowId variable declaration does not follow the FNXC format
convention required for requirement-driven comments in TypeScript files. Replace
the existing comment that describes the optional workflow steps behavior with a
properly formatted FNXC comment using the format FNXC:<Area-of-product>
yyyy-MM-dd-hh:mm: followed by the requirement details, ensuring the comment
captures the null selection and undefined behavior documentation in the
standardized FNXC format.
In `@packages/dashboard/app/components/workflow-flow-mapping.ts`:
- Around line 458-463: Add FNXC-formatted comments to document the
contract-level logic related to v2 signaling and key-omission behavior.
Specifically, add a comment in the format FNXC:<Area> yyyy-MM-dd-hh:mm: near the
v2 variable assignment (around the hasOptionalSteps check) to capture the
requirement that optionalSteps contributes to v2-signal detection and impacts
round-trip serialization. Apply the same FNXC comment pattern to the other
related v2-signal logic locations mentioned (at lines 564-569 and 981-989) to
maintain consistent documentation of this contract-level behavior throughout the
workflow-flow-mapping.ts file.
In `@packages/dashboard/app/components/workflow-phase-badge.tsx`:
- Around line 1-5: The workflow-phase-badge.tsx file is missing an
FNXC-formatted provenance comment as required by the coding guidelines for
TypeScript/JavaScript files. Add a short FNXC-formatted comment using the
convention FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: that captures the
requirement or decision that introduced this shared badge extraction. This
comment should be placed near the existing JSDoc comment at the top of the file
and should follow the FNXC format convention (not a literal FNXC_LOG token).
In `@packages/dashboard/app/components/WorkflowOptionalStepsDropdown.tsx`:
- Around line 1-18: The WorkflowOptionalStepsDropdown component is missing the
required FNXC-formatted provenance comment. Add a brief FNXC comment following
the convention FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: that documents the
requirement or decision behind this shared optional-steps control. This comment
should be placed after the existing JSDoc block and before the component
implementation to comply with coding guidelines for all TypeScript/TSX files.
In `@packages/dashboard/app/components/WorkflowOptionalStepsPanel.tsx`:
- Around line 1-13: The WorkflowOptionalStepsPanel.tsx file is missing the
required FNXC-formatted provenance comment. Add a new line at the beginning of
the JSDoc block (before the existing documentation comment) that follows the
format FNXC:<Area-of-product> yyyy-MM-dd-hh:mm: where Area-of-product should be
a descriptive label for the workflow editor functionality and the timestamp
should reflect when this requirement/decision was made. This comment documents
the rationale for the optional-steps authoring surface and is required for all
TypeScript and TypeScript React files per coding guidelines.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 426eb16b-293f-4481-a3ff-2eb2bb95517d
📒 Files selected for processing (24)
.changeset/workflow-optional-steps.mddocs/plans/2026-06-20-001-feat-workflow-optional-steps-node-editor-modal-plan.mdpackages/core/src/__tests__/workflow-optional-steps.test.tspackages/core/src/builtin-stepwise-coding-workflow-ir.tspackages/dashboard/app/components/InlineCreateCard.csspackages/dashboard/app/components/InlineCreateCard.tsxpackages/dashboard/app/components/NewTaskModal.tsxpackages/dashboard/app/components/TaskForm.tsxpackages/dashboard/app/components/WorkflowNodeEditor.tsxpackages/dashboard/app/components/WorkflowOptionalStepsDropdown.csspackages/dashboard/app/components/WorkflowOptionalStepsDropdown.tsxpackages/dashboard/app/components/WorkflowOptionalStepsPanel.csspackages/dashboard/app/components/WorkflowOptionalStepsPanel.tsxpackages/dashboard/app/components/WorkflowResultsTab.tsxpackages/dashboard/app/components/__tests__/InlineCreateCard.test.tsxpackages/dashboard/app/components/__tests__/NewTaskModal.test.tsxpackages/dashboard/app/components/__tests__/TaskForm.test.tsxpackages/dashboard/app/components/__tests__/WorkflowNodeEditor.test.tsxpackages/dashboard/app/components/__tests__/WorkflowOptionalStepsDropdown.test.tsxpackages/dashboard/app/components/__tests__/WorkflowOptionalStepsPanel.test.tsxpackages/dashboard/app/components/__tests__/workflow-flow-mapping.test.tspackages/dashboard/app/components/workflow-flow-mapping.tspackages/dashboard/app/components/workflow-phase-badge.tsxpackages/engine/src/__tests__/stepwise-workflow-parity.test.ts
💤 Files with no reviewable changes (1)
- packages/dashboard/app/components/InlineCreateCard.css
Contributor
Greptile SummaryThis PR introduces workflow optional steps end-to-end: workflow-level declarations, node-editor authoring, round-trip persistence through
Confidence Score: 5/5Safe to merge; all changed paths are covered by tests and the known residual gaps are transparently documented in the PR description. The feature is well-scoped and thoroughly tested (flow-mapping round-trip, dropdown, panel, modal, inline card, engine seam execution). The data-loss fix for the fragment/generate path is correct. The two flagged items are non-blocking style and accessibility concerns with no impact on runtime correctness or data integrity. WorkflowOptionalStepsDropdown.tsx (Tab-away accessibility) and TaskForm.tsx (effect deps comment) are worth a quick look but have no effect on functional correctness. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Workflow IR\noptionalSteps declaration] -->|optionalStepsOf| B[WorkflowNodeEditor\noptionalSteps state]
B -->|WorkflowOptionalStepsPanel| C[Author: add/remove/defaultOn]
B -->|serializeGraph / flowToIr| D[Saved IR\noptionalSteps preserved]
A -->|fetchWorkflowOptionalSteps| E[TaskForm\noptionalSteps + seed from defaultOn]
E -->|lift enabledWorkflowSteps| F[NewTaskModal\ncreate payload]
E -->|WorkflowOptionalStepsDropdown| G[User toggles steps]
G --> F
H[InlineCreateCard\nfetches optional steps] -->|WorkflowOptionalStepsDropdown| G
F -->|enabledWorkflowSteps| I[Task created]
I -->|workflow-step seam node| J[runWorkflowSteps\ne.g. browser-verification]
J --> K[review node]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[Workflow IR\noptionalSteps declaration] -->|optionalStepsOf| B[WorkflowNodeEditor\noptionalSteps state]
B -->|WorkflowOptionalStepsPanel| C[Author: add/remove/defaultOn]
B -->|serializeGraph / flowToIr| D[Saved IR\noptionalSteps preserved]
A -->|fetchWorkflowOptionalSteps| E[TaskForm\noptionalSteps + seed from defaultOn]
E -->|lift enabledWorkflowSteps| F[NewTaskModal\ncreate payload]
E -->|WorkflowOptionalStepsDropdown| G[User toggles steps]
G --> F
H[InlineCreateCard\nfetches optional steps] -->|WorkflowOptionalStepsDropdown| G
F -->|enabledWorkflowSteps| I[Task created]
I -->|workflow-step seam node| J[runWorkflowSteps\ne.g. browser-verification]
J --> K[review node]
Reviews (2): Last reviewed commit: "Address PR review feedback (#1703)" | Re-trigger Greptile |
- Dropdown: aria-multiselectable, drop dead aria-labelledby, ArrowUp opens panel - Dirty-state: NewTaskModal tracks enabledWorkflowSteps so toggles trigger discard prompt - TaskForm: reset optionalStepsLoading on the no-workflow early return - Node editor: pass plugin step templates into the optional-steps panel (both layouts) - FNXC requirement comments on the new optional-steps components
- FNXC requirement-trace comments on the stepwise workflow-step seam, the flowToIr v2-signal/byte-identity contract, and TaskForm's optional-steps create-mode behavior
Collaborator
Author
|
Re: CodeRabbit "Nitpick comments (6)" — FNXC requirement-trace comments All six FNXC nitpicks are now addressed:
All follow the |
This was referenced Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Workflow optional steps
Workflows can declare optional steps — workflow-step templates (e.g. Browser Verification) that a task may toggle on/off per task, with a workflow-level
defaultOnseeding the initial state.Implements the plan at
docs/plans/2026-06-20-001-feat-workflow-optional-steps-node-editor-modal-plan.md(units U1–U5).What's in this PR
workflow-stepseam node (placed once after the foreach, withrework-hold → workflow-stepandworkflow-step → {review,end}edges) plus abrowser-verificationoptional-step declaration (default OFF) so enabled steps actually run.flowToIr/serializeGraphnow threadoptionalSteps, and a newoptionalStepsOfreader hydrates editor state — fixing a data-loss bug where saving a workflow in the visual editor dropped its optional-step declaration. Empty/absentoptionalStepsis omitted entirely to preserve legacy v1 byte-identity.defaultOn, with a sharedworkflow-phase-badgeextraction and graceful handling of unknown/stale template ids.TaskForm/NewTaskModalload the selected workflow's optional steps, seed fromdefaultOn, and submitenabledWorkflowSteps(omitted when empty).WorkflowOptionalStepsDropdown(portal-positioned, keyboard/aria-complete) adopted by both the quick-add card and the full modal, replacing the inline chip toggles.Test plan
@fusion/coresuite: 6218 passed.@fusion/enginesuite: 7983 passed (incl. stepwise seam parity/execution tests).@fusion/dashboardoptional-steps suites: flow-mapping, node editor, dropdown, inline card, modal, form — all green (629 in the focused run; 1229 across the broader component set).Review (ce-code-review autofix) — applied
focus()was called on every render while open → moved to auseEffectkeyed on[isOpen, position, activeIndex](3-reviewer corroboration).NewTaskModalpost-create/close reset omittedsetEnabledWorkflowSteps([])→ added to both reset blocks.Residual Review Findings
These were surfaced by the autofix review and are intentionally not addressed in this PR (out-of-diff scope, behavioral decisions, or test-hardening). Recorded here verbatim as the durable handoff:
fn_task_createcannot setenabledWorkflowSteps(packages/engine/src/agent-tools.ts). The store (TaskCreateInput) and HTTP route both acceptenabledWorkflowSteps, but the agent tool schema/execute path do not expose it, so an agent cannot opt into/out of optional steps at create time. Fix: add an optionalenabled_workflow_stepsarray param and forward it tocreateAgentTask.packages/engine/src/__tests__/stepwise-workflow-parity.test.ts:583). The seam test uses a spy but never setsenabledWorkflowStepson the task, so it proves graph routing but not that the seam readsenabledWorkflowSteps→ writesworkflowStepResults. Harden: setenabledWorkflowSteps:["browser-verification"], assertworkflowStepResultspopulated, and add an OFF-sibling asserting none.InlineCreateCardvsTaskForm). InlineCreateCard resolves the effective workflow to'builtin:coding'when no default is configured; TaskForm shows no steps. Canonicalize the fetch/seed/toggle wiring (e.g. a shareduseWorkflowOptionalStepshook) — behavioral decision, needs intent.optionalSteps(copyIrWithFreshIdspath, not in this diff). Verify and add coverage that declarations survive create-from-template.rework-hold → workflow-stepedge and the threeworkflow-step → endoutcome edges have no execution-level test.settingsload (benign today; flagged by 2 reviewers) — clears then re-seedsenabledWorkflowStepsonce the default workflow id resolves.Advisory (verify before acting): FNXC_LOG comments + FN-XXXX commit-prefix conventions; mobile portal / iOS-keyboard drift and offscreen-toggle horizontal-scroll require real-browser verification (plan R-3).
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
UI Enhancements
Bug Fixes