Skip to content

feat: make Plan mode available for all users#2625

Merged
wwwillchen merged 2 commits intodyad-sh:mainfrom
wwwillchen-bot:agent--1770825441787-1770826627
Feb 11, 2026
Merged

feat: make Plan mode available for all users#2625
wwwillchen merged 2 commits intodyad-sh:mainfrom
wwwillchen-bot:agent--1770825441787-1770826627

Conversation

@wwwillchen-bot
Copy link
Collaborator

@wwwillchen-bot wwwillchen-bot commented Feb 11, 2026

Summary

  • Move the Plan mode option outside the isProEnabled conditional so it's accessible to all users
  • Agent v2 remains Pro-only
  • Plan mode allows users to design and plan before building, which is valuable for all users

Test plan

  • Verify Plan mode appears in the chat mode selector for non-Pro users
  • Verify Agent v2 only appears for Pro users
  • Verify both modes work correctly when selected

πŸ€– Generated with Claude Code


Open with Devin

Summary by cubic

Made Plan mode available to all users in the chat mode selector, and allowed plan-only flows to run without Pro while Agent v2 remains Pro-only.
Exiting Plan now requires explicit user confirmation before switching to implementation.

Written for commit 7c2749b. Summary will update on new commits.

Move the Plan mode option outside the `isProEnabled` conditional so it's
accessible to all users, not just Pro subscribers. Agent v2 remains
Pro-only.

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@wwwillchen
Copy link
Collaborator

@BugBot run

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @wwwillchen-bot, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request broadens access to the 'Plan mode' feature, allowing all users to leverage its design and planning capabilities before initiating development. This change aims to enhance the overall user experience by providing valuable planning tools to a wider audience, while maintaining 'Agent v2' as a distinct offering for Pro users.

Highlights

  • Plan Mode Accessibility: The 'Plan mode' feature has been made available to all users, removing the previous restriction to Pro subscribers.
  • Agent v2 Exclusivity: The 'Agent v2' feature remains exclusive to Pro users, ensuring its advanced capabilities are retained for premium accounts.
Changelog
  • src/components/ChatModeSelector.tsx
    • Moved the 'Plan mode' SelectItem component outside the 'isProEnabled' conditional block.
Activity
  • The author provided a test plan to verify that 'Plan mode' appears for non-Pro users, 'Agent v2' remains Pro-only, and both modes function correctly upon selection.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with πŸ‘ and πŸ‘Ž on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 1 file

Copy link
Contributor

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Open in Devin Review

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 11, 2026

Greptile Overview

Greptile Summary

This PR makes Plan mode available to all users by exposing the Plan option in the chat mode selector regardless of Pro status, while keeping Agent v2 behind the existing Pro gate. On the main-process side, it updates the local-agent handler’s Pro check to allow planModeOnly requests (used by plan mode) to run without Pro/basic-agent.

One correctness issue introduced: the exit_plan tool schema was widened from literal(true) to boolean, which allows confirmation: false tool calls to validate and then error at runtime.

Confidence Score: 4/5

  • Mostly safe to merge, with one tool-contract issue to address.
  • The Plan mode gating changes are straightforward and align UI + main-process gating, but widening exit_plan’s schema introduces a new, avoidable runtime error path (confirmation=false validates then throws) that can break plan-mode flows.
  • src/pro/main/ipc/handlers/local_agent/tools/exit_plan.ts

Important Files Changed

Filename Overview
src/components/ChatModeSelector.tsx Moves the Plan mode out of the Pro-only conditional so non‑Pro users can select Plan; Agent v2 remains gated by isProEnabled.
src/pro/main/ipc/handlers/local_agent/local_agent_handler.ts Adjusts Pro gating so handleLocalAgentStream allows planModeOnly requests for non‑Pro users (still blocks non‑readOnly, non‑planModeOnly agent runs without Pro/basic-agent).
src/pro/main/ipc/handlers/local_agent/tools/exit_plan.ts Broadens exit_plan input schema to boolean and adds runtime rejection when confirmation is false; this creates a mismatch where the tool can be invoked with confirmation=false and will now throw.

