@autodidacticon/orchestrator 0.1.0 → 0.3.0

package/hosts/claude-code/package.json

@@ -2,6 +2,6 @@
   "name": "orchestrator-claude-code-plugin",
   "private": true,
   "dependencies": {
-    "@autodidacticon/orchestrator": "0.1.0"
+    "@autodidacticon/orchestrator": "0.3.0"
   }
 }

package/hosts/claude-code/skills/import/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: import
-description: Import an epic or parent issue from Linear or Jira into the orchestrator's run graph for this repository. Use when the user wants to turn a tracker epic, parent issue, project milestone, or list of issues into an orchestrated run.
+description: Import an epic or parent issue from Linear, Jira, or GitHub Issues into the orchestrator's run graph for this repository. Use when the user wants to turn a tracker epic, parent issue, project milestone, GitHub milestone, or list of issues into an orchestrated run.
 ---
 
 # Import an epic into the run graph
@@ -11,13 +11,21 @@ session and hand over normalized records.
 
 ## 1. Check the prerequisites
 
-- A Linear or Atlassian (Jira) MCP server must be connected. Look for tools whose names start
-  with `mcp__plugin_linear`, `mcp__linear`, `mcp__plugin_atlassian`, or `mcp__atlassian`. If
-  none exist, stop and tell the user: "No Linear or Jira connector is available in this
-  session; connect one (for example the Linear or Atlassian plugin) and run the import again."
-  Do not call `import_issues`.
+- A tracker connector must be available: a Linear or Atlassian (Jira) MCP server (tools whose
+  names start with `mcp__plugin_linear`, `mcp__linear`, `mcp__plugin_atlassian`, or
+  `mcp__atlassian`), a GitHub MCP server, or the `gh` CLI for GitHub Issues: run
+  `gh auth status` with Bash and treat success as the connector. If none is available, stop
+  and tell the user: "No tracker connector is available in this session; connect the Linear or
+  Atlassian plugin, a GitHub MCP server, or log in with `gh auth login`, and run the import
+  again." Do not call `import_issues`. When more than one is available, use the one the
+  user's root belongs to (a GitHub URL or `#123` means GitHub).
 - The orchestrator daemon must be running for this repository. Call the `start` tool; it is
-  idempotent and returns the run directory and graph path.
+  idempotent and returns the run directory, the graph path, and the resolved configuration.
+  Report the toolchain in one line: the check command and the integration branch with the
+  source of each (for example "detected: npm test on main"). When `needsConfig` names
+  `checkCommand`, follow the run skill's section 1b (read `CLAUDE.md`, the README, and the
+  root manifests; set it with `configure` when it is stated unambiguously, otherwise ask) before
+  continuing, so that the first submission is not held.
 
 ## 2. Fetch the root and everything it references
 
@@ -32,6 +40,27 @@ For **Jira**: fetch the root (an epic or any parent); fetch the issues whose par
 (or whose epic link is the root); for every child, read the issue links of type "is blocked
 by"; fetch each blocker outside the child set.
 
+For **GitHub**: the root is an issue (`#123`, `owner/repo#123`, or its URL) or a milestone
+(by name or URL). Query the GraphQL API through `gh api graphql` (or the GitHub MCP server).
+For an issue root fetch its `subIssues` as the children; for a milestone root fetch the issues
+in the milestone. For every child read `blockedBy` and collect the blockers; fetch each blocker
+outside the child set for its state. One query shape covers every issue:
+
+```
+query($owner:String!, $repo:String!, $n:Int!) { repository(owner:$owner, name:$repo) { issue(number:$n) {
+  number url title body state stateReason
+  labels(first:50) { nodes { name } }
+  milestone { number url title state }
+  parent { number url repository { nameWithOwner } }
+  subIssues(first:100) { nodes { number url title body state stateReason labels(first:50) { nodes { name } } repository { nameWithOwner } } }
+  blockedBy(first:50) { nodes { number url state stateReason repository { nameWithOwner } } }
+} } }
+```
+
+If the root has no sub-issues (or the milestone no issues), say so and stop: this skill does
+not parse task lists or "blocked by" text in issue bodies, and an empty epic is not imported.
+Repositories on plans without sub-issues or dependencies need the parent to be a milestone.
+
 ## 3. Build normalized records
 
 One record per issue you fetched, including the root:
@@ -41,7 +70,9 @@ One record per issue you fetched, including the root:
 ```
 
 - `id` is the tracker key (`ENG-123`, `PROJ-45`).
-- `state` is one of `open`, `inProgress`, `done`, `cancelled`. Map tracker states: anything
+- `state` is one of `open`, `inProgress`, `done`, `cancelled`. A `done` or `cancelled` child
+  becomes an external node that already counts as satisfied: it neither holds the milestone
+  nor blocks a dependant. Map tracker states: anything
   unstarted or backlog is `open`; started or in review is `inProgress`; completed is `done`;
   cancelled, duplicate, or won't-do is `cancelled`.
 - `parent` is the root id for each child.
@@ -55,7 +86,20 @@ One record per issue you fetched, including the root:
   break ties between ready tasks with equally long chains behind them. Linear: send the
   issue's `priority` field as is (its 0, meaning none, is dropped). Jira: send the position
   of the issue's priority in the site's priority list, counted from the most urgent as 1.
-  Omit it when the tracker has no priority.
+  GitHub: the number from a label `P0`..`P4` or `priority:<n>`, otherwise omit it; the label
+  stays in `labels`. Omit it when the tracker has no priority.
+- GitHub records differ in three ways. `id` is `GH-<number>` for an issue in the tracker's
+  repository, `GH-<owner>-<repo>-<number>` for an issue in another repository, and `GH-M<number>`
+  for a milestone root (GitHub's own key, `owner/repo#123`, is not usable: ids travel through
+  URL paths and git branch names); always set `url`, which is what the run skill acts on.
+  `state` is `open` for an open issue, `inProgress` for an open issue carrying the in-progress
+  label when one is configured, `done` for a closed issue whose `stateReason` is `COMPLETED`,
+  and `cancelled` for `NOT_PLANNED` or `DUPLICATE`. `parent` is the root's id for every child.
+- `labels` are passed through. Two label shapes choose the worker for the task: `model:<name>`
+  (for example `model:claude-sonnet-5-5`) and `effort:<level>` (`low`, `medium`, `high`,
+  `xhigh`, or `max`). Without them a task runs with the run's defaults (`claude-opus-5-5` at
+  `medium`, changeable with `configure`). A label whose value is not recognised is left as a
+  plain label and reported under `ignoredLabels`.
 
 ## 4. Import
 
@@ -65,14 +109,22 @@ taken over; set `task` to orchestrate them), `gated` (the root milestone waits f
 review, default true).
 
 Always pass `tracker`: `{ kind: "linear" }` when you fetched through the Linear tools,
-`{ kind: "atlassian" }` through the Atlassian tools, plus `workspace` naming the Linear
-workspace (its URL key) or the Jira site when the connector reports it. The daemon records it
-and from then on mirrors the run back to the tracker through the `run` skill: issues move to
-in progress, done, or cancelled, and comments appear where a human is needed.
+`{ kind: "atlassian" }` through the Atlassian tools, `{ kind: "github" }` through `gh` or a
+GitHub MCP server, plus `workspace` naming the Linear workspace (its URL key), the Jira site,
+or the GitHub repository as `owner/repo`. For GitHub also pass `inProgressLabel` when the
+repository uses a label for work in progress: GitHub has no started state, so this label is
+both how an open issue reads as in progress at import and what the run skill adds when a task
+starts. When no label was given and the repository has one that looks like it (`in-progress`,
+`in progress`, `status: in progress`), offer it to the user before importing; without one, in
+progress is simply not mirrored. The daemon records the tracker and from then on mirrors the
+run back through the `run` skill: issues move to in progress, done, or cancelled, and comments
+appear where a human is needed.
 
 ## 5. Report
 
-Show the user the summary: counts of tasks, external nodes, and milestones; the tasks missing
+Show the user the summary: counts of tasks, external nodes, and milestones; any
+`ignoredLabels` (say which issue's `model:` or `effort:` label was not recognised and that the
+task will use the run default); the tasks missing
 acceptance criteria, which will block at ready until someone adds them; any unknown external
 blockers; and whether the graph was accepted by the daemon. If the import was rejected as an
 incompatible reload, show the reasons and suggest cancelling the affected tasks first.

