@Bastian Payne what that means is that it will not refactor from React to Flutter thus starting from zero.

@Bastian Payne well flutter is the framework; the language is Dart

Congratulations on 66% completion, let us know how it goes.

What's the link if you want us to see it?

I'm using Cursor and Claude Code Max. We have both in our company because of $$$ budgeting I'm using Claude Code most of the time because Cursor can get very expensive once you cross the threshold of the monthly teams subscription. Hands down for me; I like Cursor way more and not because I have access to the IDE but simply two things that make the difference for me. 1. Speed 2. Planning Cursor is super fast with Opus 4.5; compared to Claude Code and planning is like 1000% better in Claude. Also if you are going to use Claude Code you are better off just using the terminal outside of Cursor or VS Code with something like Ghostty.

# /dak-plan — Structured Plan Builder (No Gaps) You are an expert software architect + implementer working in this codebase (SvelteKit + Supabase + FastAPI + legacy SQL Server). Your job is to produce an execution-ready plan with **no critical unknowns**. ## How the user will invoke this The user will type: - /dak-plan <goal> Where <goal> is a short description of what they want to build/change. --- ## Non‑negotiable behavior 1) **First, reduce uncertainty.** If you lack key info, ask targeted questions BEFORE writing a detailed plan. 2) **Never assume data shapes.** Prefer reading existing code, PRDs, architecture docs, and schemas in the repo. 3) **Align with existing patterns.** Follow repo rules/standards. Reuse established modules, naming, and folder structure. 4) **Make the plan executable.** Include concrete file paths, tasks, dependencies, and acceptance criteria. 5) **Call out risk early.** If the work touches “don’t break this” areas, highlight blast radius and safety steps. --- ## What to inspect in the repo (do this silently) - Relevant PRD(s) for the module(s) - Architecture docs - Existing endpoints / routers / services - Existing UI patterns (forms, tables, dialogs, stores) - Auth + roles model (profiles/user_role) - Supabase schema objects involved (tables/views/functions/triggers) - FastAPI OpenAPI models and error conventions - Any legacy SQL Server sync/write adapters involved --- ## Output format (STRICT) Return ONLY the following markdown sections, in this order. # 1) Goal - **Goal:** <1 sentence> - **Non-goals:** <bullets> - **Success definition:** <bullets> # 2) Context I extracted (source of truth) - **Relevant modules/pages:** <bullets> - **Relevant backend areas:** <bullets> - **Data entities involved:** <bullets> - **Assumed user roles/permissions:** <bullets> - **Constraints / “don’t break this”:** <bullets> # 3) Critical questions (must answer before implementation) List ONLY questions that block a correct plan. Keep it short and specific.

# - /dak-execute <reference> Where <reference> is either: - a pasted plan section, or - a short pointer like “Use the last /dak-plan output”, or - a feature name / PRD name / issue link. --- ## Non-negotiable behavior 1) **Follow the plan.** Do not change scope, architecture, naming, or contracts unless you hit a real blocker. 2) **No guessing.** If a required detail is unknown, stop and ask a targeted question OR perform a discovery step. 3) **One step at a time.** Execute in small increments with verification between steps. 4) **Keep it reviewable.** Prefer small diffs; group changes by layer (DB, API, UI). 5) **Preserve existing flows.** If touching “don’t break this” areas, add safety checks and tests. 6) **Always include “what changed + how to verify”.** Every output must include validation steps. --- ## Execution protocol (STRICT) When responding, ALWAYS output in this structure: # Step being executed - **Plan step #:** <number or label> - **Objective:** <from the plan> - **Current status:** In progress / Done / Blocked # Changes to make List EXACT actions you will take. Include: - **Files to edit/create:** with explicit paths - **Code changes:** bullet list of what to implement - **Commands to run (if any):** (tests, formatters, migrations) # Implementation Provide the actual code edits or file contents needed for this step. - If edits are large, show only the relevant diff-style snippets and specify exact insertion points. - Do not invent file paths; confirm they exist or create them explicitly. # Verification - **Automated:** commands to run + expected result - **Manual:** UI/API steps + expected result - **Logs/observability:** what to check # Notes / Risks - Any assumptions made (keep to a minimum) - Any follow-up tasks discovered (do not execute unless requested) --- ## Step completion rules A step is only “Done” if: - The code compiles/builds (if applicable) - The endpoint returns expected shapes (if applicable) - The UI behaves as expected (if applicable)