tk3.biz
Back to Blog

[Released] dev-orchestra: Parallel Work Units and Per-Role Instructions v1.1.0 - v1.2.1

Introduction

dev-orchestra is a plugin for Claude Code / Codex / Antigravity that takes a one-sentence request through design, implementation, testing, review by several AIs, and fixes.

This post rounds up the changes from v1.1.0 to v1.2.1 (five releases: 1.1.0, 1.1.1, 1.1.2, 1.2.0 and 1.2.1). What 1.0.0 does is covered in the introduction post.

dev-orchestra is open source on GitHub (MIT license). If it looks useful, a star would mean a lot.

→ github.com/istb16/dev-orchestra

Main changes

Split a plan into work units and run them side by side (1.2.0)

If a plan (plan.md) has a ## Units section, it can now be implemented as work units. Units that don’t depend on each other run side by side, each in its own git worktree, and each is merged back into the working tree file by file as it finishes.

  • units check refuses units that cannot run, such as two whose files overlap, before anything runs, and prints the order they will run in (waves)
  • How many run at once is implementation.max_parallel (default 2, up to 8)
  • The units of one plan share a single implementer attempt
  • A plan without units runs once, as before

I walk through running two units side by side in the work units post.

Standing instructions per role (1.2.1)

Instructions written under instructions in the configuration, per role (orchestrator, architect, implementer, review_fixer, reviewers, design_reviewers), now go into that role’s prompt on every run. Things you used to repeat in every request, like “run tests with make test” or “ask before touching db/”, can be written once.

# .dev-orchestra.yaml
instructions:
  orchestrator: "Ask before adding a new dependency."
  implementer:
    file: .dev-orchestra/implementer.md
  reviewers: "Check that every public function in textkit/ has a docstring."

Alongside it came implementation.unit_tests: after_merge, which runs the units’ tests once after merging, and implementation.worktree_files, which copies git-ignored files (such as .env.test) into each unit’s worktree. See the per-role instructions post for how to use them.

Questions before the design (1.1.0)

With design.ask_questions set to auto or true, dev-orchestra now asks you questions about the requirements before the plan is written. The orchestrator asks the questions it noticed itself, then the architect asks the ones it found by reading the code. The answers are collected in decisions.md and reflected in the plan’s ## Decisions.

dev-orchestra config set design.ask_questions auto

It is off (false) by default, and while it stays off nothing changes from 1.0.0. The number of question rounds is capped by design.max_question_rounds (default 2).

Configurable progress reports (1.1.2)

The new progress settings decide how often the orchestrator reports during a long run.

SettingDefaultWhat it does
progress.updatesautotrue always runs architect runs and reviews in the background and reports on them. false keeps only the “may be stuck” notice
progress.interval_seconds180How often to report (30 to 3600 seconds). Also the default wait of jobs wait
progress.quiet_notice_seconds600With no tool activity for this many seconds, it says may be stuck. 0 turns it off

The “may be stuck” notice only informs; it never cancels the run.

Changes you may need to act on

  • If you capture its output on Windows (1.2.0). Output to a pipe or a file is now written in UTF-8. Japanese read by the agent is no longer garbled, but capturing it in PowerShell, as in $x = dev-orchestra ..., now garbles it there instead. Set [Console]::OutputEncoding to UTF-8, or set PYTHONIOENCODING=cp932 to get the old output
  • The default wait of jobs wait (1.1.2). Without --timeout, it now waits 180 seconds (progress.interval_seconds) instead of 60
  • The wording of config validate (1.1.2). Messages for settings that accept null now say or null. The accepted values haven’t changed, but a script that matches the message text from config validate --json or doctor --json needs updating
  • Your own adapters. Provider.worktree_files (1.2.0) and Provider.file_read_tools (1.2.1) were added. Both have defaults, so nothing needs to change

Smaller changes and bug fixes

  • A work unit whose run is gone is now recorded as failed as soon as units status or run implementer --unit runs (no need to run units clean first)
  • A file to be copied into a unit’s worktree that goes through a link, or isn’t a regular file, is now skipped with a note:
  • The workflow guidance now asks for shorter plans, splits a plan with more than four steps into work units, and sends small jobs to the light tier (to keep costs down; the CLI’s behavior is unchanged)
  • On Windows, a file being replaced could vanish for an instant to a reader, so a running job or its state could be read as missing. Fixed
  • On Windows, hooks install / hooks uninstall couldn’t write a settings.json that Claude Code or an editor had open. They now retry
  • reviewer set --role now drops the old role’s relevance rule when the role changes and says so (as the setup wizard does)
  • Antigravity CLI (agy) 1.4.7 reads files with read_file, so the tool activity display and the live checks now accept it as well as view_file
  • The live check script (scripts/smoke_live.py) no longer crashes when printing results on a Japanese Windows console
  • The README now opens with an animated example run

Stabilization

As usual, there was internal reorganization for stability, such as splitting large files by responsibility, along with added and tidied tests. CI now runs the tests split into parts in parallel. Nothing changes from a user’s point of view.

How to update

How you update depends on your CLI. Follow the steps in the update post with the new version’s tag (v1.2.1). After updating, it’s worth running dev-orchestra doctor once.

Summary

  • Work units (1.2.0): split a plan, and run the independent parts side by side in worktrees
  • Per-role instructions (1.2.1): instructions under instructions go into the prompt on every run. Plus a setting to run the units’ tests after merging
  • Questions before the design (1.1.0): design.ask_questions checks the requirements before the plan
  • Progress reports (1.1.2): progress sets the interval and the “may be stuck” notice
  • If you capture its output on Windows, watch out for the switch to UTF-8

GitHub: istb16/dev-orchestra (a star is always appreciated)

Related Posts