Sequence Diagram

sequenceDiagram
  participant User as User (renderer)
  participant UI as ChatModeSelector
  participant IPC as chat_stream_handlers
  participant LA as handleLocalAgentStream
  participant Tool as exit_plan tool

  User->>UI: Select "Plan" mode
  UI->>IPC: Start chat stream (selectedChatMode="plan")
  IPC->>LA: handleLocalAgentStream(planModeOnly=true)
  LA-->>IPC: Stream response with plan-only toolset
  LA->>Tool: (model) calls write_plan / exit_plan
  Tool-->>IPC: safeSend("plan:exit", {chatId})
  IPC-->>UI: UI switches to local-agent for implementation
Loading

@github-actions
Copy link
Contributor

github-actions bot commented Feb 11, 2026

πŸ” Dyadbot Code Review Summary

Verdict: β›” NO - Do NOT merge

Reviewed by 3 specialized agents: Correctness Expert, Code Health Expert, UX Wizard.

Issues Summary

# Severity File Issue Found By Endorsed By
1 πŸ”΄ HIGH local_agent_handler.ts:266 Plan mode blocked by Pro-only guard for non-Pro users Correctness Team Lead (verified)
2 🟑 MEDIUM DefaultChatModeSelector.tsx:38-49 Plan mode missing from DefaultChatModeSelector (settings page) UX Team Lead (verified)

Details

1. πŸ”΄ HIGH β€” Plan mode blocked by Pro-only backend guard

The backend handler handleLocalAgentStream in local_agent_handler.ts:266 has this guard:

if (!readOnly && !isDyadProEnabled(settings) && !isBasicAgentMode(settings)) {
    // returns error: "Agent v2 requires Dyad Pro."
}

When a non-Pro user selects Plan mode:

  • readOnly = false (plan mode sets planModeOnly: true, not readOnly: true)
  • isDyadProEnabled(settings) = false (not a Pro user)
  • isBasicAgentMode(settings) = false (plan mode is "plan", not "local-agent")

All three conditions are met β†’ the guard fires β†’ non-Pro users get "Agent v2 requires Dyad Pro" error. The entire feature this PR delivers is broken for non-Pro users.

πŸ’‘ Fix: Add !planModeOnly to the guard:

if (!readOnly && !planModeOnly && !isDyadProEnabled(settings) && !isBasicAgentMode(settings)) {

2. 🟑 MEDIUM β€” Plan mode missing from DefaultChatModeSelector

The DefaultChatModeSelector (used on the Settings page) does not include Plan as an option. Its getModeDisplayName function has no "plan" case and would throw an error if "plan" were somehow set as the default. Users who discover Plan mode cannot set it as their default chat mode.

πŸ’‘ Fix: Add a "plan" case to getModeDisplayName and add a Plan SelectItem to the dropdown.

🟒 Low Priority Notes (2 items)
  • Dropdown ordering for non-Pro users β€” src/components/ChatModeSelector.tsx (UX) β€” For non-Pro users, Plan appears first in the dropdown before Basic Agent. This is a reasonable placement since Plan is the newly-promoted feature, but could be reconsidered if the conceptual flow of plan β†’ agent β†’ build β†’ ask is preferred.
  • NewBadge on Plan for all users β€” src/components/ChatModeSelector.tsx (UX) β€” Pre-existing concern, not introduced by this PR. Worth noting for future cleanup when the feature is no longer "new."
🚫 Dropped Issues (1 item)
  • Order change for Pro users β€” Initially flagged as MEDIUM by UX reviewer, but challenged by Correctness and Code Health reviewers: the rendered DOM order for Pro users is unchanged (Agent v2 β†’ Plan). Only the JSX structure changed, not the visual output. Dropped by consensus.

Generated by Dyadbot code review

</div>
</SelectItem>
)}
<SelectItem value="plan">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ”΄ HIGH | logic | Found by: Correctness Expert, Verified by: Team Lead

