@autodidacticon/orchestrator 0.1.0 → 0.2.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.2.0"
   }
 }

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

@@ -17,7 +17,12 @@ session and hand over normalized records.
   session; connect one (for example the Linear or Atlassian plugin) and run the import again."
   Do not call `import_issues`.
 - 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
 
@@ -56,6 +61,11 @@ One record per issue you fetched, including the root:
   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.
+- `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
 
@@ -72,7 +82,9 @@ 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
 
@@ -47,7 +79,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:

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
@@ -30,7 +38,8 @@ Workflow({ scriptPath: "<plugin dir>/workflows/work.js", args: { workers: 2, run
 ```
 
 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
+the brief with the model and effort the claim carries (the task's choice, else the run
+default), 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.
 
 ## 3. Monitor while it runs

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

@@ -24,6 +24,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' } },
@@ -47,7 +49,7 @@ 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).`,
     `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).',
+    '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 30000, then call status. Return { claimed: false, stop, finished, stalled, openQuestions, awaitingReview, claimable } from status.',
     `   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.`,
     '4. On any other error return { claimed: false, stop: true }.',
@@ -89,7 +91,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:${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 })

package/package.json

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