Workers, monitor, merge

Send non-critical work to orkai/work. You keep the critical task in OpenCode. Test that branch yourself.

The idea

A model is a resource. Two unrelated jobs should not share one prompt and rewrite catalog math. Daily specials is a banner. The accountant CSV is an export. Neither is “make croissant 350 into a float.”

Background workers pick up tasks that already have a workflow_id and a model. That model id is an OpenCode id. If OpenCode cannot call the key, the worker cannot run.

Default integration branch is orkai/work. Each task runs in a worktree and merges there. You do not merge to main from a chat. When the tasks are on orkai/work, you switch to that branch, test, then you accept the land to main.

Workers are for work you can let run: extra UI, an export, tech debt, a benchmark, an A/B. Critical path stays with you in OpenCode, where you read the reasoning live. Most days that means one critical task in the chat, and planning while the workers run.

Do this in OpenCode

1. In OpenCode, configure the models you will use. Valid keys. /connect adds a provider. /models lists what is connected. You do not have to put them in a global opencode.json.
2. Open the orkai window. Setup, then Work. Planner first, then the coding models.
3. New chat in the Stall folder. Extend the same Stall requirement (Product Owner, Architect if needed, Feature Planner). Do not put model or workflow on the tasks in the chat.
4. Open Project Manager, select the plan, switch to Work mode. Select the tasks, Configure work. Assign Fullstack Developer and a DeepSeek id in bulk. You will see the models and workflows already in orkai.
5. orkai work start, then orkai work monitor --category stall (use the name or id from .orkai.yaml if yours is different). You can keep planning in OpenCode while that runs.
6. When the tasks are merged into orkai/work, switch to that branch and test it yourself. Then review against main and merge. Save the session.

Workflows: Workflows. Tasks: Plans, milestones and tasks. Review: Review.

OpenCode first

orkai Work does not log you into a provider. OpenCode does. Each model you will assign must already work in OpenCode with a valid key. If a model is missing there, do not add it in orkai and hope.

Work setup in orkai

Run orkai open if the window is not already open. Open Setup, then Work. Two different jobs:

• Planner. A small LLM that decides which pending tasks can run together. Ollama or OpenAI-compatible only. You can reuse the Review model if it is compatible. For this tutorial, DeepSeek V4 is enough.
• Coding models. These ids are OpenCode provider/model for task assignment, not the planner.

orkai open

The models list is not “everything you use in OpenCode.” It shows free OpenCode models plus whatever is already in the global OpenCode config file. Many people never touch that file. They add keys with /connect inside OpenCode, then check /models. Those models will not appear in orkai until you type the exact id yourself.

Example of an exact id: xai/grok-4.6. Wrong names fail later, not now. For Stall, add and use:

• deepseek/deepseek-v4-pro
• deepseek/deepseek-v4-flash

Mark one as default. Both must already work in OpenCode.

Extend Stall, then assign in Work mode

Same requirement as before. Specials: a banner on the shop, not the catalog price table. CSV: an export the accountant can open. Tasks must not touch croissant cents or the sold-out rule. Same loop you already know: Product Owner, Architect if needed, Feature Planner. Leave model and workflow empty.

Load the Product Owner workflow to extend the requirement. The new features are: a daily specials banner on the shop, and an accountant price CSV. Still catalog plus orders. No payments. Do not change catalog pricing rules.

Load the Architect workflow to validate if the new features need to extend the architecture or a new standard.

Load the Feature Planner workflow. Add this work to the existing Stall v1 plan. New milestones are enough. Do not assign workflow_id or model on the tasks. Stop for my approval.

Then orkai open. Project Manager, open the plan, switch Default to Work mode. Select the new tasks (or Select all). Configure work assigns workflow and model together. That list is the models and workflows you already configured. Start with one lane, or many tasks from many milestones. The planner coordinates. Do not start workers until this is done.

Start workers and watch

orkai work start
orkai work monitor --category stall

start wakes the worker inside the daemon you already have running.

Monitor is how you watch without sitting in every chat. Same board in two places: the terminal command above, or orkai open → Work Monitor. You see tasks that are valid for work (workflow and model already assigned), plus in progress, done, and blocked.

Open a task that is in progress. You get Details, Steps, and Opencode: live reasoning from the background run. That is the value. You still keep one critical task in your own OpenCode chat. Monitor is for the rest.

Always pass --category with this project's name or id from .orkai.yaml. Without it, you see every project. There is no /docs/work page.

Test on orkai/work

Worktrees merge into orkai/work, not into your current checkout. When monitor says the tasks are done, switch and validate there. Catalog math must still hold.

git switch orkai/work

Merge to main is an accept decision

Do not merge orkai/work to main until I have tested that branch and orkai review --process stall passes vs main.
I will run review. If it fails, fix. Then merge.

orkai review --process stall --base main --head HEAD

Done looks like this

Specials and the CSV landed on orkai/work through the git hook. You switched there and tested. Review vs main passed. You merged on purpose. The critical shop rules stayed in your hands.

Save the session

Save the session, I will continue in a new one.

Recap

You kept one critical thread. Workers filled orkai/work. You tested that branch. Parallel work is extra evidence under the same house rules. Next you ask the project where Stall stands.