Plan mode is blocked by Pro-only backend guard for non-Pro users

The Plan SelectItem is now visible to all users, but the backend handler handleLocalAgentStream in local_agent_handler.ts:266 has a Pro-only guard:

if (!readOnly && !isDyadProEnabled(settings) && !isBasicAgentMode(settings)) {
    // returns error: "Agent v2 requires Dyad Pro."
}

For non-Pro users selecting Plan mode: readOnly = false, isDyadProEnabled = false, isBasicAgentMode = false β†’ guard fires β†’ error.

The planModeOnly parameter is not checked by this guard. Non-Pro users will see Plan mode in the UI but get an error when they try to use it.

Suggested change
<SelectItem value="plan">
<SelectItem value="plan">
<div className="flex flex-col items-start">
<div className="flex items-center gap-1.5">
<span className="font-medium">Plan</span>
<NewBadge />
</div>
<span className="text-xs text-muted-foreground">
Design before you build
</span>
</div>
</SelectItem>

Note: The UI change here is correct. The fix needs to be in local_agent_handler.ts:266 β€” add !planModeOnly to the guard:

if (!readOnly && !planModeOnly && !isDyadProEnabled(settings) && !isBasicAgentMode(settings)) {

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly makes the 'Plan' mode available to all users by moving it out of the Pro-only conditional rendering. The change is straightforward and achieves the stated goal. I've added one suggestion to improve code maintainability by reducing duplication in how the chat mode options are rendered. This is an optional refactoring that you might consider for cleaner code.

Comment on lines 130 to +153
{isProEnabled && (
<>
<SelectItem value="local-agent">
<div className="flex flex-col items-start">
<div className="flex items-center gap-1.5">
<span className="font-medium">Agent v2</span>
<NewBadge />
</div>
<span className="text-xs text-muted-foreground">
Better at bigger tasks and debugging
</span>
</div>
</SelectItem>
<SelectItem value="plan">
<div className="flex flex-col items-start">
<div className="flex items-center gap-1.5">
<span className="font-medium">Plan</span>
<NewBadge />
</div>
<span className="text-xs text-muted-foreground">
Design before you build
</span>
<SelectItem value="local-agent">
<div className="flex flex-col items-start">
<div className="flex items-center gap-1.5">
<span className="font-medium">Agent v2</span>
<NewBadge />
</div>
</SelectItem>
</>
<span className="text-xs text-muted-foreground">
Better at bigger tasks and debugging
</span>
</div>
</SelectItem>
)}
<SelectItem value="plan">
<div className="flex flex-col items-start">
<div className="flex items-center gap-1.5">
<span className="font-medium">Plan</span>
<NewBadge />
</div>
<span className="text-xs text-muted-foreground">
Design before you build
</span>
</div>
</SelectItem>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There's some structural duplication in how the SelectItem content is rendered for different chat modes. To improve maintainability and reduce repetition, you could extract this into a dedicated component. This would make the list of modes cleaner and easier to manage, especially as more modes might be added in the future.

For example, you could create a helper component:

const ChatModeItem = ({
  title,
  description,
  showNewBadge = false,
}: {
  title: string;
  description: string;
  showNewBadge?: boolean;
}) => (
  <div className="flex flex-col items-start">
    {showNewBadge ? (
      <div className="flex items-center gap-1.5">
        <span className="font-medium">{title}</span>
        <NewBadge />
      </div>
    ) : (
      <span className="font-medium">{title}</span>
    )}
    <span className="text-xs text-muted-foreground">{description}</span>
  </div>
);

And then use it like this for the common cases:

<SelectItem value="local-agent">
  <ChatModeItem title="Agent v2" description="Better at bigger tasks and debugging" showNewBadge />
</SelectItem>

<SelectItem value="plan">
  <ChatModeItem title="Plan" description="Design before you build" showNewBadge />
</SelectItem>

<SelectItem value="build">
  <ChatModeItem title="Build" description="Generate and edit code" />
</SelectItem>

This would simplify the main component's render method and make it more declarative.

@github-actions github-actions bot added the needs-human:review-issue ai agent flagged an issue that requires human review label Feb 11, 2026
@wwwillchen
Copy link
Collaborator

@BugBot run

@github-actions
Copy link
Contributor

github-actions bot commented Feb 11, 2026

πŸ” Dyadbot Code Review Summary

Verdict: πŸ€” NOT SURE - Potential issues

Reviewed by 3 specialized agents: Correctness Expert, Code Health Expert, UX Wizard.

Issues Summary

# Severity File Issue Found By Endorsed By
1 πŸ”΄ HIGH usePlanEvents.ts:117-118 Non-Pro user with exhausted quota gets stranded after accepting plan UX Correctness, Code Health
2 🟑 MEDIUM exit_plan.ts:9-12 Schema weakened from z.literal(true) to z.boolean(); interacts badly with stopWhen Correctness Code Health, UX

Details

1. πŸ”΄ HIGH β€” Non-Pro user with exhausted quota gets stranded after accepting plan

When a non-Pro user accepts a plan, usePlanEvents.ts:117-118 switches selectedChatMode to "local-agent", creates a NEW chat, and sends /implement-plan=<slug>. This routes through Basic Agent, which checks quota:

  • Quota available: Works, but silently consumes 1 of the user's 5 daily free messages with no warning
  • Quota exhausted: User gets FREE_AGENT_QUOTA_EXCEEDED error. They've been navigated to a new empty chat in local-agent mode with no plan context. The plan was saved to .dyad/plans/ but the user has no obvious recovery path.

πŸ’‘ Fix: Check quota BEFORE triggering plan:exit and warn the user, or keep the user in the original plan chat when implementation fails with a message explaining they need quota.

2. 🟑 MEDIUM β€” Schema validation weakened; interacts badly with stopWhen

The schema changed from z.literal(true) (rejects false at Zod validation) to z.boolean() (accepts false, then throws in execute()). The stopWhen array includes hasToolCall(exitPlanTool.name) β€” so when false passes validation and execute throws, stopWhen terminates the stream before the LLM can process the error and retry. The user sees a cryptic tool error: "Tool 'exit_plan' failed: User must confirm the plan before exiting plan mode."

With the original z.literal(true), schema validation failures don't trigger hasToolCall, so the LLM could retry with the correct value β€” strictly safer.

πŸ’‘ Fix: Keep z.literal(true) for schema-level rejection, or if z.boolean() is needed, return a message from execute() instead of throwing (e.g., return "Plan was not confirmed. Please ask the user to confirm.").

🟒 Low Priority Notes (1 item)
  • Stale comment doesn't mention planModeOnly bypass β€” local_agent_handler.ts:265 β€” Comment says "Read-only mode (ask mode) is allowed for all users without Pro" but doesn't mention plan mode is also now allowed. (Correctness, Code Health)

Generated by Dyadbot code review

Copy link
Contributor

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 new potential issue.

View 4 additional findings in Devin Review.

Open in Devin Review

Comment on lines 9 to 14
confirmation: z
.literal(true)
.describe("Must be true to confirm the user has accepted the plan"),
.boolean()
.describe(
"Whether the user has accepted the plan. Must be true to proceed.",
),
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟑 exit_plan schema weakened from z.literal(true) to z.boolean() allows LLM to call tool with confirmation: false

The confirmation field schema was changed from z.literal(true) to z.boolean(). This alters the JSON schema sent to the LLM: previously it was {"type": "boolean", "const": true}, now it is {"type": "boolean"}. This tells the LLM that false is a valid input value.

Root Cause and Impact

With z.literal(true), the LLM could only ever pass true for the confirmation field β€” the schema itself prevented any other value. With z.boolean(), the LLM might reason "the user hasn't accepted the plan yet, so I'll call exit_plan with confirmation: false" since the schema now advertises this as valid.

When confirmation is false:

  1. buildXml at src/pro/main/ipc/handlers/local_agent/tools/exit_plan.ts:49-50 returns undefined (no UI feedback)
  2. execute at line 56-58 throws "User must confirm the plan before exiting plan mode"
  3. The error is caught by the wrapper in src/pro/main/ipc/handlers/local_agent/tool_definitions.ts:379-386 and rendered as an error XML tag to the user

This wastes one of the 25 allowed tool steps (stepCountIs(25) at local_agent_handler.ts:530), produces a confusing error message for the user, and is a regression from the previous schema that made this impossible at the schema level. The original z.literal(true) was the correct approach β€” it communicated to the LLM that this tool should only be called when confirmation is granted.

Suggested change
confirmation: z
.literal(true)
.describe("Must be true to confirm the user has accepted the plan"),
.boolean()
.describe(
"Whether the user has accepted the plan. Must be true to proceed.",
),
});
.literal(true)
.describe(
"Must be true to confirm the user has accepted the plan.",
),
Open in Devin Review

