Using the workspace

Big tasks: how Dus leads

For big requests Dus writes a lead plan, runs each part as a helper in its own copy, checks every result itself, merges them one at a time and reports what works.

Some requests are really several pieces of work: "add CSV export, a dark mode toggle and overdue reminders". Dus handles these the way a lead engineer does. It plans the work, splits it into parts that don't touch the same files, gives each part to a helper, checks every result itself, and merges the parts one at a time.

1. The plan

When a request has clearly separable parts, Dus writes a lead plan. You see it in the chat as plain steps and a list of tracks. Each track shows:

what it builds;
which files it may change;
what it waits for, if it builds on another track.

Work that can't be done in parallel is marked one at a time. That covers shared numbering (decision and migration numbers), migrations, lockfiles and merging itself.

You have three choices:

Start plan runs it.
Edit lets you change any track's title, what it builds, its files and what "done" means. Dus checks the plan again before it is saved.
Ask for changes puts a note in the message box, so you can say what you want in your own words. Dus rewrites the plan.

Set aside drops the plan. In Plan mode the tracks can't run; switch to Ask or Auto first. Small or tightly connected work is done by Dus directly, without a plan.

Behind each track is a complete brief: the goal, what to read first, the exact files, what's out of scope, the rules, what "done" means and what to report. A helper never has to guess. Every brief carries the same standing rules: add tests with every change; no network in tests; work only in your own copy; temporary files in .duscode/tmp; its own ports; placeholder numbers; never merge or push.

2. The helpers

Each track runs as a helper (a worker) in its own git worktree and branch.

How many at once: your Tasks at once setting, lowered when the machine is busy. The board then says why, for example "the machine's load is 74 on 16 cores".
Budget: each helper gets a share of the run's budget, never more than your own per-task budget.
Permissions: helpers work in your permission mode and ask the same approvals you would.

Dus watches every helper: what it's doing, its last activity and its cost.

It goes quiet. After 5 minutes the board says so. After 10, Dus restarts it where it stopped.
The outside world fails (a rate limit, a provider outage, a crash). Dus resumes the helper as it was.
The work itself falls short. Dus revises the brief once and asks for a diagnosis first. If it falls short again, the track is marked Needs you, with the reason in plain words.

3. Checked before merging

Dus never takes a helper's word for it. For each finished track:

Dus runs the project's checks itself, in the helper's copy, and reads the real exit codes.
A fresh reviewer, often a different model, reads the brief, the change and the check results. It reports findings as blocker, major or minor.

Blockers, majors and failed checks go back to the helper to fix. After two rounds of fixes Dus stops and tells you plainly what's still wrong. You can then have Dus fix it itself, merge it anyway, or drop it.

4. Merging one at a time

Tracks are merged into your session's branch one at a time, in the plan's order:

Conflicts. Where both tracks only added lines (two new entries in the same list), Dus keeps both. Anything that needs judgement goes back to the helper, with the files named, to resolve while keeping both intents. Dus looks at the history before calling anything a bug.
Shared numbers. Placeholder numbers such as ## D-EXPORT become real ones. The numbers come from the project's shared allocator (the Team board), so two sessions never take the same one.
Checks. The full checks run on the merged result before the merge is committed. If they fail, the merge is undone and the track goes back to its helper.

Merging into main stays a separate step: Finish the session as usual.

5. The report

The board shows each track's status, what it's doing, its cost and its result. Dus posts short updates at milestones: a track done, a review finding, a merge, a stall.

At the end you get:

What works now, with the evidence: each merge commit, and the checks with their exit codes;
What's left, and why;
Try it: how to see each part working.

Dus never says "done" without that evidence.

Your queue, in parallel

When you queue several requests, Dus doesn't always do them one by one.

Which run together. Requests that touch different parts of the project run at the same time, each as a track like the ones above. Requests that touch the same files, need the same migration numbers or lockfile, or build on the one before ("then…", "once that's merged…") wait their turn.
How they finish. Each track is taken to "ready to merge". Then the merge train merges them one at a time, with the checks after each merge.
Where you watch them. They all share one board.
When it doesn't happen. If fewer than two could run at once, the queue works as before. To keep the queue one at a time, set "queue": { "parallel": false }.

Waiting without sleeping

When a task only waits on something outside, Dus parks it instead of sitting idle. That covers a merge queue, CI, a deploy, a review, or a rate limit. It then works on your next queued task.

How Dus watches it. It checks the wait on a schedule that fits it, every 5 minutes for a merge queue, without using the model.
What you see. The queue panel shows "Waiting for: merge queue (#679, 6th) · next check 14:05", with Resume now and Stop waiting.
When it comes back. When the wait ends, or fails, the task comes back at the next pause in the current work, with what the check printed (the logs, if it failed). Dus tells you in one line.

Lessons and scorecards

Lessons. When a review finds a habit rather than a one-off slip ("temporary files belong in .duscode/tmp"), it becomes a project lesson. Dus reads the lessons at the start of every task. You can read and edit them in Memory and skills.
Scorecards. Every track gets a scorecard: did it pass its first review, how many rework rounds it took, its cost and time, and who found the problems (the reviewer, Dus's own checks, or the helper itself). The scorecards appear under the plan's report and in the task's Proof of Work. They are also saved in .duscode/lead/scorecards.jsonl.

Settings

In .duscode/config.json:

json

{ "lead": { "budgetUsd": 5 }, "lessons": true, "judgement": true }

"lead": false turns lead plans off.
budgetUsd caps a whole run.
"lessons": false stops reading lessons.
judgement switches the working habits on and off.