# Workflow Rules

These rules apply to workflow-layer code.

## Layer Boundary

- Workflows coordinate; they do not own prompt text.
- Agents own prompt text and `call_agent()` calls.
- Keep shared runtime mechanics in the data layer, not feature folders.

## Orchestrator Rules

- Use `context_scope(...)` at workflow entry points.
- Derive `task_path`, `plan_path`, and `module_path` from context, not hardcoded globals.
- Keep control flags explicit as function parameters.
- Keep orchestrator code focused on sequencing, branching, and retries.

## Agent Rules

- One agent file = one job.
- Agent handles its own model/provider/prompt formatting.
- Agent input should be explicit named args.
- Keep prompts consistent with current terminology (`modules`, `module.md`, etc.).

## Workflow Behavior Rules

- `create_task`:
  - requires `task_id`
  - `task_prefix` is optional
  - Linear routing is allowed only when `task_prefix` matches `.mixer/settings.json` `linear.team_prefix`
  - local tasks require `description` only when creating a new `task.md`
- Task module targeting uses `modules` only.
- `create_plan`: controlled by `branch_count` and `max_revisions`; formatter runs after build/review.
- `create_module`: build/test loop only (no reviewer loop for now).
- On terminal module test failure, write failure status in `module.md` and raise.

## Concurrency and Branching

- Branching is currently in plan workflow only.
- Branch plans live under root work folder `branches/`.
- Keep branch artifacts for traceability.