Was this helpful? React with πŸ‘ or πŸ‘Ž to provide feedback.

Comment on lines 9 to +12
confirmation: z
.literal(true)
.describe("Must be true to confirm the user has accepted the plan"),
.boolean()
.describe(
"Whether the user has accepted the plan. Must be true to proceed.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟑 MEDIUM | contract-violation | Found by: Correctness, Endorsed by: Code Health, UX

Schema validation weakened from z.literal(true) to z.boolean()

The original z.literal(true) rejected false at Zod schema validation with a clean, structured error. The new z.boolean() accepts false through validation, then throws a generic Error("User must confirm the plan before exiting plan mode") in execute(). This thrown error may not be caught or surfaced to the user as cleanly as a Zod validation failure would be.

If the intent is to allow the LLM to explicitly pass false to indicate rejection, consider keeping z.literal(true) and adding a separate rejection_reason field, or handle false gracefully in execute() instead of throwing.

Comment on lines +55 to 62
execute: async (args, ctx: AgentContext) => {
if (!args.confirmation) {
throw new Error("User must confirm the plan before exiting plan mode");
}

logger.log("Exiting plan mode, transitioning to implementation");

safeSend(ctx.event.sender, "plan:exit", {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ”΄ HIGH | user-facing-behavior | Found by: UX, Endorsed by: Correctness, Code Health

Non-Pro user with exhausted quota gets stranded after accepting plan

When a non-Pro user accepts a plan and exit_plan fires successfully, the downstream flow in usePlanEvents.ts:117-118 switches selectedChatMode to "local-agent", creates a NEW chat, and sends /implement-plan=<slug>. This routes through Basic Agent, which checks quota:

  • Quota available: Works, but silently consumes 1 of the user's 5 daily free messages with no warning.
  • Quota exhausted: User gets FREE_AGENT_QUOTA_EXCEEDED error. They've been navigated to a new empty chat in local-agent mode with no plan context. The plan was saved to .dyad/plans/ but the user has no obvious recovery path.

πŸ’‘ Suggestion: Check quota BEFORE triggering plan:exit and warn the user, or keep the user in the original plan chat when implementation fails with a message explaining they need quota.

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment on lines 8 to +13
const exitPlanSchema = z.object({
confirmation: z
.literal(true)
.describe("Must be true to confirm the user has accepted the plan"),
.boolean()
.describe(
"Whether the user has accepted the plan. Must be true to proceed.",
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Schema allows invalid calls

confirmation used to be z.literal(true), which prevented the model from calling exit_plan unless it set confirmation: true. Changing this to z.boolean() means the model can now (and will occasionally) emit {"confirmation": false} tool calls; those will pass schema validation but then throw at runtime in execute(). That new failure mode can interrupt a plan-mode tool loop and surface as an avoidable tool error.

If the intention is still β€œonly allow true”, keep the schema as z.literal(true) (or use .refine(v => v === true) so invalid inputs are rejected at validation time rather than during execution).

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/pro/main/ipc/handlers/local_agent/tools/exit_plan.ts
Line: 8:13

Comment:
**Schema allows invalid calls**

`confirmation` used to be `z.literal(true)`, which prevented the model from calling `exit_plan` unless it set `confirmation: true`. Changing this to `z.boolean()` means the model can now (and will occasionally) emit `{"confirmation": false}` tool calls; those will pass schema validation but then throw at runtime in `execute()`. That new failure mode can interrupt a plan-mode tool loop and surface as an avoidable tool error.

If the intention is still β€œonly allow true”, keep the schema as `z.literal(true)` (or use `.refine(v => v === true)` so invalid inputs are rejected at validation time rather than during execution).

How can I resolve this? If you propose a fix, please make it concise.

@wwwillchen wwwillchen merged commit fd91778 into dyad-sh:main Feb 11, 2026
7 of 10 checks passed
@github-actions
Copy link
Contributor

🎭 Playwright Test Results

❌ Some tests failed

OS Passed Failed Flaky Skipped
🍎 macOS 341 0 5 110
πŸͺŸ Windows 342 1 6 110

Summary: 683 passed, 1 failed, 11 flaky, 220 skipped

Failed Tests

πŸͺŸ Windows

  • github.spec.ts > create and sync to new repo
    • TimeoutError: page.waitForSelector: Timeout 5000ms exceeded.

⚠️ Flaky Tests

🍎 macOS

  • capacitor.spec.ts > capacitor upgrade and sync works (passed after 1 retry)
  • context_manage.spec.ts > manage context - smart context (passed after 1 retry)
  • logs_server.spec.ts > system messages UI shows server logs with correct type (passed after 1 retry)
  • select_component.spec.ts > upgrade app to select component (passed after 1 retry)
  • setup_flow.spec.ts > Setup Flow > setup banner shows correct state when node.js is installed (passed after 1 retry)

πŸͺŸ Windows

  • chat_history.spec.ts > should open, navigate, and select from history menu (passed after 1 retry)
  • chat_input.spec.ts > send button disabled during pending proposal (passed after 1 retry)
  • edit_code.spec.ts > edit code (passed after 1 retry)
  • git_collaboration.spec.ts > Git Collaboration > should create, switch, rename, merge, and delete branches (passed after 1 retry)
  • setup_flow.spec.ts > Setup Flow > setup banner shows correct state when node.js is installed (passed after 1 retry)
  • setup_flow.spec.ts > Setup Flow > node.js install flow (passed after 2 retries)

πŸ“Š View full report

azizmejri1 pushed a commit to azizmejri1/dyad that referenced this pull request Feb 12, 2026
## Summary
- Move the Plan mode option outside the `isProEnabled` conditional so
it's accessible to all users
- Agent v2 remains Pro-only
- Plan mode allows users to design and plan before building, which is
valuable for all users

## Test plan
- [ ] Verify Plan mode appears in the chat mode selector for non-Pro
users
- [ ] Verify Agent v2 only appears for Pro users
- [ ] Verify both modes work correctly when selected

πŸ€– Generated with [Claude Code](https://claude.com/claude-code)
<!-- devin-review-badge-begin -->

---

<a href="https://app.devin.ai/review/dyad-sh/dyad/pull/2625"
target="_blank">
  <picture>
<source media="(prefers-color-scheme: dark)"
srcset="https://static.devin.ai/assets/gh-open-in-devin-review-dark.svg?v=1">
<img
src="https://static.devin.ai/assets/gh-open-in-devin-review-light.svg?v=1"
alt="Open with Devin">
  </picture>
</a>
<!-- devin-review-badge-end -->

<!-- This is an auto-generated description by cubic. -->
---
## Summary by cubic
Made Plan mode available to all users in the chat mode selector, and
allowed plan-only flows to run without Pro while Agent v2 remains
Pro-only.
Exiting Plan now requires explicit user confirmation before switching to
implementation.

<sup>Written for commit 7c2749b.
Summary will update on new commits.</sup>

<!-- End of auto-generated description by cubic. -->

---------

Co-authored-by: Will Chen <[email protected]>
Co-authored-by: Claude Opus 4.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-human:review-issue ai agent flagged an issue that requires human review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants