# Run a real project end to end By the end of this page you will have a small project that runs itself: a brief you can read, a plan that tracks the actual work, and a dashboard that shows you what is still open without you updating anything by hand. The point is not any one of those pieces. It is the way they connect, so the project stays current as a by-product of doing the work, not as a chore on top of it. This is the escalation ladder in Undra. You start at the lowest-friction surface, a note, and you only move up a rung when the work demands it. Nothing gets copied between rungs, so there is never a second version to keep in sync. ## Step 1: Capture in a note Start in a [note](/docs/workspace/notes/). A note is the cheapest place to think, so it is where a project should begin: a paragraph of context, a few half-formed tasks as `- [ ]` lines, whatever is in your head right now. Do not try to structure it. The whole reason to start here is that you do not have to. Why a note first: most of what you capture never becomes tracked work, and forcing structure up front is wasted effort. Capturing in a note keeps the cost of writing something down near zero, and a note can always grow up later. ## Step 2: Promote it to a plan when it becomes work At some point the note stops being thinking and starts being work: there are tasks with an order, some have due dates, some depend on others. That is the signal to move up a rung to a [plan](/docs/workspace/plans/), where each task carries real structure (a status, a due date, a label) and the same tasks flow through list, board, and calendar views. Why promote rather than rewrite: a checklist in a note has no status, no due date, and no ordering you can sort on. A plan gives the work those handles, so you can sequence it and see what is due, which is exactly what you could not do while it was still loose text. :::tip Promote at the right moment Move to a plan when status, due dates, or ordering start to matter. Before that, the note is doing fine, and a plan is just overhead. See [Plans](/docs/workspace/plans/) for the full anatomy of a task. ::: ## Step 3: Attach the brief back as a detail note Now you have two things: the original writing (the context, the why, the decisions) and the plan (the tasks). Keep them connected. Attach the note to the plan as its detail note, so the plan holds the narrative behind the tasks and its header links straight back to the writing. The mechanics of detail notes live on the [Plans](/docs/workspace/plans/) page. The glue is a [wikilink](/docs/workspace/wikilinks-and-backlinks/). When the plan points at the brief by name with `[[Project brief]]`, that link is two-way: the brief automatically gets a backlink to the plan, with no second link to maintain. So from the plan you reach the context, and from the brief you can see every plan and task that references it. Individual tasks can wikilink out too, so a task points straight at the spec or meeting note it came from. Why bother linking instead of pasting: pasting the brief into the plan would create a copy that drifts the moment you edit either side. A wikilink keeps one source of truth and connects to it. If you want the brief to actually render inside another item, an embed (`![[Project brief]]`) shows it live and still editable, rather than a stale paste. Both forms are covered in [Wikilinks & Backlinks](/docs/workspace/wikilinks-and-backlinks/). ## Step 4: Build a dashboard that surfaces the open tasks live The last rung is a [dashboard](/docs/workspace/dashboards/): one view that sits above the project and answers "what should I look at right now?" Add a query-list widget and point it at this plan's tasks, sorted by due date. The widget reads your live workspace every time, so it always shows the current open tasks. You are not copying tasks onto the dashboard, you are opening a live window onto them. This is the part that makes the project run itself. Because the dashboard surfaces tasks by reference rather than by copy, finishing a task in the plan removes it from the dashboard with nothing for you to update. Drop a query list for what is due, a link back to the brief, and you have a one-screen command center for the project. The widget types and how query lists read your workspace are detailed on [Dashboards](/docs/workspace/dashboards/). :::note Query by reference, not by copy Every rung above the note works the same way: the plan references the brief, the dashboard references the plan's tasks. Nothing is duplicated, so there is nothing to keep in sync. Edit the source once and every surface that points at it updates on its own. ::: ## Why the ladder works You climbed from a throwaway note to a self-updating dashboard, and at no point did you maintain two copies of anything. Capture stayed cheap because it started in a note. The work got real handles when it became a plan. The context stayed attached through a wikilink. And the dashboard stays current because it queries by reference instead of holding copies. That is the whole model: start low, escalate only when the work demands it, and connect rather than duplicate. ## Where to go next - **[Plans](/docs/workspace/plans/)**: the full anatomy of tasks, views, and detail notes. - **[Dashboards](/docs/workspace/dashboards/)**: query-list widgets and the other tiles you can add. - **[Wikilinks & Backlinks](/docs/workspace/wikilinks-and-backlinks/)**: the two-way links and embeds that hold it all together.