@hecer/yoke 1.10.0 → 1.11.0

package/dist/loop/decision.js

@@ -60,9 +60,9 @@ export const DecisionResumeSchema = z.object({
     answered: z.boolean().optional(),
     /** Absent preserves the default unlimited run across a critical-decision resume. */
     maxIterations: z.number().int().positive().optional(),
-    agent: z.enum(['claude', 'codex', 'gemini']).optional(),
+    agent: z.enum(['claude', 'codex', 'gemini', 'qwen']).optional(),
     isolate: z.boolean().optional(),
-    reviewer: z.enum(['claude', 'codex', 'gemini']).optional(),
+    reviewer: z.enum(['claude', 'codex', 'gemini', 'qwen']).optional(),
     review: z.boolean().optional(),
     allowSelfReview: z.boolean().optional(),
     timeoutMinutes: z.number().nonnegative().optional(),

package/dist/loop/prd.js

@@ -42,7 +42,7 @@ export const StorySchema = z.object({
     area: z.string().min(1).optional(),
     /** Advisory relative file/directory scopes; not a filesystem permission boundary. */
     writes: z.array(z.string().min(1).max(500).refine(validWriteScope, 'Write scopes must be relative non-glob paths without traversal')).max(100).optional(),
-    agent: z.enum(['claude', 'codex', 'gemini']).optional(),
+    agent: z.enum(['claude', 'codex', 'gemini', 'qwen']).optional(),
     /** Inbox request that created this story. Used for idempotent append-only intake. */
     sourceChange: z.string().min(1).optional(),
     quality: StoryQualityDeclarationSchema.optional(),

package/dist/prd/command.js

@@ -10,23 +10,23 @@ import { acquireLock, releaseLock } from '../loop/lock.js';
 import { agentInvocation, buildWatchdogInvocation, runAgent, isAgentAvailable, } from '../loop/runner.js';
 import { resolveIdleMs } from '../loop/run-command.js';
 import { detectHostAgent, resolveRunnerAgent } from '../agents/host.js';
-export const PRD_TEMPLATE = `# Yoke PRD — the loop picks the lowest-priority open story each iteration.
-# Story format (see canon/loop/prd.schema.md):
-# - id: STORY-1
-#   title: scaffold the project with a runnable test suite
-#   priority: 1
-#   needs: []             # optional story IDs that must pass first
-#   area: foundation      # optional collision domain for parallel runs
-#   agent: codex          # optional claude|codex|gemini affinity
-#   acceptance:
-#     - id: suite-runs
-#       text: "the project test suite can run"
-#       verify: ["npm run test:suite-runs"]
-#     - id: scaffold-starts
-#       text: "the scaffolded application starts"
-#       verify: ["npm run test:scaffold-starts"]
-#   passes: false
-[]
+export const PRD_TEMPLATE = `# Yoke PRD — the loop picks the lowest-priority open story each iteration.
+# Story format (see canon/loop/prd.schema.md):
+# - id: STORY-1
+#   title: scaffold the project with a runnable test suite
+#   priority: 1
+#   needs: []             # optional story IDs that must pass first
+#   area: foundation      # optional collision domain for parallel runs
+#   agent: codex          # optional claude|codex|gemini affinity
+#   acceptance:
+#     - id: suite-runs
+#       text: "the project test suite can run"
+#       verify: ["npm run test:suite-runs"]
+#     - id: scaffold-starts
+#       text: "the scaffolded application starts"
+#       verify: ["npm run test:scaffold-starts"]
+#   passes: false
+[]
 `;
 export const MAX_PLANNING_BRIEF_CHARS = 20_000;
 export const MAX_PLANNING_BRIEF_BYTES = MAX_PLANNING_BRIEF_CHARS * 4;

package/dist/quality/types.js

@@ -1,6 +1,6 @@
 import { z } from 'zod';
 const QualityPolicySchema = z.enum(['blocking', 'advisory']);
-const QualityAgentSchema = z.enum(['claude', 'codex', 'gemini']);
+const QualityAgentSchema = z.enum(['claude', 'codex', 'gemini', 'qwen']);
 const RelativePathSchema = z.string().min(1).refine(value => !/^(?:[A-Za-z]:[\\/]|[\\/])/.test(value) && !value.split(/[\\/]+/).includes('..'), 'path must stay within the project');
 const QualityReferenceSchema = z.object({
     name: z.string().min(1),

package/dist/retrofit/plan.js

@@ -1,6 +1,7 @@
 import { planClaude } from './planners/claude.js';
 import { planCodex } from './planners/codex.js';
 import { planGemini } from './planners/gemini.js';
+import { planQwen } from './planners/qwen.js';
 import { baseContextActions } from './context-actions.js';
 export function planClaudeRetrofit(canonDir, targetDir) {
     return planClaude(canonDir, targetDir);
@@ -9,6 +10,7 @@ export const PLANNERS = {
     claude: (c, t, cg) => planClaude(c, t, undefined, cg),
     codex: planCodex,
     gemini: planGemini,
+    qwen: planQwen,
 };
 export function planRetrofit(canonDir, targetDir, agents, codeGraph = 'graphify') {
     const seen = new Set();

package/dist/retrofit/planners/claude.js

@@ -6,21 +6,21 @@ import { hasWsl } from '../wsl.js';
 import { detectGstack } from '../gstack.js';
 import { PRESERVE_SCAFFOLD } from '../preserve.js';
 import { skillPackageActions } from '../skill-actions.js';
-const GSTACK_COMPOSE = `## Composed tools (gstack detected)
-
-This project also has [gstack](https://github.com/garrytan/gstack) installed. For capabilities Yoke does not ship, prefer gstack's skills:
-
-- Live-browser QA → \`/qa\`
-- Security audit → \`/cso\`
-- Ship / deploy → \`/ship\`, \`/land-and-deploy\`
+const GSTACK_COMPOSE = `## Composed tools (gstack detected)
+
+This project also has [gstack](https://github.com/garrytan/gstack) installed. For capabilities Yoke does not ship, prefer gstack's skills:
+
+- Live-browser QA → \`/qa\`
+- Security audit → \`/cso\`
+- Ship / deploy → \`/ship\`, \`/land-and-deploy\`
 `;
-const claudeMd = (rtkNote, composeNote) => `# Project Instructions
-
-This project uses the Yoke harness. Baseline instructions:
-
-@AGENTS.md
-${rtkNote ? `\n${rtkNote}\n` : ''}${composeNote ? `\n${composeNote}\n` : ''}
-${PRESERVE_SCAFFOLD}
+const claudeMd = (rtkNote, composeNote) => `# Project Instructions
+
+This project uses the Yoke harness. Baseline instructions:
+
+@AGENTS.md
+${rtkNote ? `\n${rtkNote}\n` : ''}${composeNote ? `\n${composeNote}\n` : ''}
+${PRESERVE_SCAFFOLD}
 `;
 export function planClaude(canonDir, targetDir, wslAvailable = hasWsl(), codeGraph = 'graphify', gstackDetected = detectGstack(targetDir)) {
     const manifest = loadManifest(join(canonDir, 'manifest.yaml'));

package/dist/retrofit/planners/qwen.js

@@ -0,0 +1,73 @@
+import { readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { loadManifest } from '../../canon/manifest.js';
+import { parseFrontmatter } from '../../canon/frontmatter.js';
+import { mcpServers, rtkInstruction } from '../tools.js';
+import { PRESERVE_SCAFFOLD } from '../preserve.js';
+import { skillPackageActions } from '../skill-actions.js';
+function tomlString(s) {
+    return '"""\n' + s.replace(/\\/g, '\\\\').replace(/"""/g, '\\"\\"\\"') + '\n"""';
+}
+export function planQwen(canonDir, _targetDir, codeGraph = 'graphify') {
+    const manifest = loadManifest(join(canonDir, 'manifest.yaml'));
+    const actions = [];
+    // QWEN.md: baseline + instruction for commands outside the rewrite hook.
+    const baseline = readFileSync(join(canonDir, 'AGENTS.md'), 'utf8');
+    const autoSkillIndex = manifest.skills
+        .filter(skill => skill.invocation === 'auto')
+        .map(skill => {
+        const source = readFileSync(join(canonDir, skill.path, 'SKILL.md'), 'utf8');
+        const description = String(parseFrontmatter(source)?.description ?? skill.id).replace(/\s+/gu, ' ').trim();
+        return `- \`/${skill.id}\` — ${description}`;
+    })
+        .join('\n');
+    actions.push({
+        kind: 'write',
+        target: 'QWEN.md',
+        content: `${baseline}\n${rtkInstruction()}\n\n## Yoke automatic skills\n\nUse the matching command when its capability is relevant:\n\n${autoSkillIndex}\n\n${PRESERVE_SCAFFOLD}\n`,
+        reason: 'baseline + rtk instruction',
+    });
+    // One TOML slash command per skill.
+    for (const skill of manifest.skills) {
+        const body = readFileSync(join(canonDir, skill.path, 'SKILL.md'), 'utf8');
+        const fm = parseFrontmatter(body) ?? {};
+        // Collapse any newlines so the single-line TOML `description = "..."` stays valid
+        // even for ported skills whose frontmatter description spans multiple lines.
+        const description = String(fm.description ?? skill.id).replace(/\s*\r?\n\s*/g, ' ').trim();
+        const skillBody = body.replace(/^---\r?\n[\s\S]*?\r?\n---\r?\n?/, '').trim();
+        const prompt = `You are using the "${skill.id}" skill.\n\n${skillBody}\n\nFollow it for the current task.`;
+        actions.push({
+            kind: 'write',
+            target: `.qwen/commands/${skill.id}.toml`,
+            content: `description = "${description.replace(/\\/g, '\\\\').replace(/"/g, '\\"')}"\nprompt = ${tomlString(prompt)}\n`,
+            reason: `qwen command: ${skill.id}`,
+        });
+        actions.push(...skillPackageActions(canonDir, skill, 'qwen'));
+    }
+    actions.push({
+        kind: 'write',
+        target: '.qwen/hooks/qwen-rtk-hook.mjs',
+        content: readFileSync(join(canonDir, 'tools/gemini-rtk-hook.mjs'), 'utf8'),
+        reason: 'portable RTK BeforeTool argument adapter',
+    });
+    // Merge to preserve user MCP servers, context and unrelated hooks.
+    actions.push({
+        kind: 'write',
+        target: '.qwen/settings.json',
+        merge: true,
+        content: JSON.stringify({
+            mcpServers: mcpServers(codeGraph),
+            context: { fileName: ['AGENTS.md', 'QWEN.md'] },
+            hooks: { BeforeTool: [{ matcher: '^run_shell_command$', hooks: [{ name: 'yoke-rtk', type: 'command', command: 'node .qwen/hooks/qwen-rtk-hook.mjs' }] }] },
+        }, null, 2) + '\n',
+        reason: 'MCP servers + AGENTS.md context',
+    });
+    // Also ship AGENTS.md so the context.fileName entry resolves.
+    actions.push({
+        kind: 'write',
+        target: 'AGENTS.md',
+        content: baseline,
+        reason: 'baseline instructions (shared)',
+    });
+    return actions;
+}

package/dist/retrofit/preserve.js

@@ -1,7 +1,7 @@
 export const PRESERVE_START = '<!-- yoke:preserve:start -->';
 export const PRESERVE_END = '<!-- yoke:preserve:end -->';
-export const PRESERVE_SCAFFOLD = `${PRESERVE_START}
-<!-- Project-specific instructions go here. Yoke keeps this block across retrofits. -->
+export const PRESERVE_SCAFFOLD = `${PRESERVE_START}
+<!-- Project-specific instructions go here. Yoke keeps this block across retrofits. -->
 ${PRESERVE_END}`;
 /**
  * Extract the inner content of every balanced preserve-marker pair, in order.

package/dist/retrofit/skill-actions.js

@@ -4,6 +4,7 @@ const roots = {
     claude: '.claude/skills',
     codex: '.agents/skills',
     gemini: '.gemini/skills',
+    qwen: '.qwen/skills',
 };
 function manualClaudeSkill(content, skill) {
     const source = content.toString('utf8');

package/dist/review/command.js

@@ -5,7 +5,7 @@ import { loadConfig } from '../retrofit/config.js';
 import { parseReviewVerdict } from './verdict.js';
 // Resolve to the first available agent, preferring a *second* model so the review
 // is genuinely cross-model. claude last => a Claude-only box degrades to self-review.
-const RESOLUTION_ORDER = ['codex', 'gemini', 'claude'];
+const RESOLUTION_ORDER = ['codex', 'gemini', 'qwen', 'claude'];
 export function runReview(targetDir, opts = {}) {
     const available = opts.isAvailable ?? isAgentAvailable;
     const implementer = opts.implementer ?? loadConfig(targetDir)?.agents[0] ?? 'claude';

package/dist/routing/capability.js

@@ -68,7 +68,7 @@ export function chooseCapability(input) {
     const worker = reliable[0];
     const blocked = !worker && (input.fallback === 'block' || input.maxTier !== undefined);
     const provider = worker?.agent ?? input.story.agent ?? input.parent;
-    const selection = worker ? { model: worker.model, reasoningEffort: worker.reasoningEffort, nativeMultiAgent: false, ...(provider !== 'gemini' && input.parentSelection?.bare !== undefined ? { bare: input.parentSelection.bare } : {}) }
+    const selection = worker ? { model: worker.model, reasoningEffort: worker.reasoningEffort, nativeMultiAgent: false, ...(provider !== 'gemini' && provider !== 'qwen' && input.parentSelection?.bare !== undefined ? { bare: input.parentSelection.bare } : {}) }
         : { ...(provider === input.parent ? input.parentSelection : {}), nativeMultiAgent: false };
     const reason = `${role}: ${tiers[level]}; ${input.assessment.reason}${failures.length ? `; ${failures.length} verified failure(s), ${failures.length === 1 ? 'one targeted repair' : 'escalated'}` : ''}${worker ? '' : '; no eligible profile, parent/provider fallback'}`;
     return { worker, provider, selection, reason: blocked ? `${role}: no eligible profile within routing limits; execution blocked` : reason, blocked, requiredTier: baseTier, selectedTier: tiers[level], failures: failures.length, exhausted, next: input.maxTier && level >= tiers.indexOf(input.maxTier) ? 'stop at configured tier limit' : level < 3 ? tiers[level + 1] : 'stop after bounded attempts' };

package/dist/routing/router.js

@@ -247,7 +247,7 @@ function routingSteps(options) {
             return blocked('Selected routing profile exceeds configured limits; execution blocked');
         const provider = worker?.agent ?? options.parent;
         const selection = worker
-            ? { model: worker.model, reasoningEffort: worker.reasoningEffort, nativeMultiAgent: false, ...(provider !== 'gemini' ? { bare: options.parentSelection?.bare } : {}) }
+            ? { model: worker.model, reasoningEffort: worker.reasoningEffort, nativeMultiAgent: false, ...(provider !== 'gemini' && provider !== 'qwen' ? { bare: options.parentSelection?.bare } : {}) }
             : { ...(options.parentSelection ?? {}), nativeMultiAgent: false };
         const workerStarted = now();
         const result = yield () => makeWorker(provider, selection)(ctx);

package/dist/setup/command.js

@@ -4,7 +4,7 @@ import { detectHostAgent } from '../agents/host.js';
 import { loadConfig, saveConfig } from '../retrofit/config.js';
 import { detectProject } from '../retrofit/detect.js';
 import { runRetrofit } from '../retrofit/command.js';
-const ALL_AGENTS = ['claude', 'codex', 'gemini'];
+const ALL_AGENTS = ['claude', 'codex', 'gemini', 'qwen'];
 export function defaultRoutingWorkers(agents) {
     const workers = {
         claude: [
@@ -25,6 +25,12 @@ export function defaultRoutingWorkers(agents) {
             { id: 'gemini-strong', agent: 'gemini', model: 'gemini-2.5-pro', tier: 'strong', costTier: 'medium', capabilities: ['debugging'] },
             { id: 'gemini-frontier', agent: 'gemini', model: 'gemini-2.5-pro', tier: 'frontier', costTier: 'high', capabilities: ['architecture'] },
         ],
+        qwen: [
+            { id: 'qwen-light', agent: 'qwen', model: 'qwen-turbo-latest', tier: 'light', costTier: 'low', capabilities: ['mechanical', 'tests'] },
+            { id: 'qwen-standard', agent: 'qwen', model: 'qwen3-coder-plus', tier: 'standard', costTier: 'medium', capabilities: ['implementation'] },
+            { id: 'qwen-strong', agent: 'qwen', model: 'qwen3-coder-plus', tier: 'strong', costTier: 'medium', capabilities: ['debugging'] },
+            { id: 'qwen-frontier', agent: 'qwen', model: 'qwen3-235b-a22b', tier: 'frontier', costTier: 'high', capabilities: ['architecture'] },
+        ],
     };
     return agents.flatMap(agent => workers[agent]);
 }
@@ -75,12 +81,12 @@ export async function runSetup(targetDir, opts = {}) {
         let decisionPolicy = defaultPolicy;
         let routing = defaultRouting;
         if (interactive && ask) {
-            agents = parseAgents(await ask(`Agents [${defaultAgents.join(',')}] (claude,codex,gemini|all): `), defaultAgents);
+            agents = parseAgents(await ask(`Agents [${defaultAgents.join(',')}] (claude,codex,gemini,qwen|all): `), defaultAgents);
             const graphAnswer = (await ask(`Code graph [${defaultGraph}] (graphify|serena): `)).trim().toLowerCase();
             if (graphAnswer === 'graphify' || graphAnswer === 'serena')
                 codeGraph = graphAnswer;
             loop = yes(await ask(`Enable autonomous loop? [${defaultLoop ? 'yes' : 'no'}]: `), defaultLoop);
-            const runnerAnswer = (await ask(`Default runner [${runner}] (claude|codex|gemini): `)).trim().toLowerCase();
+            const runnerAnswer = (await ask(`Default runner [${runner}] (claude|codex|gemini|qwen): `)).trim().toLowerCase();
             if (ALL_AGENTS.includes(runnerAnswer))
                 runner = runnerAnswer;
             const policyAnswer = (await ask(`Decision mode [${decisionPolicy}] (auto|critical): `)).trim().toLowerCase();

package/docs/CAPABILITY-ROUTING.md

@@ -1,17 +1,17 @@
-# Routing by task requirements
-
+# Routing by task requirements
+
 Capability routing is available in Yoke 1.9.0. Batch preparation, separate planning settings and routing limits described below are local, unreleased additions.
-
-New setups use `routing.strategy: capability`. Existing explicit strategies and profiles remain unchanged. To opt an existing project into capability routing with its current profiles:
-
-```sh
-yoke setup . --yes --routing --routing-strategy=capability
-```
-
-Give each existing worker a `tier: light|standard|strong|frontier`. Profiles without a tier remain usable with legacy strategies but are not candidates for capability selection. To explicitly replace worker profiles with the supplied provider presets, add `--routing-preset`. This replaces customized worker profiles; omit it to retain them.
-
-## Planning and selection
-
+
+New setups use `routing.strategy: capability`. Existing explicit strategies and profiles remain unchanged. To opt an existing project into capability routing with its current profiles:
+
+```sh
+yoke setup . --yes --routing --routing-strategy=capability
+```
+
+Give each existing worker a `tier: light|standard|strong|frontier`. Profiles without a tier remain usable with legacy strategies but are not candidates for capability selection. To explicitly replace worker profiles with the supplied provider presets, add `--routing-preset`. This replaces customized worker profiles; omit it to retain them.
+
+## Planning and selection
+
 The start provider/model remains the planning default. Optional `planning.agent`, `planning.model` and `planning.reasoningEffort` select a separate planner without changing the execution model. Draft and change-inbox planning request complete assessments in the same pass that creates the tasks. The inbox still performs its separate coverage review.
 
 New setups use `routing.assessmentPolicy: prepared` and `routing.fallback: block`. Before dispatch, each unfinished task must have 2–5 executable criteria and a current assessment. No per-task planning call runs in this mode. Existing configurations retain `on-demand` and `parent` unless explicitly changed; on-demand routing makes a read-only planning call for an unassessed task and caches its result.
@@ -41,42 +41,42 @@ routing:
 ```
 
 `maxTier` limits automatic execution and escalation, including routing-rule selections. If a task needs frontier while the ceiling is strong, it blocks; Yoke does not lower the required capability. Planning itself may still use Astra. Explicit quality-role model overrides retain precedence. Goal execution retains its own protected manifest and budgets, uses the configured planner on demand, and honors routing fallback/tier limits; PRD preparation policy does not apply to synthetic goal tasks.
-
-An assessment is a planning judgment, not a measured success probability. High testability means executable checks can detect an incorrect implementation. High uncertainty, architecture work or high risk require the frontier tier; difficult or broadly coupled work requires strong; routine implementation requires standard. Light is reserved for clear, low-risk mechanical work with strong checks. Weak testability raises the minimum tier. Reviews and critics have a standard minimum even for light tasks.
-
-```yaml
-assessment:
-  taskClass: implementation
-  difficulty: medium
-  uncertainty: low
-  risk: low
-  scope: low
-  testability: high
-  reason: Existing handler pattern and executable contract tests
-  approach: Extend the handler, cover the boundary cases, run contract tests
-```
-
+
+An assessment is a planning judgment, not a measured success probability. High testability means executable checks can detect an incorrect implementation. High uncertainty, architecture work or high risk require the frontier tier; difficult or broadly coupled work requires strong; routine implementation requires standard. Light is reserved for clear, low-risk mechanical work with strong checks. Weak testability raises the minimum tier. Reviews and critics have a standard minimum even for light tasks.
+
+```yaml
+assessment:
+  taskClass: implementation
+  difficulty: medium
+  uncertainty: low
+  risk: low
+  scope: low
+  testability: high
+  reason: Existing handler pattern and executable contract tests
+  approach: Extend the handler, cover the boundary cases, run contract tests
+```
+
 Yoke chooses an eligible profile at or above the required tier, then compares declared cost tiers. Optional `roles: [implementation, reviewer, critic, repair]` limits a profile's uses. Task `agent` affinity restricts implementation to that provider. Explicit routing rules and explicit quality role models retain precedence. With legacy `fallback: parent` and no tier ceiling, a missing suitable profile falls back to the start model (or the explicitly bound provider's default) and labels the fallback; it does not prove sufficient capability. `fallback: block` or a configured tier ceiling prevents that fallback. An invalid assessment blocks implementation.
-
-## Initial profiles
-
-| Tier | Codex | Claude | Gemini |
-| --- | --- | --- | --- |
-| light | gpt-5.6-luna, low | haiku | gemini-2.5-flash |
-| standard | gpt-5.6-terra, medium | sonnet | gemini-2.5-pro |
-| strong | gpt-5.6-sol, high | sonnet, high effort | gemini-2.5-pro |
-| frontier | gpt-6-astra, high | opus | gemini-2.5-pro |
-
-These are editable starting hypotheses, not measured equivalences or price claims. The Codex names follow the requested profile family. Account access is not established by finding an installed CLI. Gemini uses documented explicit model IDs and receives no unsupported reasoning-effort parameter. Several Gemini tiers deliberately share Pro; moving between those tiers alone is not a stronger-model transition. Adjust the presets to the models available to your account. Claude aliases can resolve to different concrete models over time. Provider-reported model identity remains separate from requested identity.
-
-Provider references: [Claude model configuration](https://code.claude.com/docs/en/model-config), [Gemini model selection](https://geminicli.com/docs/cli/model/).
-
-## Repair, escalation and evidence
-
-After an independent mechanical failure, capability routing permits one targeted repair at the initial tier, then raises the required tier on further failures. Attempts retain the current worktree and receive the previous gate findings. Every returned candidate still passes the normal acceptance, protection, quality, review and integration gates. Critical decisions, pause/cancellation and protected-acceptance violations stop retries. Provider process failures are classified conservatively as infrastructure; they do not count as evidence that a stronger model is needed.
-
-`routing.maxAttempts` limits implementation calls per unchanged task contract (default 5, configurable 1–8). The initial tier imposes an additional bound: light at most 5, standard 4, strong 3, frontier 2. An exhausted task blocks and requires a revised plan. These are inner implementation attempts; the outer loop's iteration count still counts task dispatches. Existing quality repair rounds and time limits remain separate bounds, and quality repairs can raise their profile tier by round. Goal execution keeps its existing global attempt, time and token budgets.
-
-Routing observations record task class, required tier, requested and reported models, effort, independent result, duration and available consumption. Selection considers matching project/task-class/tier history from the last 30 days within the bounded registry read. At least ten matching observations are required before an observed success rate below 80% excludes a profile. History is scoped to the concrete reported model to avoid mixing changed aliases. This is a conservative exclusion rule; it does not lower the planner's safety floor or claim calibrated probabilities. Missing usage remains unknown. Financial optimization and cross-provider performance require authenticated benchmarks.
-
-The dashboard's Now view shows the last recorded implementation profile, requested model/effort, rationale and next escalation tier. Usage & time retains reported model and role consumption, including assessment calls. Cached planning has no new model-call charge. Routing state is local runtime data and excluded from Yoke story commits.
+
+## Initial profiles
+
+| Tier | Codex | Claude | Gemini |
+| --- | --- | --- | --- |
+| light | gpt-5.6-luna, low | haiku | gemini-2.5-flash |
+| standard | gpt-5.6-terra, medium | sonnet | gemini-2.5-pro |
+| strong | gpt-5.6-sol, high | sonnet, high effort | gemini-2.5-pro |
+| frontier | gpt-6-astra, high | opus | gemini-2.5-pro |
+
+These are editable starting hypotheses, not measured equivalences or price claims. The Codex names follow the requested profile family. Account access is not established by finding an installed CLI. Gemini uses documented explicit model IDs and receives no unsupported reasoning-effort parameter. Several Gemini tiers deliberately share Pro; moving between those tiers alone is not a stronger-model transition. Adjust the presets to the models available to your account. Claude aliases can resolve to different concrete models over time. Provider-reported model identity remains separate from requested identity.
+
+Provider references: [Claude model configuration](https://code.claude.com/docs/en/model-config), [Gemini model selection](https://geminicli.com/docs/cli/model/).
+
+## Repair, escalation and evidence
+
+After an independent mechanical failure, capability routing permits one targeted repair at the initial tier, then raises the required tier on further failures. Attempts retain the current worktree and receive the previous gate findings. Every returned candidate still passes the normal acceptance, protection, quality, review and integration gates. Critical decisions, pause/cancellation and protected-acceptance violations stop retries. Provider process failures are classified conservatively as infrastructure; they do not count as evidence that a stronger model is needed.
+
+`routing.maxAttempts` limits implementation calls per unchanged task contract (default 5, configurable 1–8). The initial tier imposes an additional bound: light at most 5, standard 4, strong 3, frontier 2. An exhausted task blocks and requires a revised plan. These are inner implementation attempts; the outer loop's iteration count still counts task dispatches. Existing quality repair rounds and time limits remain separate bounds, and quality repairs can raise their profile tier by round. Goal execution keeps its existing global attempt, time and token budgets.
+
+Routing observations record task class, required tier, requested and reported models, effort, independent result, duration and available consumption. Selection considers matching project/task-class/tier history from the last 30 days within the bounded registry read. At least ten matching observations are required before an observed success rate below 80% excludes a profile. History is scoped to the concrete reported model to avoid mixing changed aliases. This is a conservative exclusion rule; it does not lower the planner's safety floor or claim calibrated probabilities. Missing usage remains unknown. Financial optimization and cross-provider performance require authenticated benchmarks.
+
+The dashboard's Now view shows the last recorded implementation profile, requested model/effort, rationale and next escalation tier. Usage & time retains reported model and role consumption, including assessment calls. Cached planning has no new model-call charge. Routing state is local runtime data and excluded from Yoke story commits.

package/docs/DASHBOARD-EVOLUTION.md

@@ -1,33 +1,33 @@
-# Dashboard evolution
-
-The local dashboard is an actionable workspace for registered Yoke projects. It reads the same saved project, loop, goal, acceptance, and measurement data as the CLI. Project-controlled text is rendered through `textContent`, and the server remains bound to the loopback interface with same-origin authorization for pause requests.
-
-## Overview
-
-Project status is derived from both the saved goal and the latest loop report. A blocked or running loop is not hidden by a completed goal. When goal and loop states differ, the card displays both. Blocked, failed, paused, unavailable, and stale active reports need attention; those projects are ordered before active projects, followed by the remaining projects.
-
-Cards also show the reported current task and saved blocker reason when available, so the overview explains why a project needs attention before opening it.
-
-An active loop report more than 20 minutes old is labeled **unconfirmed**. This means Yoke has an old active report, not evidence that the process is still live. The overview can be searched by project name, canonical path, or goal objective and filtered to All, Active, or Needs attention. A no-match state explains the result and provides a clear action that resets both search and filter.
-
-## Durable navigation
-
-The URL hash stores the current screen, project, project tab, period, UTC grouping, and complete custom date range. Supported screens are the overview, workspace comparison, and project detail. Supported project tabs are Now, Usage & time, and Results; periods are 1, 7, 30, 90, or 365 days; groupings are day, week, or month. Custom dates must be real ISO calendar dates in chronological order and cover at most 366 inclusive days.
-
-Invalid hash state returns to the overview with the 30-day/day defaults. Browser back and forward, a page reload, and Refresh restore the validated state. Refresh reloads data without resetting the selected view or controls. Starting any navigation aborts earlier fetches and changes a request generation, so an older response cannot replace the current screen.
-
-The workspace comparison schedules at most three project analytics requests at once. If navigation changes, in-flight fetches are aborted and no additional obsolete project requests are scheduled. All projects and individual project links remain available in the navigation while viewing the comparison.
-
-## Usage comparisons
-
-Usage & time compares the selected period with the immediately preceding period of exactly the same duration. A single time boundary is captured before either analytics request is made. The comparison covers recorded input plus output tokens, recorded acceptance events, and reported cost.
-
-When the preceding value is zero, the dashboard describes no change or new recorded activity instead of calculating an infinite percentage. A cost percentage is shown only when both periods have fully measured cost. Otherwise the dashboard says the percentage is unavailable. Current and previous missing-usage coverage is displayed from calls with unknown usage and unmeasured attempts. Recorded portions remain recorded portions; missing tokens or charges are not estimated as zero.
-
-Charts and their tables include periods that contain recorded events. Empty UTC calendar buckets are omitted and the chart explains that a gap means no recorded activity, not a measured zero. Detailed provider/model/role, model timeline, task, and phase tables remain below the comparison.
-
-## Design findings and limitations
-
-Goal state and loop state describe different durable facts and need independent presentation. Freshness is also separate from state: a saved `running` value can become unconfirmed without being rewritten. Navigation state belongs in the URL because the dashboard has several independently useful views and time controls. Analytics fan-out needs cancellation as well as a concurrency bound because registered workspaces may contain many projects.
-
-The dashboard combines local saved evidence with process-identity checks for supervised providers (see [Windows runner validation](WINDOWS-RUNNER-VALIDATION.md)). Unverified process identity remains unknown. It does not reconstruct activity that predates retained measurements, estimate missing provider usage or prices, or turn requested model names into proof of models used. Parallel call durations can overlap, so summed call time is consumption intensity rather than generation speed. The 20-minute freshness threshold is a presentation rule, not a process-health guarantee. No provider performance benchmark is implied by these views.
+# Dashboard evolution
+
+The local dashboard is an actionable workspace for registered Yoke projects. It reads the same saved project, loop, goal, acceptance, and measurement data as the CLI. Project-controlled text is rendered through `textContent`, and the server remains bound to the loopback interface with same-origin authorization for pause requests.
+
+## Overview
+
+Project status is derived from both the saved goal and the latest loop report. A blocked or running loop is not hidden by a completed goal. When goal and loop states differ, the card displays both. Blocked, failed, paused, unavailable, and stale active reports need attention; those projects are ordered before active projects, followed by the remaining projects.
+
+Cards also show the reported current task and saved blocker reason when available, so the overview explains why a project needs attention before opening it.
+
+An active loop report more than 20 minutes old is labeled **unconfirmed**. This means Yoke has an old active report, not evidence that the process is still live. The overview can be searched by project name, canonical path, or goal objective and filtered to All, Active, or Needs attention. A no-match state explains the result and provides a clear action that resets both search and filter.
+
+## Durable navigation
+
+The URL hash stores the current screen, project, project tab, period, UTC grouping, and complete custom date range. Supported screens are the overview, workspace comparison, and project detail. Supported project tabs are Now, Usage & time, and Results; periods are 1, 7, 30, 90, or 365 days; groupings are day, week, or month. Custom dates must be real ISO calendar dates in chronological order and cover at most 366 inclusive days.
+
+Invalid hash state returns to the overview with the 30-day/day defaults. Browser back and forward, a page reload, and Refresh restore the validated state. Refresh reloads data without resetting the selected view or controls. Starting any navigation aborts earlier fetches and changes a request generation, so an older response cannot replace the current screen.
+
+The workspace comparison schedules at most three project analytics requests at once. If navigation changes, in-flight fetches are aborted and no additional obsolete project requests are scheduled. All projects and individual project links remain available in the navigation while viewing the comparison.
+
+## Usage comparisons
+
+Usage & time compares the selected period with the immediately preceding period of exactly the same duration. A single time boundary is captured before either analytics request is made. The comparison covers recorded input plus output tokens, recorded acceptance events, and reported cost.
+
+When the preceding value is zero, the dashboard describes no change or new recorded activity instead of calculating an infinite percentage. A cost percentage is shown only when both periods have fully measured cost. Otherwise the dashboard says the percentage is unavailable. Current and previous missing-usage coverage is displayed from calls with unknown usage and unmeasured attempts. Recorded portions remain recorded portions; missing tokens or charges are not estimated as zero.
+
+Charts and their tables include periods that contain recorded events. Empty UTC calendar buckets are omitted and the chart explains that a gap means no recorded activity, not a measured zero. Detailed provider/model/role, model timeline, task, and phase tables remain below the comparison.
+
+## Design findings and limitations
+
+Goal state and loop state describe different durable facts and need independent presentation. Freshness is also separate from state: a saved `running` value can become unconfirmed without being rewritten. Navigation state belongs in the URL because the dashboard has several independently useful views and time controls. Analytics fan-out needs cancellation as well as a concurrency bound because registered workspaces may contain many projects.
+
+The dashboard combines local saved evidence with process-identity checks for supervised providers (see [Windows runner validation](WINDOWS-RUNNER-VALIDATION.md)). Unverified process identity remains unknown. It does not reconstruct activity that predates retained measurements, estimate missing provider usage or prices, or turn requested model names into proof of models used. Parallel call durations can overlap, so summed call time is consumption intensity rather than generation speed. The 20-minute freshness threshold is a presentation rule, not a process-health guarantee. No provider performance benchmark is implied by these views.

package/docs/MIGRATING-TO-1.0.md

@@ -1,33 +1,33 @@
-# Migrating to Yoke 1.0
-
-Yoke 1.0 changes unsafe implicit behavior into explicit policy.
-
-## Runner permissions
-
-The default is `runner.permissions: safe`. Automation that intentionally requires a full
-sandbox bypass must pass `--unsafe` or configure `runner.permissions: unsafe`. Use
-`read-only` for planning and probing.
-
-## Reviews
-
-Reviewers write `.yoke/review-verdict.json`; Yoke validates and consumes it. The reviewer must
-differ from the implementer unless `--allow-self-review` is explicit. CI can add `--json`.
-
-## Commit ownership
-
-Yoke resolves identity before implementation. Configure it when Git has no identity:
-
-```yaml
-commit:
-  authorName: HECer
-  authorEmail: hec_er@web.de
-  allowCoAuthors: false
-```
-
-## PRDs, audit, and cleanup
-
-Existing PRDs remain valid. Optional `needs`, `area`, and `agent` fields add dependencies,
-collision domains, and affinity. Enable the story audit gate with `audit.enabled: true` and
-version suppressions with `suppressionsVersion: 1`.
-
-`yoke loop cleanup` now reports retained worktrees. Add `--remove-worktrees` for deletion.
+# Migrating to Yoke 1.0
+
+Yoke 1.0 changes unsafe implicit behavior into explicit policy.
+
+## Runner permissions
+
+The default is `runner.permissions: safe`. Automation that intentionally requires a full
+sandbox bypass must pass `--unsafe` or configure `runner.permissions: unsafe`. Use
+`read-only` for planning and probing.
+
+## Reviews
+
+Reviewers write `.yoke/review-verdict.json`; Yoke validates and consumes it. The reviewer must
+differ from the implementer unless `--allow-self-review` is explicit. CI can add `--json`.
+
+## Commit ownership
+
+Yoke resolves identity before implementation. Configure it when Git has no identity:
+
+```yaml
+commit:
+  authorName: HECer
+  authorEmail: hec_er@web.de
+  allowCoAuthors: false
+```
+
+## PRDs, audit, and cleanup
+
+Existing PRDs remain valid. Optional `needs`, `area`, and `agent` fields add dependencies,
+collision domains, and affinity. Enable the story audit gate with `audit.enabled: true` and
+version suppressions with `suppressionsVersion: 1`.
+
+`yoke loop cleanup` now reports retained worktrees. Add `--remove-worktrees` for deletion.

package/docs/MIGRATING-TO-1.1.md

@@ -1,27 +1,27 @@
-# Migrating to Yoke 1.1
-
-Yoke 1.1 makes Claude, Codex, and Gemini share the same setup, planning, runner-selection, and decision behavior.
-
-Run the setup wizard once in an existing project:
-
-```bash
-npx @hecer/yoke@1.1.0 setup .
-```
-
-It preserves existing Yoke configuration and asks for target agents, code graph, loop state, default runner, and decision mode. A non-interactive agent can apply explicit choices with `--yes`.
-
-The new config fields are optional and backward-compatible:
-
-```yaml
-runner:
-  agent: codex
-  permissions: safe
-loop:
-  enabled: true
-  timeoutMinutes: 30
-  decisionPolicy: critical  # auto | critical
-```
-
-`loop.onAmbiguity: resolve|abort` and `--on-ambiguity=` still work. Prefer `decisionPolicy` for new projects: `auto` resolves routine choices without asking; `critical` pauses only for high-impact decisions and continues after `yoke loop answer`. Resume restores the original isolation, review, runner, permissions, timeout, and policy flags instead of silently weakening the run. If the restart cannot begin, `yoke loop resume` retries from the request-bound state stored under Git's private state directory.
-
-Restart an already-open Codex task after retrofit if it does not discover the newly generated `.agents/skills/yoke-workflow/SKILL.md`.
+# Migrating to Yoke 1.1
+
+Yoke 1.1 makes Claude, Codex, and Gemini share the same setup, planning, runner-selection, and decision behavior.
+
+Run the setup wizard once in an existing project:
+
+```bash
+npx @hecer/yoke@1.1.0 setup .
+```
+
+It preserves existing Yoke configuration and asks for target agents, code graph, loop state, default runner, and decision mode. A non-interactive agent can apply explicit choices with `--yes`.
+
+The new config fields are optional and backward-compatible:
+
+```yaml
+runner:
+  agent: codex
+  permissions: safe
+loop:
+  enabled: true
+  timeoutMinutes: 30
+  decisionPolicy: critical  # auto | critical
+```
+
+`loop.onAmbiguity: resolve|abort` and `--on-ambiguity=` still work. Prefer `decisionPolicy` for new projects: `auto` resolves routine choices without asking; `critical` pauses only for high-impact decisions and continues after `yoke loop answer`. Resume restores the original isolation, review, runner, permissions, timeout, and policy flags instead of silently weakening the run. If the restart cannot begin, `yoke loop resume` retries from the request-bound state stored under Git's private state directory.
+
+Restart an already-open Codex task after retrofit if it does not discover the newly generated `.agents/skills/yoke-workflow/SKILL.md`.