package/hosts/claude-code/skills/run/SKILL.md

@@ -11,13 +11,45 @@ never raw event lists.
 
 ## 1. Start
 
-Call `start`. It returns the run directory, graph path, URL, and the runner `mode` in force,
-and is safe to repeat. A run started from this plugin defaults to `pull`: the daemon prepares
-each launch and this session's own subagents do the work (section 1a), so the user sees every
-agent here. `spawn` (the daemon runs headless agents, for unattended runs) and `mixed` are
-explicit choices: `start` with `mode`, or `runner.mode` in `orchestrator.yaml`, which wins.
-Tell the user who is executing the work. Then call `status`. If no graph is loaded, say so
-and suggest the `import` skill.
+Call `start`. It returns the run directory, graph path, URL, the runner `mode` in force, and
+the resolved configuration: `config` (every key as `{ value, source }`, the source being
+`argument`, `file`, `pinned`, `detected`, `default`, or `unresolved`), `toolchain` (what
+detection found in the repository root), and `needsConfig` (keys no layer supplied). It is safe
+to repeat. A run started from this plugin defaults to `pull`: the daemon prepares each launch
+and this session's own subagents do the work (section 1a), so the user sees every agent here.
+`spawn` (the daemon runs headless agents, for unattended runs) and `mixed` are explicit
+choices: `start` with `mode`, or `runner.mode` in `orchestrator.yaml`, which wins.
+
+Tell the user who is executing the work, and report the toolchain in one line: the check
+command, the integration branch, and the worker model and effort (`config.model` and
+`config.effort`, default `claude-opus-5-5` at `medium`) with the source of each and, when the
+daemon spawns agents (`spawn`, or `mixed` after the claim window), the toolchains whose
+commands agents may run, for example
+"detected: npm test on main; workers claude-opus-5-5 at medium (default); agents may run npm and node".
+When this session's subagents work the launches (`pull`), omit the allow-list part: workers
+run under this session's own permissions.
+When `config.model.applied` is false (a `runnerCommand` without the `{model}` slot), omit the
+model part. A task can choose its own model or effort: `model` and `effort` in its payload, or
+`model:<name>` and `effort:<level>` labels on its issue; `status.liveLaunches` shows what each
+launch runs with. If `needsConfig` is not empty, resolve it now (section 1b). Then call
+`status`. If no graph is loaded, say so and suggest the `import` skill.
+
+## 1b. Resolve what detection could not
+
+When `needsConfig` names `checkCommand`, in the `start` result or in a later `wait` digest,
+submitted work is held under `verifying` until a check command is set: no attempt is spent and
+the sealed work is kept, but nothing is published. Never leave it unresolved while a task is
+`submitted` without having asked the user. Look for the test command in `CLAUDE.md`, the
+README, and the manifests in the repository root (`package.json` scripts, `Makefile` targets,
+and their counterparts). When one is stated unambiguously, call `configure` with `checkCommand`
+and tell the user the command and where you found it ("set checkCommand to `make check` from
+CLAUDE.md"). Otherwise propose your best reading, or say you found none, and call `configure`
+only with what the user confirms. `configure` also takes `capacity`, `allowedTools` (rules
+appended to the derived list for spawned agents, such as `Bash(docker:*)`), `runnerCommand`,
+and `model` and `effort` (the worker defaults for launches prepared from then on; effort is
+`low`, `medium`, `high`, `xhigh`, or `max`); a null clears an override so the value falls back
+to the file, detection, or the default. The integration branch is start-only: pass `integrationBranch` to `start` before
+the run holds any launch; a running daemon refuses it.
 
 ## 1a. Work the run with session subagents
 
@@ -26,13 +58,18 @@ with a worker count no larger than the run's `capacity` (from `status`), usually
 a run tag such as `work-1`:
 
 ```
-Workflow({ scriptPath: "<plugin dir>/workflows/work.js", args: { workers: 2, runTag: "work-1" } })
+Workflow({ scriptPath: "<plugin dir>/workflows/work.js", args: { workers: 2, runTag: "work-1", capacity: <status.config.capacity.value> } })
 ```
 
-Each worker loop claims a launch, runs a worker subagent on its brief in the prepared
-worktree, reports through the worker tools, and claims again until nothing is claimable. The
-workflow runs in the background; do not wait for its completion notice, monitor with `wait`
-(section 2). When the workflow has ended while launches are still claimable (a question was
+Each worker loop runs a cheap claimer agent (`claude-haiku-5-5` at `low` by default; pass
+`claimModel` and `claimEffort` only when the user asks otherwise) that claims a launch, polling
+up to three times with 90-second waits when nothing is claimable, then runs a worker subagent
+on its brief in the prepared worktree with the launch's model and effort, reports through the
+worker tools, and claims again until nothing is claimable. Agents are labelled `claim
+<workerId>` and `work <workerId> <taskId>`. Workers edit files in worktrees under the run
+directory, outside the repository, so an `acceptEdits` session prompts for each file there
+unless it was started with `--add-dir ~/.orchestrator`. The workflow runs in the background; do
+not wait for its completion notice, monitor with `wait` (section 2). When the workflow has ended while launches are still claimable (a question was
 answered after it stopped, or a task was retried), re-run it with the same run tag: a worker
 with the same id claims its launch back. In `spawn` mode run no workflow; the daemon's agents
 do the work and you only monitor.
@@ -47,7 +84,15 @@ answers (section 2b), then act on the digest:
 
 - **openQuestions** non-empty: for each task, call `status` or `logs` only if you need
   context, then present the question to the user verbatim and wait for their reply. Send the
-  reply with `answer`. Do not invent answers to questions that need a human decision.
+  reply with `answer`. Do not invent answers to questions that need a human decision. When the
+  question's kind is `needsAccess` and it names a command (from `status`, under the task's
+  blocked or waiting reason), offer three things: adding a rule through `configure`
+  (`allowedTools: ["Bash(<command>:*)"]`) so launches spawned afterwards can run it, saying
+  that the live agent cannot gain the rule; running the command yourself on the agent's behalf
+  in its worktree and sending the result with `answer`, which is what unblocks the live agent
+  now; or answering with an alternative. Do what the user picks.
+- **needsConfig** names `checkCommand`: submitted tasks are held under `verifying` until a
+  check command is set. Follow section 1b now; do not call the run slow or stalled.
 - **awaitingReview** non-empty: invoke the `review` skill for each milestone.
 - **finished** true: report the final state (done tasks, milestones) and stop.
 - **stalled** true: report `stallRoots` with their reasons. Offer the options that apply:
@@ -65,7 +110,10 @@ answers (section 2b), then act on the digest:
   user's decision. On acceptance in a run imported from a tracker, first create the issue
   with this session's tracker tools: a child of the epic, blocked by the proposing task's
   issue, with the acceptance criteria under the configured heading in its description; then
-  call `accept_proposal` with the new issue's key as `nodeId`. In a file-based run call
+  call `accept_proposal` with the new issue's key as `nodeId`. GitHub: `gh issue create
+  --repo <owner/repo> --parent <root url> --title ... --body-file -` creates the sub-issue;
+  add the dependency with the GraphQL mutation `addBlockedBy(input: { issueId, blockingIssueId })`
+  (node ids from `gh api graphql`); the `nodeId` is `GH-<new number>`. In a file-based run call
   `accept_proposal` without `nodeId` and report the new node id. On rejection call
   `reject_proposal` with the user's note. Never accept a proposal the user has not approved.
 - **pausedReason** is `costBudget`: the run cost reached its ceiling. Report `cost.runUsd`
@@ -92,12 +140,25 @@ tracker tools in this session, acknowledging each one before the next:
   type `started` for `inProgress`, `completed` for `done`, `canceled` for `cancelled`. Jira:
   transition to a status in category In Progress or Done; for `cancelled`, a canceled-type
   status when the workflow has one. When the tracker has no canceled-type state, leave the
-  status, post a comment saying the task was cancelled, and acknowledge. On success call
-  `ack { id, result: { stateId } }`.
-- `comment`: list the issue's recent comments first. If one already contains the effect's
-  `marker`, call `ack { id, result: { commentId } }` with that comment's id and do not post
-  again (a previous session posted it and crashed before acknowledging). Otherwise post
-  `body`, a blank line, and the `marker` as the last line, then `ack { id, result: { commentId } }`.
+  status, post a comment saying the task was cancelled, and acknowledge. GitHub (act on the
+  effect's `url` with `gh`, never on the `GH-` id):
+  `done`: `gh issue close <url> --reason completed`;
+  `cancelled`: `gh issue close <url> --reason "not planned"`;
+  both followed by `gh issue edit <url> --remove-label <policy.tracker.inProgressLabel>` when
+  the policy has a label (a no-op when the issue does not carry it);
+  `inProgress`: `gh issue reopen <url>` when the issue is closed, then
+  `gh issue edit <url> --add-label <policy.tracker.inProgressLabel>`; when the policy has no
+  `inProgressLabel`, call `ack { id, result: { skipped: true } }` and change nothing.
+  A milestone root (`GH-M<n>`, the effect's `url` is a milestone): `done` closes the milestone
+  with `gh api`; acknowledge `inProgress` as skipped. On success call
+  `ack { id, result: { stateId } }` (for GitHub, `{ state }`).
+- `comment`: list the issue's recent comments first (GitHub: `gh issue view <url> --comments`
+  or the GraphQL `comments` connection). If one already contains the effect's `marker`, call
+  `ack { id, result: { commentId } }` with that comment's id and do not post again (a previous
+  session posted it and crashed before acknowledging). Otherwise post `body`, a blank line,
+  and the `marker` as the last line (GitHub: `gh issue comment <url> --body-file -`), then
+  `ack { id, result: { commentId } }`. A GitHub milestone root takes no comments: acknowledge
+  the effect as skipped.
 - On a tracker error: `ack { id, error: "<message>" }`, then skip the remaining effects for
   that issue in this drain; they come back next time. The daemon retries a rejected effect
   up to its cap and then lists it in `trackerErrors`; when the digest shows `trackerErrors`,
@@ -109,7 +170,8 @@ conversation.
 ### 2b. Relay answers from the tracker
 
 When `policy.answersFromComments` is true and the digest lists `openQuestions`: for each
-task, list its issue's comments; ignore any containing "— orchestrator run"; take the first
+task, list its issue's comments (GitHub: `gh issue view <url> --comments`); ignore any
+containing "— orchestrator run"; take the first
 human comment posted after the latest marked comment that you have not relayed before; send
 it with `answer`; remember that comment's id so you never relay it twice. If the daemon
 answers 409, the task is no longer waiting or blocked (someone answered first): tell the

package/hosts/claude-code/skills/work/SKILL.md

@@ -14,7 +14,15 @@ the workflow hands back: questions, reviews, and the end.
 ## 1. Prerequisites
 
 - A graph must be loaded: call `start` and then `status`; if no graph is loaded, use the
-  `import` skill first.
+  `import` skill first. `start` also returns the resolved configuration: report the check
+  command, the integration branch, and the worker model and effort (`config.model`,
+  `config.effort`; default `claude-opus-5-5` at `medium`, changeable with `configure`, and
+  overridable per task by `model`/`effort` in its payload or `model:`/`effort:` labels) with
+  their sources in one line, for example "detected: npm test on main; workers claude-opus-5-5
+  at medium (default)", and when `needsConfig`
+  names `checkCommand`, follow the run skill's section 1b (find the test command in
+  `CLAUDE.md`, the README, or the root manifests and set it with `configure`, or ask the user)
+  before running workers, since submitted work is held until it is set.
 - `start` reports the mode in force. A plugin-started run is already `pull`. To work a run in
   `spawn` mode, call `start` with `mode: "pull"` (workers only) or `mode: "mixed"` (the
   daemon spawns whatever nobody claims within its claim window); this switches a daemon
@@ -23,15 +31,26 @@ the workflow hands back: questions, reviews, and the end.
 ## 2. Run the workflow
 
 Pick a worker count no larger than the run's `capacity` (from `status`), usually 2 to 4, and a
-run tag such as `work-1`. Run the plugin's workflow `work.js` with the Workflow tool:
+run tag such as `work-1`. Run the plugin's workflow `work.js` with the Workflow tool, passing
+the capacity so the workflow clamps the count itself:
 
 ```
-Workflow({ scriptPath: "<plugin dir>/workflows/work.js", args: { workers: 2, runTag: "work-1" } })
+Workflow({ scriptPath: "<plugin dir>/workflows/work.js", args: { workers: 2, runTag: "work-1", capacity: <status.config.capacity.value> } })
 ```
 
-Each worker loop claims a launch with the worker id `<runTag>-<n>`, runs a worker agent on
-the brief, and claims again until nothing is claimable. The workflow runs in the background
-and returns short outcomes per launch; never paste briefs or logs into the conversation.
+Each worker loop runs a claimer agent that claims a launch with the worker id `<runTag>-<n>`;
+when nothing is claimable it waits up to 90 seconds, reads `status`, and tries again, up to
+three polls before returning. The claimer makes no decisions, so it runs on a fixed cheap
+model: `claude-haiku-5-5` at `low` effort. Pass `claimModel` and `claimEffort` in `args` only
+when the user asks for a different claimer. On a claim the loop runs a worker agent on the
+brief with the model and effort the claim carries (the task's choice, else the run default),
+then claims again until nothing is claimable. In the agent view the claimer is labelled
+`claim <workerId>` and the worker `work <workerId> <taskId>`, so the two agents of a loop
+share the worker id. The workflow runs in the background and returns short outcomes per
+launch; never paste briefs or logs into the conversation. Workers edit files in worktrees under
+the run directory (`~/.orchestrator/runs/<id>/worktrees`, outside the repository), so a session
+in `acceptEdits` mode prompts for each file there unless it was started with
+`--add-dir ~/.orchestrator`; tell the user when the first such prompt appears.
 
 ## 3. Monitor while it runs
 

package/hosts/claude-code/workflows/work.js

@@ -1,11 +1,21 @@
 export const meta = {
   name: 'orchestrator-work',
-  description: 'Fan out N worker loops that claim prepared launches from the orchestrator daemon, do the work in the prepared worktree, and report; stop when nothing is claimable.',
-  whenToUse: 'When the work skill runs a pull-mode or mixed-mode orchestrator run inside this session.',
+  description: 'Fan out N worker loops that claim prepared launches from the orchestrator daemon (a cheap claimer polls; the worker runs with the launch\'s model and effort), do the work in the prepared worktree, and report; stop when nothing is claimable.',
+  whenToUse: 'When the work skill runs a pull-mode or mixed-mode orchestrator run inside this session. Args: workers, runTag, capacity (clamps workers), claimModel and claimEffort (the claimer; default claude-haiku-5-5 at low).',
   phases: [{ title: 'Claim' }, { title: 'Work' }],
 }
 
-const workers = Math.max(1, Math.min(16, Number((args && args.workers) || 2)))
+// The claimer makes no decision (claim, wait, status, a spelled-out stop rule), so it runs on a fixed cheap model unless the user asks otherwise. See specs/host-integration "Work skill and workflow".
+const EFFORTS = ['low', 'medium', 'high', 'xhigh', 'max']
+const claimModel = String((args && args.claimModel) || 'claude-haiku-5-5')
+const claimEffort = EFFORTS.includes(args && args.claimEffort) ? args.claimEffort : 'low'
+const CLAIM_POLLS = 3
+const CLAIM_WAIT_MS = 90000
+const requested = Math.max(1, Math.min(16, Number((args && args.workers) || 2)))
+const capacity = Number(args && args.capacity)
+// A loop beyond the daemon's capacity would only poll for a slot that is never filled.
+const workers = Number.isInteger(capacity) && capacity > 0 && capacity < requested ? capacity : requested
+if (workers !== requested) log(`workers clamped from ${requested} to the run's capacity ${workers}`)
 const runTag = String((args && args.runTag) || 'work')
 const held = {}
 const outcomes = []
@@ -24,6 +34,8 @@ const CLAIM_SCHEMA = {
     briefMarkdown: { type: 'string' },
     pendingSeq: { type: 'number' },
     pendingAnswer: { type: 'string' },
+    model: { type: 'string' },
+    effort: { type: 'string', enum: ['low', 'medium', 'high', 'xhigh', 'max'] },
     finished: { type: 'boolean' },
     stalled: { type: 'boolean' },
     openQuestions: { type: 'array', items: { type: 'string' } },
@@ -45,11 +57,12 @@ const OUTCOME_SCHEMA = {
 
 function claimPrompt(workerId, heldCount) {
   return [
-    `You are the claimer for orchestrator worker "${workerId}". Use the orchestrator operator MCP tools (names end in claim, wait, status; load them with ToolSearch if needed).`,
+    `You are the claimer for orchestrator worker "${workerId}". Use the orchestrator operator MCP tools (names end in claim, wait, status; load them with ToolSearch if needed). You make no decisions: follow these steps exactly.`,
     `1. Call claim with workerId "${workerId}" and access "local".`,
-    '2. If it returns a launch (status 200): read the markdown brief at briefPath and return { claimed: true, launchId, taskId, token, worktree, briefPath, briefMarkdown: <the full brief file>, pendingSeq, pendingAnswer } (pending fields only when the response carries pending).',
-    '3. If it returns 404 (nothing claimable or paused): call wait with until "any" and timeoutMs 30000, then call status. Return { claimed: false, stop, finished, stalled, openQuestions, awaitingReview, claimable } from status.',
+    '2. If it returns a launch (status 200): read the markdown brief at briefPath and return { claimed: true, launchId, taskId, token, worktree, briefPath, briefMarkdown: <the full brief file>, model, effort, pendingSeq, pendingAnswer } (model and effort exactly as the response gives them; pending fields only when the response carries pending).',
+    `3. If it returns 404 (nothing claimable or paused): call wait with until "any" and timeoutMs ${CLAIM_WAIT_MS}, then call status, and compute stop:`,
     `   stop is true when finished is true, or stalled is true, or (claimable is 0 and ${heldCount} launches are held by other loops is false and (openQuestions is non-empty or awaitingReview is non-empty)). Otherwise stop is false.`,
+    `   If stop is false and you have done fewer than ${CLAIM_POLLS} polls (a poll is one claim followed by one wait and one status), go back to step 1. Otherwise return { claimed: false, stop, finished, stalled, openQuestions, awaitingReview, claimable } from the last status.`,
     '4. On any other error return { claimed: false, stop: true }.',
     'Return only the structured output; do not do any task work.',
   ].join('\n')
@@ -80,7 +93,7 @@ async function loop(i) {
   const workerId = `${runTag}-${i + 1}`
   for (let cycle = 0; cycle < 200; cycle++) {
     const heldCount = Object.keys(held).filter((k) => k !== workerId).length
-    const c = await agent(claimPrompt(workerId, heldCount), { label: `claim:${workerId}`, phase: 'Claim', schema: CLAIM_SCHEMA, effort: 'low' })
+    const c = await agent(claimPrompt(workerId, heldCount), { label: `claim ${workerId}`, phase: 'Claim', schema: CLAIM_SCHEMA, model: claimModel, effort: claimEffort })
     if (!c) break
     if (!c.claimed) {
       lastDigest = { finished: c.finished, stalled: c.stalled, openQuestions: c.openQuestions || [], awaitingReview: c.awaitingReview || [], claimable: c.claimable || 0 }
@@ -89,7 +102,8 @@ async function loop(i) {
     }
     held[workerId] = c.taskId
     log(`${workerId}: working ${c.taskId}`)
-    const r = await agent(workerPrompt(c), { label: `work:${c.taskId}`, phase: 'Work', schema: OUTCOME_SCHEMA })
+    // The launch's model and effort were fixed when the daemon prepared it; the worker agent runs with them. See specs/model-selection.
+    const r = await agent(workerPrompt(c), { label: `work ${workerId} ${c.taskId}`, phase: 'Work', schema: OUTCOME_SCHEMA, ...(c.model ? { model: c.model } : {}), ...(c.effort ? { effort: c.effort } : {}) })
     delete held[workerId]
     const outcome = r || { taskId: c.taskId, outcome: 'failed', summary: 'worker agent returned nothing' }
     outcomes.push({ worker: workerId, ...outcome })
@@ -98,4 +112,4 @@ async function loop(i) {
 }
 
 await parallel(Array.from({ length: workers }, (_, i) => () => loop(i)))
-return { runTag, workers, outcomes, digest: lastDigest }
+return { runTag, workers, claimModel, claimEffort, outcomes, digest: lastDigest }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autodidacticon/orchestrator",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "Parallel coding-agent orchestrator over a task DAG",
   "type": "module",
   "engines": {